Crash Boxes Off

[falcon409]

The scenery I'm finishing up has a large number of grass objects. As it turns out I failed to get the crash boxes turned off so now when someone taxi's into the infield grass they trigger a crash. I loaded one of the two bgl files that contain the grass (each bgl contains about a dozen variations of various grasses). I set the exporter to show "No Crashes" true, which I assume means just that. . .no crash boxes. How do I apply that to all of the various objects without doing each one individually then reloading the bgl and doing each one in succession?

I thought about doing a batch conversion but I don't see an option under "operator" that fits what I want to accomplish.

 

[falcon409]

Still messing with this and as far as I can see (with "show crash box") selected from the MCX menu, the compiles I've done after changing the "exporter" information have indeed removed the crash boxes. I am using two types of grass ONLY in this scenery and both have been recompiled and then checked for crash boxes. Both are showing no crash boxes. Despite that I still record a crash when I taxi across the grass. The only other thing I have in that area is the photoreal ground texture. . .nothing else. . .so why is it still showing a crash?

 

[GaryGB]

Hi Ed:

Perhaps this thread describes a similar scenario ?

http://www.fsdeveloper.com/forum/threads/still-having-invisible-crash-boxes.407962/



As Crash Boxes are added by the FS SDK MakeMDL and XtoMDL compilers (when handed-off for export by them "outside" MCX), if MCX does not show a crash box after the exported MDL files are (re-)imported into MCX for inspection (after double-checking that the MCX Icon for display of Crash Boxes is toggled "on"), then it is unlikely that any such Crash Boxes are present inside the MDLs.


Another way to test this, just to be certain, is:

1.) De-compile a copy of the placement BGL output by Instant Scenery

2.) Using a XML-capable editor (such as NotePad++ etc.):

a.) via Search and Replace, edit the XML placement code for the Grass scenery library objects


[EDITED]

1.) under each <SceneryObject placment "element" section, and before the closing </SceneryObject> line

(a) add the optional "<NoCrash/"> XML element

(b) the optional "<NoCrash/"> XML element must appear both before and after certain other optional Scenery object data elements in a specified order ...as alluded to here:

http://www.fsdeveloper.com/forum/threads/noautogensuppression.19971/


...and as Arno alludes to here:

http://www.fsdeveloper.com/forum/th...n-crash-for-already-exported-mdl-files.14602/


...and as the FS SDK docs describe here:

"The following elements can be added to a SceneryObject, but contain no additional attributes or elements, so are entered into the XML, for example, as <NoAutogenSuppresion/>."

https://msdn.microsoft.com/en-us/library/Cc526978.aspx#XMLFormat


See this example and brief discussion:

http://www.fsdeveloper.com/forum/threads/noautogensuppression.19971/


Between that and the positioning of the example "<BiasXYZ" XML element shown in the SDK Docs:

https://msdn.microsoft.com/en-us/library/Cc526978.aspx#XMLFormat


...I must conclude that the positioning of the <NoCrash/> element is to be above the ex: <LibraryObject element ...in scenery library object placement XML source code.

[END_EDIT]


NOTE: I would have to refresh my memory on this, but ISTR conflicts were reported when multiple such optional elements were used in one's BGLComp placement code, resulting in ex: flickering when <NoAutogenSuppression/> and <NoShadow/> are both used.


But... again, it may also have had to do with the order in which multiple such optional elements were added below the scenery object element section, as this may have been an "un-documented" requirement ...when applying multiple such optional elements:

http://www.fsdeveloper.com/forum/threads/noautogensuppression.19971/


PS: You may wish to use these options in IS3 via the object properties check-boxes for an object placement BGL, then de-compile the BGL to see how they have been inserted into the XML code.


CAVEAT: One must enable display of those above optional element check-boxes in the IS Object Properties dialog ...via the IS 'Options' dialog: "Show Extended Object Properties".


Hope this info might help with troubleshooting !

GaryGB

 

[falcon409]

