texture overlaps runway.

[Guest Dominique]

Hi guysI do a new runway from scratch for the first time.I did it with AFCAD at 3400 feet (both RW and airport) and made a plateau with the flatten function of FSFC also at 3400 feet.I see the runway all right from a little altitude but closer it tends to progressively disappear. At first the texture runs over the sides (see the overlapping triangles)and then very close it disappear entirely around the aircraft. Same if I put the RW a tad higher say 3400.2.I do something wrong somewhere but where ? Dominique

[Guest VSQ]

Hi,It seems that the flatten function does not work for runways.Regards,Val

[Guest Dominique]

thanks, next question would be how do you get your priorities straight so as to get your runway showing up OK on top of the terrain as in the stock or 3rd party sceneries ?

[Guest VSQ]

Hi,I solved this problem, using another tool to make the runway, e.g. Airport from Tom Hiscox.Regards,Val

[arno 1]

Using airport for windows is not a perfect solution, as it does not use the modern XML code. So you would still have to make something in AFCAD as well to get the AI working etc. I suspect something is wrong with the flatten.Did you say you made it with FSSC? Maybe you can try to make a LWM polygon as flatten. You can make these with SBuilder for example or (a maybe simpler tool) is [a href=http://www.FS-traveler.com/Flatten.shtml]FsFlatten[/a].

[Guest Dominique]

thanks you guysyou mean my flatten is somewhat corrupted or the flatten function is dysfunctional in general ?How come default or 3rd party airports are OK :-) ?

[saabpilot 0]

I have a similar problem. Until now I have only made scasm scenery which works 100% OK.But since scasm compilations might not be supported in FSX I am now trying to make pure XML scenery with the airport "ground" laid out with AFCAD 2 and MDL 3D objects with FSDS 3.Normal 3D objects causes no problems at all.Main severe problems:The former flattens made with Area16 methods (scasm) does not seem to work at all but I have not yet tried the LWM method.Any XML "Ground polygons" flickers big time so cannot be used.There is no way to stop this since you cannot tell the graphics engine of the display order. In scasm you can do that with the use of Z-bias.Ground polys are used for, among other things, stand info on apron surfaces.There are no way I can see to program a "light" to shine in a fixed direction - only "omnidirectional". This was easy in scasm. My XML programming skills are zero so would appreciate any help on this.There are no way to put lines on the apron like red and blue lines close to the gates (fire zone and no vehicle zones).Anyone has knowledge how to overcome the above?Bjorn

[Guest Bell206freak]

Here's another suggestion.. If you are just wishing to "flatten" the terrain in the immediate vicinity of the airport's runway, all you have to do is insert an apron texture in AFCAD right under the runway. It works every time for me, and I used it to get rid of the same exact side effect I had at Sanderson Field during the beginning of the revamp development.Give that a shot.-Steve

[saabpilot 0]

Hi Steve,The field I am working with has phototexture so that approach will not work in this case I believe since the "apron" properties does not have as far as I can see a transparent texture choise.Bjorn

[Guest Dominique]

I did a Q&D trial and it works for me too :-) ! Thank you Steve for the tip !Dominique

[arno 1]

Hi Bjorn,>The former flattens made with Area16 methods (scasm) does not>seem to work at all but I have not yet tried the LWM method.If you are trying to switch to the new techniques, I would indeed advice the LWM polygon. That is also how MS does it in the default scenery.>Any XML "Ground polygons" flickers big time so cannot be>used.>There is no way to stop this since you cannot tell the>graphics engine of the display order. In scasm you can do>that with the use of Z-bias.Do you mean the ones your create with AFCAD or ones created as MDL files? In the last case this is logical, as MDL object are not supposed to be used as ground polygons (the code is simply not suitable for that). Best way is to place these still with the Fs2002 techniques (old GMax gamepack for example), then you can give them the correct LayerCall so that they behave as ground polygons.>There are no way I can see to program a "light" to shine in a>fixed direction - only "omnidirectional". This was easy in>scasm.Do you mean in the MDL files again? This is possible by using the LIGHT_LAND option as described in the MakeMDL SDK. Unfortunately there is a little bug in MakeMDL, so you will have to tweak the resulting object a lit bit to get your light working.>There are no way to put lines on the apron like red and blue>lines close to the gates (fire zone and no vehicle zones).Nope, this is a real pity. It is high on my FsX wishlist, hopefully MS will listen to this :D. For the moment I still draw my marking with older commands, although I also know people who draw them in GMax.

