PDA

View Full Version : [cfs2autocoast] Test team bug reports



Sander
August 8th, 2013, 13:27
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
http://www.sim-outhouse.com/sohforums/images/smilies/icon35.gif Application exception section 981180
http://www.sim-outhouse.com/sohforums/images/smilies/icon35.gif Application exception section 957130
http://www.sim-outhouse.com/sohforums/images/smilies/icon35.gif Illegal point error 981190
http://www.sim-outhouse.com/sohforums/images/smilies/icon35.gif Cannot build color mapping table (GUI shortcoming)
http://www.sim-outhouse.com/sohforums/images/smilies/icon35.gif Cannot install SBuilder without FS9
http://www.sim-outhouse.com/sohforums/images/smilies/icon35.gif No LOD13 clipping of LWM polygons; only de-compiled LWM can be used

rhumbaflappy
August 8th, 2013, 17:08
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

Sander
August 9th, 2013, 02:03
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...
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).

blohmundvoss
August 9th, 2013, 02:43
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

Sander
August 9th, 2013, 03:18
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.



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

Sander
August 10th, 2013, 09:10
Current version version CP2 (build 3.0.4970.25983)

rhumbaflappy
August 11th, 2013, 12:36
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.

91790

Dick

Sander
August 11th, 2013, 12:55
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?

Sander
August 11th, 2013, 13:53
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 ....
91796

Sander
August 11th, 2013, 14:40
Pffff the LWM will compile for that sbx, but the result is really messed up.

rhumbaflappy
August 11th, 2013, 15:03
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.

91798

Dick

Sander
August 11th, 2013, 15:25
Those 0's should be in there - I check for that

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.

rhumbaflappy
August 11th, 2013, 17:32
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

Sander
August 12th, 2013, 01:08
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.

UncleTgt
August 12th, 2013, 04:31
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.

Sander
August 12th, 2013, 05:03
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.....

Sander
August 12th, 2013, 11:16
: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).

Sander
August 12th, 2013, 13:30
Well, the LWMPoly1Ex story is yet another headache.


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....


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

rhumbaflappy
August 12th, 2013, 14:28
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.

91847

Dick

Sander
August 12th, 2013, 14:49
:jawdrop: No way. I'll have to try on a different PC tomorrow.

Sander
August 13th, 2013, 04:07
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.

rhumbaflappy
August 13th, 2013, 15:24
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

Sander
August 14th, 2013, 02:50
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>0:perennial or something)?.

rhumbaflappy
August 14th, 2013, 10:22
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

Sander
August 14th, 2013, 12:32
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.

Sander
August 14th, 2013, 23:57
A bit of testing reveals that it will be rather simple to implement the processing of SbuilderX SBX. It's pretty much the same, for the polygons anyway.
Then when I've completed the LWMpolyClipping routine, those STRM SHP files should be pretty straightforward to convert/ same as the FS9-bgl-Sbuilder9 procedure. Well, as long as we can get the Altitude data linked to the polygons somehow anyway.

rhumbaflappy
August 15th, 2013, 15:44
Hi Sander.

The original SWBD tiles ( SRTM waterbody ) do have the elevation as a z value, which do get appended correctly to SBuilderX. They don't tile above N60...

Dick

blohmundvoss
August 16th, 2013, 03:24
Guys

This may already be covered but . . . using the latest release:

LOD5 956150 did compile but with two errors: (1) Illegal pointcall on X and Y (twice) as before (2) ASMfileVTP attempting to add a 1 point line.

Other LODs nearby - 956160, 957150, 957160 - all compiled without errors.

