Update modeldef scripts in an already compiled MDL

[JB3DG]

Hi Arno

I have a bit of a challenge. We lost the modeldef for our T-38 ADV at Milviz a while back and there are some visibility scripts that I need to fix. Is there any way I can change them without having to recompile the MDL? Or at least, export a modeldef and a set of X files with the renamed modeldef tag names from MCX and then recompile with XtoMDL?

 

[arno]

Hi,

MCX tries to reconstruct the file on import. So you could use that as basis. It's not easy to update the mdl without compiling. So best you can do is save as X file and go from there. I would have to check if that also saves the modeldef.xml file automatically.

 

[JB3DG]

Thanks. If it will save the modeldef along with the X file that would be great.

 

[arno]

I just checked the code, it's only the MDL exporter that saves the ModelDef file. So you need to export as MDL. If in the option you select the option for the X file to be kept the modeldef.xml will also remain.

 

[JB3DG]

Will it put out an xanim file as well?

 

[arno]

Yep.

 

[Heretic]

Copying the content from the modeldef viewer also works.

 

[n4gix]

I've previously used MCX to 'recover' a missing modeldef.xml file, but it was a bit of a pain to reconstruct it into the "normal" format....

I'm simply grateful that I was able to reconstruct it at all and can cast no blame on anyone but myself for having "lost" the original in the first place!

 

[arno]

If you have tips to make the output more normal, I might be able to improve the xml generation. Inside the mdl the information is stored quite different.

 

[Heretic]

If you have tips to make the output more normal, I might be able to improve the xml generation. Inside the mdl the information is stored quite different.

The "custom_" prefix can be done away with, because a "Mouserect_", "Visibility_" or "Animation_" prefix is enough to distinguish it from the default modeldef entries.
Name generation seems to be done by taking a certain number of charcters from the involved code or simvars at the moment. It would be great if this could be changed to include either the part number or at least a sequential number. E.g. "visibility_part98_01" or "mouserect_01".
Grouping the tags by part would also be helpful. E.g. "animation_part272", "mouserect_part272", "anim_part273", "vis_part273", etc.
Even better would be combining all applicable tags into a single <PartInfo> entry, just as for the default entries. Name generation could involve the part data type with the part number at the first position, e.g. "Part135_Animation_Visibility".

 

[arno]

I'll have a look.

You mean combine animation, visibility conditions and mouse rectangle in one? Unfortunately in the mdl they are not grouped, so I'm not sure how easy that's todo.

For the name I now use the variable indeed. At the point of reading the mdl I don't know yet to which part number they will apply. Could even be more than one.

 

[Heretic]

You mean combine animation, visibility conditions and mouse rectangle in one? Unfortunately in the mdl they are not grouped, so I'm not sure how easy that's todo.

<Partinfo> and <Name> are always the same. The actual properties are set within the <Animation>, <Visibility> and <Mouserect> tags.

This is an example for a combined animation and visbility tag:

<PartInfo>
<Name>A32x_N1_R_Slow</Name>
<Copy>prop_anim</Copy>
<AnimLength>100</AnimLength>
<Visibility>
<Parameter>
<Code>
...
</Code>
</Parameter>
</Visibility>
<Animation>
<Parameter>
<Code>
...
</Code>
</Parameter>
</Animation>
</PartInfo>

The same applies to animation and mouserect tags. Or mouserect and visibility tags.

For the name I now use the variable indeed. At the point of reading the mdl I don't know yet to which part number they will apply. Could even be more than one.

How does the Hierarchy or Animation Editors determine which animation, visibility and mouserect tag apply to what part?

If it's from the PartData(?) tag in the .x file, maybe you could make the importer collect all the associated XML tags first, track to which parts they apply and finally combine them if applicable for modeldef generation.

This might be a bit complex to implement though.