Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[se5a]

Don't get me wrong, the criticism was/is, imho constructive.
and, I agree. parallelism is the future.

[BoredVirulence]

There are a number of calculations in dwarf fortress that would be very beneficial to offload onto separate cores. Personally, I like to imagine a world where calculations that affect every tile in a predictable time frame, such as temperature calculations, would be offloaded to the GPU. Even crap GPU's, like mine, can handle these kind of calculations much faster than a single core of the CPU of a high end computer. Unfortunately (my expertise isn't with parallelism, although I know some people that do interesting research with GPU's), transferring memory between the CPU and GPU constantly creates a bottleneck. Although I've seen impressive use of caching data so that only changes are sent. Although, and once again this isn't my area of expertise, I've been told that GPU's built on the motherboard don't have the same bottleneck issues since they also use main memory. Of course, I stand waiting to be corrected.

I can see it now. What would take the CPU several hundred iterations, could be done in a single iteration on the GPU plus the time to transfer data for a handful of tiles.

Of course its easy to say that a certain way of doing things is better. I think we all agree parallelism is the future. Its another thing to tell someone to rewrite a significant portion of the code to properly handle it. Although Toady doesn't have a choice, he will eventually have to do it; its a question of know or in a few years.

[wierd]

Any time large amounts of data is routinely shuttled over a bus, it causes contention.

For an analogy:

Imagine a city public transit system. It isn't a very large city, but it is a poor city. Nobody owns a car, so if it helps, imagine 3rd world setting.  This one, lonesome bus is constantly transporting people around the city.

A memory heavy application is a bit like a family of 20 people, crammed into the bus station. It takes longer for them all to get on board, and get seated, and then when they arrive, it takes longer for them to collect their things and leave the bus.

This bus is the memory bus.

A multi-core machine has many bus stations, and only 1 bus. The problem with DF, is that it is a family of 50, and dividing that 50 person group up over 1 or even 50 bus stations still ends up completely filling the bus's seats, forcing other parties waiting at the station to wait even longer. By plugging up the whole bus, they bring the rest of the city's transport to a standstill.

Adding a GPU to the mix is like adding a fixed trolley line inside a gated community inside that city. To get to and from the gated community, you have to use the bus. To get around inside the gated community, you use the trolley. The trolley can have several different routes and cars running on the lines, depending on how it is laid out. By sending part of the family of 50 to the vgated community, and communicating by letters, you free up seats on the bus, and shorte the queue in the bus station. There are limits on how many people you can exchange between the bus ad the trolley line at any given time however; the more self-sufficient the gated community is, and the less it needs to exchange people with the city bus, the more efficiency is gained. The gated community has a shopping mall, and some some other useful/convenient features that let people do more with less travel, so they only use the city bus to get there and then go home.

NUMA is more like adding additional bus lines, where 1 bus travels only on the east side, 1 travels on the west side, one travels on the north side, and another on the south end.

These buses don't cross paths, but do have a central transit hub, which is also where the gated community's trolly line's station is.

To get from west side to north side, a rider rides the bus to the hub, disembarks, boards the north side bus, and then does their thing.  This added step makes it inefficient for somebody in westside to go shopping in north side. As such, it makes much more sense to have local shops and businesses in west side for the west side resident to make use of, and only use the transit hub for special purchases. Even in this arrangement, the shops on the 4 'hoods are more open air, while the shops in the gated community are more mall/supermarket. There is still an advantage to send people with lots of luxury goods shopping needs to the gated community, because they can't be adequately serviced locally, and trying to get those goods from all over the city intails lots of waiting at bus stations.



Toady is basically saying "adding more bus stations won't improve the rate of transport, because there is only one bus, and it is a jesus-christ bus. It's not worth the expense. We need a bigger bus."