(FYI - I found an FS9 LWM where some small islands south-east of Singapore appear to have been incompletely drawn originally i.e. the coastlines are incomplete and bleed out into the general background. I haven't checked it out in FS9 yet.)

Cheers
BuV

Sander
August 16th, 2013, 03:54
Guys

This may already be covered ...
BuV

No it wasn't. I'll take a look at it.

UncleTgt
August 17th, 2013, 08:00
Picked up a copy of FS9, installed & SBuilder up & running.

Unsurprisingly, I picked LOD5 988330 (New Ireland area) as my first project.

Got a compile error with the -6 vtp compile,

"Assembling: c:\program files\ground2k\sbuilderfs9\projects\988330_vtp_6.a zm
c:\program files\ground2k\sbuilderfs9\projects\988330_vtp_6.b gs(24598) : error A2071: initializer magnitude too large for specified size
VTPPointXYUV(5): Macro Called From
c:\program files\ground2k\sbuilderfs9\projects\988330_vtp_6.b gs(24598): Include File

complete compile log is in the attached text file. Other lines seemed to compile OK.

Need to play a bit more with Sbuilder - I can see the possibilities are huge.
Is there a way of selecting lines & picking them up to correct "offset" with the SRTM mesh? It would save a lot of time compared to selecting line by line & repositioning.

Next observation is about shorelines. If we use all the FS9 lines as is, they really need tweaking to improve transparency, like Jean Bomber & myself have done with the vshoresu. This allows the water colour from the underlying waterclass to show through, just leaving whitecaps, surf & coast. All of these will need tweaking in the same manner, using bmp2000, & it can be tedious work :icon35:

Sander
August 17th, 2013, 09:15
BuV: The warning from 956150 was easy to fix: there was a 1 point line in the SBX; amazing that problem didn't occur before.

UncleTgt:I was not able to reproduce your error; 988330 completes in all older and newer builds of cfs2autocoast (1017 lines). There must be something wrong with your SBX. Please try again to build it step by step. If you still get the error, please zip and e-mail the SBX to me.
Rhumba and me are working on ways to use SRTM watermasking instead of FS9, that should be a better fit. Reorganizing the FS9 files is not practical.
For the texture, it'll be an artistic mix-and-match operation of better fitting textures for each region, sure there's some work to do there. Not only depending on the used Water textures, but also matching the Landclass terrain textures for each region/sub-region.

blohmundvoss
August 17th, 2013, 13:27
BuV: The warning from 956150 was easy to fix: there was a 1 point line in the SBX; amazing that problem didn't occur before.

And just like buses . . . here comes another one.

I got this error again in 976260 - only in this case the errors were doubled (just to make up for the previous lack :icon_lol: )

Cheers
BuV

Sander
August 17th, 2013, 13:41
There'll be a bugfix release tomorrow.

UncleTgt
August 17th, 2013, 14:07
Still getting same error with 988330 - my build shows 1016 lines, not 1017 lines.
No RR or UT lines.
FS9 is fresh, unmodified install from disks, patched to 9.1 with MS download patch.

Sander
August 17th, 2013, 15:51
Still getting same error with 988330 - my build shows 1016 lines, not 1017 lines.
No RR or UT lines.
FS9 is fresh, unmodified install from disks, patched to 9.1 with MS download patch.

Ok, I can reproduce the problem with your SBX file. Will be fixed in tomorrows release :)

Sander
August 17th, 2013, 15:55
... RR or UT lines.....

The failing BGL is actually RD; there appear to be no railroad in that part of the fs9 world.
The UT are not used at the moment; reserved for utility pylons 3d objects.

Sander
August 18th, 2013, 04:35
----------------------------------------------------------------------------------------
Current version is now Community Preview 3 (CP3), build 3.0.4978.21535

:wiggle:

Sander
August 25th, 2013, 03:47
----------------------------------------------------------------------------------------
Current version is now Community Preview 4 (CP4) Build3.0.4985.18153
:jump:

blohmundvoss
August 29th, 2013, 05:18
Sander

I took a flight over Wonsan in Korea today and spotted this:

9252292521925209251992518

It runs along the junction of two LOD5 cells - 982170 & 982180 - shown below in the original FS9 LWMs

92523

At first I wondered if it was cause by the 'ragged' edge of the original FS9 LWM for 982170 to the north - shown below in LWM Viewer (hopefully you can see the 'thick' line) - and which I hadn't spotted or edited in SBuilder.

92524

I deleted the ragged edge, recreated the SBX file completely and recompiled - but the problem persists. I now see that the issue seems to be with just one part of the cell - Area 656 x 143 in LWM Viewer.

92525

Strange.

Cheers
BuV

Sander
August 31st, 2013, 02:08
Sander

I took a flight over Wonsan in Korea today and spotted this:


It runs along the junction of two LOD5 cells - 982170 & 982180 - shown below in the original FS9 LWMs



At first I wondered if it was cause by the 'ragged' edge of the original FS9 LWM for 982170 to the north - shown below in LWM Viewer (hopefully you can see the 'thick' line) - and which I hadn't spotted or edited in SBuilder.



I deleted the ragged edge, recreated the SBX file completely and recompiled - but the problem persists. I now see that the issue seems to be with just one part of the cell - Area 656 x 143 in LWM Viewer.



Strange.

Cheers
BuV

It appears to be the general "missing texture" behavior. Please check in the _vtp_8_textures.txt file if you are missing the BMP for the shorelines. In some cases I've found that sometimes fs9 changes textures from one LOD5 to the next.

blohmundvoss
August 31st, 2013, 03:30
Sander

I checked the texture files and confirmed that all the .bmps are present.

