Non permanent water bodies in FS2002

[Guest]

Hi everybody,I tried today to fly north from Adelaide (South Australia) to reach Alice Springs, and I noticed that, in contrast to what I remember from a real life flight on that route, Lake Torrens north of Port Augusta and the other lakes in that region were almost unvisible, being just greenish flat territory. I tried the same changing to spring and winter seasons (assuming that there might be more water present at thet time)-- without visible effect :-( .Looking for the reason I tried tfm-view, opening first hyp476096 in the auste directory - no water polygons. But opening hyl746096 I noticed that the shorelines were there. Then I tried nph476096 - and finally there were the polygons! (so nph translates to "non perennial hydrography"). Disassembling that file I noticed that MS uses "1209" as the texture for these polygons, and according to terraintexture.cfg that translates to the 126 group of textures which exists for hard winter, winter and summer only. Both winter and summer textures of group 126 show no water at all, the hard winter texture is with snow. There seem to be several possible ways to make these salt-water lakes more realistic. It would be possible to design region-specific textures for the 126 group (I think the water of these lakes looks quite normal in winter, maybe in the dry season it is more whitish because of the salt), but I am not sure whether textures selected via the cfg file change according to the region lookup table ? Or would it be possible to move the respective nph-files to another folder, add a texture folder to that and change the 126 type textures in that folder? To add another entry to the terraintexture.cfg file and to change the texture reference in the respective nph-files would be more difficult, and I do not know whether that would work.I would be interested to here your opinion about this problem (and to hear from our Aussie friends how these lakes look really like in summer).- osman

[rhumbaflappy 113]

Hi osman.These 'nph' files are vtp method2 polys with a layer of 4. As such, they can be overwritten easily.LWMDraw, Ground2k, Coast-Line-Maker or by hand, can all make BGLS to exclude and redraw the polys.The trick is in the definition of the texture:TextureDataStart label word texturemark_0 label word VTPTextureName "winter.bmp;hardwinter.bmp;spring.bmp;summer.bmp;fall.bmp;night.bmp" VTPTextureType 1, 0, 0, 4 texturemark_1 label wordTextureDataEnd label wordEach season and night should have a named texture. This texture should be in a local twin, texture sub-folder ( next to the scenery twin sub-folder ), or from the Scenedbworldtexture folder. Define something for each season and night... and a water texture could be assigned for one or two seasons without problem.Dick

[Guest]

Hi Dick,if possible I want to avoid the trouble to overwrite the VTP2-polys in the nph file manually, that would be quite tedious, because there are so many lakes of this type in Southern Australia. Of cause I could copy and rename the disassembled nph-files, changing every texture name with a word processor and giving the polys a higher priority, this solution should work, but is there no more elegant solution?? - osman

[rhumbaflappy 113]

Hi osman.Actually, you've hit on the solution.The new version of BGLAnalyze will give you the ASM file with the correct points. ;)The layer can remain the same, as you're overwriting the poly later in the datastream by making a new bgl. You could change it if you like, but as long as the new bgl is later in the datastream, it won't matter.You just need to use a text processor's replace function to replace the texture name string... and of course, provide the textures. You could rename the ASM file to something different, so you can identify the end result as a non-default BGL. Then just place it in a scenery folder, and it will overdraw the polys, with the new textures for the seasons.This way, you don't need to disturb or deactivate the default 'nph' files... they'll get covered by the new polys at runtime.Dick

[Guest]

Hi Dick,testing this solution I found that it is not that easy to get an acceptable result. - analyzing the nph files turned out to be more difficult than assumed. Even after correcting a bug in BGLAnalyze it could not produce an asm file for recompilation, because there are undocumented flags in the VTPolyMethod2 records that spoil the business. So I was obliged to use a hex editor, and since the texture reference is just at the end of the file I could change that one entry (indeed MS uses just one texture for all the polys).- but now there is the problem of the limited visibility of ground polygons, which FS2002 apparently inherited from the old ground polygons in FS2000. The textures used by MS blend with the arid environment of those lakes, so one would not notice, but with another (water-like) texture supplied you see the lakes flopping up in chunks when you approach them - not a desirable effect. So the only possibility would be to make new LWM water polygons for those lakes - not an easy task. If we could get a comlete and correct disassembled file for the nph polygons it would not be to difficult to write a program to transform them into lwm water polygons, but that's again a problem of those extra flags in the MS files ...

[rhumbaflappy 113]

Hi osman.I hadn't realised there were some VTP m2 polys affected by the undocumented bits. I had thought those were related to VTP lines only. :(Simply changing the texture number doesn't solve the problem. You'd like to have different textures for different seasons, so the TextureID needs a seasonal string... and just inserting that in the hex code probably won't work, as the address pointers will then be messed up. It may be possible to hack those pointers as well, but now you're in it pretty deep. :)A somewhat different approach might work... but I don't know the extent of your commitment to this:I've been experimenting with TDFViewer. I load worldlc.bgl so the entire world is now georeferenced in the viewer, then I load a BGL on top of this ( say, nph472096.bgl ).I can now take a screenshot of the TDFViewer, and jot down the georeference of the viewport extents. After trimming the screenshot, I now have a bitmap with georference, that I can load into Ground2k.Now, within Ground2K, I can draw the polys to rework them, and rework the 'shorelines' as well.A little crude and slow, but it does work.This might not be a viable solution to an area as large as Australia. :)TerraScene can also produce a georeferenced image from shapefiles that can be used with Ground2K.In the abscence of decompiled source, another alternative is converting georeferenced data to ASM code. "Falko" has given us E002VTP that will help translate E00 files to VTP lines... hopefully there will be something like this for VTP and LWM polys, eventually. Most designers don't have access to ARCView, MapInfo, or Manifold... that have scripting capability for translating georeferenced code. I keep hoping someone will write a standalone translator for EOO or SHP files. It's a little over my head as a programmer. :(Dick

[Guest]

Hi Dick, your solution to use TDFViewer to take a screenshot with the Lon/Lat data of the corners used to make the resulting bitmap useful for Ground2k sounds quite good, and in a program like Photoshop it would be even possible to overlay that bitmap on the scanned image of a map.But I hope I can do better now after I found a way to analyze the nph*** files cracking one of the undocumented bits in VTP files (see my post of today) ;). Now I only have to write a program to use the VTP points as a base for LWM polys splitting the VTP polys if they span more than one area in a cell. But that should not be too difficult.-osman

[rhumbaflappy 113]

Hi osman.Congratulations on cracking that reserved bit! I replied to the other post, and hope you can send me an ASM using more than 127 polys so I can check the format of my proposed macro addition.A VTP m2 poly to LWM poly program could be very useful. Dick

[Guest]

>A VTP m2 poly to LWM poly program could be very useful. >How about a poly definition with lat / lon pairs (in a text file) to a LWM poly list (text file) with all of the boundry crossings included? Would anyone be interested in that?Lee.

[rhumbaflappy 113]

Hi Lee!Yes. I'm interested. :)Dick