I am basically saying "that is currently true; however, the city is going to buy more busses, so planning your neighborhood to have more than one bus station hookup is prudent, even if it does nothing special right now. Doing it later after you have tent cities and shantytowns all over will make it much harder to put your bus stations in efficiently. You are going to have to rip some out and start over from scratch on civic planning if you wait."


To continue that analogy-- right now, the city is laid out with the premise that there is only 1 bus, and 1 bus station. All the shops and businesses in town are laid out by local resources and functions, such that all the city buildings are right next to each other, the fish restaraunt is next to the fishery, so the fish is very fresh, etc. If you want bread, you ride the bus to the baked goods street, which is nearby to the flour mills. All that sort of thing. The bus travels all over the city, and by minimizing the distances between related industries, you improve efficiency.

That does not work so well once you add seperate bus lines; now to get the breading for the fish at the fish restaurant, the cook has to board the bus, ride to the transit hub, wait around, ride the new bus to bakery street, get the breading, ride back to the transit hub, wait some more, ride the first bus again back to the restauraunt. By that time, the fish has been laying around too long and is not fit to cook.

The solution is to have fisheries, bakeries, and restauraunts in each quarter of the city, so that local transport is favored over external transport. 

This means redesigning the city, and the way it is laid out.

Toady sayd "that's a lot of work! I prefer to add new shops in the different shopping districts, because that's more fun, and I don't see an advantage to adding more bus stations".

As stated above, I disagree with that view, because the longer he waits before modernizing the city, the harder it will be to modernize it later, when the new bus lines get mandated by the fed.

[Miuramir]

As stated above, I disagree with that view, because the longer he waits before modernizing the city, the harder it will be to modernize it later, when the new bus lines get mandated by the fed.

I agree with some of your general ideas, but after thinking about this off and on for a while, I'm not convinced as I used to be that now is the best time. 

On the one hand, compiler tools for "automatically" handling parallelization have gotten *dramatically* better in the last decade or two; it's far less hassle to use either of several sorts in your code than ever before.  The thing is, the tools are highly likely to get better yet; Toady is far from the only owner of a chunk of legacy code that needs help for a multi-processor world.  I would not be terribly surprised if getting basic parallelization running is as simple as picking a compiler optimization in less than a decade more; why do all sorts of manual work now when the far better compilers of the 2020s will have tens of thousands of expert person-hours into developing tuned routines to do that for you? 

Another issue is that developing for the specific quirks of today's architecture is likely a dead end.  We have at best a hazy idea of how the computers will be built when DF 1.0 nears; it's moderately likely that it will be quite different from today.  One moderately visible possibility, for instance, is that they might built far more like today's GPUs; a desktop might well have thousands of quite stupid processor "cores", for instance.  There's at least one popular computer already (Raspberry Pi) where the "CPU" is actually a near-afterthought capability dropped into a corner of a powerful video-processing GPU, pretty much because the chip designers could say "why not?" at the time. 

Design for such systems would be quite significantly different than design for modern architectures, and optimizing for single-digit numbers of modern x86_64 compatible cores may be seen as as much a dead end by then, as having hypothetically spent months of Toady time a few years back on customizing for Itanium or SPARC would seem today. 

If you're looking at a medium development cycle, something designed to come out in, say, less than 3 years, your suggestions are pretty solid.  I'm just not convinced they hold if you're looking at a project expected to not come out for well over a decade.  To extend your analogy, why spend a lot of effort now on going from one bus to four, when by the time the program is ready, people get around in thousands of tiny little autonomously-routed electric capsule cars, and the idea of "bus routes" is a fading memory of the elderly? 

[wierd]

About the only tech that could serve the analogy as "personal capsule cars" would be quantum mechanically based computing; by the physics involved, it can't work for general purpose computing-- those EVs would be more like mopeds. You can't fit 50 people on a moped.


I fully agree that compilers are quite amazing these days, and can produce machine code much more quickly and robustly than people pushing hand-assembled machine code themselves. However, there is only so much that a compiler can do with a process that is not designed for parallelism, and its attempts to parallelize the code could well end up with angina inducing race conditions, infinite recursive looping code, and other "not good" output, depending on how that serialized task code was written.

(Race condition being the most obvious as being the most likely to happen.)

 In other circumstances, straight up errors can happen when the compiler incorrectly presumes that the horse can come before the cart, so to speak-- causing very much unintended behavior. Compiler optimization is a powerful tool, but it is a mistake to think that it can totally replace the programmer in regard to writing parallelizing code.

[Thundercraft]

Personally, given the player base's success in making the game more playable, I'd rather Toady stick to working on features, anyway.

When I stumbled across this thread I had to read because the "Playability Patch" in the title suggested this would be about begging Toady to concentrate more on bug fixing - i.e., making it more playable.

Features are nice and all. However, I'm certainly not alone with the fervent desire that Toady devote more to fixing outstanding bugs (some of which are categorized as "major" and remain unresolved years after they've been reported) rather than introduce more and more complexity to software that is already - by far - the most sophisticated and complex simulation game ever attempted.

Continuing to add more features and complexity is just going to introduce more and more bugs. (Case in point: Bug 0005312: Undead reanimate too quickly (and forever)) The longer Toady waits to fix this growing list of bugs, the more code he will have to wade through in order to sleuth out the root cause and squash them. Meanwhile, he has probably forgotten many of the temporary workarounds and the reasoning behind certain code decisions, which compounds these problems.

Example, how Toady "temporarily" fixed dwarves leaving worn-out clothes laying around a fort:

Quote from: assimilateur on February 17, 2011, 08:15:23 am

Quote from: Thundercraft on February 17, 2011, 05:08:21 am
So, many versions ago Toady intentionally turned off the ability of dwarves to change clothes as a temporary workaround to the problem of dwarves leaving their old clothes all over a fortress as clutter.

That's like throwing the baby out with the bathwater, if you ask me.

Granted, the player base has done an amazing job of creating graphics upgrades, useful utilities, interesting mods, and workarounds to a number of bugs. With stuff like the UI Improvement Plugins and Mouse Fortress, even the user interface isn't much of a problem. However, there are certain bugs that the player base can't touch, no matter how much of a genius they are or how much time is devoted to fixing them.

Just saying...

Instead of a Kickstarter, fans should remind Toady of the success of Rainseeker's Animal Sponsorship Drive and suggest he hold a similar drive for bug fixing! If Toady were to skip a development cycle to concentrate entirely on bug fixes, I'm sure he'd discover his monthly donations going up.

[Miuramir]

About the only tech that could serve the analogy as "personal capsule cars" would be quantum mechanically based computing; by the physics involved, it can't work for general purpose computing-- those EVs would be more like mopeds. You can't fit 50 people on a moped.

Quantum computing would be "every apartment and shop has a teleport booth aka Niven", perhaps   I was trying for an analogy for what "CUDA 8.0" might be like; and the 50 person thing is kind of my point; it's at least conceivable that in 1-2 decades, very little of the compute power of a system may lie in it's general-purpose core(s).  This is already true in some of today's workstations; one with a comparatively inexpensive Quadro K4000, for instance, has 768 CUDA-usable cores, compared to perhaps 8 accessible by traditional methods.  If those trends continue, concepts like "put pathing on another core" will seem meaningless; we'd be looking at a rewrite in a different direction much closer to "each active entity (dwarf, animal, trader, invader, etc.) on the map gets a very simple core to do whatever it is trying to do".  Or, perhaps, figuring out how to do fluid-flow calculations with the successor to Map - Reduce. 

I fully agree that compilers are quite amazing these days, and can produce machine code much more quickly and robustly than people pushing hand-assembled machine code themselves. However, there is only so much that a compiler can do with a process that is not designed for parallelism, and its attempts to parallelize the code could well end up with angina inducing race conditions, infinite recursive looping code, and other "not good" output, depending on how that serialized task code was written. ...

