writeBytes to address without timer

[nightn4]

Hi all ! Can this be done without using a timer? Without the timer, the value will change after changing the location. I will be grateful for the example, Thank you.

if flag == 0 then -- bla
writeBytes("[[[[baseaddres]+1c]+5c]+c]+30", 2)

else --bla

if flag == 1 then -- bla
writeBytes("[[[[baseadress]+1c]+5c]+c]+30", 1)

[FreeER]

without the createTimer object, sure you can use createThread and sleep to reimplement your own timer, but without the general idea of repeatedly checking it... no. At least not without hooking the assembly actual code that changes it and doing the check/assignment there but that's not necessarily lua then.

You can do anything once without a delay (just write the code and, ta da!), you can do something multiple times in a row with a loop, and you can even do it multiple times in a row with a delay using a loop and sleep IF it's ok for the rest of CE to freeze while waiting for your script to run. Beyond that you have to use CE's already existing concept of a thing that can wait x amount time before doing something aka the timer, or recreate it using what CE and lua make available to you.

The only "real" alternative I see for it is using a hotkey when you press a key to reset it whenever you do something that changes it, that may not be very practical depending on exactly how everything is working in your game and may not be as convenient either way. So in the end you're mostly left with the question, why not use a timer?

[nightn4]

Thanks FreeER!
Difficulties of translation
Could you give an example of how?

Maybe it can be done in assembler?
//example
//or asm

Inv:
cmp [Inv_flag],0
je health
mov [baseaddres]+1c]+5c]+c]+30,#1 //how to freeze this value exactly 1 byte

[FreeER]

You've got the basic idea there. To read a pointer path in assembly you have to do each offset separately (well I believe CE supports the combined format but it only calculates the address when you enable the script so if it changes that's useless because it'd still be using the old address after it changed)

Code: Select all

// assuming eax is free, if not use another register or push/pop
mov eax, [baseaddress+anyBaseOffset]
mov eax, [eax+1C]
mov eax, [eax+5C]
mov eax, [eax+C]
// eax is now player/struct/object base
// now you can access the actual value as you normally would for it's type
mov byte ptr [eax+30], #1

There's a couple other way where your final address ends up in eax instead of just the player base but with the player base you could access multiple values without recalculating eax or having to push/pop it to prevent recalculating it.

[nightn4]

It's almost what I wanted, I think it works,
I'm going to try now

Update after the test, this method works fine
Thank you very much FreeER

[gir489]

You should look at how the game is accessing these variables, and either hijack that getter/setter schema, or emulate it.

People who tried to cheat on Fallout 3/Fallout New Vegas found this out the hard way, because the game had a generic getter and setter and that's what people would see from the breakpoint, but if you look at what calls the generic getter for the player, you would've noticed that the call puts a static pointer deref to the stack, and from there, you could figure out if the call is coming from the player or not.

It's probably doing something like FreeER said. But if it's just doing EAX+C in the call or EAX+2AE, you'd want to look for a pointer that ends with +2AE, since that's more likely to be consistent.