hardcoded start"scripts", ScriptName tag, Script SMD tag

[Tobi]

I'm wondering if anyone is still using those for anything special.

I'm referring to the start scripts you can choose when you start the spring executable directly, i.e. air script, spawn script, test script, commanders script, skirmish AI test scripts, load scripts.

This includes usage of the "ScriptName" engine/mod option and the "Script" map SMD tag (which overrides the ScriptName mod option).

So do you use any code that relies on anything related to these tags, or these scripts in particular, or do you regularly use a script other then "Commanders" from the start menu?

If so, then please post in this thread which script you use and how you use it.

[Beherith]

I use empty test script to test mods without commanders or flash.

[hoijui]

Skirmish AI test scripts.
starting spring directly -> pressing enter when GUI appears.
every 5th-20th time i switch the AI to test in the GUI.

[SpliFF]

BD said something about deprecating empty script. Please don't. It saves setting up sidedata when creating experimental or non-TA type mods. Commanders is fine for existing stuff but empty should be default when sidedata.lua is missing. Also, I know the lobbys and presumably unitsync want sidedata but please make it optional and provide some kind of sane defaults like "Default" for faction name. Currently Spring throws a content error and exits which is not a really good default behaviour.

I'm considering writing mods which implement tools (like a unit / model editor) so anything that implies a type of gameplay should not a hardcoded requirement. This last bit pretty much applies to the Commanders script in particular.

EDIT: Correction, empty should also be the default when sidedata specifies no start units. It should be valid to have a sidedata.lua that's empty or incomplete in case you only want to use a subset of its supported values.

[Auswaschbar]

Iirc some non-ta mods rely on empty script (and break on commander script).

[SpliFF]

BTW. Don't know what your plan is for this but hardcoding scripts into the engine is poor form imho. Could we just have a startscripts.lua or startscripts/ and look for scripts there? Maybe that's what you have in mind, your post doesn't say.

[Auswaschbar]

BTW. Don't know what your plan is for this but hardcoding scripts into the engine is poor form imho. Could we just have a startscripts.lua or startscripts/ and look for scripts there? Maybe that's what you have in mind, your post doesn't say.

You got it wrong.

[FLOZi]

Commanders, Empty and AI Test are all that are needed. A new lua-based script system would be nice in the longterm (Though not that much was ever done with the old lua start script system), but in the short you can strip out the dead wood.

[Auswaschbar]

Commanders, Empty and AI Test are all that are needed. A new lua-based script system would be nice in the longterm, but in the short you can strip out the dead wood.

Lua based scripts were removed because they were made obsolete by luarules, and I don't think they will ever come back.

[Tobi]

Exactly.

My plan (half implemented already, it was easy), is to get rid of the hardcoded scripts as they are now altogether, reimplement them at a much smaller scope (only affecting the pre-game menu, so this will remain functional), and replace empty script / commander script by a gadget. (Whichever the game wants; if it wants both, it's easy enough to add a mod option.)

This effectively also makes sidedata meaningless for the engine: it would just pass it through to the Spring.GetSideData function and to the lobbies, and it wouldn't use it by itself at all.

This change saves A LOT of confusing old engine code that really shouldn't be there anymore. (In particular extra code paths that have been responsible for many bugs in the past...)
(my current patch adds like 150 lines and removes 1200 or so)

For games, the advantage of getting rid of hardcoded spawning a single unit is that they can get rid of hacks to remove the engine spawned unit just to replace it with another unit, or even the same unit in a different orientation.

The only issue that I'm not sure how to solve yet, is how to preserve backward compatibility. Is it desired that I make the gadget opt-out, i.e. some engine (springcontent.sdz) gadget sitting in your game unless you override it with an empty file, or would it be fine if this gadget is just provided as example (like all engine provided gadgets are now), and you have to manually copy/include it for it to become effective.

Personally I prefer to do the gadget as an example, but this would of course be a quite major breaking change. (No start unit would be spawned anymore in all current game builds.)

Any opinions on this?

[Pxtl]

Personally, I'm thinking more and more we need a single file for centralizing all those "should I use legacy behavior" questions - maybe a key in ModInfo. A simple, single location to say "this mod is being made from scratch, so all those files I need to override to empty should be overridden as such".

After all, fundamentally the problem is
1) A new mod needs a tonne of stuff just to disable undesired legacy behavior
2) An old mod will be broken by forcing them to insert new files for newly-generalized features.

Ultimately this problem will come up over and over and over again. So perhaps the best approach is to realize that these cases will _always_ exist and allow the modder to simply define whether they're expecting case 1 or 2 in a single, convenient spot. Thus, making an "empty" mod becomes a 1-line operation instead of overriding a bunch of stuff, but backwards-compat is preserved.

[Tobi]

Yeah, I've been thinking about that too.

The problem with how you suggest it, is that then, it is still impossible to make new API changes, which might even break the mods that have the key "this mod is being made from scratch, so all those files I need to override to empty should be overridden as such".

Maybe there should be a single configuration file that defines the "expected engine version", then the engine can read that, and try to behave as that engine version. (Maybe emitting a big fat warning that it's in compatibility mode, to encourage modders to bump the version. (although I realize it would probably be ignored...))

Support for really old engine versions can then optionally be removed after some while, if it appears there aren't really any games in use anymore which require that engine version (or if the effort to maintain this compatibility become too big, compared to just fixing the few games that still need it.)

That way it would become quite easy to implement breaking API changes, and a modder could decide by himself when he adopts such breaking API changes.

[zwzsg]

I'm wondering if anyone is still using those for anything special.

I'm referring to the start scripts you can choose when you start the spring executable directly, i.e. air script, spawn script, test script, commanders script, skirmish AI test scripts, load scripts.

So do you use any code that relies on anything related to these tags, or these scripts in particular, or do you regularly use a script other then "Commanders" from the start menu?

If so, then please post in this thread which script you use and how you use it.

I could do without those script. But sometimes it's nice to be able to run Spring.exe and test any mod without the hassle of going through a multiplayer lobby or writing a startscript. I mostly use Empty script because other scripts used to have a tendency to break on non-TA mods.

This includes usage of the "ScriptName" engine/mod option and the "Script" map SMD tag (which overrides the ScriptName mod option).

BTW. Don't know what your plan is for this but hardcoding scripts into the engine is poor form imho. Could we just have a startscripts.lua or startscripts/ and look for scripts there? Maybe that's what you have in mind, your post doesn't say.

The /startscripts/*.lua got removed shorlty before I decided to have a look at them, so I use other means now, and I don't even know what those /startscripts/*.lua could actually do.

[Argh]

I would love to see a generic start-script that was mod-definable, if it actually operated before GameStart(). It'd be really nice to do anything that required lengthy operations there.

[Auswaschbar]

I would love to see a generic start-script that was mod-definable, if it actually operated before GameStart(). It'd be really nice to do anything that required lengthy operations there.

Whats wrong with GamePreload?

[Argh]

Well, last time I tested, it behaved like GameStart(). I guess I need to test that

[Tobi]

Committed.

http://github.com/spring/spring/commit/ ... 7fb2c543ef
http://github.com/spring/spring/commit/ ... d5e7c995e5

Example gadget, modify as desired (different way to determine start resources/storage, spawn multiple units, calculate optimal build facing for the start unit, etc.) and include in your game:

http://github.com/spring/spring/blob/ma ... _spawn.lua

I'll put announcement in game & mod development soon.

[SeanHeron]

Great job ! Nice to see more unneeded functionality being removed/ made optional or more flexible (as you say - games haveing to remove the start unit and such).


Interesting thoughts also on the breaking compatibility vs. keeping things clean/orderly (or making them more sensible). I had a discussion with Flozi on just that issue with regard to this neat bit of code he came up with: Auto-resources.lua.

I think the solution you layed out, Tobi, would be best, but in the vein of keeping the effort for this minimal (ie increasing the likelyhood of it happening ), I'd suggest going for some variation of Pxtl's solution:

Perhaps if you define the two more in lines of
- "use legacy behavior (ie one set version eg. 0.81, and not changing)"
- "this mod will be continuously maintained, and does not expect to work after API changes, so all those files I need to override to empty should be overridden as such".

Well, not ideal, I can see that, but still, a good bit less effort I might have thought.

[zwzsg]

It doesn't work like that! Every mods that went unmaintained was maintained up to its update! And when they went unmaintained, there was no more new release to mark them as unmaintained!

Also, SeaHeron & Pxtl proposal is too much all or nothing. Some mods will want to keep certain bits of retro-compatibility and not others.

I prefer the idea of gadgets reimplementating default behavior being loaded by default, and ovveridable. Maybe make one over arching gadgets containing them all or something it feel it dirty to requires modse to override a bunch of file to start clean. Though I dunno, I could make sense that new mod has to have a custom game_spawn.lua to specificy their own what to spawn, or default to old behavior (that is, default to the game_spawn.lua of base archive).

[SeanHeron]

I prefer the idea of gadgets reimplementating default behavior being loaded by default, and ovveridable. Maybe make one over arching gadgets containing them all or something it feel it dirty to requires modse to override a bunch of file to start clean. Though I dunno, I could make sense that new mod has to have a custom game_spawn.lua to specificy their own what to spawn, or default to old behavior (that is, default to the game_spawn.lua of base archive).

If I understand you correctly, then I think we actually mean much the same thing...

Sorry - I perhaps hadn't made myself clear.
What I meant to say (and the way I had understood Pxtl), we would have the following basic setup:
Each time a part of standard game behaviour (API) is changed / removed, then a replacement would be implemented for this, and that would be included in /base/springcontent.sdz. Ie the default would be that behaviour is kept the way it was, no breaking of backwards compability (in this regard anyway). [just like you were suggesting, I think]. If you want to override individual parts, just put in empty/adapted files, like you described.

My/Pxtl's request was just that, for people that would like to use the most recent implementation
--> rather than have to include a bunch of empty files overriding the default ones - just have a "switch", one file that is added saying "backwards compatibility = off"
Ie people sticking to the current system don't have to do anything, just if you want a clean way to use the latest API, there's a simple way for you to do that.

Addressing the statement you made on all games having been maintained (till they weren't):
-->And label it clearly enough that people that use the "switch" are aware it will mean that their Game breaks (in smaller or larger things) as soon as the API changes.
I would have thought we can give Game makers the responsibility to make that choice (I wouldn't see why anyone should complain if the Game breaks later on - it was, and I see it as, the dev's choice).