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

FSX Hidden Costs of Complexity

FOLLOWUP:


ADDENDUM:
I've tested using the <Visibility> and confirmed that it will reduce the animation count by one for each simple switch that's modified. There are 69 such chrome toggle switches on the overhead alone, so that is a substantial reduction already!

The "Bad News" is that I've got one shed-load of XML to revise now! :yikes:

Cripies!!! I just started thinking about all of that new code to write in the parts list for all of those visibilities.

Also, dont forget, you can only have 1/2 million polygons for the 32bit exporter.


Bill
 
Cripies!!! I just started thinking about all of that new code to write in the parts list for all of those visibilities.

Also, dont forget, you can only have 1/2 million polygons for the 32bit exporter.
Well, all I can say is "Thank God for the invention of copy/paste/edit!" Once the pattern is established, it's not especially difficult to do, but it is very much a "time sink..."

As for the exporting, I'm no where near that limit, but even so I do have the 64bit compiler that Sean wrote that I've confirmed does work, even though it did nothing to help with the "too many animations" problem. ;)
 
Hello,
I didn't read through the whole thread, so I don't know if you've solved your particular issue, but I ran into the same problem with the Coolsky DC-9.
The VC is very close in complexity to what you've posted. I noticed early on that I was having similar issues with objects not being drawn after compiling. I used dummy objects to control animation groups (for lit and non-lit objects), but that produced screen flickering and artifacting. I had also used the various compilers that had been released, but all produced the same result.
Long and short of it, after I finally realized what was causing the flickering, I finally resolved the object draw issues. The solution was to simply parent the objects that weren't being drawn to a center none (in this case, a dummy node sitting at position 0,0,0 called DC9_VC_Interior), which every part in one way or another is associated with.
After about 5 or 6 months of issues, that solved the problem. Everything compiles correctly now. And I did not have to reduce poly or part counts.

Hope this makes sense and maybe can help you out!

Jamal
 
Last edited:
Thanks for the suggestions, Jamal.

No, the problem is still present. What is most frustrating is that yesterday I removed all but 197 animations from the .xanim file, recompiled the .x file, and...

...still have problems! In this specific case, although there weren't any blownup and/or misplaced parts, the mouse areas became unstable, meaning as you pan around the VC the mouse areas would become active/inactive randomly. :eek:

What is even MORE frustrating is that if I compile only the entire VC, despite the 520 animations, everything works!
 
This is one of those really scary stories that you tell when you and your Developer friends talk about, late at night around the camp fire... :S

Reminds me of the FS9 Unlimited Export days... Trying to get everything to work. What a nightmare. One day it exported fine, the next, it was malfunctioning like crasy. 4 days late, back to normal, no problems. 3 weeks later, NOTHING WORKED!!!!!!!! ack! That was grim.




Bill
 
This is one of those really scary stories that you tell when you and your Developer friends talk about, late at night around the camp fire... :S

Bill

Hahaha, if we had a like button this would be an instant click!:D

"Do you know the story of Knight Bill? He was thrown into the deep black SDK pharynx when he challenged the 500 animations gnome and was never seen again!"
 
Last edited:
This is one of those really scary stories that you tell when you and your Developer friends talk about, late at night around the camp fire... :S

Hahahahahahahahahaha! :D



"Do you know the story of Knight Bill? He was thrown into the deep black SDK pharynx when he challenged the 500 animations gnome and was never seen again!"

Don't forget the one about the blue checkered box...*shivers*
 
Thanks for the suggestions, Jamal.

No, the problem is still present. What is most frustrating is that yesterday I removed all but 197 animations from the .xanim file, recompiled the .x file, and...

...still have problems! In this specific case, although there weren't any blownup and/or misplaced parts, the mouse areas became unstable, meaning as you pan around the VC the mouse areas would become active/inactive randomly. :eek:

What is even MORE frustrating is that if I compile only the entire VC, despite the 520 animations, everything works!

