Also, since we’re on slow downs, if you make your own map, make sure it’s closed, i.e. that the world has walls and ceiling so that nothing can fly out of it into the void. The map I included in the sample has, by mistake, no collider of the sky, so if you use a grenade something might fly through the sky and then out of the world. Once in the void, it will start gaining speed and thus slowing things down to a hold (that’s because the ccd will need to put more and more stuff between the frame positions). I will update the map as soon as I have a moment, but you can use this oversight of mine as a training task in adding OdeBoxGeoms from Blender ;D.
This is a difficult question to answer. This code, as I wrote in the first post, is extracted from the project I’m working on and thus it might see any kind of changes as needed. You must understand that releasing this code here is not my priority ATM.
So far, since the release, the code has seen some minor refurnishing already. The readme PDF mentions that I was planning to ditch the odeGeomData class, and this is exactly what I did. I didn’t want to wait with the release, though, since I had no idea how long that would take. It proved to be not that difficult (which is good news actually, since that means it’s not that big of a change).
That’s why, as you can see, I’ve decided to tag this release 0.9 instead of 1.0, exactly because I was preparing for that little change.
Is it safe to use it? I guess so. The changes in the API, so far, include ditching odeGeomData in favor of operating strictly on physicalObjects, removing the isTrigger flag in favor of “trigger” value for the objectType variable and not much more actually. Other things are internal and shouldn’t affect your code that much.
If you started now and switched to 1.0 once it’s released, you’d basically just need to remove all odeGeomData objects from your code, as well as calls to odeWorldManager.getGeomData and .setGeomData methods. To make the future switch less painful, if you decided to start real codding (and not just some testing, prototyping and training) now, keep this in mind:
-
The code will operate strictly on physicalObject class children (it’s not required for your classes to inherit from that as soon as they have methods of the same names and contain an objectType variable).
-
The callbacks will be moved into the physicalObject classes themselves, so they won’t be assigned to any variables in odeGeomData (which will no longer exist). Thus make sure your selection callback methods are called selectionCallback and your collision callback methods are called collisionCallback. That way you won’t need to rename them.
-
Make sure that, in your collision callbacks, you get to physicalObjects as soon as possible and get the geoms and bodies from those objects. That way you can save more time on changing callbacks in the future – all you will need to do is remove a part of the code.
That’s all of the most important stuff I guess. I do a lot of writing and don’t usually keep records (except for version control) so I might have forgotten something, sorry if I have.
I’m planning to get 1.0 uploaded sooner than later, but it takes some time to extract and comment the code (I generally don’t use comments with Python).
FYI, the 1.0 will contain, aside of much cleaner code (due to the lack of odeGeomData, of course), classes for guns. Pistols, shotguns and assault rifles based on raycasting. You might be interested in those, I guess 
.
I would suggest you only test for now, and not dive into some real codding of the actual game. I will try to get 1.0 up as soon as I can, but surely not before the weekend.
Your welcome. Have fun.