VTP Shoreline Problem

[Guest]

Hi AllI've checked and rechecked for misspellings, bad spaces, and etc but I can't see to figure out why the below VTP Method 2 Poly shoreline assembles ok with BGLC.exe but stops FS during the texture loading period. I'm hoping someone will see where I've messed up.ThanksKen===============================================;----> FS Coordinates: 61 25.24 -148 59.51;----> VTP Method2 road/line/shoreline;----> The next two files MUST be included within the same directory as;----> BGLC.exe when this file is assembled (compiled).include TDFHeaders.incinclude TDFMacros.inc;----> Begin Header Section <----BGLHeader 62, 60, -147, -149, TerrainHeaderStart, VTPHeaderVTPHeader label word VTPFileHeader 256, VTPIndexStart, TextureStart, VTPEnd;----> End Header Section <----;----> Start File Data <----VTPStart label word datamark_v0 label word;----> Begin Data Area Information <----VTPDataArea 1, 1, 0, 0VTPLayer 8, 0VTPNumTexturesInLayer 1, 0VTPTextureId 4, 0VTPPolyCount 1, 0VTPPolyMethod2 54, 1, 0VTPWidePoint 5337, 1, 6379, 0VTPWidePointWidth 1VTPWidePoint 5337, 1, 6379, 0VTPWidePointWidth 25VTPWidePoint 5337, 0, 6379, 0VTPWidePoint 5333, 0, 6381, 0VTPWidePoint 5322, 0, 6386, 0VTPWidePoint 5309, 0, 6380, 0VTPWidePoint 5302, 0, 6382, 0VTPWidePoint 5286, 0, 6398, 0VTPWidePoint 5273, 0, 6396, 0VTPWidePoint 5238, 0, 6401, 0VTPWidePoint 5211, 0, 6397, 0VTPWidePoint 5184, 0, 6385, 0VTPWidePoint 5135, 0, 6426, 0VTPWidePoint 5139, 0, 6448, 0VTPWidePoint 5139, 0, 6463, 0VTPWidePoint 5134, 0, 6482, 0VTPWidePoint 5125, 0, 6503, 0VTPWidePoint 5116, 0, 6546, 0VTPWidePoint 5116, 0, 6572, 0VTPWidePoint 5131, 0, 6585, 0VTPWidePoint 5154, 0, 6584, 0VTPWidePoint 5225, 0, 6506, 0VTPWidePoint 5245, 0, 6496, 0VTPWidePoint 5263, 0, 6495, 0VTPWidePoint 5283, 0, 6507, 0VTPWidePoint 5281, 0, 6520, 0VTPWidePoint 5266, 0, 6544, 0VTPWidePoint 5239, 0, 6564, 0VTPWidePoint 5214, 0, 6579, 0VTPWidePoint 5206, 0, 6594, 0VTPWidePoint 5209, 0, 6610, 0VTPWidePoint 5246, 0, 6622, 0VTPWidePoint 5263, 0, 6614, 0VTPWidePoint 5290, 0, 6614, 0VTPWidePoint 5310, 0, 6617, 0VTPWidePoint 5334, 0, 6610, 0VTPWidePoint 5341, 0, 6598, 0VTPWidePoint 5344, 0, 6578, 0VTPWidePoint 5340, 0, 6555, 0VTPWidePoint 5347, 0, 6539, 0VTPWidePoint 5342, 0, 6525, 0VTPWidePoint 5333, 0, 6514, 0VTPWidePoint 5336, 0, 6500, 0VTPWidePoint 5329, 0, 6488, 0VTPWidePoint 5334, 0, 6473, 0VTPWidePoint 5342, 0, 6462, 0VTPWidePoint 5342, 0, 6450, 0VTPWidePoint 5335, 0, 6435, 0VTPWidePoint 5335, 0, 6421, 0VTPWidePoint 5340, 0, 6410, 0VTPWidePoint 5344, 0, 6401, 0VTPWidePoint 5348, 0, 6393, 0VTPWidePoint 5347, 0, 6385, 0VTPWidePoint 5342, 1, 6381, 0VTPWidePointWidth 0datamark_v1 label word;----> End Data Area Information <----;----> Begin Cell_66_81's defination data information <----Cellv_66_81 EQU VTPCellID 0, 66, 81VTPIndexStart label wordVTPIndexHeader 1, VTPIndexData, VTPStartVTPIndexData label wordVTPIndexEntry Cellv_66_81, VTPStart, datamark_v0, datamark_v1;----> End Cell_66_81's defination data information <----;----> Begin Texture Information <----TextureStart label wordVTPTextureListHeader 5, TextureIndexStart, TextureDataStart, TextureDataEndTextureIndexStart label word VTPTextureListEntry TextureDataStart, texturemark_0, texturemark_1 VTPTextureListEntry TextureDataStart, texturemark_1, texturemark_2 VTPTextureListEntry TextureDataStart, texturemark_2, texturemark_3 VTPTextureListEntry TextureDataStart, texturemark_3, texturemark_4 VTPTextureListEntry TextureDataStart, texturemark_4, texturemark_5TextureDataStart label word texturemark_0 label word VTPTextureName "1063"VTPTextureType 2, 0, 0, 4 texturemark_1 label word VTPTextureName "1063"VTPTextureType 2, 0, 0, 4 texturemark_2 label word VTPTextureName "1063"VTPTextureType 2, 0, 0, 4 texturemark_3 label word VTPTextureName "1063"VTPTextureType 2, 0, 0, 4 texturemark_4 label word VTPTextureName "1063"VTPTextureType 2, 0, 0, 4 texturemark_5 label word VTPTextureName "1063"VTPTextureType 2, 0, 0, 4TextureDataEnd label word;----> End Texture Information <----;----> The next line below ENDS this file <----VTPEnd label word

