[FUBAR-BDHR]

I've run into an issue that's had to come up before.  Trying to fix the last of the known errors in TBP I had to redo part of a ship due to bad geometry on some of the debris and LODs.  Figured I'd do it right and get rid of all the extra maps and do the LODs with the subsystems as well.  Previously they were just left off of detail1 2 and 3.  So I have subsystems named Bridge, Turret01, etc.  Now the problem.  If I do LODs of those I now have Bridgea and Turret01a etc.  Of course this doesn't match the tables.  That I can fix.  What I can't fix are all the existing missions that refer to those existing subsystem names.  So if I change turret01 to turret01a and there is an order somewhere in a mission to destroy subsystem turret01 that mission will now crash.  Any know way around this?  Wouldn't be too bad if it was just this ship as I'd just not LOD the subsystems in that case but probably half the TBP ships never had LODs so it's going to become an issue as those are added or if anyone makes a new version with proper LODs. 

[Genghis]

Than definitely looks like a sticky problem...  Can't see it being possible to fix without changing the code to allow different LODs to have subsystems with the same name.

[Aardwolf]

Admittedly not having looked at the relevant code...

changing the code to allow different LODs to have subsystems with the same name.

seems like the optimal solution

[FUBAR-BDHR]

Yea the fun part is while investigating this and solutions it seems a lot of converters made assumptions over the years about LOD names that aren't valid.  Did a quick check of the MediaVPs and there are several models there with invalid LODs and at least 2 different naming systems there.  Of course there is no error checking to catch them so 2 possible things can happen.   They are either skipped and the higher LOD is used or both versions are used so when you get to LOD1 you are actually having more polys rendered for things like turrets.  What actually happens hasn't been figured out yet. 

Basically this one is a huge can of worms that was opened a long time ago and no one noticed. If your model has subsystems that have LODs they better end in a, b, c, d and possibly e (5 LODs are legal but almost never used) or they aren't doing what you think they are. 

Haven't even really got into subobject naming for pieces that aren't subsystems and what happens there.  Have a feeling that isn't going to be pretty either. 

[chief1983]

This bit of modding always seemed like black magic to me, and now I guess I see why.  It _is_ black magic!

[Genghis]

How about this for a solution:  a new extra piece of optional info in the subsystem LOD that says "oh hey, I'm actually the same as xyz in the highest LOD version"

This completely side-steps the naming convention problem, because the LOD in question is telling you explicitly which one it's equivalent to.

[FUBAR-BDHR]

That's basically what we were discussing on IRC the other night.  No idea if it will work though. 

[Wanderer]

How about 'virtually' adding an 'a' to the name of the LOD0 only for the name check purposes if that is 'requested' in the submodel properties

That is assuming the testing for LODs is only done in model parsing that should allow for submodel LODs and still maintain compatibility.

[FUBAR-BDHR]

That was one of the things I considered and do like that route.  Thing I don't know yet is if the LODs are processed in order.   The other issue is where to add the virtual 'a'.  Can't remember it at the moment but I did hit a snag on the logic of just adding it to LOD earlier. 

[FUBAR-BDHR]

Have a solution for this that allows addition of subsystem LODs without breaking backward compatibility with existing tables.  lod_name_compatiblity.patch

To use you just enter $lod0_name=<proper LOD0 name> in the properties for the LOD subobject in PCS2.  Example would be a ship that has turret01 which never had LODs on the original model.  To give it LODs you would just enter $lod0_name=turret01a in properties then follow the naming convention for the other LODs (turret01b, turret01c, etc). 

I've tested this on some TBP models as well as the MediaVP Orion[/ulr] (patch included in file) which had invalid subsystem naming for the radar dishes. 

[FUBAR-BDHR]

 

TBP really needs this one and it's been ages since I posted the patch.

[Goober5000]

And yet none of the coders posted after you posted the patch, so you should have bumped this earlier.

Patch reviewed and committed to trunk.  Although I am somewhat bemused at the bizarre string comparison in the middle of it.

[chief1983]

If there's a bizarre string comparison in there, is that something that happens every frame during gameplay?  That sounds like one of those things that can create a real bottleneck on the engine.

[FUBAR-BDHR]

This whole thing only happens at model load. 

The whole naming scheme is bizarre so it doesn't surprise me.  Pretty much just copied the comparisons that were already there. 

[Goober5000]

If there's a bizarre string comparison in there, is that something that happens every frame during gameplay?  That sounds like one of those things that can create a real bottleneck on the engine.

Only at model load.  Look in the model_load function in modelread.cpp, at line 2532.  The submodel names are compared character by character, and the ndiff variable tracks how many characters they differ by.