P3D v4 Massive (import) problems with DEV 18.11.2020 and P3D4 (4.4, 4.5)

[PilotOne]

Hello Arno,

I write to you again after a long time.
We had a longer conversation about the MCX in summer under the title "Recent development release stability".

It was about various problems your tool has with payware aircraft, especially PMDG.

I am aware that your development focus is more on MSFS2020. But unfortunately your modifications make your tool for P3D4 and higher more and more useless. Few things have improved, many things have worsened.
I think that's a pity, because the P3D is more like a real simulation, because you can imitate much more with it, while the MSFS2020 is more of a graphically inflated adult toy. But I own both, no comparison.

Maybe you can look at your last developer version (18.11.2020).

Already after starting the user interface the following is noticeable:
1) The displayed effects are now in their correct place. Positive.
2) The particles of the effects are displayed although the control button is NOT activated. The usage shows also no effect. (Negative)
3) PMDG uses luminous surfaces over long distances (i.e. under certain conditions visible polygons instead of effects. These textures consist of DDS textures with an alpha channel for transparency.
And this is where the MCX has a problem with the display. These, normally not visible areas are now displayed transparently in the normal view, where they were never visible, thus changing the view of the Albedo textures. Everywhere where such areas are, the albedo texture shows "holes".
It is noticeable that this was NOT the case until the September versions. (negatives).

4) In the settings in the options many pull-down buttons have no function.
The parameters can only be changed by using the arrow keys. (negative).

5) When using the import function it is noticeable that the scenery hierarchy is already destroyed during the import. You can clearly see this if you open the object hierarchy editor immediately afterwards and compare the versions. With the "old" versions, the hierarchy is preserved, with the new versions it is changed.

The following happens:
6) Attached effects are detached from their attachment positions.
This also causes the effects to lose their visibility conditions, because they are only assigned to their attachment positions.

7) Especially the light area polygons lose their function, because at the same time as the hierarchy is changed, the special visibility conditions are also deleted and are then no longer available in the pull-down menu in the object hierarchy editor.
Interestingly, this effect only affects the "real" light surfaces such as cab-, landing-, wheelwell-, tail- or wing lights. Due to the lack of visibility conditions, the switch function fails and they ALWAYS light up.

Not affected are beacon, strobe or navigation lights.




All versions were used with the basic settings.

I am not a professional like you, but I think the basic error is in the import. The scenegraph only governs as it is presented to it.

I have attached screenshots that clearly show the problems. you can use the model I sent you in the summer to understand the problems.

I would be happy to receive a reply. Best wishes from vienna.

 

[arno]

Hi,

I am aware that your development focus is more on MSFS2020. But unfortunately your modifications make your tool for P3D4 and higher more and more useless. Few things have improved, many things have worsened.
I think that's a pity, because the P3D is more like a real simulation, because you can imitate much more with it, while the MSFS2020 is more of a graphically inflated adult toy. But I own both, no comparison.

So nice that you already think to know that these issues you encounter are caused by changes made for FS2020. I would say that first has to be seen. All the additions I have made for FS2020 in the past months do not alter the support there is for previous versions. So I think it is more likely that you encountered some bugs.

2) The particles of the effects are displayed although the control button is NOT activated. The usage shows also no effect. (Negative)

Are you sure you are seeing particles? If I look at the screenshot it looks like some of these lights are modelled with polygons instead. But I will double check if the settings are working correctly.

3) PMDG uses luminous surfaces over long distances (i.e. under certain conditions visible polygons instead of effects. These textures consist of DDS textures with an alpha channel for transparency.
And this is where the MCX has a problem with the display. These, normally not visible areas are now displayed transparently in the normal view, where they were never visible, thus changing the view of the Albedo textures. Everywhere where such areas are, the albedo texture shows "holes".
It is noticeable that this was NOT the case until the September versions. (negatives).

This looks like a drawing order issue to me. Maybe the order in which the parts are drawn has changed in the past view months. I'll see if I can reproduce it with some object here, as I do not have any PMDG aircraft on my computer.

4) In the settings in the options many pull-down buttons have no function.
The parameters can only be changed by using the arrow keys. (negative).

Which settings are you talking about here, then I can try to reproduce.

5) When using the import function it is noticeable that the scenery hierarchy is already destroyed during the import. You can clearly see this if you open the object hierarchy editor immediately afterwards and compare the versions. With the "old" versions, the hierarchy is preserved, with the new versions it is changed.

