-
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.
Dummy/Placeholder animation tags?
- Thread starter Heretic
- Start date
- Messages
- 33,943
- Country
Hi,
I tried to debug some of the reported issues tonight, but I haven't been able to solve them completely. One thing I noticed is that visibility conditions must be set on a modelpart and not on a scenegraph node. When you are adding them manually do you also always set them on a modelpart?
I'll continue to debug tomorrow...
I tried to debug some of the reported issues tonight, but I haven't been able to solve them completely. One thing I noticed is that visibility conditions must be set on a modelpart and not on a scenegraph node. When you are adding them manually do you also always set them on a modelpart?
I'll continue to debug tomorrow...
- Messages
- 144
- Country
Arno, I always add visibility conditions on the model part because they do not work on a node.
tgibson
Resource contributor
- Messages
- 11,630
- Country
When I open the Hierarchy Editor after loading the DC-6, the visibility conditions are listed with the scenegraph node, so that gets things easily confused. See my pictures on page 5 of this thread.
And the problem with the prop_still part I am discussing above is that (due to an apparent bug?) MCX *does not display a ModelPart* in the hierarchy for the prop_still part, only a scenegraph node. Thus I cannot apply a visibility condition to that part (and no, the visibility condition already displayed in the scenegraph node does not work).
Hope this helps,
And the problem with the prop_still part I am discussing above is that (due to an apparent bug?) MCX *does not display a ModelPart* in the hierarchy for the prop_still part, only a scenegraph node. Thus I cannot apply a visibility condition to that part (and no, the visibility condition already displayed in the scenegraph node does not work).
Hope this helps,
- Messages
- 33,943
- Country
I really thought I have seen it working, but guess I need to make sure they are applied to the modelpart in that case. That should fix a lot of the problems.
This also means it will be hard to use the conditions in the FS2004 that don't apply to a specific modelpart but to an entire section of the model.
- Messages
- 33,943
- Country
Tom, I have just made the changes to remember the selected node in hierarchy editor like you suggested. That makes working with the model easier indeed.
Below I have selected prop0_still. As you can see the visibility condition is now on the scenegraphnode. But there are 5 models parts below, would you expect all of them to get that visibility condition? Since they don't work on the scenegraphnode, I guess that's the only way to do it.
- Messages
- 33,943
- Country
I'm pushing a new build now (should be online in 10 minutes or so), that will try to copy down the visibility conditions to the modelparts.
I do still see some visibility conditions are dropped on export. That's something I will look at next (probably some mistake in my code somewhere).
Also the more general IfVarAnd visibility conditions are now pushed down to the modelparts. I'm not sure if that is what we want
. So I'll have another look at that later as well.
I do still see some visibility conditions are dropped on export. That's something I will look at next (probably some mistake in my code somewhere).
Also the more general IfVarAnd visibility conditions are now pushed down to the modelparts. I'm not sure if that is what we want
. So I'll have another look at that later as well.
- Messages
- 144
- Country
I have a problem with today's new build, when I import an FSX model with attached effects which have visibility tags, all those tags are wiped out... Visibility tags on model parts survived the import.
- Messages
- 33,943
- Country
Hi Henk,
Oops, that's a use case I didn't consider indeed. I'll make a fix for it ASAP and also add a test model for this situation.
Oops, that's a use case I didn't consider indeed. I'll make a fix for it ASAP and also add a test model for this situation.
- Messages
- 144
- Country
Arno, thanks for the quick fix, it works for me.
Henk.
Henk.
tgibson
Resource contributor
- Messages
- 11,630
- Country
Hi,
Yes, when you use GMAX to create objects, a child object inherits the visibility condition of the parent. So (for example) the prop blades (which use the lever_prop_pitch animations) should also have a visibility condition of prop_still, since they are linked to the main prop_still part which has a visibility condition of prop_still. For now I am assigning those conditions manually when it's clear from the hierarchy tree they are children of a given part.
Major progress with the new version - nice job. Using the DC-6 MDL, the flaps now animate correctly and I can get the props to animate correctly by assigning the correct visibility conditions to the Model Parts (once I figured out what they all were).
There are major changes in the way the Hierarchy Editor displays the parts, and I'm not sure if that is all OK? First, the order of the parts is completely different in the left panel, but that's not a problem for me. The other change is that for the DC-6 prop parts, instead of there being no Model Part for the main prop_still part (a small cube), now there is no Scenegraph node. And I'm not clear on the Hierarchy tree diagram.
I'll take it step by step. First, here is the hierarchy of the prop2_still part in GMAX:
The main prop2_still part is a small untextured cube, the hole parts are small squares where the prop enters the spinner to create the circular "holes" where the prop blade enters the spinner, and the lever_prop_pitch2 parts are the prop blades, which turn with any change in prop pitch.
I choose the main prop_still part in the Hierarchy Editor.
Note that the part no longer has a Scenegraph node - it's now attached to one of the two main Scenegraph nodes of the aircraft. This main Scenegraph node contains most of the parts of the plane, the other one contains only a few parts. Note that I have already assigned the prop2_still visibility condition to this part - it was originally None.
When I isolate this part, I get this:
This displays the three prop blades which are children of this part, but not the central cube that is actually the parent prop2_still part in GMAX. This is presumably the part I selected in the editor. It also includes the "holes" in the spinner for each prop ((see the little attachment to the lower left prop?), but those hole parts are not listed in the Hierarchy editor, only the prop blades are. There are actually one of these on each prop, but they are one sided and do not appear in this image. The cube is untextured while the prop holes are textured using the DC6B_RTAFT_T texture so the editor is somehow picking that up.
When I select the part displayed just below the three prop blades in the Hierarchy editor, I get this:
When I isolate this part, I get this:
As you can see this is the actual prop_still part, which I have assigned the prop2_still part (originally it was None).
When I select some parts listed some distance below these parts in the Hierarchy Editor listing, I find the hole parts that are not listed as children of the main prop2_still part. They aren't linked to anything in the editor.
So the actual parent of the prop blades in GMAX is not displayed as the parent of the prop blades in the Hierarchy Editor, a phantom part is. the actual prop2_still part is listed separately, as is the hole parts that should be listed as children along with the prop blades.
Confused? I was.
But with all of that said, when I assigned the proper visibility conditions to the various parts as they are displayed in the Editor, the props animated correctly, including the visibility conditions. So it appears that the actual linking of the parts is correct, or that the linking is no longer necessary since each part now has keyframes and the proper animation code assigned (in this case MCX assigned prop2_blurred for all parts). So while the Hierarchy display is confusing (compared to the original GMAX hierarchy), they do end up animating correctly.
BTW, none of the custom visibility conditions are working at this point, but we are making progress. The control surfaces do not move either.
Hope this helps,
Yes, when you use GMAX to create objects, a child object inherits the visibility condition of the parent. So (for example) the prop blades (which use the lever_prop_pitch animations) should also have a visibility condition of prop_still, since they are linked to the main prop_still part which has a visibility condition of prop_still. For now I am assigning those conditions manually when it's clear from the hierarchy tree they are children of a given part.
Major progress with the new version - nice job. Using the DC-6 MDL, the flaps now animate correctly and I can get the props to animate correctly by assigning the correct visibility conditions to the Model Parts (once I figured out what they all were).
There are major changes in the way the Hierarchy Editor displays the parts, and I'm not sure if that is all OK? First, the order of the parts is completely different in the left panel, but that's not a problem for me. The other change is that for the DC-6 prop parts, instead of there being no Model Part for the main prop_still part (a small cube), now there is no Scenegraph node. And I'm not clear on the Hierarchy tree diagram.
I'll take it step by step. First, here is the hierarchy of the prop2_still part in GMAX:
The main prop2_still part is a small untextured cube, the hole parts are small squares where the prop enters the spinner to create the circular "holes" where the prop blade enters the spinner, and the lever_prop_pitch2 parts are the prop blades, which turn with any change in prop pitch.
I choose the main prop_still part in the Hierarchy Editor.
Note that the part no longer has a Scenegraph node - it's now attached to one of the two main Scenegraph nodes of the aircraft. This main Scenegraph node contains most of the parts of the plane, the other one contains only a few parts. Note that I have already assigned the prop2_still visibility condition to this part - it was originally None.
When I isolate this part, I get this:
This displays the three prop blades which are children of this part, but not the central cube that is actually the parent prop2_still part in GMAX. This is presumably the part I selected in the editor. It also includes the "holes" in the spinner for each prop ((see the little attachment to the lower left prop?), but those hole parts are not listed in the Hierarchy editor, only the prop blades are. There are actually one of these on each prop, but they are one sided and do not appear in this image. The cube is untextured while the prop holes are textured using the DC6B_RTAFT_T texture so the editor is somehow picking that up.
When I select the part displayed just below the three prop blades in the Hierarchy editor, I get this:
When I isolate this part, I get this:
As you can see this is the actual prop_still part, which I have assigned the prop2_still part (originally it was None).
When I select some parts listed some distance below these parts in the Hierarchy Editor listing, I find the hole parts that are not listed as children of the main prop2_still part. They aren't linked to anything in the editor.
So the actual parent of the prop blades in GMAX is not displayed as the parent of the prop blades in the Hierarchy Editor, a phantom part is. the actual prop2_still part is listed separately, as is the hole parts that should be listed as children along with the prop blades.
Confused? I was.
But with all of that said, when I assigned the proper visibility conditions to the various parts as they are displayed in the Editor, the props animated correctly, including the visibility conditions. So it appears that the actual linking of the parts is correct, or that the linking is no longer necessary since each part now has keyframes and the proper animation code assigned (in this case MCX assigned prop2_blurred for all parts). So while the Hierarchy display is confusing (compared to the original GMAX hierarchy), they do end up animating correctly.
BTW, none of the custom visibility conditions are working at this point, but we are making progress. The control surfaces do not move either.
Hope this helps,
- Messages
- 783
- Country
With the latest McX developer release (downloaded today), I suddenly have a problem with my NAAI E3A Awacs conversion. Not knowing what visibility parameter to use in my custom modeldef, till now I just deleted the engine covers and wheel chocks. Did a new conversion today, only changed the tires to blurred and spoilers to key, then exported as P3D4. To my surprise McX seemed to have found covers and chocks, as they disappeared at pushback. The thing is the main gear is also invisible, both at standstill and moving. I now also have two usvar values. One I use for the rotating antenna with a custom parameter, the other is unknown. The original visiblity parameter for engine covers & chocks are "custom_vis_light_NAV12". I tried to set these to my custom parameter "custom_part_vis_blocks", but the same result after export; engine covers and chocks working just fine, but no main gear, only the nose gear. The original model uses "custom_vis_06" for gear parts" whatever that means. Regarding where to put vis conditions: For the wheel chocks there is the Node, with no vis condition set. Then there is four modelpart (one for each highest LOD), and one need to set vis condition for each of them I think. With the latest McX version, for the gear, LOD's and vis conditions seems to be all over the place and I don't understand it no more.
Last edited:
Arno, I'm not sure what the difference is but the latest version I downloaded (DEV 21/04/2018) is giving me the same display as Tom in Hierarchy Editor. I notice that you are getting ModelParts all being beneath SceneGraphNodes (like it used to be) but I am seeing lots of ModelParts being beneath other ModelParts like Tom is. I will even see SceneGraphNodes being beneath ModelParts
Gavin
Gavin
tgibson
Resource contributor
- Messages
- 11,630
- Country
Hi Arno,
OMG, I have been working with the wrong MDL file. The MDL file that was used in posts #133 and 138 was an MDL file I had exported using the old version of MCX into FSX format. When I go back and use the original FS2004 MDL file I get what you see. So sorry! I will begin again.
I have found that if I use the latest development version of MCX to export the FS2004 MDL file into an FSX MDL file, I now get a proper display of Scenegraph nodes in the FSX model in the Hierarchy editor. So that problem doesn't exist in the latest exported MDL files.
OMG, I have been working with the wrong MDL file. The MDL file that was used in posts #133 and 138 was an MDL file I had exported using the old version of MCX into FSX format. When I go back and use the original FS2004 MDL file I get what you see. So sorry! I will begin again.
I have found that if I use the latest development version of MCX to export the FS2004 MDL file into an FSX MDL file, I now get a proper display of Scenegraph nodes in the FSX model in the Hierarchy editor. So that problem doesn't exist in the latest exported MDL files.
Last edited:
tgibson
Resource contributor
- Messages
- 11,630
- Country
Hi,
OK, now that we are working from the same object, let's start again.
When I Import the FS2004 DC-6 MDL file and Export directly to FSX (the ultimate goal), this is what I get:
1. Prop visibilities are now correct. However, they do not rotate due to the assignment of engine0, etc, to the animations, rather then prop0_blurred, etc.
2. The slow and blurred props are not transparent - it would be nice if they would be set that way, but no big deal.
3. The landing gear (which used to work OK), is now not working properly. It appears that the compression animation is now messed up, at least for the main gear:
4. The elevators and the rudder get assigned a Damage texture (_D.bmp) instead of the proper day and night textures (_T.bmp, _L.bmp). I use no damage textures in this aircraft. Further, they are assigned the day texture as the Specular texture. Note the black rudder above.
5. I have ramp objects which also use the gear compression animation to remain on the ground, but also have custom visibility conditions to disappear when the engines are running, the parking brake is not on, etc. The airstairs should be snuggled up next to the plane, and the oval panel should be in place on the right side of the airstairs instead of on the ground:
That right hand panel (now on the ground) should slide back when the door opens, and slides back after it has moved out of the way. The green cube should be inside the base of the airstairs object. It is the main parent for the entire airstairs objects. That location is probably the correct one for the green cube IF the rest of the object was not moved away from the plane.
Another custom object using gear compression animation is the forklift. In this case it's buried in the ground:
BTW, the visibility conditions for these ramp objects is correct, good job. It's the animations that aren't working correctly. All these animations (gear and ramp equipment) work fine in MCX - they are not converted properly into FSX. What is truly bizarre is that when I load the converted FSX MDL file into MCX, the gear and the ramp equipment animations display properly! So the information is there, but not being interpreted correctly by FSX.
5. The flaps are moved to the center of the aircraft. They still appear at the middle of the aircraft even when I assign the l_flap_key or l_flap_percent_key animations manually. Hopefully when the animation names are translated to the correct FSX ones in MCX, this will no longer happen? Thiis is still true when the FSX MDL is imported back into MCX.
6. None of the control surfaces move. Again, hopefully they will work with translating the animation names. They do not move when the FSX MDL file is imported back into MCX.
7. The rudder animation in MCX is incorrect (I assume) - it spins around 360 degrees. The elevator animation appear correct in MCX. The ailerons move in the same direction, but this might be handled by FSX to reverse one using the animation names? I don't know that.
Hope this helps,
OK, now that we are working from the same object, let's start again.
When I Import the FS2004 DC-6 MDL file and Export directly to FSX (the ultimate goal), this is what I get:
1. Prop visibilities are now correct. However, they do not rotate due to the assignment of engine0, etc, to the animations, rather then prop0_blurred, etc.
2. The slow and blurred props are not transparent - it would be nice if they would be set that way, but no big deal.
3. The landing gear (which used to work OK), is now not working properly. It appears that the compression animation is now messed up, at least for the main gear:
4. The elevators and the rudder get assigned a Damage texture (_D.bmp) instead of the proper day and night textures (_T.bmp, _L.bmp). I use no damage textures in this aircraft. Further, they are assigned the day texture as the Specular texture. Note the black rudder above.
5. I have ramp objects which also use the gear compression animation to remain on the ground, but also have custom visibility conditions to disappear when the engines are running, the parking brake is not on, etc. The airstairs should be snuggled up next to the plane, and the oval panel should be in place on the right side of the airstairs instead of on the ground:
That right hand panel (now on the ground) should slide back when the door opens, and slides back after it has moved out of the way. The green cube should be inside the base of the airstairs object. It is the main parent for the entire airstairs objects. That location is probably the correct one for the green cube IF the rest of the object was not moved away from the plane.
Another custom object using gear compression animation is the forklift. In this case it's buried in the ground:
BTW, the visibility conditions for these ramp objects is correct, good job. It's the animations that aren't working correctly. All these animations (gear and ramp equipment) work fine in MCX - they are not converted properly into FSX. What is truly bizarre is that when I load the converted FSX MDL file into MCX, the gear and the ramp equipment animations display properly! So the information is there, but not being interpreted correctly by FSX.
5. The flaps are moved to the center of the aircraft. They still appear at the middle of the aircraft even when I assign the l_flap_key or l_flap_percent_key animations manually. Hopefully when the animation names are translated to the correct FSX ones in MCX, this will no longer happen? Thiis is still true when the FSX MDL is imported back into MCX.
6. None of the control surfaces move. Again, hopefully they will work with translating the animation names. They do not move when the FSX MDL file is imported back into MCX.
7. The rudder animation in MCX is incorrect (I assume) - it spins around 360 degrees. The elevator animation appear correct in MCX. The ailerons move in the same direction, but this might be handled by FSX to reverse one using the animation names? I don't know that.
Hope this helps,
Last edited: