View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000700 | FSSCP | gameplay | public | 2006-01-10 19:08 | 2006-01-19 04:10 |
| Reporter | thesource2 | Assigned To | phreak | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000700: Turret destroyed submodel is not restored after repair | ||||
| Description | If turret is destroyed and then repair-subsystem (or set-subsystem-strngth) is called for it, it begins to function again but displays the destroyed submodel | ||||
| Tags | No tags attached. | ||||
|
|
Its been like this since retail. There are a few options to fixing this 1) Automatically do this no matter what 2) Have a mission flag toggle this behavior 3) Create another sexp to change the destroyed state of a submodel. 4) Something any FRED gurus think of. |
|
|
I vote for 1). If you repair a turret, it fires just like before. IMO the model should match the behavior. edited on: 01-13-06 23:32 |
|
|
Well, will this be fixed? |
|
|
I would prefer that, yes. But be patient... we need to have our discussion first. :p |
|
|
I'd go with a second SEXP. Whether you want the destroyed model back or not is going to be very dependant on how the ship was modelled, which sort of rules out a mission flag if you're going to be using it on several ships. There are some ships where the repair looks fine but there are others which involve a 50m turret suddenly appearing out of nowhere and that's always going to look bad. Seeing as how we're only ever going to see this happen when a FREDder has decided to repair a subsystem that was previously destroyed this is a situation that is only going to arise by the choice of the mission designer so I say give him the choice in what the turret does too. |
|
|
I just thought of another idea. We could add an optional parameter to repair-subsystem and/or set-subsystem-strength to change the destroyed state of a submodel eg -repair-subsystem --GTD Bastion --Turret01a --100 --[true] (this parameter is will repair the submodel if true and is optional, so it won't interfere with previous uses. Defaults to false) edited on: 01-16-06 15:22 |
|
|
Phreak's suggestion would be my second choice. But honestly, how often would we *not* want the subsystem reappearing if it was repaired? Consider a problem I had with one of my early FS1 missions. I wanted to make sure the rotating solar panel would stay operational, and I got incredibly frustrated when the submodel refused to reappear despite its hull strength remaining positive. |
|
|
For once I'm with Goober on a backwards compatibility issue. Make it default to show the submodel again, but make the SEXP mod just in case. Having the subsystem appear looks like a game limitation, having it fire while looking destroyed looks like a bug. |
|
|
i think all you need to add is this little snippet of code at the end of sexp_repair_subsystem() and sexp_set_subsystem_strength(). Also it seems if you use sabotage-subsystem, the submodel won't blow off. Need to look through the code there. if (ss->current_hits > 0) { ss->submodel_info_1.blown_off = 0; ss->submodel_info_2.blown_off = 0; } |
|
|
My fix works, we just want to decide how to trigger that fix. |
|
|
I say go with phreak's suggestion of editing the repair-subsystem SEXP but default to making the undamaged turret reappear. I do like the idea of having engines buckle when destroyed but allowing a ship to limp out with them looking less than brand spanking new. |
|
|
"I say go with phreak's suggestion of editing the repair-subsystem SEXP but default to making the undamaged turret reappear." Works for me. |
|
|
k i'll get it done. |
|
|
fixxxed |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-01-10 19:08 | thesource2 | New Issue | |
| 2006-01-13 23:34 | phreak | Note Added: 0004254 | |
| 2006-01-13 23:34 | phreak | Summary | Turret normal view is not restored after repair => Turret destroyed submodel is not restored after repair |
| 2006-01-13 23:34 | phreak | Description Updated | |
| 2006-01-14 04:32 | Goober5000 | Note Added: 0004261 | |
| 2006-01-14 04:32 | Goober5000 | Note Edited: 0004261 | |
| 2006-01-14 07:48 | thesource2 | Note Added: 0004266 | |
| 2006-01-14 08:16 | Goober5000 | Note Added: 0004267 | |
| 2006-01-16 20:01 | karajorma | Note Added: 0004318 | |
| 2006-01-16 20:21 | phreak | Note Added: 0004319 | |
| 2006-01-16 20:22 | phreak | Note Edited: 0004319 | |
| 2006-01-16 23:12 | Goober5000 | Note Added: 0004330 | |
| 2006-01-17 17:21 | WMCoolmon | Note Added: 0004351 | |
| 2006-01-18 00:36 | phreak | Note Added: 0004361 | |
| 2006-01-19 00:58 | phreak | Note Added: 0004390 | |
| 2006-01-19 00:58 | phreak | Status | new => assigned |
| 2006-01-19 00:58 | phreak | Assigned To | => phreak |
| 2006-01-19 00:59 | phreak | Category | graphics => gameplay |
| 2006-01-19 01:11 | karajorma | Note Added: 0004391 | |
| 2006-01-19 01:22 | Goober5000 | Note Added: 0004392 | |
| 2006-01-19 02:14 | phreak | Note Added: 0004394 | |
| 2006-01-19 04:10 | phreak | Status | assigned => resolved |
| 2006-01-19 04:10 | phreak | Resolution | open => fixed |
| 2006-01-19 04:10 | phreak | Note Added: 0004399 |
