View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001645 | FSSCP | gameplay | public | 2008-03-30 04:43 | 2009-07-27 15:55 |
| Reporter | Galemp | Assigned To | chief1983 | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.6.11 | ||||
| Fixed in Version | 3.6.10 | ||||
| Summary | 0001645: Shielded fighters lose shields when unshielded fighter specified in loadout | ||||
| Description | If 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 Information | This 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. | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
Hmm. Maybe it's just a line like +Initial Shield: 0 taking precedence? |
|
|
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. |
|
|
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. |
|
|
Fix appears to work. I'll commit later today and then mark this as resolved. |
|
|
Fixered. |
|
|
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. |
|
|
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. |
|
|
Reminder sent to: taylor If this bug has been smooshed you can close the issue. |
|
|
It's fixed, but I haven't had a chance to commit it yet which is why it's still open. |
|
|
Should be fixed in SVN now. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
Ok, FRED support for the forced shields was added thanks to Karajorma's help, so I'm marking this one completed. |
| 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 |
