FS2004 aircraft mdl export

[arno]

A new development release will be online in about 30 minutes. It has the fix for the nose gear animation and also a fix for the issue with the props when exporting from FSX models.

I was able to reproduce the issue with navigating through the objects as well. When the preview is still loading textures it will ignore a request to load the next object. So in that case the title bar and other editors can end up with a newer object, while the preview is still stuck with the previous one. Let me think how I can make that more robust.

 

[tgibson]

Thanks, I’ll check it out soon. Happy New Years Eve.

As I’ve been making these conversions I was wondering if MCX displays the sim the object was compiled to? For example, when I need a P3D model in FSX, how can I know that it is not already an FSX object being used in P3D?

Thanks,

 

[arno]

Hi Tom,

MCX does not display that at the moment. I guess I could show the source format it was loaded from. But as soon as people start to make changes or export it that information is kind of obsolete of course.

 

[tgibson]

Hi Tom,

Maybe a stupid question, but I am trying to look at those missing prop feather mouse rectangles when converting the Electra to FS2004. But which button in the cockpit is that so I can check what happens to them?

They are the 4 red buttons on the overhead:

EDIT: now seems OK in the latest MCX release.

 

[tgibson]

Test 1: FS9 DC-6B to FSX
Same as before, exterior model collapsed, interior model OK.

Test 2: FS9 DC-6 to FSX
Looks perfect to me, the nose gear steering is just right. Prop pitch and water rudder are fine too.

Test 3:
FSX DC-6B to FSX
Exterior model - the animated parts are collapsed.
Interior - looks and animates fine.

Test 4: FSX DC-6 to FSX
Exterior and interior models look and animate fine.

Test 5: FSX Electra to FSX
Exterior and interior models look and animate fine.

Test 6. FSX Electra to FS9 (interior model is simplified to allow FS9 compile).
First load of the day of FS9 and the converted FS9 Electra crashed the sim - not unexpected.
FS9 was set to load into the VC model and that crashed FS9 on the second and third load as well.
On the next load I switched to a different plane and loaded that VC. Then switched to the Electra and the VC loaded fine.

The exterior model seems fine. The landing lights are too bright - ini file. The cabin windows are much dimmer than in FSX. Are there night lighting options in FS9 like Additive and Multiply Blend? They don't seem to do anything when I change them in MCX - they are FS2004 choices in the Material Editor.

In the interior model the 4 prop feather buttons now all work and have the correct tooltip. The gauges are very dark at night, I think I will have to create night textures for the gauge maps, there are none in FSX and I don't know how the VC gauges are lit in that sim.
The VC has no landing or taxi light splashes.
In the interior model these 4 rotary switches in the left hand side of the VC overhead do not have mouse rectangles - they do in the original FSX model. Otherwise fine. BTW, only two of the rocker switches below these have mouse rectangles in the original model, same in the FS9 conversion.

Test 7: FS9 Electra back to FS9
Exterior - The prop blades of engine #1 wobble instead of rotate (rotation, not pitch).
Interior - seems unchanged from original conversion.

 

[tgibson]

Test 8: FSX Cessna 1972 to FS9
Prop animation in the VC is correct.
Nose wheel steering is correct in MCX and in the sim.
This model loaded into FS9 just fine.

Test 9: FSX Awesome DC-3 to FS9.
Prop animation in the VC is correct when viewed in MCX.
I loaded the FS9 converted model into FS9, after converting the DDS textures to DXT3. I got this error message immediately after loading the plane:

Problem signature:
Problem Event Name: APPCRASH
Application Name: fs9.exe
Application Version: 9.1.0.40901
Application Timestamp: 4135a208
Fault Module Name: SIM1.dll
Fault Module Version: 9.0.0.30612
Fault Module Timestamp: 3ee946b8
Exception Code: c0000005
Exception Offset: 00017110
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033
Additional Information 1: 402a
Additional Information 2: 402ae66697f3c7c252f2b62e81016a2c
Additional Information 3: 6a56
Additional Information 4: 6a564d47c9d9dc4d34a2666d02875f6d

I then loaded another plane first, and then switched to the DC-3. I got the same error even before loading had finished.

This model has only 27347 triangles, so it is way under the limit.

 

[arno]

