Chris/Geoff, I normally see reams of these and other similar lines. I think that you are seeing some form of count for terrain type.
My usual output has other textures mixed in there and only ever <3 as the number expressed. If you are using a hight level of detail (OSM residental) and processing a 10x10 then is will take a long time to complete and any tile that has a lot of detail will produce lots of the described output. I have also noticed that the generation takes a long time due to it being single threaded ( hogs a single core ). I have tried to use the server/client but found that it just doesn't appear to work anymore...... Jason Cox ( still building YSSY to YWLM ) On Wed, 2011-06-01 at 01:35 +0200, Geoff McLane wrote: > Hi Chris, > > Glad the rough 'fixes' I provided worked a little > for you... have yet to clone your 'papillon81' > clone, and try it... but... > > While it is agreed on this list everyone seems to > really _LOVE_ extreme brevity, (perhaps except > me ;=)), your post just did not tell me > enough ;=(( > > I searched the entire terragear-cs source for - > "Default=", and did not get a single hit, well > one "... Default=%s\n", out_file)", but that's > obviously not it, so no idea where to look ;=(( > > Maybe the output is in simgear, or some of the > other libraries that are included in fgfs-construct... > > Spaces and case are vitally important... > > But what is the console output immediately prior > this 'continuous' output? Maybe that would provide > more clues as to where it is in the processing... > > It is clear fgfs-construct is getting 'stuck' > somewhere, but simply need more information... > > It is certainly _NOT_ 'normal' behavior, and > historically (I assume Curt ;=)) implemented some > draconian 'rlimit' - setrlimit(RLIMIT_CPU,<timeout>), > to abort after a period of time, which is just > NOT available in my WIN32 environment, to avoid > such a 'forever' loop... > > At the time I understand, they were building the > WHOLE WORLD world of scenery, and did not want the > process 'stuck' on some bucket, or group of > buckets... > > So while I also now play with a Ubuntu linux build, > I try HARD to find 'other' solutions for WIN32... > like finding, and fixing the 'reason' for such > 'forever' loops... > > So with more information, maybe we can track > down, and 'fix' it, forever ;=)) > > But, _BUT_, be aware, some others, who have tried > my 'fixes', including myself ;=)), especially regarding > the 'priorities' have succeeded in only producing > really _MESSED_ up scenery - see - > http://geoffair.org/tmp/mess-01.ppm > or > http://geoffair.org/tmp/mess-02.jpg > and these were generated using my modified > WIN32 fgfs construct exe - > http://geoffair.org/fg/fgfs-054.htm#downloads > so I feel I am very _FAR_ from the solution ;=(( > > Any input from others, with knowledge, would > really HELP... > > Regards, > Geoff. > > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
