• Guest Please check out the Help Wanted thread in Ickie's NewsHawks.
    The future of the Outhouse depends on you!
    Help Wanted

[cfs2autocoast] Test team bug reports

S

Sander

Charter Member
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:

:a1310: First Fill does not show up - fixed for next release
icon35.gif
Application exception section 981180
icon35.gif
Application exception section 957130
icon35.gif
Illegal point error 981190
icon35.gif
Cannot build color mapping table (GUI shortcoming)
icon35.gif
Cannot install SBuilder without FS9
icon35.gif
No LOD13 clipping of LWM polygons; only de-compiled LWM can be used
 
rhumbaflappy said:
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
Click to expand...

You know that would be too easy...
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).
 
'Unhandled exception' errors

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.


blohmundvoss said:
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
Click to expand...
 
Too many polys in texture

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.

View 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 ....
View attachment 91796
 
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.

View attachment 91798

Dick
 
Those 0's should be in there - I check for that
Code: 
    If y > 255 Then y = 255
      If y < 3 Then y = 1
Anyway, it's going to have to wait for another day.... getting ready for the working week ahead now.

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 :icon_eek:) 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.
 
UncleTgt said:
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.
Click to expand...

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.

Code: 
LWMPoly1Ex        Macro    PointCount, Reserved, Attrib, ExPointCount

I've implemented what I think is in accordance with the SDK, but it just throws a syntax error every time....

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.

View attachment 91847

Dick
 
You must log in or register to reply here.
Back
Top