View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002797 | FSSCP | user interface | public | 2013-02-20 03:00 | 2013-02-27 04:57 |
| Reporter | Axem | Assigned To | karajorma | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0002797: Ship/weapon loadout doing TOO good of a job remembering? | ||||
| Description | The 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 Reproduce | Make 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. | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
FS2 had that naming scheme specified for any missions submitted to V. It had nothing to do with campaign branching. |
|
|
Oh, you're referring to user-submitted multiplayer missions. I was talking about the single-player FS1 campaign. |
|
|
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. |
|
|
Fix committed to trunk@9544. |
|
fs2open: trunk r9430 2012-12-14 04:27 Ported: N/A Details Diff |
Fix Mantis 2753 (Customised Loadouts sometimes won't save for next time the mission is played). |
Affected Issues 0002753, 0002797 |
|
| mod - /trunk/fs2_open/code/missionui/missionscreencommon.cpp | Diff File | ||
|
fs2open: trunk r9544 2013-02-27 00:38 Ported: N/A Details Diff |
Fix Mantis 2797 (Ship Loadout shouldn't remember the previous settings if the mission has changed) |
Affected Issues 0002797 |
|
| mod - /trunk/fs2_open/code/missionui/missionscreencommon.cpp | Diff File | ||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-02-20 03:00 | Axem | New Issue | |
| 2013-02-20 20:58 | Goober5000 | Note Added: 0014727 | |
| 2013-02-20 20:58 | Goober5000 | Assigned To | => karajorma |
| 2013-02-20 20:58 | Goober5000 | Severity | tweak => minor |
| 2013-02-20 20:58 | Goober5000 | Status | new => assigned |
| 2013-02-20 20:58 | Goober5000 | Changeset attached | => fs2open trunk r9430 |
| 2013-02-20 20:59 | Goober5000 | Relationship added | related to 0002753 |
| 2013-02-21 05:43 | karajorma | Note Added: 0014728 | |
| 2013-02-21 12:51 | Axem | Note Added: 0014730 | |
| 2013-02-21 17:53 | FUBAR-BDHR | Note Added: 0014731 | |
| 2013-02-21 23:06 | Goober5000 | Note Added: 0014733 | |
| 2013-02-22 01:38 | FUBAR-BDHR | Note Added: 0014734 | |
| 2013-02-22 02:34 | Goober5000 | Note Added: 0014736 | |
| 2013-02-27 04:54 | karajorma | Note Added: 0014740 | |
| 2013-02-27 04:57 | karajorma | Changeset attached | => fs2open trunk r9544 |
| 2013-02-27 04:57 | karajorma | Note Added: 0014741 | |
| 2013-02-27 04:57 | karajorma | Status | assigned => resolved |
| 2013-02-27 04:57 | karajorma | Resolution | open => fixed |
