| View previous topic :: View next topic |
| Author |
Message |
TPRammus Advanced Cheater
Reputation: 0
Joined: 05 Jan 2016 Posts: 61 Location: Germany
|
Posted: Wed Jun 22, 2016 2:08 pm Post subject: Access the registers of other addresses? (in a script) |
|
|
Hey!
Can you somehow access the registers of other addresses? For example:
I have two scripts Script one: One Hit, Script two: Fall through the ground.
I've found out that at script one, esi+118 determines if the enemy or the player accesses the code. (1=enemy, 0=player)
Can I compare esi+118 with 1 also in my second script anyhow?
I would try something like that:
| Code: | push esi
mov esi, 04567890 //04567890 is esi of script nr one
cmp [esi+118], 1
je fall
pop esi
...
fall:
pop esi
... |
|
|
| Back to top |
|
 |
cooleko Grandmaster Cheater
Reputation: 11
Joined: 04 May 2016 Posts: 717
|
Posted: Wed Jun 22, 2016 2:18 pm Post subject: |
|
|
Does the first script only access one address?
if yes, then store esi by:
| Code: | alloc(bESI,4)
registersymbol(bESI)
mov [bESI], esi |
i think globalalloc() does those two lines of code in one, but i never use it.
in other script
| Code: | cmp [bESI],0
jne return
push esi
mov esi, [bESI] //04567890 is esi of script nr one
cmp [esi+118], 1
pop esi
je fall |
|
|
| Back to top |
|
 |
Zanzer I post too much
Reputation: 126
Joined: 09 Jun 2013 Posts: 3278
|
Posted: Wed Jun 22, 2016 5:59 pm Post subject: |
|
|
You use globalalloc() in both scripts so that you can enable either script first.
Cheat Engine will make sure to not allocate it twice.
Now either script can read from or write to the address independently.
|
|
| Back to top |
|
 |
TPRammus Advanced Cheater
Reputation: 0
Joined: 05 Jan 2016 Posts: 61 Location: Germany
|
Posted: Wed Jun 22, 2016 6:40 pm Post subject: |
|
|
| Zanzer wrote: | You use globalalloc() in both scripts so that you can enable either script first.
Cheat Engine will make sure to not allocate it twice.
Now either script can read from or write to the address independently. |
But wouldnt you still need to activate the health script first with cooleko's example? Because esi needs to get moved into bESI first, right?
|
|
| Back to top |
|
 |
Zanzer I post too much
Reputation: 126
Joined: 09 Jun 2013 Posts: 3278
|
Posted: Wed Jun 22, 2016 7:05 pm Post subject: |
|
|
That first compare would check to see if it's been populated yet.
Not necessarily the correct jump under it, but you get the idea.
I assume you would want "je fall" to execute the original code.
|
|
| Back to top |
|
 |
++METHOS I post too much
Reputation: 92
Joined: 29 Oct 2010 Posts: 4197
|
Posted: Wed Jun 22, 2016 7:56 pm Post subject: |
|
|
As Zanzer said, you can incorporate a check/test for the data.
Alternatively, just use globalalloc in your first script, and set the second script as a child that gets enabled/disabled automatically, with the first script.
Personally, however, I would just combine the scripts.
|
|
| Back to top |
|
 |
TPRammus Advanced Cheater
Reputation: 0
Joined: 05 Jan 2016 Posts: 61 Location: Germany
|
Posted: Thu Jun 23, 2016 12:17 am Post subject: |
|
|
| ++METHOS wrote: | | Personally, however, I would just combine the scripts. |
But if you combine them, the enemies would be killed with one hit but they would also Fall through the ground which doesnt really make sense?
I want to implement this later in a trainer. Can you check for a checkbox inside of an aob script so only the globalalloc is ran or something like that? And how would you combine the scripts? I would just enable both scripts after each other when the checkbox is being activated.
EDIT: I think I know now what you mean. Do you mean I should make an separate script for the globalalloc? But then you could not run all (three now because of the globalalloc script) scripts at the same time because of the identical injection point of those two scripts?
|
|
| Back to top |
|
 |
++METHOS I post too much
Reputation: 92
Joined: 29 Oct 2010 Posts: 4197
|
Posted: Thu Jun 23, 2016 12:42 am Post subject: |
|
|
You set up a trigger. Having a trigger would be better anyway, especially for your fall script. You could set up a keyboard hotkey or controller button to initialize it. You could either have a key/button to turn it on and one to turn it off, or, set up a timer, so that every time you pressed a key/button, the fall would activate and run for 1 second or whatever...that way, you could execute it on the fly, whenever you wanted, without having to have it enabled constantly, all of the time.
CE will automatically combine your scripts for you. Just open the first script, and with the second instruction highlighted inside of memory viewer, you can add another injection via the auto assemble window where your first script has already been generated. Just select template from the drop-down menu again and inject your second script. You can do this as many times as you like.
Really, you could do it however you like. There are many solutions.
|
|
| Back to top |
|
 |
TPRammus Advanced Cheater
Reputation: 0
Joined: 05 Jan 2016 Posts: 61 Location: Germany
|
Posted: Thu Jun 23, 2016 9:43 am Post subject: |
|
|
| ++METHOS wrote: | | You set up a trigger. Havi... |
Something came to my mind. There are more than one address which accesses this assembly code. And esi is obviously everytime different. So since the addresses which accesses the fall through the ground code does have nothing to do with the health, an enemy could access the health code during an ally accesses the fall through ground code so the ally would fall through the ground because the health code says "its an enemy".
|
|
| Back to top |
|
 |
++METHOS I post too much
Reputation: 92
Joined: 29 Oct 2010 Posts: 4197
|
Posted: Thu Jun 23, 2016 5:40 pm Post subject: |
|
|
| I don't understand what you're saying. But to be clear, combining two or more scripts does not cause them to be related in any way; the scripts still execute separately and do not 'touch' each other. You can still register a symbol or use the same, allocated value in each script, however.
|
|
| Back to top |
|
 |
Zanzer I post too much
Reputation: 126
Joined: 09 Jun 2013 Posts: 3278
|
Posted: Thu Jun 23, 2016 5:58 pm Post subject: |
|
|
Yea, I thought the whole purpose of you populating the address was because you found an instruction that only accessed the player's structure.
So you were reserving that address to use in all of your other "player-only" scripts.
Keep searching for an instruction that only effects the player. Like the HUD constantly accessing a display value.
|
|
| Back to top |
|
 |
TPRammus Advanced Cheater
Reputation: 0
Joined: 05 Jan 2016 Posts: 61 Location: Germany
|
Posted: Thu Jun 23, 2016 11:55 pm Post subject: |
|
|
| Okay thank you all for your help and explanations! It will help me a lot!
|
|
| Back to top |
|
 |
|