As always Gary, a very comprehensive answer. I appreciate the information. Back tracking just a bit to reiterate that re-compiling the grass objects via MCX with the "Exporter" set to "no crash boxes" appeared to work correctly. . .when rechecked in MCX none of the version of various grass elements showed a crash box. Take those objects a step further to Instant Scenery 3 placement in the sim, am I to take from this that IS3 actually disregards the material settings and attaches a crash box back on each object it places?

My reasoning here is because after loading IS3 just a while ago and selecting a small group of grass objects to test, I checked the Object Properties box for "no crash box". Closed IS3, closed the sim and then restarted. I was able to taxi through the grassy area without any crash being detected.

Your suggestion to edit the IS3 placement xml and add the "No Crash" line for each of the grass objects listed sounds like an easy way to go, using the search and replace option but there are almost 2600 entries that require that additional line which isn't actually a replacement, it's actually an addition so it'll take a bit to add it to all of the selections, lol. It's either that or load the scenery and slew around the airport selecting each of the 2600 clumps of grass to make the change in the properties box. . . .I wish IS3 would leave well enough alone and quit changing material settings that have been previously compiled. The same problem was seen when I was working on Old Reinebeck for the Golden Age Simulations project where the NoAutogenSuppression tag had to be manually set in the xml file and the bgl recompiled in order for it to take effect.

 

[=rk=]

How did you do it with Reinebeck? Open the document as text and select "Edit>Replace." Copy past this into the "Find what" field, "</SceneryObject>" and this into the "Replace with" field, "<NoCrash/></SceneryObject>." The whole procedure will take less time than typing this sentence, unless you already started doing it by hand. In that case you'd have to do a find, "<NoCrash/><NoCrash/></SceneryObject>", replace with, "<NoCrash/></SceneryObject>" pass in order to clear everything up.

 

[GaryGB]

Hi Ed:

Indeed, as Rick explained in further detail above, one can essentially allow the text editor to do the "replace all" procedure automatically, given the correct "Find" and "Replace" strings.


I'll have to test this later this morning on a different computer to refresh my memory on this, but IIRC, depending on which text editor one uses for the XML edits, one can also insert the carriage return code between the "<NoCrash/>" and "</SceneryObject>" strings in the 'Replace with' field.


However, IIRC, BGLCOMP will still tolerate the edited line (as it supports XML element sub-sections entered in the "wide" display format) if implemented as Rick shows above ...without the 'extra' carriage return.

[EDITED]

PS: I'll also try to test the possibility of Instant Scenery version 3 adversely affecting display "elements" such as "<NoCrash/>" in the XML code of the placement BGL format which it writes ...after checking the check-box for that "<NoCrash/>" option in Object Properties.

[END_EDIT]


Hope this helps a bit more !

GaryGB

 

[falcon409]

Ok, I have hundreds of lines of errors when compiling the bgl file. Are there supposed to be quotes before and after the No Crash line or was that used for emphasis here?

000001 <?xml version="1.0" encoding="ISO-8859-1"?> <<<<
000002 <!-- Created by Scenery Design Engine (SDE) on 9/7/2015 -->
000003 <FSData
000004 version="9.0"
000005 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
000006 xsi:noNamespaceSchemaLocation="bglcomp.xsd">
000007 <SceneryObject
000008 lat="47.4895824864507"
000009 lon="-123.133270740509"
000010 alt="0.0M"
000011 altitudeIsAgl="TRUE"
000012 pitch="0"
000013 bank="0"
000014 heading="292.8955078125"
000015 imageComplexity="NORMAL">
000016 <LibraryObject
000017 name="06cd881a425e316bc1753989a25f92ba"
000018 scale="1.00"
000019 />
000020 <NoCrash/></SceneryObject>

This is the line it goes to when I select "Show XML Line" using Scruffyducks Xml2Bgl program

 

[=rk=]

The excerpt you have posted implies that at line 20 that the Scenery Object closing command (</SceneryObject>) might have to be on line 21 for the entire statement to work. That observation would be consistent with Gary's comment about a carriage return and this part of his post:

1.) under each <SceneryObject placment "element" section, and immediately before the closing </SceneryObject> line
(a) add the optional "<NoCrash/"> XML element
GaryGB