The difference here is perhaps that I personally remember people back into the 1970s saying similar things over the years, about high-level compilers in general, vector processing, loop unrolling, etc.  There's no fundamental reason a compiler can't do all the checking for parallelism; it has all of your code, and can probably keep track of the cross-connections better than most people.  In highly structured and very handholding settings like Matlab, it's already as simple as changing your "for" statements to "parfor" statements in many cases.  (Seriously, I had one graduate student whose heavily-looped code went from taking over 6 hours to run to less than 1 hour, simply by using parfor.  5 minute code change, half an order of magnitude improvement.)  And IMO there's enormous market pressure for compilers to get better at this sort of thing.  There's no question that automatic parallelization is hard; but I don't think it's hard enough that a couple of decades of Intel throwing buildings full of bright people at the problem isn't going to show significant improvements. 

Unless we get a "Black Swan" breakthrough, general-purpose single-core continuous operation speeds for air-cooled home PCs are not likely to get dramatic improvements; perhaps not more than 2x, and quite probably less than 5x.  I think the odds of a significant paradigm shift are reasonable, but pretty much by definition we're not going to know what the other side looks like... except there will be plenty of large organizations with vested financial interest in finding ways to easily convert huge masses of old code to the "new way". 

Another point is Amdahl's law.  Colloquially, the low-hanging fruit of parallelism is where you get most of your gains; there's diminishing returns on the harder stuff.  I suspect that compilers able to do the easy stuff will come first, and frankly for many programs that will be enough to make a significant difference.   

[Putnam]

Just saying...

Instead of a Kickstarter, fans should remind Toady of the success of Rainseeker's Animal Sponsorship Drive and suggest he hold a similar drive for bug fixing! If Toady were to skip a development cycle to concentrate entirely on bug fixes, I'm sure he'd discover his monthly donations going up.

Semi-related:

Threetoe:   Ok, Aaron asks, 'Considering Dwarf Fortress' long development, will animals be removed the game as their real life counterparts go extinct or will animals such as polar bears, gorillas and pandas be kept in Dwarf Fortress even after their extinction in reality? Any plans to include the moa, dodos, or pygmy mammoths that were still kicking around past 1400AD?' Yeah, that's kind of a messed-up question. We were thinking about having the animal sponsorship drive. That didn't really work out that well, well it did monetarily, but it was kind of hard to implement. At one point considering having an extinct animal sponsorship drive.
Toady:   Yeah, it probably wouldn't be a sponsorship drive, at least not the same way. We'd be happy to include extinct animals, and I think it would be just cold, if the polar goes extinct, to remove it from the game, that'd be cold. I'd like to keep the polar bear in there as kind of an homage to the existence of the polar bear, but it is incredibly depressing to think about that. But I'm not removing polar bears from the game.

[BoredVirulence]

Any time large amounts of data is routinely shuttled over a bus, it causes contention.

Spoiler (click to show/hide)

For an analogy:

Imagine a city public transit system. It isn't a very large city, but it is a poor city. Nobody owns a car, so if it helps, imagine 3rd world setting.  This one, lonesome bus is constantly transporting people around the city.

A memory heavy application is a bit like a family of 20 people, crammed into the bus station. It takes longer for them all to get on board, and get seated, and then when they arrive, it takes longer for them to collect their things and leave the bus.

This bus is the memory bus.

A multi-core machine has many bus stations, and only 1 bus. The problem with DF, is that it is a family of 50, and dividing that 50 person group up over 1 or even 50 bus stations still ends up completely filling the bus's seats, forcing other parties waiting at the station to wait even longer. By plugging up the whole bus, they bring the rest of the city's transport to a standstill.