We discussed this in Augustus/September already, both versions of MCX modify the hierarchy as stored in the MDL file. But that is by design and to make sure that MCX works correctly (un August you had issues with orientation of effects due to left overs from the import that were not optimized correctly, that has been solved now). Further optimizations have been made since then, but once again this is by design. So that you see a difference here is not an issue.

The following happens:
6) Attached effects are detached from their attachment positions.
This also causes the effects to lose their visibility conditions, because they are only assigned to their attachment positions.

I'll double check this, but since visibility conditions are attached to the scenegraph node in the MDL file anyway, this should not matter. Or do you mean that in the sim the visibility conditions no longer work now?

7) Especially the light area polygons lose their function, because at the same time as the hierarchy is changed, the special visibility conditions are also deleted and are then no longer available in the pull-down menu in the object hierarchy editor.
Interestingly, this effect only affects the "real" light surfaces such as cab-, landing-, wheelwell-, tail- or wing lights. Due to the lack of visibility conditions, the switch function fails and they ALWAYS light up.

What you see in the pull-down menu has nothing to do with the optimizations. All visibility conditions that are stored in the modeldef.xml file are shown in that menu.
The optimization does take visibility conditions into account, so that should ensure that parts that belong to a visibility condition stay under this condition. I'll double check if a bug maybe got into that code, if I can find a good object to reproduce it.

I have attached screenshots that clearly show the problems. you can use the model I sent you in the summer to understand the problems.

I'll see if I can still have that model, usually I throw away test objects after fixing a bug.

 

[PilotOne]

So nice that you already think to know that these issues you encounter are caused by changes made for FS2020. I would say that first has to be seen. All the additions I have made for FS2020 in the past months do not alter the support there is for previous versions. So I think it is more likely that you encountered some bugs.

It is not a reproach to you. Since your tool is very complex, the more you type, the more likely it is that errors will creep in. This is quite normal, as you cannot take all options into account every time you make a change.

In my opinion, an all-in-one tool would not be necessary. If you separated it now, handling errors would probably be a bit easier. I would have absolutely no problem having one MCX for FSX & P3D (which are very similar) and another MCX only for MSFS2020 (where many things work a bit differently).

This is just a thought-provoking impulse, perhaps to make your work easier, the results of which you kindly provide free of charge.

Are you sure you are seeing particles? If I look at the screenshot it looks like some of these lights are modelled with polygons instead. But I will double check if the settings are working correctly.

You're right. It represents the bright areas.

This looks like a drawing order issue to me. Maybe the order in which the parts are drawn has changed in the past view months. I'll see if I can reproduce it with some object here, as I do not have any PMDG aircraft on my computer.

You can judge this better. If you like it and can use it, I have no problem sending the model again. You just have to tell me how.

Which settings are you talking about here, then I can try to reproduce.

It affects ALL functions.
Immediately after opening the options ALL pulldown menus work. However, as soon as you press ONLY ONE time - you can make a selection here - all pulldown menus will not work. Not even the same.

We discussed this in Augustus/September already, both versions of MCX modify the hierarchy as stored in the MDL file. But that is by design and to make sure that MCX works correctly (un August you had issues with orientation of effects due to left overs from the import that were not optimized correctly, that has been solved now). Further optimizations have been made since then, but once again this is by design. So that you see a difference here is not an issue.

However, it is a problem because the links of visibility conditions between light surfaces and effects are separated.
Originally, the effects attached to the light surfaces assume the visibility conditions of the light surfaces. The effects themselves have NO visibility conditions of their own.

The - intended - combination between the light surfaces and effects is that e.g. the lens of a spotlight - i.e. the polygon - is illuminated (brightened) and at the same time the effect of dynamic floor lighting is activated.
The combination of both results in the realistic view, light area and ground effect of the light beam.

By separating the effects from the light polygons - you can see this clearly in the hierarchy editor - the function of the light surfaces (which have their own visibility conditions) is preserved, but the separated effects are ALWAYS active, because they have NO visibility conditions of their own. The visibility condition "none" means, that the effects are always active and not restricted by any condition.

I have added some screenshots to illustrate the problem.

I'll double check this, but since visibility conditions are attached to the scenegraph node in the MDL file anyway, this should not matter. Or do you mean that in the sim the visibility conditions no longer work now?

As already mentioned, it changes almost everything.

What I also observed is that it mainly affects those light functions that are connected to the hull.
Those that are connected to the wings or winglets are not affected by the problem.
You can see this clearly in the scenegraph. The structure of the fuselage (scenegraph) looks significantly different, while that of the wings remains unchanged.
This also explains why navlights, strobes and position lights work, but the taxi-, RTO- and landing lights do not.

