Local Team Recoloring

[trepan]

I'll be adding a new feature that will allow you to recolor
the teams before the game starts. Here is an example file:

https://spring.clan-sy.com/svn/spring/t ... colors.lua

There are a few of good reasons for adding this feature:
- better colors for the color-blind
- disallowing colors like white and black which can conflict
with features like selection hilighting, or are difficult to see
on certain maps
- giving the user the ability to have a consistent color set
(in the example file, enemies are reddish, and allies are greenish)

For lua scripts, a couple of new calls have been added:
Spring.GetTeamColor(teamID) -> nil | r, g, b, a
Spring.GetTeamOrigColor(teamID) -> nil | r, g, b, a

[Argh]

Woot! Custom icons, here we go.

[trepan]

Huh? This file can only be used locally (it can not be read from an archive).
(and I added custom icons a long time ago )

[YokoZar]

It "would be nice" if there were still a way to identify players by the color they chose, so when your teammate says "help me with green" you don't get confused. Although, we should be using player names anyway

Still, this sounds like a good idea whose time has come.

[SwiftSpear]

I'm gonna recommend throwing this into a separate mode. There are dozens of gameplay reasons why I need to be able to see every enemy/ally as the same color as every other player in the game.

[trepan]

1. Separate mode?
2. Then don't use it

[Argh]

Huh? This file can only be used locally (it can not be read from an archive).
(and I added custom icons a long time ago Wink)

Er, I meant that I could read from Spring.GetTeamOrigColor(teamID) -> nil | r, g, b, a and then apply that to an icon, so that I might, maybe someday could get the kind of custom icons I want, to replace teamcolor with. I have been using your custom icon stuff for ages, this is a sideways application of what you've made available. You also realize that, as soon as you get around to the other stuff I keep bugging you about (support for different maps on .S3O units, etc.) that we can immediately use this for Army-Painter style stuff, as in DoW, where a Unit could be assigned multiple user-configurable colors as part of their skin...

[trepan]

You can already define your own model format and texture
usage with 0.75b2. I haven't released an example gadget yet.
(you can apply per-unit textures, shaders, GL states, etc...)

[Argh]

Ok well in that case, I shall await the gadget and go from there. I am wanting bumpmaps and alpha-trans + alpha-glow rather badly, to achieve certain visual effects... ooh, and I know you did something involving tranforms u,v, didn't you? We could use that for tank tracks, and save people a lot of time and scripting hassle...

[trepan]

Oh, and LODs, units can already be setup for LOD'ing

[Argh]

Yes, now I just need magic LOD-making tools, instead of sheer willpower Really, the issue there, given that I'm modeling low-poly anyhow, is more one of texture sizes, and doing a swap there to lower total texture memory use and other things.

The bigger thing for the future is mipmapped normalmaps, if I can ever get to the point where I can use any of the tools available for that job. Earth: 2150, while not the best video game ever made, convinced me that normalmaps have a lot to offer even RTS scales and requirements...

[trepan]

Normal mapping (plain, parallax, relief, etc...), can all be done with 0.75b2
(for clients that support GL 2.0). The trick will be to figure out what file format
to use, and how to get the data from your modeller. I could set something up
so that tangents and binormal are generated automatically.

P.S. Even displacement mapping could be used

P.P.S. Blender has a decimation tool that might be able to help make LODs.

P.P.P.S. It's probably more important to first convert 3DOs to S3Os internally
to reduce the amount of code overlap in the engine (with a new culling mode
flag, etc...) It'd be interesting to see the speed difference because of the
ways that they use textures (atlased vs. non-atlased).

[Argh]

P.P.P.S. It's probably more important to first convert 3DOs to S3Os internally
to reduce the amount of code overlap in the engine (with a new culling mode
flag, etc...) It'd be interesting to see the speed difference because of the
ways that they use textures (atlased vs. non-atlased).

That is one of the things I have been waiting for, for like, ever. Nobody's wanted to wade into that mess, though- 3DO code is scattered throughout Spring still. I have this sneaking suspicion that if this were done, it would actually speed stuff up quite a bit, for all mods, simply because a large number of logic-tree jumps would get optimized during the process of getting this to work properly.

As for the rest... yes, I'm pecking away at Blender, now that I've gotten a version that works (yay, they use SVN, yay, the new beta works) and basically, "all" I really need is a Gadget that will allow me to start messing about with this stuff, frankly. I know it's asking quite a lot, but I really do think that the benefits, in terms of look-and-feel, if we can start using multitexturing approaches to objects, and have more options about how things are rendered, will be worthwhile.