@QuothTheRaven - Good to hear it
@CPU
The functions in the include file are very parallel to the direct DLL calls. The big purpose behind the include file is that it allows us to change stuff as we update the system without effecting the front end code. If we did it as a normal direct plugin we lose that benefit and it makes updating a lot harder.
Maybe the only place of real interest would be in the RunCollisionPRO() function. If you look at that function in the include file, you'll find that it resets the pointer for the "active stack".
The "active stack" is a list of currently active objects being tested for collision - When you call DeActiveObjPRO() for an object it removes the object from this stack, hence making the RunCollisionPRO() function operate faster with the more objects you de-activate.
Next, it runs through all of the objects in this "active stack" and passes all of their positions to the collision system. (This allows the system to determine where an object moved to)
After all the objects' positions are updated, then it calls the DLL function to update collision for all active objects.
Next, it resets the "active stack" pointer again.
Then it runs through and fetches the 'current' (as they are in DLL memory) positions of all active objects and positions them using the DBPro function 'position object'.
This effectively makes collision work between DLL memory and DBPro memory.
Currently, I don't have a real big demand for documenting all of the direct DLL functions, so it's not on the task list. But, if you have any specific questions regarding direct DLL calls I'd be glad to help explain them to you