Spring RTS Engine

qray wrote:

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:

Code: Select all

[MAP]
{
}

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...

Yes, that blank smd was my way of tricking zk's plasmaserver (or whatever the server on the zk side of things is called) into actually recognizing maps. But lately, I decided that as long as the spring server recognizes them, fuck plasmaserver (or whatever the server on the zk side of things is called).

SWL still relies on it for minimap images, which is freaking irritating, so my maps in the lobby get a big ? on the preview, but frankly,. I am tired of dealing with the archaic, hacky crap you have to deal with just to make something work with ZK's infrastructure.

I just realized,

The engine already has the stuff to even standalone convert tdf to lua:
https://github.com/spring/spring/tree/d ... /maphelper

I would be curious to see detail of how much code is improved by removing smd.

All I have been able to find is the 200 line file there that relates to map parsing. The springlobby/lsl code doesn't contain the word "smd", although I didn't find the springfiles code to look there.

In the long run tdf deprecation is ofc sensible, although no clue how easy it would be for some older games. In that direction, script.txt looks like a far more worthy target than smd.

If https://springrts.com/mantis/view.php?id=4921 didn't exist, I'd have used http://imolarpg.dyndns.org/trac/balates ... params.lua to remove the last tdf from BA/BAR a long time ago. Ofc it would be possible to do it with the basecontent parser too - just somewhat more effort.