FSX Meaning of Variable 33B?

[Mick_S]

Hi,

when converting / editing models in MCX, I frequently have to confirm a variable "33B" with a value of 0 after opening. The variables name "33B" seems to be independent from the model, since it's the same for many models (always "33B" and always a value of 0 to confirm on MCX import). The following happens

• In MCX (window title) the name of the object gets changed to "[genuine_name]00" (i.e. suffix)
• Editing and exporting of the model works fine without any errors. But, when re-importing the edited model into MCX, the variables-dialoque doesn't show up anymore. It seems the variable has been stripped out from MCX?

What does this variable stand for, and how can I preserve it in the model? There's no visible difference in the models, but since I have no idea what the variable serves for, I just don't know what (effect?) I miss.

Thank you for sharing your insights,
Mick

 

[=rk=]

Have you tried selecting "1" for the variable? It is a reasonable test if you consider the variable to be a switch; switches are either on or off - which sounds binary and there is only one other state from zero in binary.
In FS2004 and earlier, virtual cockpits are a separate model. You can confirm this by looking in the model folder. The variable 33B dialog only appears when importing models with separate VC's, select 1 as the variable and you will see the VC instead of the exterior model. Presumably you exported the model to FSX format, which does not allow separate VC models and so it would not present the 33B dialog upon import.

 

[Mick_S]

Hello rk, thank you for your response. As suggested, I tried to put "1" for the variable and found that the MCX window title still has the '00' suffix after the objects name.

if you consider the variable to be a switch

I don't have any idea if it's a switch or not. It might as well be something like "C2FA100" to set any effect parameters (which was my first assumption).

The VC information is interesting, but in this case it's not possible to be the reason since I work on a building (edit crash boxes of some "FSX Helipack" clinics). You presumed correct that I'm exporting to FSX format, so – if 33B isn't needed/used in FSX - the behavior to not present the dialog on re-import would make sense. But, as mentioned above, after setting the variable different (after initial import) I don't "... see the VC instead" – actually I don't see any recognizable difference.

I tried different values for the variable:

• C1A00F (just as any example of hex values) results in MCX reporting "invalid value for variable", the dialog stays open
  
• any integer > 4000 results in MCX reading the object file, but reporting "No objects found in file"
• any integer <= 4000 shows the object in MCX without noticeable difference

Thank you again,
Mick

 

[GaryGB]

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


IIRC, 33B reportedly refers to "distance from aircraft to scenery in meters"and is a legacy conditional display parameter for scenery objects (or portions of same) often used to implement "LOD"-related visibility separate from the V1 / V2 paramaters < Arno, please correct me on this if I'm mistaken >, as well as for distance related functions with other types of legacy-coded FS objects.


BTW: 4,000 Meters = 2.159827 Nautical Miles; perhaps this is a FS limit for object visibility comparable to LOD-controlled display ...through yet another mechanism ?


Also, I believe it would be helpful to distinguish between the terminology used for "interior" and "exterior" MDLs in FSX native aircraft and the "virtual cockpit" in FS9.

http://www.fsdeveloper.com/forum/threads/feature-request-view-export-fs9-aircraft-mdl-vc.435492/

https://www.google.com/#q=FS9+virtual+cockpit+MDL


Hope this helps !

GaryGB

 

[Mick_S]

Thank you for the link, Gary. Arno put a question mark, but the variable seems to be "033B - distance from aircraft to scenery / in meters (?)". This sounds like it's supposed to be an aircraft variable, I would conclude that it's nothing relevant for the model, i.e. no problem if it's not preserved? But why is it in the original model at all then???

I made a test, putting different values (0, 100 and 3500) and saving the scenery and testing it in FSX then (one after the other). There's again no difference, even when setting the variable to 100 the model is visible from several km away. I have to admit that I still don't understand.

 

[GaryGB]

Perhaps Rick or Arno might be able to correlate use of this variable with MDL Hierarchy for 3D Geometry when a copy of the original MDL source (not yet exported by MCX) is examined within MCX ?

 

[Mick_S]

Yes, I think that's some background they might be able to clear up. means "wait a bit", right ? Thank you though...

 

[GaryGB]

Got an example MDL that MCX prompts for a 33B value with, (including textures) ...that you could attach or link to ?

 

[Mick_S]

Thank you for further investigating my issue... I attached the original scenery file (only bgl, from Helipack FSX) together with the textures. Due to the permitted upload size, I had to split the texture folder into 2 parts. BTW: There are 5 textures missing, not only here but also in the original Helipack FSX and even after re-installation.

I did NOT send it as mdl, since this would be a result from MCX already (only bgls available in Helipack FSX). So you should see the variables dialog after import to MCX.

EDIT: The variables thread you linked is from 2004, so it's quite likely that it's related to FS9 only ... FSX isn't mentioned there at all. In addition, I checked the FSUIPC offsets for FS9 as well as for FSX, but both don't have an offset "33B".

 

[=rk=]

