2019-12-07 09:14 EST


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001645FSSCPgameplaypublic2009-07-27 11:55
ReporterGalemp 
Assigned Tochief1983 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version3.6.11 
Target VersionFixed in Version3.6.10 
Summary0001645: Shielded fighters lose shields when unshielded fighter specified in loadout
DescriptionIf the player slot is specified with an unshielded craft in the mission (say, a TIE Interceptor) and the player selects a shielded craft in the loadout screen (say, a TIE Defender) the new ship has no shields.
Additional InformationThis is probably related to a bunch of bugs I've reported relating to player switching craft before a mission. In all cases, leaving the player ship as the mission designer intended presents no issues, but when the craft is replaced the new craft inherits many properties of the old craft.
FSO needs to make sure ships changed on the loadout screen are loaded from top to bottom in the mission so they work like they're supposed to.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0009067

taylor (administrator)

We are really going to need a good test case for this one. Please provide a test mission and data, and the full steps to reproduce this and I'll take a look at it.

~0009069

Backslash (developer)

Hmm. Maybe it's just a line like +Initial Shield: 0 taking precedence?

~0009105

taylor (administrator)

I think that I've got this fixed, but I have no way to test it. If you can provide some data for me to test with I can get this fix committed.

~0009117

Galemp (reporter)

Simply edit your ships.tbl so the Ulysses has $Shields: 0. Then make Alpha 1 a Ulysses in a mission and change your ship to another class in the loadout. Voila.

~0009119

taylor (administrator)

Fix appears to work. I'll commit later today and then mark this as resolved.

~0009177

taylor (administrator)

Fixered.

~0009195

Galemp (reporter)

This issue isn't quite resolved. When a shielded fighter is specified, and replaced with an unshielded fighter in loadout, the unshielded fighter still has the full ETS gauge. By default it is allocating 1/3 of the power output to nonexistent shields, where the S portion of the gauge shouldn't appear at all.

~0009199

taylor (administrator)

Damn. I never even tested going the other way with it. :)

The fix is easy though, so I'll get the update committed in the next day or two.

~0009615

Galemp (reporter)

Reminder sent to: taylor

If this bug has been smooshed you can close the issue.

~0009616

taylor (administrator)

It's fixed, but I haven't had a chance to commit it yet which is why it's still open.

~0009664

taylor (administrator)

Should be fixed in SVN now.

~0010275

Goober5000 (administrator)

Last edited: 2008-11-26 14:06

We've got a problem here. This breaks FSPort missions, where no ships in the first 8 missions have shields. Unfortunately, changing from an Apollo to a Valkyrie gives you shields. (Both Apollos and Valkyries have shields in ships.tbl.)

EDIT: I have to disagree with Galemp here; ships specified in loadout *must* inherit properties of the old ship. Any flags applied to the player should apply no matter what ship he's flying.

Unfortunately, this makes the SWC fix a lot more complicated, if it can be fixed at all. In FS, shields can be specified on a ship by ship basis. In SWC, shields are an intrinsic part of the ship -- either a ship has them or it doesn't.

~0010276

chief1983 (administrator)

I could tell this would probably be a complicated fix for SWC the first time I saw this bug, for the reasons you mentioned. You may not want any player ship to have shields, regardless of if it does or not. If we want to either be able to let the mission designer say that any ship should not have shields, or just certain ones, that becomes very difficult. If the box did not need to be checked for ships with no shields defined in the tables, then we might need to define every fighter that we want to have a shieldless option twice.

So, let's say every ship should be capable of having shields. If every ship has shields in its table entry, disabling the player ship's shields in FRED for the default ship doesn't let them swap between shielded and unshielded craft. We would need duplicate entries, one with shields, and one without, for any ship we want to have shields completely disabled for in that mission. We shouldn't need to disable player shields in the mission then, so that if they do pick a shielded ship they still have shields, as it hopefully would have been before this fix. This is the only way I see to do it, without breaking the ability to fully disable a player's shields, as that option was intended for.

