Hi, Michel, THat's right, it didn't work but I may have been doing something wrong. I'll try a few more tests along the lines of Dick's suggestions. When Dick's taken a look at the code I'm sure he'll come up with the solution. When we've decided on the best approach for coast trimming I'll incorporate it into the next version of AutoAsm. I'm sure together we'll get there! Best regards, Chris

Sure I will wait for your tests results gentlemen. Thanks again Chris and Dick for your help. I hope we will be able to find a nice way to make those detailed coasts happen with your AutoAsmCheers!Michel

Hi Michel.I will e-mail you today with a corrected ASM file.The 'cure' was as I suspected.The SDK tells us that the second parameter of the LWNDataAreaDrawPolygons structure MUST be 3. That is partially right.If you want to keep the default masks active, it must be 3. But if you want to replace the masks it should be 0 (water) or 1 (land). If you want ot make watermasks, the value should be 1 (land) to give you a full LOD13 Area with land to start with. If your masks are land, you should have value 0 (water) upon which to draw your land polys.You'd want to leave it as 3, if there are masks already in place that you do not want to replace.In your circumstance, you'd want land (1) as the #2 parameter, as you are cutting water polys.It works.To change the text in the ASM file, use notepad's search'n'replace to change the following:LWMDataAreaDrawPolygons 1,3, to LWMDataAreaDrawPolygons 1,1, LWMDataAreaDrawPolygons 2,3, to LWMDataAreaDrawPolygons 2,1,LWMDataAreaDrawPolygons 3,3, to LWMDataAreaDrawPolygons 3,1,---------------------------In your ASM file, there are some minor problems. You have anomalies in Area 24,17. I think this are caused by the complexity of the polys in those areas. It may not be a problem with Chris' program, but with the nature of LWMs... they were actually designed to be triangle-type shapes, not complex, concave polys. Here's where some 'hand editing may need to be done to split the shape into 2 or more smaller shapes, in those Areas.Area 22,20 and Area 22,21 appear to have been skipped in the process somehow. That may have been a problem with Chris' program.Area 20,30 is wrong... that may have been due to the nature of the bitmap being "cut off" in that Area.As remarkable as Chris' program is, it still has some limitations, as Chris is very much aware. So it still benefits you to learn LWM-BGLC coding, so you can fine tune the very few problems that do arise. Chris continues to work very hard to polish his program, and unless the coding oddities of LWMs sabotage his efforts, he'll probably get it 100% in another version or so. Even then, it doesn't hurt to learn LWM coding.Dick

Hi Chris.The reason your having problems was because the Areafills for land must not have height data! I ran into this just a few days ago, in some posts with 'Anders' and already I forgot. :( The SDK states the height structure must be present for water and flattens... but doesn't say it must not be present with land!Also in your example, I think some of the areas are outside the landclass, and won't show up.Try this:include TDFMacros.incinclude TDFHeaders.incBGLHeader 89,-89,179,-179,LWMHeader,TerrainHeaderStartLWMHeader label word LWMFileHeader 513, LWMIndexStart, LWMStart, LWMEnd LWMStart label word datamark_0 label word LWMDataAreaFill1x1 0, 1, 1, 22, 17LWMDataAreaDrawPolygons 1, 3, 1, 22, 17LWMPoly2 4, 0, 0, -9999, 0 LWMPoint 10, 10LWMPoint 200, 10LWMPoint 200, 200LWMPoint 10, 200 LWMDataAreaFill1x1 0, 1, 1, 23, 17LWMDataAreaDrawPolygons 1, 3, 1, 23, 17LWMPoly2 4, 0, 0, -9999, 0 LWMPoint 10, 10LWMPoint 200, 10LWMPoint 200, 200LWMPoint 10, 200 LWMDataAreaFill1x1 0, 1, 1, 24, 17 LWMDataAreaDrawPolygons 1, 3, 1, 24, 17LWMPoly2 4, 0, 0, -9999, 0 LWMPoint 10, 10LWMPoint 200, 10LWMPoint 200, 200LWMPoint 10, 200 datamark_1 label word Cell_459_159 EQU LWMCellID 0, 0, 3, 459,159LWMIndexStart label word LWMIndexHeader 1, LWMIndexData LWMIndexData label word LWMIndexEntry Cell_459_159, LWMStart, datamark_0, datamark_1 LWMEnd label wordThis also works, and I prefer it as it doesn't add more polys to the code:include TDFMacros.incinclude TDFHeaders.incBGLHeader 89,-89,179,-179,LWMHeader,TerrainHeaderStartLWMHeader label word LWMFileHeader 513, LWMIndexStart, LWMStart, LWMEnd LWMStart label word datamark_0 label word LWMDataAreaDrawPolygons 1, 1, 1, 22, 17LWMPoly2 4, 0, 0, -9999, 0 LWMPoint 10, 10LWMPoint 200, 10LWMPoint 200, 200LWMPoint 10, 200 LWMDataAreaDrawPolygons 1, 1, 1, 23, 17LWMPoly2 4, 0, 0, -9999, 0 LWMPoint 10, 10LWMPoint 200, 10LWMPoint 200, 200LWMPoint 10, 200 LWMDataAreaDrawPolygons 1, 1, 1, 24, 17LWMPoly2 4, 0, 0, -9999, 0 LWMPoint 10, 10LWMPoint 200, 10LWMPoint 200, 200LWMPoint 10, 200 datamark_1 label word Cell_459_159 EQU LWMCellID 0, 0, 3, 459,159LWMIndexStart label word LWMIndexHeader 1, LWMIndexData LWMIndexData label word LWMIndexEntry Cell_459_159, LWMStart, datamark_0, datamark_1 LWMEnd label wordDick

Hi Dick,Thanks allot, I tried your modified ASM and I think it is geting closer and closer to the shape I dream about :) at least the polygon that fills the area with land before watermasks is the technique to use.Now as you mentioned, my shape is a little complex and can make the computing of the masks a little problematic for LWM commands. So I will wait for Chris input and feedback about this one. Hopefully with those experimentations, he can include the automation in AutoAsm for future releasesThanks!!!Michel

