[Help] Understanding pointers and opt codes in general.

[Wombleinc]

I have been a long time user on fearless evolution and have learned a lot over the years. However, I still am struggling to understand certain pieces of the puzzle when trying to make my own scripts. Here recently I had tried to make a few script for Blue Price for the amount of steps.

I was basically just wanting to take the amount of steps find out what accesses it which appears to be:

Code: Select all

mov [rsi+38], eax

eax in this case held the number of steps count and it was putting it into rsi+38 which was my step count address. rsi from my understand contains my base step count address or "player" +38 is the offset to where my step count address was located.

The script I was trying to build would take rsi and store it into a pointer called my_steps or [my_steps],rsi
My full code looked like this:

Code: Select all

[ENABLE]
alloc(newmem,2048,"GameAssembly.dll"+6E705E)
alloc(my_steps,8) // this allocates 8 bytes to hold the RSI base address
label(return)

registersymbol(my_steps)

newmem:
  mov [rsi+38],eax
  mov [my_steps],rsi  // store base address of steps
  jmp return

"GameAssembly.dll"+6E705E:
  jmp newmem
  nop
return:

[DISABLE]
"GameAssembly.dll"+6E705E:
  db 89 46 38 80 7B 60 00  // original instructions

unregistersymbol(my_steps)
dealloc(newmem)
dealloc(my_steps)

The problem was that when I restarted the game. The my_steps pointer would give me the right step count but it wouldn't actually affect the steps themselves so I got the incorrect address at that moment in memory but what confuses me is the way opt codes work, shouldn't I be getting the correct value since I am taking the address from rsi when that piece of game code runs?

I've watched a lot of videos and I get confused because people will find out what accesses the address and start building scripts right off of the opt code that they find that accesses the address. How do they know this won't be incorrect when they close the game and start the game back up?

[happyTugs]

The problem was that when I restarted the game. The my_steps pointer would give me the right step count but it wouldn't actually affect the steps themselves so I got the incorrect address

Prior to restarting the game, were you able to modify the step count and have it reflect in the game? If not, it might be the visual count instead of the actual count. You could try activating mono to dissect and analyse the address contained in RSI for more info.

I've watched a lot of videos and I get confused because people will find out what accesses the address and start building scripts right off of the opt code that they find that accesses the address. How do they know this won't be incorrect when they close the game and start the game back up?

People typically assume that the hooked instruction only accesses the address they are interested in unless proven otherwise. So, it's mostly trial and error.

[Wombleinc]

The problem was that when I restarted the game. The my_steps pointer would give me the right step count but it wouldn't actually affect the steps themselves so I got the incorrect address

Prior to restarting the game, were you able to modify the step count and have it reflect in the game? If not, it might be the visual count instead of the actual count. You could try activating mono to dissect and analyse the address contained in RSI for more info.

I was able to find the step count address that effected the actual value on screen so I know at least I was working with the right address there. I used the what accesses this address on that address which gave me
mov [rsi+38], eax. rax held my step count number as hex. So my step count number was being put into rsi's address with an offset of 38.

[AlexS]

I got the incorrect address at that moment in memory

(Google Translate)

This instruction "mov [rsi+38],eax" changes different addresses, not just the number of steps. That's why you see the last address in "my_steps".

Now several users have posted tables and trainers for this game on the forum, and each table has the same error - the scripts change all the addresses, not just the "useful" ones. Therefore, players use these tables to mark failures in the game. In addition, the problem is that the game automatically saves progress, and using scripts with errors can damage game saving and destroy game progress.

[imjustmaxie]

I have been a long time user on fearless evolution and have learned a lot over the years. However, I still am struggling to understand certain pieces of the puzzle when trying to make my own scripts. Here recently I had tried to make a few script for Blue Price for the amount of steps.

I was basically just wanting to take the amount of steps find out what accesses it which appears to be:

Code: Select all

mov [rsi+38], eax

eax in this case held the number of steps count and it was putting it into rsi+38 which was my step count address. rsi from my understand contains my base step count address or "player" +38 is the offset to where my step count address was located.

The script I was trying to build would take rsi and store it into a pointer called my_steps or [my_steps],rsi
My full code looked like this:

Code: Select all

[ENABLE]
alloc(newmem,2048,"GameAssembly.dll"+6E705E)
alloc(my_steps,8) // this allocates 8 bytes to hold the RSI base address
label(return)

registersymbol(my_steps)

newmem:
  mov [rsi+38],eax
  mov [my_steps],rsi  // store base address of steps
  jmp return

"GameAssembly.dll"+6E705E:
  jmp newmem
  nop
return:

[DISABLE]
"GameAssembly.dll"+6E705E:
  db 89 46 38 80 7B 60 00  // original instructions

unregistersymbol(my_steps)
dealloc(newmem)
dealloc(my_steps)

The problem was that when I restarted the game. The my_steps pointer would give me the right step count but it wouldn't actually affect the steps themselves so I got the incorrect address at that moment in memory but what confuses me is the way opt codes work, shouldn't I be getting the correct value since I am taking the address from rsi when that piece of game code runs?

I've watched a lot of videos and I get confused because people will find out what accesses the address and start building scripts right off of the opt code that they find that accesses the address. How do they know this won't be incorrect when they close the game and start the game back up?

Hi.
Since we're talking about Blue Prince, it's kind of hard for beginners to start with.
Values might be easy to find, but the memory location / pointers related to it might be confusing.

Values like: Steps, Gems, Coins, Keys
They are stored in a different FSM pointer, for each item type. In each FSM pointer, you'd have to look at the variables that correspond to it.
Some FSMs have two different item addresses in its FSM Variables list (FSM for Gems has both Gems and Keys, but the only real one is Gems. Keys address is in the Keys FSM.

And from what I've looked, some tables posted use a shared instruction that overrides values of various item types altogether (e.g change one value also changes the steps,keys,gems value). The one I used in my table is how I separate them.

You can check my table on how I do it.
viewtopic.php?p=403463#p403463