[saabpilot 0]

Hi Arno,Thanks for the clarification.LIGHT-LAND as well as the TAXI variant are as far as I know restricted to a certain small number, what I need are some 50 lights affixed to light poles (to form 3D approachlights). This is easy in scasm but I believe not so with BGLC or BGLcomp.The ground polys are not the AFCAD "aprons" but polys made in FSDS3.(Could be Gmax too as the resulting BGL via FS2004 gamepack will be the same).I will test the ground polys with BGLC (FS2002 gamepack) and see if they work, but as it seems impossible to make a full scenery with XML code and BGLcomp only one has to use other means so scasm ground polys might at the moment still be the way to go.In FSX, BGLC compilations (= FS2002 gamepack) as well as Scasm compilations are both "threated animals" as I understand it while BGLcomp BGL:s most likely will be supported.Hopefully when we get FSX there will be improved tools available that can give us the means and methods we need and or least come to par with the possibilities in the present scasm compiler.BestBjorn

[arno 1]

Hi Bjorn,>LIGHT-LAND as well as the TAXI variant are as far as I know>restricted to a certain small number, what I need are some 50>lights affixed to light poles (to form 3D approachlights). >This is easy in scasm but I believe not so with BGLC or>BGLcomp.Sorry, but that is nonsense. If you use SCASM or BGLC, you can create exactly the same BGL file with it (on bit level). BGLComp is different, but there is no option to create that kind of lights in the XML code. They should be in your MDL object.The only limitation you have is the performance of your PC. I once did a test with about 600 lights on poles and that killed my performance rather well. But this would be the same for SCASM and BGLC (the SCASM Light command is the same as BGL_LIGHT in BGLC).>The ground polys are not the AFCAD "aprons" but polys made in>FSDS3.>(Could be Gmax too as the resulting BGL via FS2004 gamepack>will be the same).Yes, these are known not to work correctly. The code of the MDL object is simply not intended for ground polygons. There is no way to get them display as they should.>I will test the ground polys with BGLC (FS2002 gamepack) and>see if they work, but as it seems impossible to make a full>scenery with XML code and BGLcomp only one has to use other>means so scasm ground polys might at the moment still be the>way to go.Yes, unless you are happy with how the AFCAD/XML ground polygons look. I really hope MS will extend the XML format in FsX, so that we don't have to mix all kind of techniques.>In FSX, BGLC compilations (= FS2002 gamepack) as well as Scasm>compilations are both "threated animals" as I understand it>while BGLcomp BGL:s most likely will be supported.Nope. If SCASM is no longer supported, the same is true for BGLC. In fact it is not the compiler that is in danger, it are the antique scenery commands we use (the ones form Fs5/Fs98/Fs2000). If we then compile them with SCASM or BGLC does not matter.Actually you can compile mesh scenery according to the Fs2004 standard with SCASM and these are very likely to still work in FsX. So to say SCASM is the problem is not correct. It are the antique scenery commands that we keep using.

[saabpilot 0]

Hi Arno,Thanks again.I have always thought that the resultant BGL:s from each of the three compilers actually were different and needed command support in the FS9 engine but appearantly I was wrong.If it is the "old" scenery commands that will become obsolete the compiler using those will put out "gibberish" for the FSX engine so still, the compiler is then obsolete be it present scasm or BGLC.The compiler will still be usable but limited to commands supported in e.g. FSX so in practice the compiler will be only partially supported or not supported at all.Bjorn

[arno 1]

Hi Bjorn,>The compiler will still be usable but limited to commands>supported in e.g. FSX so in practice the compiler will be only>partially supported or not supported at all.Yes, that's it :). With BGLC I can create a BGL file according to the Fs5 standards, but also a Fs2004 MDL file. So I can still use the compiler, but I need to be careful not to use the commands that are obsolete. For SCASM the same is true, although it has not been fully updated to the Fs2004 format.