Modding, Mission Design, and Coding > FS2 Open Coding - The Source Code Project (SCP)
A suggestion for improved modding stability: Bugfix releases between stables.
Cyborg17:
--- Quote from: mjn.mixael on June 14, 2021, 08:31:16 am ---And no, this bug is not on GitHub. My last couple of bug reports have gone completely ignored, sooo... ¯\_(ツ)_/¯
--- End quote ---
I helped you with two of those recently. You have two open non-mantis bugs on github. (thank you, again, for transferring those mantis bugs over) One of them was admittedly ignored, but so have the 6 surrounding bugs, meaning that no one has had time to address them. The only other one that hasn't been resolved since you posted it is the bug for the ships going ridiculous speeds, but we were never able to reliably reproduce that one.
All the members are stretched and we're falling behind on pretty much everything. Only Goober and Asteroth have been able to regularly submit pr's. The most I've been able to do is review the stuff Asteroth has submitted. He's been submitting features and bugfixes.
mjn.mixael:
Issue 3375 and 3367. Both of which I've had to come up with workarounds for. But that's not the point of this thread.
Phantom Hoover:
--- Quote from: Goober5000 on June 13, 2021, 07:11:39 pm ---The quarterly release cycle is intended to improve FSO's stability in precisely this way. We have a mini-code freeze before every release, precisely for the purpose of squashing any outstanding bugs.
It doesn't take much effort to post an official build, but it does take a fair amount of effort to manage the release cycle. I don't know that we have enough manpower to produce maintenance releases with everything else going on. PR reviews take a lot of work too, and there are a lot of pull requests currently outstanding that need reviewing.
--- End quote ---
The proposal here is basically to make minor patch releases to stable builds if and when regressions are caught. The problem with quarterly builds is that proactive testing before release doesn't seem to be enough to prevent a couple of big 'showstopper' bugs for one mod or another slipping through (the very subtle resequencing of AI, physics and goal code which broke BP checkpoints in 21.0.0 is a great example), and it's frankly embarrassing to be telling modders hit by that kind of thing that they'll have to use the next quarterly stable build, which may have introduced more regressions with new features, to fix it. I would really like to see incremental patches, say 21.0.1 for instance, that have precision fixes to major regressions found in the wild. I really hope that we can get the release requirements for these down enough to be practical, because I get an alarming sense of "two steps forward, one step back" with every release under the current arrangement.
Cyborg17:
--- Quote from: Phantom Hoover on June 14, 2021, 09:39:29 am --- I really hope that we can get the release requirements for these down enough to be practical, because I get an alarming sense of "two steps forward, one step back" with every release under the current arrangement.
--- End quote ---
I agree. It's not a great system.
Goober5000:
--- Quote from: mjn.mixael on June 14, 2021, 08:31:16 am ---Not everything that causes compatibility issues is so clearly a bug. I've brought up this example before and at the risk of sounding like a broken record, I'm going to do so again because it's the perfect example of the kind of breakage mods encounter without expecting it. It's also a pretty good example of how SCP handles these types of issues (see: they don't).
BtA had a mission with an event tied to when the AI fires missiles. The idea was that the event would trigger when the AI hostiles get within firing range and actually start firing. There's a thousand ways to FRED such a thing, but this is the way the mission designer chose. This bug did not exist at release or for several years following. Then at some point unknown the AI started firing as soon as they arrive in the mission even though they are out of range of any valid target. This caused the event tied to AI missiles firing to trigger too early, breaking the mission.
It's easy to fix in FRED, which is what I did. But the implications of this small AI change are pretty broad. Outside of just the sexp, this implies that across the board the AI has fundamentally changed when they choose to fire missiles which can have far reaching effects on missions and mission balance. I know SCP is aware of the issue. Asteroth scolded me for months about not fixing the mission in BtA (Notice how he expected me to fix it in the mission even though it's the engine that broke it). Is anyone in SCP even interested in looking at why this behavior changed? I suspect not and that we're just gonna roll with it now.
--- End quote ---
If you're referring to the Mefistofele issue, I undertook an extensive debugging session, at the time that you posted the issue, to figure out the root cause. It was caused by SEXPs, not AI, and it was a buggy SEXP that had its behavior masked by a bug in FSO. (I believe Lepanto was the author of the buggy SEXPs in question.)
When the FSO bug was fixed, the SEXP bug revealed itself. But I also described how the SEXP bug could be fixed, again at the time it was posted. This is all documented on Discord.
--- Quote from: Phantom Hoover on June 14, 2021, 09:39:29 am ---
--- Quote from: Goober5000 on June 13, 2021, 07:11:39 pm ---The quarterly release cycle is intended to improve FSO's stability in precisely this way. We have a mini-code freeze before every release, precisely for the purpose of squashing any outstanding bugs.
It doesn't take much effort to post an official build, but it does take a fair amount of effort to manage the release cycle. I don't know that we have enough manpower to produce maintenance releases with everything else going on. PR reviews take a lot of work too, and there are a lot of pull requests currently outstanding that need reviewing.
--- End quote ---
The proposal here is basically to make minor patch releases to stable builds if and when regressions are caught.
--- End quote ---
I don't disagree with the proposal, per se, I'm just saying that it would involve a certain amount of work. In addition to branching and patching, one would have to collect a list of bugs, filter out the fixes to be applied, and merge them.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version