GENETICZZ wrote: ↑Tue Apr 15, 2025 9:01 pm
[...]
[...]. I've tried looking for the skill points value, for example I've got 15 skill points I scan for that 4 bytes and so on. By logic, I'd check what accesses this address and hover on a "learn skill" button to see if it checks/compares that you got enough skill points, but somehow I can't find out what you've found out, I never get to the same place that your AoB leads me to for example. Would you mind sharing/explaining on what I am doing wrong? would much appreciate it.
first of all, it's been quite awhile since I made the script, so I've forgot the exact route I took.
but your approach could get the results as well, albeit longer in certain scenarios, but would work anyway.
so, if you goes by the route of using "what access the address" method, for this game engine, it would take you quite awhile if you start tracing from the skill points reading codes right away,
as most likely the reading codes you found are handling NOT ONLY the lock/unlock process, but many other processes as well like value DISPLAY, value COLOR DISPLAY, etc.
so, after you have:
1. located the correct obtained skill points/used skill points,
2. get the correct opcodes that access the pointes,
the next thing you should do is to find
the next RET following the obtained skill points or used skill points reading codes (by just reading the codes literally line by line, or by break and trace. if you're not familiar with any of these, try all and practice~), then use "find out what addresses the instruction access" on the RET.
if the RET only goes to one address,
try the next RET.... until you find a RET that goes to multiple addresses on different scenario.
now you can narrow down which RET to study further by simply observing the hit # of the addresses (i.e., see which ones goes up when they should), then find out which of them would leads you to the "required skill points checking process" by, again, using break and trace, and/or break point (especially when the value you're interested in is being thrown around in the stacks, using break point should help keeps track on them).
another thing to look out for, is if your initial approach failed to returns useful info, try to broaden your search.
in this case, try to see what access (again, both the obtained and used points should be checked) when the skill menu is open as well.
because, if memory serves, the game refresh the skills-learnable-lock on skill menu access. BUT I can't stress this enough, that it's been awhile and I forgot the details already , I can't guarantee if tracing from skill menu is the best route.
but this engine isn't too difficult to trace around anyway, and the game engine didn't update much on most of the aspects we're (or I'm) interested in cheating since AC Origin.
for example, the time of day module is still the exact same since ACOdyssey, my mod script from Odyssey can be used on this game without any modification, I just need to find the injection point.
even if it isn't the exact same, the logic behind is still the same. e.g., the game's own gamespeed manipulation still consist of a float/double modifier and a 1 byte flag in the same offsets pattern, when the game want to apply a slow motion, it flip the flag to true so that the game would read the speed modifier, and flip the flag back to zero and reset the modifier to 1 when finished -- which is the same in ACValhalla AND Watch Dogs Legion.
same goes with the items prefix/suffix, which is a recursive pointers array... if memory serves, it doesn't changed much from ACOrigin to Odyssey....etc. but I digress.
so, to summarize, two new tricks to learn: when and where to use "find out what access".
1. when: in this example, if on skills hover doesn't returns what you need, try on skill menu access. (general hints, for some games, try it on skill learning button pressed could do the trick as well. in other words, imagine on more scenarios the value could be access and try them out)
2. where: "find out what access" can be used on RET as well, useful to differentiate the callers to the value accessing codes, although what you'r looking for may not be immediately at the RET address, utilize with breakpoint or simply break and trace after you narrowed down the possible routes after the RET is a good practice, especially when compared to simply using "find out what access" on the value accessing codes.
um..... that's about it for now... I think.
hope that helps~
EDIT:
just read my scripts once more and tried to jog my memory, it seems that the "button locked by insufficient check" is done on skill highlighted, and the "skill prerequisite requirement check" is done on skill menu access.
but again, I'm not sure, it's been a while, you will have to check for yourself~ good luck!