Print

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

Faster than 40d, no problems

42 (26.1%)

Faster than 40d, problems

72 (44.7%)

No slower than 40d, no problems

14 (8.7%)

No slower than 40d, problems

16 (9.9%)

Slower than 40d, no problems

2 (1.2%)

Slower than 40d, problems

3 (1.9%)

Doesn't work (please explain)

12 (7.5%)

Total Members Voted: 160

[Veroule]

I have been hunting in vain for information on the key repeat rate.  All I can find is KEY_HOLD_MS...  Unless the wait period is the same as the repeat rate, really they ought to be seperate..

[edit] They are integrated, so, setting it low makes it almost unplayable.  The trick doesn't work anyhow, the seperate timing of the two keys can fall in and out of sync.

I have the following suggestion for key repeats: 

• Time them all as one.  Tracking them individually is inaccurate since the cycling just makes beat frequencies against the frame rate.
• Run the key repeat at double-time, divided into two beats.  Have motion keys repeat on the first beat, and entry keys repeat on the second.  That way, arrow+enter is guaranteed to work in any place that needs it since the game cannot register their repeats out of order.

It would be pretty easy to make seperate options for how long before starting the repeat, and how long between repeats.  Currently the first repeat for keys that aren't a cursor movement get a different timing, and then repeat at the regular timing.  Switching that first repeat detection to use a new init option is easy.  I will tack that onto my to do list.

The complaint about setting the key hold too low making the game unplayable is just about as good as jumping in a lake in the middle of winter, and then talking about how cold you are.

I will never write timing them all as one or using a fixed timing beat.  Both of those methods break down when a user wants to hold two or more repeatable keys.  The first method is what is used by just about everything in computers, and you can see how well that handles things by trying any 2 keys in a text entry box.  The second method does the same thing when the keys are in the same class.  Pressing 2 arrow keys didn't work too well in 40d for just that reason.

I doubt I fixed the problem of them getting out of synch for d12.  I would have to change the listing structure to specifically sort them based on next repeat time.  Right now the list is a fifo based on order pressed, and then skips those that are not ready to be repeated.  I will consider what the speed impact would be to do sorting on based on when to repeat instead of the current skip.

Random832, sorry checkboxes aren't going to happen anytime soon either.  I think having more then 15 colors in the color palette will happen sooner than checkboxes.

[kutulu]

3. Implement proper shift/ctrl-selecting and checkboxes instead of continuing to provide support for a bizarre keyboard entry method that works literally nowhere else in the entire world of computing

Hey, this is Dwarf Fortress.  Next you'll be asking for more than 15 colors!  I'm trying to ask for what might be feasibly implemented without completely reinventing the thing :p

true multi-select might be difficult to implement in a keyboard-based UI, but bulk selection is not.  There are a couple of ways this can work, all of which I've implemented with good results:

* If a particular modifier key, usually Shift, is held down, then the arrow keys don't just move the cursor, they simultaneously move the cursor and toggle the newly focused item.

* If a particular modifider key is held down the Enter is pressed, it automatically toggles every item between the current one and the previously toggled one to the new state.

* A particular key combination, like Shift+Enter, toggles "bulk mode" on and off; while bulk mode is on, it is used to set the start and end range for a mass toggle.

In fact, that last one is already implemented in df -- it's how designations work.

[Random832]

3. Implement proper shift/ctrl-selecting and checkboxes instead of continuing to provide support for a bizarre keyboard entry method that works literally nowhere else in the entire world of computing

Hey, this is Dwarf Fortress.  Next you'll be asking for more than 15 colors!  I'm trying to ask for what might be feasibly implemented without completely reinventing the thing :p

true multi-select might be difficult to implement in a keyboard-based UI, but bulk selection is not.

The standard windows listbox actually has true multi-select for keyboard.

