Jump to content

Sign in to follow this  
Petraeus

Version 2.1 OOM and possible memory leak.

Recommended Posts

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:


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556

Interests: Gauge Programming - 3d Modeling for Milviz

Share this post


Link to post

 

 


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

 

Not under strict type checking!  :D  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 Hookins

 

Oh! I have slipped the surly bonds of Earth
And danced the skies on laughter-silvered wings;

Share this post


Link to post

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:


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556

Interests: Gauge Programming - 3d Modeling for Milviz

Share this post


Link to post
Guest

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

Share this post


Link to post

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.


Regards,

Brian Doney

Share this post


Link to post
Guest

 

 


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.

Share this post


Link to post

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.

 


Regards,

Brian Doney

Share this post


Link to post

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.

 


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556

Interests: Gauge Programming - 3d Modeling for Milviz

Share this post


Link to post
Guest

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.

Share this post


Link to post

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:


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556

Interests: Gauge Programming - 3d Modeling for Milviz

Share this post


Link to post
Guest

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

Share this post


Link to post

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:


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556

Interests: Gauge Programming - 3d Modeling for Milviz

Share this post


Link to post

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


 
 
 
 
v63vq9-5.png

Share this post


Link to post

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.


Petraeus

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
  • Donation Goals

    AVSIM's 2020 Fundraising Goal

    Donate to our annual general fundraising goal. This donation keeps our doors open and providing you service 24 x 7 x 365. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. We reset this goal every new year for the following year's goal.


    31%
    $7,965.00 of $25,000.00 Donate Now
×
×
  • Create New...