Spring RTS Engine

It reminds me of the map from Battlefield 1942; "Operation Market Garden" with the Bridge at Arnhem.

Go check the things that are needed urgently thread in Dev. And complain to Zaphod.

aGorm

Stuff like this shouldn't be handled as a map-feature anyways. Large-scale level geometry should be part of the landscape model - it would allow for proper occlusion culling, render distance, etc. Plus, simplified models usually provide easier physics for navigation. Unfortunately, it also means that mappers have to work in unusual mapping software instead of their fave tools.

The problem is that fusing such models with a landscape is tricky. Most free engines incorporatign them use them entirely - and how many players would be willing to give up landscape with mutable terrain for that?

But yeah, basically this needs to be done as a BSP or a irregular octree (a la Sauerbraten) for it to work right.

Alternately, if simple collision models for rectangles and columns and suchlike were implemented, it could be broken up into many small parts. That would also provide seperate render distances. The thing would be indistructible though, or else platforms would be left floating in space.

If features could have seperate parts, and EACH part had a seperate collision detection, and you could chose box not sphere, then things like this would be muchg easyer as you just have to make each leg and the bridge all differnt parts. Also parts would drop out of view distance. Althouth personly I think very large features should not disaper no matter what hence why I wanted an Alwaysrender tag.

aGorm

aGorm wrote:If features could have seperate parts, and EACH part had a seperate collision detection,...

Just make a feature for each part of the bridge.

But anyway, tanks still won't be able to drive over them, and making tank drive over the face of a feature probably won't even be suppored by the Spring engine. Just use features as eyecandy, and stop dreaming about bridge you can drive over.

so your bridges were hovercraft transports or something right, just kinda forced the animattion and manually moved the unit to the other side?

I'm malining aGorm a modified spring binary with 3 new tags, one such you'll find useful for rendering features at a distance, "drawfar = 1".

or you cna downlaod the code yourself and recompile spring and test. See filunvierse. You can also make your feature burnable by adding "burnable = 1" and idnestructible tag has been fixed.

Why not use flamable=1; like for TA trees and shrubs?

because he probablie didn't know there was one. Actully its because in teh source (I have looked) the trees use that name. I take it he's copyed code over thats the same.

If only I could compile...

aGorm

zwzsg wrote:

aGorm wrote:If features could have seperate parts, and EACH part had a seperate collision detection,...

Just make a feature for each part of the bridge.

But anyway, tanks still won't be able to drive over them, and making tank drive over the face of a feature probably won't even be suppored by the Spring engine. Just use features as eyecandy, and stop dreaming about bridge you can drive over.

I thought of a simple way of making that possible that only required minor code changes... but the solution really wasn't gracefull, and I don't really understand the full function of all the code enough that I can fully impliment it. The problem is that spring has alot of stuff depending on the construction of the ground... so I can't just modify the way that building the ground works and have everything still work properly. I need to go through everything that calls the ground and make sure it's either calling the right ground object, either the original or the new one I'm trying to make. I might keep trying to understand what is going on here... if I do it shouldn't be too long before I know weather what I'm planning is possible or not. That is if I can even get the source to compile... (stupid boost)

the bridges I've got do have seperate parts to the original model, so if the new model format could export the mutliple objects into into the s3o format then we'ed have a good collision model.

and with the collision spheres could it be possible to shrunk them to hunderds around the faces in a big model or a string/line for ramps, ropes, cables, pipes etc.
or would that cause serious frame rate drop?

I did have 1 thought. You COULD have the plactforms (if Features can be made to support scripts) relate their own health to the health of the connected pillars (so if Pillars Connected = 4, then the death of a pillar removes 1/4 of the health of the plactform and the game renders the model at a slightly different angle........