Print

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

[PeridexisErrant]

I just spent a while playing with 4.61, and it was good

One thing that struck me as odd though was that the vanilla zoom commands change the text, and console commands change the map zoom level - it seems much more intuitive to have it the other way around both because the text is changed in much more obvious ways and because users generally want to leave the text tiles at their default size.  Given that I got similar feedback when I briefly had the next gen branch in the starter pack a while ago, would you consider changing it?  It's one of those minor-but-major UI issues...

[mifki]

Ok I'll try to make it the other way round, don't yet know how to do it though.

[Grumalg]

Don't know how it works in OSX or *nix, but it's fairly easy in windows via hooks with Windows API functions.  You can intercept and act on all user input or leave it unchanged for it's original target app. 

See:  http://msdn.microsoft.com/en-us/library/windows/desktop/ms632589(v=vs.85).aspx

Edit: fixed typo

Edit 2:  If I had my druthers, I'd like to see regular mousewheel events captured and eaten while sending twbt tilesize bigger | smaller commands to DFHack console instead, and convert Ctrl-mousewheel events by removing the Ctrl part and passing them on to DF.

[PeridexisErrant]

If I had my druthers, I'd like to see regular mousewheel events captured and eaten while sending twbt tilesize bigger | smaller commands to DFHack console instead, and convert Ctrl-mousewheel events by removing the Ctrl part and passing them on to DF.

Let's start by assuming that TwbT zooms the map-tiles with console commands, and the text-tiles with standard commands, and you're using keybindings that zoom DF with the mousewheel.  This is the current vanilla state of affairs. 

You should be able to adjust the controls to your own liking by adjusting the DF keybindings and adding a keybinding for the TwbT size commands to dfhack.init - though I'm not sure if dfhack can bind commands to the mousewheel (and don't have time to check right now). 

Personally I'd use "[/]//{/}" as the zoom set, but practically anything should work. 

[Grumalg]

You should be able to adjust the controls to your own liking by adjusting the DF keybindings and adding a keybinding for the TwbT size commands to dfhack.init - though I'm not sure if dfhack can bind commands to the mousewheel (and don't have time to check right now). 

Personally I'd use "[/]//{/}" as the zoom set, but practically anything should work.

DFHack is pretty limited in keybinds per it's docs:

Currently it supports any combination of Ctrl/Alt/Shift with F1-F9, or A-Z.

So neither your desired keys nor the mousewheel is supported for keybinds.  Using Win API hooks as I described above would allow *any* user input to be used and interpreted any way desired.

[PeridexisErrant]

DFHack is pretty limited in keybinds per it's docs:

Currently it supports any combination of Ctrl/Alt/Shift with F1-F9, or A-Z.

So neither your desired keys nor the mousewheel is supported for keybinds.  Using Win API hooks as I described above would allow *any* user input to be used and interpreted any way desired.

...Bugger.  Keybinding "bigger/smaller" to something should still be useful though - and if those commands changes the text and normal zooming the map tiles it'd be less of a problem. 

I guess my proposal then is that the focus should be on a more general expansion of DFHack's keybinding capabilities, rather than hardcoding a one-OS workaround that matches specific keybindings.  *touches wood*  How hard can it be?

[Grumalg]

A few afterthoughts...

The DFHack keybind limits makes choosing a sets of keys for map/text zooming a ugly issue, as DF uses so may keys that finding a set of binds that doesn't conflict with DF's keys within the DFHack keybind limits forces you to make non-esthetic choices.

I'm currently using shift-O and shift-P as was suggested earlier in the thread.  This has side effects, as pulling a lever changes your map zoom (making a dirt road probably does too, though I've not tried it).

Thses keys do not auto-repeat in the TwbT/DFHack/DF combination, so holding them doesn't allow quickly changing map zoom level - it takes a bunch of keystrokes to change it much.  Not sure if DF has these keys configured to not autorepeat or of DFHack is responsible for the lack of repeat - haven't looked.  In any case, that's why I asked mifki to make the amount of zoom change/keystroke  adjustable.  He added twbt tilesize +<delta> | -<delta> to handle this.

Since DF natively supports the mousewheel for zooming everywhere, I felt remapping things so regular mousewheel for map zoom and Ctrl-mousewheel for text zoom would quickly be intuitive for many users. It would also be fairly easy to code.  Much easier than having to create a full featured user defined keybinding system on his own.  I doubt mifki will want to bite off that task.

That being said, it would still be easy to use mousewheel and/or a fixed known set of keys.  The "[/]//{/}" set isn't a bad choice for a non-user settable fixed set of keys that doesn't conflict with DF.

While I'm speaking of the Win API, 'hooking' is a quite common technique and I'll be very surprised if the equivalent of this isn't available in OSX and *nix as well.

