Page 3 of 4

Re: Engine fork and Ingame Community

Posted: 14 Feb 2023, 11:07
by abma
sprunk wrote: 03 Feb 2023, 11:34 It would be interesting to hear your own concerns though. Why not merge the fork, what are your worries?
thats not possible: 106+ dropped a lot of code which the fork still has.


A lot of game devs and people wanted opengl4 thats what spring 106+ is. It requires to drop a lot of old opengl code, without breaking stuff thats not possible IMHO. Creating a fork and not trying to get it merged upstream / beeing integrated into the existing infrastructure and also ignoring the development guidelines. All of this was AFAIK agreed / discussed / voted. I don't see why this should be changed.

Re: Engine fork and Ingame Community

Posted: 15 Feb 2023, 00:36
by sprunk
abma wrote: 14 Feb 2023, 11:07 thats not possible: 106+ dropped a lot of code which the fork still has.
Bringing back that code is one of the major points of the fork, because dropping it broke a lot of gameside rendering. Yes, it's not possible to merge the code in the technical git sense of a merge. But it's entirely possible to designate the fork as the new official development branch, or any of similar measures that essentially amount to dropping the commits that drop useful code from the main official branch.
abma wrote: 14 Feb 2023, 11:07 A lot of game devs and people wanted opengl4 thats what spring 106+ is.
Yes, game devs wanted GL4, but also most of them never gave a carte blanche to break existing Lua interfaces.

Some game devs enthusiastically agreed despite the risk of breakage, hoping they would just take code from more mature games. This didn't work out, because mature games haven't completely migrated so far, so these people didn't get what they wanted from 106 (but they can follow mature games on the fork).

Some game devs were promised a transition branch that would help them smooth out the migration. They didn't get what they wanted from 106, but they are getting what they want from the fork.

Some game devs were promised help migrating or led to believe the breakage would not come sooner than the migration. This didn't work out, so these people didn't get what they wanted from 106, but they are getting what they wanted from the fork.

Some game devs maybe were both willing and capable to migrate to GL4. But they aren't exactly getting what they wanted from 106.

Some people with no stake at all wanted it and were willing to throw games under the bus. I have no way to know how much weight this carried, but regardless, that specific post wants GL4 to "see a modern version of spring" and "make spring popular again". Not getting what what was wanted from 106, but games on the fork tend to look more modern.

Lastly, engine devs wanted to drop GL3 so that the engine would not slowly stagnate and die, new possibilities could revitalize it. This was actually legitimate reasoning given the assumption games would migrate. But that assumption wasn't fulfilled, and the reasoning should be reevaluated. Engine devs didn't get what they wanted from 106, but they (both the currently active engine devs doing anything, and most historical ones) are getting what they wanted from the fork which is more alive than Spring has ever been.

Regardless of my points above, what a lot of game devs and people really wanted is evidenced by most of them switching to the fork.
abma wrote: 14 Feb 2023, 11:07 It requires to drop a lot of old opengl code, without breaking stuff thats not possible IMHO.
Yes, eventually old GL3 code should be dropped. This should happen when games making an effort to do it are ready for it, not arbitrarily at somebody's whim. It is entirely possible to advance to GL4 in steps, as evidenced by the fork.
abma wrote: 14 Feb 2023, 11:07 Creating a fork and not trying to get it merged upstream
What is https://github.com/spring/spring/pull/559 if not an attempt to get it merged upstream? How would you have preferred to see this go instead? That PR waited half a year for a review that would not come and they even kept a relatively clean branch so the goalpost wouldn't move. What more could you ask of them? The only thing they didn't do is wait an eternity for a review or merge which was never going to come. There was a month of inactivity before the close during which absolutely nothing happened from the official Spring's side. Even after closing, you could still take the early commits that were reviewed and had no issues raised, or even keep slowly trickling them in. I see a lack of trying but not on the fork's part.
abma wrote: 14 Feb 2023, 11:07 (not trying to) beeing integrated into the existing infrastructure
Being integrated into infrastructure would only make sense if the branch was merged, but that is not to say there was no trying. Check the back-and-forth starting around this post. How would you rather see infra handled? Do you expect somebody to also fix infra as a precondition for accepting major engine work? This doesn't sound viable.
abma wrote: 14 Feb 2023, 11:07 and also ignoring the development guidelines
Which guidelines listed on that page were ignored? Being aware of synced/unsynced, code comments, and things like avoiding needless CPU usage obviously aren't what you mean. One thing listed there is "if your changes change gameplay it might be a good idea to make it optional", which sounds like it would apply to dropping half the rendering interfaces, but that's a rule the fork follows well (it's the most important rule by far! It's why anybody is using the fork!).

