Texture Bleed Through

[swiss1]

J have the similar issue at start-point 5, (see attached picture with the old Afcad-file!). The scenery is compatible with many other mesh and scenerie, when properly installed ,
(I will talk about later).  I think it's not a scenery behind neither a mesh or traffic file problem but a Afcad problem. The Afcad of FSDream is not properly aliigned with the default scenery , (AP949150).

Altitude: default scenery: /   430.072 m (JABBgl prg)// FSDream scenery: 430.070 m
Set-point loc: default scenery:/ N46*1428-E6*06.533// FSDream scenery: N46*1429-E6*06.544
Start-point 5: default scenery:/ 46*13.566-E6*05.481// FSDream scenery:  46*13.566-E6*05.497
Magnetic Heading(new file AvSim):  default scenery:/ 45.5°//FSDream scenery: 45.8°.

With the new Afcad file in the hot-Fix,  the texture aligne is very bad

Except this small issue, it's just a fantastic and realistic scenery!!

[attachment deleted by admin]

[Sylle]

I think it's not a scenery behind neither a mesh or traffic file problem but a Afcad problem. The Afcad of FSDream is not properly aliigned with the default scenery , (AP949150).

Hello Swiss,

if you only have the FSDT afcad and the stock FS2004 afcad (that resides in the AP949150.bgl), the default FS2004 afcad will be supressed by the FSDT afcad file. The problem comes from the lsgg.bgl file in the FSDreamTeam scenery folder as I described in the previous post.

I'm glad you confirmed the misalignment of the displaced threshold arrows with the new afcad. You will notice however that with the new afcad file the white threshold line itself will be correctly located.

Regards,
Sylvain

[virtuali]

a/ I started to look extensively to find another AFCAD file for LSGG. I couldn't find any except the stock one contained in the AP949150.bgl file. Even with this general bgl-file disabled I still had double markings in your scenery.

It's not only an AFCAD that might have created your problem. If it is an altitude difference problem, it might have created by a mesh as well.

b/ I decided to remove all the files form the FS Dreamteam LSGG folder to another location and insert them again in small groups to check the effect in FS.

This would not change anything. The actual location doesn't matter at all, the scenery.cfg layer number matters, and how exclusion areas are made. And, in case of mesh, the scenery.cfg doesn't matter anymore, but only the mesh resolution so, an higher resolution mesh will always "win", regardless of were is the scenery layer.

My conclusion is that the new FSDT AFCAD file indeed better matches the scenery but we need a new lsgg.bgl without the second set of displaced threshold markings...

But the "scenery" that the AFCAD better matches to IS LSGG.BGL!! And, of course, the problem doesn't appear here, so we are back at square one, to understand why you see duplicated marking and I don't...or, better yet, why you see the duplicated markings with a *much* bigger offset than they should.

[Sylle]

Good evening Virtuali
Thank you for your fast replies. I hope we will find a solution in the end.

It's not only an AFCAD that might have created your problem. If it is an altitude difference problem, it might have created by a mesh as well.

Everything looks good when I have all the FSDT bgl files installed EXCEPT the lsgg.bgl file. Please have a look again at my screenshot number 3 "all files except lsgg.bgl.jpg" I would expect to see the altitude problem as well then if it is caused by an altitude difference problem? Is this assumption correct?

If it is an altitude difference problem, it might have created by a mesh as well.

I haven't installed extra mesh in FS apart from mesh that would come together with a scenery. I have always stayed clear from products as FS global for exactly this reason. I know it is not very helpful as you can't check this for 100%.

b/ I decided to remove all the files form the FS Dreamteam LSGG folder to another location and insert them again in small groups to check the effect in FS.

This would not change anything. The actual location doesn't matter at all, the scenery.cfg layer number matters, and how exclusion areas are made. And, in case of mesh, the scenery.cfg doesn't matter anymore, but only the mesh resolution so, an higher resolution mesh will always "win", regardless of were is the scenery layer.

I already knew this 
By moving files to another location I ment physically taking the files out of the FSDT LSGG folder and put them in a folder on a separate harddisk which is not taken into account by the scenery.cfg file. (All my scenery folders listed in the scenery.cfg file are in my main FS9 folder on the C-drive)
That is how I managed to 'build up' your scenery step by step to see which file caused the double arrows.

But the "scenery" that the AFCAD better matches to IS LSGG.BGL!! And, of course, the problem doesn't appear here, so we are back at square one, to understand why you see duplicated marking and I don't...or, better yet, why you see the duplicated markings with a *much* bigger offset than they should.

