CTD when Building a package after duplicating objects - bug and workaround

I’ve encountered a very nasty bug in the Scenery Editor. From a certain moment it began to CTD every time I tried to build a package. Even when I took out all new models to make sure only previously working models are present. What’s actually happening in XML file is when you duplicate an object, the name is appended with a " (copy)". So, an object “My Object” becomes “My Object (copy)”. When it gets duplciated, the name becomes longer, and when you duplicate many objects in succession, the name becomes “My Object (copy) (copy) (copy) (copy) (copy) (copy) (copy) (copy) (copy) (copy) (copy) (copy)”.

After a dozen or so of " (copy)" the project just CTDs without any error messages in the log. Now once I duplicate more than a few objects, I open the XML in Notepad++ and replace all " (copy)" with “”. And voila! It compiles fine again.

Very nasty. It should not append the name to be so long, especially when duplicate name is apparently OK. Or it should just place “(copy 2)” and just increase the number on every duplicate, not add another " (copy)". The strings that it eventually makes are ridiculous. And it should through an error in console instead of CTD anyway…

I hope it gets fixed, or at least somebody finds the workaround useful. I spent a lot of time figuring it out…

It’s not memory or resources, I have RTX 3080 / Ryzen 9 9000X / 64Gb RAM / dedicated 2TB SSD.

Update: this is happening routinely when duplication objects. Removing " (copy)" works.

New bug: just by working with Scenery Editor, XML gets screwed very regularly, with either CTD or compilation failing with a useless error message (XML validation error - line, column) - and it literally says “line, column…” instead of giving the error line!

I had to use external validator (XML Tools plugin for Notepad++) and it shows this kind of error. This is happened to me several times with similar kind of gobberish in XML, rendering it unworkable:

Removing those characters works. I had this in other places too, but this one seems connected to the “(copy)” problem again.

When you design your scenery, better name your objects. When you place them, you change the name to the name in your design. That is the only way to find them back. This “copy” thing via “duplicate” is a very lazy mode of operation and it will bring you in trouble anyway, when scenery gets complex. Avoid the “duplicate” option I would say… or use “duplicate” and rename right away. You can also group certain small objects in Blender into a local assembly consisting of 1 object. That will make your scenery faster… and your scenery list shorter.

There is no sense to name each and every little apron and bush and cone and trolley. It would add a huge amount of unneeded work. Large and important objects are unique, but hundreds of clutter objects are not worth naming or renaming. If they are generic MSFS objects I don’t need to look for them by name, I can just point and click. Every marking group on my runways are custom aprons, cracks on pavement, etc. And all generic vehicles etc. - it would add up to extra hours of work for no reason…

It’s a lot of work, but in the end you have a better project. You can modify things.
Apron3Building15North is easier to locate than Apron(copy)(copy)(copy)(copy)(copy)

I mean, imaging naming every little line and ground marking, container and vehicle, loader and cone etc. in here…

And regardless, this should NOT result in CTD. There should be an error thrown, and names should just increase a numner, like “(copy 24)” - this would make sense, unliek have 24 of “(copy) (copy) (copy)”…

If the number will increase instead of this senseless word multiplication, the building would be automatically names “Apron3Building copy 15” which would be just fine. And won’t CTD.

I don;t advocate CTD’s.

I advocate naming.

And if you can avoid CTD’s by naming… this (copy)(copy)(copy) why leave it ? If you copy a file in Windows you leave the name on (copy) ? Or you place it in a new directory ? Building15Apron3. The third apron “under” that building. Whatever. As long as you know you can find it back 3 weeks later…

A practice that will add hours of work, without saving any time is not a good practice. Names are fine, but they won’t be seen by anyone, and hours naming things don’t justify the marginally easier task of finding them later (if at all).

Ok, so you make a scenery in one go without errors. No need to correct anything. You must be very talented :slight_smile: