how to update memory_address.ini

[dcep93]

Hi!
I'm an engineer trying to understand how to get the values to populate memory_address.ini

I've learned cheat engine basics and seen Roguelinke's video, but I think with a little more support, I can better understand all the moving parts.

Specifically, I'm comfortable on fetching p2_data_offset and rollback_frame_offset, but I'm totally lost on how to efficiently get player_data_pointer_offset. Also, I don't know the best way of finding updates like facing or if I wanted to add current_health as a feature in addition to damage_taken.

Once we have a repeatable pattern, I think I can build a python script that will automatically perform these steps and update the memory address file. Even if that's not possible, I can help to post updated files and document these steps so that others can follow too.

Would it be possible to set up some time to hop on a call with @WAZAAAAA0 or @Fimox, since they seem to understand this stuff a lot better than I do? I promise I'll do the heavy lifting, and I think a 30-minute sync will be plenty to get me up to speed.

There's a Tekken patch coming May 8 - perhaps we can grab those updated values together!

[WAZAAAAA0]

added an experimental ghetto OPPONENT_SIDE "quick finder script" using the instructions above me

as for player_data_pointer_offset, I think I fixed the "quick finder" to work more reliably in more stages/modes/situations etc. (I took a full 8 GB RAM dump of the game process in February using Windows Task Manager and I'm still using it to come up with AOB signatures lol)

rest of the CT won't last long, incoming patches（-＿- ）
TK8BotPrime_2024-05-03.zip

[dcep93]

this is awesome, thanks!

I'm making progress on this python script to automatically detect everything, but it's hard to say when it'll be done, maybe a few weeks.

Just a few questions while I have people's attention

1. how do we know the move_id offset is 518?
2. why did you pick the offsets "Polaris-Win64-Shipping.exe"+08E732C8 with offsets 10 68 8 30 518? my pointer scan had many many results where the final offset was 518

[WAZAAAAA0]

how do we know the move_id offset is 518?

the devs placed it there and that's where all the scanning brought us. It just be like that

my pointer scan had many many results

no it didn't, those were all invalid except 1. Try this: keep the "found pointer list window" open, restart the game, go back to training, reattach CE to the game process, click Pointer scanner -> Rescan memory -> Address to find: the-new-correct-address and watch the list get pruned with only 1 survivor.

Once we have a repeatable pattern, I think I can build a python script that will automatically perform these steps and update the memory address file.

imo, because of HOW the game gets patched, I doubt it's possible to keep it updated fully automatically with no human intervention whatsoever. Let's say we were to find a solid way to get the player_data_pointer_offset memory area (with a so-called "AOB signature" usually) that keeps all the hot and spicy addresses close to each other such as:

blabla1 + 518  = move_id
blabla1 + 57C  = recovery
blabla1 + 5B8  = hit_outcome
blabla1 + B388 = attack_startup
etc.

well, unfortunately in the next update the structure may or may not change UNEVENLY! (real example btw)

blabla2 + 518  = move_id
blabla2 + 57C  = recovery
blabla2 + 5B8  = hit_outcome
blabla2 + B438 = attack_startup <<<<<<
etc.

An observation:
Honestly, if you're in the process of reworking the bot, there's a lot to gain by making it more resilient to incorrect addresses/values.
Sure we've made the process of providing updates a bit easier by using the memory_address.ini fork, by documenting the steps in a wiki, and most importantly by crowdsourcing the efforts in a centralized place... but there's no good reason for the bot to crash and burn entirely when it can't find a valid damage_taken or whatever for example (that one's not even displayed anywhere lol)...

[dcep93]

Wow, thanks so much for the context! My understanding is much better now - here's my progress so far

1. I've been working in my own repo - I find that my fork is quite resilient! I use it often, and it basically never crashes. It's not quite ready to be showcased, since I'm doing heavy construction on it while experimenting with update_memory_address.py. I expect to be all done with my development on it by early June.
2. Speaking of which, I'm making tons of progress on update_memory_address.py. If we assume that move_id_offset is constant at 0x518, it's able to determine most of the values that make it to the ini file. It takes about 5 minutes to scan the entire memory state and build a pointer map. Once it does, it asks for a few user inputs, like p1_high_attack or p2_crouch. I tried to make it automatically do the inputs, but it was tricky to force the inputs to go to the Tekken process, and tricky to send inputs to p1 vs p2.