The rule I assume you probably mean is the one for git branches? But the fork started as just a large feature branch PR, so follows the rule decently (specifically, on that graph it's represented by the leftmost pink commit chain). It's larger than a typical feature branch but that's the nature of the work involved. More importantly, it's just a continuation of the maintenance/transition branch that existed just before the fork did, which had official engine endorsement, and which is more recent than an obscure wikipage that nobody knows about. How else do you expect to handle branches with large amounts of connected changes?
abma wrote: 14 Feb 2023, 11:07 All of this was AFAIK agreed / discussed / voted.
As far as I can tell it was initially voted in 6 years ago in the circumstances and assumptions appropriate to that time. Note that this is before the full emergence of BAR as a separate game, and with basically no gamedev input. It was then discussed, 2-3 years ago, by game devs who, as I described above, were somewhat cluelessly agreeing on something else than what they were getting after all. This is plenty time to gather enough feedback to decide that this turned out to have been a bad idea and is still a bad idea. This doesn't mean GL3 cannot ever get dropped. It just means that at the moment that GL3 code does more good than harm to the engine and should be brought back. Doing it by wholesale replacing the current main branch with the fork is the ideal way to do this because it saves the most work (the fork is well-tested, major games are already compatible with it, it contains multiple non-GL related improvements, etc).
abma wrote: 14 Feb 2023, 11:07 I don't see why this should be changed.
What would be enough to convince you?

Re: Engine fork and Ingame Community

Posted: 17 Feb 2023, 22:33
by raaar
+1 to Sprunk's arguments. Don't get stuck on bad past decisions without very strong reasons.

In early January Abma removed BAR from the list of games on the wiki. This a mistake and not just because it's hostile. Even if they use a rebranded fork of the engine (it's a shallow rename and backwards compatible atm), they still use the same format for maps and upload them to Springfiles. MF, ZK and possibly other games are using them!

In the future we may even get games using their own forks of either engine with some niche feature added that they couldn't emulate using the lua API.

Instead of pretending popular forks don't exist, they should at least get a branch on the official repository for safekeeping.

The current spring engine github repository has like 15 branches, most haven't seen any commit in 5 years, some more than a decade.

Re: Engine fork and Ingame Community

Posted: 18 Feb 2023, 00:34
by Google_Frog
Sprung covers the situation well.

If the wiki is meant to only list games that run on the official engine (106.0), then the page should be empty.

Re: Engine fork and Ingame Community

Posted: 21 Feb 2023, 19:26
by abma
sprunk wrote: 15 Feb 2023, 00:36 But it's entirely possible to designate the fork as the new official development branch, or any of similar measures that essentially amount to dropping the commits that drop useful code from the main official branch.
There was no discussion about that, also it was never tried to do that. The complains in the merge request about reviewing a moving goal were ignored.

From the changes i have seen in the fork, i don't want to help maintain it. From the technical point IMHO it goes into the wrong direction: it gets more and more complex and will be at some point unmaintainable by hobbyists.

i.e.

https://github.com/spring/spring/tree/develop/rts/lib
vs
https://github.com/beyond-all-reason/sp ... 05/rts/lib

and no commits in tests:
https://github.com/beyond-all-reason/sp ... AR105/test

i guess i'll just leave "spring" as it makes no sense due to lack of time and the endless discussions just eat my few time up. I blamed others for not beeing active and just discussing, before having to blame myself i'll need to stop this.

Re: Engine fork and Ingame Community

Posted: 21 Feb 2023, 19:39
by abma
Google_Frog wrote: 18 Feb 2023, 00:34 If the wiki is meant to only list games that run on the official engine (106.0), then the page should be empty.
where is the line? should the wiki list games like ta3d? coil is a fork.

Re: Engine fork and Ingame Community

Posted: 21 Feb 2023, 21:34
by raaar
Use common sense when drawing lines. Coil is a recent fork and more compatible with existing spring games than 106.0... you can't use ta3d to run any spring games.

The push to rebrand/rename would have been much lower if the official spring maintainers were more open to it instead of being standoffish.
abma wrote: 21 Feb 2023, 19:26
sprunk wrote: 15 Feb 2023, 00:36 But it's entirely possible to designate the fork as the new official development branch, or any of similar measures that essentially amount to dropping the commits that drop useful code from the main official branch.
There was no discussion about that, also it was never tried to do that. The complains in the merge request about reviewing a moving goal were ignored.

