 |
@Springheel: If you decide you want LOD disabling for AI with a new model, just assign me the issue. I can't think of any other way but you know the setup much better than I do. Disabling it in the game gode would be trivial -- AI already have the "no_lod" spawnarg which sets an on/off switch for LOD. |
 |
I think that's the way to go. It won't be a performance issue since very few AI will be affected. The only issue I'll have to double-check is to make sure that all the old "model" spawnargs still refer to an actual modelDef. If not we can always add a legacy version. |
|
|
I'm not sure what that means. Am I ok to go ahead and suppress LOD if there's a "model" spawnarg, or shall I wait for confirmation from you? If there's an extra condition to check, let me know. |
|
|
"Am I ok to go ahead and suppress LOD if there's a "model" spawnarg" Yep. |
|
|
The rule: If the mapper overrides the "model" spawnarg but doesn't override any "model_lod" spawnargs, we disable LOD on the entity. If the mapper overrides at least one "model_lod" spawnarg too, that shows they have it in hand so we don't disable LOD on the entity. That should fix maps with a changed model, without the mapper having to do anything, while still letting Biker have a builder archer with LOD if he wants to add the extra LOD models too. |
|
|
Tried to wikify this info, but the wiki is read only?? I'll query it in the forum |
|
|
Committed at rev 6170 Entity.cpp That's just the code. I'll do new binaries later when I've commited soft particles. |
 |
The solution doesn't handle the case where a func_static has no default model in its entityDef. For example, this causes func_statics that only use a 'hide_distance' (like weather patches) to stop working. |
|
|
The fix above was to allow LOD models to be added to existing AI without breaking maps where the mapper had overridden the default model. We don't want Builder archers who're based on a City Guard archer with model and vocals overriden, to turn back into a city guard when the player gets further away. So LOD gets disabled where the default model is overridden, unless the mapper has specified LOD models too. Fixed by checking whether LOD was inherited before disabling it. We don't need to disable it where it wasn't set up in the first place. That was in fact the original plan. I've been able to leave my original comment in place unamended: // Disable LOD if the LOD settings came with the entity def but the mapper has overridden the model // without updating any LOD models # 3912 But the code checked only for the overriden model. It omitted to check whether LOD had been inherited :-/ |
|
|
at rev 6522 game/Entity.cpp |
|
|
In the attached test map, all 4 guards in the line are TDM 2.03 Builder guards with 3 LOD stages. The 1st guard on the left has default spawnargs, = 3 active LOD stages. Guard 2 has his default model changed to City Guard, but no LOD models specified. LOD should be disabled on him. Guard 3 has his default model and his most distant model changed to City Guard, but LOD stage 2 is ignored. He should change to a Builder at medium distances. Guard 4 has a non-existent LOD stage 4 model override. There's no LOD stage 4, but that setting should be enough to stop LOD being disabled, and to make him change back to a Builder at all but close distances. Further down the line, the floating carpet square should rain on you when you stand under it. A weather particle with hide_distance only set. Last up, when you get into the corner beyond the line up, another chunk of floating carpet should appear. A FS with hide_distance only set. |
- Anonymous
