What the ETA for the next release of the engine?

[Super Mario]

So that people know when to make the changes before the new engine goes up.

[smoth]

the release date for the next engine build

[hoijui]

All changes i can think of are backwards compatible (at least for games).
I hope you have already seen this thread.

Thus the logic is, do the changes now, release new version, let people know about this new version in the above mentioned thread.

[Licho]

Well thats not entirely true there are always minor breaking issues. Several ZK commits deal with them in preparation to release (something with categories, something with lua not detecting pylons correctly, game end).

Anyway heads up would be nice .. to upgrade springies etc.

[hoijui]

so.. you had to write extra code to make ZK work with both release and master/testing release?
maybe explain what you had to do in the other thread then, so others can profit.

The whole idea is, to make releasing so smooth a process, that nobody will feel much pressure at release time (release manager, engine devs, game devs, lobby-client and -server devs, autohost maintainers, users). over sooner or longer, game devs will probably have to make their games work with multiple versions anyway, when we have multi version support well established.
If it is well established one day, you may wait until after an engine release, till you start adapting. even though we would always need some up to date games for testing dev versions aswell, of course.

[FLOZi]

All changes i can think of are backwards compatible (at least for games).

It depends how strictly you interpret backwards compatibility (i.e. stuff that will work without any changes on our end, stuff that can be made to work under both versions using version checks etc):

https://github.com/spring/spring/commit ... 387bbb64d5

Unitdef tag change is, name of command available in lua isn't.

Spring.SetUnitLineage is removed entirely.

The arguments to Spring.SetUnitPieceCollisionVolumeData have changed.

The array .n change is backwards compatible in the way that we can fix it now and work in both versions, but it still requires us to know to fix it. A similar thing can be said for inclusion of the game ending gadget, etc.


N.B. None of this is meant as a complaint as I am in favour of all these changes (well the Spring.SUPCVD change is annoying but I know jk has valid reasons for it ).

[smoth]

Spring.SUPCVD

?

[Kloot]

name of command available in lua isn't.

Yes it is, because:

Code: Select all

LuaInsertDualMapPair(L, "DGUN", CMD_MANUALFIRE);

[FLOZi]

Ah sorry, didn't catch that.

@Smoth; SetUnitPieceColVolData

[smoth]

ah cool

how are you guys doing old <-> new compatibility for game ends?
Right now it is an engine option we are changing it to a mod option. Gundam does not use the engine option lua included with spring because it includes many ta-isms that don't apply to gundam.

Other projects are probably the same so how are you handling it?

[hoijui]

The array .n change is backwards compatible in the way that we can fix it now and work in both versions, but it still requires us to know to fix it. A similar thing can be said for inclusion of the game ending gadget, etc.

That is the definition of of a backwards compatible change, so it is not in a way.
but thanks for listing up some stuff again, can't hurt!

could you please explain roughly what to do for Spring.SetUnitPieceCollisionVolumeData in the other thread? i'd then link your post in the first post of that thread.

[FLOZi]

It is, 'in a way'. Kloots DGun engine changes are fully backwards compatible - nothing has to change game side to accommodate them. That's the distinction I was trying to make. As I see it there are three levels:

BC1. Engine change, no game change required
BC2. Engine change, game change required but works with current spring
BC3. Engine change, games change required that will not work with current version, you must use version checks if you want to run the game under both engine versions.

But if you count 3 as 'backwards compatible', then surely there are never (or perhaps merely extremely rarely) any non-backwards compatible changes


https://github.com/spring/spring/commit ... 3#comments

Arguments 3, 4, 6 are now ignored, so the code is backwards compatible (BC1) - but if you were relying on the effect of those arguments (they make the change apply to all future units with the same model) you will have to change the logic of your code (call for each individual unit as needed), so its BC3. AFAIK, though, this only affects S44. Don't know of any other mod using piece collision volumes (except BTL), but I may be wrong.

[smoth]

I figured we were largely bc2? a lot of shit has the .n stuff.

[FLOZi]

I was meaning that individual changes can be BC1, BC2, BC3 or even some combination thereof depending on the game. The .n change is BC2 for sure.

[zwzsg]

how are you guys doing old <-> new compatibility for game ends?
Right now it is an engine option we are changing it to a mod option. Gundam does not use the engine option lua included with spring because it includes many ta-isms that don't apply to gundam.

Other projects are probably the same so how are you handling it?

I have a game_over.lua gadget with:

Code: Select all

         if not Spring.GameOver then
            gadgetHandler:RemoveGadget()
            return
        else

Also, I have had for a long time a EngineOptions.lua with { key = 'gamemode',

[hoijui]

ahhh, i see where the confusion came from now, thanks for clarifying.

when we are talking about adapting games to work with master,
it makes no sense to even think of BC1. therefore, and as we are talking about adapting games to the engine here, i mean changes in games when i talk about changes. BC1 is irrelevant for the discussion, BC2 is a backwards compatible change (in games), and BC3 is a non (easily) backwards compatible change (in games).

[zwzsg]

All changes i can think of are backwards compatible (at least for games).

No, they are not.

However, games can be made forward compatible.