Deprecate TD start scripts?

[AF]

I think its time we all moved from script.txt to script.lua, IIRC this feature was added in 0.77 (0.76 even?).

[Auswaschbar]

Yay. Why use simple things if we can make them complex!

[AF]

lua scripts shouldn't be anymore complex than TDF unless you start putting in extra calls and settings parameter values to equations and stuff. Most of the TDF files in the engine now support lua alternatives as it is

[Tobi]

Why would we need to deprecate TDF startscripts? Does it have any advantage?

As long as all lobbies write startscripts with same meaning it doesn't matter whether they are written in LUA or TDF, and we have LUA TDF parser anyway so it would be trivial to distinguish based on extension (or even on content, as happens for .smd files in map...)

I don't see much point in forcing lobbies to write in LUA when they have correct writing code in TDF now.

Also realize that this means lobbies would need to execute startscript in demo to get the data from it. This also means it would be trivial to make malicious demo that puts lobby in infinite loop when it's scanning demo folder. Of course this could be solved by just dumping the raw data in binary format in the demo file, instead of the script from which the data was generated.

[Pxtl]

My only complaint is the use of .txt to describe a tdf file. If the engine consistently used .tdf and .lua, in the case where a serialized object is expected the engine could just look for the filename (sans extension) and use the naked Lua execution for .lua or the tdf parser for TDF, but then handle the resulting the object the same way. .txt is ambiguous.

[AF]

Arguably this can already be done with UI widgets

[Tobi]

My only complaint is the use of .txt to describe a tdf file. If the engine consistently used .tdf and .lua, in the case where a serialized object is expected the engine could just look for the filename (sans extension) and use the naked Lua execution for .lua or the tdf parser for TDF, but then handle the resulting the object the same way. .txt is ambiguous.

This applies to .smd too, trepan already wrote simple check (in LUA) to see if file contains TDF or LUA contents.

And otherwise, .lua isn't taken yet for startscript, we can only not use .sdf because that's used for demo files

Arguably this can already be done with UI widgets

?

[Auswaschbar]

My only complaint is the use of .txt to describe a tdf file. If the engine consistently used .tdf and .lua, in the case where a serialized object is expected the engine could just look for the filename (sans extension) and use the naked Lua execution for .lua or the tdf parser for TDF, but then handle the resulting the object the same way. .txt is ambiguous.

The setupscript can have every name you like it to have, only restriction is not to use "*.sdf" or "*.ssf".

[imbaczek]

they say that if it's not broken, don't fix it.

[Tobi]

IOW, if it works and is used, don't deprecate it

[AF]

My point was that lua should become the 'preferred' method and we should nudge in that direction

[Tobi]

Yes, but why?

TDF isn't going to be removed from the engine anytime soon anyway, so it isn't that it would save code. TDF is still needed for about 10 G legacy maps, and various mods too, and if it's up to me there's no reason to deprecate TDF at all.

[trepan]

TdfParser is only required for script.txt, and SM3 maps, iirc.

edit: I forgot, the old lua startscripts use it too.
(this all relating to the engine, and not AIs, etc...)

[Tobi]

Was talking about the format not the parser

[FLOZi]

Deprecating the (engine) parser is a good idea though.


edit: And the old lua startscripts

[trepan]

"removed from the engine" -- TdfParser is the engine's interface to TDF

[Tobi]

Yes but it could use the one from springcontent.sdz too, requires some LUA-fication here and there, maybe mapping springocntent.sdz earlier in the VFS, and voila, then engine has LuaParser interface to TDF startscript.

And indeed +1 on removing TdfParser and boost::spirit dependency.