What you see in the pull-down menu has nothing to do with the optimizations. All visibility conditions that are stored in the modeldef.xml file are shown in that menu.

This is only partially correct. Since all changes in the hierarchy editor immediately affect the .xml file, the visibility conditions of those parts that you have deleted are lost. They are no longer listed.

Example: you would like to assign the visibility conditions of a part to which this effect is originally linked to an effect that has no visibility conditions.
the purpose is to have the effect on its own, WITHOUT the component. This is quite possible, for example, with a beacon located on the fuselage.
I have already done this. Why? Well, I did not want the light polygons to show the "light corona", but integrated this optic into the new beacon effect. Apart from that I also wanted a different light frequency.
But if I delete the component "light area" to which these conditions are linked before assigning the visibility conditions to the effect, this condition will be deleted in the .xml file as well.

This means that these visibility conditions are not stored in the .xml file, but only exist and are displayed as long as only one single component has these conditions. If this is deleted, it is over. This has been mentioned here in other posts.

The optimization does take visibility conditions into account, so that should ensure that parts that belong to a visibility condition stay under this condition. I'll double check if a bug maybe got into that code, if I can find a good object to reproduce it.

That is true, and it is correct so far.
But what is completely under the table is the fact that attached effects also accept these visibility conditions. Due to the restructuring these connections are disconnected and therefore the effects lose their visibility conditions.
You have shown this yourself in a very old tutorial about how to attach an effect to a polygon.
"Back to the roots", as they say. ;-)

I'll see if I can still have that model, usually I throw away test objects after fixing a bug.

As already mentioned, you are welcome to have the model again.

 

[arno]

Hi,

In my opinion, an all-in-one tool would not be necessary. If you separated it now, handling errors would probably be a bit easier. I would have absolutely no problem having one MCX for FSX & P3D (which are very similar) and another MCX only for MSFS2020 (where many things work a bit differently).

I don't see how that would help. Since the main function of MCX is to convert models between different simulators, a lot of functionality in the MSFS and FSX/P3D would have to be shared. So I think it's better to fix the bugs you have encountered.

It affects ALL functions.
Immediately after opening the options ALL pulldown menus work. However, as soon as you press ONLY ONE time - you can make a selection here - all pulldown menus will not work. Not even the same.

I am still confused. Are you taking about the options where you set the settings for MCX? Or do you mean one of the editors, like the hierarchy editor? In the options dialog I don't see any issues with drop-down menus here. But I have a feeling we are talking about different things.

However, it is a problem because the links of visibility conditions between light surfaces and effects are separated.
Originally, the effects attached to the light surfaces assume the visibility conditions of the light surfaces. The effects themselves have NO visibility conditions of their own.

By separating the effects from the light polygons - you can see this clearly in the hierarchy editor - the function of the light surfaces (which have their own visibility conditions) is preserved, but the separated effects are ALWAYS active, because they have NO visibility conditions of their own. The visibility condition "none" means, that the effects are always active and not restricted by any condition.

OK, this sounds like a bug. I am going to reproduce it here, so that I can fix it. It should be that the parent node of the attached object keeps the visibility condition, but from what you describe that does not happen.

What I also observed is that it mainly affects those light functions that are connected to the hull.
Those that are connected to the wings or winglets are not affected by the problem.
You can see this clearly in the scenegraph. The structure of the fuselage (scenegraph) looks significantly different, while that of the wings remains unchanged.
This also explains why navlights, strobes and position lights work, but the taxi-, RTO- and landing lights do not.

The optimization looks at animation as well, since the wing probably has a wing flex animation it is logical that this structure can't change too much.

This is only partially correct. Since all changes in the hierarchy editor immediately affect the .xml file, the visibility conditions of those parts that you have deleted are lost. They are no longer listed.

Example: you would like to assign the visibility conditions of a part to which this effect is originally linked to an effect that has no visibility conditions.
the purpose is to have the effect on its own, WITHOUT the component. This is quite possible, for example, with a beacon located on the fuselage.
I have already done this. Why? Well, I did not want the light polygons to show the "light corona", but integrated this optic into the new beacon effect. Apart from that I also wanted a different light frequency.
But if I delete the component "light area" to which these conditions are linked before assigning the visibility conditions to the effect, this condition will be deleted in the .xml file as well.

Definitions of visibility conditions are only added to the modeldef.xml file during import of the MDL file. When you un-assign a visibility condition from one node, it is not removed from the internal modeldef.xml representation. Of course if you export a model only the definitions that are used by the model are written to the modeldef.xml that XtoMDL uses during export.

 