Currently, I am loading every edited LOD5 cell as a separate scenery layer to make it easy to manage them. Bearing that in mind, I changed the scenery precedence to put the 982170 cell 'above' 982180 to discover:

9257692577

As you can see, the problem disappears except for that small area of coastline.

Taking these thoughts a step further, I amalgamated the .bgls for the two cells in one folder and found the problem reappeared with some additional texture blotches.

92578

By the by - a few days ago I created one folder to hold all the .bgls for Burma. When I tried to launch 'Free Flight' it took several attempts to achieve it and the sim seems to be producing poor resolution textures. I put that down to some eccentricity in my rig and am leaving it in peace for a while before I try again. Perhaps this is something similar. I would love to know if anyone else is having any similar problems dealing with bulk files.

Cheers
BuV

Sander
August 31st, 2013, 03:42
I suspect you have some non-default Landclass loaded. I suggest creating a clean install, and add just the cfs2autocoast stuff to it (all in a single folder should NOT be a problem), above the default scenery (for the Korean LOD5's you mentioned, obviously the default coastlines will still show through, but that's not the issue right now).
Or at least disable all Landclass related add-ons (Rhumbaflappy's Tropical set?)

Sander
August 31st, 2013, 03:44
Oh yeah, another thing: screenshots in Chase view are pretty useless for me to analyze this type of issue; please only use Top Down view.

blohmundvoss
September 2nd, 2013, 02:31
Very weird.

I loaded the scenery into a clean install - original landclass, coastlines, textures etc with no other alterations/additions - and still see the same issue.

92642

I also rebuilt/recompiled the 982180 files as well, given the apparent interaction, but to no avail.

Cheers
BuV

Sander
September 2nd, 2013, 03:12
The only way I can reproduce the problem is by compiling 982180 with the CellFill type as Land... Did you by any chance compile any of the surrounding SBX's with the CellFill=Land option enabled?

blohmundvoss
September 5th, 2013, 04:25
The only way I can reproduce the problem is by compiling 982180 with the CellFill type as Land... Did you by any chance compile any of the surrounding SBX's with the CellFill=Land option enabled?

I've compiled all the cells so far with 'Default cell type fill' set to 'Land' as per your remark in the tutorial about this being the best way to stop LWM in lower layers from showing through.

If I've misunderstood something that would explain it.

Taking your earlier hint about neighbouring cells, I tried changing the scenery layer precedence and got more of the same issue.

92763

Cheers
BuV

Sander
September 5th, 2013, 06:23
I've compiled all the cells so far with 'Default cell type fill' set to 'Land' as per your remark in the tutorial about this being the best way to stop LWM in lower layers from showing through.

If I've misunderstood something that would explain it.

Taking your earlier hint about neighbouring cells, I tried changing the scenery layer precedence and got more of the same issue.


Cheers
BuV
I've found a better way to do the DefaultCellFill; the next release will only paint the ground fill in the cells that are actually part of the LOD5 you're working on. This will prevent accidental Land Fills in the cells where the LWM files overlap, thus preventing this problem.

blohmundvoss
September 5th, 2013, 11:22
I've found a better way to do the DefaultCellFill; the next release will only paint the ground fill in the cells that are actually part of the LOD5 you're working on. This will prevent accidental Land Fills in the cells where the LWM files overlap, thus preventing this problem.

Great! I hope this does the trick since I would hate to think I couldn't help out with the conversion work because of some anomaly on my part.

By the by - the trick to texturing hills that you've introduced is terrific. Looking forward to the next release.

Cheers
BuV

Sander
September 13th, 2013, 04:57
----------------------------------------------------------------------------------------
Current version is now Release Candidate 1 (RC1) Build 3.0.5004.18489
:jump:

blohmundvoss
September 14th, 2013, 03:35
Hi Sander

I'm sure there is a blindingly obvious reason for this but . . . (1) after recompiling my SBX files for Korea using the new version (2) using the original textures folder from v.1 (3) on a clean install with no modifications . . . I see:

9317693177

Cheers
BuV

[edit] this is by dragging and dropping the SBX files onto the application just in case this is an issue

Sander
September 14th, 2013, 03:55
Hi Sander

I'm sure there is a blindingly obvious reason for this but . . . (1) after recompiling my SBX files for Korea using the new version (2) using the original textures folder from v.1 (3) on a clean install with no modifications . . . I see:

9317693177

Cheers
BuV

[edit] this is by dragging and dropping the SBX files onto the application just in case this is an issue

Because with this new version a Land Class file is also created, you need to make sure you have a complete terrain texture set in the texture folder, or move the 9****0_lc.bgl to a scenery folder where you have terrain textures.

Sander
September 14th, 2013, 04:10
I'm very curious to see if/how the Land Class modifications work in the H-band (south); I've only been testing N-America/Europe...

blohmundvoss
September 14th, 2013, 06:04
Phew! Not that you had doubts, I'm sure.:jump:

Not the best use of space, I suspect, but I have got around the immediate problem by copying my SCENEDB\World\texture folder into my Korean scenery texture folder - as you suggested. Having proved that it worked on my clean install I then did the same for my Korean War install.


I'm very curious to see if/how the Land Class modifications work in the H-band (south); I've only been testing N-America/Europe...

As you already know, I have PacTex in my Korean War install; here is a before and after shot, showing the differences using the new landclass files. Noticeable, if not dramatically so in just this one example - but they do work.


9319193192

Great stuff, Sander.

Cheers
BuV

p.s. the problems near Wonsan I mentioned in previous posts have disappeared as well.

Sander
September 14th, 2013, 06:16
Cool!

rhumbaflappy
September 14th, 2013, 08:20
I believe CFS2 follows the same rules as other sims in the FS series concerning landclass and waterclass textures. If so, then you only need the textures actually used by the lc bgl in the local texture folder... may save some disk space. This approach also allows each group to have it's own texture set. In this context, it may make sense to organize groups of LOD5 BGLs into regional areas, rather than as continents... something for the future perhaps, if we can derive a good set of regional textures, like FSX has.

Dick

rhumbaflappy
September 14th, 2013, 08:25
What I'm doing now is editing the SBX files LWM fills. Assuming the 'Land' cell designation, rather than transparent, I delete all the fills, then refill the water fills.

I start filling complete 32x32 fills using the LOD8 grid view. Then go to LOD9, LOD10... until all water fills are complete. It is a slow process for island areas and coastal areas, but it makes a good LWM BGL.

Dick

Sander
September 14th, 2013, 09:57
I believe CFS2 follows the same rules as other sims in the FS series concerning landclass and waterclass textures. If so, then you only need the textures actually used by the lc bgl in the local texture folder... may save some disk space. This approach also allows each group to have it's own texture set. In this context, it may make sense to organize groups of LOD5 BGLs into regional areas, rather than as continents... something for the future perhaps, if we can derive a good set of regional textures, like FSX has.

Dick
Yes, differentiation of the LC texture sets should follow different criteria then the regional separation of LWM/VTP's. Since CFS2's LClookup.bgl is a lot more limited than FS8/9's, we'll need more sets. For instance where in FS9, cities can be either "grid" or "non-grid" style, CFS2 uses the same textures for both.

Sander
September 14th, 2013, 09:59
What I'm doing now is editing the SBX files LWM fills. Assuming the 'Land' cell designation, rather than transparent, I delete all the fills, then refill the water fills.

I start filling complete 32x32 fills using the LOD8 grid view. Then go to LOD9, LOD10... until all water fills are complete. It is a slow process for island areas and coastal areas, but it makes a good LWM BGL.

Dick
That's exactly how I do it too.
I've done EURW and NAMW completely now. Gotta remember to make sure the Altitude is at 0.... made a bit of a mess-up near the Norwegian coast with that....

blohmundvoss
September 16th, 2013, 01:37
That's exactly how I do it too.


Me too. There's one thing I have noticed during this process - and it may explain an old phenomenon in EURW. Remember the thin white lines that sometimes used to appear in the sea? I remember Sander saying this may have been a side-effect of compiling but, working with the FS9 LWMs in SBuilder, I notice that some areas are incompletely filled i.e. very thin white lines at the edge. Sometimes these are not noticeable unless you zoom right in and in some areas there is no other obvious reason to do this. I only spotted it by accident.

I'm happy to be given my homework if you're ready to start cranking out the Cells . . .

Cheers
BuV

Sander
September 16th, 2013, 03:26
Me too. There's one thing I have noticed during this process - and it may explain an old phenomenon in EURW. Remember the thin white lines that sometimes used to appear in the sea? I remember Sander saying this may have been a side-effect of compiling but, working with the FS9 LWMs in SBuilder, I notice that some areas are incompletely filled i.e. very thin white lines at the edge.
That problem back then was caused by a bug in Ground2k where the VTP1 texture x,y started at 0 instead of 1. What we deal with now are LWM polygons that do not quite fill an area. The fix for that is to use a Fill in those area's.


I'm happy to be given my homework if you're ready to start cranking out the Cells . . .
Cheers
BuV
I think I'll start collecting the regions on Skydrive, so we can get the world together. To get a full SVN repository going turns out to be a bit of a challenge and take a bit longer (finding a suitable free hosting provider).
Considering Dick has SAME and OCEN, I started on EUR and NAM: ASIA and AFRI are up for grabs....

blohmundvoss
September 16th, 2013, 05:32
What we deal with now are LWM polygons that do not quite fill an area. The fix for that is to use a Fill in those area's

I suppose what I'm really saying is that - unless we zoom in on areas that appear at the first view to be complete - we may have small gaps in the water fills. If folks are checking for stuff like this anyway, then no problem. Worst case, people spot a gap and mention it. Hardly the end of the world.

Thanks for the reminder about altitude. Can't swear that I've avoided this problem either even if I haven't noticed it.


ASIA and AFRI are up for grabs....

Happy to carry on with Asia - or do both - if that helps.

Cheers
BuV

rhumbaflappy
September 16th, 2013, 13:13
I'm reworking Ocen with the new program. I have finished Aust and will be reworking Same.

Ocen has "lines" of unnecessary watermasking in every FS9 HP BGL. Slow going to delete these artifacts. Occasionally there are errant VTP lines as well. I'm trying to keep editing of the fills to a minimum.

2 weeks and I hope to have them done with polys and fills of water, and cell "background" of land. Then I can go after Africa if it is still open.

Dick

blohmundvoss
September 16th, 2013, 14:12
Occasionally there are errant VTP lines as well. I'm trying to keep editing of the fills to a minimum.

One thing I've spotted - two occasions in a (relatively) small number of cells I've tested so far - is a failure to completely draw a coastline. Even though these render in FS9 (with some odd results) they fail to compile in cfs2autocoast (surprise!) and so obviously need editing.

For the record, I'm doing an out-of-the-box conversion as well for Version 1 (although there's already a couple of areas I'd now love to customise with SBuilder as a training exercise. Next version.)


Then I can go after Africa if it is still open.


Fine with me Dick - but I'm happy to help if you get there first.

Cheers
Ian

blohmundvoss
September 17th, 2013, 05:46
Sander

I've run into a problem regarding inland desert areas in Asia (e.g. Iraq) that have no corresponding LWM files (HP, HL) in FS9 and therefore no polygons. The tool is refusing to compile the SBX file.

I can obviously post the error report if that would be more helpful.

Cheers
Ian

Sander
September 17th, 2013, 06:09
Sander

I've run into a problem regarding inland desert areas in Asia (e.g. Iraq) that have no corresponding LWM files (HP, HL) in FS9 and therefore no polygons. The tool is refusing to compile the SBX file.

I can obviously post the error report if that would be more helpful.

Cheers
Ian
That's interesting; I have to admit I did not test that scenario; I did test "LWM/no lines" but not the other way around! (If you want to work around the issue -as it may be a while before I get around to bug fixing- I'm sure it will work to create a tiny LWM LAND polygon somewhere in the LOD8)