Many thanks, Dick! I'll give it a try.... Best regards, Chris

Dick, that's brilliant! The solution is very simple and will be easy to implement in the next version. I am surprised by the anomalies that appear. To get full visibility I tested Michel's image in a different location and it was perfect. But of course if the location is changed then the relationship between the lines and the LOD13 squares also changes - that's one reason why this is such a difficult problem! I tried the modified asm but it looked exactly the same. I assume this is because it requires an extended landclass file to put land beyond the beaches. I should be able to duplicate the anomalies by shifting it east by exactly one LOD8 or one LOD13. I fixed two more problems today, one associated with the beginning points of polygons. The other problem occurred when two successive points had the same LOD13 coordinates, which FS doesn't like - this may occur particularly when the image covers a small geographical area. Once again, you've come up with the goods! It's much appreciated. Best regards, Chris

Hi, Michel, that's great! I knew Dick would come up with the solution. It'll be easy to put it in the next version. Meanwhile, I'll try and find the cause of those anomalies.... Best regards, Chris

Hi Michel and Chris.I'm glad this a solution for remasking coasts. We're still defining the limitations of both LWMs and VTPs.. I still learn something every week ( unfortunately, it's usually something I just forgot the week before! ) :-eek Dick

Hi again!Thanks to Chris and Dick for another version of autoasm.How I get the X,Y values?? the pictures that I use are take from 50 milles aproximately, and the file-size is 2800x2800. Help!!ThanksPablo

Hi, Pablo! The X Y values are the geographical size of the image in decimal degrees. If you're using a screenshot you can use the method described in the readme file: choose a reference point, slew across so the point is exactly on the left edge of the map view, and note the longitude from the screen readout. Then slew to get the point on the right hand side of the screen and again note the longitude. Subtract one longitude from the other and that gives you the width of the image (it must be in decimal degrees). Use the same technique to get the height of the height of the image (slew up/down so the point is at the top of the screen etc....)If the file size is 2800*2800 pixels then you can put those two numbers straight in to the IMAGE SIZE boxes. If you're using a different source for the image, let me know and we can work out a method for measuring the image size. Best regards, Chris

Dick, you've probably forgotten more about this stuff than I'll ever learn! Best regards, Chris

Hi Pablo.If you have a printer handy, you could take some notes for landmarks to help derive the bounds. is pretty good at getting exact Lat-Long coords and the Area and Cell LWM values. TDFCalc3 requires the FSUIPC dll ( by Peter Dowson ) installed.[link:ftp.avsim.com/library/esearch.php?DLID=&Name=cellgrid&FileName=&Author=&CatID=Root] Cellgrid2 is a little more involved, but gives great visual references, and was made to assist getting screenshots with the LOD13 Areas and LOD8 Cells marked off... It requires a little ( very little ) BGLC coding, but the results are perfect for AutoASM.The attached Cellgrid pic shows how the Area numbers are even visible.Dick

Hi, Dick, I tried both examples but nothing showed! I also tried the modified version of Michel's code but it's the same problem - I don't see any land beyond the default coast. As I understand it this method does require underlying landclass but normally landclass does extend some distance beyond the default coast. In my case it seems the extra landclass is missing! I wouldn't have thought it could depend on the way my system is set up (it's a full install as I recall).... Best regards, Chris

Hi Dick and Chris :)Wow great evolution in this new FS technology. Chris, do you mean that if my coastline is placed somewhere else in FS world it would not have the bugs that happen where I placed it? Cheers!Michel