Ah, found your problem!  FUEL CROSS FEED is not a bool, it's an enum, 0 or 1.  Apparently that couldn't be converted to a bool by explicitly specifying it with ",bool)" and that's what threw the error.

Oh Larry, that was simply an example chosen at random. That actually does work without any errors, despite what the SDK states. Any 'enum' with only two possible value states is by usage a boolean...  :Whistle:

 

Oddly enough though, as far as the XML parser is concerned, there's absolutely no distinction made between a "bool", an "enum" or a "number..."

 

For that matter -and this has been tested- I could have used 'fred' or 'ginger' as the unit and it still works!  :LMAO:

 

 

Any 'enum' with only two possible value states is by usage a boolean...

 

Not under strict type checking!    I guess it wasn't as strict as we thought.

 

You can't automatically assume that an enum will equal the number specified in every environment.  Same goes for pretty much everything else... we've been spoiled by C, I think.  For example, under Apple Pascal, True was defined specifically as 1, false as -1.  Just because the enum is either 0 or 1 in this case doesn't mean it's correct;  that's how we got into this situation in the first place.  Ah, the joys of script languages. 

 

Hook

Larry, more to the point, ACES themselves insisted most vehemently that the only guaranteed return for any variable is zero, even with declared boolean unit type...

 

I know this is true because there are a scarce handful for which the non-zero return is -1...  :wacko:

I don't know the SDK, but I do know XML and I'm pretty sure an enumerated type will evaluate to an integer not a boolean (regardless of the number of defined values).

 

Under W3C XML spec states that a program should stop processing XML if it finds an error.  Where I've run into XML issues is that I don't define a value 0 enumeration (or all the possible assignable values) ... sometimes an unexpected (think the impossible) situation that returns False/0 but because I haven't enumerated the value 0, I'll get an error even though it a valid integer.

 

Not suggesting this is the issue, just tossing out ideas to think about.

 

But what has me really curious is why would one compile XML into an model file - to try to obfuscate it a little?  Isn't that defeating the intended purpose of using XML?

 

Rob

Many custom animations are written in XML, and are compiled with the model. 

 

For many things, I'm not sure there is any other way.

 

 

For many things, I'm not sure there is any other way.

 

You'll have to forgive my ignorance of the SDK here ... I don't know, is there?  In my world I use XML for data structures and XAML for building GUI's (including animations) that get compiled into DLLs and deployed.

I'll leave it to Bill to set things straight, but no I don't think there is.

 

Even all stock animations are scripted in modeldef.xml from the SDK.

 

Pretty sure that's just how it's done now, but I only know just enough to know I don't know much at all  :lol:

 

EDIT: Let me save him from having to repeat himself, by linking and quoting a post of his  :lol:

 

 

 

When we "export" the Max/GMax scene, the export module will parse the modeldef.xml file and create two separate files: the modelname.x and modelname.xanim files. The first contains the vertices and material/texture information, the latter contains some animation information that was taken from the modeldef.xml file.

 

When we "compile" the modelname.x file using the supplied xtomdl.exe program, we pass the name of the modelname.xanim file at the same time, along with the full path to the modeldef.xml file. The "compiler" will take the data from the .xanim file and parse the modeldef.xml file once again to incorporate the actual "XML script" into the .mdl file.

 

I don't know the SDK, but I do know XML and I'm pretty sure an enumerated type will evaluate to an integer not a boolean (regardless of the number of defined values).

I refer you to Reply #269 where Wes listed the valid tokens to represent TRUE or FALSE, which include the integers 1 and 0. Keep in mind also that MS/ACES have themselves created a "mutant" form of XML specifically for the sim, which may or may not comply with the W3C specifications. One example of which is that on finding an "error" it will simply skip subsequent lines until the "error" is passed, and valid XML script resumes.

 

Now what I meant when referring to the insistence of only zero being "guaranteed" as a valid return, consider these two examples:

 

(A:SomeVariable,unit) 1 == if{ do someting }
versus
(A:SomeVariable,unit) 0 != if{ do something }

Logically, both are functionally identical. The first one however will only ever return TRUE if the variable's value is the integer "1"... which may or may not ever occur. It's (pardon the pun) rather "iffy*."

 

The second variant however will always work because it's looking for any non-zero number in order to return a TRUE result!

 

*Nota bene: the reason it's "iffy" is simply because within the XML domain, all variables are treated as floats, not integers!

But what has me really curious is why would one compile XML into an model file - to try to obfuscate it a little? Isn't that defeating the intended purpose of using XML?

Rob, as mentioned by Brian, XML is the only method by which the sim can "communicate" with the 3d model. XML is used to send sim token variables to 3d gauge "needles" and "switches" et cetera.

 

Likewise, mouse events that are attached to 3d objects will send the XML "commands" back to the sim.

 

Thanks for the explanation gents ... Bill, I can see why LM wanted to clean this up then, but sounds like it'll be a pain for many 3rd party content providers.

 

IMHO, 0 and not 0 should always represent Boolean logic ... 'True', 'False', 'Yes', 'No', etc.etc. just adds conditional logic and slows things down.

Rob, I was still editing when you replied. Look at the "Nota bene" I added to explain the precise reason why only zero is a guaranteed valid value...  :LMAO:

Floats?!   So this must XML-ACE protocol ... hehehe

Floats?!   So this must XML-ACE protocol ... hehehe

Which is precisely why I stated that the "unit" type requested is with few exceptions essentially meaningless. The type specifers "bool", "enum", "number", "fred" or "ginger" will all work equivalently.

 

The exceptions occur when one wishes the sim to refactor the returned value(s) as "feet", "meters", "feet per second", et cetera. These are math conversion unit specifiers that will be recognized. A full list of the various forms for these are in the SDK of course.  :ph34r:

I had an oom tonight same area as always that gives a massive chunk of vas. Using orbx lc usa and Canada.

 

It's definitely an issue that north east corner of Canada

Wow, this is a blast from the past.

 

This was a memory leak, in P3DV2, that I reported on three years ago.

 

Things have nosed on since then, so i suspect that your problem may be something else.