Print

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

[lethosor]

CP437 uses 0-255 internally, but many characters are converted to Unicode values larger than that (and they have to be, because ASCII/Unicode characters 0-31 are non-printable). 128-255 (or maybe a subset?) are used in Unicode to specify characters >255, so they can't be used on their own - some of them would work in the Latin1 encoding, but I doubt that would work well in a UTF-8/Unicode terminal window. Anyway, even if there were a way to get 128-255 to display correctly, the lack of 0-31 would make it impossible to display all of the characters DF uses.
I'd say that your screen reader ought to support more than 255 characters, but maybe it's running into a weird ncurses/terminal issue that it can't deal with.

[zkline]

Yeah. I'll have to do some more experimenting. My Mac screen reader has much better Unicode support but generally awful terminal support. It seems like I'm suck in a cycle where i can't get the two elements to play nicely together, and it's infuriating.

Thanks for clarifying the CP437 issue.

[Dirst]

I'm not sure how to make DF render in a different character set, but it may be possible to avoid the CP437 characters that map to high Unicode values.  There are only 190 printable characters in the Unicode range 0 to 255, and I don't think all of them are in the CP437 space.

On the other hand, some of the nonprintable ones might have a use.  Unicode 134 and 135 are "start of selection" and "end of selection."  This might help focus the screen reader on the cursor, though it would mess up alignment if this trick was used anywhere inside the map area.

In CP437, those characters are å and ç respectively.  The former is used occasionally in text, while the latter represents a totem object.

[zkline]

I may have to try playing with the Linux GUI screen reader, which I don't usually like, just because I hear its Unicode support is better. It's vaguely ironic that the whole point of text mode is to play in a text console.

All in all, I wish I had some knowledge of kernel programming, as that's where my unicode-unaware reader is buried. I imagine that converting it is non-trivial. As to whether the control characters will be useful, I don't know, but have my doubts. I kind of wish there were a "pure ASCII," mod for DF, but I realize that's impractical.

[lethosor]

It wouldn't be that hard to translate characters before they're displayed. The main issue is that DF uses all 256 CP437 characters, and there aren't 256 printable ASCII characters that they could be translated to.

[zkline]

That makes sense.

I've also been wondering about a menu-focused play style. It seems like there's a lot of information displayed on units and the state of the fort in general. I wonder if it's strictly  necessary for me to know where all the dwarves are, for instance. People can get that visually, but without zooming to a specific creature aren't they mostly just differently-colored smiley faces?

I tried the Linux GUI screen reader, Orca. It does read more characters than my console reader does, but I can't track selected items or the position of the terminal cursor easily. It's essentially the same problem exhibited by my Mac reader.

[mifki]

Do you have an idea how you're going to interact with the map if you're able to "read" it? While you were absent from the forums, I've released my Dwarf Fortress Remote for iOS app. It reimplements all DF screens with native iOS controls. I've checked now, and apart from some of them needing tweaks here and there, most of screens work with VoiceOver, as expected. Except for the map of course. I can implement any changes for the map too, but have no idea what exactly to do.

I wish I could support Adventure Mode as it's much easier to play in this situation than Fortress Mode, but it has poor support in DFHack.

[zkline]

Do you have an idea how you're going to interact with the map if you're able to "read" it? While you were absent from the forums, I've released my Dwarf Fortress Remote for iOS app. It reimplements all DF screens with native iOS controls. I've checked now, and apart from some of them needing tweaks here and there, most of screens work with VoiceOver, as expected. Except for the map of course. I can implement any changes for the map too, but have no idea what exactly to do.

I wish I could support Adventure Mode as it's much easier to play in this situation than Fortress Mode, but it has poor support in DFHack.

The big issue with the map is probably getting an overview of what's where. Actually, if there's a way to make it work with iOS that would definitely e something, as it's much easier to get a tactile "feel," for where things are if they're in different regions of a screen.

The way I would probably use the map would be to explore it with my screen reader's review cursor. This lets me get a sense of spacial relationships: this patch of stone is here, my tunnel entrance is over there to the south, whatever. I already do something similar with more traditional roguelike maps.

iOS would make his easier because the "cursor," could be my finger. If I move my finger over a tile it could tell me what I was touching. There are maps which operate on a similar principle—try opening up Apple Maps with VoiceOver.

Just some rough brainstorming here.

[Pvt. Pirate]

when i first read this, i imagined an interface that has pixels pop out, similiar to a braille screen.
a boy at our school had a braille laptop with a two lines display.
having that with a size of like 20x20 characters could give you a fast overview of the map.
still that would only show the currently selected layer, but as you stated, a display with one line with 24 characters is already very expensive - i don't want to imagine the price for a 20x20 screen.
so going for sound would be the easier way and i hope someone actually gets this woking for you.
in addition, i recommend playing with soundsense as it plays sounds for almost all anouncements, reports and even some minor events.

