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

[virus_found]

It should've. Never mind..

At this point, just use the latest version; it works now.

I meant, wouldn't start, not wouldn't compile
From d09e2fb5ff already, says the same old thing:

Code: [Select]

$ ./df
./dwarfort.exe: symbol lookup error: ./libs/libgraphics.so: undefined symbol: _ZN15enabler_inputstC2EvI'm using the release, but I'm just curious about a git repo.

[Angellus]

Hi, I just booted up an adventurer in an already played world (Played fortress mode before) and I seem to be unable to play. Whatever I press, it will not work. I cannot control my character, does anyone know if this is a known bug or maybe something to do with my pc?

The non dx versions worked perfectly with adventurer.


EDIT: I just restarted, still no keyboard response.

[Random832]

What direction is the keyboard code going in, generally?

The direction I am headed currently is to allow full Unicode support.

That is a bad direction. Keys are not characters. There is no Unicode for F1, Page Down, Control-7, Alt-X, Shift-Backspace, or any of numerous other things that make sense to have as assigned keys.

[Random832]

Scan codes still have to be used for keys that do not produce a character, and I will keep writing code that detects them despite the many people that have said scan codes should not be looked at.

SCAN codes should not be used. KEY codes (i.e. VK_... on windows, Keysyms on X11) should be used.

You should not use character values (i.e. unicode) for anything other than text entry - and there are not that many places where text entry occurs.

It is possible that you do not understand what a scan code is, and that you are either using the term incorrectly, or inconsistently mixing the two in your code.

The people complaining you should not use scan codes almost certainly are using the term correctly, since use of scan codes is _exactly_ what causes dvorak/azerty layouts to screw up.

[Corona688]

SCAN[/b] codes should not be used. KEY codes (i.e. VK_... on windows, Keysyms on X11) should be used.

SDL provides its own keycodes consistent from OS to OS.  For very weird keyboards/keys though, scancodes may be the only way to recognize a keypress has even happened for, say, the 'play/pause' key.  So scancodes should only be used when a key cannot be recognized by its code, and never as default since it'll be keyboard-specific.

SDL also provides unicode support but I have to agree here -- I have no idea what good unicode support would be in a game that is pretty much operating inside its own wacky code page by now   Unless you want to start introducing actual fonts and all the headaches they mean, that is.

I believe SDL translates anyway, the unicode values aren't actually provided by the OS, so its not more information.

[Corona688]

How would I get this thing to actually get me a full-screen view on my laptop? I can only get about half the screen to actually be used, and it's way to small for my tastes.

I'd blame your laptop/video drivers for just using half the screen instead of scaling it to the screen's native resolution.  You may have to mess with your init.txt to set it to a higher resolution than your tiles and thereby stretch it.

[Toady One]

Re: the map text output, I made that feature at the request of somebody working on one of the main visualizers (as far as I know), in the format requested by that person.  I'm not going to change it until there's an established consensus from that group of people.

[Random832]

SDL provides its own keycodes consistent from OS to OS.

Then use those. Extensively. Neither scancodes nor character values should be used 'out of the box', even if support is provided for both.

[jup]

Hi. Thanks for a new version. Problems I've run into (I am using linux version):

• build and designation menus are garbled, as others mentioned. It seems to by some justify problem - hotkeys are mixed in with text and it looks ugly. When I double info window size via Tab, it's somehow better, because most letters are right of the text as they used to be, but still not correctly aligned. For me, this is rather show stoper, because I am stilll new to this great game and I don't really know menus by memory. And I use these menus all the time, so I'll proably just use previous version for now.
• input in adventure mode is wierd. As someone mentioned, keys like '>' for visitng site from Travel mode don't work. Neither does '<'. But '.' does, if I remap it. Seems to be problem with Shift (I am using regular English keyboard). But capital letters do work.

That's all for now. Hope it helps.

[HandOfCode]

With Tim's custom tileset d13 seems to be skipping a few of the specified tiles. Fire snakes are not the same, palm trees are the default tree icon, and I'm sure I'll find others as I continue playing.  Most of the tiles did in fact load properly so I'm not sure why it skipped/is not rendering a few of them.

Also if I use my mouse in dig mode it stays "clicked" until I actually exit the program itself.  When the mouse is over the game window it constantly registers click events, I can't even switch dig modes until I move the mouse over an area where the game doesn't respond to mouse clicks.

d13, windowed mode, win XP.

[peterix]

Re: the map text output, I made that feature at the request of somebody working on one of the main visualizers (as far as I know), in the format requested by that person.  I'm not going to change it until there's an established consensus from that group of people.

Some kind of consensus on this thing would be great.

To me as a co-developer of khazad, it seems rather sub-optimal. Extracting the *whole* map this way (not just a single z-level) takes too long. I brewed some tea after staring at it for a couple of minutes. Khazad does this in seconds through the tiny 4B window of the Linux ptrace function. Also the amount of raw data produced is quite staggering. A well documented binary format would be better IMHO.

[Random832]

To me as a co-developer of khazad, it seems rather sub-optimal. Extracting the *whole* map this way (not just a single z-level) takes too long. I brewed some tea after staring at it for a couple of minutes. Khazad does this in seconds through the tiny 4B window of the Linux ptrace function. Also the amount of raw data produced is quite staggering. A well documented binary format would be better IMHO.

That wouldn't really have any advantage over text - either he has to convert into it (slow, just like the text format), or he has to freeze the internal structures (not gonna happen)

The way you do it now is only fast because you have to adapt to any changes he makes to the internal structures.

[Veroule]

SDL provides its own keycodes consistent from OS to OS.

Then use those. Extensively. Neither scancodes nor character values should be used 'out of the box', even if support is provided for both.

That is what 40d11 used exclusively.  Let me repeat that another way so it might sink in...40d11 exclusively used SDL's keysym.  It didn't work for some Dvorak users because the OS layout translation is done with the Unicode translation.

Now please let it go, unless you have a bug to report.

[Veroule]

Hi. Thanks for a new version. Problems I've run into (I am using linux version):

• build and designation menus are garbled, as others mentioned. It seems to by some justify problem - hotkeys are mixed in with text and it looks ugly. When I double info window size via Tab, it's somehow better, because most letters are right of the text as they used to be, but still not correctly aligned. For me, this is rather show stoper, because I am stilll new to this great game and I don't really know menus by memory. And I use these menus all the time, so I'll proably just use previous version for now.

I am not really sure what happened to these.  I did make a change from D12 in the routine that retrieves the key text from the binding system.  That change seems to work correctly everywhere else.  I will put it on my list to look into though.

• input in adventure mode is wierd. As someone mentioned, keys like '>' for visitng site from Travel mode don't work. Neither does '<'. But '.' does, if I remap it. Seems to be problem with Shift (I am using regular English keyboard). But capital letters do work.

The travel end '>' seems to be an issue with the order bindings are tested, and a result of the law of unintended consequences.  In order to keep things from getting too slow I had to make bindings sticky.  This make it so that once a binding is matched to a keypress no other binding can be matched to that keypress, until the binding is marked done.  I am not quite sure what is being tested for during travel.

This is also the cause of numbers not working in notes, it applies equally to all 8 movemement numbers, and the shifted versions of them.  I am not sure if I can do anything for these immediately, but I will write a few functional options for Toady to use.

[Veroule]

I am testing it now.
...
...

Ok, adventure mode movement keys work for the numpad, but moving with the arrow keys still doesn't work.

It would seem I forgot to put them in the default bindings file.  It will be added for the next time.  Thank you.