Sorry...mistyped...
Thanks for fixing.
Sorry...mistyped...
Thanks for fixing.
Just a heads up, the same mechanism should work with all object transports (Boats/Zeppelins/Airships/the Tram/etc) if you extend it to work with rotation also.
The whole transport position matrix (from where the game object base address + 1D8, etc, thing come) is stored at game object base address + 1A8 (at least for 3.3.2, didn't test for 3.3.3 yet); it's a 4x4 matrix to store 3D positions and rotations.
To get the world position for the mob/player, you just need to do a matrix multiply of the position vector for the mob/player/whatever by the position and rotation matrix from the transport.
I have got a private message for this thread, but i'm too leecher to reply plus maybe some of you might found this useful (who want to chase offsets in Cheat Engine), so i post it here:
hi,
thanks about the post with elevator positions.
i have the same problem for ages :-)
> In 3.3.2, these are:
> (Player base address + B+ 6C
> (Player base address + B+ 70
> (Player base address + B+ 74
do you have the offsets for 3.3.3
or can you explain how you found these?
thank you very much[/QUOTE]
The offsets haven't changed in 3.3.3 or 3.3.3a. I have checked it. So you can use those.
I used Cheat Engine to find the correct addresses. I knew that the player addresses are stored in (base + x) + y format, so i searched for x or y coord of my character (i have knew the coords of my char from another address, but those changed as i step on to the elevator), and checked all addresses found. If you search for, and move your char, and search again, it would be 16-21 addresses. Then i checked the neighbours of these addresses for correct x, y, z coord, discarded those too far away from player base, and the ones which changing within the elevator, and trace back, which hold the offset of these (find which writes to these address, maybe you need to move, or jump a bit, to catch the address). Then i searched, which contains this address, and calculcated the offset from the player base.
The elevator position was a bit harder, i had to search for z coord (x, and y are fixed). I searched the two side position of the elevator in thunder bluff. I guessed the z coord (between 50-90 for lower, 120-150 for higher positon), and narrowed the search with 4-5 searching when the elevators at side position.
The game object position is stored in an eaier way than player or creature, just base address + x, so when i got the address, i have already know the base address, so i could calculate the offset.
As I have learnt many, many good things from this forum (thank for all, who contributed useful things tips, methods or anything), i have decided to spend some time to write down and send something back that might be useful for some of you. This is my solution for elevator usage, but this works for all kind of moving transportation.
I'm using a simple pathfinding, pathwalking method as A* algorithm. The character's path is a set of waypoint calculated by this algorithm. Let's see a simple example, the thunder bluff elevator. It has a lower and a higher end position. For the correct use of the elevator, the character must walk to the elevator, wait for it to arrive, get into, wait for it arrives to the other position and get out.
So you have to record two waiting position in front of the elevator (one on the lower ramp, for going up, and the other on the upper ramp for going down).
You have to record two another positions to record. These are the positions to move in the elevator, and wait for the elevating. You can record these, when the elevator is in the correct position, and your character is in the elevator. These four points are your characters coordinates in the correct positions.
You have to record the two side position of the elevator. The elevator is a game object, you can get it from the wow object list (object type 5), with the correct id (base address + 0C).
You can easily get the id of the elevator, if you create a function to list all the game objects within a range (ex. 10 yards), then move the character close to the elevator, wait to come, and use the function (thunder bluff elevator ids are 4170, 4171).
Make your algorithm to use the elevator positions for calculating walking path (positions inside the elevator are neighbours, others are neighbours only, if close enough), and make the path walk.
When the character reaches the waiting point in front of the elevator, stop the character, and check the elevator for the correct position. You have to store waiting point - elevating point - elevator position in relation.
After the elevator arrives, the character can move to the lower elevator position. Then stop, process to the next elevating point, and wait the elevator to reach the other stored elevator position. Then the character can continue walking towards its destination.
There can be some problems with this method.
1.: The character can't make difference between the waiting points, so it will stop at the other waiting point, when it comes out from the elevator, and wait for an elevator position, if that already began elevating. So you have to store that, you waited for the elevator. I store elevator id (you can use a boolean if you wish), if my char get to the first waiting point, and set it to zero, when i get to a waiting point and have an elevator id set. If this is zero, the char must wait for elevator position, if its set and the character reached a waiting point, it indicates that the character have got out from the elevator, and reached the other waiting point, so don't stop, just release elevator id.
2.: When the character get in to the position inside the elevator, it want to continue its way to the other point. But it can't reach it on foot, so it will move around in the elevator. You can eliminate this by storing that you have entered in the elevator. You can store the elevator id, or use a boolean. In this case the character musn't move until the elevator reaches its correct position.
In this method, it doesn't matter if it is an elevator, or a zeppelin, it works a same way. I have already posted the character, and game object coordinate address few post above. You can read coordinates from there. I don't know the game object coordinate is what point of the game object, but it doesn't matter, i just use it to check if the elevator is at correct position (which is recorded before).
Feel free to use the stuff.
thanks lapari72 :-)
There are simpler ways to handle elevators.
First of which, is simply waiting for an elevators relative speed to hit 0 before getting on/off of it. (Relative speed is a very simple calculation) This means you won't have to record any start/stop positions for the elevator. You can then use TraceLine to find out where the 'edge' of the platform is where you need to stand. (All transports [including elevators] have their start/stop locations stored 'somewhere'. I leave that as an exercise to the reader to find out where)
Once a transport has 'stopped' according to its relative speed, you simply move forward until your transport GUID matches the transport you decided to take.
Once you're on the transport, you wait for the transports location to change, and start your relative speed checks to determine when the transport has hit it's other location, at which time, you simply hop off.
Thanks Apoc!
Watching relative speed is a good idea. Plus you need to check the elevator distance from the character, when it's not moving, because it can be in the other position (but if you can read elevator start/stop locations from memory, that would be the smartest solution).
Using gameobject ID for transport checking maybe better than GUID, because GUID changing from server to server, ID is the same, but unique for transports unless i'm mistaken (i have only checked it only on thunder bluff elevators).
You need to check the GUID so you know which transport you're watching the relative speed for once you get on it. It also helps to know if you're actually on it!
Hey, necroing this because a lot of wrong information is given.
You can not just do transport.Location + me.Location to get your location. Your rotation is also relative to the transport, which means you will have to rotate your position by the gameobjects rotation before you do the addition.
The far easiest way is to use the world matrix that every game object has. As of the current patch there is a virtual function at index 49 that returns a 4x4 matrix of the object.
So basically, you grab that matrix and transform your location by it and you will have your correct world position.
Also, if you have noticed weird things with CTM when you're on transports, it's because you need to click the relative location. I'll give you a hint: Inverse the matrix.
Edit: Bleh, just saw RoKFenris already posted this. Fail by me.
[16:15:41] Cypher: caus the CPU is a dick
[16:16:07] kynox: CPU is mad
[16:16:15] Cypher: CPU is all like
[16:16:16] Cypher: whatever, i do what i want