Don't worry, the airplane is great, same is valid here: do it yourself 😄 It was only an example on how the publisher handles issues or requests and unfortunately that's exactly what I was told back then... The next guy came up with a third party solution. But yes, this is the PMDG forum 😄 we're actually talking about the 747 and THIS issues is easily to resolve for US if we want to risk it.

 

..disregard

Edited October 15, 20187 yr by Wothan

Just for those wondering what this is about:

Default AFCAD for Aerosoft EDDF - Airport map "wrecked":

Notice FPS ~22.

 

My converted AFCAD for Aerosoft EDDF - Airport map "Looks fine":

Notice FPS still at 22 FPS - no performance loss.

 

Topdown view with default AFCAD for Aerosoft EDDF:

Topdown view with converted AFCAD for Aerosoft EDDF - no apparent differences:

 

 

Edited October 15, 20187 yr by Wothan

Although i cant really spot any difference between original and modified AFCAD in your example, it may have some negative effects on other airports using the methods Oliver described. I guess the best workaround would be to allow PMDG EFB to read "custom" BGL's for a certain airports, this way we could have a modified BGLs with taxiways instead of paths which will only be read by PMDG EFB while leaving the actual scenery AFCAD untouched. 

2 hours ago, Woozie said:

Although i cant really spot any difference between original and modified AFCAD in your example, it may have some negative effects on other airports using the methods Oliver described. I guess the best workaround would be to allow PMDG EFB to read "custom" BGL's for a certain airports, this way we could have a modified BGLs with taxiways instead of paths which will only be read by PMDG EFB while leaving the actual scenery AFCAD untouched. 

That actually sounds lik an good idea.

Maybe the AFCADS for the ND map could be called something like: "PMDG_AFX_ZZZZ.xxx" where ZZZZ is the ICAO name for the airport, and .xxx a new file type f.ex *.pam. (PMDG Airport Map), since if it is called BGL, then it will be loaded with the scenery. The *.pam file will in effect be a renamed *.bgl file.

If such an AFCAD exist, then that will be read in favour of the "real" AFCAD. If it does not exist, then the original AFCAD will be read.

Not sure if that would work, but it would be far less intrusive.

Edited October 15, 20187 yr by Wothan

Why not ask to LM to fix that, instead of always find a workaround or blame this or that developer; since FS9 we have always to cheat the platform to fix this and that!

34 minutes ago, simbio said:

Why not ask to LM to fix that, instead of always find a workaround or blame this or that developer; since FS9 we have always to cheat the platform to fix this and that!

I'm not sure that there's anything to 'fix' as - as far as I can see - it's not a bug! 

37 minutes ago, simbio said:

Why not ask to LM to fix that, instead of always find a workaround or blame this or that developer; since FS9 we have always to cheat the platform to fix this and that!

No - it's not a bug, since the AFCAD files where never meant to bu used thks way. But gir PMDG it is the best solution, because the airport layout will always be correct for the airport scenery that is used, despite any incuracies with the scenery itself.

Yeah no bug, its more working around limitations of an ancient system that wasn't designed for today's ultra complex sceneries. It may be a monumental task for LM to revamp it without breaking functionality of existing 3rd party sceneries. And given how long it takes for some scenery designers to update their existing scenery to P3Dv4, we would be in hell for the next 12-24 months. 

47 minutes ago, Woozie said:

Yeah no bug, its more working around limitations of an ancient system that wasn't designed for today's ultra complex sceneries. It may be a monumental task for LM to revamp it without breaking functionality of existing 3rd party sceneries. And given how long it takes for some scenery designers to update their existing scenery to P3Dv4, we would be in hell for the next 12-24 months. 

I agree..

I rather go for Your suggestion about custom .bgl's, but done like I described below Your post.

This would mean that only custom *.bgl's (or *.pam files as I suggest) would be necessary for Airports not compatible with the addon scenery.

1 hour ago, Wothan said:

2 hours ago, simbio said:

Why not ask to LM to fix that, instead of always find a workaround or blame this or that developer; since FS9 we have always to cheat the platform to fix this and that!

No - it's not a bug, since the AFCAD files where never meant to bu used thks way. But gir PMDG it is the best solution, because the airport layout will always be correct for the airport scenery that is used, despite any incuracies with the scenery itself. 

Actually there is a bug.

There is a DrawSurface  parameter in the AFCAD files that is supposed to suppress drawing of taxiways/runways surfaces. However, if set to 0 it is just ignored and the surface is drawn anyway. This has been always the case with FSX and has not changed in P3D. If this parameter was working, scenery developers could use it instead of having to change the type to PATH.

I've created a few sceneries myself and my solution is, when using PATH, to put an apron beneath it.

The AMM will parse the taxi line and will also show a solid surface. Keep in mind though that this only works for small adjustments otherwise its a lot of work.

2 hours ago, mfrantz said:

Actually there is a bug.

There is a DrawSurface  parameter in the AFCAD files that is supposed to suppress drawing of taxiways/runways surfaces. However, if set to 0 it is just ignored and the surface is drawn anyway. This has been always the case with FSX and has not changed in P3D. If this parameter was working, scenery developers could use it instead of having to change the type to PATH.

Yeah I know...

For the airports I have converted so far, the drawing of the taxipath's has no visual influence on the actual scenery, probably because they are drawn beneath the custom scenery, or excluded via some exclude bgl's. 

If that is the case with all  addon airports is questionable, so therefore the solution probably won't work on all airports - so it's down to trial and error.

According to Oliver Pabst, from Aerosoft, these taxiway poly's are drawn by the  GPU, but not necessary visible. Performance wise there is little to no impact on my modest PC system, probably because the taxiway poly's are very low.

I have no idea where to go with this. PMDG' solution, as it is now, is right and a nice feature. But because the issue with many addon airports, using AFCAD files thecway they do, this will often render the Airport Map on the ND unusable, which us a great shame.

I don't think we should rely on LM changing the AFCAD system as it is niw, since that would risc rendering some airport addons inop.

 

MFRANTS:

Did You read my (actual Woozies) suggestion about reading a custom AFCAD just for use by the PMDG airport map ?

Not sure if it's possible, but it' a suggestion for a solution on this issue.

Don't get me wrong I'm not bashing You or PMDG for the current issue, I'm just trying to give some idea's to solve it.

6 minutes ago, Wothan said:

Did You read my (actual Woozies) suggestion about reading a custom AFCAD just for use by the PMDG airport map ?

Not sure if it's possible, but it' a suggestion for a solution on this issue.

Don't get me wrong I'm not bashing You or PMDG for the current issue, I'm just trying to give some idea's to solve it.

This is something that would most likely be better going into a support ticket if you want to make sure they actually see it.

6 minutes ago, Captain Kevin said:

This is something that would most likely be better going into a support ticket if you want to make sure they actually see it.

Don't worry we do monitor this thread 🙂