The test team of cfs2autocoast can use this thread to post bug reports.
Current version: Community Preview 1 (build 3.0.4963.39491)
Known issues:
First Fill does not show up - fixed for next release
Application exception section 981180
Hi all.
I think this may be primarily a registry issue. There is a utility to force the registry to show FS9 as installed:
http://tweakfs.com/download/fs9path_utility.zip
Dick
You know that would be too easy...Originally Posted by rhumbaflappy
I already tried just the registry but it needs a lot more (using Sysinternals process monitor I'm checking step by step what's missing; an file called fs9.exe and a non-empty scenery.cfg and a bunch of bitmaps).
Sander
This has been a common error - 4 out of 13 occasions now in my testing - and so I did a little test.
I created SBuilder exports for a LOD adding one extra layer of detail (roads, rivers etc) at a time.
To cut a long story short, the 'problem' seems to be with the fs9 UT .bgl. If I create a combination that includes that I get the error. If I include all the other elements except that I can compile the cfs2 .bgls. I tested 2 of the 4 LODs that failed and got the same result.
Having said that, it doesn't apply to every LOD because I have successfully compiled .bgls that do include that data.
Anyway, maybe this will help you.
Cheers
BuV
That's interesting, 'cause as far as I know I'm just silently dropping the UT lines while the SBX is loaded, so they should not even be in memory when you click the "make" button... maybe for those area's MS has used a different line type for the utilitymask. Good stuff, this really helps with the debugging. Thanks!
I'll be going over each bug this weekend, there will probably be a bugfix release on sunday.
Current version version CP2 (build 3.0.4970.25983)
Too many polys in texture... but the FS9 version compiles just fine, so that tells me there is a problem with the cfs2autocoast code. I've attached the FS9 files and the SBX. This is data from SRTM Watermasks I've been playing with. I beleive the waterpolys will compile, but the vtp2 lines won't convert.
Attachment 91790
Dick
My oh my, someone has been a busy boy
Interesting issue....bug reproduced, confirmed and promoted to first-in-line.
Edit: is it the first such SBX that you have tested with? Are others compiling ok?
Edit2: the LWM appears to contain Polygons instead of FillArea1x1; that points to dirty compilation of the FS9 bgl. I'm mow working on clipping LWM poly's within cfs2autocoast; would that make matters easier?
The source contains such a high level of detail that there are more than 126 poly's (=line segments) of the same texture in a single LOD13 in many instances. (such detail that will be overkill for the result). Since the FS9 stock is so much simpler, it never occurs so I just caught it with the msgbox error. Now I have to program that a new texture with same TextureID is created on the Cell/Area/Layer/Texture stack. On the other hand, looks like there's some work to be done on the nested island-on-lake detection as well ....
Attachment 91796
Pffff the LWM will compile for that sbx, but the result is really messed up.
Hi Sander.
Attached is a comparison of the .bgs files from TMFViewer.
FS9.bgs is the decompiled SBuilder fs9 LWM bgl
Knobloch.bgs is the converted FS9.bgs... from Edgar Knobloch's cfs2conv.exe
cfs2autocoast.bgs is the decompiled cfs2autocoast.bgl ( not the original bgs )
FS9 and Knobloch compile just fine. cfs2autocoast is not right.
One thing I noted is you are shifting the points by one. If you are trying to get rid of the zero, just convert the zero point to 1, and leave the rest alone. I don't think the default CFS2 LWMs use 0 as a point... just like the vtp1 doesn't use 0.
Attachment 91798
Dick
Those 0's should be in there - I check for that
Anyway, it's going to have to wait for another day.... getting ready for the working week ahead now.Code:If y > 255 Then y = 255 If y < 3 Then y = 1
Just a thought: most likely have to use PolyEx I suspect.
Hi Sander.
I may have found a problem with the cell and area sorting. We are supposed to presort the cells and within the cells the LOD13 areas. Starting with the NW corner across the row to the NE corner... then back to the west, and down to the next row.
VTPDataArea 1, _Method1_, 0, 0...
VTPDataArea 1, _Method1_, 1, 0...
VTPDataArea 1, _Method1_, 2, 0... until-> VTPDataArea 1, _Method1_, 31, 0...
VTPDataArea 1, _Method1_, 0, 1...
VTPDataArea 1, _Method1_, 1, 1...
VTPDataArea 1, _Method1_, 2, 1...
until-> VTPDataArea 1, _Method1_, 31, 31...
always incrementing the x values to the end of the row (y), before dropping down to the next row. ( VTPDataArea 1, _Method1_, x, y )
This is also true of cells, and is true for LWM as well as vtp.
I think the complicated example I had was too much for BGLC when the cells and areas are unsorted. This was a problem in the early days of LWM and VTP discovery, as i recall.
Dick
Hi Dick,
It will be rather easy to add SortAreaCollection (since I already have SortCellCollection), so I'll give that a try, but I fear that will not solve the compilation issue.
We're working with such tiny polygons here (duh, 200 poly's on a 255x255 pixel grid, I mean Like Come On) that it's likely that some of them are impossible to create (sub-1 pixel, impossible UV map), similar to the issue I posted on FSdeveloper forum a few weeks ago.
The SDK's explicitly mention that the Area polygons (LWM for sure) in a Cell are read and drawn as a stream; later in the list drawn on top. But if the community found out otherwise, who am I to argue
The perfectionist in me says yeah cfs2autocoast has to work for ANY poly collection you throw at it, the realist in me says: we have to decrease the pointcount somewhat.
Sander & Rhumba,
Code talk is way above my head, but in my G2K project work I do recall several times Rhumbas VTP_fix stalling with bgs code > 10.2mb(from memory, I need to check this figure), so I'm guessing it may be a BGLC limit?
I resolved my VTP compile issues by breaking the project into smaller lumps for vtp lines. Given the complexity of some LOD 5 cells, I can understand the hard limit might actually be in the compiler then?
Hope this helps.
Thanks, but that's not the case though. When you de-compile a stock cfs2 file, it is also a very large file. If you then re-compile it, it works fine.
The biggest problem is the lack of error info from BGLC; it reports all vague errors with line number 65534.....
:isadizzy:Ordered area's makes no difference for the VTP, as I suspected. The hunt is on for the offending poly (like a needle in a haystack).
Well, the LWMPoly1Ex story is yet another headache.
I've implemented what I think is in accordance with the SDK, but it just throws a syntax error every time....Code:LWMPoly1Ex Macro PointCount, Reserved, Attrib, ExPointCount
Code:LWMDataAreaDrawPolygons 1,3,1,0, 2 LWMPoly1Ex 63, 0, _Water_, 15 LWMPoint 146, 1 LWMPoint 147, 4 LWMPoint 148, 13 LWMPoint 149, 19 LWMPoint 150, 24 LWMPoint 153, 33 LWMPoint 153, 41 LWMPoint 152, 47 LWMPoint 153, 52 LWMPoint 154, 58 LWMPoint 152, 69 LWMPoint 152, 76 LWMPoint 151, 81 LWMPoint 149, 93 LWMPoint 148, 98 LWMPoint 146, 103 LWMPoint 144, 110 LWMPoint 142, 115 LWMPoint 139, 121 LWMPoint 137, 127 LWMPoint 135, 132 LWMPoint 135, 138 LWMPoint 136, 145 LWMPoint 134, 149 LWMPoint 133, 157 LWMPoint 130, 161 LWMPoint 129, 166 LWMPoint 127, 172 LWMPoint 125, 177 LWMPoint 122, 181 LWMPoint 120, 185 LWMPoint 118, 189 LWMPoint 115, 197 LWMPoint 114, 202 LWMPoint 113, 206 LWMPoint 110, 217 LWMPoint 110, 222 LWMPoint 108, 226 LWMPoint 106, 235 LWMPoint 105, 242 LWMPoint 106, 254 LWMPoint 106, 255 LWMPoint 82, 255 LWMPoint 82, 253 LWMPoint 84, 248 LWMPoint 86, 233 LWMPoint 86, 224 LWMPoint 88, 218 LWMPoint 89, 213 LWMPoint 90, 205 LWMPoint 91, 199 LWMPoint 93, 194 LWMPoint 95, 177 LWMPoint 96, 166 LWMPoint 97, 158 LWMPoint 99, 153 LWMPoint 100, 147 LWMPoint 100, 139 LWMPoint 99, 133 LWMPoint 97, 128 LWMPoint 95, 122 LWMPoint 93, 116 LWMPoint 91, 108 LWMPoint 90, 104 LWMPoint 87, 98 LWMPoint 86, 89 LWMPoint 85, 83 LWMPoint 84, 78 LWMPoint 81, 69 LWMPoint 81, 61 LWMPoint 82, 55 LWMPoint 81, 51 LWMPoint 80, 44 LWMPoint 82, 31 LWMPoint 82, 23 LWMPoint 84, 17 LWMPoint 85, 13 LWMPoint 86, 1
The above attached rhumba_lwm.zip compiles for me. And I then ran the resulting BGL through LWMViewer to obtain another bgs file.
I took both bgs files, stripped the blank lines and lines with comments... and they are then the same length. So that seems to have solved some of the problems with LWM files. I don't know why it would throw an error.
I'm attaching the most current version of Jim Keir's LWMViewer, as well, which includes the most current macros and headers.
Attachment 91847
Dick
No way. I'll have to try on a different PC tomorrow.
Oh boy, on another PC (Win8 in US English/Regional settings Dutch) it compiles fine, like with you. My home laptop (Win7 Dutch/Regional settings EN-US) it throws a syntax error on each LWMPoly1Ex line.
Hi all.
I found a very good method for simplifying polygons. http://www.mapshaper.org/notice.html
This is an online simplifier that works extremely well... I can reduce vertices to 15% without appreciable loss of recognizable shapes. There is a 'stand-alone' html/javascript version at the GitHub site, so you don't need to be online to use the routines. It's very quick. I'm using it with the SRTM watermasks to make LWMs. What I need now is a reliable way to convert shapefiles to BLN without using GlobalMapper or SBuilderX.
Dick
Hi Dick,
that is very promising, but I have a couple of concerns about using that method and in particular using BLN files as intermediary format.
Wouldn't it be nearly impossible to create flattens at the correct altitude for lakes and rivers since BLN's don't include altitude info? And difficult to get the correct shoreline types (alt=0: ocean, alt>0erennial or something)?.
Hi Sander.
I agree. But to get information into SBuilder9, we have limited choices. It might be possible to create a SHP2SBX9 program that would contain the information. (I have found SAGA can properly convert SHP files to BLN).
Another possiblity is to use SBuilderX SBX files for CFS2autocoast, as that allows SHP files.
Dick
Hi Dick,
Just tried to run SBuilderX without having FSX and after a bit of moaning it started and the import/export functions are enabled. Haven't loaded any shp files yet but it appears the SbuilderX-SBX route is the most feasible.
Members who have read this thread: 2
Posting Permissions
Reply With Quote
Bookmarks