[chief1983]

This has already been discussed in the internal, but I'm posting this announcement here so it's clear.  In order to prevent the same extended delay we had getting 3.6.14 out, we're currently working on stabilizing trunk (which shouldn't be hard because the Diaspora build that is very stable is not far behind it) and releasing that as a much more up to date stable build before merging in the new pilot code.

What this means is that we're currently only committing bug fixes (and preferably specific ones, but any Mantis fix is probably welcome) to trunk for now.  Below is a reference list of bugs we're currently trying to take care of before releasing a 3.6.16 build for testing.  (This list isn't necessarily comprehensive; it may be modified in the course of the code freeze.)  If you can't fix these but want to help, any follow up or additional info on reproducing some of them often comes in handy.  In particular, we would appreciate testing on the tickets which need confirmation that the bug is in fact fixed.

Crash/high priority:
1951: Standalone crashes - Ship <ship>does not have subsystem <subsystem> linked into the model file

Other:
1890: Fighter beams and lag = no respawn for client

Fixed:
2529: AI guards leader of player's wing when ordered to guard player
2600: Misc Anims Sounds Are Duplicated
2649: Crash upon proceeding to ship or weapon loadout after manually aborting a mission
2664: shockwaves uses target objects radius to calculate damage
2690: ship-create and mn.createShip() don't load thruster models/submodels
2691: Briefing colors need tweaking
2702: Mainhall sounds not panning correctly
2704: Some models rendered incorrectly with fixed render pipeline
2706: Weapons not colliding
2708: Collision problems with weapons
2712: "change-ship-class" sexp doesnt work for clients
2714: HUD won't change with change-ship-class SEXP
2719: Lab crash after switchting from ship debris to another ship
2723: Ship lab crashes for any ship with show secondaries
2724: Crash at ship selection
2725: Beam sounds not panning correctly
2727: Ship Lab - Debris rendered in wrong location if model has non-zero center of mass

Bugs are everyone's problem, and we need everyone's help keeping FSO running smoothly.  Having a stable trunk before the pilot code goes in is going to be critical to stabilizing it quickly.

TLDR: A code freeze is currently in effect.  No new features will be added until after 3.7 is released.

[General Battuta]

Will the capship CM feature be fixed? (i guess that is at least in part up to me so i'm asking: can it be fixed?)

[chief1983]

Haven't heard of it before, but if it's a clean enough fix, why not.

[mjn.mixael]

Below is a reference list of bugs we're currently trying to take care of before releasing a 3.6.16 build for testing.

Eh? Am I blind?

[chief1983]

It's still being compiled, sorry for the delay on that.

[Goober5000]

Added.

Will the capship CM feature be fixed? (i guess that is at least in part up to me so i'm asking: can it be fixed?)

What Mantis ticket is it?

[mjn.mixael]

Does commit 9347 fix mantis 2704, or is that unrelated?

[General Battuta]

Added.

Will the capship CM feature be fixed? (i guess that is at least in part up to me so i'm asking: can it be fixed?)

What Mantis ticket is it?

It's not

[Goober5000]

Does commit 9347 fix mantis 2704, or is that unrelated?

Not sure; that's probably a Zacam or Valathil question.  I've added it to the "close"/"to test" list.

It's not

then why are you even

[Trivial Psychic]

I don't suppose that shadows and the other cool visuals supplied to us by "Mr. Wizard" will be making it into this release.

[chief1983]

Not enough time for testing that stuff at the moment.  Plus, I'm not sure he's 100% done with any of those yet himself.

[Nuke]

the point of the code freeze is to stabilize the code base so that all those new features sitting in antipodes, and all the test build code (assuming they wont go through their own antipodes phase first) can be merged in with less trouble. badass features + buggy codebase = buggy features. [/captain obvious]

[Goober5000]

There are now five unfixed bugs on the list.  Also, there is a standing offer of pizza and other goodies if the number of open Mantis tickets can be pared down to 99 or less before we pull the trigger for 3.6.16.  (The list currently stands at 183.)

[chief1983]

I don't know if we'll be able to get that many bugs fixed before we need to start calling a build 3.6.16.  Trying to fix that many bugs that quickly is likely to introduce more bugs, etc.  I'd prefer we focus on the major ones for this, and more bugs can be fixed when we get the pilot code in, which itself should fix a lot of outstanding bugs hopefully.

[Goober5000]

Well, right now we have bug-fixing momentum.  It's not a case of trying to fix too many bugs too quickly, it's a case of sustaining the momentum that we have.  The pizza and other goodies are incentives to keep the momentum going until the number drops below 100.

It's true that we should focus on the major bugs, but if people are able to fix a couple of minor bugs, they should certainly do so.  Every little bit helps.

Also, don't forget that several people are keeping an eye on Mantis these days.  We're not going to allow bugs to be resolved or closed unless it's justified.

[FUBAR-BDHR]

Apparently closing unresolved issues because they require redesign to fix is now justified. 

[chief1983]

I think it's a redefinition of the problem from a bug, to simply going beyond the limits of the engine.  Expanding those limits is a feature, and without a plan to tackle that at some point, the bug is just going to sit there.  I am open to discussion on whether we should be leaving issues like that open though, as it would at least serve as a reminder of a problem that many people would like to see addressed at some point.  But at the moment, I'm still thinking it's fine being closed, unless someone has an actual plan for addressing it at some point.

[niffiwan]

Are the two mantis tickets that FUBAH is referring to caused by floating point imprecision?  i.e. to fix would require a rewrite of the engine to convert the co-ordinates system from floating point to integer?

[Goober5000]

I believe so, since those are the most recently closed tickets.

Really, the jitter at extreme coordinates is an unavoidable side effect of using floats.  It can't be "fixed" without a substantial redesign -- substantial in both time and effort.  You could argue about where to draw the line when deciding when to close a ticket, but this is well and safely past the line of impracticality.

That's not to say it could never happen, but it's less likely to happen than wxFRED.

[Nuke]

id actually call that a feature request and not a bug. the engine was never intended for big areas like that.