• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

HELP!! Crash on SPLITGRID

I see a folder x86, are you sure you are running a 32 bit version of Windows? For a 64 bit OS you need to grab the x64 version of scenProc.
 
So you have the subfolders gdal-data and x64 in your installation folder as well? The message indicates that some required files are missing. I added this check to prevent issues later on.
Got both folers with files:

scenProc

View attachment 17477
gdal-data

View attachment 17478
View attachment 17479

x86
View attachment 17480View attachment 17477 View attachment 17478 View attachment 17479 View attachment 17480
I see a folder x86, are you sure you are running a 32 bit version of Windows? For a 64 bit OS you need to grab the x64 version of scenProc.
Oops. :oops::rolleyes: My dyslexia kicks in again (excuse). Like an idiot I just took the bottom file and didn't look up the list for the 64-bit version.
Sorry.
ian
 
Arno - I don't know what you did with that endless loop but scenProc is now super-fast (I mean really fast and on huge files) and is working perfectly in this release. Now I can test all zones, it appears the problem polygons are being processed.

My utmost thanks to you on this one, sir!!! (PayPal here I come)

ian
 
Glad to hear it's working now.

I add some checks that if a polygon enters in a very long loop it is stopped. In that case the Boolean result is also empty, so it might result in a few missing polygons. But I thought that would be acceptable in general (better than not responding or crashing).

Although from your feedback it seems that you don't miss any polygons yet, so that is even better :)
 
Strangely enough for most zones I appear to be getting more autogen files though I haven't ha a chance to test for missing polygons. It does look as though the impact is minor as I had only one or two problem polygons in each area out of thousands.

I'll share the outcome with you soon!

And thanks, again...
 
It's weird that you get more autogen files. That would mean that the data covers a bigger area than before. Because each file is linked to a certain location.
 
I think it's able to process areas that failed previously (even if only one polygon in there broke the code), hence the additional files. I don't know if that makes sense.
 
That could also be the case of course.
 
I add some checks that if a polygon enters in a very long loop it is stopped. In that case the Boolean result is also empty, so it might result in a few missing polygons. But I thought that would be acceptable in general (better than not responding or crashing).

Although from your feedback it seems that you don't miss any polygons yet, so that is even better :)

Hi Arno - you might waant to close this thread now - because I keep adding more!

Can you help me understand the logic you use in your checks? Could you just "skip" the never-ending polygon and move onto the next rather than quit the main loop?

I have now found that it appears to exit the loop at a "bad" polygon and then (as you note) skips polygons that follow it. Polygons previously processed are no longer rendered in FSX. I'm wondering if there's just a way to skip or exit the bad polygon without processing and at least keep the ones that can be done. I have no clue if that's possible. Though I have relatively few polygons that can't be processed, I found two situations at least where they apparently came before a large number of "good" polygons which did not then appear. If I worked through the input "manually" I had been able to isolate the bad polygon and get the others working. Does that sound right?

A fix for this is one would be just for an ideal world. Meanwhile I can still work through the remaining bad areas manually. What I do is gradually shrink down any area that fails because of a bad polygon (using smaller and smaller grid squares) until I'm only left with that one and a couple of others. (I wish I could script this in QGIS using Python or similar). I generally get down to the single polygon and can ignore it. Programmatically I guess I would mark a failed zone (not polygon), complete the good ones, divide the failed zone again, and recursively drill down - but watching for the endless loop as you do.

Nice challenge, huh? And you don't have a thousand other things to do!!! ;)

(Actually I don't know how you find the time to do any or all these things - do you ever sleep?)

Thanks for the help, sir.

ian
 
Back
Top