Runway Decompile Error

I'm having a slight problem with the new 0.91.2628 update. I was able to open APX25160 in the 0302 folder just fine with SDE 0.91.2624, but when I try to open the same .bgl after installing the new jmFlightSimLib.dll file, I get the following error message:

Decompiler Output...

. 3284 39672 13 ... Airport
. 42956 37820 13 ... Airport
. 80776 29216 8 ... Airport
. 109992 24764 13 ... Airport
. 134756 10440 10 ... Airport
. 145196 20356 4 ... Airport
. 165552 20844 6 ... Airport
. 186396 11376 5 ... Airport
. 197772 57232 28 ... Airport
. 255004 48308 19 ... Airport
. 303312 106224 31 ... Airport
. 409536 85796 25 ... Airport
. 495332 100480 29 ... Airport
. 595812 45328 17 ... Airport
. 641140 90844 27 ... Airport
. 731984 258084 23 ... Airport

ByteArray Error Exception of type 'System.OutOfMemoryException' was thrown.


ByteArray Error Exception of type 'System.OutOfMemoryException' was thrown.


ByteArray Error Exception of type 'System.OutOfMemoryException' was thrown.


ByteArray Error Exception of type 'System.OutOfMemoryException' was thrown.

=======Error Caught========
Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: startIndex
at System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument argument, ExceptionResource resource)
at System.BitConverter.ToInt16(Byte[] value, Int32 startIndex)
at ScruffyDuck.Flightsim.Scenery.SceneryObject.AirportRecord.Runway.Decompile(Byte[] rawdata)
at ScruffyDuck.Flightsim.Scenery.SceneryObject.AirportRecord.Runway..ctor(String objectName, Byte[] rawdata, Int32 offset, SceneryBase parent)
at ScruffyDuck.Flightsim.Scenery.SceneryObject.Airport.Decompile(Byte[] rawdata)
at ScruffyDuck.Flightsim.Scenery.SceneryObject.Airport..ctor(String objectName, Byte[] rawdata, Int32 offset, SceneryBase parent)
at ScruffyDuck.Flightsim.Scenery.SceneryFile.ObjectFactory.New(String newType, String newName, Byte[] rawdata, Int32 offset, SceneryBase parent)
at ScruffyDuck.Flightsim.Scenery.SceneryFile.ObjectFactory.New(SceneryObjectType newType, String newName, Byte[] rawdata, Int32 offset, SceneryBase parent)
at ScruffyDuck.Flightsim.Scenery.SceneryFile.SceneryFile.processAirport(Int32 pointer)
at ScruffyDuck.Flightsim.Scenery.SceneryFile.SceneryFile.processGeneralSection(SectionPointer currentSection)
at ScruffyDuck.Flightsim.Scenery.SceneryFile.SceneryFile.decompileFull()
at ScruffyDuck.Flightsim.Scenery.SceneryFile.SceneryFile.Decompile(DecompileType decompileType)
==========


If I replace the newer jmFlightSimLib.dll file with the old one, it opens again with no problems. Any clue on what the problem could be?
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Let me check it out. It looks like the de-compiler has lost the plot...........
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
OK This is a problem that I have seen a few times. The old engine avoided it, but in doing so did not always get the last entry in the runway record so things like Vasis etc could go missing. The new Engine deals with this but the old problem returns. I can fix it easily enough by ignoring it but I would like to get to the bottom of it once and for all. This may take a little time.

In the meantime if any one else sees this problem please report it in this thread. Thanks
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Quick Update

The problem is with Runway 07 at KDET. BglAnalyzeX also stops reporting an unknown type in the runway record. The hunt goes on.............
 
We already had a previous problem with KDET somewhere back in all these threads on one of the builds.

I can't remember what we found but I thought at first it was the unattached taxiway.

I am trying to search for those post but if I recall the actual problem was not with KDET 07 but another airport close by. It could have been a no draw hold short node. I just can't remember!!!

EDIT

I found the thread

I took KDET a part and it appears that RW07 was not closed after the displaced threshold with

</Runway>

possibly causing the Runway records to be corrupt.

I also found in the Taxiway points a no_draw

<TaxiwayPoint index="75"
type="HOLD_SHORT_NO_DRAW"
orientation="FORWARD"
lat="N42 24.45309"
lon="W083 0.13920"/>

That will not compile and I have never seen a type="HOLD_SHORT_NO_DRAW"
before.

I had to remove _NO_DRAW so the compiler would match index 75 to 90


FSX did connect the taxiway to rwy07 which FS9 did not attach as per my picture

Another stab in the dark to see if this could be the problem.


I have confirmed that the

</Runway>

missing after RWY 07 is the problem.

Once I added it and put the displaced thresholds plus the PAPI4 that also was missing back into the runway records SDE opened the new compiled APX25160 bgl with no problem
 
Last edited:

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Hi Jim

I thought it seemed familiar. I want to understand what is in the record though as clearly it was compiled at some point using BglComp and there should be a safe way to handle this. Also there may be more examples that we have not turned up yet.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
OK I have reached one ending with this. There is a record with the ID 0x0065 (101 decimal) that is inside the runway record. It is 16 bytes long and is mostly empty. There was a bug in SDE when encountering a unknown Id in a runway record. I have fixed this so SDE will handle it correctly and actually indicates it's existence in the object tree.

I will do some searching to see if this exists at any other airport.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
I have a way on the development version of SDE to read every record in every scenery file automatically. Using this reveals that there are only two runways in the whole default set that have this extra '101' record of 16 bytes. They are (as we know) R07 at KDET and also R15 at PAWD. No other runway has this.

So maybe someone can determine the common denominator :)
 
Top