The end of the maintenance branch

[gajop]

Providing the develop API in maintenance would be a good way to start, go right ahead please.

[Silentwings]

Split out "BA questions" because off-topic, viewtopic.php?f=44&t=41370

[raaar]

Moving on, my plan is to modify the Lua graphics API of the current "maintenance" such that it's API compatible with the other branch of the engine called "develop".

@ivand:
why not vice versa, why not add some backwards compat code to the develop branch? i don't have code insights: i just want to know, if you have a reason to add the opengl code to maintenance. adding more code to maintenance makes it to live longer i guess. without investigation/code insights i would suggest to:

- release current maintenance as 105.0
- drop maintenance branch
- add compat code to develop
- release develop as 106.0

still +1 from me in general for the plan and thanks a lot for your efforts!

I agree with this.

It's very important for most of us who are actually playing the games to at least have one stable release from the latest maintenance engine. Please don't just drop it.

[FLOZi]

The intention quite clearly is not to drop it but mark 1510 as 105.0. I have a few small bugs I would like to see fixed first, working on bisecting them.

Also https://springrts.com/mantis/view.php?id=6357 if anyone ever wants to see trains.

[sprunk]

My proposal is to end the development and support for the maintenance branch

I support ending development on the maintenance branch but I think bugfixes should still be backported for some time (where reasonable given mana - it may well be fine to skip everything that doesn't cherry-pick without conflicts). If the premise of maintenance stability is true (and I think it largely is, especially when new features don't get backported) then this should not be too large of a burden.

[ThinkSome]

I think that the time used up for backporting fixes would be better spent helping games migrate to the new graphics stack.

I also propose:
1) that regular meetings be held between engine devs and at least one representative of each game's development team.
2) that a wikipage be created and maintained by game devs, which would document the reasons why a particular game is not yet using latest development.

Communication is key!

[ivand]

I also propose:
1) that regular meetings be held between engine devs and at least one representative of each game's development team.
2) that a wikipage be created and maintained by game devs, which would document the reasons why a particular game is not yet using latest development.

Communication is key!

Thanks for the proposal. Several notes from my side though:

1a) As mentioned in the OP, we don't really have engine devs in the full sense of this phrase. I'm a part time contributor, the others are rather busy too. Now after the decision to leave `maintenance` behind is practically made, I hope Kloot resumes from his hiatus. It's hard, maybe even impossible to move forward without him.
1b) I'm not sure regular meetings are doable. First we all live in different TZ, secondly the availability seems to be the issue. Instead of the formal, regular meeting I propose much more agile format of Discord discussions. Some don't like Discord, any chat application certainly distracts, but nothing better is seen. Most of the engine contributors can be found there already.
1c) The meetings are in fact semi - happening. Whoever made themselves available and public do talk on a regular basis.

2) Interesting idea, I like it. Though I don't necessary like more rigid format of wiki, but having the common knowledge of the issues seen on the game side is definitely worthy.

For now I put together the list of deprecated functions: https://springrts.com/wiki/Deprecated_Lua_GL and started drafting a PR, that would include new API and optional infolog warnings in case the deprecated functions are called from Lua https://github.com/spring/spring/pull/536

For me in order to act with confidence I ask that the final maintenance release is released in the next several days.

[Silentwings]

It would be good if (at least one of) Kloot/Hokomoko got time to reply, not sure how long that needs.

[FLOZi]

I'm going to keep banging the drum on 6357 (patch in mantis) and 6402 (changing 2 char) to be included before 105.0.

[ThinkSome]

1b) I'm not sure regular meetings are doable. First we all live in different TZ, secondly the availability seems to be the issue. Instead of the formal, regular meeting I propose much more agile format of Discord discussions. Some don't like Discord, any chat application certainly distracts, but nothing better is seen. Most of the engine contributors can be found there already.

I do not condone the use of proprietary software. A free software project cannot and must not depend on software outside of its control. Matrix exists and as far as I am aware, offers most (if not all) of the features that Discord has. That, and some Matrix channels are already transparently linked to the official lobby server's chat channels.

The reason why I proposed meetings is because I do not see any discussions going on the official lobby's channels or here on the forum. Mantis is also quite barren.

[zwzsg]

For now I put together the list of deprecated functions: https://springrts.com/wiki/Deprecated_Lua_GL

Not sure how long till they get removed, but that's gonna break a lot of code in Kernel Panic, as well as my HexFarm map, and varied widgets.

[ivand]

I do not condone the use of proprietary software. A free software project cannot and must not depend on software outside of its control. Matrix exists and as far as I am aware, offers most (if not all) of the features that Discord has. That, and some Matrix channels are already transparently linked to the official lobby server's chat channels.

You are free to join Discord servers from OSS browser or use whatever bridging solution that exists or possible to do.

The reason why I proposed meetings is because I do not see any discussions going on the official lobby's channels or here on the forum. Mantis is also quite barren.

You do not see them because these communications means are outdated and less used these days. I can understand your stance on Discord and state this only as a matter of fact.

Not sure how long till they get removed, but that's gonna break a lot of code in Kernel Panic, as well as my HexFarm map, and varied widgets.

I thought I expressed myself clearly. If not, let's reiterate.

• Spring-develop does not have these functions already. They are considered obsolete by the industry and removed from core profile starting from 2009

• Spring-"transition" does have and will have these functions. They are also considered obsolete, nothing changes here, but they are available for use. The purpose of having them here is to enable gradual transition from old API to new API, which is being added to the transition branch