They are the 4 red buttons on the overhead:
EDIT: now seems OK in the latest MCX release.

OK, I'll leave the issue open for a while, let me know if you see similar issues again in the future. But I won't

Thanks for the detailed testing again, I'm happy to see that you did not found too many issues. Some of the issues you reported are into still on my bug list:

• Animations collapsed to center (have not yet been able to reproduce this) - https://gitlab.com/scenerydesign.org/astofra/-/issues/6362
• Animation wobble after exporting to FS2004 again - https://gitlab.com/scenerydesign.org/astofra/-/issues/6428
• Light issues (no lights in VC and some lights read wrong from Electra model) - https://gitlab.com/scenerydesign.org/astofra/-/issues/6407
• Visibility conditions not read correctly (reported by @gsnde some models have the prop visibility conditions mixed up) - https://gitlab.com/scenerydesign.org/astofra/-/issues/6426

The landing lights are too bright - ini file.

Do you have a good suggestion for a better value? Then I will modify the default value in the INI file.

Are there night lighting options in FS9 like Additive and Multiply Blend? They don't seem to do anything when I change them in MCX - they are FS2004 choices in the Material Editor.

No, there are not. They are only listed in the FS2004 choice now because those values determine if the emissive textures get written as a lightmap or a nightmap. If I remember correctly you can modify the emissive color value in FS2004 and it should blend that with the texture, but I am not 100% sure.

In the interior model these 4 rotary switches in the left hand side of the VC overhead do not have mouse rectangles - they do in the original FSX model. Otherwise fine. BTW, only two of the rocker switches below these have mouse rectangles in the original model, same in the FS9 conversion.

OK, I'll check if I can find anything on these.

Test 9: FSX Awesome DC-3 to FS9.
Prop animation in the VC is correct when viewed in MCX.
I loaded the FS9 converted model into FS9, after converting the DDS textures to DXT3. I got this error message immediately after loading the plane:

This model has only 27347 triangles, so it is way under the limit.

Maybe the error is not coming from the vertex limit, but from something else in the model then. But the error message of FS2004 does not really tell us much.

 

[arno]

Hi Tom,

I checked those mouse rectangles. It seems that MakeMDL does not like to export mouse rectangles that have no animation on the part and some of those switches you pointed at have no animation assigned. Let me check if I'm exporting them wrong or if it is a limitation of MakeMDL.

As for the rocker switches, I see all of them have mouse rectangles in FSX (they are all default types). Two of them (switch_fasten_belts and switch_no_smoking) don't seem to be supported when exporting to FS2004. I guess FS2004 might not know these events or tooltips.

 

[tgibson]

• Animations collapsed to center (have not yet been able to reproduce this) - https://gitlab.com/scenerydesign.org/astofra/-/issues/6362

I looked at this in more detail, since our results are different.
First I looked at XtoMDL. I had been using the P3D v1.4 SDK XtoMDL, and thought you might be using a different one. I switched to the FSX SP2 SDK XtoMDL, but it made no difference.
Next I thought it might be my FSX SP2 version that is displaying the model incorrectly (since it looks fine in MCX). So I loaded the collapsed model into P3D v4.5, but it is still collapsed there.
Another difference could be our Windows OS - I am still using Windows 7.
Very confusing...

Do you have a good suggestion for a better value? Then I will modify the default value in the INI file.

I am currently using 50,50,50 which works well, but perhaps I should find a value that matches that displayed in FSX. This might vary with the aircraft though, since I believe they are customizable even when creating FSX models in GMAX or 3DSMax, I assume?

No, there are not. They are only listed in the FS2004 choice now because those values determine if the emissive textures get written as a lightmap or a nightmap. If I remember correctly you can modify the emissive color value in FS2004 and it should blend that with the texture, but I am not 100% sure.

I will look into this further, but texture repainting might be the only solution.

Maybe the error is not coming from the vertex limit, but from something else in the model then. But the error message of FS2004 does not really tell us much.

Yes, this could be a tough one...

 

[tgibson]