As far as I could see on my test, your lsgg.bgl file not only contains the approach lights system but also a set of displaced threshold arrows. Is this mandatory? Like an automatic addition when you create the approach lights system??
Is it maybe possible for you to recompile the lsgg.bgl to only contain the approach lights? (and not the arrows which are already displayed by the afcad file)
Just wondering...

Thanks for your help on this matter.

Cheers,
Sylvain

[Sylle]

Is it maybe possible for you to recompile the lsgg.bgl to only contain the approach lights? (and not the arrows which are already displayed by the afcad file)

Try with this set of files here:

Virtuali,

Replacing both files enabled me to get rid of the double arrows but the white threshold line across the runway was again too much forward just like when iusing the first version of the afcad file.
I therefore replaced this afcad file again with the one I could download in the hotfix topic.
The white line across the threshold is now back at the correct spot and I no longer have the double arrows. (pic 1 & 2)

Problem is definately solved by day but... I no longer have approach lights at night. (pic 3)

I have no idea why the markings seem to be displaced compared to your install but in my case at least the solution seems to rely in a modification of the lsgg.bgl file. I think we are getting closer...

Thanks again for the assistance!

Cheers,
Sylvain

[attachment deleted by admin]

[swiss1]

 Just to clarify :
With the Hotfix Afcad (22.12.2008) and the new LSGG.bgl available in this Forum (23.12.2008) the
problem seems to be also solved for me. (see picture). Many thanks for this Christmas gift!
But I am convinced, that it's not a mesh problem . I have FSGlobal at very low priority and a more precise Swiss mesh fromLago between and every works.
I have also FSDT Zuerich, which is also perfectly integrated.

[attachment deleted by admin]

[martyc]

Same to me : applying the new afcad file and the lsgg.bgl file available on that topic results in great and fixed scenery the day, but no more approach lights on runway 05 at night, approach lights of runway 23 partially OFF and also edge lights of the runway dimmed too much versus the previous release. I precise also that I have no mech added at all for switzerland. Just the ultimate terrain Europe.

[M-Sauce]

Just to clarify :
With the Hotfix Afcad (22.12.2008) and the new LSGG.bgl available in this Forum (23.12.2008) the
problem seems to be also solved for me. (see picture). Many thanks for this Christmas gift!
But I am convinced, that it's not a mesh problem . I have FSGlobal at very low priority and a more precise Swiss mesh fromLago between and every works.
I have also FSDT Zuerich, which is also perfectly integrated.

I don't think it is fixed, you are still showing double threshold lines and you have runway sidestripes. On Virtuali's screenshot of what the runway should look like, there are no side stripes. I've only found one pic of the LSGG runway on the thread about "Texture Problems", the promotion screenshots did not show any runway screenshots.

For some reason LSGG's runway does not look that good. This bleed through only happens in LSGG, and not in all the other FSDT runways (LSZH, KORD, KJFK). Did you guys change the method of making runways?

The other thing is that if we are forced to use the AF2 that came with the software, that really limits the capabilities of the scenery. I myself enjoy making AF2s that closely resemble the real airport layout and won't be able to do so with LSGG.

Mariano 

[Sylle]

I don't think it is fixed, you are still showing double threshold lines and you have runway sidestripes. On Virtuali's screenshot of what the runway should look like, there are no side stripes. I've only found one pic of the LSGG runway on the thread about "Texture Problems", the promotion screenshots did not show any runway screenshots.

Mariano,

I guess the double threshold lines will stay but they should be on top of each other when using the afcad file you can find in the hotfix topic. Virtuali changed the distance of the displaced threshold compared to the afcad that came with the setup of v1.1.

The runway sidestripes are due to different default FS runway textures I think. Virtuali confirmed that Geneva partially uses FS default runway textures. The runway textures I use also contain a runway sideline.

Apart from the fact you better not change the runway characteristics in the afcad file, I don't think you will encounter a lot of problems to further modify the afcad file of LSGG.

Lets wait and see if Umberto finds a way to add the approach lights without adding the displaced threshold arrows in the lsggg.bgl file...

Cheers,
Sylvain

[virtuali]

If you download the new lsgg.bgl and af2_lsgg.bgl from the Hotfixes post, they should be ok now.

I've deleted the ones from the forum post, they were provisional anyway.

[swiss1]

With the latest files in the hot-fixes, every thing is perfect now at day an also the night-lights.
Thanks very much and merry Christmas.

[Sylle]

I'm happy to report that all the problems are now solved on my side as well!!

