View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000559 | FSSCP | mediaVP | public | 2005-09-19 03:51 | 2005-09-20 21:16 |
| Reporter | CP5670 | Assigned To | taylor | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000559: Ares thrusters are missing | ||||
| Description | The Ares has no visible thrusters in the game. This appears to be an issue with the high poly Ares model in the media VPs. | ||||
| Tags | No tags attached. | ||||
|
|
Damnit, I'm the last one to touch that model aren't I. I'll look in to it. |
|
2005-09-19 06:10
|
|
|
|
Ok, so I think I know what should be causing the problem. Since engine glows are now properly tied to subsystems, the Ares seemingly fell through the cracks when the V special cases were done. Its engine glowbank was not assigned any subsystem, so the subsystem they were tied to did not exist and so the thruster tails were never rendered. However, on assigning them to the correct engine system, the glows still fail to render. So it looks like there is a special case in there for it, but it's misfiring and never rendering instead of always rendering. I've attached a "fixed" file as far as the media goes; the rest of the problem apparently lies in code. |
|
|
The original and the one in the previous MediaVPs (or at least what I have) work ok. The new one doesn't but it doesn't even get far enough to fall through a crack in the modified engine glow code. The glowbank doesn't actually have to be assigned to a subsystem to render btw. I haven't done anything but take a quick look with a hexeditor but there doesn't appear to be anything marked as a thruster in the POF. The glows will only be rendered on a subsystem marked as a thruster. |
|
|
I'm not quite sure what you're refering to taylor, as I cannot find anywhere in the POF spec that indicates that subsystems should be marked as thrusters in the POF data. The way I've always understood it is that any subsystem starting with the phrase "engine" was considered an engine subsystem, and that subsystem is present. If it weren't the ship would not be able to move. The spec calls for a FUEL section that delimits thruster banks, which is also present in both the offending model and the original, in more or less the same form. EDIT: If you're refering to physical subobjects named "thrusterX", those are not there intentionally. That object is the geometry-based scaling thruster that's inherited from FS1; it was ditched on the Ares because the new tails cover them up anyway. It should not need to be there for the thruster glows to appear. And I have several fighters that work just fine without them (not to mention each and every capital ship in existance) so that shouldn't have anything to do with this problem. And I don't mean to be too sure of what I'm saying, but I do have a more complete understanding of the POF spec than most modelers. edited on: 09-19-05 14:36 |
|
|
I deffinitely don't really understand the modeling aspect of things so this is a bit difficult for me to explain. In the code though it specifically looks for "thruster" in the name of a subobject and if it's there marks it as a thruster. If it's not marked as a thruster then it will never render the glows. |
|
|
I can provide specific examples of many, many places where this is not the case though. I probably should clarify though that the problem is not the thruster subobjects; I along with a number of other modders have stopped using those because they scale incorrectly and are covered up by the trails most of the time anyway. Unfortunately, FS2 uses "thruster" in two places to describe two different things (hence the really confusing terminology), one being the "thruster" subobjects and the other being the thruster banks (FUEL chunk). The problem is that the trails themselves (FUEL chunk) don't show up. The Ares model indeed has no thruster subobjects, by design. |
|
|
Here is the code: in modelread.cpp: if ( strstr( pm->submodel[n].name, "thruster") ) pm->submodel[n].is_thruster=1; in modelinterp.cpp (when it gets rendered): if (pm->submodel[mn].is_thruster ) { if ( !(Interp_flags & MR_SHOW_THRUSTERS) ){ return; } Interp_thrust_scale_subobj=1; } If "Interp_thrust_scale_subobj" is not 1 then it will not render *any* thruster graphics. EDIT: Little too bland of a reponse. :) Anything specified in the FUEL chuck is slaved to the is_thruster variable when it comes to rendering. If is_thruster isn't set then it skips all rendering of what FUEL says. This really is just a terminology thing, probably something that we need to fix at a later time. edited on: 09-19-05 15:30 |
|
2005-09-19 19:34
|
|
|
|
See that's what I thought you were saying, but that nullifies pretty much every model out there EXCEPT for :v: fighters. How do capital ships work? They don't have thruster subobjects. Why does the file I just uploaded work? It's identical to the Ares in just about every way as far as internal POF format goes but it's got proper thruster glows without any subobject named "thruster". I don't mind fixing the model if that's the problem; the issue is I can't find any evidence that the function you posted is reflected in any other model that I've tested. EDIT: And I can read code, so I'm actually glad you posted the function. edited on: 09-19-05 15:38 |
|
|
Ha! I knew this smelled of a hack! Ok, so the catch is, the glows simply aren't rendering FOR THE ARES. If I take a custom mod and replace its POF with this bonus2t-02.pof, the glows appear as in the attached pic. If I replace the Ares POF with one of my models without thruster subobjects in the main table, the glows on my custom ships dissapear. In fact, the FUEL chunk does not render on ANY pof I assign to the Ares, regardless of whether it has that thruster object. Try replacing it with the Herc II (fighter2t-02.pof); while you see the physical models, the glows are still absent. |
|
2005-09-19 20:14
|
|
|
|
Hmm, yeah your right. Checking the code again... (it's a messy bunch of crap) You know POF so if I'm not explaining this right let me know (I'm a bit confused at this point). The thruster glows will render even if it's not is_thruster. The thruster animation which the other models used (which don't have glows) will only render if is_thruster. For bonus2t-02.pof the thruster animation bitmap is set, the glow bitmaps are not. There is something funny going on here though since it should load the glows but isn't. They are invalid for some reason... Ahh! Are you testing it as your player ship with no other Ares in the mission? Add an Ares as another ship and see if it renders then. Edit: Didn't reload before posting, sorry. I added another Ares in the same test mission and all Ares has glows. It would only not render on the player ship if another Ares didn't exist in the mission. There is a loading bug somewhere that I'm looking for, nothing wrong with the model. Edit2: Nope, it's just if I select a different ship in shipselect and that ship happens to be Ares does it cause a problem. If the Ares is the default player ship then it displays fine. edited on: 09-19-05 17:00 |
|
|
Ok, the "if player selected, non default, only one in mission" case is now fixed. The first model you posted has worked fine in all other cases though. |
|
2005-09-19 21:18
|
|
|
|
It's actually more general than that. I just tested it; if the mission does not contain an Ares by default, the glows do not render. It matters not who flies the ship (player/non-player) nor how many of them are in mission. And this actually applies to any ship, not just the Ares. EDIT: I see you found/fixed a potential case, I just want to make sure that it's the right case for all instances that I've seen :) edited on: 09-19-05 17:20 |
|
|
Yeah the case I caught handles it in any case that the Ares isn't in the mission by default. The includes the ship getting assigned to any wingman or even when changed by a sexp during a mission (all done in the same function, fixed by one line of code). If there is any other case then I'm not sure about it so let me know. |
|
|
As long as it's not somehow specific to the Ares, that should cover it. I'll test it as soon as I get a build with it in there. |
|
|
StratComm: That could well be it. I noticed this issue in a campaign mission as well as one of my own, but in both cases I selected the Ares for myself and some wingmen over the default ships. I just assumed it had something to do with the Ares model since there were no thruster submodels visible when I opened it in Modelview. The funny thing is that I can't remember ever noticing this for any other ship in the 8/28 version, which I did all my testing in. Is this something new that has come up in 3.6.7? Perhaps I was just seeing the standard thruster subobjects on almost everything else and thought everything was normal. I've gotten too used to retail FS2 over the years. :p |
|
|
I think this bug has been there for quite a while and it's certainly not Ares specific. Not sure why it's never been reported (or noticed?) before though. |
|
|
Me either. I assume it's because of a combination between all stock fighters having the modeled cones which are visible anyway and that the Ares, which is the first distributed retail fighter to not have them, is not by default something anyone would want to use most of the time anyway (when Erinyes are available, it's a downgrade). But you're right, I can reproduce this as far back in builds as I can go before the builds start throwing errors on tables that use new features. |
|
|
Fix is in CVS now but I'll wait to resolved this until I hear that it's working for everyone. Check the next available build and let me know. |
|
|
Works for me in all cases that I was testing the other day. |
|
|
Fixered. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-09-19 03:51 | CP5670 | New Issue | |
| 2005-09-19 04:52 | WMCoolmon | Status | new => assigned |
| 2005-09-19 04:52 | WMCoolmon | Assigned To | => WMCoolmon |
| 2005-09-19 05:16 | StratComm | Note Added: 0003423 | |
| 2005-09-19 06:10 | StratComm | File Added: bonus2t-02.pof | |
| 2005-09-19 06:13 | StratComm | Note Added: 0003424 | |
| 2005-09-19 07:49 | taylor | Note Added: 0003425 | |
| 2005-09-19 18:27 | StratComm | Note Added: 0003427 | |
| 2005-09-19 18:32 | StratComm | Note Edited: 0003427 | |
| 2005-09-19 18:34 | StratComm | Note Edited: 0003427 | |
| 2005-09-19 18:36 | StratComm | Note Edited: 0003427 | |
| 2005-09-19 18:56 | taylor | Note Added: 0003428 | |
| 2005-09-19 19:11 | StratComm | Note Added: 0003429 | |
| 2005-09-19 19:24 | taylor | Note Added: 0003430 | |
| 2005-09-19 19:30 | taylor | Note Edited: 0003430 | |
| 2005-09-19 19:34 | StratComm | File Added: fighterSC-02.POF | |
| 2005-09-19 19:36 | StratComm | Note Added: 0003431 | |
| 2005-09-19 19:37 | StratComm | Note Edited: 0003431 | |
| 2005-09-19 19:38 | StratComm | Note Edited: 0003431 | |
| 2005-09-19 20:14 | StratComm | Note Added: 0003436 | |
| 2005-09-19 20:14 | StratComm | File Added: ares_correct2.jpg | |
| 2005-09-19 20:51 | taylor | Note Added: 0003437 | |
| 2005-09-19 20:54 | taylor | Note Edited: 0003437 | |
| 2005-09-19 21:00 | taylor | Note Edited: 0003437 | |
| 2005-09-19 21:16 | taylor | Note Added: 0003438 | |
| 2005-09-19 21:16 | taylor | Assigned To | WMCoolmon => taylor |
| 2005-09-19 21:18 | StratComm | File Added: aresTest.fs2 | |
| 2005-09-19 21:19 | StratComm | Note Added: 0003439 | |
| 2005-09-19 21:19 | StratComm | Note Edited: 0003439 | |
| 2005-09-19 21:20 | StratComm | Note Edited: 0003439 | |
| 2005-09-19 21:23 | taylor | Note Added: 0003440 | |
| 2005-09-19 21:31 | StratComm | Note Added: 0003441 | |
| 2005-09-19 22:22 | CP5670 | Note Added: 0003442 | |
| 2005-09-19 22:28 | taylor | Note Added: 0003443 | |
| 2005-09-19 22:32 | StratComm | Note Added: 0003444 | |
| 2005-09-20 02:07 | taylor | Note Added: 0003445 | |
| 2005-09-20 21:00 | StratComm | Note Added: 0003446 | |
| 2005-09-20 21:16 | taylor | Status | assigned => resolved |
| 2005-09-20 21:16 | taylor | Resolution | open => fixed |
| 2005-09-20 21:16 | taylor | Note Added: 0003447 |