I have been thinking about the display/model folder mismatch and was thinking you have (at least) three options:
1. Inactivate. The slowest but perhaps the clearest to the user, and probably easy to code: The green arrows are inactivated and turn gray whenever the display is not finalized. Then when the user presses a green arrow the arrows turn gray until the display is finished. Once the title bar has updated, the arrows turn green again. This method can keep the title bar display change at the end as it is now, since the user cannot do anything until the arrows turn green again.
2. Remember. The middle one for speed but perhaps confusing: MCX remembers each arrow press but allows it to begin only after the previous display load is complete. If the user presses the arrow buttons several times this could lead to several rounds of texture loading. It would be best for the title bar to update at the beginning of each load, not at the end.
3. Interrupt. The fastest one, but probably the hardest to code: When the user presses a green arrow, the new model file path is immediately displayed in the title bar and the current texture load process is stopped. The new texture load begins immediately. The user could interrupt this texture load by pressing an arrow button again.

I'm sure there are other choices too.

Hope this helps,

 

[arno]

Hi Tom,

I looked at this in more detail, since our results are different.
First I looked at XtoMDL. I had been using the P3D v1.4 SDK XtoMDL, and thought you might be using a different one. I switched to the FSX SP2 SDK XtoMDL, but it made no difference.
Next I thought it might be my FSX SP2 version that is displaying the model incorrectly (since it looks fine in MCX). So I loaded the collapsed model into P3D v4.5, but it is still collapsed there.
Another difference could be our Windows OS - I am still using Windows 7.
Very confusing...

Maybe you can send me your MDL file that is collapsed? Hopefully if I compare it with the one I have generated here I get a clue what is different (and then hopefully also what might cause it).
I also use the P3D v1.4 XtoMDL most of the time btw. And the FSX version I have installed is the Steam Edition.

I am currently using 50,50,50 which works well, but perhaps I should find a value that matches that displayed in FSX. This might vary with the aircraft though, since I believe they are customizable even when creating FSX models in GMAX or 3DSMax, I assume?

I don't think you can customize them in a FSX model, since they link to a FX file. Unless you make different versions of that file of course.
The fx_landing.fx file seems to use a color of 55, 52, 50. So that is quite close to the values you use now.

I have been thinking about the display/model folder mismatch and was thinking you have (at least) three options:
1. Inactivate. The slowest but perhaps the clearest to the user, and probably easy to code: The green arrows are inactivated and turn gray whenever the display is not finalized. Then when the user presses a green arrow the arrows turn gray until the display is finished. Once the title bar has updated, the arrows turn green again. This method can keep the title bar display change at the end as it is now, since the user cannot do anything until the arrows turn green again.
2. Remember. The middle one for speed but perhaps confusing: MCX remembers each arrow press but allows it to begin only after the previous display load is complete. If the user presses the arrow buttons several times this could lead to several rounds of texture loading. It would be best for the title bar to update at the beginning of each load, not at the end.
3. Interrupt. The fastest one, but probably the hardest to code: When the user presses a green arrow, the new model file path is immediately displayed in the title bar and the current texture load process is stopped. The new texture load begins immediately. The user could interrupt this texture load by pressing an arrow button again.

Thanks for the ideas. I did try option 2 yesterday already and that was still not very robust. Option 3 would be quite hard to implement. The way I have setup MCX is that once the object loader finishes loading an object it raises an event to notify anybody interesting that there is a new object available. When you press that arrow button a similar event is raised to inform that a new object is activated. But everybody subscribed to the event handles it on their own. So for example the preview will get the event and load all the textures that are needed to render it. But an open editor, like the material and hierarchy editor, will also get the event and update their information based on it. And the main form will also get the event and updates its title. All of these activities happen at the same time and I don't really know when they are finished. Usually updating the preview takes the longest.
Maybe option 1 would be the easiest way to make it robust. Then I would need to add a new event whereby the preview can report to others that it is done with updating and thus that new updates are accepted. I'll have a look at that.

 

[arno]

I would just use those values then, so they look the same as FSX.

OK, will do.

EDIT: Probably not a problem.

One thing I notice about the collapsed DC-6B in the Hierarchy Editor is that most (not all) of the parts that are displaced do not have a parent SceneGraphNode, but begin the chain with the ModelPart itself. That said, the planes I converted to FSX using previous versions of MCX have much the same structure with plenty of those arrangements and they load just fine.

