Print

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

[Sarmatian123]

Sparing happens during training exercises, but is reported like regular combat. Knowing all the sparring activity does not bring anything new to the game. Sparring activity is tedious and repetitious. It does not contribute to any game bug tracing. The dodging bug is well known and described for decades now. It does not need sparring report. There is no point to report sparring. Sparing report also has a negative side to it. It generates around 50mb in gamelog.txt for every 1 season, which I believe is detectable hit on frame rate.

Therefore I suggest in announcements.txt following change:

UCR or UNIT_COMBAT_REPORT: the announcement will be associated to the unit combat/hunting/sparring reports

be split into

UCR or UNIT_COMBAT_REPORT: the announcement will be associated to the unit combat/hunting reports
SPR or UNIT_SPARRING_REPORT: the announcement will be associated to the unit sparring reports

and then by default make SPR _SILENT_ and not reporting. I would also like to suggest splitting report and announcement to 2 different gamelog.txt files.

I play currently around 18 year old fortress. If I never cleaned gamelog.txt, then it translates into 18*4*50mb= 3600mb gamelog.txt. Write operation on 3.6gb txt file I would believe would be taking quite a considerable computing time. I just wonder how many people got disenfranchised with DF, because their fortress become too lagy due DF creating huge txt files in its directory and for no good reason at all, like sparring, which does not contribute a thing to game or even bug tracing.

Sparring report is utterly pointless feature, which generates considerable lag.

[Shonai_Dweller]

What was your fps improvement when you cleared your Gamelog? Is this Science or just a rant?

[Sarmatian123]

I believe it is actually known, confirmed and still not fixed bug:
0001430: Announcements vanish too quickly (next day) https://www.bay12games.com/dwarves/mantisbt/view.php?id=1430

About impact on fps. I am on new quad cpu with 4ghz backed with 16gb ram. DF is still on old sata hd (hd system is fat32 and os is latest long term ubuntu), however I have new sata controller. I am running DF in around 45-35 fps. So impact on my fps is not currently big with 50mb gamelog.txt for each season. Clearing it still rises average fps somewhat, but it is not science any more. Many things do impact fps in overall, so it is hard to say.

This was another story on my old dual cpu with 3ghz backed with 2gb ram same (more or less) fortress run at speeds of around 10fps, which after some miracle work in 0.44 by Toady went up to 17 fps. However, I was clearing gamelog.txt religiously like every month on it. It was adding around 2 fps each time to game speed and the file was around 15mb on each purge. So it was tangible gain on my old computer.

What was your fps improvement when you cleared your Gamelog? Is this Science or just a rant?

For science you could generate 0mb, 10mb, 100mb, 1gb, 10gb and 100gb txt files and put them into DF directory and rename each to test fps to gamelog.txt. Then run DF on each and check the fps for one month. You should test different file systems. You should test ide, sata, usb and those new hds too. If there is no difference in fps on neither hd on neither file system with neither gamelog.txt, then I guess this argument will be put to rest for ever through science. It could still be an issue on some old hardware though.

[FantasticDorf]

Just to point out to the OP, in the english language 'Rapport' means "collective support, or to have a good relationship with the crowd" so please edit your title in the 'Subject:' of the OP post so it's grammatically correct to 'report' for clarity.

Im not too bothered about my dwarves sparring, but a setting to turn off the sparring reports being logged would be welcome also for ease of reading my game log, i can just turn it on again if i encounter any problems that require me to log it.

If it obviously makes a improvement, then go ahead.

[lethosor]

Can't you just remove "UCR" for the relevant sparring announcements in announcements.txt?

Write operation on 3.6gb txt file I would believe would be taking quite a considerable computing time.

I think you're saying that writing to files gets slower as those files gets bigger. However, on modern OSes, this usually isn't the case for appending to files, which is what DF is doing (or what it should be doing, at least - it ought to be opening the file in a way that only permits appending, but I haven't verified that it does that). Appending doesn't require moving any existing file content, or even knowing what it is.

Now, appending to a file frequently can hurt performance, which could be part of the issue here, but that doesn't depend on the size of the file at all.

[Sarmatian123]

Can't you just remove "UCR" for the relevant sparring announcements in announcements.txt?

That's the whole point of this suggestion, right? Currently if you stop reports on sparing, then you stop those on combat too.

Now, appending to a file frequently can hurt performance, which could be part of the issue here, but that doesn't depend on the size of the file at all.

Sparing activity is constantly preformed by 4-5 couples of Dwarves and like combat it is very rapid activity. It is constant and continuous too. I imagine appending to a file is very rapid and somewhat depended, if you use old ide hd or old external usb hd or some latest one mounted on motherboard directly.

[lethosor]

Oh, I didn't realize the announcement types were shared by combat. Oops. I think this suggestion makes sense, although its feasibility depends on how easy it is to determine whether an action is part of normal combat or sparring when it occurs.

Yeah, frequent disk writes can hurt performance (although if they're buffered, which they usually are by default, they might not, but I don't know if gamelog writes are buffered or not). I meant that the file size isn't usually a factor, although extremely large files are also not good.