bugfix: Hide visible bones from damaged China Emperor Overlord model

[Stubbjax]

Summary

This change fixes several issues with the damaged China Emperor Overlord model:

• Three cube meshes are visible where invisible bones are meant to be
• The inbuilt Speaker Tower uses the pristine texture
• The wrong barrel recoils when firing a shot
• Smoke can only emanate from 2 smoke bones instead of the originally intended 6

This is quite a poor setup to anyone with a keen eye. It's not overly conspicuous, but once you see it, you can't unsee it.

Details

The following changes were applied:

• Replaced the three cube meshes (SMOKE06, SMOKE07 and SMOKE08) with corresponding smoke bones
• Replaced the pristine Speaker Tower texture with the damaged Speaker Tower texture (NVOvrlrd_U → NVOvrlrd_UD)
• Swapped the barrel names so that the correct barrel recoils when firing (BARREL01 → BARREL02 and BARREL02 → BARREL01)
• Renamed the 6 smoke bones to a consecutive order so that the TransitionDamageFX can find them (only SMOKE01 and SMOKE02 were originally found as SMOKE03 did not exist)
• Moved applicable bones to the correct transform hierarchy (SMOKE01 was outside CHASSIS01)
• Added a new SPEAKERFX01 bone to support spawning the Propaganda effects from the actual Speaker Tower

Note

Particle systems defined in the TransitionDamageFX module do not respect animated bones. The only way to achieve this is by defining the bones in the Draw module and specifying ParticlesAttachedToAnimatedBones = YES. This however conflicts with the effects defined in the TransitionDamageFX module and thus forgoes the ability to randomly spawn a limited number of systems from a range of bones.

Engine changes will also be required to spawn Propaganda effects from a bone.

Testing

Before

After

[xezon]

I suggest link to the Patch1 changes so that they can be easily cross referenced on review.

[xezon]

There needs to be a TheSuperHackers comment explaining this, because it is not intuitive at all.

[Stubbjax]

Compared to other HideSubObject or ShowSubObject cases, this does indeed seem to be an unorthodox solution and more of a workaround than a proper fix.

Upon looking at the model itself, it clearly contains superfluous bone meshes. It would be preferable to simply delete the bone meshes - they already exist as bones anyway. I've tested this and the outcome is identical.

The cannon bones are also reversed to the cannon meshes, so the left cannon recoils when the right fires and vice versa. Do we want to fix both issues in this PR?

[xezon]

The HideSubObject solution is for making the fix work without changing models.

[xezon]

Still needs doc.

[Stubbjax]

The HideSubObject solution is for making the fix work without changing models.

Correct. The better solution is to update the model.

[Stubbjax]

I have fixed the model; I can push it here?

[xezon]

Did you use the Blender Plugin? If yes, keep in mind Blender Plugin is destructive and not safe.

[Stubbjax]

I can also do it with Max. What is destructive about the Blender plugin? I've not encountered any issues so far.

[xezon]

I think last time I used it was 2022 or 23. Maybe things were improved and fixed by then. There were bugs where importing and exporting some models would destroy their texture mappings.

It would be also good to get the plain text model format, so that we can review and revision model edits in text. We have not finished work for that yet. Bobtista did some LLM generated prototypes in GeneralsGameCode but it did not materialize.

I think first step is implementing a w3d to plain text tool and engine support, and then make use of that for the Blender Plugin as well.

[Stubbjax]

There were bugs where importing and exporting some models would destroy their texture mappings.

Did you document these bugs anywhere? I would like to reproduce them to understand what's going on. Were they always conspicuous? Any such bugs surely wouldn't make it past the development / testing phase.

If anything, I've found Max to be more destructive in that transform exports and texture blend modes are always lost on import, which has been a known issue for as long as I can remember.

I think first step is implementing a w3d to plain text tool and engine support, and then make use of that for the Blender Plugin as well.

I've not historically found plain-text model/prefab diffs to be very useful other than for catching very basic things like object renames or for resolving merge conflicts on those exceptionally rare occasions when an asset is worked on by more than one developer.

Besides, wouldn't this approach only be viable for subsequent model iterations and not the initial transition from binary to plain-text? Would such transitions need to be separately reviewed (somehow) to ensure the transition is lossless? I can't imagine there being many (if any) cases where a model edit is reviewed by reading the data and not via direct comparison in modelling software (or even using wdump) along with in-game testing, regardless.

Will this first step be required before we can do any model changes?

[Stubbjax]

I suggest link to the Patch1 changes so that they can be easily cross referenced on review.

I link each change to the Patch Migration Project upon creation.