Draft tutorial for editing default LWM and VTP landscape files

[Holger 0]

Hi all,well, I keep receiving requests for more information regarding my particular methods for editing default landscape scenery files. At some point, writing a one-shot tutorial is more economical than many emails and posts ;-) Attached is the draft (in MS Word) of a basic tutorial for editing default LWM and VTP landscape scenery files, such as lakes, roads, etc. The main incentive for landscape designers for messing with the default files is to remove the bl**dy flattened areas and lineaments associated with them but also to save on excludes and provide a nice "blank slate" for a project.I'd appreciate feedback on content, clarity, and style (my email is in the Word file) so that I can do final edits and upload the document as a .pdf to the file library. Due to size restrictions for attachments the zip file contains only the first of six images. Below are four more, the last one is just a "summary" image of the completed edits of the example area.The final version will also include the uncompiled example files so that users can quickly test their setup of BGLC.exe and the .inc files.Thanks to Wil Husted for a first round of editing and Gilles Gauthier for getting me set on doing these kinds of edits in the first place; it's all his fault ;-)I hear that Lars is working on a tool that would automate this procedure and (potentially) make this tutorial superfluous - oh well...Cheers, HolgerImage 2http://forums.avsim.net/user_files/76537.jpgImage 3http://forums.avsim.net/user_files/76538.jpgImage 4http://forums.avsim.net/user_files/76539.jpgImage 5http://forums.avsim.net/user_files/76540.jpg

[Guest sapper42]

Holger, thanks for this effort, it is greatly appericiated.rgds Jeff

[Guest HSIMAN]

Thank you Holgerfor spending some of your time teaching us.FriendlyChristian, Paris, France

[GHD 21]

Thanks Holger for a well thought out presentation.George

[Guest adriano]

Hi Holger,I have to confess that I have already written a tutorial on the same subject. It appeared (in Italian) on Aliditalia (www.aliditalia.com) one week ago or so. I did my best to give you all due credit; however, I regret now not having asked for your permission first. To a certain extent, I feel that writing a tutorial about someone else's work is only a little short of piracy. I think that intellectual property deserves being respected even more carefully than commercial rights. I wrote that, just because it was obvious that here in Italy the technique was largely ignored, and it was a real pity. I realize that my approach follows a slightly different editing strategy from yours, probably dictated by the different examples we've chosen, an island vs. inland lakes. But yours is definitely more general, and I learned from it several details and tricks I was missing.Please accept my apologies and my best appreciation for your work.Adriano

[Guest fame]

Hi Holger:I've just downloaded your *.zip file and look forward to reviewing it.BTW... you're correct in your statement "At some point, writing a one-shot tutorial is more economical than many emails and posts ;-) " IMHO the community could put to good use, a authoritative tutorial on editing default LWM and VTP landscape files.Thanks for taking the time to collect your thoughts on the subject, and commit them to writing.Continued successTom G, Sr.

[Guest Anthony_D]

Hello Holger,The tutorial will no doubt become very useful for me. The section about the naming convention could be elaborated a bit. My understanding from reading your document is that HL* and HP* files are related to the LWM polygons and VTP lines. But what about the AP*, BR*, FL*, AP*, ST* .... etc files?Many thanks for your conttribution to the scenery design community.Anthony Dyer

[wsieffert 0]

Download LWMViewer - http://www.jimkeir.co.uk/FlightSim/LWMViewer.html. The Readme.html file defines the various file prefixes.W. Sieffert

[Holger 0]

