Spring RTS Engine

I would say we need to replace those trees first and take the screen shot again, they're glaringly obvious and quite ugly, and ruin the overall image, which is other wise quite nice.

http://trepan.bzflag.bz/spring/more-gnd-fog.jpg

They aren't that bad, especially for an RTS.

You have to admit they're in need of some loving though?

I'd love to see better trees, but I'm not about to go make them myself

Is there no magic lua trickery of sorts to improve their appearance? No lua facelift?

You can use a lua script to replace them with another type of feature, e.g. a better looking tree.

I know that..

Black & White 2 had the best trees I've seen in an RTS game!
http://www.lionhead.com/teambw/makingof.html -(Blooming and Trees)

Would be cool if one could define a bunch of models to use for random trees, i.e. tree0 = model0.s3o, tree1 = model1.s3o, ... me and some other people already made some very low poly trees, though much more than the billboard ones now.

PS: After seeing supcom's trees spring's trees ain't that bad. :)

Pendrokar wrote:Black & White 2 had the best trees I've seen in an RTS game!
http://www.lionhead.com/teambw/makingof.html -(Blooming and Trees)

GROWING TREES

FLOZi wrote:

Pendrokar wrote:Black & White 2 had the best trees I've seen in an RTS game!
http://www.lionhead.com/teambw/makingof.html -(Blooming and Trees)

GROWING TREES

Well SKIP THAT PART go to "Blooming and Trees"!

If somebody will write a LUA script that will replace trees with random Units from a list, that can be included with a map, and that someone will also write a Widget version and a Gadget version, I will give you replacement low-poly foliage and ... other things.

IT MUST GIVE UNITS TO GAIA, though. Units, not Features.

Map version, Widget version, Gadget version. From a config list. So that we can distribute / maintain a single, unified "game" that has these, and all future Maps can make use of variant code to call different objects, and players could activate a Widget for "ultra-high-performance trees", "pretty trees", and games could have very specific Gadget-generated objects ... and... other stuff.

Then I will give you ... stuff. Which I have built, but have not released, because I was waiting for this code to bloody well exist in the first place. Lathan also has a lot of stuff, too, which could be used with this concept once it's refined a bit.

nit: Widgets can't do that by definition, they are run in unsynced code.

But you could disable the tree rendering with a widget (set maxtrees=0) and then draw those with widget code ^^

Bloom solves everything. We should force render light sources behind every tree. They would move with the camera to make the tree impossible to see from every angle!

Please, don't derail this thread. I have been waiting for this for ages.

And, ok, ok, I can see the point about Widgets, which I keep forgetting, sorry.

So we need Gadget code, one example mod-side (cannot be dis-allowed, very important) and map-side (maybe with a Widget allowing for some manipulation, so that we can do LOD for the trees, give super-competitive players trees that are just a tri-mid, etc.).

Oh, yeah... and, um, if it's Gadget code, and runs from the Map... the Host's results, drawing Units from the random table, will be what everybody sees, right?

I think it would be a bad idea to allow replacement of mapper defined features, and such a gadget would best be done using a mod gadget and only for features that break the mod or features that the engine uses by default (aka tree1,tree2etc, the default trees)

However argh you cant swap them out for different versions based on the computers performance ebcause as soon as that happens the game desyncs because one persons gamestate differs because of their lower poly count optimized trees.

I don't want to swap out mapper-defined stuff, like to swap out models used on one of Forb / Lathan's maps, for example.

That'd be silly, and bad for mappers.

I just want to be able to replace the standard trees.

As for the LOD stuff... my thought is that if all players were given access to the same objects, and they merely swapped models, that it would not be subject to desync, because Spring doesn't care about the models, it cares about the Units, but I could be incorrect, and it's not that important anyhow.

Now, is anybody willing to model new trees to replace the default? Ideally, I would like to see a random selector pick between different sets of trees, which can be expanded as new generic trees are released.

Sort of something like this...

Small Supreme Battlefield loads. LUA checks the tree archives, finds;
Elm.sd7
TemperateClimate.sdz
QuantoShockFoliage.sd7
Default.sdd

Loads one of them randomly OR gives the host the ability to select the set.

Neddie: You are aware that Spring procedurally generates its trees, right? A bit of tweaking to the generator would produce better results than having the same modelled ones every time, I believe.