Spring RTS Engine

Since phoenix is getting played more, people noticed there is a problem with chat being gray. I also noticed that drag line move command doesn't always work with air - it turns the line you dragged into a single point.

I have been told the used engine 104.0 is the problem ( ). For BA10 engine 104.969 is used and seems to be ok. So I think PA hosts should switch to that engine? Fabs?

OK np. Host is actually in maintenance.
just after, PA will be switched with 104.0.1-969-ga0e1218.
I will post here again when done.

It seems ok now, up and done.

Ares wrote: ↑07 Apr 2019, 16:36 Since phoenix is getting played more, people noticed there is a problem with chat being gray. I also noticed that drag line move command doesn't always work with air - it turns the line you dragged into a single point.

AFAIC, I don't see com, also a problem with ADV playerlist with engine 104-969. It's not ok actually.

Sorry, my fault as I expected that an engine version 104.0 would be compatible with another engine version 104.x within the same major version (as you can expect it from other projects).
As I have just learned from Bluestone there are no two engine versions that are necessarily compatible to each other. So there is afaik no way to update any engine version without proper testing/bugfixing cycle from game developers. (Current developer count: 0)

It's not a problem. I really thaught the same as you.
We should now contact ex-Phoenix dev to see if they want to work a bit to adapt Phoenix on 104+ engine.

As "we" seems to keep Phoenix 1.01 or 1.1 as equal to BA9.46, there is not "so much" job to do, just resolving 104+ engine compatibility problem.

I expected that an engine version 104.0 would be compatible with another engine version 104.x

You seem to either have attached too much value to version numbers or be dreadfully confused about what the various 104.0.1-123-gabcdef builds actually are, so allow me to clear up some details. They represent development snapshots on the road to the next engine release (105), which would in ye olden times have arrived (after many moons, with far less overall testing time) as one final build based on an arbitrarily chosen commit deemed release-worthy. As such I'm afraid none of them carry any implicit or explicit promises of stability or compatibility with 104, that rather lofty expectation exists solely inside your head and should be lowered asap. Read this thread to understand why this approach was taken.

no way to update any engine version without proper testing/bugfixing cycle from game developers

There has never been a magical responsibility-free period like that in Spring's entire history.

developer count: 0

Then maybe you should start solving that problem?

Kloot wrote: ↑08 Apr 2019, 21:02 As such I'm afraid none of them carry any implicit or explicit promises of stability or compatibility with 104, that rather lofty expectation exists solely inside your head and should be lowered asap. Read this thread to understand why this approach was taken.

Ok, so maintainance releases are based on arbitrary commits. So release 24523 is in no way more stable than release 23435. As a game developer your only chance is to just try some engines and stick to the one that runs best for you. If you update the engine then you have the chance to get some bugfixes but with same chance you will get new bugs. That's the normal develop cycle. But that's probably not something you will want if you are serious about developing a game and aim to provide at least a semi-stable gameplay experience for your playerbase.

Kloot wrote: ↑08 Apr 2019, 21:02

no way to update any engine version without proper testing/bugfixing cycle from game developers

There has never been a magical responsibility-free period like that in Spring's entire history.

You are overexaggerating my point, right? In the past there have been regularly bugfix-only releases (after a major release) that aimed for API-stability and mainly provided bugfixes. The whole release model was different and game devs could update from one bugfix-release to a newer bugfix-release in the same mainline with good chances to not get API-breaking chances and good chances to get more bugfixes than new bugs.

Kloot wrote: ↑08 Apr 2019, 21:02 Then maybe you should start solving that problem?

So, correct me where I am wrong, but it works like this now:
- no stable releases from time to time
- no bugfix releases that aim to stabilize previous releases
- in no way guaranteed API-stability between any releases
- you might even be out of luck if you found a stable engine version and planned to stick with it...

So I guess it won't be an easy task to find someone who is willing to put enough effort in that would be needed to cope with stuff like that.

very_bad_soldier wrote: Ok, so maintainance releases are based on arbitrary commits. So release 24523 is in no way more stable than release 23435. As a game developer your only chance is to just try some engines and stick to the one that runs best for you. If you update the engine then you have the chance to get some bugfixes but with same chance you will get new bugs. That's the normal develop cycle. But that's probably not something you will want if you are serious about developing a game and aim to provide at least a semi-stable gameplay experience for your playerbase.

Consider it part of the social contract or quid-pro-quo that game devs accept the chance of new bugs (if they choose to update) in exchange for receiving engine snapshots with new features (quite often requested by said devs) and other fixes for free.

While I sympathize with people wanting to provide a smooth ride, and have tried to ensure this with every build, expecting more from a volunteer project which lacks any commercial backing is neither realistic nor justified.

very_bad_soldier wrote: You are overexaggerating my point, right? In the past there have been regularly bugfix-only releases (after a major release) that aimed for API-stability and mainly provided bugfixes. The whole release model was different and game devs could update from one bugfix-release to a newer bugfix-release in the same mainline with good chances to not get API-breaking chances and good chances to get more bugfixes than new bugs.

There were bugfix-only releases precisely because each major version had at least one kind of serious undiscovered flaw (due to protracted development cycles and no intermediate testing) forcing them to be made, and even those often spanned multiple iterations. Ergo the old model was itself inadequate and led to many a memorable shitstorm over the years.

I'd also question the claim that devs are not still getting "more bugfixes than new bugs" on average; maintenance builds have been in far better shape than 104 by every objectively measurable standard for a while now. The occasional bumps in the road are annoying but worth it.

very_bad_soldier wrote: So, correct me where I am wrong, but it works like this now:
- no stable releases from time to time
- no bugfix releases that aim to stabilize previous releases
- in no way guaranteed API-stability between any releases
- you might even be out of luck if you found a stable engine version and planned to stick with it...

You have a stable release (104.0), just no bugfix-only branch. This is influenced both by past experience and by the unique constraints that 105's development imposes.

The disadvantage is that stability is now more fluid (though by no means Russian roulette), and game devs have to invest more if they want to stay with the bleeding edge. The major advantage is that 1) new features and API changes are picked up early and incrementally, rather than being delayed by months or even years and 2) 105.0 will contain fewer surprises and require less neo-natal care.

Regarding your last point: I don't think any version that includes known DOS exploits deserves the moniker "stable", but that's just me.

very_bad_soldier wrote: So I guess it won't be an easy task to find someone who is willing to put enough effort in that would be needed to cope with stuff like that.

It however already has precedent, and would be a one-time effort given PA's mission statement.