two Bugs & a Question

[Akila 39]

hi there I found to bugs in P4AO

1. when disabling a specific scenery (paints it RED) it still shows it green in the Group TAB (the specific Scenery in the group). same the other-way around - Visual / UI Bug only...

2. if you add a mew scenery to a pre-disabled group, the scenery is added as Active (<AddOn.Component> and not <AddOn.Component.Disabled> ).
to mitigate the issue, one needs to enable the group and disable it again. only than all the sceneries in the group would be <AddOn.Component.Disabled> included the new added one.

how does the tool decides when to Active/Deactivate based on <AddOn.Component.Disabled> or based on Active=TRUE?

 

 

Edited May 27, 2018 by Akila

[Lorby_SI 2,038]

A general remark: Activating/Deactivating scenery has nothing to do with the groups, those are completely independent. The groups are to remain static, so you can predefine a certain state of your scenery library that you can always return to. If the tool would change the groups every time you change the scenery, then it would destroy the whole concept of what the groups are supposed to do. I think that "bug" #1 and #2 are actually as designed, P4AO is not supposed to change the state of a scenery in the group definition. But I will take a look at it.
(quite a few features around the groups were requested by a actual users, and they seem to be happy with it - so changes are not to be taken lightly in this area)

4 hours ago, Akila said:

how does the tool decides when to Active/Deactivate based on <AddOn.Component.Disabled> or based on Active=TRUE?

One is for scenery.cfg the other for add-on.xml.
"Active = true" is only possible for scenery in the scenery.cfg. The add-on.xml definition has no such feature, you can only disable the whole package, not a single AddOn.Component.  "AddOn.Compontent.Disabled" is not an official state, this is something that only P4AO does. As stated in the manual, it is strictly against the specification and will show up as an error in the P3D content error log - but it was the only option that we currently have to disable a single component in an addon.xml that holds several. Example: imagine that you have an add-on.xml where you have collected all your north american airports. If you stick to the P3D spec, you can not deactivate one single airport in it - you can only deactivate the whole package (=all airports), by disabling the addon-definition on the "Options->Add-ons" dialog in P3D.

Best regards

[Akila 39]

I understand and see your point. Maybe from concept point of view you are correct, but from User experience 
it might not match the concept so well. that is because there is a mismatch of the coloration between the scenery TAB  and the scenery in the group TAB that presents the scenery.
why did I raise it as a concern?  because when I disabled the scenery and did not see it becoming RED in the group, i wasn't sure if it was actually disabled or not, as there was 
a discrepancy in the colors between them both. only after I physically checked the XML file(s) I knew it was disabled, but from UI prospective it could be rather confusing.
an average user won't know which color to believe is actually in place.

as to Point two, I also understand the grouping concept you had in mind, however my point is, if a user wants to add a scenery to a disabled group, he want's it to remain disabled
until he enable the entire group. that is my view, as I many times add scenery for house keeping, migrating, etc. if i have a disabled group I would assume that the scenery that was just added to that group is also disabled as it is colored RED group suggests. there is no other indication to the user that it is actually enabled (that is what I believed when I added the scenery to the disabled group - that it would also be disabled), unless I rely on the GREEN color in the scenery tab. but than again,  we going back to issue number one discussion, color mismatch, which one I rely that is correct? the group color or the scenery color.

anyway, it's up to you how you want to take this feedback, I am just expressing my opinion on the matter from a user experience prospective.
for me it is not so critical really as I am a technical person, so I know how to check XML/CFG files to validate.
but for a less techi' person it might be confusing, etc... the fact that I had to validate it in XML/CFG files, suggests that the UI was confusing.

Anyway man, I love your job!!! you are amazing!!!! the best tool for P3D ever!!!!!
so comprehensive !!!! I would sure buy this tool as it already becoming a pay grade tool..
thanks for everything..

Edited May 27, 2018 by Akila

[Lorby_SI 2,038]

Hello Joel,

Not to worry, I will check this out as soon as I have a bit of time on my hands. I am currently in the middle of something.

The only real reference to check if a scenery asset is active or not is on the first page - that one should always be correct, you don't have to look into the XML.

But there are three use cases that can influence this (de/activating the scenery, de/activating via a group and de/activating the package). I have to trace it step by step to see if one if overriding the other where maybe it shouldn't.

I concur that the group logic is complex, it is for me too...

Best regards

[Akila 39]

by the way, where is the group information is saved? what file?

the Grouping and the group nesting is a brilliant feature / function in the tool.
 

Edited May 27, 2018 by Akila

[Lorby_SI 2,038]

32 minutes ago, Akila said:

by the way, where is the group information is saved? what file?

Config files are here:

C:\Users\...\AppData\Local\LORBY_SI\P4AO

Best regards