blohmundvoss
September 20th, 2013, 03:09
More of a Windows issue I suspect but . . .

For some reason cfs2autocoast no longer displays the command box when it loads. No matter how I access it - by dragging/dropping a file or by opening the program directly - it immediately pins itself to the Task Bar. I can't expand the icon and using Task Manager to switch to it doesn't work either. I've tried a fresh install but no joy.

Any suggestions gratefully received. Am beavering away with Sbuilder in the mean time.

Cheers
Ian

Sander
September 20th, 2013, 03:19
More of a Windows issue I suspect but . . .

For some reason cfs2autocoast no longer displays the command box when it loads. No matter how I access it - by dragging/dropping a file or by opening the program directly - it immediately pins itself to the Task Bar. I can't expand the icon and using Task Manager to switch to it doesn't work either. I've tried a fresh install but no joy.

Any suggestions gratefully received. Am beavering away with Sbuilder in the mean time.

Cheers
Ian
I'm not exactly sure what you mean; command box? You mean the main window, where you do all the settings etc.? What version of Windows are you using? I suspect you need to clear out old settings files, but on various windows versions they are in different places.
Edit: did you EVER run the latest version successfully?
Edit: I can confirm there is a regression in the latest version that there is no context menu on the Task Bar icon... I'll need to investigate that. The .NET programmers here at my work place have no idea how that happened (or how to get it back), but it is likely to do with all the code cleanup I did....

