Sign in to follow this  
Guest Freddy Wilhelmsen

Draft tutorial for editing default LWM and VTP landscape files

Recommended Posts

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

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Thanks Holger for a well thought out presentation.George

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Hi all,Luis, thanks for the input! Having a tool like that is a great idea. Correctly implemented, it would save a huge amount of headaches.Adriano, thanks for the impressive "draft standards". I really don't have much to add to them other than a few points:"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."Strictly interpreted, this includes any LWM/VTP file because the visible features can be excluded without problem. Instead, what we are dealing with here are the residual flattens associated with water bodies, roads, railroads, and streams, which cannot be altered with excludes. To me, all four are "bad" but the degree to which they interfere with a project - and thus the motivation for removing the data from the default files - depends on the local topography more than on the LWM/VTP type. In other words, I would replace "no other way out" with a more general statement that says one should edit default files ONLY if the residual flattens create problems for the intent of the project. (I realize now that using HL9* shorelines in my tutorial is a poor example in that regard; I'll probably switch to roads or streams to avoid confusion). In No. 3, you list coastlines as "the only good reason"; again, I think that those three VTP line types with flattens/depressions should be included.No. 4: I agree that it would be nice to have a rigorous standard for documenting these changes but I doubt that this will happen (writing read-me's is typically the least liked part by designers). My guess is that a utility as suggested by Luis and yourself, which actually makes it easier for the designer too, is the option more likely to be successful. However, until such a tool exists (if ever) I agree that everyone should provide the minimum information about which files and data were altered.---Coming back to Rhumba's suggestion regarding setting entire LOD5 sections to mesh-clinging. To me the main reason we are creating add-ons is to enhance the subjective (i.e., apparent) and/or objective (i.e., measurable) realism of the FS world. This is a process that proceeds in steps but it should always move forward. I just don't find it useful to sacrifice realism in large parts of a 90,000 sq km LOD5 section - by allowing water to climb up and down slopes - just so that my project doesn't interfer with potential (!) other projects in the same LOD5 (Again, this VERY MUCH depends on the kind of landscape we're in; it won't matter much in Kansas). I'm currently in a situation were two other people are using the "surgical" approach in two LOD5 sections previously altered by me. I'm in contact with both of them and I'm sure we'll figure out a way to make our projects mutually compatible. To me, communication among designers is a very important aspect, one that is perhaps the easiest way to avoid chaos.Cheers, Holger

Share this post


Link to post
Share on other sites

>Luis, thanks for the input! Having a tool like that is a great>idea. Correctly implemented, it would save a huge amount of>headaches.Hi,I hope that some of the readers of this forum who implemented LWM/VTP disassemblers consider the challenge.While such a tool is not available, may be designers could divide the "default LOD5" in 1024 "default LOD8". The possibility for conflict would be much smaller.Regards, Luis

Share this post


Link to post
Share on other sites

Hmm? Wha? Sorry, sleeping :)Well, it shouldn't be too tricky to put together something that could merge or split LWM/VTP bgls as long as they were split along cell boundaries. Arbitrary boundaries would be entirely possible of course but would require a bit more work.It could take all cells from the 'input' file and substitute them in the 'output' file, if they already exist there. In either case, the first patch applied to any file should store a copy of the unmodified original in a central location. This would be used to uninstall any add-ons. Uninstallation would require the add-on BGL to still be available; this would allow subsequent differences to be spotted and left in place.Simply deleting the matching areas from the original BGL would seem simpler to do, but selective uninstalling would be more difficult since you couldn't compare each cell and see if it's been updated by something else.Of course, this means that users have to run a program with correct parameters to install and uninstall your add-on scenery. Given that a number of people have trouble copying files(!), this may be a problem in itself.Cheers,Jim Keir

Share this post


Link to post
Share on other sites

Interesting discussion this is becoming :). Just a few comments.I like the idea of some sort of tool to apply the changes to the default files, this would make it better accessible to more scenery designers. But compared to the AFCAD installer for Fs2002 i also see a problem. With the AFCAD you where always talking about one airport with a fixed name. That means that when installing a different AFCAD of the airport you would just overwrite all data. Having a simple backup file of the origional airport also allowed you to put that back easily.With the mesh elements there is not fixed area however. It is very well possible that different designers could even have some overlap in their areas. This would make uninstall options much more complex. Assume you ahve installed the changes made by designer A and then you install some work by designer B that overlaps part of designer A. Should the uninstall then revert to the status of designer A or to that of the default scenery? And what if you want to uninstall designer A, while keeping the work of designer B? It would be a rather complex process of storing all this data so you can have a flexible uninstall.Therefore I think I like the suggestion of Dick more where the only change to the default files is to remove the flattens information. The addon designer can then redefine the altitudes in his own files as he likes. I think we can still use a tool in this case that allows a scenery designer to let the user remove the flatten information from the default files in a very specific area (the area you are editing). This tool would for the uninstall only have to restore the default flattens.

