Print

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

[MrWiggles]

I was doing something really dorky, and doing a count of the number of bugs fixed, and recording what kind of bugs they were. However, when I was over half way done with the count, I lost it. -_-

So, this is the information I most readily recall with accuracy.

318 have been fixed.

18.4 bugs were quashed pre release on average.

11% of these bugs were typos or raw changes.

4% of these bugs had Adventure Mode tag. Though, the other bugs also probably addressed bugs in Adventure mode as well.

50.3% of these bugs had Dwarf Mode tag. Though, the other bugs probalby mostly deal with fort mode directly.

Most of the repaired bugs were fixed on their 3rd month.

Most crashes, and typos were fixed on the month they were reported. Chinchilla being an exception. Took 3 months. Bugs fix in the month they were report was the second highest count for the age of repaired bugs.

Bugs that took 6-7 months to fix, were a minority.


About a third of the bugs fixed were of Normal- Minor/Tweak/Text variety. (95 Count)

With Low/none - Minor/Tweak/Text being the second highest. (Mid forties count.)

---
Information that I was drawing from, while I was doing my count, is that quick fixes and crashes were top priorities, and were done in the same month as reported.

Most bugs were concerning Fort Mode. This makes senses, as its the most popular mode to player. However, adventure bugs were starting to fix at the start of the first major adventure release.

The bulk of the prioritizing done by the community is Normal. Which, I take to mean, get these in yer own time. Where as High and Urgent, meant more of Sooner then later/ASAP.

A conclusion that I was drawing as I was compiling this information, is that anallyst OP does't have a lot of merit, and contains falsehoods. The majorty of bug fixes were addressing issues that crop up in Fort mode, or solely affect Fort mode, with very little love paid toward Adventure mode, within the context of Bug Fixing.

Although a point in anallyst favor, is indeed Toady does care about typos, making 11% of the total bug fixes, and they were quickly repaired. However, the typo fixes, from what I was seeing was not being done over other, more game impacting fixes.

Crashes however were equally favored in a fervor to quash, but since reported crash bugs were not being reported as often as typos, it does seem to hold a numeric favoritism. When looking at it with time reported, and time last updated (Which I know isn't 100 accurate when a bug was repaired, but fairly accurate though.) perspective,  they are high on his list, while indifferent if it was Normal, Low or High priority.

Other conclusions I was drawing about Toady bug quashing, is that the bulk of bugs being reported are Normal, which is dubbed by the community. So, their in, even if not with design, Toady, is heeding community direction where to address bug quashing efforts.

Bugs marked with High and Urgent, seem more common to be 4-5 month range of being reported and being last updated. This was suggesting to me, that these bugs, were more difficult to quash. Though, I admit, this may be apathy toward them, considering his response time to quick fixes and crashes, I don't believe so.

Given the 18.4 bugs being quashed on average with each release, Toady does seem to have some sort of dedication to getting them out of the way. In fact, from the Change Logs, it quite clear, that Toady favors doing a heavier bug fix, then a light bug in a cycle. With the light bug fixes have a mean of 4 bugs fixed.

So yes, TL;DR

anallyst OP is mostly meritless. Through the use of the bug tracker, Toady is already heeding the community direction of bug fixes through its system of priority. Most High/Urgent bugs were being addressed in the 4-5 month range of being reported, which I take to mean that they're hard. Toady favors quashing crash bugs and typos.

And the suggestion of voting on bug priority I see as redundant from the bug tracker system.

----
EDIT: Cat jumped on the keyboard, totally messed up this post, and took me a bit to retype it.

[MonkeyHead]

This is clearly the bug of the week:



another one in the series next week!

[Rowanas]

That is quite a bug. What is it though?

[Lord Shonus]

76 replies before derail. I suspect that's a record for troll-threads.

[zwei]

I've found no consistent connection between splatter and fps. In fact it's made it worse nearly as much as it's made it better.

I have found a clear link between Population count and FPS:


As I accumulate more data points, I believe the curve will settle into a smoother shape. I'm especially interested to see what happens when population goes down. Will the fps go up?

No, it will not. Mostly because older fort with reduced population will have more items and more pathable places. I had fort reduced to three dwarves that had fps of 50 while embark with 7 was at 250fps cap.

I'll go and make item-fps measurement.

[MrWiggles]

I've found no consistent connection between splatter and fps. In fact it's made it worse nearly as much as it's made it better.

I have found a clear link between Population count and FPS:


As I accumulate more data points, I believe the curve will settle into a smoother shape. I'm especially interested to see what happens when population goes down. Will the fps go up?

No, it will not. Mostly because older fort with reduced population will have more items and more pathable places. I had fort reduced to three dwarves that had fps of 50 while embark with 7 was at 250fps cap.

I'll go and make item-fps measurement.

Yes, most folks forget that items also do impact FPS, and its not just entities pathing which solely decides on FPS. This is why I asked if one could be done. I'm sure that revealed tiles also have an impact on FPS as well, but I don't know one would go about gaining the proper information.

Though, if those three sources of information could be obtained, then a line graph or histogram should show impact of FPS.
---
But anyway, this is also another neat highlight on our limited understanding of DFs source.

What really needs to be done is to use a program profiler. Which, some months ago, Toady has stated that he was soon going to use one.

---
Also, back on track to the whole, Toady fixing bugs things.

I am curious how the OP is determining which bugs toady is currently working on and which he is not. Maybe his pet peeve, and falsely presumed FPS saver, Splatter Bug, is already being worked on, and us ignorant on the the hardcode of DF, just dont know how hard of an issue it is to track, what it means to quash it.

So, anallyst how are you tracking which bugs Toady is currently tackling? From what I can gather, Toady doesn't really say which bug(s) he is currently working on. There have been a few times though. He announced he was working on the rain melting fats bug, before it was released. However that isn't a rule.

Toady and company, does keep up somewhat and regularly informed on what his current activity with DF development. As someone already pointed out, they are planning on doing some major bug quashing after they make some hedgeway with the Caravan arc.

(Also, anallyst, the Caravan Arc is going to impact Fort Mode and Adventure mode, incase you're still operating under the premise that hes ignoring Fort Mode.)

[MonkeyHead]

Lantern Bug.

+1 Entomology.

All troll threads need a poitless image derailment.

[Rowanas]

Who posted the giant image of kittens earlier? Doesn't that count?

[Aklyon]

Is there any other forum on the internet that seems to be able to derail any thread into something else?

[Rowanas]

ALL OF THEM

[anallyst]

Pop   fps before   fps after
51       50             60
80       28             28   (that was the bloodiest fort)
58      73              62

try again with a huge fort (min 300 creatures pets + dwarves)  where fps have dropped below 10 (if you butcher 3 cats or war dogs which "wear" some blood, performance will likely go up 1 FPS. in my experiment it was like washing 2-4 dwarves from blood and cleaning that away with dfcleanmap (run in a loop with "dfcleanmap -q") improved FPS by 1)
or wait inside the fortress for some merchants getting killed outside ( at least 100 dead outside), then send 'em all outside gathering refuse (o-r-o)
you will see a HUGE performance drop (mine went from 25 fps down to 10)
my last fort was on 100 FPS with 28 dwarves, after i equipped 1 (!) hunter with a crossbow, and after he killed around 30 animals which were hauled to the butchery, performance dropped to 60.

[TheyTarget]

First fort had upwards of 150 pets, Fps, was increased, but not as amazingly as you claimed.
Third fort, which, in your quote is second, had considerably more dead then the 100 you suggested, was from a very long succession game.
Four and last fort, was the second fort, one year later. In one year, and 8 more dwarfs, it went from increasing 10 fps, with a wash, to actually losing 10 fps with a wash. Which contradicts. Leading me to believe that splatter, has little to no effect, and there are some other factors, resulting in fps, lose/gain. Which may go hand in hand with splatter, but doesn't seem to be the actual splatter. This was in 0.31.17 again, background processes, seemed to be the same though each fort. I honestly, believe there is some connection to splatter, and FPS, but it needs to be repeatable, for it to be concrete. I can repeat the tests, in forts, with more and less dwarfs, but if my results stay the same, I wont post it.

[Footkerchief]

I have nothing against the community expressing what bugs it most wants fixed.  However, this thread's approach is not going to work, for two reasons:

• The adversarial nature of your plan.  Your premise is that Toady doesn't care about what people want, and you have to force him to care by cutting off donations?  Not only is that incorrect and unworkable, it's pretty depressing that you want to take this rare level of developer-community interaction and make it adversarial.
• Logistical issues.  The forum is not a useful environment for assessing popular support for bug fixes.  Even if you include polls in these weekly threads, good luck including all the conceivably popular bugs, and have fun keeping up with the constant influx of new reports.

The best place to assess support is on the bug tracker.  We already have some rough metrics of the most popular issues, such as "Most Active," although that section is only visible to managers/admins.  Additionally, I and the other managers make our own (very rough) assessments of the most popular, severe, and devious bugs, and sticky them.  The spatter issue is already stickied.  We could also install a Mantis plugin that allows users to vote directly.

[anallyst]

We could also install a Mantis plugin that allows users to vote directly.

that would be great. it would be the right place for voting, since the people that use the bugtracker naturally seem to care more about bugs and technical backgrounds.
what is yet to see is if it would have any influance about what bugs are fixed by the game author, though.

i will close this topic now, as further discussion seems unnecessary.