blohmundvoss
September 20th, 2013, 05:29
I'm not exactly sure what you mean; command box? You mean the main window, where you do all the settings etc.? What version of Windows are you using? I suspect you need to clear out old settings files, but on various windows versions they are in different places

Sorry if I was unclear - but yes, I mean the main window with all the settings. (When the icon is pinned to the Task Bar, all I can see when I hover the mouse over it are 'File' and 'Edit' - which may be the two top commands if I remember correctly?). When the tool is launched I can see the main window for a fraction of a second before it reduces to an icon on the Task Bar.

I'm using Windows 7 Home Premium 64-bit SP1.


Edit: did you EVER run the latest version successfully?

Yes I have - very happily since you issued it and I was using it last night when the problem occurred. One minute it worked fine and the next it was fixed to the Task Bar.

Cheers
Ian

Sander
September 20th, 2013, 05:39
Sorry if I was unclear - but yes, I mean the main window with all the settings. (When the icon is pinned to the Task Bar, all I can see when I hover the mouse over it are 'File' and 'Edit' - which may be the two top commands if I remember correctly?). When the tool is launched I can see the main window for a fraction of a second before it reduces to an icon on the Task Bar.

I'm using Windows 7 Home Premium 64-bit SP1.



Yes I have - very happily since you issued it and I was using it last night when the problem occurred. One minute it worked fine and the next it was fixed to the Task Bar.