From the changes i have seen in the fork, i don't want to help maintain it. From the technical point IMHO it goes into the wrong direction: it gets more and more complex and will be at some point unmaintainable by hobbyists.

i.e.

https://github.com/spring/spring/tree/develop/rts/lib
vs
https://github.com/beyond-all-reason/sp ... 05/rts/lib

and no commits in tests:
https://github.com/beyond-all-reason/sp ... AR105/test

i guess i'll just leave "spring" as it makes no sense due to lack of time and the endless discussions just eat my few time up. I blamed others for not beeing active and just discussing, before having to blame myself i'll need to stop this.
People make things complicated. You complained about lack of devs, then they got active on the branch you disliked and you dropped it, then doubled down, and now threathen to ragequit.

If you adopt the fork's code then something breaks in a way you can't easily fix, you can do what everyone else does and talk with the other devs, namely the ones responsible for the code that's breaking.

Re: Engine fork and Ingame Community

Posted: 21 Feb 2023, 22:44
by sprunk
abma wrote: 21 Feb 2023, 19:26 There was no discussion about that, also it was never tried to do that.
It was never tried, but also there was never a crisis deep enough to cause a very successful fork, so maybe it's the best moment for the first time! On discussion: we're "discussing" right now, but there isn't much left to discuss. The facts are what they are and the majority of the community is on the side of the fork (essentially, people already "discussed" by migrating, not by making forum posts or chat). The main reason I see for a discussion would be to extend good will to games not using the fork, which are BA and TechA. I don't think TechA has anything to worry about, plus they aren't being forced to immediately migrate. BA is probably always going to be contrarian in the current atmosphere. It's up to you to weigh how much standing they actually have and act accordingly.
abma wrote: 21 Feb 2023, 19:26 From the changes i have seen in the fork, i don't want to help maintain it.
You aren't being asked to help maintain the engine. Current fork engine devs are handling that well.
abma wrote: 21 Feb 2023, 19:26 From the technical point IMHO it goes into the wrong direction: it gets more and more complex and will be at some point unmaintainable by hobbyists.
Are the fork engine devs not hobbyists? But even if they're so exceptional they would be unreplaceable if they go missing, that is not a problem: hobbyists who need something done can just fork the engine and rip out unmaintainable systems. In a way this is what is currently happening, except with the unmaintainable part being social instead of technical.
abma wrote: 21 Feb 2023, 19:26 i guess i'll just leave "spring" as it makes no sense due to lack of time and the endless discussions just eat my few time up. I blamed others for not beeing active and just discussing, before having to blame myself i'll need to stop this.
You're doing a good job maintaining the platform (as I described earlier: site, uberserver etc) and I don't think anybody has a complaint there. But passing the engine to active devs from the fork would be a great move.

Re: Engine fork and Ingame Community

Posted: 22 Feb 2023, 23:04
by hokomoko
To be frank, my personal opinion is that Spring needs new blood that has more time and is more invested than the current management.
If it were up to me, I would transfer control of the Spring project, (both repository and domain) to the most active developers.
These are not random people but figures that we've seen in the community for a long time and I feel we can trust.

Throughout my work on Spring I thought the Spring ecosystem is on its way to oblivion, but I'm very happy that the community, especially BAR and ZK, proved me wrong. Both by game popularity and by pushing the development of the engine. I would like to give the current active developers the opportunity to lead the Spring project in their own way so it can reach new heights.

Nonetheless, some of the core principles that made Spring into what it is, must remain in force, therefore this transfer should be done only upon the agreement of the receiver(s) to several conditions, such as: (this is not a final list)
1) Keeping the name Spring.
2) Reaffirming that this transfer does not confer copyright, so the existing code stays GPL.
3) Future engine code will be licensed under GPL as well.
4) Keeping Spring game-agnostic - The success of our ecosystem hung on the separation of powers between engine devs and game devs. We must keep it this way if we don't want to find ourselves in the same situation a year from now.

Yes, even under these limitations the new people will fuck up. But we fucked up many things as well along the way. That's part of the fun :)

Re: Engine fork and Ingame Community

Posted: 23 Feb 2023, 03:13
by gajop
hokomoko wrote: 22 Feb 2023, 23:04 To be frank, my personal opinion is that Spring needs new blood that has more time and is more invested than the current management.
If it were up to me, I would transfer control of the Spring project, (both repository and domain) to the most active developers.
These are not random people but figures that we've seen in the community for a long time and I feel we can trust.