[rhumbaflappy 113]

Hi Ken.Real quick answer:VTPDataArea 1, 1, 0, 0VTPLayer 8, 0VTPNumTexturesInLayer 1, 0VTPTextureId 4, 0VTPPolyCount 1, 0VTPPolyMethod2 31, 1, 0VTPPolyMethod2Ex 23 ; 54 - 31 = 23VTPWidePoint 5337, 1, 6379, 0VTPWidePointWidth 1VTPWidePoint 5337, 1, 6379, 0VTPWidePointWidth 25...You exceeded the 31 point limit, so this extended form is the way to go.I don't know the total limit of the extended form. The SDK shows this as a byte ( 255 + 31 points ), but Christian Stock discovered the SDK to be wrong, as it's actually a 16-bit word ( would allow 65535 + 31 points ). Who knows. But the above change should work.Dick

[Guest]

Indeed Dick, it did work and you've saved me again. Thanks so much!!That leads me to another question though about LWM's:How would I allow more than 62 points on the LWMPoly2 or Ex lines? I tried using it like your VTPm2 example above but that didn't work and I also tried reversing the numbers.Thanks Again BroKen

[rhumbaflappy 113]

Hi Ken.I never had an LWM poly with that many points.With VTPm2s you need to have both lines:VTPPolyMethod2 31, 1, 0VTPPolyMethod2Ex 23But with LWMs, maybe only the extended type line???LWMDataAreaDrawPolygonsEx 63, 0, 0, -9999, 0, 24That would define 87 points ( 63 + 24 ).Note the parameter format is exactly the same as a regular LWM, with an extra BYTE for the extension added to the end.VTPm1s cannot use an extended format... and seem to be limited to 24 points. LWMs and VTPm1s are both legacies from CFS2, so I'm no longer surprised they have different characteristics than VTPm2s.I think this works. -----------------------Christian Stock had been leaning towards the idea of using one Macro for both regular and extended LWMs, with the macro using some logic to determine if the extra byte was needed. I never put that in TDFMacros.inc, because I was trying to keep the same format as the SDK. Christian's idea is undoubtedly better, but I was, and still am, afraid of having 100 different sets of macros rather than one standard, by which we can all communicate. And the SDK is that standard. But I understand we will eventually be forced to add new macros ( I do it myself ).Anyways, try the above form and see if it works.Dick

[Guest]

For the record, I've produced polygons up to the limit 317 (63+254), and it has worked fine. (My scenery is very detailed: it's also got railroads, streets, minor rivers and an updated landclass. Can't wait to finnish it all and release it)I do have a problem with a particular LOD13 area, which I've had to disable because it corrupted the rest of the file. Don't know what the problem was yet. The source was above the maximum point count and thus my code simply clipped to 317, and it was heavily non-convex. Not to the point that the border crossed itself, though, not even with the abrupt 317 cut, and then many other reservoir polygons had the same characteristics and didn't break FS. I'm still researching on this one.Fortunatelly LWM is more forgiving than VTP in that FS won't usually crash right away, but rather start representing crap. You can follow the polygons within the LOD8 cell in file order to see which one is the last one to be well displayed, and there is your problem.Regards,Juan.

[Guest]

Thanks DickI'll certainly give that a shot a little later today. Usually when using multiple LOD 13 LWM's I don't get to that 62 point limit as each Area doesn't cover that large of the Area but with several experiments using only one LOD 13 and a detailed shape that covers most of the Area I've found more points are necassary otherwise I'll have long straight lines in the LWMPoly.Thanks BroKen

[Guest]

Thanks JuanI'll store that important information somewhere in my peabrain for later use. I'm certain it'll come in handy in the future.Take CareKen

[rhumbaflappy 113]

Hi Juan.Then you did find the limit as 317. Good to know for sure.Dick

[rhumbaflappy 113]

Hi Juan."You can follow the polygons within the LOD8 cell in file order to see which one is the last one to be well displayed, and there is your problem."Wise words! That is a great debugging tip for LWMs. Using TDFCalc3, you can slew to the first bad Area, and then use the search function to find that Area in the ASM file. The preceeding Area code has the bad instruction, as you say.I'm really looking forward to your scenery, and any help or details of your method you can pass along!Dick

[Guest]

DickI just got done checking that helpful hint out and it worked very nicely although it was the LWMPoly2Ex line and I used 91 points.LWMPoly2Ex 63, 0, 0, 1200, 0, 28Sure am glad this works but I'm uncertain at this point how I'll implement this into LWMDraw.Thanks againKen

[rhumbaflappy 113]

Hi Ken.Of course, you're right... LWMPoly2Ex.Couldn't your program code just check if the pointcount exceeds 62, and if so then write the LWMPoly2Ex line instead of the LWMPoly2 line?Seems like an "If...Then" statement would do it.Dick

[Guest]

Umm, I think your right Dick. That does make sents so I'll work on that awhile and see what I come up with. I'm sure it can be done but unsure if I can do it but practice make perfect they say. :)Later BroKenIf budcan = full Thenbudcan = full + 2morebudcansfullEnd If

[Guest]

Hi DickSome very helpful programming people gave me several examples of IF statements and from that it worked within the VTP source file so I applied that knowledge to the LWM side and got it working as well. I guess the sky is truly the limit and LWMDraw should soon be able to handle complete lakes with shorelines and a small amount (less than minute) of manual editing to select road/line/shoreline type although I'll eventually put that into a combobox for quick selection.And I learned a valuable lesson in the process, I called a label string as an Integer and got the dreaded runtime error 13 type mismatch but re-edited using CLnt and that fixed the problem. At least I know what not to do now for that anyway.Thanks for your great help Bro! :-beerchug Ken