Cheers
Ian
Can you delete the following folder from your computer (you must change the folder settings in Explorer to show hidden files (http://windows.microsoft.com/en-us/windows/show-hidden-files#show-hidden-files=windows-vista)):
C:\Users\your_user_name\AppData\Local\SdC_Designsh op
and then try again?

blohmundvoss
September 20th, 2013, 06:10
Can you delete the following folder from your computer (you must change the folder settings in Explorer to show hidden files (http://windows.microsoft.com/en-us/windows/show-hidden-files#show-hidden-files=windows-vista)):
C:\Users\your_user_name\AppData\Local\SdC_Designsh op
and then try again?

Thanks Sander - that did the trick!

Back to work . . .

Cheers
Ian

rhumbaflappy
September 22nd, 2013, 09:13
I've completed Ocean, Aust and Same. Oceana was miserable... bad data, extra LWM lines, empty BGLs...

Now I seem to have many Area16n flattens that are not right. I'll go through the files and look at them visually. But it will be quite time consuming.

Dick

blohmundvoss
September 22nd, 2013, 14:38
I'm slogging away with Asia and figure on another couple of weeks to finish, as long as there are no interruptions. Since it's such a huge area I'm also organising the 4,000+ files (before you strip out the stuff we don't need) as I go along and taking a snapshot of each cell with LOD5_Image to help orientate myself. Makes it a bit slower but I hope it will help if/when I revisit any of the areas.

Cheers
Ian

rhumbaflappy
September 22nd, 2013, 15:38
Hi Ian.

I'll start Afri then... we.ll probably end up around the same time. then we can coordinate with Sander for whatever is left over.

Save your SBX files, as we probably should have them in the repository saved in a 'FS9_SBX' folder. We can then use them for any corrections users feed back to us.

Dick

Sander
September 23rd, 2013, 00:00
That's great progress guys.
So what do you think of the current version? If there is anything you'd like to see different or added, now is the time to speak up!
I'm probably going to finish up the code this week for the release version.

Dick, what's the problem with the A16N's?

rhumbaflappy
September 24th, 2013, 12:25
Hi Sander.

I think the A16ns are just doing what the SBX tells them... I suspect the original FS9 polys are the problem. There wasn't much error checking in the production process.

Dick

blohmundvoss
September 24th, 2013, 13:45
If you have the time, Sander, I would love a fix for the 'no polygons-no compile' issue. I'm putting any - thankfully few - problem cells to one side for the moment.

I did try your work around but finished up with a cell otherwise full of water. My very limited knowledge of SBuilder is to blame I'm sure. My next job is to spend a week really working with it for the future. I know satellite data for the higher latitudes is a bit problematic but I wonder if that explains why entire islands off the north coast of Russia are missing in FS9. It certainly doesn't explain why large inland lakes are missing (they can't all be 'recent' additions to the landscape, surely?).

Anyway, first things first. Have had a couple of productive days so far this week - my boredom threshold for the mechanical process is getting higher as I become even more familiar with it.

Cheers
Ian

rhumbaflappy
September 29th, 2013, 06:52
Hi all.

I have Afri done, as well as Aust and Ocen. I have some time to do other areas if anyone can suggest one that is open. I am saving the SBX files as well as the BGLs.

For areas that have no water polys, I save the SBX files in a separate folder and batch process tham after I adjust the CFS2Autocoast parameters to NOT process the lwm files.

93776

I remembered an interesting program by Masakazu Irie. It's the DPCle11 program that edits our old A16n flattens. You can import the BGL, add a background map, etc... the interface is a bit different, but reading the instructions allows you to edit and save a flatten BGL. Works with our flattens. :)

93775


And Sander, what do you think about parsing out the 32x32, 16x16, and 8x8 area flattens? Flattens do have a bit of a drain on the CPU, and the mesh should take care of these ocean areas.

Dick

rhumbaflappy
September 29th, 2013, 08:47
Hi Sander.

I've narrowed down the flatten errors I'm seeing. They are caused by the routine that creates flattens from the LWM areafills. I'm attaching a zip file that shows the errors.

93788

Dick

blohmundvoss
October 3rd, 2013, 07:36
Finally, I can see the end of the tunnel. Asia is done but with a few issues.

1. I'm not clever enough to batch process the 'dry' cells like Dick. I did try to run them through individually with the 'fill poly's' option unticked; worked on the first one and then failed again afterwards. I'll try to find the trick.
2. I've had several instances when the landclass bgl has failed to compile. Since nobody else has mentioned this I think I'm making a mistake somewhere and will start again from scratch with the culprit cells and see what happens.
3. I have a few cells where I need fix gaps in coastlines.

Otherwise (ha!) I'm done.

Cheers
Ian

blohmundvoss
October 3rd, 2013, 12:14
Hi Sander

I've just reworked the first of these eight failures with the same result: the lc bgl fails to compile. Given that the cell has no complications and required no editing I'm not going to check the others. Maybe you can see my mistake.

I'm attaching all the reports.

93930

Cheers
Ian

Sander
October 3rd, 2013, 12:57
Hi Sander

I've just reworked the first of these eight failures with the same result: the lc bgl fails to compile. Given that the cell has no complications and required no editing I'm not going to check the others. Maybe you can see my mistake.

I'm attaching all the reports.

93930

Cheers
Ian
I think the folder names are too long; in each instance the folder path (c:\program files (x86)\microsoft games\installs\cfs2 addons\sdc cfs2\xx my scenery_workings\asia\1_done\980250 tuguegarao cit) is truncated to 128 characters. Please try to compile the SBX's from another folder (not as deep in the folder structure).

Edit: note, the path is truncated by the Microsoft tmf tools, not by cfs2autocoast.

Sander
October 3rd, 2013, 13:23
Hi Sander.

I've narrowed down the flatten errors I'm seeing. They are caused by the routine that creates flattens from the LWM areafills. I'm attaching a zip file that shows the errors.

93788

Dick
Indeed, that looks very messy.
Very annoying; the A16NCreator function is pretty much the last of the old code from the first version that is still used.... I was hoping I wouldn't have to revise it; if it ain't broke, don't fix type of thing. Now it's been made blatantly obvious; it must be done.
But thanks for reporting it, obviously.

About skipping x32-x4 fills; I'd rather keep them in (as long as correctly implemented). There are occasions where there are islands in the open sea in the real world that are in SRTM data, but not in the FS9 world. And the CPU/GPU are not that highly loaded in the open sea anyway without much VTP, land class and mesh to process.

Sander
October 3rd, 2013, 13:31
Hi all.

I have Afri done, as well as Aust and Ocen. I have some time to do other areas if anyone can suggest one that is open. I am saving the SBX files as well as the BGLs.

NAMC, NAME and EURE are still up for grabs AFAIK



For areas that have no water polys, I save the SBX files in a separate folder and batch process tham after I adjust the CFS2Autocoast parameters to NOT process the lwm files.


I remembered an interesting program by Masakazu Irie. It's the DPCle11 program that edits our old A16n flattens. You can import the BGL, add a background map, etc... the interface is a bit different, but reading the instructions allows you to edit and save a flatten BGL. Works with our flattens. :)

Interesting little program!

rhumbaflappy
October 3rd, 2013, 15:17
I'll claim NAMC, if no one objects.

Dick

blohmundvoss
October 4th, 2013, 01:11
I think the folder names are too long; in each instance the folder path (c:\program files (x86)\microsoft games\installs\cfs2 addons\sdc cfs2\xx my scenery_workings\asia\1_done\980250 tuguegarao cit) is truncated to 128 characters. Please try to compile the SBX's from another folder (not as deep in the folder structure).

Edit: note, the path is truncated by the Microsoft tmf tools, not by cfs2autocoast.

Thanks, Sander - I'll give it a try.


NAMC, NAME and EURE are still up for grabs AFAIK.

I'm happy to do EURE.

Cheers
Ian

blohmundvoss
October 5th, 2013, 01:06
I think the folder names are too long; in each instance the folder path (c:\program files (x86)\microsoft games\installs\cfs2 addons\sdc cfs2\xx my scenery_workings\asia\1_done\980250 tuguegarao cit) is truncated to 128 characters. Please try to compile the SBX's from another folder (not as deep in the folder structure).

Edit: note, the path is truncated by the Microsoft tmf tools, not by cfs2autocoast.

Just to confirm this was the problem - now solved. Thanks again.

Cheers
Ian

blohmundvoss
October 9th, 2013, 05:01
Have just finished EurE, except for a couple of cells with incomplete coastlines.

One hassle was the difficulty of doing this kind of filling/editing in the extreme northern cells. SBuilder won't allow you to scroll beyond the northern limit and zooming in loses sight of the northern limits of the cell. Had to do some editing from a 'distance' that meant I couldn't really see what I was doing. No big deal - I hope - since these areas aren't likely to have any visitors.

Cheers
Ian

rhumbaflappy
October 9th, 2013, 17:33
One hassle was the difficulty of doing this kind of filling/editing in the extreme northern cells. SBuilder won't allow you to scroll beyond the northern limit and zooming in loses sight of the northern limits of the cell.

Yes. Same problem with NAMC. I'll start NAME this weekend, then we can sort out where we're at.

Dick

rhumbaflappy
October 18th, 2013, 12:13
I have a few odd files to fix this weekend, then I should have NAME done... and that should just about bring us up to date. We might need to wait for Sander to fix the Area16n generation before we can release the bgls, but the SBX files should be good to go.

Dick

blohmundvoss
October 21st, 2013, 04:13
I am trying - and failing - to fix the 'no polygon' Cells in Asia and would be grateful for any tips.

If I create a tiny polygon - at maximum zoom in SBuilder - I still end up with a bottomless pit in the sim, presumably because I've set no altitiude.

I know this isn't an SBuilder forum but I'm struggling to understand how SBuilder handles this since it seems to imply you have to determine the altitude of every polygon you draw before you start a project. I'm assuming that the conversion work we're doing takes the altitude info from the original FS9 files (but then I don't understand how the bgls seem to be reconciling themselves with Dick's mesh - unless they're both derived from similar sources).

I suspect the gurus will be rolling their eyes at my ignorance but hey - if you don't ask, you never learn, right?

Of course, if there is a really simple trick to solving the immediate problem even better.

Cheers
Ian

rhumbaflappy
October 21st, 2013, 15:29
Hi Ian.

For SBX files that have no water, I first alter the settings in cfs2autocoast:

http://img689.imageshack.us/img689/8284/ci84.png (http://imageshack.us/photo/my-images/689/ci84.png/)

This produces a set of BGLs with no elevation. An Area16n is made, but with no polys. There is no lwm BGL made.

Alternately, you could make a land poly, and leave the settings alone. When the files are made, discard the 9?????_a16n.BGL, which gets rid of the elevation.

Dick

blohmundvoss
October 22nd, 2013, 06:51
Thank you, Dick!

I followed the first suggestion after realising that I'd been trying to do it by deselecting 'process polygons' and not LWMs. Doh.

Cheers
Ian

rhumbaflappy
October 31st, 2013, 13:44
This might be a good time for a check-in, to see where we are at. Also, we can get 7GB file storage at Microsoft's Skydrive, and I now find files are hot-linkable... just an idea.

I have Ocen, Aust, Same, Name, Namc, and Afri done.

We still have issues with the Area16N files until Sander gives a rewrite... the problem is with the bounds of the area fills. Polygon flattens are OK.

Dick

blohmundvoss
November 1st, 2013, 03:04
I can add EurE and Asia to the mix.

I have taken my first steps with SBuilder to edit/create some missing or incomplete coastlines & islands - at least well enough for the cells to compile successfully.

I'm trying to swot up on texture types and mapping via the various SDKs - but this is new territory for me. Like you said earlier, having regional texture sets would help get the best out of the new landscape.

Cheers
Ian

UncleTgt
November 1st, 2013, 16:56
BnV et al

I made this equivalence chart from the landclass screen in Russell Dirk's EZ Landclass to help me decypher the deployment & use of the "h" landclass values. I arrived at the values by a series of trial & error. Used in conjunction with Pen32win & Sander's illustrated guides to "H" & "b" landclass values it may be of some limited help here.

blohmundvoss
November 3rd, 2013, 07:43
BnV et al

I made this equivalence chart from the landclass screen in Russell Dirk's EZ Landclass to help me decypher the deployment & use of the "h" landclass values. I arrived at the values by a series of trial & error. Used in conjunction with Pen32win & Sander's illustrated guides to "H" & "b" landclass values it may be of some limited help here.

Many thanks, Unc. Right now I'll take all the help I can get!

Cheers
Ian