Share this post


Link to post
Share on other sites

>Interesting discussion this is becoming :). Just a few>comments.>Yes indeed! After reading the posts by Jim and Arno: I think that the replacement can either be "by Area" or "by Cell". I was thinking in a "by Area" approach in which case the author should modify the complete Area (not a part). Jim refers to a "by Cell" which may be mandatory from a point of view of the coding (?) but can bring problems if authors only change some Areas in the Cell. The point by Arno is an important one! What we need is the removal of the flattens. For the rest we can use the priority mechanism of the sim. So the tool would remove the flattens from the worked areas!Regards, Luis

Share this post


Link to post
Share on other sites

Hi all,"What we need is the removal of the flattens. For the rest we can use the priority mechanism of the sim. So the tool would remove the flattens from the worked areas!"(jumps up and down) But this approach works ONLY for LWM polys, not the flattens/depressions associated with vectors!!! Am I really the only one concerned about vector flattens? I could show you a couple of really ugly screenshots of residual vector flattens but I have reached my screenshot quota for this thread. :-)I think that if a tool existed that restricted its influence to full LOD8 Cells only, then the issue of overlap between adjacent projects would be minimized (it would also make it easier to remove VTP2 vectors, which are organized in LOD8, not LOD13). In case a designer's project area includes only part of a LOD8 Cell he/she can develop a replacement LOD8 Cell that consists partially of his/her work and partialy default Areas; that's what I do all the time already.Basically, the designer would prepare his set of replacement LOD8 Cells, submit them to the utility, and the utility would remove the default LOD8 Cells and replace them with the new ones. It shouldn't be too difficult to address Arno's concern by storing a new "last-edited" version (in addition to the default-only version) each time things are changed so that the uninstall can proceed in reverse succession. Admittedly, this wouldn't catch a case were B is installed after A but the user wants to uninstall A but not B. Maybe it's just easier to "lock" an altered LOD8 Cell after it has been altered once. Or, the utility could alert the user that this LOD8 Cell had already been altered once and give the choice to uninstall the previous edit (for that Cell only) and install the new one instead (for polys this could be implemented on a LOD13 basis, if desired). Since we're talking replacing default flattens and default vectors/polys with more accurate versions there shouldn't be a need for multiple changes anyway. Also, doing this would "force" the designers to coordinate their efforts and restrict themselves more or less to LOD8 Cell boundaries. As for the implementation by users, I think a batch executable that initiates the process should do the trick (one for install, one for uninstall). Cheers, Holger

Share this post


Link to post
Share on other sites

Hi Holger,>(jumps up and down) But this approach works ONLY for LWM>polys, not the flattens/depressions associated with vectors!!!>Am I really the only one concerned about vector flattens? I>could show you a couple of really ugly screenshots of residual>vector flattens but I have reached my screenshot quota for>this thread. :-)Just to know I understand you correct. If the tool would also allow you to remove default VTP lines the flattens belonging to them are also gone not?I agree with you that these elements should also be removed, but the principles stay the same I would say.

Share this post


Link to post
Share on other sites

Hi Arno,yes, removing the VTP2 lines (and replacing them with more accurately placed ones) will remove the flattens/depressions. One can also do this via changes to the terrain.cfg but those changes would be global and, IMO, undesirable.Cheers, Holger

Share this post


Link to post
Share on other sites

Hello Holger,I think you mean "... removing the VTP2 lines (and replacing them with more accurately placed ones) will NOT remove the flattens/depressions.", right?A depressing thought indeed!Cheers, Edgar

Share this post


Link to post
Share on other sites

Hi Edgar,this is interesting; it seems that people are indeed unaware of this option:Removing the default VTP2 lines WILL remove the flattens and depressions. The flattens are associated with the vectors via the terrain.cfg (with the "offset= [flat/0]" parameter), NOT stored in any separate file. If you simply exclude the VTP2's their textures will disappear but because the default RD/RR/ST bgls are still loaded the flattens/depressions are drawn by the engine. Removing those bgls (or parts thereof) will remove the flattens.Cheers, Holger

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this