Holding down ctrl moves the cursor (well, the rectangle thing) without selecting the item. pressing space (ctrl is still pressed) selects or deselects the item under the cursor. pressing shift-space selects (or deselects all items in between the current one and the last one you did. And of course shift without ctrl will select a contiguous range while deselecting everyone else. And moving around with the arrows and no modifier keys selects a single item and deselects everything else of course.

You could instead use the checklist model - where the "selected" item is not the same as the "checked" item - you do arrows and shift to select a range, and then space checks or unchecks the currently selected range.

[Corona688]

true multi-select might be difficult to implement in a keyboard-based UI, but bulk selection is not.

If I understand the situation correctly the 40Dxx project is not tasked with remaking DF however they want, just efficiency and compatibility improvements, since DF is of course still strictly Toady's baby.  There's no point suggesting changes to the interface.  I'm trying to make suggestions that could be possible without changing the interface code at all.

Besides, we actually have no idea how hard it would be to build that kind of selection into the existing system.  It's one thing to say it's "easy", and quite another to do it.  And I seriously doubt the area designation system could be shoehorned in.

[Corona688]

I'm not about to read through 98 pages of replies so I don't know if this has been posted or not, but I find if I switch back and forth from other programs (like notepad or firefox) and DF a lot, eventually DF becomes unresponsive, and I have to ctrl-alt-del and cancel to get DF to respond again.

Just noticed this and remembered something.  I'm using the linux version and when I alt-tab back and forth from it, something weird happens -- a sort of hidden popunder thing is visible but inactive.  It doesn't hurt anything so I've ignored it but it might be worth looking into what that means for the Windows version.  Sorry to be so vague about what it does, I'll be more specific when I can but I'm away from my machine right now.

[sev]

d10 removed most of the original scaryness, d11 corrected a key repeat bug.

That key repeat fix means I can't do <Enter><Down> repeatedly as fast  as I used to on the carpal-tunnel-inducing trade screen. Although it did prompt me to use xvkbd to fabricate keystrokes for it instead, so I guess that's an improvement of sorts.

The d11 key repeat fix was for a bug introduced with d10.  The parts rewritten for d10 made the key testing faster with less memory, and improved the handling for holding many keys.

If you hold Enter, and then press and hold Down at the right moment it will mark the trade for each item.  This is because the timing at which to repeat each held key is kept seperately.  It is easier to do it if you set the key repeat rate in the init.txt higher.

My experience of keyboard input is that a problem has arisen between d9 and d11 (I missed d10 entirely) for this and related tasks.  In d9, I never noticed df missing keystrokes.  In d11, however, I regularly find that when I do a quick pair of keystrokes, the first one gets lost -- like, I do jm for "job list" -> "manager" and find myself on the military screen, as if I hadn't hit the j at all.  Similarly, the screen where you select items to be moved to the trade depot can filter what's shown if you hit 's', and if I type at-speed, it misses keystrokes in d11, while it did not in d9.  Other places where I find myself rapidly entering text, such as filtering in Legends mode or typing the name of a note or a hotkey, I don't lose keystrokes at all.

[Lord_Shadow]

If i wanted to say see the game code in a text document were code i look?

[Taritus]

No place.  The source is closed.  The closest thing is the Battle Champs source, but that only shares the input, graphics, and sound code.  None of the actual game code is there.

[chucks]

Just pulled from the git master for battlechamps:

Code: [Select]

03:09:58 chucks@ares ~/src/bc/src $ sloccount .
Creating filelist for src
Categorizing files.
Finding a working MD5 command....
Found a working MD5 command.
Computing results.


SLOC    Directory       SLOC-by-Language (Sorted)
23729   src             cpp=12155,ansic=11329,objc=245


Totals grouped by language (dominant language first):
cpp:          12155 (51.22%)
ansic:        11329 (47.74%)
objc:           245 (1.03%)




Total Physical Source Lines of Code (SLOC)                = 23,729
Development Effort Estimate, Person-Years (Person-Months) = 5.56 (66.72)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 1.03 (12.34)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 5.41
Total Estimated Cost to Develop                           = $ 751,078
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL license;
see the documentation for details.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."


[Journier]

right now i have 102 dwarf fortress, all dwarfs at this moment are mining.

i just loaded my save from 40d, brought it over to 40d11, and im actually getting 2 or more fps less in 40d11.

averaging 13-20 fps.

in 40d i was getting 16-24

any suggestions? I turned off weather, economy, temperature... in the INIT, but not sure if that effects current saves.

Quad core cpu Q6600, 8800gt video card, 4gb ram etc etc.

[Smew]

right now i have 102 dwarf fortress, all dwarfs at this moment are mining.

i just loaded my save from 40d, brought it over to 40d11, and im actually getting 2 or more fps less in 40d11.

averaging 13-20 fps.

in 40d i was getting 16-24

any suggestions? I turned off weather, economy, temperature... in the INIT, but not sure if that effects current saves.

Quad core cpu Q6600, 8800gt video card, 4gb ram etc etc.

Personally I don't think 40d11 works very well for 64bit OS's, it runs the same as 40d for me, do you have a 64bit OS?

[Baughn]

What init.txt settings do you have?

[Shades]

I'm running a core 2 duo 2.4ghz (one of which stays at 800mhz due to cpufreqd) with 8gb of ram and a nvida 8400M GS under Ubuntu 9.04 64bit with the propriety gfx drivers (the open ones where slow)

I average around 120fps with 72 dwarves and a waterfall, capping at 150 which I rarely reach. Every so often I get a horrible slow spike for a few frames (the spike seems to be 20-30fps but it feels slow compared to normal running).

I don't have magma or much in the way of animal life left on the map though so that might be something to do with it. I have everything on in the init file and am using framebuffer as the print mode (instead of partial print 0 which I used to use).

Not sure if that will help narrow down why Journier is getting slow results though. I'll tell you know what I have when I breach 100 dwarves too if it's any different.

[Journier]

I am running a 64 bit OS, Windows 7 I didnt see the huge drop in FPS till i was around 60 dwarves then i went from probably easy 35fps + to this.

I can probably say ive never seen 120 fps after i had 25+ dwarves... but not sure on that.

Ive actually been killing off all the animals i had which gave me a few more FPS for a while till my dwarf population continued to grow.

I really dont know what to do, other than try this same fort on windows xp 32 bit system I have maybe.. although its a considerably worse system, maybe if its not that much worse performance wise that will tell me something...

ok im looking at previous saves, i had 50-90 fps with 57 dwarves.

[Journier]

What init.txt settings do you have?

I tried changing a few of them from another thread that reccomended it, but I saw No difference, so i put them back to stock.