Spring RTS Engine

As this seems to be a concern for one modder other then myself... and I am not asking anyone to drop anything important to work on this. However, I figured I should post the idea...

Perhaps within the mod/game there could be a configuration file saying whether or not the users can select a color(custom team color) or the color will be locked and the list populated with some mod/game specific colors.

I understand that this could be over-ridden by a mutator.

By no means am I requesting this for my project and have NO problems with the current system.

I am requesting it for people who may want it for their projects. This is just a thread to get the old idea ball rolling so people could probably suggest a system that would better suit them.

WTB a dawnofwar style team color scheme

Not talking about that. I am talking about setting it so that in the lobby the mod might be able to specify a color set for usage.

doesn't seem like a bad idea... I would like to see mod designers able to choose the default available colors at least... locking the choices doesn't seem too awesome. This in conjunction with some clever LUA would allow custom paint jobs based on color choice as well which would be awesome.

This would be helpful in IW, such as removing the white player colour, because they clash with our 'neutral flags', and black, because you can't read the radar icons at all.

But my comment in the other thread was more retroactive, in that I think that giving players the choice for a wide range of colour options was a bad choice from the start. I've made this clear in threads before - however, what's done is done, and I bet that if I made 20 limited colours to pick from in IW, I would inevitably be hit with a barrage of complaints from people who want their off-beige standard colour.

While I do not agree with the idea of allowing a mod/game to limit what colors a player can use, warlord Z has a very valid point. For his project, starwars this might be useful. If they want their off beige in starwars they can make a mutator and it would be super tiny.

I would not use this option but I think he has a point and some of the future mods/games MAY want to be a bit more restrictive on player colors.

Im not sure this makes that much sense in a lobby that has 12 different ways of picking a colour.

Well before you change this entire color stuff it might be a good idea to just integrate a color filter option into the lobby clients. I mean there already things like auto-fixing colors so why not giving the option to exclude certain colors and just run this option before you start the game just like you'll probably do for balance...

Might be less work than digging in the source code for colors...

It would be even more work to filter colours than it would be to list predefined colours. The difference in effort is several orders of magnitude.

And remember, not all of us wrote our colour selectors from scratch and rely on pre-written APIs from our respective languages.

I wont implement this anyway. I dont want to remove features, and if all the other lobbies implement this then mine will have a fancy new feature to add, as it'll be the only lobby left to allow full freedom of colour. So there's a strategic advantage to not implementing this.

Spring.SetTeamColor?

Lua gadget based enforcement:

user: "Hey whyd you change my colour?"
host: "wha?! you changed it"
user: "nope I definately had a different colour before we started"
host: "are you sure?"
user: "yeah all my units look different"
host: "wtf your colours different in the lobby"
user: "huh? stupid springs borked"
host: "restart"

AF wrote:It would be even more work to filter colours than it would be to list predefined colours. The difference in effort is several orders of magnitude.

Why is that? I mean why is changing stuff in the source code of Spring about the colors in order to prevent certain colors and then adapt the lobbies to include that feature more work than a weighted mode of what's already included (at least I think about every lobby has that now) with the fix-colors option...

You just should be able to give an additional input saying "I don't want this and that color" and then when auto-assigning colors colors of that type plus colors in that range (doing a weighting in a specific range of RGB colors with 3 values shouldn't be so hard and might even be present in the recent fix-colors function (I'm not sure if custom colors already are weighted or not when comparing the colors present)) are changed to something else...

AF wrote:Lua gadget based enforcement:

user: "Hey whyd you change my colour?"
host: "wha?! you changed it"
user: "nope I definately had a different colour before we started"
host: "are you sure?"
user: "yeah all my units look different"
host: "wtf your colours different in the lobby"
user: "huh? stupid springs borked"
host: "restart"

Lua_UnsyncedCtrl

Unsynced widget based colour enforcement:

user1"attack the blue enemy"
user2"erm there is no blue enemy"
user1"yes there is, see on the left!"
user2"no there's only green on the left"
user1"but there are no green players"
user2"lets just attack red"
user1"dont you mean pink?"
user2"gah"

And krogothe I think you haven't realized that there are 3 lobbies not 1. I also think yet again you've misunderstood my reasoning. And ontop of that you've then applied it to tasclient not aflobby/battlehub.

Either way the whole concept of this is totally flawed and doesnt serve a purpose. We originally had the 16 colours as a holdover from OTA and when we moved to full rgb colours it was a feature not a drawback. We shouldn't be moving backwards in time.

Forcing it on the spring side will only cause confusion and annoyance for the player no matter how they implement it because there's no lobby side support.

(oh and peet, you could have said Lua_usyncbannana and still gotten the same reaction. Explain what you mean rather than pulling terms out of a hat nobody understands save for a small minority who write gadgets and widgets)

AF wrote:And krogothe I think you haven't realized that there are 3 lobbies not 1. I also think yet again you've misunderstood my reasoning. And ontop of that you've then applied it to tasclient not aflobby/battlehub.

Well I don't know about your lobby but the other two have a fix color function (as it's something regularly used) to build upon which was my suggestion...

Well maybe I didn't really understand you because I fail to see why the requested feature would be a setback as you call it. It's just about that you might want to not use a specific color in your game/mod because it might be just confusing (if you can't differ between a neutral white flag and flag owned by player white that imo is a severe issue). So instead of sorting this out for every and every game that's going to be hosted there was a request made to somehow get rid of this situation...

I don't really understand why you call all this a setback and praise the times when colors were changed to RGB mode. I think nobody here wants to change anything about that - it's just about a management for colors which will ruin your game (and which doesn't take anything away but just is sort of an additional filter option). So this isn't about a "decrease" of features but just automatize something that is going to be done anyway in those games and that is not letting someone use a specific color. That was the point where I asked myself if it would be a better idea to just add this option to the existing fix color options of the lobbies or to have changed code in the Spring source AND the lobbies or not...

I might be wrong about that but heck it just was a suggestion - I did not order anyone to do so...

Personally I can see the wisdom in limiting the color choices to mod definable.

@af, If you use lua drawn stuff directly on the map texture, on certain maps it shows up really badly.

There are two reasons for this you're not understanding, AF:

1) The gaia team is, by default, white. It would be possible to write code which would change the gaia team's color to some unused color each game, but then the game becomes inconsistent. "Ok, neutral flags are white this game, purple this game, green this game...". It'd be better to disallow white and near-white colors from player selections so there's no confusion and the game itself remains consistent.

2) This one is slightly less important but it would still be nice. For IW, we made our radar icons use not only shapes but symbols embedded in those shapes to give the player more information without necessarily being required to zoom in. See here:

Due to the way spring's icon format works, the white areas get filled with team color and the black areas don't (well technically i bet they do but they just can't show it). If a player chooses a color that is too dark, he's at a disadvantage because he has less information available than he would otherwise have. This would be fine for veteran players who know about it but new people who simply want to be black would be hurt even more.

Of course, this one could also be fixed by an engine patch which would invert the borders/symbols to white when the player color is dark. I'm sure we're not the only ones who use outlines at least, and on a darker map, dark colors can blend in regardless of the mod without an outline.

No one has any problem with freedom of selection; we only want to limit or fix a few key colors to make the game more consistent overall. I'd rather sacrifice black and white as selectable team colors.

I don't see anything wrong with limiting color choices if modmakers decide so.

Any thoughts on how such colorset would be stored/exposed to lobby?

(don't just say unitsync please )

Thus users of my lobby could gain a tactical advantage by setting themselves as white.

I too have a set of fixed colours, but just as I expect spring lobby ahs, this is not because I added them this is because an engineer in a big building with the Sun micro-systems logo added it. I have other things to think about then restricting colours for a mod.

I'm sure the bug in your game can be fixed by a fix in your game or a patch to the engine and not a kludge in the lobby.