View Issue Details

IDProjectCategoryView StatusLast Update
0001645FSSCPgameplaypublic2009-07-27 15:55
ReporterGalemp Assigned Tochief1983  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.6.11 
Fixed 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.

Activities

taylor

2008-03-30 05:44

administrator   ~0009067

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.

Backslash

2008-03-30 07:46

developer   ~0009069

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

taylor

2008-03-31 09:02

administrator   ~0009105

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.

Galemp

2008-03-31 21:30

reporter   ~0009117

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.

taylor

2008-03-31 22:17

administrator   ~0009119

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

taylor

2008-04-04 07:16

administrator   ~0009177

Fixered.

Galemp

2008-04-06 01:51

reporter   ~0009195

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.

taylor

2008-04-07 07:16

administrator   ~0009199

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.

Galemp

2008-08-28 13:37

reporter   ~0009615

Reminder sent to: taylor

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

taylor

2008-08-28 23:56

administrator   ~0009616

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

taylor

2008-09-13 14:41

administrator   ~0009664

Should be fixed in SVN now.

Goober5000

2008-11-26 18:59

administrator   ~0010275

Last edited: 2008-11-26 19: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.

chief1983

2008-11-26 20:16

administrator   ~0010276

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.

chief1983

2008-12-05 22:01

administrator   ~0010351

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.

Goober5000

2008-12-05 22:51

administrator   ~0010355

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.

chief1983

2008-12-05 23:49

administrator   ~0010359

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.

Goober5000

2008-12-06 19:51

administrator   ~0010369

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.

chief1983

2008-12-10 22:52

administrator   ~0010393

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.

chief1983

2009-03-19 03:53

administrator   ~0010752

Last edited: 2009-03-19 04: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

chief1983

2009-07-27 15:55

administrator   ~0011110

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

Issue History

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