Spring RTS Engine

I am politely asking will Lua widgets break with future engine updates because I would like to know the answer to this question.

Thank you -BA developer

Yes, some of them will.

Wait until he finds out that sometimes that breakage is because of features being added to existing calls. *internal conflict intensifies*

To be honest, the version 105 whose changelog only says:
-- 105.0 --------------------------------------------------------
- special maintenance release: contains only bugfixes
introduced some entirely unnecessary breaking changes of Lua, such as the switching of the 7th and 8th argument of Spring.GetTeamInfo

Also the entirety of LuaUI was disabled until I stole a LuaUI\main.lua from another mod, but the role of that file is still rather mysterious to me.

So I understand Ares frustration.


And to answer the topic title: all the lines starting by ! in the changelog are breaking changes.

So yes, there will be 38 breaking changes so far in Spring 106. But at least we know what they'll be and can prepare.

To be fair you can't expect that no API changes happen between versions. It has always been and always will be the case.

zwzsg wrote: ↑20 Jun 2021, 15:06 LuaUI\main.lua from another mod, but the role of that file is still rather mysterious to me.

main.lua is entrypoint to a respective Lua system. Usually it's not big, do a diff with your old version and see what's going on.

zwzsg wrote: ↑20 Jun 2021, 15:06 And to answer the topic title: all the lines starting by ! in the changelog are breaking changes.
So yes, there will be 38 breaking changes so far in Spring 106. But at least we know what they'll be and can prepare.

What you read is a changelog in `develop` branch. My personal opinion is that this branch will never be used as actual engine and my intent is to release 106 99% API/file compatible to 105 (with various improvements nonetheless).

In theory, a mitigation layer could be created - in lua.
Allowing old games to pretend they are running on a old version of spring.
But in practicality most of those things broke are not used/developed on anymore anyway.
Demanding from others to include countless special cases for software noone is willing to maintain, is quite the demand.

Death is the great cleaner of all things, life and software alike.
If its important and loved, somebody will maintain and update it.

If not, into the void it goes - as we all do.
In.
The end.

In theory, a mitigation layer could be created - in lua.
Allowing old games to pretend they are running on a old version of spring.

Quite a bit of this exists already, when you delve into base content. But imo its important to be careful about what is and isn't cushioned like that, or it would get unmanageable to maintain.

IIRC so far we had zero changes to Lua callins and Lua callous only got extra optional parameters. Most API changes were the introduction of GL4 functions that hadnt existed before.

PicassoCT wrote: ↑22 Jun 2021, 10:18In theory, a mitigation layer could be created - in lua.

That's usually what I do, in the hope that newer KP can also be run under older engines. Though, since I don't really test that, not sure how well that works.

PicassoCT wrote: ↑22 Jun 2021, 10:18But in practicality most of those things broke are not used/developed on anymore anyway.

I'm very sad that nearly old games/mods cannot be played anymore.

PicassoCT wrote: ↑22 Jun 2021, 10:18Demanding from others to include countless special cases for software noone is willing to maintain, is quite the demand.

On the other side, I find it quite the demand that every mod must be individually maintained forever.

PicassoCT wrote: ↑22 Jun 2021, 10:18Death is the great cleaner of all things, life and software alike.
If its important and loved, somebody will maintain and update it.

Engine and mods are symbiont, you can't repeatly kill one and expect a thriving ecosystem.

PicassoCT wrote: ↑22 Jun 2021, 10:18If not, into the void it goes - as we all do.
In.
The end.

I'm not saying Spring games should be immortal, but that's still no reason to hasten their walk to the tomb.