Printable View
You'd have to check if the player's slave unit has a null parent-object-index or not.
By iterating over the player_data you can interface with all active players. The data iterator skips any datum which is invalid (read: not allocated for use).
I thought you were done with Halo?
Using your OS as a info sauce. Trying to incorporate some of my math ideas into a bot (...which I will not release). Halo is a good sex slave for doing this kind of stuff.
Also, it would require a bit of work but implementing a signature system to get the offsets right on every version would help a lot don't you think? Halo Sausage would work on every version then (afaik). I could help you with that.
The codebase isn't setup to use dynamic addresses and I really don't see anymore updates past 1.09, at least not anytime soon. Not only that but some function hooks are done at the very end of the function they're hooking. This is a problem because some of the patches done to the client\dedi have caused the padding bytes between functions to fall under 5 unused bytes (and you need at least 5 to perform relative branches). This would still leave version specific junk in the code. Then you'd have to test for each build of the game to make sure this theoretical signature system doesn't give false positives to function and data memory addresses.
I'm not here to support egg heads who are still running around on 1.00. They're all pirates to me and I don't support people who feel they can't shell out less than 10$ or whatever to play a 7 year old game that they still enjoy.
If someone wants to develop and prototype the implementation into OS on their own then fine. But I'm not taking part in it.
@Pat
Even though Kornman00 gave me crap about it too I still worked on it lol. I tried modifying the ENGINE_PTR/FUNC_PTR macros with a sig scan routine but of course it doesn't work because they are macros and ran through the pre processor first. It would've made everything really really easy that way. You would have to scrap those macros and edit each function pointer to run through the scan routine, which I didn't even want to get started on. I have a signature generator and scanner that won't give false positives he was mentioning. Of course the longer the signature the more unique it is. The other butt hurt part is going to be data pointers, to scan for them you have to reference from code, but to save time you can write a routine to search for them and generate a signature too. I'll contact you later
Does Engine::Objects::GetLocation() return screen coordinates of the object position? And GetOrigin() returns the object position? And GetCameraPosition() returns the position of the camera that is attached to the specified object? Merr?
I made a final decision to use OS to build Forge CE. I doubted myself before and even though I am a hobbyist programmer, it wasn't until recent that I realized how omnipotent OS is. Thanks for this.
GetLocation is actually mis-documented. It copies the object's scenario location. A scenario location houses the bsp leaf and cluster index that the object is currently located by (this will be fixed in the next release, don't worry).
GetOrigin gets the position of object in the game world. If its a child object, it uses the parent object to calculate its world position.
GetCameraPosition is for unit based objects only and it calculates the view position based on the unit's 'head' if it has one. If not, it will estimate the sight position based on the object's origin.
Awesome thanks. Also what would happen if I passed an object datum_index to one of these functions that is actually to an invalid / non-existent object? Will it pass a null pointer or will it just crash? I guess I could test for myself.
Oh yea, I wanted to shorten my code by using the - operator to subtract two real_point3d variables that equal a real_vector3d, because I use Magnitude() on the result -- but it says the - operator is ambiguous and won't let me. Is there a way I can do this without initializing each member individually? For now I'm using Set(), but vect = point - point would be super!
Because of OS, my development time is tenfold!!
In OS2 RC, if the engine function code doesn't have a null handle check then it will crash. If you're passing a handle which is to a datum that is no longer active then it will more than likely crash too. However, as long as you're using the game state's memory for data handles you should be fine. If you're not keeping your handles up to date then it's on you for having crashes from inactive datum accesses.
real_point has operator overrides for casting to real_vector and D3DXVECTOR types. So just cast the real_point to a vector then you can use the vector's manipulators.
I haven't yet tried type casting, I will get to that later. Right now GetOrigin is crashing Halo for some unknown reason. I used YELO_DEBUG_FORMAT to print out the object handle and object address before calling it. All the other printed data is fine and working great. I don't see anything wrong, but maybe you might? Thanks
http://www.pastebin.com/Kjg2hB6H
Debug output of my last test:
Edit: Fixed a few things, updated but still crashing.