2018-06-18 21:27 EDT


View Issue Details Jump to Notes ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0002797FSSCPuser interfacepublic2013-02-26 23:57
ReporterAxem 
Assigned Tokarajorma 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0002797: Ship/weapon loadout doing TOO good of a job remembering?
DescriptionThe recent changes to the loadout code added in 9430 seem to go a little above and beyond their intended goal.

FreeSpace will now only remember the last settings to a mission's loadout. Any changes made in FRED will not override the last settings. This can cause some giant headaches for mod development.

Suppose a FREDder makes a mission with Alpha wing flying 2 Herc II-class fighters. He sends if off to his testers. They complain that Alpha wing needs to be faster and stronger. The FREDder changes the classes to be Perseus-class fighters and ups the wing size to 4. Sends the mission back to his testers. His testers complain that he didn't change anything and quit because obviously this guy is a total loser.

(I realize the reset button cures this, but this can be a hassle when doing rigorous testing.)

Would it be possible to save the last defaults and check them against the defaults in the current mission? That way in a testing environment, if a FREDder changes those starting wings, the testers will get reset to default and see the changes. In a release environment, the missions aren't as likely to change (just from patches) and their settings will be saved.
Steps To ReproduceMake a mission, add the player to a 2 fighter wing.
Play the mission in FreeSpace, quit.
Go into FRED, change the player's ship and add 2 extra fighters to his wing.
Play the mission again, the player's fighter has not changed and the 2 extra fighters are not there.
TagsNo tags attached.
Attached Files

-Relationships
related to 0002753resolvedZacam Custom loadouts not loaded 
+Relationships

-Notes

~0014727

Goober5000 (administrator)

Assigning to karajorma since he committed r9430.

Historically, I think the behavior has been to reset the loadouts if FSO detects that the mission's "Last Modified" date has changed.

~0014728

karajorma (administrator)

Yeah, that's what they used to do. And I can certainly bring that behaviour back very easily. The problem is that it is in and of itself rather annoying. If for instance you are setting up a mission where you can fly a fighter or bomber you're going to have to reset your loadout every single time you test the non-default configuration no matter how small the change is. It was actually this issue (after a discussion on IRC) that led to me removing the check in the first place as most people seemed to agree with me that it was actually far more annoying.

Brainstorming ideas, a possible middle ground solution would be a FRED option to say "This mission is in release format\This mission is not ready for release" when the mission is saved. We could then tie a whole bunch of other settings to it (i.e no use of the mission log, the mission will reset the loadout if it has changed, etc.).

That way, you send missions out for testing only in the release format (or at least give the FREDder and testers a way to see what isn't in the correct format).

The drawback is the message itself might be annoying.

~0014730

Axem (reporter)

I mean the idea sounded good on paper, but in practice it revealed that its just a different kind of annoying now. Because it only saves the last settings, even without actually making it a custom loadout. While the release format option sounds good, but I have a feeling that FREDders will just leave it in its default status and never use it.

Another option (though probably a more painful for the coders) is an addition to the ship/weapon loadout screens a toggle button "Save Loadout". Its been done before for the "apply to wing" button, as well as other cosmetic improvements.

~0014731

FUBAR-BDHR (developer)

This is probably why V had file naming specifications. Each version of the file ended in a letter so the first version of mission1.fs2 was mission1a.fs2 next release mission1b.fs2 etc. It was not named mission1.fs2 until it was ready for final release.


Maybe an internal version number the FREDder can bump (and is logged during parse in debug) would be a solution.

~0014733

Goober5000 (administrator)

The file naming specifications were not for versioning but rather for campaign branching. Originally, there was going to be an "A branch" and a "B branch" of the main FS1 campaign, like Wing Commander. Eventually (probably because of the difficulties of maintaining multiple copies of similar missions) they just decided to do the campaign so that both branch possibilities resided in one mission file. These files were suffixed with A and the B files were removed. You can see a vestige of this in that the FS1 missions are all suffixed with A, except for the very first one, which has no suffix, because it was originally the first split point.

~0014734

FUBAR-BDHR (developer)

FS2 had that naming scheme specified for any missions submitted to V. It had nothing to do with campaign branching.

~0014736

Goober5000 (administrator)

Oh, you're referring to user-submitted multiplayer missions. I was talking about the single-player FS1 campaign.

~0014740

karajorma (administrator)

Hmmmm. I don't see much point in a save loadout button. You'd have to remember to press it all the time. It would rapidly get annoying.

I think I'll just restore the original behaviour and make this issue yet another thing to deal with when I get round to re-writing the loadout code.

~0014741

karajorma (administrator)

Fix committed to trunk@9544.
+Notes

+Related Changesets

-Issue History
Date Modified Username Field Change
2013-02-19 22:00 Axem New Issue
2013-02-20 15:58 Goober5000 Note Added: 0014727
2013-02-20 15:58 Goober5000 Assigned To => karajorma
2013-02-20 15:58 Goober5000 Severity tweak => minor
2013-02-20 15:58 Goober5000 Status new => assigned
2013-02-20 15:58 Goober5000 Changeset attached => fs2open trunk r9430
2013-02-20 15:59 Goober5000 Relationship added related to 0002753
2013-02-21 00:43 karajorma Note Added: 0014728
2013-02-21 07:51 Axem Note Added: 0014730
2013-02-21 12:53 FUBAR-BDHR Note Added: 0014731
2013-02-21 18:06 Goober5000 Note Added: 0014733
2013-02-21 20:38 FUBAR-BDHR Note Added: 0014734
2013-02-21 21:34 Goober5000 Note Added: 0014736
2013-02-26 23:54 karajorma Note Added: 0014740
2013-02-26 23:57 karajorma Changeset attached => fs2open trunk r9544
2013-02-26 23:57 karajorma Note Added: 0014741
2013-02-26 23:57 karajorma Status assigned => resolved
2013-02-26 23:57 karajorma Resolution open => fixed
+Issue History