I had not noticed the word "line" which is probably important and will prevent Notepad from performing the edit.

 

[falcon409]

Thanks, I'm currently editing 2600 sections of xml code to split the two elements. I'd like to wring the neck of the guy who wrote IS3 and in his wisdom decided that stripping or discounting elements of a compiled object bgl was the way to go.

 

[GaryGB]

Hi Ed:

Indeed, as Rick explained in further detail above, one can essentially allow the text editor to do the "replace all" procedure automatically, given the correct "Find" and "Replace" strings.


I'll have to test this later this morning on a different computer to refresh my memory on this, but IIRC, depending on which text editor one uses for the XML edits, one can also insert the carriage return code between the "<NoCrash/>" and "</SceneryObject>" strings in the 'Replace with' field.


However, IIRC, BGLCOMP will still tolerate the edited line (as it supports XML element sub-sections entered in the "wide" display format) if implemented as Rick shows above ...without the 'extra' carriage return.

The excerpt you have posted implies that at line 20 that the Scenery Object closing command (</SceneryObject>) might have to be on line 21 for the entire statement to work. That observation would be consistent with Gary's comment about a carriage return and this part of his post:

I had not noticed the word "line" which is probably important and will prevent Notepad from performing the edit.

Hi Ed:

Sorry for the delay in finding and linking to this info for you.

I usually use WordPerfect (payware) to edit XML, with output to a ASCII DOS TXT file format, re-named to XML.

But perhaps this info on <CRLF> codes within Replace All features of freeware text editors or MS-Word may still help reduce the manual workload (...which I suspect may already be furiously underway on your keyboard) ?

http://www.ultraedit.com/support/tutorials_power_tips/ultraedit/multiline_find_replace.html

http://www.anysitesupport.com/notepad-find-and-replace-with-carriage-return/

https://support.microsoft.com/en-us/kb/214204



Hope this might still help; after one gets the sometimes mind-numbing method down for these occasionally-needed XML edits, the "Replace All" feature in text editors can truly be nearly instantaneous when retro-actively fixing de-compiled BGLComp placement BGL files ...as Rick described above.

GaryGB

 

[falcon409]

Well, this has turned into a nightmare. The decompiler "bgl2xml" is stripping some close statement characters (/>) so not only are those a cause for consternation but having to hard return manually all 2600 instances of <NoCrash/></SceneryObject> has become a total waste of time. I intend to go into the scenery, slew around the grassy areas and select areas that can be used for parking off the rwy and tag them as "No Crash" in the IS3 properties box.

I thank all who contributed to this discussion.

 

[GaryGB]

Hi Ed:

AFAIK, IS3 only writes "placement" code in the BGLs it creates using a proprietary scenery placement XML compiler that is nearly identical in output format ...to that of FS SDK BGLComp itself.

IIUC, IS3 will also put a few proprietary code blocks into the BGL which allows it to use the BGL as a 1-piece file while it performs object placement tasks.

All that propietary "work" XML code can and is stripped out when IS3 placement BGLs are de-compiled, then re-compiled via FS SDK BGLComp.

When desired, after placing even "1" scenery library object and saving that placement into that re-compiled BGL (via IS3 GUI), that BGL is again considered acceptable and re-usable by IS3 for any needed 'edits' (...and will again contain a small amount of "work" code, and will again be subject to total control by IS3).


