Spring RTS Engine

After my initial knee-jerk reaction to tdf deprecation/map recompilation, there are quite a few outstanding issues that I have realized. https://springrts.com/mantis/view.php?id=5189

1. Many popular maps have this old bug from an old version of mapconv which result in horizontal lines appearing on maps at specific zoom levels:
https://springrts.com/mantis/view.php?id=2313

2. Many old maps have a absolutely flat (and in my opinion, ugly) lighting. Most the the time this can be traced to a global misunderstanding of groundambient and grounddiffuse. Many maps have their groundAmbient set to unreasonably high levels (anything above 0.5, 0.5, 0.5 is too much, except for very specific use cases). groundAmbient is the absolute darkest a map can get, while the engine clamps ambient+diffuse to reasonable levels, this results in a very washed out look. The same can be said for unitAmbient and unitDiffuse.

3. Related to the above, the shadow densities compound the issue above, as they also clamp the amount of shading range from ambient(unlit) to ambient + diffuse (fully lit).

Points 2. 3. are imo a result of lighting parameters being very difficult and time consuming to adjust, as one needed to relaunch spring to test each change. The solution to this issue is coming along with scened very well. (I also plan to add a dev widget to BAR which allows mappers some freedom).

4. Engine trees look quite dated. Very reasonable replacements exist, to the point that i'm thinking of adding a gadget to BAR that replaces engine trees.

5. I'm dissatisfied with the default detail texture used by most maps (the engine's builtin one has too much noise, but it served a purpose in the age of mars and small divide).

Im not saying all TDF maps should be deprecated immediately, but now I see there are valid points in the argument.

ok, thanks for getting this more constructive.

1. can this be solved by recompile with a fixed version of mapconv without manual work?

2+3 sounds like its not possible to automaticly solve? only thing which could be done is to detect such an lightning?!

Im not saying all TDF maps should be deprecated immediately, but now I see there are valid points in the argument.

imo the poins is: we need a process to deprecate maps / replace it with newer ones. currently if a much better / fixed DSD would be created, the old version will be still used / spread arround as its not possible to "update" it as it works with games / show users easily that there is a newer version available as maps are often not correctly versioned.

1 is solved by recompile, but who cares enough to do it?

2 very true.

3 very true.

4 evo already does this since a long time now. BAR should as well.

5 actually, in all my testing, the engine one is a great equalizer and is uniquely suited to the task. It manages to work pretty well for just about everything, and ssmf kinda makes it a moot point because you can specify the default detailtex anyway.

TDF maps getting the boot would be a GOOD THING.

WHen you say tdf do you mean SMD?

Certainly there are pros - but (afaics?) the time to handle these issue manually per map is prohibitive, so the question is if its possible to automate unpack -> decompile -> rename & update mapinfo.lua -> fix various stuff -> recompile -> repack.

There could also be maps with non-derivative licenses.

Silentwings wrote:Certainly there are pros - but (afaics?) the time to handle these issue manually per map is prohibitive, so the question is if its possible to automate unpack -> decompile -> rename & update mapinfo.lua -> fix various stuff -> recompile -> repack.

yes, thats definitly possible to automate these steps, for me its just unclear what exactly needs to be done in the step "recompile".

Not meaning to be cruel, but if you're not familiar with (de/re-)compiling maps there is no way you can judge the possibility of automating this. https://springrts.com/wiki/Mapdev:Tutorial_Finalizing

While we're at it, hopefully we can agree to kill sm3 (and that really does remove a chunk of bloated code).

Narrow passage was the only serious map ever made using sm3. I think It's still on SF. Edit: Nope, got asploded at some point apparently.

Silentwings wrote:While we're at it, hopefully we can agree to kill sm3 (and that really does remove a chunk of bloated code).

sm3 was disabled in spring 95.0 the code for sm3 is only there "for the reference", but no clue if it still works as its not compiled.

1. Can be automated. It affects all maps before 2011 that have a non-uniform tiled texture.

2+3 cant be automatically solved, but clusters of misbehaving maps can be identified, and with ingame adjustment, I can probably tackle a few hundred of them.
I forgot to mention the old groundAmbiAnt color misspelling too :D

