DescentBB

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.

Per the information I've been given, the original coder for \"Duel\" was Gwar. Anybody know how to contact him?

Look in the dallasfuncs.cpp provided by the D3-SDK. There's a function
with which you can move objects, so you could get the code from there.

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.

The Lion wrote:Look in the dallasfuncs.cpp provided by the D3-SDK. There's a function
with which you can move objects...

Including playerobjects? I'll have to look into it.

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.

Excellent, thank you!

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.

Thanks for the advice.

I haven't yet dived back into the code, but I probably will here in the next couple of days.