Hi allthanks for the feedback so far. Please let me know if you have any further comments; I'll probably wait another week or so before pooling the input and wrapping up the final version.I'm not sure what the approriate response is if someone offers apologies and the intended recipient doesn't think they are necessary?!? Anyway, I am in email contact with Adriano. His Italian version of the tutorial is quite a bit more detailed and includes a really interesting and helpful discussion about the pros and cons of this approach and the potential for ensuing "chaos". I'd like to incorporate some of his suggestions in my tutorial because the potential for conflict is indeed very real (and already happening; see the Grand Coulee/Roosevelt Lake thread).While I agree in principle with Adriano's concerns regarding "intellectual copyright", and appreciate the very obvious credit given to me and others in his tutorial, I can't claim (and don't want to) "copyright" for the procedures covered in the tutorial. Even if I was the one to first put this approach into practice - and I don't even know that - it's obvious that 90% of the necessary information and tools are NOT my original contribution. Everyone frequenting this and other scenery design fora knows that it is the investigative and creative work of many different people (including the SDKs shared by the MS FS design team), and the free exchange of knowledge and ideas, that allows us to improve our methods and utilities. Thus, for me the issue of copyright or infringement only comes into play when people "harvest" the knowledge or use freeware tools to create for-profit add-ons.Coming back to the "chaos", perhaps this would be a good time to discuss "standards" for designers that choose to edit and distribute default scenery files. Based on Adriano's suggestion, I included all the necessary information I could think of with my latest project, the North Cascades scenery enhancements (us_wa_nc.zip). I'd be interested in your all opinions regarding this "issue".Cheers, Holger

[rhumbaflappy 113]

Hi Holger.We've discussed this before, but I'll give a recap of the solution I earlier proposed for others reading this thread.The LWM bgls are arranged in FS9 as ( approximately ) LOD5 sized sections. This is a lot of area and a lot of data. The code of FS9's LWMs all have elevational data for each point in the polys ( LWMPoly3 ). You can code new masking, to change the land and water, but there is no way to "exclude' the flattening or elevational characteristics of the default BGLs.We have found no decent method of "remeshing" via flattens... in fact those flattens hard-code their elevations and can cause problems with other LWM coding or new meshes.The best approach would be to rewrite the entire LOD5 sized default to proper shape and elevation for the water. But, this is an almost impossible task due to the size of the area.Another approach is a "surgical" method, such as yours, that rewrites the default code for the section you would like to alter, and leaves the rest usdisturbed. But, as you noted, chaos can happen when we have more than one alteration of the default. Now, which version would new BGLs use?A third approach ( my choice ) is to replace the entire LOD5 sized default with mesh-clinging water. Now the replacement would have no flattens.Rename the original as "*.bgl.orig" and it is deactivated. The mesh-clinging replacement would have the default name ( and perhaps an addition like "HP915190_cling.bgl", and differ only in that it is mesh-clinging. The designer can then have total freedom for his LWM changes without worrying about the default flattens interfering with his work... and the default water areas are still in place ( although they are likely to climb up hills due to their poor shape and placement ). This lets you accurately chang a small area, or a large area as you see fit.Edgar Knobloch has made a utility that will take FS9 ASM code for LWMs ( like that produced by LWMViewer ), and make it into CFS2 LWM code... which is mesh-clinging and works for FS9.http://library.avsim.net/esearch.php?CatID...scen&DLID=43104This can be recompiled and named like "HP915190_cling.bgl", and then you don't need to worry about the default's flattens in your design area. If a flatten or two are absolutely needed, a third file ""HP915190_flat.bgl", could be included.====================Of course, all this is nonsense. MS should have allowed us to revert elevations to mesh in a defined area... like an exclusion. But they did not design the sim for the purpose of addon scenery. In fact LWMPoly3 requires elevation at each poly vertex... a big step backwards, as far as terrain design requirements.Maybe the next version will allow the posibility of returning a defined area's LWM to the non flattened state.Dick

[LuisFelizTirado 33]

Hello Dick, I could not agree with you more on all this. There is not really a good solution for the moment, and all the alternatives comport certain problems.The solution that you propose is also what I would recommend: removing all water elevations and make mesh-clinging water. However, this too can bring about problems.In areas containg many islands, such as the Caribbean, the default mesh is not aligned with the land masses. By converting all water to mesh-clinging, the mis-aligned mesh will thereupon raise the water in a very large area.This would then oblige the designer to re-create each and every land mass in the relevant bgl in order to avoid this problem.Note to our friends at Microsoft: Water flattens must be eliminated!Best regards.Luis

[Guest]

Hi Holger,Right off the top of my head and mainly an attempt to get a discussion going on this "chaos", it looks like any standards will have to be based on an honor system since there won't be any way to control who chooses to edit default scenery. At first blush, your inclusion of the us_wa_nc.zip data appears the way to go and I'm going to do the same with my Yellowstone National Park project. I'll also do this with an update to the Beartooth Lakes project that was posted some time back. At the least, the information will be available for use by others.There's no guarantee that every project created with the file editing procedure will be downloaded, seen or used by other scenery designers. Maybe some kind of "code" could be incorporated in the finished product file name to alert others but they'd have to pay attention to it.I'm sure that others will have ideas and suggestions for you.Wil

[Holger 0]

Hi all,excellent points, everyone! Thanks, inparticular, for the summary of your suggestions, Rhumba.I won't reply in more detail right away, just wanted to add another point: the discussion should not be limited to the LWM files; what really bugs me are the linear flattens associated with streams, roads and railroads. In steep terrain the misplaced vectors can carve up the slopes very badly, sometimes cutting deep "gorges" when crossing ridgelines at right angles. Unfortunately, the "local" mesh-clinging option doesn't exist for these files. The global changes to the terrain.cfg are not really an option because, IMO, the road and stream cuts are actually a very useful feature for accurate renditions of road and water networks.Cheers, Holger

[Guest luissa]

Hi,This problem is very similar to changing AFCAD layouts in FS8. Both Lee Swordy and Manfred Moldenhaeur came to a solution which was to provide a tool to "incorporate the change into the default". Their tools were AFInstaller and AFDLINK. I will recap the idea using AFinstaller in the following.Basically if a designer wanted to change airport A belonging to the AFD file ABCDE.BGL (containing airports A, B, C, D and E) he would provide 2 source files A1.TXT and A0.TXT. The first file contained the redesigned airport A. The file A0.TXT contained the source code of the default airport. The user had to run something like: >AFInstaller A1.TXTfor the new changes to be incorporated in the default (or already modified by others) file ABCDE.BGL. Later on, if the user wanted to uninstall that change, he would run:>AFInstaller A0.TXTI implemented this in my scenery installer/uninstaller for FS8. An improvment to this would be, the designer to distribute just one A1.TXT and AFInstaller to create A0.TXT before adding A1.TXT into ABCDE.BGL. In that way I could change one airport. Then, another designer could change the same airport. An user installed my modification and then that of the other designer. He could return to mine (not the starting default) if this improvment could be realized.I think that the idea could be applied in LWM and VTP scenery. A tool could be developed. Designers would produce source files covering LOD13 areas. The tool would read the source files and would incorporate them in the whole LOD5 BGL.Kind Regards, Luis

[Guest adriano]

Hi Holger, all:I have been pondering over the chaos story and I have come to a set of possible draft 'guidelines' that I would like to propose to the community. I hope that they may trigger a debate and eventually allow to establish a general policy that may be shared by everyone.1. Default LWM/VTP files must be modified, I believe, ONLY IF THERE IS NO OTHER WAY OUT. (This may limit interventions to the selective suppression of default shoreline flattens, river gorges, and ?). Every time an exclude file or whatever else can do the same thing, please let the default files as they are. Impending chaos size should limited as far as possible.2. Suppressing elements is one thing, modifying them is another. Should anyone feel free to alter the data within the default files at will, I think that the problem of compatibility among sceneries will not just bring us to chaos: it will bring us to insanity. In my opinion, default LWM/VTP files MUST ONLY BE MODIFIED BY SUPPRESSING GIVEN AREAS/CELLS/ELEMENTS. NO OTHER TYPE OF MODIFICATION SHALL BE ALLOWED. 3. The only good reason to suppress a default flatten is that of replacing it by a new coastline and, if the default file data must not be changed with others, then the only way to obtain that is by means of another LWM/VTP file. Therefore, ALL MODIFICATIONS TO A DEFAULT FILE SHALL BE ASSOCIATED WITH ONE OR MORE REPLACEMENT FILE(S).4. I think there can be no doubt that the original default files must be saved. This said, WE MUST KEEP TRACK OF WHAT WE ARE CHANGING IN THEM. A possible way to do so is storing the relevant infos as comments in the decompiled files themselves. This was my first idea, but it compels to save all decompiled files somewhere and, if they become too many, this can become a nuisance or, worse, another source of confusion. Better, maybe, keeping a unified logbook. WE NEED SOMETHING LIKE A BRAND NEW .CFG FILE. Call it with a different extension, if you like, but it must be a file where all changes to the default files are logged in. The format may be relatively unimportant, but it must be A FIXED STANDARD, as if it had been imposed by MicroSoft themselves, otherwise we shall never be able to write in it in a uniform way. Ambitious? No doubt. Feasible? I hope.Relevant data are probably, for every single suppressed area/element : - world zone (optional); - modified LWM/VTP file (mandatory); - modified cell (mandatory, when applicable); - suppressed area/element (mandatory); - replacement file(s) (mandatory); - .... (?) Of course MSFS will never look into this .cfg-like file at startup. We have two basic choices, I guess: - either we keep it only as a passive logbook; - or someone prepares a small program that checks this .cfg file first, and allows MSFS to start only if the stored .bgl files are correctly matching its content. This of course would greatly mitigate the risk of incurring into chaos. 5. Last but not least, if we want all users to take full advantage of this procedure, I think that a program that does everything automatically must be made available. I mean that it should be attached to any scenery involving default LWM/VTPs and, working on the user's personal copy of the relevant files, create a new customized version of them at no - I hope - hazard of confusion.In my opinion, this program should - decompile the relevant file(s); - remove the elements to be suppressed; - re-compile; - replace the previous file issue (and store it somewhere else); - update the logbook. One problem at least is still remaining, that of stepping back, i.e. removing an old scenery and restoring the relevant default features. But here the logbook should prove helpful. I'm suggesting that another piece of software might: - check in the logbook which files, cells, areas have been altered in connection WITH AND ONLY WITH the scenery to be deleted; - decompile the (saved) default file and copy the relevant missing lines back into the current version; - recompile, replace, update the logbook etc.I suppose that the above software shouldn't prove too complex to build. Most elements are already existing. Unfortunately my software experience isn't up to such a task (easy , from my side, you may say, but so it goes). LARS, WHERE ARE YOU? Can you help? Or can anyone else?Cheers