Adding a GPU to the mix is like adding a fixed trolley line inside a gated community inside that city. To get to and from the gated community, you have to use the bus. To get around inside the gated community, you use the trolley. The trolley can have several different routes and cars running on the lines, depending on how it is laid out. By sending part of the family of 50 to the vgated community, and communicating by letters, you free up seats on the bus, and shorte the queue in the bus station. There are limits on how many people you can exchange between the bus ad the trolley line at any given time however; the more self-sufficient the gated community is, and the less it needs to exchange people with the city bus, the more efficiency is gained. The gated community has a shopping mall, and some some other useful/convenient features that let people do more with less travel, so they only use the city bus to get there and then go home.

NUMA is more like adding additional bus lines, where 1 bus travels only on the east side, 1 travels on the west side, one travels on the north side, and another on the south end.

These buses don't cross paths, but do have a central transit hub, which is also where the gated community's trolly line's station is.

To get from west side to north side, a rider rides the bus to the hub, disembarks, boards the north side bus, and then does their thing.  This added step makes it inefficient for somebody in westside to go shopping in north side. As such, it makes much more sense to have local shops and businesses in west side for the west side resident to make use of, and only use the transit hub for special purchases. Even in this arrangement, the shops on the 4 'hoods are more open air, while the shops in the gated community are more mall/supermarket. There is still an advantage to send people with lots of luxury goods shopping needs to the gated community, because they can't be adequately serviced locally, and trying to get those goods from all over the city intails lots of waiting at bus stations.



Toady is basically saying "adding more bus stations won't improve the rate of transport, because there is only one bus, and it is a jesus-christ bus. It's not worth the expense. We need a bigger bus."

I am basically saying "that is currently true; however, the city is going to buy more busses, so planning your neighborhood to have more than one bus station hookup is prudent, even if it does nothing special right now. Doing it later after you have tent cities and shantytowns all over will make it much harder to put your bus stations in efficiently. You are going to have to rip some out and start over from scratch on civic planning if you wait."


To continue that analogy-- right now, the city is laid out with the premise that there is only 1 bus, and 1 bus station. All the shops and businesses in town are laid out by local resources and functions, such that all the city buildings are right next to each other, the fish restaraunt is next to the fishery, so the fish is very fresh, etc. If you want bread, you ride the bus to the baked goods street, which is nearby to the flour mills. All that sort of thing. The bus travels all over the city, and by minimizing the distances between related industries, you improve efficiency.

That does not work so well once you add seperate bus lines; now to get the breading for the fish at the fish restaurant, the cook has to board the bus, ride to the transit hub, wait around, ride the new bus to bakery street, get the breading, ride back to the transit hub, wait some more, ride the first bus again back to the restauraunt. By that time, the fish has been laying around too long and is not fit to cook.

The solution is to have fisheries, bakeries, and restauraunts in each quarter of the city, so that local transport is favored over external transport. 

This means redesigning the city, and the way it is laid out.

Toady sayd "that's a lot of work! I prefer to add new shops in the different shopping districts, because that's more fun, and I don't see an advantage to adding more bus stations".

As stated above, I disagree with that view, because the longer he waits before modernizing the city, the harder it will be to modernize it later, when the new bus lines get mandated by the fed.

I'm familiar with the problems with shuffling data over the bus. With efficient use of caching however, there would be significantly less data to send over the bus. For temperature data for instance, it would send all of it once, then it need only send what has changed between ticks. I've seen some research into problems like this, and I've seen how memory transfer over the bus takes up by far the majority of the time. I've also seen projects that used caching like I day-dreamed about for stupidly awesome results. Pathfinding however might not be a problem that could easily be pushed onto the GPU though, because potentially too much data would need to be updated for the caching to be efficient anymore. Certain problems would be extremely beneficial for, others less so. But this is won't happen, because new features is more fun than worrying about optimization. I understand his position, but think this needs to change. Of course, this will be like the UI, it will be fixed towards the end of development.

[MrWiggles]

Just saying...

Instead of a Kickstarter, fans should remind Toady of the success of Rainseeker's Animal Sponsorship Drive and suggest he hold a similar drive for bug fixing! If Toady were to skip a development cycle to concentrate entirely on bug fixes, I'm sure he'd discover his monthly donations going up.

