• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

A Couple Obscure Issues

G

gadgets

Resource contributor
Messages
9,388
Country
ca-britishcolumbia
Hi, Arno. What did you do to warrant such a "big piece of coal" in your stocking this year? Hopefully fsDeveloper's DN issue will be sorted out soon.

In updating SAMM to be compatible also with P3Dv2, I discovered a couple of MCX-related issues. One is not the fault of MCX and the other may not be. Nonetheless, MCX users may be affected by them so I thought you'd want to be made aware.

Issue 1: MCX won't generate either FSX or P3Dv2 .mdl code for SAMM-converted FS-9 static model of a well-used FS9 AIA model (aia735.zip at Avsim). The static model is rendered properly by FS9. "Listening" to the "Events "channel", MCX seems to start the FSX export process OK but very quickly reports "XToMdl.exe Unhandled Application Exception". If you let it proceed, it also complains about a Guid not being 32 characters - which may simply be a side-effect of the initial problem. I tried another b735 model from AIA with the same result. The SAMM-generated model - Boeing 737-500 (C-FPHS).mdl -is attached.

Issue 2: It appears there is a fundamental problem in FSX when rendering scenery models. That is, any static offset applied to SCEN 0 seems to be applied twice during rendering. (P3Dv2 does not exhibit the same behavior.) I've overcome this in SAMM by only applying half the real static offsets (static_cg_height and static_pitch) to the FSX static model and doubling those values when applied to MCX-created FS9 and P2V static models derived from the FSX static model. Since scenery models seldom have any static offsets applied (at SCEN 0), this is largely a non-issue - other than for SAMM conversions. My reason for raising it now (possibly again) is that when the FSX models (with half the real static offsets) are rendered by the MCX viewer, MCX doesn't double the values like FSX. The model appears in the viewer with the cg at only half the elevation at which it would be shown in FSX. This is simply an observations, and I am reporting it only to make you aware of the situation should it be related to other MCX issues. I was unable to attach a static FSX file (no reason given, too big??)

Incidentally, I've implemented a workaround for the SAMM/MCX issue (related to mouse boxes) I reported in this thread. There were no "mouse box" blocks (neither MREC nor MREI) in that aircraft and SAMM doesn't change the PART blocks, so the issue must be due to the aircraft design.

Happy New year to all,
Don
 

Attachments

Hi Don,

Let me check the exporting error, I guess something in that model must trip xtomdl to fail.

I'll have a look at that offset issue as well. I have never seen this before myself, but in MCX I always make sure that the first scenegraph node is just the unity matrix. I think gmax does the same by default. So I guess that's why I never noticed it.

About the mouse rectangles, weird. I would assume that the original model would give the same crash in MCX then. But since I didn't have that model I couldn't try that, I only had the SAMM version.
 
First, re the mouse rectangles (which was not the subject of the post I referenced but, rather, of a private exchange of e-mails), the static model I sent you was of the stock FSX A321.

Re the offset, please note that P3Dv2 does not exhibit similar behavior. Both P3Dv2 and FS9 apply the offset from SCEN 0 only once - as it should be.

I'd like to send you a static model to demonstrate, but the attachment manager just refuses to send it. I'll try e-mailing it to you. (The problem "mouse-model" likely exhibits the same characteristics, i.e., renders fine in FSX but displays in the MCX viewer with the ground reference plane at mid-strut. The same model will be rendered by P3Dv2 with the wheels below ground.)

Don
 
Hi Don,

I have fixed the export issue now. Somehow xtomdl didn't like the parentheses in the X filename. So I now strip them from the X file (the MDL file will keep the same name). If you grab the new DLL files from the development release tomorrow it should work.

I had a look at the mouse rectangles again, but the last model you send me doesn't have the crash we had before. In that model all the mouse rectangle references are at -1 as expected.

Would it make sense if I add an option to the preview to double the translation of the root node? That would mimic FSX behaviour then, but I don't want to do that as default option.
 
I have fixed the export issue now
Click to expand...
That was fast work. Great!

I had a look at the mouse rectangles again, but the last model you send me doesn't have the crash we had before. In that model all the mouse rectangle references are at -1 as expected.
Click to expand...
While I can't vouch for the original model, (I only received the converted static), I can assure you SAMM doesn't edit the PART blocks and is not even aware of the mouse blocks.

Since SAMM will never copy the mouse blocks, what I can do is always set the PART flag to -1.

Would it make sense if I add an option to the preview to double the translation of the root node? That would mimic FSX behaviour then, but I don't want to do that as default option.
Click to expand...
Don't do anything on my behalf. There's no alternative for SAMM but to address the situation. And, unless you know of other utilities that initialize that transform to other than "identity", it should only happen with SAMM. I just wanted you to be aware of the FSX issue in case it was relevant to other concerns.

Don
 
Hi Don,

We'll just leave the offset as it is then. But I'll remember it in case I read about this problem later on.

I guess the mouse rectangles should also be OK. In the last model you sent they are always -1, so maybe it was some glitch that the earlier model failed. MCX is more robust now and if you never got complaints I guess FSX also has no trouble with it.
 
You must log in or register to reply here.
Back
Top