MSFS Is there a limit on number of scenery objects which can be compiled?

[jgarnold]

Some more interesting observations about incorrect footprints-
FD_CHILD which I believe is a scenery object part of MSFS shows a small round footprint
PILOT MALE CASUAL also seems to be a scenery object part of MSFS BUT IS ANIMATED shows a large square footprint - could this be because it is animated?
Other scenery objects I have downloaded (PIER_MODELS) and added which are PIERS (about 20 metres x 10 metres) show that the datum in Blender is 1 METRE above bottom of the 'legs' and they display a large square footprint (instead of a smaller rectangularjust like my rusty pole when it is more than 50cm 'deep'.

Once again does being more than 50cm deep result in an incorrect footprint?

 

[scruffyduck]

I can't answer your questions since you may be seeing the results of the bug. Sim objects just show as a small rectangle as I recall and are not covered by detailed footprints.

I know what the bug is an I am trying to work out how best to fix it with the minimum disruption. It is likely to be a breaking change.

Detailed footprints are generated by code taken from MCX and the latest MCX will show a representation of the footprint if an object is opened there. That footprint may well change if you move the model up and down the Z scale but I can't control that. The main issue with ADE 2020 footprints are first that there may still be some that show not top down but side on and the position of the rotation handle can be misplaced. The main issue with non detailed footprints is they all default to 20x20

Internally the issue is that ADE is not reading bounding box information of glTF models correctly and I am trying to figure out why

 

[scruffyduck]

This is an object shown in MCX and the footprint option

 

[jgarnold]

Thanks Jon. I can 'live' with a small annoyance. In the meantime I will ensure none of my models is more than 50cm below the datum (ground level). As mentioned before I only did that to prevent the possibility of such an object (a pole or bottom of a dock) showing due to wave action and I don't even know if that would ever happen. Do you?

added later - thanks also for pointing out generate footprint object in MCX.

 

[scruffyduck]

The final thing to be aware of - I guess you are - is that if you update a model then you need to generate its footprint again

 

[jgarnold]

Thanks for the advice

 

[GaryGB]

Hi John:

I believe Jon may have intended to infer 2D footprint derivation issues may be potentially greater in ADE-18 versus ADE-19.

The major in display of library objects is present in 18

I would recommend you to use ADE Alpha-19 ...available here:

https://www.fsdeveloper.com/forum/threads/alpha-19-released.452236/post-880291

Again, I recommend- no, actually I now implore- you to switch to use of ADE-19 ...instead of ADE-18.

"Please Help Me by Always Updating to the Latest Alpha".​

https://www.fsdeveloper.com/forum/t...y-always-updating-to-the-latest-alpha.451018/

...is Jon's request as a reasonably equitable condition for use of this new build of ADE for MSFS-2020.


Many thanks to Jon for all his ongoing efforts in developing this new- and evolving- build of ADE for MSFS-2020.

And thanks to you John, for exploring this quirk of display size for derived / non-derived 2D footprints in the current state of ADE (Alpha) development.

I envision even better functionality in the future for both ADE and MCX ...as Jon and Arno work more on this 'footprint' feature.

GaryGB

 

[jgarnold]

Gary
I agree that by using ADE 19 we help Jon address and potential bugs but as he states "Err - this whole program is still in alpha so by definition it has bugs, unfinished code and missing functionality. It is close to a total rewrite from ADE 1.7," I am concerned that it might be possible that I screw up an airport I have spent a lot of time on. I guess keeping backups along the way eg saving project as "project name_nn" where nn is the latest version is the answer.

 

[GaryGB]

I guess keeping backups along the way eg saving project as "project name_nn" where nn is the latest version is the answer.

Hi John:

IIUC, you can do a side-by-side install of ADE-19 (co-existing with ADE-18), and 'Open' a ADE Project Backup *.APF file set ...with impunity.


Until Jon states whether that "_nn" suffix *.APF file naming option works OK with ADE-19, I recommend you let ADE do the file naming:


I recommend instead that you use ADE to do this:

ADE Menu > Project > Backup ...to make a saved backup of all project source files, and the latest (if any) MSFS SDK compiled package.


AFAIK, you can then:

ADE Menu > File > Open Project > browse for the latest *.APF

...and the latest ADE Project Backup file set will load (...it does for me, with no errors seen so far aka "Check Complete" is the result).


GaryGB

 

[jgarnold]

Hi Gary

I already have ADE 19 installed just don't use it because of what I mentioned. I will have to read up about the .APF file to see where/how I can use it as I was not aware of it until now.

John

 

[scruffyduck]

well I guess I should tell you that bugs reported in versions other than the latest are ignored, so the only way to get support is to be on the current version. Make backup of your projects and keep them in a separate place for use with 19

 

[jgarnold]

Point taken.
If I find anything in the future using 18 I will see what happens in 19 before reporting.

 

[scruffyduck]

Also I mentioned Breaking Changes earlier. This is a code change which breaks what has gone before and can result in the user having to repeat some work. The point about alpha programs is that breaking changes can be part of development. I generally try to avoid these or put some code in to help the user. In this case I can see a breaking change in handling library objects and custom models due to the bug. Essentially the bug is that ADE is not storing enough information about the object to create a correct placement of the reference point and drag handle. The code can be fixed but I am expecting that users will need to reload their library objects into the LOM and reload custom models. This is to force the collection of the missing data. Right now I can't see a way to automate this for the user.

Watch this space

 

[rhumbaflappy]

Thanks Jon. I will continue using ADE 18.

Why would you continue to use an outdated version? Participants in this public beta are supposed to be using version 19. Questions about the beta should only be related to version 19.

 

[rhumbaflappy]

Works for me in ADE MSFS version 19:

Truthfully, it would work in version 18 as well.

 

[rhumbaflappy]

I have found a problem with the footprints. If you delete an LOM entry, the footprint doesn't seem to get deleted, and adding the model back into the LOM results in the default footprint being saved... where it stubbornly stays, even after the object gets deleted again. So it overrides the new footprint getting placed.

Open a project with a unique library object in the LOM and placed in the airport.

Delete that library object entry in LOM and left-click on the placed object. It should change to a black square in ADE. Close ADE.

Open the file location of ADE 19, open the Global folder, open MFUser folder. Delete the .BIN file that matches the GUID of the object in question. Close the folder and restart ADE. The LOM entry should now be cleaned of the object.

Open ADE. Load the project. You still have a black square for the object's footprint. Left-click on the object and it changes to the default square footprint. Open the LOM. Add the object library and save the LOM. Left-click anywhere on the airport layout and the footprint changes to the correct footprint.

It could be the only problem with the LOM is that the footprint isn't getting generated or overwritten with the object addition if a <GUID>.bin already exists.

 

[scruffyduck]

Thanks Dick. What you describe is certainly part of the problems with the LOM. A footprint will not get deleted if the object itself is. Basically it is currently a mess. The same is probably also true of 1.79

 

[jgarnold]

I hate to say it but the footprints using 19 are ok. Should have gone to Specsavers

I will start using 19 and make backups of my project everytime I do a save.

Thanks for the advice with LOM HOWEVER whenever I add or modify a scenery object (and place it in the appropriate lib folder)
1) Do a BUILD
2) Tools >LOM> select the library > DELETE ALL > SAVE
3) Tools > LOM> ADD FILE > select the appropriate .bgl > SAVE
(I only would get black footprints when opening the project in 19).