In windows terms you have to get the HWND of the target window to establish the hook on.  Usually you can ask for it by the name of the window.  Worst case takes enumerating the windows on the system to find it at initialization by means other than name.

Once you have it, the link I posted earlier shows how it's done - with code examples.  I also should have mentioned that you don't need to pass any commands through DFHack console at all with this technique, you'll already be in your code with the necessary info to just call your own routines to act on input.

[Pidgeot]

Personally I'd use "[/]//{/}" as the zoom set, but practically anything should work.

Those are probably fine on a US keyboard, but they'd be a pain on e.g. Danish: http://en.wikipedia.org/wiki/File:KB_Danish.svg

Everything else from the default DF keybindings works well enough despite being tailored for US already, so it would be best to avoid adding too many special characters in order to preserve that.

[PeridexisErrant]

The big problem with the mousewheel idea is that it's very common to remap the mousewheel to change z-levels.  Zooming is then done with [/], and so holding shift to send {/} for the alternate zoom would make sense  (yes, on a US keyboard).  Collisions are a problem generally, and an unavoidable conflict between z-levels and zooming is horrible - I've set that by accident a few times. 

That's whey I genuinely think the best solution is to zoom the map with whatever the standard zoom keys are (default: mousewheel), and just have the other commands given standard keybindings through dfhack.  Clearly it would also be good to allow a wider range of keybindings through dfhack, but I think that should be a general goal rather than specific to TwbT.  This would also help with localisation issues, since it would be as easy to change as anything else. 

[Grumalg]

Personally I'd use "[/]//{/}" as the zoom set, but practically anything should work.

Those are probably fine on a US keyboard, but they'd be a pain on e.g. Danish: http://en.wikipedia.org/wiki/File:KB_Danish.svg

Everything else from the default DF keybindings works well enough despite being tailored for US already, so it would be best to avoid adding too many special characters in order to preserve that.

Sheesh - How do you get along without [, ], {, and } ?  Every programming language I know uses those character extensively...

[Pidgeot]

Sheesh - How do you get along without [, ], {, and } ?  Every programming language I know uses those character extensively...

Why do you think I'm writing my LNP fork in Python (Also I have a macro keyboard so I can allow them to show up with just one keypress if I really need to)

They're still there, they're just not on the same key. (Some programmers switch to a US layout while coding just for this, I don't though...)

Of course I could use AltGr-8/9/7/0 even if those characters were used, but as you can see, that is already far less obvious how they map over than on a US keyboard

[fricy]

Personally I'd use "[/]//{/}" as the zoom set, but practically anything should work.

Those are probably fine on a US keyboard, but they'd be a pain on e.g. Danish: http://en.wikipedia.org/wiki/File:KB_Danish.svg
Everything else from the default DF keybindings works well enough despite being tailored for US already, so it would be best to avoid adding too many special characters in order to preserve that.

Sheesh - How do you get along without [, ], {, and } ?  Every programming language I know uses those character extensively...

Just so you can feel the pain... And that's the standard, osx adds it's own twist too.

[mifki]

Nice discussion, but it turns out that dfhack already intercepts ALL events (including mouse wheel). "Keybindings" command is what is limited and supports only some keys. So of course I'd prefer to have support for binding any input events to commands in dfhack rather than to deal with this in twbt.

[Grumalg]

Personally I'd use "[/]//{/}" as the zoom set, but practically anything should work.

Those are probably fine on a US keyboard, but they'd be a pain on e.g. Danish: http://en.wikipedia.org/wiki/File:KB_Danish.svg
Everything else from the default DF keybindings works well enough despite being tailored for US already, so it would be best to avoid adding too many special characters in order to preserve that.

Sheesh - How do you get along without [, ], {, and } ?  Every programming language I know uses those character extensively...

Just so you can feel the pain... And that's the standard, osx adds it's own twist too.

<gets down on knees and thanks the God(dess) for having been born in the land of defaultia>

You still working on a 32x32 tileset(s)?

Waiting with baited breath for a good one...

Running at 2560x1440 on a 27" here as main monitor.  Figure I'm gonna love a more detailed tileset.

[Grumalg]

Nice discussion, but it turns out that dfhack already intercepts ALL events (including mouse wheel). "Keybindings" command is what is limited and supports only some keys. So of course I'd prefer to have support for binding any input events to commands in dfhack rather than to deal with this in twbt.

What do you think the chances are for DFHack keybinding support to change?

It's your choice, but what I'm suggesting for the Win case likely amounts to 1-2 pages of code that's far simpler than most of your code.  You'd hook in ahead of DFHack and transparently pass everything except the map/text zoom stuff.

<Shrug> hope one of you makes the changes...  It'd make use of TwbT far simpler for the non-techy types and encourage wider use.