I'm trying to make a script that will allow me to teleport to my reticle position. Both instructions for my reticle position and player coordinates are correct. Both my flags get reset so I know its running through the script like it should. However my player just wont teleport. I cant figure out where I went wrong. Any help will be greatly appreciated.
You are sure that your coordinates for player/reticle are 4 bytes apart?
This will not fix your problem, but should be corrected:
loadblink:
movaps xmm3,[rax+50]
movaps xmm0,xmm2 //add this line
Aside from that, there are a few things that you can test:
1. Add custom addresses to your table after the script is executed, and put these values in the address fields:
ret_x
ret_y
ret_z
Just to make sure that you are loading the correct values.
2. Manually change one of your coordinate values to see if you can teleport through objects (not around them). If you cannot, then you need to find better coordinate values to work with.
Corrected the script as you mentioned. I'm positive both sets of coordinates are 4 bytes apart. I added ret_x,y,z and noticed z still wasn't updating so I made +68 the injection point and that fixed that. I'm able to manually change my coordinates successfully. I can move through a wall into a building, move to the opposite end of the map, and fall through the ground when I lower my height value. Not sure if that's what you meant by through objects. My reticle coordinates pick up all collision fields so I know that's correct, besides it just the values I want. I just still cant teleport..
Attachments
[The extension png has been deactivated and can no longer be displayed.]
Just checked and yes it is. When I switched characters an address popped up for his coordinates but my Player Coordinates script wouldn't update for that character.
I tried both out. The pointers were off a bit on both but that's no big deal. The first one had no effect at all. I changed the height coordinate and my character didn't go up at all. The second one ended up crashing the game which tells me at least something is happening! So I tried messing around with the offsets in the script to match the old ones. Then again to match the pointer offsets but still no luck. I'll try rewriting my script again and try pushing registers like you did.
I've seen it in a couple scripts I've looked at but have no idea what it does. Does it set anything special to the following code or is it just another specified location?
The pointers should not be off. If you changed something, you should change them back. I wrote two examples -- one for values that are 4 bytes apart, and one for values that are 8 bytes apart. Always be checking that the instructions that you have chosen are still being used and that they are exclusive to the values that you are trying to manipulate. It should also be noted that the instructions should be 'accessing' your values constantly, not 'writing' to the values only when you do something in-game. When the script is activated, the values for coordinate and reticle XYZ should populate. Manually changing the values for coordinate XYZ should affect your character in-game.
I'll have to take another look at my player coordinates instruction then seeing that it wants to write the value as soon as I move rather than right away. I'll work on this some more and let you know if I make any progress. But why does it have an effect when the offsets are 8 bytes apart when both in memory and instructions they are only 4 bytes apart?
You need to use instructions that constantly 'accesses' your coordinate/reticle values. Right-click on the values and check to see what 'accesses' them...not what 'writes' them.
Copy a segment of code from assembly viewer around the instruction that handles your coordinate values and paste it here.
I've used access to find both by instructions the first time. I went back and kind of started from scratch again. But I ended up with the same instructions again. Many instructions popped up and I went through most and made pointers to see if they pointed to the correct address. Many of them put me about 10000+ offsets away from the actual address and others would point to the right address at first but as soon as I moved in game it would point to a different address. None of them were constantly checking my coordinates either. As for reticle coordinates only 2 popped up. There are a couple things I may have overlooked that I'll look into further. Such as the timing of the crash on the second script. In the pictures below I debugged on the players z coordinate.
Attachments
[The extension png has been deactivated and can no longer be displayed.]
[The extension png has been deactivated and can no longer be displayed.]
When I say 'constantly accesses', I simply mean, several times per second -- or, at least, every second. It is important to use an instruction that is reading your coordinate/reticle values all of the time (even when you are not moving around in the game), so that you can teleport instantly, and without having to move in the game first in order for the code to initialized etc..
Also, when you check to see what is accessing the values, when the debugger window pops up and instructions populate the list, you can right-click on an empty, white space inside that window and select 'check if found opcodes...'. This will show you if the instructions that populate the list are exclusive to the value that you are targeting, or if they access multiple addresses. You will see an additional number appear in the count column -- (1), for example. If there are any instructions that are exclusive to coordinate/reticle values, and are also accessing your addresses constantly, then those would be good choices for your injection locations.
For this game, you may need to incorporate checks for the different characters, or do some additional work in order to keep the scripts working -- but I honestly do not recall if that was the case for this game or not. Zanzer would probably know, as I know that he worked on this target for a bit.
I was checking for constant updates. I stood still for roughly 20 seconds then went to check if any counts updated and they did not, at least I didn't notice if they did. I found "check if found opcodes" to be extremely useful. I've always seen it but never really wondered about its functionality. However after doing all that my best option was still using my first instruction. Knowing that wouldn't work I started debugging on addresses in the same region as my coordinates just to find something that constantly updated, was unique and pointed to my coordinates every time. I know that's not the best thing to do but I tried anyways. Came up with a few I could use but they still didn't work. I came to the conclusion that either there are checks (for character or having the weapon raised/lowered) which are pretty easy to find, or the certain instructions I'm looking for aren't popping up due to one or all in game trainers I have. I'll feel pretty damn stupid if its the second reason.. But due to my lack of interest in this game and the fact I'm not going to build/release a full table for it, I'll go back to it at a later time. I'm still determined on getting that script to work.
I was originally working on this type script for No Mans Sky, but after seeing how the game handled coordinates I thought it was near impossible to make. I had another go at it and was able to easily make one. It has a few limitations though. The player coordinate values go up to 130 then back to zero or visa versa depending on the direction. I'm guessing when it does that its writing a value somewhere that further relates to specific coordinates?
Either way it should be pretty easy from here on out. And I wanted to thank you again for all your help on this subject!
Unless I overlooked something (or you did) one of the scripts that I sent you should work -- assuming that you did not change anything. It is impossible to know, for sure, without looking at it myself, though.
As far as the coordinates going to 130 and then back to 0, it's hard to say. Could be a different data type that you should be working with. Assuming that the game is not an older game or a basic, 2D (look-down) type game. Most games have a 0/0 near the center of the map, that will be positive/negative, depending on your location relative to that ground zero location. The only time I have seen values increase, and then reset, are oddball 2D type games that use screen location or something for coordinates.
With regard to instructions that are constantly getting accessed -- typically, for coordinates, this should be easy to find. Some games require you to have the target window in focus and/or to be in-game for this to actually happen, though. If the game really does not have any instructions that are reading the coordinate values constantly (I find this incredibly hard to believe, especially if the game is 3D), then you can look at other values from within the same data structure that might have instructions that are constantly accessing them, and just hook those instead. You can use the same approach for finding instructions that are exclusive to the player to avoid any additional code segregation requirements.
