ILS misalignment

[flyway]

Hey all,
Have searched the forum, but nothing came out.
POH developers are facing a new problem, regrading ILS allignment on photorealistic airbases.
Am sure it’s not only a POH issue much probably many of theater developers in here have came across this problem…
If those airbases reflect IRL alligment, many of the cases, this allignment is not 1deg spot on.
When defining these runways heading in Falcon for a few features like ILS, we heave to sitick to this unity max precision field.
Is there any work around, so we can match perfectly the ILS to the the realistic implemented runways, say ex: heading 192.4ºdeg ?
Thank you very much.

Cheers.

[Mav-jp]

@flyway:

Hey all,
Have searched the forum, but nothing came out.
POH developers are facing a new problem, regrading ILS allignment on photorealistic airbases.
Am sure it’s not only a POH issue much probably many of theater developers in here have came across this problem…
If those airbases reflect IRL alligment, many of the cases, this allignment is not 1deg spot on.
When defining these runways heading in Falcon for a few features like ILS, we heave to sitick to this unity max precision field.
Is there any work around, so we can match perfectly the ILS to the the realistic implemented runways, say ex: heading 192.4ºdeg ?
Thank you very much.

Cheers.

No,
round values only

I suggest you rotate the tile from 0.4 deg , seriously who will notice ?

[neystratiou]

@Mav-jp:

No,
round values only

I suggest you rotate the tile from 0.4 deg , seriously who will notice ?

Hi there Mav.
Well let me describe the problem a little better than “flyway”. The issue is the parallel offset guidance that we have in the photorealistic hand made airports. Means the Localizer don’t guide you over RWY centerline but a little (some time more) parallel offset of it to one side of RWY. Check the below photo to have a good idea of the issue:

So can we move the ILS emitter with some actions, and which are them?
Thanks in advance.
Nikos.

[flyway]

@Mav-jp:

No,
round values only

I suggest you rotate the tile from 0.4 deg , seriously who will notice ?

We’d already figured that out as one solution, but that would mean a tremendous workload and a serious delay in publication of the next POH version…
Is it a near future BMS devs team objective, this correction? I mean having runways heading definitions precision added with at least one decimal figure…?

[Tom Catz]

Depends on your ILS Settings in your DID. You should use the correct heading. Did you tryed heading 230?

[Red Dog]

Depends on your ILS Settings in your DID. You should use the correct heading. Did you tryed heading 230?

incorrect.
It’s not implemented in BMS and even if it was, it wouldn’t impact localizer, it would impact the flight director only

[flyway]

Anyway…. why 230º ?
Anything related to my post?

[Nuno Santos]

@Mav-jp:

No,
round values only

I suggest you rotate the tile from 0.4 deg , seriously who will notice ?

[neystratiou]

If there is no way to can move the ILS emitter, then the only action seems to be the rotation of all the under tiles with all the objects/features over it…
Leaving the ILS at this status at the photorealistic airports is a no go. At least from my point of view.
For the moment seemed to be a rule to be the tiles/laid airport rotated to the nearest integer degree BEFORE inserted into its final position in the theater.
Nikos.

[Nuno Santos]

Bad visibility, strong crosswinds…hell, just point me to the threshold and I’ll take it from there

[Mav-jp]

You can define precisely the position of the emitter as It is the runwayPT of the specific runway

For the alignment , I.e the axis, only ROUND values are taken for the runway direction in the PD/PHD files

No intention to change that.
For MANY reasons you should be sure that your runways are precisely aligned with ROUND values .

I think AI can not approach correctly a 0.4 deg offsetted runway for instance

[flyway]

@Mav-jp:

You can define precisely the position of the emitter as It is the runwayPT of the specific runway

For the alignment , I.e the axis, only ROUND values are taken for the runway direction in the PD/PHD files

No intention to change that.
For MANY reasons you should be sure that your runways are precisely aligned with ROUND values .

I think AI can not approach correctly a 0.4 deg offsetted runway for instance

AI lands perfectly on these runways. Its tested already.
Well, guess that best option will be living with the offset…

[Mav-jp]

@flyway:

AI lands perfectly on these runways. Its tested already.
Well, guess that best option will be living with the offset…

Yeah you are lucky

AI uses heading between runwayPT and TakeoffPt

I can code ILS on that principle as well then since this will be very useful for carrier ILS

[Nuno Santos]

Great news, Mav-jp!
So may we assume by your statement that, on a future update, BMS editor will allow the introduction of decimal numbers, thus avoiding the present missalignments and also allowing more precise rotation for the features also?

[Mav-jp]

@Nuno:

Great news, Mav-jp!
So may we assume by your statement that, on a future update, BMS editor will allow the introduction of decimal numbers, thus avoiding the present missalignments and also allowing more precise rotation for the features also?

no
i mean ILS will not use any runway alignment from DB , only runwayPT and TakeoffPT

dont expect it anywhere before 3 to 4 falcon Weeks, which means NOT a 4.33 update

[Joe Labrada]

@Mav-jp:

no
i mean ILS will not use any runway alignment from DB , only runwayPT and TakeoffPT

dont expect it anywhere before 3 to 4 falcon Weeks, which means NOT a 4.33 update

3-4 weeks are nothing (even Falcon weeks) for us, after 14 years working on a project for a theater that is getting closer and closer to what we have in mind.

Your words fill me with joy.

Thank you very much, on behalf of the entire F4pain team.

[flyway]

Well, any kind of a door unlocking is always an half-step for something to happen…

[Mav-jp]

done

[neystratiou]

@Mav-jp:

done

Well done, then :p.
Nikos.