Throughout my work on Spring I thought the Spring ecosystem is on its way to oblivion, but I'm very happy that the community, especially BAR and ZK, proved me wrong. Both by game popularity and by pushing the development of the engine. I would like to give the current active developers the opportunity to lead the Spring project in their own way so it can reach new heights.
This is where I 100% agree with hoko.

I think our current issues are that of governance - we have failed to adequately transfer management responsibilities from inactive to active members. This includes ownership of https://github.com/spring, forum and lobby moderation and so on.

I'd like to again (this time publicly) offer my resignation on all roles in the Spring community - my responsibilities should reflect my activity levels, which have been very low for some time.
PS: Couple of weeks ago I also resigned from "Core Member" role in the BAR organization - for the same reasons.
PS2: I wonder if BAR & ZK communities have considered (or maybe even implemented?) a term-limited role system, which would adequately transfer responsibilities to new contributors as activity levels change. I think such a thing is necessary for long-lasting organizations.

hokomoko wrote: 22 Feb 2023, 23:04 Nonetheless, some of the core principles that made Spring into what it is, must remain in force, therefore this transfer should be done only upon the agreement of the receiver(s) to several conditions, such as: (this is not a final list)
1) Keeping the name Spring.
2) Reaffirming that this transfer does not confer copyright, so the existing code stays GPL.
3) Future engine code will be licensed under GPL as well.
4) Keeping Spring game-agnostic - The success of our ecosystem hung on the separation of powers between engine devs and game devs. We must keep it this way if we don't want to find ourselves in the same situation a year from now.

Yes, even under these limitations the new people will fuck up. But we fucked up many things as well along the way. That's part of the fun :)
On this, I generally disagree with hoko. If you give up ownership of something, you no longer get to decide what they do with it. As long as licenses are respected, which is a legal requirement anyway, they should be free to do whatever they'd like imo. And they can't exactly relicense the engine without getting consent from *every* previous contributor, or rewriting large swathes of it, which is effectively impractical.

--------------

With all this said, I think the BAR people can simply go along with their fork, they don't need to keep Spring branding. One could even argue that a new name and somewhat separate community might sprinkle some new life into the project.

Re: Engine fork and Ingame Community

Posted: 23 Feb 2023, 21:58
by zwzsg
I understand it is sad that such bad blood festered between official spring, led by abma and the bar fork, led by ivand.
However, we should also be glad that, in this case, open source worked exactly as designed:
When the official spring went in a direction that didn't satisfy some people, they were able to split, implement their own ideas without needing the approval of authority, and as by their work proved the validity of their approach, finally ended up with a more vibrant community.

Yes, a smoother change of dev lead would have been nicer. I wish too all the tears, hatred, wasted effort would not have been spilt. Still, thanks to the principle of open source, Spring may keep on living through its scion of Coil. And that is a much better outcome that having a single dead Spring.

Re: Engine fork and Ingame Community

Posted: 24 Feb 2023, 05:14
by MaDDoX
From a not-so-finished games standpoint, which includes my own Total Atomic Power (formerly T.A. Prime) and Splinter Faction (from Scary Lepoo), it’s extremely clear that 1.06 should have never happened. Not enough game devs interested in building and sharing code for GL4 in 1.06 when it meant to break a huge chunk of the widgets which actually make the game.

In the end, as the “old infra” isn’t actually used by the big games, it’s all about if the “SpringRTS” name and domain will live on or not (as in being transferred to the branch lead dev). Some game devs believe Spring was never a good name to start with, others think it’s got emotional value and it does score well on Google searches, has a long story behind it etc.

There’s no other decision to be made or valuable discussion to be had about this topic anymore. IMO.

So, will SpringRTS live on or not?

Re: Engine fork and Ingame Community

Posted: 25 Feb 2023, 16:58
by raaar
I see this trend of "we need new blood" that becomes "new blood must displace old blood" because old blood did something wrong. The "new blood" of today will likely become the "old blood" of tomorrow.

In this context the discussion isn't about firing some highly paid CEO with a huge severance package, it's about pushing away a tech worker that's been doing it for free for a decade.

People sometimes say and/or do mean, disrespectful things to each other. Often there's a feedback loop which leads to hostility or disengagement. This is hard to avoid as a lot of decisions are debatable, people's timings don't match and people just get on each other's nerves...

The deeper the splits, the more duplicate work is required to maintain software, infrastructure,promotion,etc. and the more likely it is to lose bits of knowledge required to fix something that'll eventually break. Being too pedantic about people's behavior and pushing them apart is how we get unstable projects with low bus factor.