[PilotOne]

I am still confused. Are you taking about the options where you set the settings for MCX? Or do you mean one of the editors, like the hierarchy editor? In the options dialog I don't see any issues with drop-down menus here. But I have a feeling we are talking about different things.

No, we are talking about the same things.
I have tried to narrow down the "problem". I noticed that it only occurs when an object is loaded.

It concerns all settings in the OPTIONS MENU. No matter what you want to set in any section.
Start the options. Select any tab, e.g. "General Settings" and press the pull-down menu for "AutoSaveEventLog".
It only works exactly once. If you try it a second time, nothing happens. Similarly, all other pull-down menus will not work anymore. But you can still change the setting with the up and down arrow keys.

I only found it by chance, because I wanted to change a parameter for the next program start, which reads the settings again.

OK, this sounds like a bug. I am going to reproduce it here, so that I can fix it. It should be that the parent node of the attached object keeps the visibility condition, but from what you describe that does not happen.

The parent node of the attached object retains its visibility condition, this does not change.
However, because the "attached" effect is "detached" by the restructuring, it loses its visibility condition assigned to it by the parent node. This is the flaw, the effect is "disconnected".

You can understand this quite simply.
Create a simple polygon with e.g. a white surface. Then assign a visibility condition to the polygon, e.g. "active light" at night.
Then use a simple standard effect like an OBS-light.
As soon as you attach the effect to the polygon, it will adopt the visibility conditions of the polygon. This means that the OBS-light will only glow at night when the polygon is also glowing white.
But as soon as you disconnect the polygon, it will continue to glow only at night. the effect, however, will glow continuously because no visibility conditions control the function.
And this is exactly what is currently happening when restructuring the hierarchy in the scenegraph. the existing connections will be separated and the visibility control function of the effects will be lost.

I think, it would be better to leave this existing structure untouched, because otherwise these errors occur completely unintentional.
It may serve to improve the function of the MCX, but the result is unwanted. I think it is better to adapt the MCX to the circumstances and not the other way round, the object to the MCX. I think, this is not in the sense of the universal functionality you are aiming for.

Definitions of visibility conditions are only added to the modeldef.xml file during import of the MDL file. When you un-assign a visibility condition from one node, it is not removed from the internal modeldef.xml representation. Of course if you export a model only the definitions that are used by the model are written to the modeldef.xml that XtoMDL uses during export.

Sorry, that is not right.
If the last object in the .xml file that needs these visibility conditions is deleted or removed from the model, this visibility condition is no longer accessible to other objects or effects to which you want to reassign this condition.
Here, at the same moment you do this, either the access is blocked or the data is deleted from the xml. file.
BEFORE you have exported the model, directly on the open application.

 

[arno]

It concerns all settings in the OPTIONS MENU. No matter what you want to set in any section.
Start the options. Select any tab, e.g. "General Settings" and press the pull-down menu for "AutoSaveEventLog".
It only works exactly once. If you try it a second time, nothing happens. Similarly, all other pull-down menus will not work anymore. But you can still change the setting with the up and down arrow keys.

I can't reproduce this issue on my computer. The options form works fine here, no matter how many times I click on an option and no matter if an object is loaded or not.

This is all standard .NET functionality as well, it is not something that I coded myself.

The parent node of the attached object retains its visibility condition, this does not change.
However, because the "attached" effect is "detached" by the restructuring, it loses its visibility condition assigned to it by the parent node. This is the flaw, the effect is "disconnected".

I mentioned before that this is probably a bug, so I am going to reproduce it here so that I can fix it.

Sorry, that is not right.
If the last object in the .xml file that needs these visibility conditions is deleted or removed from the model, this visibility condition is no longer accessible to other objects or effects to which you want to reassign this condition.
Here, at the same moment you do this, either the access is blocked or the data is deleted from the xml. file.
BEFORE you have exported the model, directly on the open application.

Are you talking about the ModelDef.xml editor in MCX? It has an option to only show the definitions that are used on your model. If you have that option enabled and next you use the edit mode of the ModelDef.xml editor to make changes to the XML file you will indeed loose all unused definitions in your model. But that is not something that MCX does automatically. So if you want to edit the XML file and keep unused definitions, you need to uncheck the option to only show the used entries.

 

[arno]

Hi,

There was a bug indeed that caused the visibility conditions to be lost for the attached effects. I have fixed that bug now, so in the next development release that will be solved.

Remains open the issues with that drawing order in the preview, I'll try to find an object to debug that with.

 

