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

[Tobi]

The problem with that is that the particular place where this should be implemented (gadgethandler or maybe main.lua/draw.lua) is often (always, as far as I have seen) overridden by games too.

So as engine developers we have no control over what kind of gadgetHandler is running, and as such have to be very careful of enabling gadgets by default, that expect certain interactions with the gadgetHandler.

We can just provide an example, and the modder will have to judge whether the example needs to be modified to work with the rest of his code.

[zwzsg]

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

Because the modder will use it while it means the removing of backward compatibility as of now, while still relying on what is today still hard coded. Then the modder goes missing without notice. Then new advancements are made to the engine, removing more hard coded TAism. And the mod breaks.

But then new Spring releases break unmaintained mods in plenty other ways, so maybe it's not worth bothering with that one specifically.

[Tobi]

My current opinion is that eternal backward compatibility with each and every mod and map ever made, which is using each and every bug and undocumented feature in the engine no one really knows about, isn't worth the effort.

IMO, if a game is really worth something, there will be someone who fixes it. (And otherwise you can still play it in singleplayer using old Spring version.)

Note this isn't a warrant to allow breaking everything at will, but I think it's fine to modify things in ways that break backward compatibility as long as it's communicated well enough, examples are available of how to keep things as they are, and enough time is provided for the modder to adapt.