Yeah, I ran into the same issues with mouse clicks when I was troubleshooting... somehow I found some kind of happy balance eventually.

Here's a weird thing I had to do with a few parts that just wouldn't compile correctly:

Let's say you have 2 instrument objects, an HSI 100 mile roller digit, on the Pilot and FO panels. Let's say one compiles, but the other doesn't, and no matter what you do, it just won't come up. Even merging and breaking off the one that won't compile doesn't work... try copying and pasting the one that does work, and see if that fixes it. That was the ONLY way I was able to fix quite a number of parts.

I'm not sure if you're having that problem, but if you are, give that a go.
Jamal
 
Yeah, I ran into the same issues with mouse clicks when I was troubleshooting... somehow I found some kind of happy balance eventually.
Mouse points will always work unless there is

1. some mesh object in the way. What I didn't check was to look back from the mouse point towards my eyepoint to see if a rogue polygon had somehow intruded into my line of sight...

...'cause if the normals of such an object were facing forward, it would have been invisible from my eyepoint position!

or

2. The object with the mousepoint assignment has a scale applied. This can be checked by looking at the Dope Sheet for the scene. If the object has anything other than x=100.0 y=100.0 z=100.0 as the Scale, then the mousepoint will fail in the sim.
 
Yeah, I ran into the same issues with mouse clicks when I was troubleshooting... somehow I found some kind of happy balance eventually.

Here's a weird thing I had to do with a few parts that just wouldn't compile correctly:

Let's say you have 2 instrument objects, an HSI 100 mile roller digit, on the Pilot and FO panels. Let's say one compiles, but the other doesn't, and no matter what you do, it just won't come up. Even merging and breaking off the one that won't compile doesn't work... try copying and pasting the one that does work, and see if that fixes it. That was the ONLY way I was able to fix quite a number of parts.

I'm not sure if you're having that problem, but if you are, give that a go.
Jamal

Names.... If names of parts (regular names) in FSX SDK projects are exactly the same, the animation will not work for the duplicated part(s).
 
To bring anyone interested up to date, here are my observations so far...

It wasn't any one thing at all, it is a combination of issues.

One issue is too much texture loading. Reducing the ten 4096^2 exterior model textures has provided some additional headroom. Likewise, some of the seven 2048^2 interior textures have been reduced to 1024^2.

Some of the frivolous (i.e., "eycandy") switches, guards and knobs animations have been removed. Currently the 496 remaining animations are solid, and no visual artifacts or other such weirdness is occurring.

I am going to eliminate the 186 rotating numeric drums however, and replace them with a single gauge and number/symbol sliders either as an XML script or a C gauge. Right now I'm leaning towards a C gauge to further improve performance.

I think if I keep three polys from each of the "drums"; top/middle/bottom and retain the curved surface, it should keep the illusion of a rotation drum intact.

I am also going to be working on further reducing the total tverts by simplifing the outside mesh of the interior model.
 
Success!

SUCCESS! After replacing all 186 of the number drums with gauges, I've managed to compile all three interior models: cargo, combi and pax...

...now I can finally move on with this project! :D
 
Well, I may have hit this 'grim zone' of too many parts being animated. :(

I noticed my auto pilot switches (first to be put in the panel custom animations) no longer animate nor have any mouse-rect effect. I tried redoing the code, nothing. I tried totally new code from scratch with basic working L:var code to 'check' the parts and the animations 'do not' show up in the Attach Tool/MouseRect's nor in the Animation Manager.

what have I done.... :(

Is there a quick way to find out how many animations are on your plane? A file or properties area?
 
Last edited:
As FS treats the VC .MDL file as it is was a single gauge, all of its animation's script sections are probably grouped also in a single, huge script. I didn't make any test on this issue so far, but it is possible that if a "complete" script exceedes ~ 50 Kb problems would start to rise, like in 2D gauges.

Tom
 
Back
Top