Back then I did see this effect with the FS9 DC-6B when I made changes to the model and then exported it to FSX, so I exported it after each small change. This made the collapse less likely. If the collapse happened, often (but not always) I could import the collapsed model and export it again to fix the issue.

I have seen that more often that modelparts are nested under modelparts. So that does not really worry me.

Still investigating the collapse.

I have found one significant difference between the FSX DC-6B I converted from the FS9 model earlier and the one converted now. The parts are being duplicated in the conversion.

The c_gear parts we can use as an example, but many (all?) other parts show this behavior.
In the model I converted earlier the Hierarchy editor (searching for c_gear) lists 1 SceneGraphNode (SGN) and 10 Model Parts (MP). That's top to bottom in the listing.
In the model I converted today there are 10 MP, then 2 SGN, and then 10 MP.

What's more, the second SGN does *not* light up anything red when Highlight Selected is checked. If you then get the full listing back, that SGN is the parent part to a lot of SGN and MP. None of them light up red in the model (I used wireframe view for this because for some reason the solid views now only show red from certain angles of the plane). They are phantom parts. Deleting them changes nothing in the visual model.

It looks like every part may be duplicated. I removed every phantom part I could find, and got the props rotating and the nose gear appearing in its proper down position, but that's about it. The rest was still collapsed (including the still prop blades). When I remove all the phantom parts, the MDL size goes from 3043 KB to 1501 KB. I accidentally removed the left aileron in this process, so that may account for it not being exactly half. The model I created earlier is 1531 KB.

I think you are onto something here. When I do a conversion of the exterior FS2004 model to FSX I get a MDL file that is 1529 kB in size. Why yours is about double is quite weird. But I guess it is somehow related indeed.

 

[arno]

Perhaps there is a difference in our MCX settings? I’m not sure how to explore that?

I can't think of a setting that would double the MDL in size. But I indeed suspect there must be a setting or so that affects this.
Can you keep the X file and send that to me as well? Hopefully that gives some clues.

 

[gsnde]

To make sure the same settings are used you have to delete the settings in %appdata% and then only change the paths to the FS9 SDK.

Thats the setup I am using now.

From mobile hence short

 

[arno]

Yes, that's also the basic setup I use. I run with the default values, except of course for the MakeMDL and MakeMDL.parts.xml paths, as these have to be set manually.

 

[arno]

Hi Tom,

I have been checking that MakeMDL error with the Electra VC. It's quite weird, when I compile the X file of the Electra VC as interior model I get about 4000 vertices more than when I compile the same X file as external model. So it seems that for a VC MakeMDL adds extra vertices somehow. But that would mean we would need to use a lower limit for the VC probably. Unless I can figure out why MakeMDL adds those extra vertices

 

[tgibson]

Hi again,

I don’t think it’s a setting. Because:

I checked the size of the DC-6 conversion which animates correctly and it is 1534 KB, almost the same as the 1533 KB model I converted using previous versions of MCX. Thus it appears this doubling occurs only when the plane is collapsed in the sim. Whether it is the cause of the collapse or just occurs at the same time (hopefully due to the same root cause) remains to be seen.

 

[tgibson]

That vertices issue could indeed be why at a certain size MCX lets me compile but MakeMDL gives me 2071 errors.

 

[tgibson]

I am so embarrassed. I'm so sorry for putting all of us through this wild goose chase (American idiom meaning looking for something useless), but this is all my doing.

In November I decided to try to fix a problem I had been having with parts of the maintenance stairs at the cockpit door becoming displaced when converting between sims. Turns out those parts have an undefined animation - keyframes but no valid FS animation tag. So in GMAX I removed the animation keyframes and reset Transform and Scale. This appeared to fix the problem in FS9, but I didn't notice that GMAX/MakeMDL had doubled the size of the FS9 plane! Thus when converted to FSX, it became double the size as well. MCX is only trying to cope with a very damaged model.

When I reverted to a previous model of normal size, conversion to FSX resulted in a 1529 KB file, the correct size. AND, the animated parts are not collapsed in FSX, so all is fine.

So we can all go on with our day now, nothing to see here...

Again, so sorry for the trouble.

 

[tgibson]

And I figured out why the model is doubled - GMAX created two aircraft, LOD 100 and LOD 200. I did not change any part names and none have LOD in the name, so I have no idea why GMAX did that.