FSDreamTeam forum
FS9 support => Geneva FS9 => Topic started by: M-Sauce on December 21, 2008, 08:29:16 pm
-
Anybody else getting this? I used to have the Dream Factory Studio version, but I fully unistalled it before installing FSDT version. Somthing is definitely peeking through though. I am using a third party mesh from FS Genesis. That is the only add-on that might show for the Geneva Area. Any suggestions? Anybody else get this?
Mariano ???
[attachment deleted by admin]
-
OK, some of the things I tried which where unsuccesful;
- Terrain max vertex level; Changed from 19 to 21 and back
- Disabled all the FS Genesis meshes by removing them from the World folder
- Moving LSGG to the top of the priority list
Still can't fix this problem.
Mariano ???
-
Hello Mariano!
I lso observe some texture bleedthrough on my setup
- No third party mesh installed here.
- No duplicate AFCADs.
I succesfully uninstalled the Dreamfactory Studio LSGG scenery a long time ago but I can't exclude the fact that there may be some leftovers somewhere in my FS9 install. :-\
Could it be that it is part of the scenery to simulate older and worn-out markings??
Let's wait for the feedback of other users...
Cheers,
Sylvain
-
Hello,
we found the problem, and it appears to be FS9 only. You can download a fix now, by going in the "Hotfixes" section, and download the AFCAD again.
NOTE: the problem can't really be 100% eliminated, due to the way the ground scenery is made however, it should be a lot less noticeable now, and it affects only the displaced threshold markings.
-
Could it be that it is part of the scenery to simulate older and worn-out markings??
Just read the other topic about ground textures and it is definately not worn-out markings... :D
Looking further into this matter,
S.
EDIT: Thanks Virtuali! Looking forward to test the new AFCAD!
-
Unfortunately the new AFCAD makes the problem worse here :(
At least we confirmed it has something to do with the AFCAD now...
Regards,
S.
[attachment deleted by admin]
-
Unfortunately the new AFCAD makes the problem worse here. At least we confirmed it has something to do with the AFCAD now...
No, we confirmed only that is has to do with *an* AFCAD, not necessarily the one that comes with Geneva. This is how it looks like here:
[attachment deleted by admin]
-
Unfortunately the new AFCAD makes the problem worse here. At least we confirmed it has something to do with the AFCAD now...
No, we confirmed only that is has to do with *an* AFCAD, not necessarily the one that comes with Geneva. This is how it looks like here:
Hello Virtuali,
My runways looked like the screenshots Mariano posted in the beginning of this topic.
I only replaced my AFCAD with the new AFCAD you provided in the hotfix section so this file definately has some influence on the markings issue.
It looks good on your side now... Could you tell us what you changed in the AFCAD compared to the first one so that I can try to tinker with the same parameters to make it match on my side?
Regards,
Sylvain
-
Virtuali,
I notice your runway texture looks a bit different than mine...
Is this due to different graphic cards or settings??
Does your LSGG runway uses some parts of the default FS runway textures??
I have some replacement textures for the default FS runway textures... maybe they also influence the postion of the displaced threshold markings...
Cheers,
Sylvain
-
I only replaced my AFCAD with the new AFCAD you provided in the hotfix section so this file definately has some influence on the markings issue.
Not so simple, as usual...
yes, the AFCAD has some influence on the markings, but the one that should be identified in YOUR case, is the other one that is interfering, ours is now more properly matched to the scenery itself.
What you are seeing, looks also like a difference in altitude, because the double markers might also due to a perspective effect of seeing two AFCAD at a slightly different altitude.
Our AFCAD is of course set at the correct real world altitude, which is 403.0728 meters (1411 ft) BUT, there's a bug in FS9 AFCAD that, if one creates or edits an airport with it, the fractional part is lost.
In order to not hit into this bug, we compile the AFCAD with the BGLC compiler, but other AFCAD you might have might have been compiled with the AFCAD utility itself, and have this bug, with a small altitude difference, that is enough to create that effect.
-
Does your LSGG runway uses some parts of the default FS runway textures??
Yes.
I have some replacement textures for the default FS runway textures... maybe they also influence the postion of the displaced threshold markings...
No, because runway textures are just the base textures. Markings are not textures and are added by FS9 itself always in the same way, regardless if the underlying texture has been replaced.
-
Hello,
we found the problem, and it appears to be FS9 only. You can download a fix now, by going in the "Hotfixes" section, and download the AFCAD again.
NOTE: the problem can't really be 100% eliminated, due to the way the ground scenery is made however, it should be a lot less noticeable now, and it affects only the displaced threshold markings.
It did not only affect to the displaced thresholdmarkings. It did it to the Holding point-Markings too! But I've found a way to eliminate the holding-point markings of the AFCAD-file by reducing the wide of the taxiway-sectors before and after the holding-points to only one feet. Now the markings ar not drawn anymore (to small) and there are only the markings of the scenery visible. The 1 feet width fortunately has no negative influence to AI- or other operations. (It's already included in the actual AFCAD)
Nothing has changed at the AFCAD-runways since the first AFCAD!
Best regards
Mike
-
But I've found a way to eliminate the holding-point markings of the AFCAD-file by reducing the wide of the taxiway-sectors before and after the holding-points to only one feet.
Yes, in FSX there's an official AFCAD command to do just that, and that's probably why we haven't noticed it before in FS9.
-
But I've found a way to eliminate the holding-point markings of the AFCAD-file by reducing the wide of the taxiway-sectors before and after the holding-points to only one feet.
Yes, in FSX there's an official AFCAD command to do just that, and that's probably why we haven't noticed it before in FS9.
Hehe, yes I know, there are some advantages with FSX indeed...sometimes... :P
Mike
-
Hello again Virtuali,
I think I found the origin of the problem...
The file lsgg.bgl (containing the approach lights) also contains a set of displaced threshold markings.
With the new AFCAD file the displaced threshold markings are no longer co-located.
Let me explain here below how I came to this conclusion. I apologize in advance for the long post ;)
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.
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.
c/ With only the FSDT afcad, the excludes & several other files activated you can see that the AFCAD file itself does not contain touchdown zone markings or runway centerline markings. The afcad file only draws the displaced threshold arrows and the white threshold line.
See picture 1
d/ Adding some more bgl files, you see the runway markings appear together with another threshold line which is colocated with the threshold line of the afcad file. The holding points markings are not colocated but this can be fixed as described by MikeS.
Picture 2A and 2B
e/ All FSDT LSGG files are now back in place EXCEPT the lsgg.bgl file.
Markings of the displaced threshold are still ok but I miss of course some approach lights at night now.
The holding point markings are still displaced for the same reason as described in point d.
Picture 3 and 4
f/ If I add lsgg.bgl I get the displaced markings. (all files are now back in place)
picture 5
g/ If I remove the FSDT afcad file, the default FS9 stock afcad (AP949150.bgl) kicks in. You can see another set of runway centerline markings, a second runway designator and completely different threshold markings. No other afcad for LSGG is present is this shot and the problem still exists!
picture 6
h/ When using the old FSDT AFCAD file, stock afcad file is suppressed and you can see that the threshold arrows are now co-located but the white threhold line itself is not in the correct spot.
picture 7
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...
Is this possible Virtuali?? ???
I hope this helps you to solve this issue.
Regards,
Sylvain
[attachment deleted by admin]
-
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]
-
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
-
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.
-
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
-
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]
-
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]
-
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.
-
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 :(
-
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
-
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.
-
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.
-
I'm happy to report that all the problems are now solved on my side as well!!
Merry Xmas everyone!
Regards,
Sylvain
-
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!!
-
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.
-
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!
-
What I don't understand, is why this is a problem in LSGG and not in the other 3 airports you made. What specifically has changed in the way you make runways for FS9 and FSX that is making this such an issue?
Mariano ???
-
What I don't understand, is why this is a problem in LSGG and not in the other 3 airports you made.
Because we don't use always the same methods, regardless of the airport. Each one has different requirements, so the methods are not always the same.
What specifically has changed in the way you make runways for FS9 and FSX that is making this such an issue?
Apart with the fact that the issue is now basically fixed, and it's really due to the fact there's a bug in FS9 that makes impossible to disable the displaced thresholds markings so, with a runway without displaced thresholds there would be no issue to begin with, what has changed is the different ways of creating ground, which allows much better sharpness at Geneva than, for example, JFK (no, it wouldn't be possible to use the same method at JFK, because is simply too big) AND keeping compatibility with FS9 AI in FSX, AND keeping sort of compatibility between FSX and FS9 that allows us to still support FS9.