4. Forb, may I steal your related gadget, if you got a repo link to the sweet luas?

5. You may be right on that forb, its just a pet peeve of mine.

6. SM3: its dead, Jim.

Also, let me state for the record, that any maps that get hit by this that are actually popular will end up getting recompiled in pretty much no-time. The others... well, good riddance.

Forboding Angel wrote:Also, let me state for the record, that any maps that get hit by this that are actually popular will end up getting recompiled in pretty much no-time. The others... well, good riddance.

That what I was thinking. I would surely take on the maps I usually play and do the adjustments for them (probably even add ssmf stuff to polish them a bit). But there are also many maps where I wouldn't see the point to invest work.

But wouldn't it be sufficient for the others that nobody is willing to invest work in to do just the automatisable steps?
Converting smd to mapinfo and de/recompiling with newer mapconv could be done automatically, if I don't miss a point here. If the lightning is off, well, it has already been in the original version that people played before, so no loss here.

Silentwings wrote:There could also be maps with non-derivative licenses.

Most maps I looked at don't have a license information at all. So if you want to be 100% correct, one isn't allowed to do anything with them, if one follows the usual copyright laws*. The smd to mapinfo conversion should nevertheless be allowed in any case since scripts should be GPL?!

*depends of course on country etc.

qray wrote:Most maps I looked at don't have a license information at all. So if you want to be 100% correct, one isn't allowed to do anything with them, if one follows the usual copyright laws*. The smd to mapinfo conversion should nevertheless be allowed in any case since scripts should be GPL?!

when the maps contain no copyright info i would assume that they are public domain as they were uploaded to springfiles.

also the "automatic conversion" thing is meant for fixing errors / convert to a newer format, nothing else. the alternative would be to delete the affected maps.

True, that's why I wrote "if you want to be 100% correct". Maybe I should have phrased it "110%" but that hurts my math understanding

abma wrote:when the maps contain no copyright info i would assume that they are public domain as they were uploaded to springfiles.
...
the alternative would be to delete the affected maps

I agree that this assumption is most probably right, since all maps I saw so far have also the "Freeware / Free" license tag on spingfiles. And I don't think deleting maps is the right way to go.

I noticed the "horizontal lines appearing in maps" and that the light on many maps seems too bright. Are these tdf-only issues?

Was expecting to fix the light issue by overriding map cfg through lua, but currently I don't think it's possible.

Forboding Angel wrote:Also, let me state for the record, that any maps that get hit by this that are actually popular will end up getting recompiled in pretty much no-time. The others... well, good riddance.

Really?...This is dangerous.

What happens if someone tries to play on a tdf map after deprecation?

example : person that played spring games before, maybe years ago, and came back to check

- person starts some spring lobby, any spring lobby, possibly springlobby
- person clicks on a host, downloads latest engine and game version
- person tries to start a single player vs AI on that popular map he used to play (tdf)
- game won't start : crash or show "some error message" that "didn't happen before"
- person downloads a few "random" maps from spring files and places in the correct directory
- person retries playing, with same result
- person wonders if it should ask around on the chat about it, but instead quits and goes back to lol, starcraft 2, etc.

how likely is this?

Ideally the lobby would stop recognizing smd maps

Which I'm assuming only requires a somewhat simple change to the unitsync lib, and for nostalgia purposes an old engine/game could be used to still play them. I agree with Forb; the active community would update any maps it deems worthy, and anyone coming back will more than likely stick with what the active community is playing.

So, realistically, someone ssmf DSD and we're good.

I do not think TDF/SMD should be deprecated, but I do feel that recompilation/conversion is an option.

Forb:

I seem to recall an old outstanding unitsync or lobby issue where the description tag was required to be in an .smd file. Is there anything in smd that cant be put into mapinfo.lua?

Beherith wrote:I seem to recall an old outstanding unitsync or lobby issue where the description tag was required to be in an .smd file.

I remember some problems with maps related to the map server and them not being picked up by some systems or sth. like this. For this it was sufficient to include a basically empty smd file -named like the smf- containing only: But I don't know if this has been solved by now.

And reading your post again it seems like you mean a different issue...