~0010351

chief1983 (administrator)

Seeing as how FotG doesn't _need_ this fix immediately, and it's going to need more attention to keep from breaking other mods, we may want to revert this fix and look at it another day. We certainly won't need it for 3.6.10. I'm not entirely sure I agree with the description of this bug either, since if a mission designer specifically checks a box in the ship's properties, it should apply to any replaced ship. Any loadout changes between ships should only come from available weapons besides what is loaded on the default ship. To disable shields on a ship with a mesh, but allow them to be re-enabled when switching to another ship should not be controlled through the ship properties dialog. It should be a property of the ship itself. The checkboxes may need to be revisited to allow greater control over that, but still retain compatibility with other mods.

~0010355

Goober5000 (administrator)

Yeah. I say let's revert this fix (make sure we revert the whole thing, since Taylor made more than one commit) and mark this ticket as "no change required". If we do add something for SWC, it'll have to be a whole other feature.

And that's IF we add something. It occurs to me we may not need to: the mission designer can simply add an event at the start of the mission that iterates through all the player ships, checks their ship classes, and does shields-on or shields-off as appropriate.

~0010359

chief1983 (administrator)

Does the game break if Has Shields is enabled for a ship with no shield mesh/surface shields? Or does the ship simply still have no shields? Just out of curiosity.

~0010369

Goober5000 (administrator)

You can't activate "has shields" on an arbitrary ship; it's backwards. In ships.tbl, all fighters and bombers have shields defined, but you can give any ships the "no-shields" flag in FRED.

~0010393

chief1983 (administrator)

Goober and I discussed several fixes for this for FotG, and I wanted to put them here for clarity. There's three levels of fixing, from least involved to most involved in the code.

1. No code changes aside from the reverting back to before this fix. We handle everything per ship class via a SEXP that runs at the start of every FotG mission. This is easiest on the SCP, but the most effort and the most likely to cause problems often for us. But it would allow us to start doing these types of things right now. One SEXP batch would run and set every ship's shields based on the class, and then individual ships could be forced on with another set of SEXPs. This seems like it would cause trouble when we want to add new ships though, unless we can add unrecognized ships.tbl flags and check for those in a SEXP, otherwise the default ship-class status would have to be hardcoded into every mission. It would also be more work to add new ships to a mission, and batch updating a set of missions for a new ship would almost require the use of copy and paste in notepad, which would be nice to avoid.

example:
when-argument
--any-of
  --TIE Fighter
  --TIE Interceptor
  --TIE Bomber
--is-ship-class
  --Alpha 1
  --<argument>
--no-shields
  --Alpha 1

2. Create an 'intrinsic no shields' flag in the code. Basically, if a ship has this flag it behaves the same as if no-shields were on for that ship in FRED, but it goes with the ship class instead of the ship in the mission, so changing the player ship would update this default setting. If he starts with a TIE, just leave the Has Shields box ticked, the intrinsic flag will still disable shields. If he switches to an X-Wing, shields will be enabled. Then the only SEXP usage would come into play to force shields on for a ship that normally has intrinsic no shields, which would be more of a mission-specific occurence anyway and make sense.

3. Twice as much work as the previous (because it includes it), but completely SEXP free and clean. Add a new checkbox besides Has Shields (such as Force Shields On), that forces shields on even for a ship with the intrinsic no shields flag. Then instead of a SEXP to force them on a ship by ship basis, the FRED Edit Ship dialog could be used to say, force shields on for a TIE Fighter. I also think that renaming Has Shields to No Shields would then make this less confusing semantically, since the unchecking of it is what adds a property to the ship in the mission anyway, not the checking of it. If not it would at least need to be clarified to say Default Has Shields or the like. Forced shields would require Has Shields to be checked so that the force-shields property or whatever it would be called would not be combined with no-shields.

