View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001802 | FSSCP | models | public | 2008-10-20 20:57 | 2008-12-21 19:44 |
| Reporter | Goober5000 | Assigned To | Wanderer | ||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0001802: Subsystem fixup problem when using modular tables | ||||
| Description | In the FSPort, the Orions all use their own ship models like so: $Name: GTD Orion#Intrepid $POF file: capital01-intrepid.pof Per taylor's recommendation, I've added texture replacements to each mission that the modified Orions appear in. I've also added a modular table so that they all use the same model like so: $Name: GTD Orion#Intrepid +nocreate $POF file: capital01.pof This is supposed to save memory by not needlessly loading multiple models when all that changes is one texture. However, running a debug build of FSO reveals a strange bug in ship_page_in(). I can't really follow the subsystem code, but it looks like ship_copy_subsystem_fixup wasn't run properly, or at all. | ||||
| Additional Information | Warning: Ship 'GTD Orion#Intrepid' does not have subsystem 'ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌturret01a' linked into the model file, 'capital01.pof'. File: Ship.cpp Line: 15645 Call stack: ------------------------------------------------------------------ level_page_in() freespace_mission_load_stuff() game_post_level_init() game_start_mission() game_enter_state() gameseq_set_state() game_process_event() gameseq_process_events() game_main() WinMain() WinMainCRTStartup() kernel32.dll 7c816fd7() ------------------------------------------------------------------ | ||||
| Tags | No tags attached. | ||||
|
2008-10-20 20:57
|
|
|
|
During the course of getting the new MediaVP's out the door, this issue has been noticed along with the Assert issue. (Assert issue currently potentially fixed). However, this issue does not stay with any one model. Even regressing to models which previously cause the message, the error is not always reproduceable. It first (to my experience) happened with the new Iceni model. Apparently it also had assert and collision errors, so the problem was thought to be resolved. I then had it happen with the Argo, Hippocrates and currently the Shivan Comm Node. (Note that none of these have a tbm for replacement of the model). However, when I rename my --debug-filter.cfg to remove the "--" to capture an extensive error report, the problem stops and I cannot reproduce it. Build that I used when events took place: 4894, 4889, 4880, 4874. Additional note: recently, I have noticed that IBX generation is not sticking and does not match what -pofspew delivers. And recently, TSB files are starting to fail being generated. I just checked my drive space at home and all the failure models never had a TSB at the time of failure. Don't know if that is in any way related however. |
|
|
That sort of warning message was supposed to be fixed, I thought. It may be something that was fixed in the Xt tree but that I forgot to commit. I'm not at home right now but I'll check it out when I get back and see if that is indeed the same old bug that I'm remembering. |
|
|
This may not be limited to modular tables. I'm seeing the same sort of error with GTF Loki#stealth and GTF Loki. |
|
|
Errors which are not (and have not yet occured) with the Internal MediaVP's. And if that is VA's Loki model, then it shouldn't be happening to the best of my knowledge. |
|
|
Looking through the Xt tree... I removed the Assert()'s in there for when the subsystems don't match the modelnum, and fixed the warning as well (it should use "subobj_name" rather than "name" to get the actual name). I know that I traced out why it messes up, but I don't see a fix related to that in the diff so I'm guessing that it was just something bogus. |
|
|
If it's bogus, it's a code problem, not a MVP problem. I never use the mediaVPs when I'm testing a mod. This is all happening with retail data, except for the fact that I'm copying a ship entry. EDIT: I changed the warning to use subobj_name. |
|
|
Galemp here. I wanted to note that the previous problem does not appear with recent builds or recent MVPs, so this looks resolved. HOWEVER! The texture still isn't getting replaced. |
|
|
I don't know if this info can be useful somehow... Please check Mantis 0001556. Shivan Comm node had a strange warning exactly equal to your Orion. Here it goes: Warning: Ship 'Shivan Comm Node' does not have subsystem 'ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌcore' linked into the model file, 'Comm2S-01.pof'. File:J:\src\cvs\fs2_open_3_6_9.final\code\ship\Ship.cpp Line: 14678 [This filename points to the location of a file on the computer that built this executable] In the end there wasn't any code problem but a PCS problem and therefore a bad POF file: Properties field wasn't multilined so, in that subsystem properties: $special=subsystem $name=Core was converted to: $special=subsystem$name=Core And, voilà, that caused the warning... PCS needed to be fixed in order to allow building correct models. So maybe it's a bad data issue again. |
|
|
I saw sort of similar issue while testing Diaspora material. It seems that if two ships share a pof file and use modular tables things go quickly and badly wrong. What seems is that both ships - which were tbms - attempted to use the 0th ship_info slot subsystem data. And actually copied that to the ship in question so that table entries wouldn't match any longer. At least that appeared to be the case when using debugger to view the problem spot more closely. Additionally the whole game CTD'd while trying to do following in ship.cpp close to line 15640. Assert( sip->subsystems[j].model_num == sip->model_num ); Where debugger reported that sip->subsystems[j].model_num == -1 EDIT: Correction... the 0th slot ship was actually one it was supposed to reference. Inverted TBM parsing caused the confusion. |
|
|
After some more test on the Diaspora data it appeared that during initial model load the code loaded the models in reverse order (sometimes). That is it first loaded good submodel & subsys data and then while attempting to copy these over to the second ship it actually copied invalid values over the existing valid values resulting in both two ships getting invalid subsystem data. I posted a fix for to trunk. Please comment if it has resolved the issue. |
|
|
It seems to have resolved the issue for modular tables. However, ship copies aren't working. In Playing Judas, for example, neither SD Demon nor SD Demon#scan will have any valid subsystems. |
|
|
Incidentally, I am raising the priority on this bug because if it is still present on Christmas, it will cause at least one ST:R mission to be unplayable. :( |
|
2008-12-21 02:56
|
|
|
|
I've been directed here by Goober, having encountered this or at least a related bug. Hello-- I've found that if the arrival cue is set to 'true' the error doesn't occur and all the subsystems are intact. But anything else in there, even if it means the ships will be there at mission start, and they'll have no subsystems. It only happens if both the retail Fenris and Levi are in the same mission. With the MVP's separated models there's no problem. I've attached the mission I've been using to test it. I hope some of this is helpful. |
|
|
Small clarification: Regarding the arrival cue thing, if ANY Fenris/Levi's arrival is set to true, then all cruisers that arrive afterward will also be fixed. |
|
|
Did some digging and it seems like the diff 4704 was (indirectly) causing this. As a possible solution i changed the ship.cpp line 15624 (r5012) from ship_previously_loaded = j; to if ((sip->n_subsystems > 0) && (sip->subsystems[0].model_num > -1)) { ship_previously_loaded = j; } and it seemed to fix the problem. I haven't yet committed the fix though if there might be more related (or if that would affect adversely) issues hanging around. |
|
|
Hopefully resolved in trunk - if problem persists, reopen. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-10-20 20:57 | Goober5000 | New Issue | |
| 2008-10-20 20:57 | Goober5000 | File Added: fs2_open.log | |
| 2008-10-20 21:08 | Zacam | Note Added: 0010070 | |
| 2008-10-20 21:12 | taylor | Note Added: 0010071 | |
| 2008-10-20 21:12 | Zacam | Note Edited: 0010070 | |
| 2008-10-20 21:42 | Zacam | Note Edited: 0010070 | |
| 2008-10-20 22:38 | Goober5000 | Note Added: 0010072 | |
| 2008-10-20 23:20 | Zacam | Note Added: 0010073 | |
| 2008-10-20 23:20 | Zacam | Note Edited: 0010073 | |
| 2008-10-21 01:06 | taylor | Note Added: 0010074 | |
| 2008-10-21 02:14 | Goober5000 | Note Added: 0010075 | |
| 2008-10-21 02:19 | Goober5000 | Note Edited: 0010075 | |
| 2008-10-21 18:05 | Galemp | Note Added: 0010080 | |
| 2008-10-21 18:31 | ARSPR | Note Added: 0010081 | |
| 2008-10-21 18:35 | ARSPR | Note Edited: 0010081 | |
| 2008-10-21 18:36 | ARSPR | Note Edited: 0010081 | |
| 2008-10-27 06:11 | Wanderer | Note Added: 0010129 | |
| 2008-10-27 06:14 | Wanderer | Note Edited: 0010129 | |
| 2008-10-30 07:55 | Wanderer | Note Edited: 0010129 | |
| 2008-12-19 22:22 | Wanderer | Note Added: 0010440 | |
| 2008-12-19 22:22 | Wanderer | Status | new => assigned |
| 2008-12-19 22:22 | Wanderer | Assigned To | => Wanderer |
| 2008-12-20 19:43 | Goober5000 | Note Added: 0010443 | |
| 2008-12-20 19:45 | Goober5000 | Note Added: 0010444 | |
| 2008-12-20 19:45 | Goober5000 | Priority | normal => immediate |
| 2008-12-21 02:56 | Ransom Arceihn | File Added: subsysdisappear.fs2 | |
| 2008-12-21 02:56 | Ransom Arceihn | Note Added: 0010446 | |
| 2008-12-21 03:05 | Ransom Arceihn | Note Added: 0010447 | |
| 2008-12-21 08:28 | Wanderer | Note Added: 0010452 | |
| 2008-12-21 19:43 | Wanderer | Status | assigned => resolved |
| 2008-12-21 19:43 | Wanderer | Resolution | open => fixed |
| 2008-12-21 19:43 | Wanderer | Note Added: 0010453 |
