Spring RTS Engine

Engine devs agreed that there aren't 'unsafe' changes and if there are than they are engine bugs.
So I would like to remove that function in the next Spring RC.
Opinion by modders welcome, if this is too short dated and you already fixed your mods with current git.

Bin it.

This RC would be preferable as mods are already forced to update for it (modinfo.tdf and startUnit changes).

I agree. Errors from unsafe changes are engine bugs so there is no point calling them unsafe changes.

jK wrote:Engine devs agreed that there aren't 'unsafe' changes and if there are than they are engine bugs.
So I would like to remove that function in the next Spring RC.
Opinion by modders welcome, if this is too short dated and you already fixed your mods with current git.

This is not clear, do you mean that AllowUnsafeChanges("USE AT YOUR OWN PERIL") will always be on or do you mean that you want to remove the ability to give orders outside of gameframe and so on?

He means it will always be on. No loss of functionality, just dispensing with the chore of flipping the switch.

`Unsafe` changes will be always allowed and the AllowUnsafeChanges() function will get removed (any tries to call it will give an error).

What's the word on this?

Done here.

So it isn't the current test-build, but will be in the RC.

since this is a quite important change, mod-breaking even, may I suggest creating another sticky in the mod section like for the other compatibility-breaking changes?

also, given the short notice ( other changes had 6 months+ warning, and were delayed by 1 major release too ) I think it would be better than instead of removing the function completely, to add an empty stub in the engine that prints a deprecation warning, and remove the stub in the next major release.

Then again, if it's at the same time as removing modinfo.tdf support..

the 2 proposals are distinct, while you can bring the "break all at once" argument for the second point, there's no reason not to advertise the change properly like the others were

-->Great success.

Indeed it should be advertised though.

BrainDamage wrote:also, given the short notice ( other changes had 6 months+ warning, and were delayed by 1 major release too ) I think it would be better than instead of removing the function completely, to add an empty stub in the engine that prints a deprecation warning, and remove the stub in the next major release.

I agree with that, deprecation warnings given out by the engine are probably the best way to communicate with the developer. No need to break things more than necessary.

announcementified

Is this announcement still relevant? It's been almost a year since the change.

Apparently, yes:

azert123 wrote:

Code: Select all

[f=0000000] Loading LuaRules
[f=0000000] Lua LoadCode pcall error = 2, LuaRules/main.lua, [string "LuaRules/main.lua"]:1: attempt to call global 'AllowUnsafeChanges' (a nil value)

zwzsg wrote:Apparently, yes:

azert123 wrote:

Code: Select all

[f=0000000] Loading LuaRules
[f=0000000] Lua LoadCode pcall error = 2, LuaRules/main.lua, [string "LuaRules/main.lua"]:1: attempt to call global 'AllowUnsafeChanges' (a nil value)

That's an outdated game without a maintainer/developer.

imo archive it to http://springrts.com/phpbb/viewforum.php?f=67

moving to archive.
I think the place where most people got in contact with AllowUnsafeChanges was the old game_spawn.lua but now it has been updated since a while:
https://github.com/spring/spring/blob/m ... _spawn.lua

this was five years ago.
if still want to document then do it on https://springrts.com/wiki/EngineChange ... ontentDevs or add AllowUnsafeChanges() to Lua wiki and mark it as deprecated.