Jump to content
The simFlight Network Forums

Issues with MakeRunways 4.801


Recommended Posts

I noticed a couple of issues after running Make Runways v4.8.0.1 tonight.  I installed Lorby Si's Addon Organizer.prior to executing MakeRwys.exe

1 - The first time I ran MakeRunways, it created the MakeRwys_Scenery.cfg file in my P3D folder; but it actually read from scenery.cfg in my %ProgramData% folder.

2 - The second time I ran it, it correctly read from MakeRws_Scenery.cfg; but it didn't parse any data from airports installed using the .xml method.  Here's a snippet from the end of Runways.txt (I'm including the last couple of ORBX entries read from the main scenery directory for reference):

=============================================================================
ORBX\FTX_EU\FTX_EU_NOR_05_SCENERY\scenery\ADE_FTX_NOR_NO30.bgl
=============================================================================

Airport NO30 :N58:56:24.3581  E007:41:34.6780  656ft
          Country Name="Norway"
          State Name=""
          City Name="Ose"
          Airport Name="Ose"
          in file: ORBX\FTX_EU\FTX_EU_NOR_05_SCENERY\scenery\ADE_FTX_NOR_NO30.bgl

          Runway 15 /33  centre: N58:56:24.3581  E007:41:34.6958  656ft
              Start 15 : N58:56:29.6708  E007:41:28.2746  656ft Hdg: 148.0T, Length 1365ft 
              Start 33 : N58:56:19.0455  E007:41:41.1152  656ft Hdg: 328.0T, Length 1365ft 
              Hdg: 148.017 true (MagVar -0.500), Grass, 1365 x 0 ft
          Taxiname:  #0 = 
          FSM A/P NO30, lat=58.940109, long=7.692966, alt=656

=============================================================================
Area.216 "FTXAA_ORBXLIBS" (Layer=216)
Path(Local/Remote)=ORBX\FTX_AU\FTXAA_ORBXLIBS

=============================================================================
Area.217 "Imagine Simulation - KATL Atlanta 2016 V4.1" (Layer=217)
Path(Local/Remote)=scenery

=============================================================================
Area.218 "Flightbeam Denver International" (Layer=218)
Path(Local/Remote)=E:\FSDT\Addon Manager\Flightbeam\KDEN\Scenery

=============================================================================
Area.219 "Flightbeam Washington Dulles" (Layer=219)
Path(Local/Remote)=E:\FSDT\Addon Manager\Flightbeam\KIAD\Scenery

=============================================================================
Area.220 "Flightbeam Phoenix Sky Harbor HD" (Layer=220)
Path(Local/Remote)=E:\FSDT\Addon Manager\Flightbeam\KPHX\Scenery

=============================================================================
Area.221 "FsDreamTeam Memphis International" (Layer=221)
Path(Local/Remote)=E:\FSDT\Addon Manager\FsDreamTeam\KMEM\Scenery

=============================================================================
Area.222 "FsDreamTeam Houston Intercontinental" (Layer=222)
Path(Local/Remote)=E:\FSDT\Addon Manager\FsDreamTeam\KIAH\Scenery

=============================================================================
Area.223 "FsDreamTeam Dallas/Fort Worth International" (Layer=223)
Path(Local/Remote)=E:\FSDT\Addon Manager\FsDreamTeam\KDFW\Scenery

=============================================================================
Area.224 "FsDreamTeam Chicago OHareX" (Layer=224)
Path(Local/Remote)=E:\FSDT\Addon Manager\FsDreamTeam\OHareX\Scenery

=============================================================================

 

Link to comment
Share on other sites

On 6/14/2017 at 3:15 AM, mach2000 said:

1 - The first time I ran MakeRunways, it created the MakeRwys_Scenery.cfg file in my P3D folder; but it actually read from scenery.cfg in my %ProgramData% folder.

Yes. That was fixed in 4.801. You must have been running 4.800.

1 hour ago, mach2000 said:

 Issue #2 is not really related to the other thread.

And what is issue #2?

5 minutes ago, srcooke said:

I suspect this is caused by the AFCAD's been complied to the latest P3Dv4 standard.

What has changed?

Pete

 

Link to comment
Share on other sites

Similar to mach2000 post Pete the only entry in runways.txt is:

Area.161 "FlightBeam San Francisco International" (Layer=161)
Path(Local/Remote)=F:\Addon Manager\FlightBeam\KSFO\Scenery

There is nothing else at all.

FSDT have compiled their AFCAD's to the P3Dv4 SDK.

I have tested an Aerosoft scenery that is initially fully identified by makerwys. If I recompile this with ADE for P3Dv4 then the data is also lost

 

Link to comment
Share on other sites

3 minutes ago, srcooke said:

Area.161 "FlightBeam San Francisco International" (Layer=161)
Path(Local/Remote)=F:\Addon Manager\FlightBeam\KSFO\Scenery

There is nothing else at all.

So it doesn't even find files it recognises as containing airports? (AFD files)?

4 minutes ago, srcooke said:

FSDT have compiled their AFCAD's to the P3Dv4 SDK.

I have tested an Aerosoft scenery that is initially fully identified by makerwys. If I recompile this with ADE for P3Dv4 then the data is also lost

I'll have to find the L-M definition of AFD's then. One trouble is  have no such scenery and don't intend to buy any. Is "ADE for P3Dv4"  a new version of Scruffy Duck's ADE editor program? Or do you just point it at the new tools? As it looks like I'll have to recompile some as you did.

It's also rather odd that L-M doesn't seem to have compiled the default scenery with anything which wrecks the old AFD recognition. That's why I didn't realise anything had changed.

Pete

 

Link to comment
Share on other sites

A beta version of ADE 1.75 is required.

There looks to be new attributes available for Runways, Taxiways and Aprons  as posted on the scruffyducks forum:

 

Quote

 

  1. New ID for Runways
  2. New ID for Taxiways
  3. Some sort of change to Aprons

p3d4-materialset.thumb.jpg.e361f2d1aaa5cd7c240c7904e295e31c.jpg

 

 

Link to comment
Share on other sites

3 minutes ago, srcooke said:

A beta version of ADE 1.75 is required.

Ah, okay. Thanks.

3 minutes ago, srcooke said:

There looks to be new attributes available for Runways, Taxiways and Aprons  as posted on the scruffyducks forum:

Someone did tell me about Aprons, but MakeRunways doesn't process those.

But even with such ID changes, the Runways.txt log file should still identify the airports, not just the file path it gets from the CFG file.

Pete

 

Link to comment
Share on other sites

From the makerwys_scenery.cfg generated by Lorby:

[Area.161]
Title=FlightBeam San Francisco International
Local=F:\Addon Manager\FlightBeam\KSFO\Scenery
Layer=161
Active=TRUE
Required=FALSE

Resulting in the previous posting from runways.txt:

=============================================================================
Area.161 "FlightBeam San Francisco International" (Layer=161)
Path(Local/Remote)=F:\Addon Manager\FlightBeam\KSFO\Scenery

=============================================================================

 

The only other entries relating to KSFO are for the stock scenery.

Link to comment
Share on other sites

9 minutes ago, srcooke said:

Resulting in the previous posting from runways.txt:

=============================================================================
Area.161 "FlightBeam San Francisco International" (Layer=161)
Path(Local/Remote)=F:\Addon Manager\FlightBeam\KSFO\Scenery

=============================================================================

 

The only other entries relating to KSFO are for the stock scenery.

Yes, as I said. It appears to not even discover the airport AFD BGLs, so there's more changes than just the 3 IDs you mentioned. Those only come in once an airport file is recognised.

Pete

 

Link to comment
Share on other sites

My tests here with pre-P3D4 sceneries recompiled with ADE 1.75 using the P3D compiler are in direct contradiction to all the reports above.

The resulting Runways.TXT file is certainly not bereft of all information. Everything is found AND the same as in original (pre P3D4 compiled) file EXCEPT, crucially, all the Runway data, and the Taxiway paths.
 
The basic Airport Data is there (name, country etc), as are COM frequencies, TAXIPOINTS, GATES and TAXINAMES. 
 
If this is the case with BGLs specifically designed for P3D4 (rather than a recompiled P3D3 compatible format) then the amount of work trying to decode the binary is a lot less than if there’s no clue at all – as appears to be the case in your results.
 
It won’t be something I would be willing to tackle without format information being supplied. I might ask L-M if they can supply this, otherwise it will wait for some of the clever person with much time on their hands to do the job.
 
Meanwhile, for my use of P3D4 I will stick to my P3D3 sceneries used in P3D4 by using effectively the same SCENERY.CFG (after the defaults).
 
Pete
 
Link to comment
Share on other sites

31 minutes ago, jabloomf1230 said:

The only item that was added to the BGL format that affects ADE is the ability to support P3d materials. It is of minor consequence unless a developer wants to take advantage of this new feature.

Not really talking about additions. I'm looking for the same information as I always did -- only stuff in airport records, nothing else.

The ID codes for the Runway entries and the TaxiPath entries are different. I can see that. They are also different sized structures. So this certainly means a different structure format. Whether there's additional information there I do not know, and I don't think "materials" figure in basic airport data, do they?

This is only with a pre-P3D4 BGL re-compiled with the new BGL compiles, after using ADE 1.75 to decompile the original. With a scenery designed explicitly using new facilities, I might not even get the parts I can currently see. I just don't know at present.

I will be looking into it, of course, but if things aren't reasonably quickly discernible I would have to shelve it for a while, and preferably wait either for some young hacker to decode it, or maybe get L-M to suply documentation.

Pete

 

Link to comment
Share on other sites

Hello Pete,

I found the reason for makerwys not seeing the FSDT & Flightbeam scenery entries, the add-on.xml entries defined by the installers go too deep:

eg.
\Addon Manager\Fsdreamteam\KCLT\Scenery

rather than to the scenery root:
\Addon Manager\Fsdreamteam\KCLT\

Apologies for taking your time on this.

Link to comment
Share on other sites

26 minutes ago, srcooke said:

I found the reason for makerwys not seeing the FSDT & Flightbeam scenery entries, the add-on.xml entries defined by the installers go too deep:

eg.
\Addon Manager\Fsdreamteam\KCLT\Scenery

rather than to the scenery root:
\Addon Manager\Fsdreamteam\KCLT\

You are using AddOnOrganizer? I'll ask the author to check for that if so. MakeRunways itself doesn't look for any XML files.

I've been experimenting by treating the new IDs as if they were the same as the old ones. and I've found that, although the structures are loger (extra information), the first part is exactly like the old. Only the length of each part is longer, but I am not using the extra information, whatever it is.

I've tested version 4.81 here with ADE 1.75 recompiled scenery the one you sent me) and it works exactly the same now as with FSX-format sceneries. I can't guarantee it will apply to new P3D4-dedicated sceneries though.

Get 4.81 using the llink below, and try it please. If there are any problems with specific BGLs, please do send me them (just the AFD BGL) so I can see what's up. (petedowson@btconnect.com).

MakeRwys481_TEST.zip

Pete

 

Link to comment
Share on other sites

The add-on.xml entries for FSDT and Flightbeam were created vendors installers, the problem was not created by Lorby's addon manager.

Scenery's worked with or without the full path to /scenery so not sure why FSDT have set then this way.

 

Link to comment
Share on other sites

6 minutes ago, srcooke said:

The add-on.xml entries for FSDT and Flightbeam were created vendors installers, the problem was not created by Lorby's addon manager.

No, but the AddOnOrganizer is supposed to provide me with the correct SCENERY.CFG by analysing the XML files. It needs to be able to correct for such installers, especially if those entries still work fine with P3D.

7 minutes ago, srcooke said:

Scenery's worked with or without the full path to /scenery

Exactly. So AddOnOrganizer needs to deal with it.  

Or perhaps MakeRunways should work if a regular SCENERY.CFG path includes the Scenery part? Do you know if 3D works with such paths? I'll have to try it.

Anyway, please do try MakeRwys 4.81 and let me know.

Pete

 

Link to comment
Share on other sites

2 hours ago, Pete Dowson said:

Do you know if 3D works with such paths?

The scenery will still load in P3D having replaced the add-on.xml entry with path \Addon Manager\FlightBeam\KDEN\scenery set in the scenery.cfg.

2 hours ago, Pete Dowson said:

Or perhaps MakeRunways should work if a regular SCENERY.CFG path includes the Scenery part?

I'm not sure of the purpose of adding the /scenery part, certainly removing it from the xml makes no difference to the scenery use.

Additionally FSDT added the texture path:

<?xml version="1.0" encoding="utf-8"?>
<SimBase.Document Type="AddOnXml" version="4,0" id="add-on">
  <AddOn.Name>FsDreamTeam KJFK</AddOn.Name>
  <AddOn.Description>FsDreamTeam New York JFK V2 International Airport scenery</AddOn.Description>
  <AddOn.Component>
    <Category>Scenery</Category>
    <Path>F:\Addon Manager\FsDreamTeam\KJFK\Scenery</Path>
    <Name>FsDreamTeam New York JFK V2</Name>
    <Layer>167</Layer>
  </AddOn.Component>
  <AddOn.Component>
    <Category>Texture</Category>
    <Path>F:\Addon Manager\FsDreamTeam\KJFK\Texture</Path>
    <Type>GLOBAL</Type>
  </AddOn.Component>
</SimBase.Document>

again to what purpose I have no idea as removing the texture entry the scenery still works.

Until such time there is a better understanding of the layout and if Lorby could remove the /scenery part when generating the scenery.cfg then it may be the better option for makerwys just now.

 

I have re-compiled an add-on scenery with ADE 175 following some amendments and can confirm makerwys reads the new entry without issue.

 

Link to comment
Share on other sites

22 hours ago, Pete Dowson said:

Not really talking about additions. I'm looking for the same information as I always did -- only stuff in airport records, nothing else.

The ID codes for the Runway entries and the TaxiPath entries are different. I can see that. They are also different sized structures. So this certainly means a different structure format. Whether there's additional information there I do not know, and I don't think "materials" figure in basic airport data, do they?

This is only with a pre-P3D4 BGL re-compiled with the new BGL compiles, after using ADE 1.75 to decompile the original. With a scenery designed explicitly using new facilities, I might not even get the parts I can currently see. I just don't know at present.

I will be looking into it, of course, but if things aren't reasonably quickly discernible I would have to shelve it for a while, and preferably wait either for some young hacker to decode it, or maybe get L-M to suply documentation.

Pete

 

Pete,

 

I don't want to completely derail this user support thread, but here's a comparison of the "tail end" of the Runway entries between the V3 SDK:

http://www.prepar3d.com/SDKv3/LearningCenter/environment/compiling_bgl.html#Runway

and the V4 SDK (which can't be directly linked, so here's the entry):

 

Quote

 

secondaryPattern (optional)Indication of pattern orientation for secondary heading (optional)LEFT, RIGHT. Default is LEFT.

primaryMarkingBiasBias from the end of the runway for primary markings.Distance in feet, nautical miles, or meters (F, N or M suffix).

secondaryMarkingBiasBias from the end of the runway for secondary markings.Distance in feet, nautical miles, or meters (F, N or M suffix)

.materialSet (optional)MaterialSet guid to override default seasonal materials. The MaterialSet order should be Winter(0), Hard Winter(1), Spring(2), Summer(3), Fall(4). If not all seasons are filled out, will select first material in set.GUID in the format:

{nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn}

The structure (materialSet)  that you referred to contains the seasonal material set GUIDs that allows differing materials to be used for runways during the 5 P3d "seasons". I apologize for not writing more clearly in my previous post above. I'm not sure why LM changed the IDs, but a few other utilities don't work correctly (yet) because of this change. Actually, the more that I think about it, this was to differentiate between runways with and without the materialSet entry. I could be wrong on that, though.

Jay

Link to comment
Share on other sites

4 hours ago, srcooke said:

The scenery will still load in P3D having replaced the add-on.xml entry with path \Addon Manager\FlightBeam\KDEN\scenery set in the scenery.cfg.

Ah, in that case MakeRunways should cope. I'll look at that.

But this is a change from FS9 and FSX days, as the folder needed to point to the palce where both Scenery and Texture folders were to be found.

Also it presumably means that the folder name need not necessarily be SCENERY. What happens then, if there are other subfolders? I often save diused BGLs in a subfolder inside the scenery folder called "saved". And I have seen scenery folders inside scenery folders.

Something is wrong with this design!

4 hours ago, srcooke said:

Additionally FSDT added the texture path:

Ah, so perhaps this design is intended to allow tetures for a scenery to be kept somewhere else, maybe even conglomerated with others from different layers?

4 hours ago, srcooke said:

Until such time there is a better understanding of the layout and if Lorby could remove the /scenery part when generating the scenery.cfg then it may be the better option for makerwys just now.

The only danger in that is where someone has decided to have a scenery folder within a scenery folder. I'm just not sure how this is all supposed to work sensibly, as per my worries above.

4 hours ago, srcooke said:

I have re-compiled an add-on scenery with ADE 175 following some amendments and can confirm makerwys reads the new entry without issue.

Thanks. Now I really need is someone to test with genuine P3Dv4-targetted scenery now.

Pete

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.