[PilotOne]

I can't reproduce this issue on my computer. The options form works fine here, no matter how many times I click on an option and no matter if an object is loaded or not.

This is all standard .NET functionality as well, it is not something that I coded myself.

It's not really important, because these are not settings that you are constantly changing. So it is rather a secondary "problem".

Are you talking about the ModelDef.xml editor in MCX? It has an option to only show the definitions that are used on your model. If you have that option enabled and next you use the edit mode of the ModelDef.xml editor to make changes to the XML file you will indeed loose all unused definitions in your model. But that is not something that MCX does automatically. So if you want to edit the XML file and keep unused definitions, you need to uncheck the option to only show the used entries.

And, I have to disagree, in this case the MCX does it "automatically".

For me as a "mere" user of the object hierarchy editor, it seems that the MCX reads the existing model-related visibility conditions in the .xml file, adds predefined standard entries - which, by the way, always remain available - and displays them.

But as soon as a certain model-dependent visibility condition "disappears", because there is no more part that has this visibility condition as a property, it will not be displayed in the list anymore.

This means that the MCX continuously reads the .xml file and updates the entries. So these entries are no longer available. As a "solution" you have to set these visibility conditions for another component - polygon or effect - before you remove the last "standard object" with the desired visibility condition for this model.
In this way an entry for this visibility condition is retained and is then also offered in the MCX selection menu.

The fact that the unneeded entries are no longer fixed during compilation would be the normal procedure. But it takes place "live".
To correct this, the MCX would have to create an "edit copy" of the .xml file, in which everything remains until the final compilation. Just like other applications do for security reasons. Only when the final editing - either by saving or, as here, by compiling - is complete, does the "working copy" replace and overwrite the original file. This would also ensure "return" functionality.

But at the moment there is no "safety net" and that's why there are such unwanted or unintended effects.

There was a bug indeed that caused the visibility conditions to be lost for the attached effects. I have fixed that bug now, so in the next development release that will be solved.

I think you are on the wrong horse here.

The real reason is NOT that the visibility conditions for the effects are "lost". They do not have any of their own.
You only get them by attaching them to objects, which have visibility conditions themselves. If these effects are separated from their objects by the restructuring of the object hierarchy, they automatically lose their visibility conditions as well. There is nothing extra deleted or wrong assigned.

To describe it quite "simple".
If you have a pair of pants hanging on a hanger in a wardrobe, you will see them. You will see the hanger and the pants. The pants have taken on the visibility of the hanger.
If you restructure this wardrobe, remove the pants from the hanger and hang the hanger somewhere else, the hanger is there and you see it, but positioned somewhere else. The pants are still there, but you do not see them because
has lost the bond to her hanger and has fallen to the ground.
As long as you do not restore the new binding to your hanger, i.e. hang it on the hanger, it remains invisible. Because in the moment you let it go, it falls to the ground again and becomes invisible again.
This means, however, that a restructuring of your wardrobe will only be successful if you let the pants keep their binding - that is, the hanging on the hanger. otherwise your undertaking will fail miserably.

The same happens in the object hierarchy. But you know that.
And for this very reason, restructuring the object hierarchy for "optimization reasons" makes no sense. Because this leads to too many mistakes, which have to be compensated in a different way.
We in Vienna say: "the soup costs more than the meat". Means translated: The effort required to compensate for errors is out of proportion to the benefit of the measure.

Remains open the issues with that drawing order in the preview, I'll try to find an object to debug that with.

I can reassure them, the MCX does not make any display errors. It only displays what it finds.

In this case, the restructuring of the object hierarchy also affects the display. The "display errors" affect the very objects whose position in the object hierarchy has been changed. You can see that exactly, because it concerns the identities of the objects, i.e. those in the immediate fuselage area - landing, RTO and other lights. All other areas that remained untouched are also displayed correctly.
This can be seen most clearly when using the object hierarchy editor. Objects within the original structure, such as strobe or nav-lights, are displayed correctly.

You can see all of this clearly if you compare two different versions, one without and one with "optimization" of the object hierarchy. it's like day and night. You will see and realize that this problems disappears by itself as soon as you give up the restructuring of the object hierarchy.

However, you have to decide for yourself whether this restructuring will bring such serious advantages that the expense of a comprehensive remedy of the errors that have occurred is really worthwhile.
Personally, I don't think so, but that's your decision. If I had to make that decision, I would leave the restructuring out. Basically it is a good idea, but the problems that arise, which one does not see or recognize at first glance, predominate in my opinion.

But you are the "expert", not me. I'm just a "little annoying" user.