I tried to find an example of my own and all I can find are models that call the "gen_model" variable. It is also a switch, the default value is 2, it applies to models with VC's integrated into the main model. If the value is set below 2, the VC opens, if the value is 2 or above the exterior model opens. You can test this on the freeware Alphasim SU-47 Berkut for FS2004. I can't confirm my 33B variable statement so I'll have to apologize for any confusion.

 

[GaryGB]

Indeed, the 'original' source 3D model you attached above is a FS9 format MDL.


It is also possible that MCX sets a 'fixed' On / OFF display state of True or False / Visible or not-Visible into the routine it will utilize for importing and rendering that 3D model based on your submitted value at the 33B prompt.

Perhaps the option for a MDL to be controlled by FS run-time input of the rendering engine applied to that 33B variable value may not be possible in FSX exports from MCX either due to how MCX itself structured the exported FSX format MDL, or use of that particular variable may have been one of the many (...READ: 'most' but AFAIK, NOT 'all' ) conditional display options removed from the FSX MDL format by ACES in favor of file size, performance, and external control solely (...or 'mostly' ? ) via SimConnect or other 3rd party modules / gauges.

GaryGB

 

[arno]

Hi,

The 33B variable is not only for aircraft. It is a way to switch elements of a scenery object on or off based on distance. So this can be used for a kind of LOD, but also for special effects like a docking system that shows a different symbol as you approach.

When importing in MCX you are asked for a value for the variable and then MCX will render the object as it would look at that distance. So if the elements under the switch show depends on the distance you enter.

 

[Mick_S]

Indeed, the 'original' source MDL you attached above is a FS9 format 3D model.

How did you find that out? Or put in another way: How would I recognize that from the bgl? As mentioned before, it's distributed in "Helipack X" (wich lacks some nice scenery available in FS9, so that I assumed the "rest" would be FSX format).

Regarding the "possible" and "may"/"may not" in your explanation: It makes sense to me, but I have the feeling it would still make sense to call out for HELP of Arno and Rick ...

 

[Mick_S]

Hi Arno,

your message popped up just after I clicked mine to be posted You're faster than "The Flash" as it seems

Thank you for clearing 33B up, I think I understand. Pls correct me if wrong: For my kind of small edits (crash boxes) it's ok then to put any valid value, right?

Just for my further understanding:

• Where do these values go when I export the FSX-Version (re-import doesn't show the prompt) of the model?
• And what does it mean that MCX puts a "00" suffix to the models name?

 

[arno]

Hi,

MCX can't export this kind of conditional display of the object. So it will always export at the state that you selected during import with the values you entered.

So if you have an object that shows some extra detail when you get close, but you enter a bigger value on import. On export this extra detail will be lost as well. So will loose special conditional effects when editing your MDL with MCX.

 

[GaryGB]

How did you find that out? Or put in another way: How would I recognize that from the bgl? As mentioned before, it's distributed in "Helipack X" (wich lacks some nice scenery available in FS9, so that I assumed the "rest" would be FSX format).

You could open the BGL in Windows NotePad (I use QuickView Plus file viewer); the FS SDK compiler version is seen in:

"MakeMDL - FS90 (9.00.030612.02)"

’8   @
Ošü™Ê                                  +         L             \   Æ2 ±Eö£EÕX/½‰š®Ñï€   ®2 RIFF¦2 MDL9MDLH$               È           ˜   FS80       ISFT    MakeMDL - FS90 (9.00.030612.02) BBOX   ´H‰Â33SÀmôÂœdCš™ÚAÃ5CCRAS   – þÇ ° ø y €H‰Â0SÀ môÂÇHCÚò´B#¶‡C ( ( ( I y y   þþ  þþþþþþþþþ    þþþþþ

FYI:

FS7 = FS2000

FS8 = FS2002

FS9 = FS2004

FS10 = FSX


BTW:

One can never be completely certain of what code type 'lurks' inside FS BGLs; IMHO it is best to "view' the file to see if a FS SDK version and compiler can be identified before attempting to open it in a SDK or 3rd party utility.

Regarding the "possible" and "may"/"may not" in your explanation: It makes sense to me, but I have the feeling it would still make sense to call out for HELP of Arno and Rick ...

The "possible" and "may"/"may not" in my explanation might be viewed by some as "Social Engineering" in an attempt to 'encourage answers' from individuals likely to know the answer, and AFAIK, are either too busy, and/or are 'keeping their cards close to their chest' ...that might otherwise not have participated in a thread.

Alternatively, my reply might be viewed by some as "Social Engineering" in an attempt to 'discourage answers' from individuals who "may or may not" be likely to know the answer, and AFAIK, are either NOT too busy, and/or are NOT 'keeping their cards close to their chest' ...that might otherwise have participated in a thread.


Hope this helps a bit more !

GaryGB

 

[Mick_S]

OK, I learn from your reaction that it's not an important thing - from professional designers point of view that's something And it's good to know I don't "destroy" anything inside the model.
Thank you again, and have a nice weekend

EDIT:
Gary, your post just came up, so I take the chance to thank you again. It DID help!