arlight1 wrote: ↑Thu Apr 27, 2017 3:54 pm
Squall8 wrote: ↑Thu Apr 27, 2017 3:11 pm
Also try debugging on addresses around the coordinates, not the coordinates themselves. Make sure you can still point to your coordinate values.
Can you elaborate on what you mean by this? What would watching and tracing the addresses around the coordinates allow me to do?
-He is basically referring to:
++METHOS wrote:- You can check to see if there are any instructions that are exclusive to any other address/value inside of the data structure for the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.
That being said, setting up a filter may not always be required. Any of the OTHER values inside of the same data structure may have instructions that access them, exclusively, thus allowing you to inject your code there.
arlight1 wrote: ↑Thu Apr 27, 2017 3:54 pm
Thanks for the list Methos. Here are the ones I've attempted so far and the reason they didn't work:
- You can use a pointer address for your filter, inside of your script, for the value that you are trying to manipulate.
Not sure if CE is guessing the correct data types for the structure containing XYZ for each player/enemy, but the ones it designates as pointers seem to be constantly changing. They change to an address which exists inside of the process and then change to something that doesn't point anywhere (e.g. 13CCCCCCC)
-It's hard to say without looking. However, I would not recommend going this route unless you have absolutely no other choices. That being said, the pointer may not be resolving correctly simply because you have not gone deep enough and/or found a stable pointer yet.
arlight1 wrote: ↑Thu Apr 27, 2017 3:54 pm
Could you expand on these points and what you mean by them?
- You can use pointer trees inside of the data structure to find something viable.
- You can check to see if there are any instructions that are exclusive to the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.
- You can check to see if there are any instructions that are exclusive to any other address/value inside of the data structure for the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.
- You can analyze assembly code to see if an identifier is being checked or assigned somewhere.
1. Pointer trees -- when you analyze a data structure, you'll notice that some of the offsets are pointers, and not traditional values. This is CE's best guess...but you can manually change them all to see if they are really pointers, as well as add offsets that may be missing etc.. You can expand these entries and see entirely different structures inside of them. Sometimes, you can find important values that can be used for your compare, by not limiting yourself to the base structure that you are originally analyzing. You may have to go several levels deep (inside of other pointer trees) to find what you need.
2. Exclusive instructions for targeted address -- when you right-click on an address in your cheat table and check to see what is accessing it, the debugger window will pop up and instructions should populate the list. If you right-click on an open, white space inside of that debugger, you have the option to 'check if found opcodes...'. Doing so will show you if any of the instructions that are accessing your targeted address are exclusive to your targeted address (i.e. you'll see if any of the instructions are ONLY accessing your targeted address and nothing else). A new number will appear inside of the 'count' column, indicating how many addresses are being accessed ( 1 through 8 ). If you see an instruction with a (1), then it may be exclusive to your targeted address...meaning...you can inject at that instruction and use it and/or and save off the address that it is accessing. You can use a custom symbol to save it and use it inside of your primary script, for your compare. So, in your primary script, the instruction may access your targeted address and loads of other addresses, but all you have to do is compare the addresses to the address that you have stored, and filter out all of the unwanted addresses. Even if the targeted address changes during each run/level etc., the instruction that you are using to save off that address should always be storing the correct address.
3. Exclusive instructions for any of the other addresses inside of the same data structure as your targeted address -- same as above, accept, you have a ton of other addresses that you may be able to use to find an instruction that is exclusive to any one of the other addresses inside of the same data structure as the targeted address that you are wanting to manipulate.
4. Analyzing assembly - this is advanced and not something that can be easily explained, as the circumstances will vary. However, this step is pretty much NEVER needed.