It's easier for most of us in the long run if we spend energy trying to keep veterans engaged and interacting constructively and avoid statements or actions that push them apart. In my opinion the response to Abma's threat of resignation should be similar to what his response to the "ban me"s that some people wrote on this thread should have been : ignore it or some variation of "please stay".

Re: Engine fork and Ingame Community

Posted: 26 Feb 2023, 15:56
by Google_Frog
raaar that is a nice approach in general, but we've reached the point where you would be saying "please join us" rather than "please stay". There is active engine development happening, more than in the last few years, but it isn't happening here. So abma would have to do more than just stick around to be involved. He would either have to join the fork himself (which would be a weird thing to do), or hand some control over to the current de facto engine developers, so that they rejoin mainline spring. And that's just what he would have to do on his end. Whether the engine devs want to be involved in mainline Spring anymore is another question.

Re: Engine fork and Ingame Community

Posted: 27 Feb 2023, 03:37
by MrCucumber
Seeing as the BAR moderation team is full of satanic homosexual pedophiles, its no wonder they are doing their best to break Spring apart and take control like they are trying to do throughout society as a whole.

Warned for Felony 1,3 and 9. -Beherith
This post deserves an instant ban -abma
User was banned for this and other posts. -Beherith

Re: Engine fork and Ingame Community

Posted: 02 Mar 2023, 11:22
by PtaQ
gajop wrote: 23 Feb 2023, 03:13 With all this said, I think the BAR people can simply go along with their fork, they don't need to keep Spring branding. One could even argue that a new name and somewhat separate community might sprinkle some new life into the project.
As someone who systematically worked on popularising Spring/BA/BAR/Recoil for 5+ years (building the player and contributor community) I can give my two cents here. From the marketing perspective, whatever the decision on how we proceed here will end up being, Spring desperately calls for a rebranding.

During my work, I received tons of feedback about how outside viewers, and the target groups see it. Here is what I have found (based by several hundreds of comments):

In popular opinion Spring as an engine is associated with:
1) Games with old generation graphics
2) Obscure indie games and low quality assets
3) Low poly limitations, although not explicitly expressed, but that is the general idea - spring is not good for high fidelity assets
4) Old and deprecated wikis, guides, difficulty in onboarding, finding reliable information, lack of quick dev support (usage of forums)
5) Games using intellectual property without consent of the creators
6) Some weird drama on forums

When promoting BAR specifically I had countless people expressing surprise that it is running on a Spring fork, as they had this idea in their minds that Spring is an old project, underdeveloped for todays standards, that cant really compete with modern engines in producing quality games.

From this perspective, no matter what we do in the end, rebranding will help. Obviously the legacy of Spring ought to be respected and made clear in shaping the communication of the new brand.

I am seeing a lot of interest in building a new refreshed knowledge base for Recoil. I think it is quite overdue. New potential devs should have a clean onboarding experience, up to date information about workflows, new optimised methods and standards.

If we menage this well, Spring/Recoil engine can be a really solid competitor in the RTS capable engines market. Even now it attracts new RTS projects that considered Unity/UE before, and that tells me a lot about where we are.

Re: Engine fork and Ingame Community

Posted: 28 Mar 2023, 14:21
by galileo
Why does BAR warn about fully FOSS compatible GPUs? (eg. Intel)
Why Discord is being used for a FOSS community? That CMS is not freedom friendly because of 3rd party components and tracking.

Re: Engine fork and Ingame Community

Posted: 28 Mar 2023, 17:58
by abma
galileo wrote: 28 Mar 2023, 14:21 Why does BA warn about fully FOSS compatible GPUs? (eg. Intel)
Can you be more specific? Where does it warn / whats the exact message?
galileo wrote: 28 Mar 2023, 14:21 Why Discord is being used for a FOSS community? That CMS is not freedom friendly because of 3rd party components and tracking.
Thats a question that mostly goes to the coil fork: "spring" (springrts.com) avoids using commercial services / closed source and tries to protect privacy.

Re: Engine fork and Ingame Community

Posted: 28 Mar 2023, 19:42
by galileo
Sorry; I've just fixed BA for BAR. This is the mod that warns about some unsupported GPUs when loading.

Re: Engine fork and Ingame Community

Posted: 28 Mar 2023, 19:45
by abma
galileo wrote: 28 Mar 2023, 19:42 Sorry; I've just fixed BA for BAR. This is the mod that warns about some unsupported GPUs when loading.
sorry, then this is the wrong forum.