A success finically? Sure. Took almost a year to implement them.

And unlike asking for animals to put into, we, the playerbase wouldnt know what we're asking for. You brought up Zombie resurrection issue. How much of that is a bug verse a system lacking another part of a system to be dealt with properly? When ToadyOne has spoken about it, it has to deal with there being no Pulping. (And Pulping should be existing in the next release.)

We don't know how much are just bugs, or just shallower place holder systems interacting with bugs or shallower place holder systems.

Like you brought up the Cloths Wearing out bug. Is that just relating to bugs, or does that relate to Stacking Item problem and/or the same set of issues that the game had with the Armorer Dorf or issues with Picks being weapons and Utilitarian objects. That might not be a bug at all, but system that needs to be in some parts rewritten.

Like, lets look at one of the things that the community saw 'low hanging' fruit. Cheese Makers. Just make Cows be milkable! Cant that big of a deal we have one Animal like thing thats milkable, and delicious dwarf cheese as the proof.

But simply making Cows milkable, wasn't what happen. An entire new sub set of stuff was added, a newer tool set to cover a lot of, what are basically the same thing. Open & more flexible.

So maybe its not worthwhile to fix the clothes wearing out bug, until dorfs can actually get new clothes eaier or better at storing their stuff. Maybe its system thats functional, but just buggy. Maybe it needs to be tossed and rewritten.

The only thing that a drive for bugs  does, is just clue in what the Community feel are priority bugs, and well, that already known.

[misko27]

As Wiggles says and as I have said, there is a lot about this game that is Placeholder. Hell, most things in this game are placeholders. It is hard to sya where placeholders end and bugs begin, because the ultimate end to the game is really, really far off, and most systems are not nearly up to snuff, no, not even that, perhaps no system is ready at all, surely everyone of them could be expanded.


Everything isn't a bug, it's incomplete. Animals not being able to fly when tamed, it's a purposeful limitation because the code is not in place. No economy was in fact because it was broken, and that the Toady One wasn't working on that yet.

[Thundercraft]

Semi-related:

Threetoe:
...[snip]...We were thinking about having the animal sponsorship drive. That didn't really work out that well, well it did monetarily, but it was kind of hard to implement.

A success finically? Sure. Took almost a year to implement them.

So, it was a success. And it was implemented. The fact that it was considerably more difficult to actually do than expected doesn't change that. Though, it certainly does sound like this would discourage them from future sponsorship drives.

And unlike asking for animals to put into, we, the playerbase wouldnt know what we're asking for.

In terms of bug reports and requests to fix bugs, I'm pretty sure the playerbase has some idea. The playerbase is what reports bugs. Taken as a whole, the playerbase is probably more familiar with bugs in DF than Toady himself (especially considering how little Toady seems to play Fort mode these days).

On the other hand, I do get your point: We the players have very limited knowledge and understanding of the code behind the game, let alone able to take things into account like features yet to be implemented, etc, etc. It is his program. So it's probably a lot more complicated than most of us imagine.

You brought up Zombie resurrection issue. How much of that is a bug verse a system lacking another part of a system to be dealt with properly? When ToadyOne has spoken about it, it has to deal with there being no Pulping. (And Pulping should be existing in the next release.)

That goes a long way to explaining why it is the way it is. Though, this is the first I've heard of it and it would have been nice if this was talked about more - i.e., given more exposure. However, in the meanwhile, this makes playing in an evil biome almost impossible for many players.

Perhaps, instead of implementing the Zombie resurrection, it should have been shelved for the next release when it could have been released alongside Pulping?

At the least, he could have added a [Reanimate_Dead:YES/NO] or similar option to the INIT file.

I'm not aware of many games that implement new features with the knowledge that they are missing important functionality to the point of being game-breaking.

