Does anyone have the source code and/or level-design specs for the \"Duel\" mod?
I'm working on a mod myself (see http://descentbb.net/viewtopic.php?t=10707), and the major sticking point I'm up against is forcing players to a certain location or spawnpoint. The Duel mod does this (when a particular \"arena\" is picked), so I know it's possible, but I'm not sure how it's being done.
\"Duel\" mod code question
You have to be careful when moving objects to specific places. Once should be fine (we did it in OG3 using whatever function was available, I lost the source a long time ago ) but if you try doing this frequently you get stuttering.
I remember how I originally implemented the hovering code for OG3... every frame the game would shoot a ray downwards from the ship, determine the distance between the ground and the ship, and move the ship accordingly. Led to jerky gameplay.
I remember how I originally implemented the hovering code for OG3... every frame the game would shoot a ray downwards from the ship, determine the distance between the ground and the ship, and move the ship accordingly. Led to jerky gameplay.
- Foil
- DBB Material Defender
- Posts: 4900
- Joined: Tue Nov 23, 2004 3:31 pm
- Location: Denver, Colorado, USA
- Contact:
Including playerobjects? I'll have to look into it.The Lion wrote:Look in the dallasfuncs.cpp provided by the D3-SDK. There's a function
with which you can move objects...
DCrazy wrote:...but if you try doing this frequently you get stuttering.
How often is "frequently"? I'll only have to do it once per player every few minutes or so... is this an issue?
Foil:
That's fine. I was talking ~60 times per second. Though you might look into using waypoint objects if they suit your needs.
And come to think of it, we didn't actually use any functions to move the player; we set the player's position vector directly. It's part of the object struct, should be a Vec3 or Vector3 or whatever it's called.
That's fine. I was talking ~60 times per second. Though you might look into using waypoint objects if they suit your needs.
And come to think of it, we didn't actually use any functions to move the player; we set the player's position vector directly. It's part of the object struct, should be a Vec3 or Vector3 or whatever it's called.
No problem; just be careful that your pointer to the player object is always valid, and remember that any changes you make won't be taken until the next frame.
Also, a lot of collision detection will be avoided if you directly set the object's position, and you might wind up not triggering the \"changed segment/room\" event that's normally raised when an object crosses from one room or terrain segment into another. Your best bet is to do a lot of debugging, and keep all the edge cases in mind.
Also, a lot of collision detection will be avoided if you directly set the object's position, and you might wind up not triggering the \"changed segment/room\" event that's normally raised when an object crosses from one room or terrain segment into another. Your best bet is to do a lot of debugging, and keep all the edge cases in mind.