Shouldn't that delete and old footprints or do you mean delete the .bgl file and then do the build?

 

[jgarnold]

Well that was short lived.
I copied my 'project' from '18' to '19' (the entire folder in F20 containing my project), started 19, did a BUILD, removed the old LOM, saved, add file .bgl and then started to add (from library) my various pole (be depth). Those with a 'depth' of 10cm and 30cm show a small round footprint and the one with a depth of 50cm shows a large square footprint.

Your thoughts?

Regarding using 'generate footprint icon' in MCX what needs to be done after that action? Export I guess but thought I would check first. When I do that 'action' it removes the image of the pole and I then can't see any footprint HOWEVER that could be because it is only 30cm in diameter as when I choose my dock which is 9M x 3M it displays a large rectangle as expected.

 

[jgarnold]

Why would you continue to use an outdated version? Participants in this public beta are supposed to be using version 19.

As I pointed out before, I always thought that software 'tagged' as a 'beta' version were for those users who wanted to be 'on the team' to test a new version BEFORE it was released and 'let the user beware'.
I used to do heaps of testing when I was in the IT industry and know what testing involves and didn't think I had the time to devote to that.

I now see when looking at Jon's website that as from 2 June it is an alpha release and although one of you may have mentioned 'alpha' previously I didn't notice that - sorry. My only excuse is that it is now 20 years since I was in the IT industry, now fully retired and the grey matter doesn't function as well as it used to.
I will download that version and start using it instead of 18.