Currently, it determines values for

1. expected_module_address
2. rollback_frame_offset
3. p2_data_offset
4. frame_count
5. attack_type
6. player_data_pointer_offset
7. opponent_side

With a bit more work, I should be able to do many of the other addresses. The code is here, but unfortunately, it's not the most legible, so I don't imagine many people will be able to add features. I'm going on a week vacation tomorrow, but I hope to implement the rest of the PlayerDataAddress values soon.

[dcep93]

my tool worked! (I think)

right now, you have to manually find move_id_offset, but in the future, perhaps it could detect it automatically - seems annoying, but potentially possible

here's what I have so far, I want to check some things before making an announcement in the other thread - probably can post there by Monday

let me know what necessary offsets are missing - these are the only ones my fork needs

https://github.com/dcep93/TekkenBot/blob/5990de0e4c97093fed4757822da0cf2869f8b7e0/TekkenBot420/assets/config/memory_address.ini

[dcep93]

Interesting - it's understandable that it found different locations for facing and stun_type, because it looks for the lowest possible offset. but it deemed 0x654 as impossible for complex_move_state

it might be nice to see the values located at these offsets side-by-side to compare them - that'll be the first place I'll look when things get fishy

[dcep93]

ok, I think things are stable and working for me, curious if stuff is broken for others, but perhaps best time to test is next patch

for facing, I do see 4 frames of discrepancy between our values while the side is switching, but they are identical outside of that - TBD if that will cause problems

for stun_type, seems that for the player doing the hitting, 0x61c reports "1" for 18 frames during the jab, which sorta makes sense, but isn't a valid value for StunStates. Also, it reports StunStates.NONE=0 for those same 18 frames for the player getting hit, whereas 0x614 reports StunStates.GETTING_HIT=256.

for complex_move_state, I just see 0's always for 0x654, but 0x65c reports the various values for both p1 and p2. Not sure if it's legit, but that's what I see so far...

I think the weirdest thing is that expected_module_address isn't consistent. It doesn't really affect anything, but in previous versions, the value returned from windll.kernel32.Module32First was always the same. I don't really understand the implications here, but just thought I'd mention.

[zeratul7x]

What about update this bot for 1.05 patch?
update_memory_address.py doesn't work and have an error. =(

[dcep93]

aww sorry it doesn't work for you!
my sister just got married, so I took a break from Tekken last month

I was planning to get back into it once Lidia comes out, so I'll probably skip patch 1.05

I'll update https://github.com/dcep93/TekkenBot/blob/master/TekkenBot420/assets/config/memory_address.ini with patch 1.06 if/when it comes out, and hopefully update update_memory_address.py too so it will be more reliable

[zeratul7x]

@dcep93
What about update your bot for v 1.07?
Also, Lidia's moves doesn't display in the log. Fix of this is reqired too =(

[dcep93]

working on it, just got back from work travel, probably will fix Monday or Tuesday

[dcep93]

thanks @Fimox - that helped a lot!

part of the reason for the delay was opponent_side - it seems the string I'm looking for has changed to
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 02 00 00 00 02 00 00 00 02 00 00 00 02 00 00 00 02 00 00 00 02 00 00 00 04 00 00 00 04 00 00 00 04 00 00 00 04 00 00 00 04 00 00 00 04 00 00 00 08 00 00 00 08 00 00 00 08 00 00 00 08 00 00 00 08 00 00 00 08 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 20 00 00 00 20 00 00 00 20 00 00 00 20 00 00 00 20 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 40 00 00 00 40 00 00 00 40

notice the change from previously ending with:
...40 00 00 00 40 00 00 00 40 00 00 00 40 00 00 00 40

https://github.com/dcep93/TekkenBot/blob/master/TekkenBot420/src/main/update_memory_address.py#L817

@zeratul7x it should be updated on my main branch - btw, how do you run my app? Do you run the exe that I build, or do you run the code from python yourself? I recommend running the exe, but curious what works for you!

[zeratul7x]

@dcep93 I'm running exe file from release section.
But, when new patch is come, i try to update it with py script tool. Sometimes, it's work correct )
So, is Lidia move display problem resolved in this release?