The substantial difference in how IS3 operates compared to other scenery library object placement tools (-except for perhaps, Lamont Clark's "Whisplacer" ? ), is that IS3 takes total control over object display for scenery library objects placed via IS3.


When we have saved any changes into a scenery placement BGL created or edited by IS3, IS3 will assume total control over display (or non-display) of objects "placed" by that BGL.

When that scenery placement BGL is "Opened" by IS3 as the (only) file currently able to be 'edited' in any way by IS3, and if in fact any changes are saved into that placement BGL by IS3, this engages the mechanism of total control exerted by IS3 over all objects placed by that BGL.

The objects placed that BGL will only be visible for the remainder of the FS session when IS3 is loaded, and that BGL must be manually re-loaded via the IS3 GUI after exiting that FS session and re-starting FS.


FYI: If we subsequently "Open" yet another scenery placement BGL in IS3 as the (only) file currently able to be 'edited' in any way by IS3 (regardless of whether any changes were saved into the previously "Opened" placement BGL by IS3), any such BGL previously "Opened" by IS3 for editing or simply to enable display ...will remain "active" in FS under the auspices of- and under the control of- IS3, and thus any objects "placed" by that BGL will also have their display enabled as long as the FS session continues.


CAVEAT: After exiting FS, any placement BGLs previously opened / edited by IS3 will NOT have object display enabled, and one would have to again manually "Open" those BGLs to enable display of any objects placed by those BGLs.


The objects seen on-screen during placement, or after placement, are being displayed via OpenGL under the auspices of the Instant Scenery module, and not by FS itself.

IIRC, those 3D objects seen on-screen while being placed / manipulated by IS3 when such a placement BGL is created / editing placement properties, or when simply opened to enable display after re-starting FS, are NOT the original 3D object MDLs being called from inside the scenery object library.

AFAIK, those objects seen on-screen are separately-created "proxy" objects 'derived' from the original MDLs ...used by IS3 to allow display via OpenGL technology (which is distinct from any 3D object display also cincurrently taking place via FS' default Windows DirectX sub-system.


So, to be certain one is seeing the intended 'normal' display of 3D scenery objects as a function of their material properties and BGLComp 'placement' display parameters / element modifiers etc. via FS' on-screen rendering engine by means of the Windows DirectX sub-system:

* after completing each editing session wherein changes are saved into a BGL via the IS3 GUI, one must exit FS

* MOVE the placement BGL to a new location that IS3 does not "know" about.

* re-start FS

* add a new 'active' Area layer to FS scenery library for the BGL's new location


This should allow "normal" display of your custom 3D scenery objects by FS ...via DirectX


BTW: Your custom 3D MDLs for scenery library objects placed via IS3 are NOT kept or copied inside the "placement" BGL file, and still remain un-altered inside your original scenery object library.


Be aware of the fact that as soon as one opens that placement BGL and saves any changes into it via the IS3 GUI, IS3 will once again "know-where-it-lives", IS3 will resume total management of display, and IS3 will substitute 3D object "proxies" ...rendered on-screen via OpenGL rather than via DirectX.


Hope this helps explain a bit more of the methods and technology IS3 uses (as I have come to understand its evolution over the years ...since I first began using the same author's Abacus EZ-Scenery in FS2002, and during the course of the IS2 Beta program).


PS: I sent you a PM here at FSDeveloper.

GaryGB

 

[GaryGB]

Well, this has turned into a nightmare. The decompiler "bgl2xml" is stripping some close statement characters (/>) so not only are those a cause for consternation but having to hard return manually all 2600 instances of <NoCrash/></SceneryObject> has become a total waste of time. I intend to go into the scenery, slew around the grassy areas and select areas that can be used for parking off the rwy and tag them as "No Crash" in the IS3 properties box.

Hi Ed:

I haven't personally seen errors involving deleted "close statement characters (/>)" working with BGL2XML versions 1.3x through 1.5x, so I just wanted to be certain that there was no mis-understanding of where the "close statement characters (/>)" should- and should not- be located in your XML code for your scenery object placement BGL.


The following is (edited) FS SDK docs example XML placement code:

https://msdn.microsoft.com/en-us/library/Cc526978.aspx#XMLFormat

<?xml version="1.0"?> <-- FSX object placement files always begin here
<FSData

version="9.0"
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:noNamespaceSchemaLocation="bglcomp.xsd" >​

<SceneryObject <-- this object's placement section ('element') begins ('opens') here

lat="N47 25.89"
lon="W122 18.42"
alt="0"
altitudeIsAgl="TRUE"
pitch="0"
bank="0"
heading="0"
imageComplexity="NORMAL">​

<NoAutogenSuppression/> <-- this object's additional "sub-element" begins and ends on 1 'line'
<NoCrash/> <-- this object's additional "sub-element" begins and ends on 1 'line'
<NoFog/> <-- this object's additional "sub-element" begins and ends on 1 'line'
<NoShadow/> <-- this object's additional "sub-element" begins and ends on 1 'line'
<NoZWrite/> <-- this object's additional "sub-element"begins and ends on 1 'line'
<NoZTest/> <-- this object's additional "sub-element" section begins and ends on 1 'line'​

<LibraryObject

name="{93802d8b-ba4f-45eb-a272-9f029a0feeb3}"
scale="1.0"/>
​

</SceneryObject> <-- this object's placement section ('element') ends ('closes') here

<SceneryObject <-- this object's placement section ('element') begins ('opens') here

lat="N47 25.89"
lon="W122 18.42"
alt="0"
altitudeIsAgl="TRUE"
pitch="0"
bank="0"
heading="0"
imageComplexity="NORMAL">​

<NoAutogenSuppression/> <-- this object's additional "sub-element" begins and ends on 1 'line'
<NoCrash/> <-- this object's additional "sub-element" begins and ends on 1 'line'
<NoFog/> <-- this object's additional "sub-element" begins and ends on 1 'line'
<NoShadow/> <-- this object's additional "sub-element" begins and ends on 1 'line'
<NoZWrite/> <-- this object's additional "sub-element"begins and ends on 1 'line'
<NoZTest/> <-- this object's additional "sub-element" section begins and ends on 1 'line'​

<LibraryObject

name="{93802d8b-ba4f-45eb-a272-9f029a0feeb3}"
scale="1.0"/>
​

</SceneryObject> <-- this object's placement section ('element') ends ('closes') here

</FSData> <-- FSX object placement files always end here


Thus, each SceneryObject placement "section" will begin and end its "element" without any inter-posed "close statement characters (/>)" as shown (...aside from each independent "sub-element" which opens and closes all on 1-line, as illustrated in the example posted above).


PS: Some types of "airport" objects utilize a similar structure, with numerous lines of code and sub-elements appearing in between the 'Open' and 'Close' statements for those objects ...without any inter-posed "close statement characters (/>)".

I mention this in case, on a future occasion, you inspect a de-compiled "airport" BGL.


Hope this helps !

GaryGB

 

[gaputz]

Gary, do you know if this editing method works for FS9 xml placement code?

Greg

 

[GaryGB]

Yes, but one must re-compile with the FS2004 SDK BGLComp.exe after editing with use of any applicable FS2004 BGLComp.xsd compliant differences in XML syntax, and with use of the FS2004 legacy GUID format for objects.

BGL Compiler SDK 1.0
FS2004 BGL Compiler SDK

Watch This Resource

• Overview
• Version History

The BGLComp SDK describes the latest version of the BGL scenery language compiler.

http://www.fsdeveloper.com/forum/resources/bgl-compiler-sdk.39/


FSX BGL Compiler SDK:

The Compiler and File Formats

https://msdn.microsoft.com/en-us/library/cc526978.aspx#GUIDFormats


FSX GUID format:

http://lc0277.gratisim.fr/sceneobjects/

ag_watertower_1
{93802D8B-BA4F-45EB-
A272-9F029A0FEEB3}
size: 7.47, 27.42, 7.51

http://lc0277.gratisim.fr/sceneobjects/autogen/{93802D8B-BA4F-45EB-A272-9F029A0FEEB3}.jpg



FS9 GUID Format:

a00b1fb9451d269931bd129284319dae


NOTE: Conversion performed via a utility by Don Grovestine (aka "gadgets"):

GUID Processor 1.0

GUID Processor

Watch This Resource

• 
  
  
  • Overview
  • Version History

GUID Processor is a small utility developed for my own use that will:

* create new GUIDs using the standard Microsoft NET.Framework capability, and
* automatically convert GUIDs between FS9 and FSX formats

http://www.fsdeveloper.com/forum/resources/guid-processor.99/


Equivalent FS2004 BGLComp placement XML code:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- Created by Scenery Design Engine (SDE) on 8/12/2017 -->
<FSData
version="9.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="bglcomp.xsd">
<SceneryObject
lat="N47 25.89"
lon="W122 18.42"
alt="0.0M"
altitudeIsAgl="TRUE"
pitch="0"
bank="0"
heading="0"
imageComplexity="NORMAL">
<LibraryObject
name="a00b1fb9451d269931bd129284319dae"
scale="1.00"
/>
</SceneryObject>
</FSData>


De-compilation performed via a utility by Jon Masterson (aka "Scruffyduck"):

BGL2XML version 1.50 - Bgl2Xml_GUI.exe

http://www.scruffyduck.org/bgl2xml/

[EDITED]

PS: Since it is not clear from some references to implementing "NoCrash" for FS2004 MDLs in scenery library format:

https://www.scenerydesign.org/page/12/

https://www.scenerydesign.org/2013/06/bglcomp-sceneryobject-flags/

http://nzff.org/viewtopic.php?f=2&t=4068&sid=76736f90b38c43f51583cab3cb46217c


...perhaps this info might help understand whether one may use <NoCrash/> with FS2004 BGLComp ?


https://translate.google.com/transl...fc2.com/BglComp/checknocrash.html&prev=search

[END_EDIT]


Hope this helps !

GaryGB

 

[gaputz]

Yes, but one must re-compile with the FS2004 SDK BGLComp.exe after editing with use of any applicable FS2004 BGLComp.xsd compliant differences in XML syntax, and with use of the FS2004 legacy GUID format for objects.

{snip}

PS: Since it is not clear from some references to implementing "NoCrash" for FS2004 MDLs in scenery library format:

{snip}

...perhaps this info might help understand whether one may use <NoCrash/> with FS2004 BGLComp ?


https://translate.google.com/transl...fc2.com/BglComp/checknocrash.html&prev=search

Hope this helps !

GaryGB

Thank you for a very detailed response. I am very grateful. After following through your instructions I tried editing the xml placement file with <NoCrash/> but I cannot get it to recompile. I will keep experimenting but I wonder if anyone can report success with this edit?

Cheers, and thanks again Gary.

Greg

 

[GaryGB]

Hi again:

It is not clear from any documentation I have seen yet whether the "NoCrash" attribute can be implemented via BGLComp XML placement code for FS2004 MDLs packaged as scenery library objects.


Thus far I have found only 1 other mention of implementing "NoCrash" for FS9 MDLs via an AttachPoint:

https://blogs.technet.microsoft.com/torgo3000/2005/11/14/attach-point-xml-in-x-files/

How many scenery library object placements do you need to use the NoCrash attribute with that involve unique and distinct MDLs ?

GaryGB

 

[arno]

The BGLComp NoCrash option is FSX only, it didn't exist in FS2004. You can make part of the model NoCrash with the AttachPoint type as Gary mentioned indeed.

 

[GaryGB]

Hi Arno:

When I import to ModelConverterX (aka "MCX"), the example MDL cited immediately above (object 124 of 219) in:

[FS2004 install path]\Scenery\Generic\scenery\Generic.bgl

...the MCX Attached Object Editor does not appear to offer the option to add a "NoCrash" AttachPoint.

http://www.fsdeveloper.com/wiki/index.php?title=ModelConverterX#Attached_object_editor


Is there a way to implement NoCrash into exported scenery library object / placement "geo-locked" BGLs via MCX using the method alluded to in this link: ?

https://translate.google.com/transl...fc2.com/BglComp/checknocrash.html&prev=search


...or should one instead 'disable crash detection' by enabling NoCrash for each exported FS9 MDL via: ?

MCX Menu > Options > Exporter settings > MDLWriter > NoCrash = True


Alternatively, one may of course 'disable crash detection' for all objects in FS9 at run time via the FS9 GUI Menu option, or by editing the 'active' FS9.Cfg file.

GaryGB

 

[arno]

Hi,

You are right, MCX doesn't support the NoCrash part attribute at the moment. It would not be an attachpoint in MCX, but would have to be an attribute of the ModelPart itself. Might be interesting to check if this can be supported as well. I'll have a look.

For the moment all you can do in MCX is toggle the crash box for the entire object with the settings.