Finally, I have one more question for you:
Would it be feasible to implement a "cut and paste" function in the object hierarchy editor?
It is very tedious to change an attachpoint from an effect, e.g. in a very extensive hierarchy, since the moving is limited to the screen area and the window does not scroll with the movement, as soon as the edge of the window is reached.
Thank you.

 

[PilotOne]

Hallo Arno,

I have now done the countercheck.
As soon as you add the visibility conditions to the effects, they will work.

The big drawback is, that PMDG has multiple links, which are defined in the object hierarchy editor. It means, for example:
A fold-out landing light is only displayed if the configuration is set to "Normal Lighting". With the setting "LED-Lighting" it is not displayed.
This means that there are already 2 visibility conditions for this headlight linked together. First, only visible in the "normal" configuration. And second, only visible when the "landing light" switch is activated.
It also means that the "mechanical parts" like headlight housing and light lens are NOT displayed in the "LED" option. Since the effect is attached to the light lens, which in turn is attached to the headlight housing, 2 conditions must be met for the effect to light up. Instead of programming the complex conditions, they have solved them by attaching them to different objects with different visibility conditions.

And this is exactly the problem, if you change the structure of the object hierarchy. All links of visibility conditions are lost. This can not be fixed by staying with the "optimizations". There are simply too many possibilities, but they also differ from model to model.

The safest and easiest solution is NOT to change the existing object hierarchy.
Here you would have the option of adding the variants "Object Hierarchy Optimization", "TRUE" or "False" to the options for the importer settings. Provided, of course, that this optimization is only used for import and not also for export.
So I could imagine a solution and "bug fixing" without much effort. So you can use your optimizations - for simple models - and at the same time ensure compatibility with complex models.

 

[arno]

Hi,

And, I have to disagree, in this case the MCX does it "automatically".

For me as a "mere" user of the object hierarchy editor, it seems that the MCX reads the existing model-related visibility conditions in the .xml file, adds predefined standard entries - which, by the way, always remain available - and displays them.

But as soon as a certain model-dependent visibility condition "disappears", because there is no more part that has this visibility condition as a property, it will not be displayed in the list anymore.

Can you confirm that this automatic behaviour happens when you do not have the modeldef.xml editor open and when you have never touched the edit button in the modeldef.xml editor since loading the model?

I can only reproduce this behaviour when I am using the edit mode in the modeldef.xml editor. I'm 100% sure that the hierarchy editor can not modify the XML code, that's simply not how the tool is designed. The hierarchy editor only reads information from the XML file and never modifies it.

The real reason is NOT that the visibility conditions for the effects are "lost". They do not have any of their own.
You only get them by attaching them to objects, which have visibility conditions themselves. If these effects are separated from their objects by the restructuring of the object hierarchy, they automatically lose their visibility conditions as well. There is nothing extra deleted or wrong assigned.

You have reported a bug with the attached objects and I have told you I have fixed it by now (new development release with the fix will be online soon).

So could you please stop crusading now about how MCX should work internally? The internal MCX representation never has been an exact replicate of the structure in the MDL file, that's already the case for over 10 years. That's because the requirement for this internal representation is that it supports conversion between various formats, that's the prime functionality the tool has been made for. But as long as I make sure that while import and export no information is lost, that is not a problem for the end user. You are looking for a tool that will keep the MDL file structure in place and only make some changes, but that is not how MCX works. So like I explained you before, what you see in the September build is also not the internal MDL representation. So although the structure you see now in the hierarchy editor is different, both structures you see are different from the actual MDL file.

If there are issues with either the import or the export, of course I'll have a look and try to fix them as soon as I can. Just like the visibility condition issue could be solved quite quickly.

However, you have to decide for yourself whether this restructuring will bring such serious advantages that the expense of a comprehensive remedy of the errors that have occurred is really worthwhile.

You only look at your use case where you want to edit an existing MDL file. If I would make the changes you request and not restructure the model, many other functionalities of MCX would be broken. Like exporting to some of the other formats that are supported. And the restructuring even helps to fix issues with the object not showing correct in the preview box in FSX/P3D, as the gamepack has a bug that it leaves some scaling transformations in that the preview box can't handle. I do have to consider much more use cases of the tool than just editing a MDL file, else I would have loads of other users complaining that things got broken.

Just let's leave the discussion to what doesn't work and when it does not work and I'll try to fix it in the tool then.