Merry Xmas everyone!

Regards,
Sylvain

[MikeS]

Hi

It works indeed and resolve some small visible problems. But it's not the right way I guess because it generate new ones. Why? The way to solve this problem was to eliminate the displaced threshold in the AFCAD (which btw. is not the updated AFCAD of Harpsi anymore, that contained all the updates we made like corrected taxiways, gates and the double Holding-Point bars...). The further bad side-effect of deleting the displaced threshold is, that the AI-Aircrafts don't touching down now at the point they should. They touching down now directly on the theshold-bar but they should do this in the touchdown-zone, around 300m after the threshold. AI-Traffic respects only the AFCAD and not the visible scenery! You cannot simply delete some relevant things. Due to the the early touchdown, the AI's which landing on Rwy 05 turning now back into Exit E for vacating the runway.
The right way to fix this problem of the double visible displaced threshold markings would be, to delete the displaced threshold markings of the scenery (lsgg.bgl), but only the markings, not the appr-lights! Then move the threshold-bar in the AFCAD to the right position. Please take a look on this again.

I wish a merry christmas to all!!

[virtuali]

But it's not the right way I guess because it generate new ones.

It's the right way, because it's the only one, which give at the SAME time: increased ground quality, compatibility with FSX without redoing the scenery from scratch for FS9 (there would be no FS9 scenery to begin with, in this case)

Why? The way to solve this problem was to eliminate the displaced threshold in the AFCAD (which btw. is not the updated AFCAD of Harpsi anymore, that contained all the updates we made like corrected taxiways, gates and the double Holding-Point bars...).

We'll integrate his fixes in our AFCAD anyway.

The right way to fix this problem of the double visible displaced threshold markings would be, to delete the displaced threshold markings of the scenery (lsgg.bgl), but only the markings, not the appr-lights! Then move the threshold-bar in the AFCAD to the right position. Please take a look on this again.

Don't you think that we did the fix the way it has been done, it's because we ALREADY tried what your are suggesting, and this obviously didn't work ? The threshold markings in lsgg.bgl are ALREADY flagged as not visible. However, it appears that FS9 doesn't honor this flag, and if there is a threshold of any lenght, it will always displays the markings, regardless if the visibility flag is set to 0, like in fact it is.

If you download the AFCAD again (from the Hotfixes), I restored the threshold as it was, but also added the latest taxiway/parking layout from Harpsi's AFCAD.

However, the double threshold markings are now back, SLIGHTLY visible, but it's either this, or the other way. As I've said, since FS9 simply ignore the 0 to the theshold markings parameter, it doesn't look to be possible to get rid of those markings. And, deleting the threshold in the background runway, wouldn't work as well, because it would affect the runway lights.

[MikeS]

It's the right way, because it's the only one, which give at the SAME time: increased ground quality, compatibility with FSX without redoing the scenery from scratch for FS9 (there would be no FS9 scenery to begin with, in this case)

Ok, good point! But one with a lot restrictions for FS9    But if it finally works (what it appears do be now after all), well, it's more than ok now, I guess

We'll integrate his fixes in our AFCAD anyway.

Great! Thank you!

Don't you think that we did the fix the way it has been done, it's because we ALREADY tried what your are suggesting, and this obviously didn't work ? The threshold markings in lsgg.bgl are ALREADY flagged as not visible. However, it appears that FS9 doesn't honor this flag, and if there is a threshold of any lenght, it will always displays the markings, regardless if the visibility flag is set to 0, like in fact it is.

Huuh, ok, I didn't know that. You never explained, that it didn't works too in the scenery designer tool. But now it's consistant to me.

However, the double threshold markings are now back, SLIGHTLY visible, but it's either this, or the other way. As I've said, since FS9 simply ignore the 0 to the threshold markings parameter, it doesn't look to be possible to get rid of those markings. And, deleting the threshold in the background runway, wouldn't work as well, because it would affect the runway lights.

You'll don't believe it, but your actual accommodations are nearly the same way I did this morning (before I read this new posting...) But how you did it without this four arrows at the threshold bar? The visible ones are only the ones oft the lsgg.bgl and are not doubled by the arrows of the AFCAD, right!? In AFX I also don't see this four arrows. How you did this?? In mine, the arrows are still there but covering the ones of the lsgg.bgl nearly perfect like the other arrows on the centerline in your actual file. I found no way, to deactivate this four arrows. Do you have a hint for me?

But as a simple conclusion for the actual files: Just perfect now!!! Thanks!