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]

damn, I'm getting the key-repeat error, in both d10 and d11. it only seems to happen some of the time, but even with the repeat value set to 1000 in the init it still happens rather regularly

which is a shame because my fps is awesome compared even to d9

Can you describe the circumstances where you see a repeat with d11?  I couldn't get any invalid repeats to occur in my short test.

I'm not sure what the differences are between 40d9 and this one that would break the non-QWERTY keyboards.  I guess that's a new project.

WinXPSP2, Dvorak layout.

Just checked, US Dvorak layout is a "good" layout (i.e. VK_A VK_O VK_E VK_U etc are in the right place)

[what that implies is that this is indeed a problem with DF, in case i wasn't clear]

I think d7 had this problem, but it was fixed (mostly) in d9.

I also have problems with my keyboard in 40d10 (same problem in 40d9). I use a german qwertz layout. Numbers and letters work well but other stuff works like with an english layout or not at all.
Numpad seams to work.

For all of the layout issues I would need very specific information.  I didn't change any of the translation table values from d9.  Also the lowest level that gets the keypress information is the same.  Every key and layout that worked in d9 should be working in d11 exactly the same.

Trying to track down the issues with keyboard layouts is not going to be easy.  There are many different layers of involved before the keypress gets to DF.  If you have a layout problem please provide OS, layout, specific keys that don't work stating both the expected character and what d11 got, and whether the keys worked in d9.

[Musluk]

For all of the layout issues I would need very specific information.  I didn't change any of the translation table values from d9.  Also the lowest level that gets the keypress information is the same.  Every key and layout that worked in d9 should be working in d11 exactly the same.

Trying to track down the issues with keyboard layouts is not going to be easy.  There are many different layers of involved before the keypress gets to DF.  If you have a layout problem please provide OS, layout, specific keys that don't work stating both the expected character and what d11 got, and whether the keys worked in d9.

Windows XP SP 2.0 Turkish Edition v2002, 102 key turkish q keyboard.

I think the problem is with the 40d9 and prior versions. Lemme grab a 40d and try there.

Edit: Yah, 40d (and 40d#) are using slash and apostophe combined with shift, thus Question Mark loc for level down and Quote (") loc for level up.

FWIWI the keys are actually working as they should, as in, the spot for < and > are actually correct this time, I'm just too used to the 40d style. It is not actually a bug for 40d10 or 11 but instead a bug for 40d9 and below. Willing to bet it's about unicode as well

[counterfeit]

If you have a layout problem please provide OS, layout, specific keys that don't work stating both the expected character and what d11 got, and whether the keys worked in d9.

OS is Ubuntu 8.10 in german. Keyboard is german, the layout is german-nodeadkeys.
Not-as-expected-working keys are:

expected	actual
;	<
<	,
>	<
=	SHIFT 0
+	=
ß	keypress not recognised
ü	keypress not recognised
ö	keypress not recognised
ä	keypress not recognised

Results are identical for 40d9 and 40d11.
This table is not complete, I checked keys used in df plus ß, ü, ö and ä.
My problem is to understand which keys you are talking about. You seem to use (in df) some logical key from the hardware which then has certain a representation in the OS but eventually a different one in another language layout. But you refer to the keys with the OS representation in your language. E.g. the "=" is where I would expect it to be for an english layout on my german keyboard, but for my german layout it is "SHIFT + 0" in df language. By this I get a somehowish english layout (although it *is* qwertz as it should be for a german layout) which does not work out  of the box.
So, state for me is:
I can, even though it is tedious, reassign most of the keys so they fit my keybord layout.
I cannot use all of the keys on my keyboard, as some are not recognised by df.
The keyboard bindings shown in-game do not match the letters shown on my keys for certain actions.

[Puck]

hmm, I never had any keyboard issues (german layout) over here, with 40d9.

The WAS one thing that was a bit weirdish, but I couldnt tell if it was that way in the 40d version (and earlier) too, or not.

When you used 2 keys (instead of one) to scroll diagonally and then let go of one of them, the other one wouldnt be registered anymore.

[counterfeit]

hmm, I never had any keyboard issues (german layout) over here, with 40d9.

Which OS and keyboard?

[Puck]

XP Home edition, SP3 and basically always up to date
Some cheapo "HAMA" USB-keyboard for 6 euros or so, no manufacturer software installed, just the generic usb keyboard drivers that I assume exist, provided by Windows. Don't really know what kind of information I could give you about my keyboard.

Maybe it's worth mentioning that the only keyboard layout I have active is in fact the german one. there is no "dormant" english layout I can switch to with a few mouseclicks or some hotkey. i believe this would be standard for most windows OS that run in german, but I just disabled it. Never found a use for it.

[cerapa]

It makes worldgen and the menu much faster, but it seems that in game it is even slower than usual.

PS: My usual is 20 fps. And I think theres something wrong with my drivers so, this might not be that important.

[counterfeit]

Don't really know what kind of information I could give you about my keyboard.

So it is a german keyboard, i suppose. For me the windows-version (just 40d9 tested) gives the same results (and problems) as the linux-version. I also use xp-sp3 with just a german layout. Tested it on a standard keyboard and on my laptop. Same issues in both cases. 

[InsanityPrelude]

In d10, I'm getting 25-30 FPS with 120 dwarves, 100 animals (I guess I need to start having the heart to kill puppies instead of waiting to train them to wardogs), magma and a cave river. I forget what size the site is... 4x5 maybe.

Also, temperature and weather are on, and with KEY_HOLD_MS at 100 I don't have the repeat issue, although sometimes the display moves further than intended when I move around the map.

I guess I may as well try out d11.

[spathi4tw]

Dwarf Fortress has had input issues for quite a while now, at least on the mac. These newer builds seem to be having an effect though, so hopefully it can get cleaned up for the next production release. I use dvorak as my keyboard layout. I tested all the standard keys (0-9a-z + punctuation), shift + key didn't seem to produce any surprises (i.e. it worked or didn't work as the base key did). I tested 40d, 40d9, 40d10, and 40d11 and got three different result sets!

Here are the expected mappings for the keys that had problems:

Spoiler (click to show/hide)

Qwerty	Dvorak
;	s
.	v
,	w
/	z
-	[
=	]
[	/
]	=
q	'
w	,
e	.

Using OS X 10.5.6 and the 'Dvorak' and 'U.S' keyboard layouts I get the following results:

Physical Key Pressed (Querty)	Result in Dvorak Mode (40d)	Result in Dvorak Mode (40d9)
;	;	s (correct)
.	.	v (correct)
,	,	w (correct)
/	/	z (correct)
-	-	-
=	=	=
[	[	[
]	]	]
q	Nothing	q
w	Nothing	w
e	Nothing	e

40d10 and 40d11 seem to ignore the input method entirely: they produce normal qwerty output for all keys (not just the ones listed above) regardless of keyboard layout settings.

'Nothing' means the key had no effect at all.

There are also issues on windows between the two mappings, but I don't have the ability to test that at the moment. Let me know if you need more info.

p.s.
All these tests were done using copies of the same save, and entering text in the 'enter a custom nickname' field for convenience.

update: This is using a standard u.s. qwerty keyboard.

[Andy Korth]

I'm testing 40d10 on my 4 core Mac Pro running OS X 10.5.6.

I'm running with the following settings:

[WINDOWED:YES]
[GRID:130:40]
[PARTIAL_PRINT:YES:2]
[WINDOWEDX: 1300]
[WINDOWEDY: 960]
[FONT:curses_800x600.png]
[FPS_CAP:100000]
[G_FPS_CAP:30]
[VSYNC:ON]

Menu framerate is about 3100. In game, when paused my framerate is about 3100. In game in an area I just embarked to, I get about 900 fps. One of my forts with heavy magma flow is sitting at about 22 fps.

There are no problems with the graphics, everything looks fine.

I am experiencing some of those double keystroke issues. I'm on a standard US qwerty keyboard. This problem is most notable when I build a door- hitting return to place the door immediately forwards me through the material selection portion- so I never get to choose which door to place. This occurs no matter how fast I try to tap return. The effect is same with only the key down- but it then goes ahead to place an armor stand too. (So I can't quite say if it's a key repeat issue)

EDIT:

I can confirm that the double keystroke issue is fixed in 40d11! Awesome work, thanks! 

[Greiger]

The occasional key doubling on the directional keys seems to have gone away for me with d11.  So whatever was done seems to have worked for them.  I never had the reported enter doubling but the directions sometimes did.

(Can't contribute to the current topic due to a fully functional, american querty keyboard. Sorry.  Hear good things about those Dvoraks though.  Faster typing once ya learn it.)

[Baughn]

I'm testing 40d10 on my 4 core Mac Pro running OS X 10.5.6.

I'm running with the following settings:

[WINDOWED:YES]
[GRID:130:40]
[PARTIAL_PRINT:YES:2]

Those settings are INCORRECT for 40d11, and I think 40d10 as well.

Don't just copy the init.txt from an earlier version, guys.

[kutulu]

Question for whoever's building the linux binary: are you *really* using libtiff v4.0 alpha?  Or are you using 3.something and your distribution is playing games w/ the soname?  It can make a huge difference: other distributions will have a libtiff version 3.8.2 or so called 'libtiff.so.3', which you can just symlink to 'libtiff.so.4' and everything will be fine; but may have libtiff 4.0.0a called 'libtiff.so.4' which is a completely different library.

(I did the symlink workaround and it seems ok so far, so either it's not using libtiff all that heavily or it really wants a libtiff v3 library.)

[Veroule]

Regarding the layout issues there seems to some rather conflicting reports.

spathi4tw: Thank you for the detailed report!  If I understand it right you have a keyboard that is labeled as qwerty and have set the layout as Dvorak using something in the Mac OS.  Can you check the physical -, =, z, x, and c keys as well.  So far I think there is a problem at the OS level for you, but until 2 physical keys map to the same value I am not calling it conclusive.

counterfeit: Your reports are the most troubling so far.  You are saying you got the EXACT same incorrect results with 2 different OSes on 2 different machines.  I can't see it being a error with any of the underlying hardware or software under that circumstance, but Puck is reporting he has no problems with a German keyboard.  Can you provide any additional details about the hardware of both test machines?

Puck: I double checked, using things like Left-Arrow and Right-Arrow simultaneously, work perfectly with d11.  You can even press and release Shift repeatedly, and it still works flawlessly.  I think all of the old stuck/lost key issues are fixed for d11.

Musluk: You are saying that everything is correct now.  What you are also saying is that the correction shifted only a few keys.  Those keys are the same ones Puck is saying have become wrong for him.

Everybody: I do want to try and make it perfect, but so far the reports are sufficiently confusing that I have no idea where the problem lies.  Maybe I just know too much about the lower level hardware and software stuff to correctly spot the problem in the higher level code.  Maybe it isn't actually solveable and I should move on to helping Baughn with the threading project he has in mind, or to the pathing project I have been taking my with.

Any detail anyone having a problem can add might be helpful.  Telling me that the cord between your keyboard and computer has a scuff 1nm deep, 2mm long, located 17cm from the keyboard housing probably isn't helpful towards fixing this, but it does say you have run out of details that could be useful.  Don't be afraid to include information about that scuff, I will sort out the relevance of everything as it becomes apparent what it means.