a few years ago i found this guy Tommy Edison by chance on youtube:
https://www.youtube.com/user/BlindFilmCritic
he's born blind and does movie reviews.

[Dirst]

The problem is that Braille is a 2-by-3 cell of dots, which only has 64 possible values.  Those have been mapped to ASCII codes (https://en.wikipedia.org/wiki/Braille_ASCII) and if we're going to use a subset of CP437 anyway, we could go one step further and restrict displayed characters to what can be rendered in Braille.

There is another implementation of Braille that uses multiple cells to represent other ASCII characters, but since this will be a map we should probably stick to what can be shown in a single cell.  Even the system I linked above has 8 prefix characters, and it's probably best to avoid using those entirely to prevent the display and reader from getting confused.

Dwarf Fortress already overloads a lot of symbols in the full set of 256, so using 56 will create many many ambiguous symbols that need the 'look' command to distinguish.

The only serious problem I foresee is that @ character that represents the adventurer.  That maps to the accent prefix in Braille ASCII, and I'm not sure DF can be modded to use something other than @.

[zkline]

Braille in general sounds great in theory, but we run into many practical problems. I have a 40-cell display, which can technically handle 8 dots per cell, though the tendency is to use dots 7-8 to indicate the cursor position.

All in all I think speech and reliance on the look command is probably a good compromise, considering I'd need to use a speech synthesizer to read a lot of game announcements anyway. I've never been a pure Braille computer user, and would probably find that frustrating and hard to get used to, added to DF's already intimidating complexity.

One aspect which would help me a lot would be positioning the text-mode cursor somewhere sensible most of the time. DF doesn't seem to care about where it ends up, so it's somewhere arbitrary. Putting it on the selected tile would, by itself, help me get a sense of where things are.

[Pvt. Pirate]

so, would it be possible to reduce the amount of used symbols and make them easier to recognize on braille?
-only one symbol for all dorfs, elves, humans,
-only one symbol for all animals
-only one symbol for all beasts
-a symbol with almost all dots for walls
-a symbol with almost no dots for empty space/floor/grass
-etc.

maybe even reduce further by having some simplified version of the "modest mod".
to be honest, the sheer plentitude of materials, items, beings and constructions in this game still confuses me everytime i play it

8 dots per cell means what? 3x3 and one of them plain? if so, you can have 5 characters next to eachother shown at the same time? that does not sound very useful for representation of the area.
even a 5x5 characters screen would be very small, but everything smaller is rather useless.

[Sanctume]

Hi. This is very interesting to me in terms of trying to design an app that would interact with DF.  My coder mind starts parsing the big pictures in smaller, manageable chunks. 

Let's take the "read map" as a large issue, and how one would go about breaking it into smaller functions. 

My first thought is to minimize the map, and it's possible to embark on a 1x1 which gives you a 48 x 48 tile playable area. 

Second, we can further minimize the z-levels or a world-gen, 1 cavern, can make a surface reach down SMR later between 30 to 60 z-levels. 
But this z-level issue is more about having a flat embark area so the surface is all in the same z-levels of our 48 x 48 playable tiles. 

I'm sure we can find an embark that gives that flat embark biome, and maybe even use Perfect World to generate such a map.


Next, let's think minimal fortress foot print.  Let's say an 11x11 walled fortress, with 1 north facing raising bridge, and roofed archer tower on the z+1.  Add a dry moat too, and it can be a perfectly decent bunker.

Sorry, it seems like I'm going off my train of thought.  But I was just thinking that DF AI mod I was watching in twitch some weeks ago.  The AI was building stuff, making military, and it was doing well actually.   

My thinking is that there is a way to tell the DF to build here or there, order a dwarf here or there without keyboard input. 
Now, if an voice command app turns those commands into "input"; and the DF AI app can be tweaked to use this "input" instead of it's AI code, then that's one step closer to interacting with DF. 

My next thought is the mod that has a separate window for Annoucements.  This app seems to just read the DF log files.  It is similar to how Soundsense work.  DF log adds a new season change, and the soundsense read the log then plays the sound file.  My thought on this is the code for reading the log can probably be parsed to describe what is happening in the game.

Oops, I have some more thought, but need to go to a meeting.  So I'll just post this now.

[LordPorkins]

Hey, just popping in to say Zkline, i am amazed at your sheer persistance. If you truly want to play DF this badly, i suggest you talk to Toady. Hes always looking for ways to make the game more accessible.

[zkline]

For what it's worth, I've installed df Remote on my iPhone and will be trying to play around with that today, among other things.

My plan of attack is mostly to see how far I can make it with the info I currently have available. At the moment, I can more or less easily access the Linux text-mode DF, though the map is troublesome. I think where I'll probably run into issues is designating areas—one question, how is designation indicated? Is it with an X to mark the cursor, or is that something else? Does the "designate," command take into account where I've been "Looking?"