(Unless the modder decided to pick the wrong license and then go MIA but that's his problem. Happens with commercial stuff all the time.)

[zwzsg]

Yeah, thanks for telling us beforehand, and providing an easy fix.

Unless the modder decided to pick the wrong license and then go MIA but that's his problem. Happens with commercial stuff all the time.

Who's up for some Fanger hunting? He needs to caught before the weekend.

[BrainDamage]

Who's up for some Fanger hunting? He needs to caught before the weekend.

current RC doesn't contain this change, neither modinfo change

[SinbadEV]

I don't know if this is what we should do but it is one way to get around a lot of the complaints I'm hearing:


Have an "engine version compatibility" mode setting so:

Somewhere in my mod-definition I specify "Compatibility=0.81.1.2"... and EVERYONE starts doing this as of now... also make it easy for mods older then now that don't have compatibility mode set will be treated as default, namely 0.81.1.2... then, when the engine is changed in a way similar to what has been discussed here, such that something is disabled by default but a gadget is made to restore this functionality, this information will be available to the engine when it polls the gadget.

Also, if mods made after now want that particular feature they don't have to set compatibility mode to the point where the feature worked, they just make their own version of that gadget based on the one that's maintaining the old behavior.

This whole "compatibility mode" thing should be handled by a gadget too, so it doesn't mess with the engine.

[SeanHeron]

Because the modder will use it while it means the removing of backward compatibility as of now, [...] And the mod breaks.

@zwzsg: I guess I take a different view from you on how widespread this would be used. And to whether game makers should be allowed "laziness" fully realising it will mean their game dieing sooner after it goes unmaintained.

The problem with that is that the particular place where this should be implemented (gadgethandler or maybe main.lua/draw.lua) [...]

@Tobi - I don't think I quite caught what you were referring to:
- To how Pxtl/my suggestion would be implemented (and difficulties with that) ?

- Or to how the current behaviour is kept going via "default" lua gadgets (ie what I had assumed was being done now/ I thought you yourself had suggested for the spawner-system...). ?

I can't say much if you're talking to the second issue (as I'm not at all in the clear on what people change in the system.lua and such).

On the first, I can just say how I thought it would be done (and believe I could implement): For every "substitution.lua" (included in base as default), have something along the lines of

Code: Select all

if globalvar-backwardscompatibilitly == false then

don't do anything, else run as intended. And the "switch" would be, as said one file with the line "backwardscompatibilitly = false". Perhaps I've looked at this too simply, and there's something I'm missing, but I would have thought that'd be pretty robust.

Edit:

Have an "engine version compatibility" mode setting so:

Actually that's just what Tobi suggested earlier in this thread . I'd be fine with that, my worry is mostly that I don't reckon anyone would implement it (while I'd be happy to write up the changes needed for Pxtl's suggestion).

2nd Edit: Link to Tobi's post I referred to.

[zwzsg]

SinbadEV: So that the engine has to keep all the old junk code so as to be able to reproduce the quirks of every Spring version ever? I don't think that'll work.

[SinbadEV]

On the first, I can just say how I thought it would be done (and believe I could implement): For every "substitution.lua" (included in base as default), have something along the lines of

Code: Select all

if globalvar-backwardscompatibilitly == false then

don't do anything, else run as intended. And the "switch" would be, as said one file with the line "backwardscompatibilitly = false". Perhaps I've looked at this too simply, and there's something I'm missing, but I would have thought that'd be pretty robust.

as zwzsg mentioned, the problem with the "backwardscompatibilitly = false" solution is "backwards compatibility to what?"... hence my suggestion.

The other option would be to have a list of variables like "spawndefaultunits" and "spawndefaultresources" for each element outmoded behavior that would default to true and would need to be set to false in the modinfo.lua if the modder wanted to use the new behaviour... sure thats a lot of "blah=false" in nearly every new mod but that's not so bad really... game makers could still disable the bahavior in the modinfo.lua and recreate this behavior in their own version of the lua-scripts that restore it.

[zwzsg]

modinfo.tdf won't be supported next next Spring (next next, not just next), and there won't be backward compatibility: http://springrts.com/phpbb/viewtopic.php?f=14&t=21811 There's only CA and svn's 44 that don't rely on modinfo.tdf, so every mod will have to update or be broken.

So, let's just break everything at once, and not bother with retro compatibility of resource, game spawn, or whatever, because anyway mods will be have to update or die.

[SinbadEV]

SinbadEV: So that the engine has to keep all the old junk code so as to be able to reproduce the quirks of every Spring version ever? I don't think that'll work.

No, I was mostly responding to the other thing where it was indicated the old behavior could be duplicated by Lua... this one in particular is a little weirder of a case... I was kinda assuming that it could also be restored using Lua when I made my suggestion.

So you would have
engine code is modified to run some special Lua file prior to anything else,
this Lua, build dev-side, has a list of compatibility variables and associated gadgets to enable... basically a list of:

if enableOldEmptyScriptBehavior then
gadgetbla1.enabled = true
end if

if enableOldCommanders1000ScriptBehavior then
gadgetbla2.enabled = true
end if


these gadgets would have to start a frame before anything else so they could do things like providing the old system menus etc.


then if you had my original suggestion before ALL of this you would have everything default to false and then:

if Compatibility >= "0.81.1.2" then
enableOldEmptyScriptBehavior = true
enableOldCommanders1000ScriptBehavior = true
spawndefaultresources = true
spawndefultunits = true
end if
if Compatibility >= "1.0.0.0" then
enableBOSandCOB = true
enable3DOrendering = true
end if


then the mod maker could still overide these settings by setting a compatibility mode and then re-disabling the undesired old behavior or setting compatibility mode to the current version and enabling the old behavior or manually recreating the old desired behavior with their own custom lua.

[SinbadEV]

modinfo.tdf won't be supported next next Spring (next next, not just next), and there won't be backward compatibility: http://springrts.com/phpbb/viewtopic.php?f=14&t=21811 There's only CA and svn's 44 that don't rely on modinfo.tdf, so every mod will have to update or be broken.

So, let's just break everything at once, and not bother with retro compatibility of resource, game spawn, or whatever, because anyway mods will be have to update or die.

To be honest I'm just playing devils advocate for the most part, while I like the idea of backwards compatibility because it doesn't piss other people off, my personal preference would be just to break things to make them better, at least until we get to a 1.0

[FLOZi]

So, let's just break everything at once, and not bother with retro compatibility of resource, game spawn, or whatever, because anyway mods will be have to update or die.

Absolutely. We have an opportunity here to review certain aspects of how Spring games/mods work, and implement (backward compatibility breaking) changes in one go as to limit the damage.

[Forboding Angel]

Why isn't tdf being kept around? Tdf is very useful, especially to people who don't understand lua nor need the power that lua provides.

Yes, I use lua for this stuff, but I still use tdf is certain spots because it's easier to format and I don't have the foggiest idea why I need to use lua for that (resources is a perfect example - even though this is obsolete due to a certain gadget made recently).

[zwzsg]

The modinfo is a special case, because it needs to be read before the mod is loaded.

The other TDF are kept. (Even if internaly, a TDF->Lua parser is applied on them, it's transparent to the modder.)