• Those who don't want or need to move forward towards spring-develop by means of spring-transition are free to stay on the hopefully-soon-to-be-released next stable

There is a lot of misconception going on. The purpose of the transition branch is to add the new API and migrate games and not to remove anything. I don't foresee the need to remove or change anything in the way "maintenance" part of the engine works and even if I do, the changes should be marginal.

[Ares]

There is a lot of misconception going on. The purpose of the transition branch is to add the new API and migrate games and not to remove anything. I don't foresee the need to remove or change anything in the way

You just said you want to remove LUA, that counts as a change.

[zwzsg]

Lua is not an acronym, it's spanish for moon.

[raaar]

105.0 soon, but how soon?

I'm going to keep banging the drum on 6357 (patch in mantis) and 6402 (changing 2 char) to be included before 105.0.

I have a bunch of changes i'd like to be included myself, namely 6395 (serious crash!), but also game mechanics issues:
- fighter aircraft attack runs sometime go way past the target and even refuse to turn if ordered to move
- beamlaser weapons do not respect heightMod weapon def
- lasercannons get less range than what the weapondef says
- lasercannons and beamlasers should have a way to specify how far they'll go before disappearing
(and more)

One thing that annoys me about the development discussions is that they've focused too much on visual issues (GL stuff) and whether the way it's done in spring is "up to date" or not, and that contrasts with the issues I run into while playing and making spring games, which focus on game mechanics: unit and weapon options, projectile movement, targetting, pathfinding (units getting stuck).

[ivand]

105.0 soon, but how soon?

As soon as possible I hope. My motivation is not endless.

One thing that annoys me about the development discussions is that they've focused too much on visual issues (GL stuff) and whether the way it's done in spring is "up to date" or not, and that contrasts with the issues I run into while playing and making spring games, which focus on game mechanics: unit and weapon options, projectile movement, targetting, pathfinding (units getting stuck).

We can discuss as much as needed (outside of this thread). The reality is that no one is looking (at least closely) into the issues you listed. It's a bitter reality. The only bugs that have been getting fixed recently are either domain specific, i.e. done by people proficient in certain area of engine or infra or done by individual contributors. Areas related to sync sim, crashes are not attended. I think I'm writing this for the 3rd or 4th time: we have had no lead developer for the past 6 months!

One the main reasons we have none is because we failed to migrate to the engine version he was developing for several years (spring-develop). My push, for which so far I'm mostly getting trolls attention, is towards moving to that version in attempt to a) bring back the lead dev b) increase capabilities and accelerate rendering of spring games that follow on. That's all I can offer.

I'm not proficient in weapons, targeting, pathfinding, crashes and stack traces, so the only chance of getting fixes is that you(*) find the exact place in the engine that is responsible for the bug, write a fix, test a fix and prepare a pull request.

(*) You, yes, you, not some abstract engine dev, that I remind, are no longer seen in the wilds.

I'm going to keep banging the drum on 6357 (patch in mantis) and 6402 (changing 2 char) to be included before 105.0.

Same as above. Please patch, test, author the PRs. I can't say for other contributors, maybe someone can review and approve, but chances are high that you will need to be personally responsible for the lines of code you add. Meaning you'll need to fix crashes, performance and potential interop issues.

P.S. Please be swift, we can't drag this for long time. Mantis has over 6000 tickets, ZK produces crashes every day in double digit numbers. If we are to fix every bug and implement every feature request, count me out.
Also even if maintenance is over the engine that would be built after will remain maintenance compatible.

[raaar]

(*) You, yes, you, not some abstract engine dev, that I remind, are no longer seen in the wilds.

P.S. Please be swift, we can't drag this for long time. Mantis has over 6000 tickets, ZK produces crashes every day in double digit numbers. If we are to fix every bug and implement every feature request, count me out.
Also even if maintenance is over the engine that would be built after will remain maintenance compatible.

It's harder for people like me who aren't used to the setup to develop for the engine itself (or coding c++ for that matter) and I'm wary that even if i do it, abstract engine devs may reject my proposed fixes (the approval process may drag on....and on....).

I've done that in the past in a few cases. I'll try again....maybe.

[FLOZi]

There's a diff file on mantis, there's a reason there's not a PR (Trying to get git to play ball is a fucking nightmare on windows ) and the second one is literally-1+2 char change. Way more pointless esoteric stuff gets added all the time. Hoko wouldn't apply the diff because he wanted me to tidy up someone else's mess.

Humorous that unlike 90% of people in this thread or many who submit PRs, I used to have commit rights.

[Beherith]

To give impetus as to how awesome the 104-2080 develop branch is (Especially the way rendering units is now so much faster), here are some screenshots and general perfomance notes. My rig is i7-2700k + GTX2060.

This is BA on develop with 7.5k (1000 fighters patrolling too) units in iconwars (zoomed out), running at 60+ fps.

screen00334.jpg

(626.36 KiB) Not downloaded yet

Now this is the wonderful part, this is the same with 7.5k units RENDERED:

screen00333.jpg

(890.8 KiB) Not downloaded yet

104 maintenance drops to below 30 fps with just 1000 units rendered.

Sim performance is generally similar between 103 and 104 develop. the conclusion here is faster rendering directly translates into better overall performance.

[FLOZi]

Awesome Beherith, thank you for sharing that.