Forgive this little missive (and if it's TL;DR; then you are oerfectly free to not R). It isn't what I would call a bug, but it is my attempt to document a little personal battle against the particular configuration of ones and zeros I find myself using. If it's of interest to others, I would be gratified, but it seems no great burden uponmthe world if it is of no interest and yet I have committed its own bits and bytes to the forum in one interminably forgettable post that quickly moves off of any first-page display you care to think of.
The point being... I discovered a problem with my worldgen, on my old 32-bit system that I still use for DF. I'm fairly sure it's hitting the 32-bit hard limit for memory (including virtual RAM), but I'm not entirely convinced. But that's a first-order working theory.
It took a few days to narrow down (several overnight worldgens, and a couple of while-I-was-out overday ones) but I took the offending version (slightly customised, but only in geological matters) of the LARGE ISLAND worldgen template and put into it the precise seeds noted in the gamelog from when I first tried to worldgen a new land - within which I spotted some geogrqphy that I'm still rather keen to try to explore/build upon (in parallel copies of the save). The point being that I've had identical setups except for the enforced END_YEAR.
I used to have no trouble at all with the 1050 default upon the largest world footprints (and increased inter-cavern geologies), but added complexity of the world has clearly added to the demands called upon to enumerate the end product (and in this instance I'm specifically talking of a 44.12, but it was true with 44.02 and even in prior generations to the 44 release). I have tended to get a semi-round Year of 750 going ok without problems (maybe a message that virtual memory is being expanded for me, especially if I have other intensive things running like GIMP) except for having to leave that machine alone for some time and get on with other things. But this time I got an application crash at some point after using the "p" to export the world details. Within the DF directory the regionN-00750-01-01-world_map.bmp would appear, zero bytes in size and then after a wait I'm prompted to send details of the crash off (which I decline; and it wouldn't help, anyway, as the machine is standalone). The world_gen_param and._history and _sites_and_pops text files never get created. At no point do I actually get prompted about virtual memory resizing.
By a bit of trial and error (rerunning for years above and below the point of failure, taking roughly half the difference and seeing if that's a "too high" or "not high enough to error", then repeating within this new established range) I discovered year 402 gave me a reportable save (which I seem to be able to, embark on, from the briefest of tests) and a year 403 report request crashes.
Sigmificantly, year 403 can be generated to and accepted without crash (I have yet to try to embark/adventure upon it) but I haven't yet tested the upper bound of a) No virtual memory resize notification¹ and b) No similarly irrecoverable crash². My current theory is that it (whatever 'it' really is) will not happen much prior to an ending-year of 806. At its simplest, the crash-on-report could happen when the genned world data objects are copied whole (to instantly double the memory needed) in order to operate upon the copy to pare it down to the report info (for which the nul bitmap has been opened for writing as.a standard precaution to rule out read-only file system or other such failures, but never gets to the point of being written to).
However, that would be simplistic. Most likely a report-sized (including map-sized) chunk of memory is to be reserved, ratjer than an identical copy. Also more years generate more hiatorical events. Leastways, this aspect of the mystery remains untested by me. Ditto much testing of otherly-seeded versions of the same custom LARGE ISLAND, non-customised (similarly/otherly-seeded) LARGE ISLANDs and (apart from my Region1 save, a "CREATE WORLD NOW = 433333" creation that did not cause any such ripples and is currently be Adventured around, betwixt other demands) anything not a LARGE ISLAND in world size.
I did rerun to Year 403 with a particularly inefficient Perl script (width-first and greedy searching of a dataset phase space, a quick'n'dirty hack towards looking for a solution (unrelated to DF) that demands more memory than it deserves and will spin up the CPU fan on its own) to see if a concurrently resource-greedy process would push DF backmover the edge again, but it did not. A tribute to whatever form of virtualised resource compartmentalising is practiced by this system well into its second decade of utility, I'm sure. And why I still stick with it for these little things
Anyway, apart from not considering a buf, a brief foray onto Mantis hasn't revealed (relevent!) bug reports such that have succumbed to my inept and uncomprehensive attempts at discovery. As I don't consider it 'fixable' nor relevent to pretty much everyone else out there (who do not reserve a particlarly old workhorse/mule of a machine for DF pleasures, as other devices take up other (more) necessary tasks of the day) I'm not inclined to further chase/create this particular line of enquiry.
Yes I could post the WORLDGEN template for others to try under their own circumstances, but with the logical separation of machine I'd have to revist it, copy the necessary onto USB and then post it up..? And I haven't yet really looked (in either play-mode) at the features on the worldgen-following map that caused me to spend so much of my DF-playing machine's time on repeated worldgennings. It's entirely possible that there isn't even that much of interest to the player (over and above any starting world sourced from any other combination of seeds and other worldgen params). That is something I hope to find out, in various extended idle moments over the next week or two.
And so, apart from the below feetnete, that's all I have to say. If you're still reading then go get yourself a cookie (or a strangely green and definitely unsweetened smoothie, according to your current dietry pursuits) as reward. And then, probably, forget all about these mad/maddening ramblings and resume living the rest of your life.
¹ I might need the whole machine restarting each time, but not entitely sure if that's sufficient and/or necessary to make each iteration an equally fair test, depends upon memory handling/reverting practices with the OS - and I haven't previously had very much reason to establish what behaviours it follows.
² Initial thoughts were that tye OS-level memory resize process, during which I am warned that some things asked by the program may not have happened, was the (later) cause of the crash as the twrget of an unfortunately nul-pointer is given an attempted peek or poke. Though, as it appears that I avoided the resizing message (so far as I can tell), I've now put that idea low on the list of possibilities.
Author
Topic: Export goes over the edge. (Read 1449 times)