We don't know how much are just bugs, or just shallower place holder systems interacting with bugs or shallower place holder systems.

Like you brought up the Cloths Wearing out bug. Is that just relating to bugs, or does that relate to Stacking Item problem and/or the same set of issues that the game had with the Armorer Dorf or issues with Picks being weapons and Utilitarian objects. That might not be a bug at all, but system that needs to be in some parts rewritten.

Granted. However, IMO it would help a great deal if such things were explained a bit better to players. If nothing else, we'd tend to be a bit more understanding.

Actually, I brought up the inability of dwarves to change clothes and how this was reported as a bug. The fact that Toady did this intentionally as a workaround to a minor bug was not widely known. It would have been nice if this was mentioned in game release notes or something.

As Wiggles says and as I have said, there is a lot about this game that is Placeholder. Hell, most things in this game are placeholders...
[snip]
Everything isn't a bug, it's incomplete. Animals not being able to fly when tamed, it's a purposeful limitation because the code is not in place...

Maybe so. But you can't tell me that actual bugs (as opposed to "incomplete features") do not exist in DF. Even after a major release and several updates, bugs are still quite plentiful. And you can't tell me that bug fixing (or temp workarounds) is not given a very low priority (as compared with other games and software).

The only thing that a drive for bugs  does, is just clue in what the Community feel are priority bugs, and well, that already known.

For feelings on bug priority we have The worst bug poll and threads like it.

But are these things that Toady actually reads or takes into consideration when deciding what to work on next - which bugs drive players up the wall the most?

Toady seems to suggest he will work on whatever he feels like working on and the impression given is that player (or even donator) opinions matter very little. And in the Dwarf Fortress Talks I've listened to he makes it pretty clear that he intentionally concentrates on new features because it helps him stay motivated to work on DF.

Another words, Toady would rather work on features than bug fixing. And who can blame him? Bug fixing can be boring stuff. How could it possibly compare with, say, creating new and interesting things for adventurers to do or devising evil ways for undead and necromancers to haunt the nightmares of players?

The Animal Sponsorship Drive, however, seemed to be a rare exception to the rule that Toady makes all the decisions. With the drive, players - in the form of donators - could actually have a say-so.

We don't know if there will ever be another official sponsorship drive. But it is out of our hands and it was merely a suggestion. However, I have to disagree on what a bug sponsorship drive could do.

The animal sponsorship drive was a financial success. And it let donators get the animals they wanted. And participation showed there was a lot of interest.

If nothing else, a lot of interest and participation in a Bug Fix Drive might impress how important bug fixing is to a certain segment of the fan base. And that might encourage Toady to give bugs and issues a slightly higher priority in the future.

BTW: A whole lot of player frustration and bug report issues could be resolved if more "incomplete features" could be -either- disabled by INIT options -or- by allowing modders to do something about them. Many of the most complained about issues are hard-coded such that modders can't touch them.

[misko27]

I certainly will go on record as saying there are bad bugs out there, but it isn't fair to say there is no work done. Many bugs are, again, simply part of larger things that will be a serious project to fix, as I imagine dealing with recombining will be, especially given that Toady is even right now discussing what a hassle that is (although in reference to historical figures and not coins, for example). Dwarves equipping is something that has been struggled with. Steel Whips are due to how the game calculates attacks, which is in fact being worked on this release, although I don't know if we will get a fix; either way, it is dependent on other systems and not simply broken. Re-animation, also on that list, will be fixed this release. Turtles disappearing should be fixed this release. Siegers waiting by their dead leaders will be fixed this release. Unreclaimed shops and too many textile shops may (need confirmation) be fixed this release.


There is a lot going on, and many bugs will disappear, and will be replaced with many new ones. It's how this game rolls.

[MrWiggles]

There are lots of bugs in DF. Most assuredly. Though a part of my point is that the community labels everything as 'not working' as a bug. And then uses that language, that its therefore fixable because there missing closed paren somewhere.

