View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002195 | FSSCP | gameplay | public | 2010-04-30 06:09 | 2010-05-26 14:28 |
| Reporter | Goober5000 | Assigned To | Goober5000 | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Target Version | 3.6.12 | Fixed in Version | 3.6.12 | ||
| Summary | 0002195: Subsystem names are destroyed during the course of a mission | ||||
| Description | In TVWP mission 11, the Reliant's communications system will not register for any events. When the mission is restarted, the parser will complain that "communications" is no longer a valid subsystem for that ship. | ||||
| Additional Information | This occurs because hud_targetbox_truncate_subsys_name operates on the string passed into it, which is supposed to be a temporary buffer. However, in ship_return_orders in ship.cpp, in the AI_GOAL_DESTROY_SUBSYSTEM case, this function operates on the subystem name directly, thus ruining it. (There is also another place this happens, in hud_show_damage_popup in hud.cpp.) This was brought to the forefront in Wanderer's commit 5290 on 5/21/2009 by switching from "name" to "subobj_name". (The hud.cpp still uses "name", which may be why it wasn't detected there.) I fixed the issue by formatting a temporary string rather than the permanent string. | ||||
| Tags | No tags attached. | ||||
|
|
Reminder sent to: Wanderer Notifying Wanderer in case he wants to comment on the difference between name and subobj_name. |
|
|
This is fixed in revision 6081. I'll leave it open until Wanderer comments. |
|
|
I'm starting to wonder if this could be related to the elusive 0001951 If the model has already been loaded once and it was hit buy this bug could it cause the crash when it tries to load it again? |
|
|
The time frame fits, but it doesn't appear to be a subsystem bug. |
|
|
Reminder sent to: Wanderer Wanderer, can you comment on the difference between name and subobj_name? |
|
|
For model_subsystem name and subobj_name... Its been a while since i last time tried to use my brains over these.. subobj_name: internal 'true' name of the subsystem - the one from the model data (actually matches with polymodel data submodel names) name: either a copy of the 'subobj_name' or then the name modder assigned for the submodel in submodel properties. Reading from the code it seems to be assumed (if not guaranteed) that only one submodel can have a specific 'subobj_name'. There does not seem to be any guarantees that multiple subsystems could not share a same 'name' though. I sorta considered it as 'alternate subsystem name'. |
|
|
Okay, makes sense. That's kinda what I assumed anyway. Marking as fixed. :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-04-30 06:09 | Goober5000 | New Issue | |
| 2010-04-30 06:09 | Goober5000 | Status | new => assigned |
| 2010-04-30 06:09 | Goober5000 | Assigned To | => Goober5000 |
| 2010-04-30 06:25 | Goober5000 | Note Added: 0011917 | |
| 2010-04-30 06:32 | Goober5000 | Note Added: 0011918 | |
| 2010-04-30 06:32 | Goober5000 | Fixed in Version | => 3.6.12 |
| 2010-05-01 20:39 | FUBAR-BDHR | Note Added: 0011921 | |
| 2010-05-02 05:59 | Goober5000 | Note Added: 0011924 | |
| 2010-05-09 06:59 | Goober5000 | Note Added: 0011947 | |
| 2010-05-26 12:09 | Wanderer | Note Added: 0012007 | |
| 2010-05-26 14:28 | Goober5000 | Note Added: 0012008 | |
| 2010-05-26 14:28 | Goober5000 | Status | assigned => resolved |
| 2010-05-26 14:28 | Goober5000 | Resolution | open => fixed |