I think the third one makes the shield setup quite versatile, and it also doesn't break any backwards compatibility (none of them do though I suppose). As stated, we can get by completely with current SEXPs, but I can't imagine FotG being the only mod to ever want to make use of this feature, maybe we're just the first to notice it could be that way.

~0010752

chief1983 (administrator)

Last edited: 2009-03-19 00:59

I think I'm about ready to close this bug, as I've managed to code up a fix. I'll post it here for now in case anyone wants to comment on it.

http://fsscp.pastebin.com/f215417c7

I'm not sure about the Fred_running checks being necessary, I didn't want it fiddling with the shields in Fred though, not sure whether it would do anything undesirable or not. My access of p_objp doesn't seem to be breaking anything but it could be leaking memory for all I know, so if I did that wrong please let me know. Otherwise I'll try to get this pushed into the next version after 3.6.10. I'm currently working on the third part of the suggestion, adding an additional mission parse object flag for forcing shields on. Works on pretty much the same chunks of code except where I added a new flag.

Edit: Ok I made the new version with support for forcing shields on. Had to clean up a bit of the way I was thinking the first time through. Now it just needs a checkbox added to FRED.

http://fsscp.pastebin.com/fcd9ff4d

~0011110

chief1983 (administrator)

Ok, FRED support for the forced shields was added thanks to Karajorma's help, so I'm marking this one completed.
+Notes

-Issue History
Date Modified Username Field Change
2008-03-30 00:43 Galemp New Issue
2008-03-30 01:44 taylor Note Added: 0009067
2008-03-30 03:46 Backslash Note Added: 0009069
2008-03-31 05:02 taylor Note Added: 0009105
2008-03-31 05:02 taylor Status new => assigned
2008-03-31 05:02 taylor Assigned To => taylor
2008-03-31 17:30 Galemp Note Added: 0009117
2008-03-31 18:17 taylor Note Added: 0009119
2008-04-04 03:16 taylor Status assigned => resolved
2008-04-04 03:16 taylor Fixed in Version => 3.6.10
2008-04-04 03:16 taylor Resolution open => fixed
2008-04-04 03:16 taylor Note Added: 0009177
2008-04-05 21:51 Galemp Status resolved => feedback
2008-04-05 21:51 Galemp Resolution fixed => reopened
2008-04-05 21:51 Galemp Note Added: 0009195
2008-04-07 03:16 taylor Note Added: 0009199
2008-08-28 09:37 Galemp Note Added: 0009615
2008-08-28 19:56 taylor Note Added: 0009616
2008-09-13 10:41 taylor Status feedback => resolved
2008-09-13 10:41 taylor Resolution reopened => fixed
2008-09-13 10:41 taylor Note Added: 0009664
2008-11-26 13:59 Goober5000 Status resolved => feedback
2008-11-26 13:59 Goober5000 Resolution fixed => reopened
2008-11-26 13:59 Goober5000 Note Added: 0010275
2008-11-26 14:06 Goober5000 Note Edited: 0010275
2008-11-26 15:16 chief1983 Note Added: 0010276
2008-12-05 17:01 chief1983 Note Added: 0010351
2008-12-05 17:51 Goober5000 Note Added: 0010355
2008-12-05 18:49 chief1983 Note Added: 0010359
2008-12-06 14:51 Goober5000 Note Added: 0010369
2008-12-10 17:52 chief1983 Note Added: 0010393
2008-12-10 17:59 chief1983 Severity major => minor
2008-12-16 19:46 taylor Status feedback => assigned
2008-12-16 19:46 taylor Assigned To taylor => chief1983
2009-03-18 23:53 chief1983 Note Added: 0010752
2009-03-19 00:59 chief1983 Note Edited: 0010752
2009-03-19 01:02 chief1983 Status assigned => feedback
2009-07-27 11:55 chief1983 Note Added: 0011110
2009-07-27 11:55 chief1983 Status feedback => resolved
2009-07-27 11:55 chief1983 Resolution reopened => fixed
2009-07-27 11:55 chief1983 Product Version 3.6.9 => 3.6.11
+Issue History