I would wager a lot of 'bugs' disappear with every release, indirectly and there also the bugs that get fixed purposefully with every release. He fixes a lot of bugs, as far as we can tell with the information we have. There just well lot of fidetly ends that just dont quite click right and then it dominos. 

I would also wager a lot that there lots of perfectly fine systems that are doing their best with malform data. The combat system itself seem to be a case of a perfectly fine system doing it best with malform data. Malform, not in not properly formatted, just wrong and mis matched values.

And again, we the playerbase, cannot tell what is what.

You brought up Zombie resurrection issue. How much of that is a bug verse a system lacking another part of a system to be dealt with properly? When ToadyOne has spoken about it, it has to deal with there being no Pulping. (And Pulping should be existing in the next release.)

That goes a long way to explaining why it is the way it is. Though, this is the first I've heard of it and it would have been nice if this was talked about more - i.e., given more exposure. However, in the meanwhile, this makes playing in an evil biome almost impossible for many players.

Perhaps, instead of implementing the Zombie resurrection, it should have been shelved for the next release when it could have been released alongside Pulping?

At the least, he could have added a [Reanimate_Dead:YES/NO] or similar option to the INIT file.

I'm not aware of many games that implement new features with the knowledge that they are missing important functionality to the point of being game-breaking.

You're assuming that putting a switch like that in the Init file is trivial matter. We don't know what that process is, or what it entails. There might not be a very clean definition of 'just zombie'. Maybe turning off zombies, stop ghost? I dont know. You don't know.

And ToadyOne, as we can infer from his Dev Logs often struggles with releasing new Content Areas, without well, Content. And so in far, has sided with releasing new Content Areas with New Content. When we got the new Biomes, and their neat new features (like eye ball grass), we also got Necromancers and zombies. And few other things. ToadyOne made a judgement call on to leave Evil Biome without enough content or leave them in as is, as its not a requirement for players to play in evil biomes.

Part of what taken this release longer is that he felt the game could no longer sustain the absence of Elven or Gobbo or Dorf sites. And their content. 

I keep on saying He. I'm sure that ThreeToe has a fair amount of say so on the game, but like a lot of things with Dwarf Fortress, we're simply just blind.

As for the transparency of these tidbits that I and others know off hand. I think I am more of a fan of the development of dwarf fortress over the game itself. I have played the game a lot, but I think I've placed more time into learning about whats happening with the game now.

It is there. And its still there. Its just in a few different spots. There dwarf talks, and and more importantly the Dev Logs and the Future of the Fortress Q&A. Lots of questions get answer there (now) once a month.

Dumping the FoTF into the change log, would probably be more noise then anything.

[wierd]

Indeed. FotF is a good portion "What's toady thinking about right now, and what loose goals does he have for the future?" where the dev log is "What did toady actually codify into the game today, and why."

There is a very important difference between what one would like to do, and what one actually does, (and the reasons for the differences.)

I really don't see a benefit to combining the two; Toady giving a link in the dev log to the FotF posts when they get given is all the more cross over the two info streams need.

But I have to disagree with some of your above concerning where you draw the line on what is a bug.  A non-closed parenthesis, or missing a semicolon is a simple typographical bug-- and yes, it's easy to squash. However, a logic bug that makes a function improperly terminate is also a bug, as is a bug where a race condition happens, etc. Those aren't content related, they are genuine bugs in implementation. (a good example of the last one is the beekeeper bug. The code expects to carry out the task without any issues, however a race condition occurs because of behavior in other linked code for carrying out the task [always pick nearest usable target, dont check for locking, dont update for availability on fail], and no error detection and correction is implemented, resulting in an infinitely looping call a nontrivial percentage of the time. the bug is easily reproduced. Proposed solutions to the problem are in the bug report on mantis. It just hasn't gotten any love. It is much less trivial to squash than adding a semicolon, since toady will have to write an error detection and correction routine to squash it-- but it is still a genuine bug.)