Page 1 of 1

Question about opcodes with many addresses.

Posted: Thu Jun 16, 2022 12:17 pm
by wne01
Hello.
I did already finish the tutorial including the shared instruction one.
I tried noping an instruction but it seems it stops the game working.
So I checked how many addresses this instruction accesses, there were about 200 addresses.
Structure dissect for 200 addresses seems too many.
What do I do if I specifically want only one address to be nopped from those 200 addresses?
Or any better way to solve this?

Re: Question about opcodes with many addresses.

Posted: Thu Jun 16, 2022 12:22 pm
by LeFiXER
You need to check for commonalities between the shared addresses.

Re: Question about opcodes with many addresses.

Posted: Thu Jun 16, 2022 12:54 pm
by wne01
I check for commonalities. But it seems it's quite hard to find the uncommon address. And there are 200 addresses.

Re: Question about opcodes with many addresses.

Posted: Thu Jun 16, 2022 4:03 pm
by GreenHouse
If it's something like a value for the Player and it's changing an offset, you could take the base of it and check if something accesses it, and use the instruction that only accesses what you want. Then mov it into an alloc and go back to the shared one and do a compare with the alloc.

Otherwise, you could look for commonalities in 5 of those with yours, if you find something then make a script with a couple of compares with that, that jump to the original code, then check what gets to the second compare. If you check the second compare while playing for a bit, and only yours got through then you should be fine.

Or you could also ignore that function and go to its call (Break&Trace), and see if you can get to one that is only executed with what you want. Then nop that call if it doesn't need anything to be returned.

Re: Question about opcodes with many addresses.

Posted: Fri Jun 17, 2022 9:37 am
by SunBeam
I recommend also properly checking those commonalities. People usually find a byte or integer that is 0 for player and 1 for enemy and decide on the spot that it will work like that. They don't debug the offset to see if/how the Engine is using that byte or integer, which often leads to "not working for me" :)