Finally, I have one more question for you:
Would it be feasible to implement a "cut and paste" function in the object hierarchy editor?
It is very tedious to change an attachpoint from an effect, e.g. in a very extensive hierarchy, since the moving is limited to the screen area and the window does not scroll with the movement, as soon as the edge of the window is reached.

IF you check a recent development release, you will see that the list of the hierarchy will now scroll if you drag a node to the top or bottom of the list. That's something I added recently and that should help to fix this.

Here you would have the option of adding the variants "Object Hierarchy Optimization", "TRUE" or "False" to the options for the importer settings. Provided, of course, that this optimization is only used for import and not also for export.

Do you remember what you asked me before summer? When you had all the optimizations of you had issues with the orientation of the attachpoints being wrong and you could not edit them correctly. That was the consequence of not optimization as there were left overs in the hierarchy from the importing. So that clearly shows that doing no optimization at all will give issues else where.

 

[PilotOne]

Can you confirm that this automatic behaviour happens when you do not have the modeldef.xml editor open and when you have never touched the edit button in the modeldef.xml editor since loading the model?

Yes, I can confirm that. It was also described here in an older thread in the same way.
Example: ONLY ONE component or effect in the model has a specific, individual visibility condition (created by the designer of the model). This condition is displayed in the pull-down menu. You remove this effect or part. Then you want to transfer this individual visibility condition to another object. You open the pull-down-menu, but this individual visibility condition is no longer visible.
For this process the modeldef.xml-editor is not touched, opened or even the editor-mode is activated - none of this. All "work" is done exclusively via the object-hierarchy-editor.

You have reported a bug with the attached objects and I have told you I have fixed it by now (new development release with the fix will be online soon).

This error is fixed. The adoption of the visibility conditions on the lowest level is implemented.
But as those objects, to which the effects are attached, are connected to other objects, which have different visibility conditions, it is only a partial solution of the actual problem.

So could you please stop crusading now about how MCX should work internally?

Dear Arno, there seems to be a fundamental misunderstanding here. It is not at all the case that I am here as a "know-it-all" and can and will tell them how the MCX should work and what they should do and not do. If something went wrong with my efforts here, I ask you to forgive it. I am not criticizing your work here. Perhaps you are misinterpreting my, perhaps too eager, efforts because of formulations.

But as long as I make sure that while import and export no information is lost, that is not a problem for the end user.

If there are issues with either the import or the export, of course I'll have a look and try to fix them as soon as I can. Just like the visibility condition issue could be solved quite quickly.

Unfortunately, this is exactly where problems arise. To the facts:

Components that were originally separated are joined together due to their similarity. As a result, they are assigned exactly the same visibility conditions. But this is deliberately NOT intended.
It is precisely the model transmitted to you that is best suited for error analysis here. when you open it, you will notice that, for example, the upper beacon (fx_beacont) is present 2x (!). But it is originally and actually NOT displayed or active 2x, but only alternately. But now it is, see screenshot. After optimization it is summarized, although it does NOT belong together.



The visibility is, normally, linked to the roof SAT system. this SAT system (its graphic display - visibility) can be activated, deactivated and also determined in position (front or center) via the FMS user interface of the aircraft.
If the sat antenna is inactive or located in the rear, only the rear beacon (fx_beacont_100) is visible.
If it is activated for the center, the rear beacon is inactive and only the front beacon (fx_beacont_99) is visible.

The same applies here for the lighting (landing, cab and RTO lights). PMDG e.g. provides here, also via FMS, 2 different light versions. Normal lighting and LED-lighting. This differs both in the use of different light polygons and effects with different light color and brightness, as well as in the different visibility of certain components. For example, the frontgear-taxilight is only displayed in the "normal light" configuration, but not in the "LED light" configuration.

So, another link on the next higher level by "appending" to another object. The structure then looks like this, starting from the lowest level. effect-object-object-object etc. whereby the visibility conditions of the topmost object in this hierarchy are inherited down to the lowest effect.

It is a matter of linked "IF" and "OR" conditions, as we know it from MS-Excel, with the means of "appending to an object and taking over the visibility conditions of the superordinate object". Only just graphically implemented.

IF you check a recent development release, you will see that the list of the hierarchy will now scroll if you drag a node to the top or bottom of the list. That's something I added recently and that should help to fix this.

Many thanks for this.

So that clearly shows that doing no optimization at all will give issues else where.

Unfortunately, I cannot sign that. But it is by no means your mistake or even your fault. It is completely normal for a developer, especially with such a complex tool, not to be able to take everything into account from the start.
I can also understand that it is a lot of work to check all possibilities and variants in the application after a change. This happens to the best of your knowledge and belief. In addition you react to every feedback, thanks for that.
I also think that this way there will be a good result for both, you as developer and us as user.


