• 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.

Probable bug with MCX export

Mick_S

Mick_S

Messages
55
Country
germany
Hi all,
hello Arno,

I guess this one has to be for Arno anyway, so I can take the opportunity to say "thank you" for your enthusiastic dedication and the helpful tools. And btw: I've been a secret admirer of your brains over years, Arno :cool:

Now I'm in the process of converting a old custom FS9 scenery using MCX. Most issues are about missing attached effects, I hope to solve these with the help of reading more from others who experienced that... But I repeatedly stumbled upon probable bugs in the program in the last days, having program crashes or non-working models. So, as a result, I'm very insecure now regarding the details of all my MCX conversions ...

What am I doing: I drag the old (FS) model to the MCX Window, create a new GUID and check "everything" regarding the objects properties (GUID, texture format, LOD etc). Then I export to different formats, one of which should make sense for archiving (and probably editing again in a few years) the models. Using MCX as the neutral basis, and creating different "entities" (FS9, FSX, 3ds, x-file etc.) from MCX, I expect to get fully similar and working models for both worlds as well as an editable model for the archive.

Most conversions seem to be fine. I say "seem to be", because I know only a few possibilities of checking (i.e. opening in MCX again and checking visibility in FSX). And the following makes me insecure about my results:

With some models I run into different bad issues like
  • MCX crashes completely when dragging the conversion result to the window
  • exported files have a size of 0
  • Exported model can't be re-loaded ("Unsupported RIFF section: @?" in the EventLog)
  • Exported model can't be re-loaded (EMPTY EventLog, no error shown)
  • LibraryCreator detects the FSX-Model as FS9 and doesn't want to let me "mix" objects in the library
Which ever of the above is happening: The big question is, WHAT exactly does MCX export for FS9 or FSX? Why is LibraryCreator detecting an FS9 object which has been exported to FSX from MCX? Is something missing in the FSX-model or are there any wrong parameters in some of the models? Mostly it seems I have trouble with models that require / show some variable for "33B"

I zipped some of the files (together with the relevant textures etc) for your examination. It's FS9 versions (working) together with the FSX conversion bringing up issues, some x-files etc (chosen arbitrarily). I hope you can find the error or guide me what I'm doing wrong.

Thank you very much,
regards
Mick
 

Attachments

Hi,

I'll try to have a look at the files.

In general MCX first writes an x file and then compiles that to a mdl for the specific sim. So check for errors in the event log when you have problems with files.
 
Just a small observation here, but it may reveal problems in the converted models as opposed to issues with MCX. The model "BonfireNight - ok.mdl contains an invisible component comprised of 1128 polygons which implies modelling errors to me, it also has a variable condition "33b" that must be set before importing completes. If the model is exported to .3ds and then re-imported into MCX, the attach points and the variable condition are lost and the invisible polygons are incorporated into the main model, however the model exports to FSX format as intended.
 
Thank you, Arno and Rick, for examining.

Maybe the BonfireNight is not representative. It's a burning woodstack which is obviously supposed to have a second object alongside (called "BonfireEffects") that I didn't enclose (it's converting without problems). It's also not the only one using that "33B" variable, and which I have no idea about (there's no visible change in MCX setting the variable to 0 or 100). The more relevant and interesting objects are models I had just exported (from MCX) and ran into these problems trying to re-open them (some with no error log at all, others with "Riff section" errors). Or the exported 0-lenght files. Also, there must be something that makes LCX recognise it as an FS9 Model despite it was a freshly MCX-exported FSX model.

BTW I could solve the attachpoints issue mentioned above. As far as I found out, it seems to be the only way to reuse the attach tool of GMAX again on each and every FS9 attach point? OK, I have no idea what the changes are in that, but this additional conversion might turn out becoming a feature request for MCX :wizard::stirthepo

Have a nice sunday,
Mick
 
I include another custom object to show what I mean. Dragging the mdl to MCX works fine, the x-file is the result of exporting that same model from MCX again.
Opening the x-file makes MCX crash... unfortunately I have no real idea about x-files, so I can't find out what might be put wrong (by MCX?).
 

Attachments

Hello:

Some pertinent links on variable 33B:

http://www.fsdeveloper.com/forum/threads/recent-concerns.428967/

http://www.fsdeveloper.com/forum/threads/mdl-visibility-setting.1910/

http://www.fsdeveloper.com/forum/threads/lods-in-eod-models.293951/

http://www.fsdeveloper.com/forum/threads/variables-available-in-fs.332/

http://www.fsdeveloper.com/forum/threads/fs-variables-definitions-where-to-get.14032/#post-89117

http://www.fsdeveloper.com/wiki/index.php?title=BGLC

ftp://www.digimap.com.au/FSInterface/FSUIPC_SDK/FSUIPC for Programmers.doc

http://www.scasm.de/doc/sca_odds.htm

[EDITED]

PS: One might wonder if there may be a internal analysis performed by MCX that decides at which LODs to 're-attach' Effect (Fx) files ...within "multi-LOD" models imported from legacy (pre-FSX) versions of FS that already have 1 or more Effects 'attached'. :scratchch


If MCX did not < -yet ?- > have such a feature, wouldn't the end user need to manually re-attach (within MCX, prior to export) ...any desired Effect (Fx) files to a ex: FSX model based on their understanding of such HEX variables as (33B) referenced above ? :idea:

[END_EDIT]

Hope this helps ! :)

GaryGB
 
Last edited:
For me the model imports as .x or FSX.mdl properly and exports successfully also. The actual name in the Object Information panel is "GewoFAG_3er_FS9," which has no effect on importing or fs version, it's just a name.
 
@Rick: Did you really import the x-file successfully? I just tried again (after restart etc.) and there's always the attached error message ("emty stack") when trying to import. The mdl is the "working" model (about which I'm insecure coz it's been made from it's FS9 predecessor), the x-file is the MCX-export from that file on my machine (core i7 with Win7-64bit, MCX 1.3.0.0). Can one of the other participants please re-confirm for a third one?

@Gary: Thank you for the links, so I have enough material to dig into that black hole a bit :coffee:

"...wouldn't the end user need to manually re-attach (within MCX, prior to export) ...any desired Effect (Fx) files to a ex: FSX model"
That's exactly what I (partially successful) did or had to do, point by point, with a few of the objects to make the chimneys smoke again... but without understanding 33B :oops:
Partially I have to say because in MCX I added effect parameters (MOY=11,3) to make them smoke from November through March, but it only works for November... all the other months there's no chimney showing that effect (this might a well be another issue or even a known FSX one?)

EDIT: I did some tests with the MOY effect parameter, changing them for 3 chimneys and checking 8 months. It's funny since one chimney (param 2,4) works accurately, another one (param 11,12) shows 1 error (no smoke in December), the third one (param 3,11) shows 2 errors (showing smoke in February and December). Can't figure it out right now, but it seems to have nothing to do with MCX!
 

Attachments

  • x-import-errMsg.jpg
    x-import-errMsg.jpg
    29.4 KB · Views: 351
Last edited:
You should be more accommodating to people who try to help you. I researched your problem and reported my results above. It is troubling that you insist the problem must be with MCX or my procedure, when from my perspective (MCX manipulates the X file fine) the problem is clearly with you or your procedure. I suggest your import settings, or some other parameter, is different from what I use in a way that prevents you importing the X file. Perhaps it is the fact that I use the P3D toolkit, or the developmental release of MCX, version 1.4.000 r2864. That would not be a problem with MCX and my models work relatively excellently in the FSX sceneries that I have created.
Anyway, I did a little more research for you. Gary was kind enough to provide a list of threads regarding the 33b variable. The thread titles imply that 33b is a visibility condition, i.e. 33b causes the model to display shiny textures when it is raining, or glowing textures when it is burning. Next I translated your error message which you reported as "empty stack." The actual phrase is "Der Stapel ist leer," or "the stack is empty." Place the four word text string in the search box at FSDeveloper and some interesting results emerge, here is a quote from a post on one of the hits:
"... (>L:FUEL TANK CENTER2 QUANTITY, number) extracts the stack's topmost value and then assigns that to L:FUEL TANK CENTER2 QUANTITY variable. After this operation, and following vololiberista's code, the stack is empty so the increment ++ operator applies over a 0 value then the result will be always 1."

http://www.fsdeveloper.com/forum/threads/incrementing-var-values.426628/page-2#post-643101
 
Sorry, Rick - I didn't mean to be rude and really do appreciate everyone helping. And you gave me the critical information (at least one of the many :D) I needed: The solution to the x-file-import problems was to use Version 1.4 of MCX (I had the stable release 1.3 installed). After installing that, my formerly problematic x-files are imported into MCX without any problem! So I will go ahead and check the other issues I had (before?)... ;)

I had followed Garys links, too, but haven't studied them yet. I guess your additional information will help understanding it a bit better.

Just to avoid confusion: The error message "the stack is empty" (etc.) didn't have to do with the variables at all. It was the error message that came up when MCX (v1.3) crashed when trying to import the x-file of an object without any variables.
 
You must log in or register to reply here.
Back
Top