srcooke

If you tick yes to use the 'Use General Assignments' first and then the profile of choice do the axis remain ? I had been helping a friend and couldn't understand why he kept losing the axis in profile until for the first time it happened here after years of just selecting the profile. So far using the above step the axis are retained.

There are certainly some strange workarounds in place, the dummy file seems to have used grass paths around the boundary rather than them been actual taxiways.

A workaround would be to create a new scenery folder 'OLD Tempelhof' with a sub-folder 'Scenery' and move the EDDI_AFX.bgl file to that location. Run makerwys and import the AIRAC again in ProATC. Whilst rare you may find this with other scenery entries also.

Just to note the EDDI file is used to exclude the old ILS frequencies of Tempelhof that are now used at Brandenburg to prevent erroneous ILS approaches.

Indeed and is the reason you may not get a takeoff clearance when on the visible hold-short and have to nudge a little further forward.

EGCC hold short at F1 and AFCAD position

Yes the scenery hold short and wigwags exist but not at the 'no draw' position.

I took a look at UK2000 EGPF D1 entry, the hold short line and wigwags are a lot further back from the runway compared to the hold short no draw entry of the afcad. If this were a runway start position it could well be too far back for AI and they would not depart.

My reference to the AIRAC was to indicate these approaches exist and are available to the sim user should entry also be included in the afcad. Yes the images are from the Airport Inspector, this allows you to easily apply the navaid again using AIRAC data. As this was more of a query Pete I wouldn't spend time on adding a function unless a developer requests it. It was an observation the runways.txt file whilst looking at data with a dual ILS that I had configured. I can however forward the afcads if you wish. I would imaging the 'NO DRAW' is used to facilitate the AI holding point, not too far away from the runway, the actual drawn line been placed by a .bgl file at the correct location.

Frankfurt has had dual ILS configuration for its new 07L/25R runway I guess since its opening. The preferred 'Y' approach has a steeper glidepath at 3.2deg. Nuerenburg has a separate LOC and ILS approach, possibly for redundancy. KORD 10R has dual ILS approaches with one been an offset. Some scenery addons such as Aerosoft EDDF are supplied with the dual freq, others not. They are contained in AIRAC data and supported by some addons such as iFly. Personally I use Herve Sors Airport Inspector to add the missing entries. It was a query Pete as to whether makerwys was looking for these.

Hello John/Pete, Should makerwys v4.873 be capturing dual ILS entries for a single runway where they exist eg EDDN EDDF. Runways.txt has the second entry missing although these are contained in the AFCAD and can be tuned on the NAV radio. Here is the EDDN entry for the addon scenery: Runway 10 /28 centre: N49:29:55.4486 E011:04:39.3506 1046ft Start 10 : N49:30:01.7655 E011:03:35.1902 1046ft Hdg: 98.6T, Length 8858ft Computed start 10 : Lat 49.500553 Long 11.059102 Start 28 : N49:29:49.1317 E011:05:43.5096 1046ft Hdg: 278.6T, Length 8858ft Computed start 28 : Lat 49.496922 Long 11.096093 Hdg: 98.600 true (MagVar 3.200), Concrete (Transparent), 8858 x 243 ft Primary ILS ID = INUE Primary ILS: INUE 109.55 Hdg: 98.6 , Flags: GS DME BC "ILS/DME 10" Secondary ILS ID = INUW Secondary ILS: INUW 109.10 Hdg: 278.6 , Flags: GS DME BC "CAT III ILS/DME 28" *** Runway *** EDDN0100 Lat 49.500553 Long 11.059102 Alt 1046 Hdg 95 Len 8858 Wid 243 ILS 109.55, Flags: GS DME BC *** Runway *** EDDN0280 Lat 49.496922 Long 11.096093 Alt 1046 Hdg 275 Len 8858 Wid 243 ILS 109.10, Flags: GS DME BC

Hello Pete, For info the makerwys.exe is identified as v4873 yet the title bar and runways.txt indicate 4872 Make Runways File: Version 4.872 by Pete Dowson

It is a beta update available from the forum Pete.

Using ADE v01.77.6986.18569 and FSUIPC 1.151 and connecting to P3Dv4.5 without issue. Did you install the new P3Dv4 SDK and correct the file paths in ADE.

Does FSC 9.7 even support P3D, even v10 does not: System requirements: Microsoft Flight Simulator X, FSX: Steam Edition or Microsoft Flight Simulator 2004

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. 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.

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.

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.

Clearly I was wrong with regards these scenery's been compiled to the P3Dv4 format and misread a forum post. I'll try and dig further as to why it is these particular entries that are causing issue whereas others do not.

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.

ADE 1.75 located on the forum HERE Pete

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:

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

Seeing the same issue with FSDT & Flightbeam scenery, I suspect this is caused by the AFCAD's been complied to the latest P3Dv4 standard.

Sent you a PM John as this doesn't appear to be an FSUIPC issue.