I am fully aware that this is a very extensive problem.
Nobody, even you as an experienced developer, could have guessed how much the definition of a certain object hierarchy would have an effect when other developers use this structure almost excessively to solve complex visibility conditions as easily as possible.

It was only because I gradually became aware of this complexity that I made the suggestion to skip this kind of optimization in individual cases. Not as a criticism of how your tool works, but as a relief for you, to relieve you of a "feature fix" and free you for further development steps.

I am also willing to help you in any way I can. Be it by testing or feedback. I will also gladly answer any questions you may have, if I am able to do so.

 

[arno]

Hi,

I haven't been able to reproduce the modeldef.xml issue yet, but I'll try it with a different approach.

I did double check if the nested visibility conditions work fine and when checking them I found another small bug. So that will be fixed in the next development release.

 

[PilotOne]

I haven't been able to reproduce the modeldef.xml issue yet, but I'll try it with a different approach.

Hi,

In my humble opinion the problem is NOT directly related to the modeldef.xml or the XML editor directly.
The problem seems to be the way the user interface of the object hierarchy editor handles this modeldef.xml.

I have observed that every time I make a change in the object hierarchy editor, the representation of the data disappears for a short time and then, when changed, is present again.
This would indicate that these changes are done live, i.e. by overwriting and re-reading the modeldef.xml, and not only when compiling.
It would also explain that entries "disappear" or are no longer listed because they simply no longer exist by removing a certain object and its associated visibility condition.

But of course you know your software better, it should only be a hint.

I did double check if the nested visibility conditions work fine and when checking them I found another small bug. So that will be fixed in the next development release.

Thanks, I am looking forward to try the newest version.
Have a nice weekend and thanks a lot.

 

[PilotOne]

Hi, Arno,

I have now tested the latest version of the MCX.

By and large the lights are now working normally, except for the beacons.
It should be noted that the lights have only a simple visibility condition, but the beacons have two visibility conditions, each of them superior.


Report:
1) the graphic representation of the hull is now (almost) complete and flawless
2) all lighting - except the beacon - works perfectly.
3) scrolling in the object hierarchy editor works perfectly

Now to the "errors", which are also graphically visible thanks to your excellent graphical user interface, which by the way is perfectly suited as "error detector" here.

Analysis:
I am now referring to the model that I have sent you.
Since it is very complex, I think it is very good for debugging.

1) The upper beacons - beacont_99 and beacont_100 - both light up simultaneously.
The reason for this is that now after the import the superior light polygons are separated, but after the conversion they are joined together again. The SceneGraphNode created during the import with the superior visibility conditions (NGXHASAntenna) is lost.

The main error has now shifted to the export.

You can easily understand this. Import the model and convert it ,WITHOUT changing. then load the converted model. For direct comparison I use the term "beacon" in the search field of the object-hierarchy editor. If you extend the structure, you can clearly see that the node is missing.


2) the emergency lights on the side are fully functional, but the display on the user interface shows "holes" in the hull. This is NOT a graphical error of your user interface (Debug Tool), but it only shows what it finds.

Should: the light polygons of these lights must be separated from the hull, because the textures are transparent.
Is: after importing, these polygons are connected to the hull, they run over the same node.
You can see this clearly in the object hierarchy editor, best search term is "emergency".



Result = holes in the hull, because the polygons if the lights with their transparent textures connected to the hull, whose polygon textures have transparencies only in windows. So the light-polygons are shown just like a window, i.e. transparent. But this is only a problem for the display in the MCX WITHOUT practical effect on the displayed model in the P3D.

I.e. this "error" is rather marginal. But since I know that you are a perfectionist who wants to have a perfect tool, I'll tell you. It is only a small optical bug, which has its roots in the restructuring.


I wish you a nice weekend. the "louse, who sits in your fur", me, will enjoy the rest of the day as well.

 

[PilotOne]

Correction to error point 1)

The change of the structure does NOT take place during the export, but already during the changes with open hierarchy editor BEFORE compiling.

Obviously the data will be rewritten LIVE and read in again immediately.

I tried this several times with different objects and effects - append effect to other objects and the result was always the same.

the effects are all attached to the 1st root node (hull), any superior visibility condition is lost.

 

[arno]

I'll double check those nested visibility conditions again. Last few days were quite busy, so didn't have time for it yet.

 

[arno]

Hi,

There was indeed another bug in the nested visibility conditions. I have fixed that tonight, so I hope the next development release works better again for you.