Print

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

[Dirst]

I don't think a stock screen reader is going to work, if for no other reason than DF's habit of using multiple columns inside a screen.

DFHack plug-ins like TWBT and Rendermax already intercept the game's renderer.  In principle they could output sounds, or text formatted for a stock reader.  They wouldn't necessarily be bound by the symbols that DF wants to display, but my opinion is that it's better to keep things as close to the DF core interface as possible so that it can follow the game through upgrades.

[zkline]

I think I can say that columns or regions of the screen, in themselves, aren't a problem. It's what's in them that is annoying—the reason the embark map was such a pain was that it was vocalized badly. My screen readers are just reading everything as best they can, and if I know that something is divided up into columns or whatever I can generally parse it.

That being said, I still think interfacing with DF directly is the way to go.

[Button]

Well, the reason I was thinking we should output the screen to a text file is so that we could give the option to, instead of reading out the whole map every time, we could have an option to just output the diff.

[TheRow]

I am sorry to say zkline, but I doubt it will be any better once past the embark screen. Since the game is made out of tiles, even underground I bet the unexplored tiles, ones you don't know what they contain will be read out as fullblock. A maxed zoom in screen would display about 25x25 blocks, and even that is when the minimap and menu are opened fully to block out alot of the tiles that show the playfield. I for one would rip my hair out to have to listen to someone read out Fullblock to me over 100 times just so I can notis that I accedently went past my mine shaft when I changed what floor I was viewing. Not only that but it would be nearly impossible to defend a site form invaders if you place it to the top left, (minimizing the number of tiles it had to read before giving you the information you really sought, your fortress). Even if placed as far top left you can go, the game is designed so you are not alowed to dig into the top left block, mening that one floor down you would have to listen to the reader read out what ever symbol was on the top line, the walls so to say. To give an example it would most likley be * * * then Fullblock 20 times, and then for the next row it would be * X * and then again 20 Fullblocks.

As I said before I am no programer, but I think it should be possible to make a script that takes the info you are presented with and present it in a better way. Even if its just to say 23 Fullblock, instead of Fullblock Fullblock and so on 23 times.

[Dirst]

Just reading out exactly what is under the cursor would work... although it would be soul-crushingly tedious.  That's why I'm thinking of something like a radius around the cursor, with each symbol mapped to a sound.  The raws would be edited to reduce the number of symbols on the screen, taking advantage of the foreground color and background color attributes to indicate specific types with a second and third sound.  Those second and third sounds probably only belong on the cursor tile, but it needs playtesting.  Skimming along the map, the player would hear something stand out from the background and could home in on it for inspection.

The problem is that some tiles show up a LOT.  Unmined rock, grass, floor and open space take up most of the map.  It's important to distinguish between them, but even the softest sound for each is going to get irritating.  It probably needs shortcut keys to toggle different types on and off, which is something no stock reader will be able to accomplish.  We can fake it by making all of those routine tiles into punctuation marks, but then they are all-or-nothing.

On another front, Toady just did a round of improvements to the announcements engine.  The game can be configured to pause or recenter on specific events, and the list of trigger events just got a lot bigger.

[Scoops Novel]

bump

[Wimopy]

Couldn't the map be displayed on the Braille device? It might only display 40 characters, which is something like 5 by 8 I guess, but I'd say that's still better than any sound-based solutions. The main problem would likely be to parse that view into a text format, unless the text print mode is used. That would require the remapping of some keys, though that seems like a fair compromise.

As for the menus, that could be read out loud on a specific key combination. The announcements could be done with stonesense, where you hear what's happening instead of the actual information. Then when oppening the announcement screen, you could get a program to read the actual text.

Finally, the whole game would have to be slowed down with an FPS cap to limit information overload from the announcements. Pausing would help plan things.
It might just be manageable on a small embark. I'd say you'd definitely need help to learn the basics and to get a feel for all of it, maybe also for embarks and worldgen, but in play it could work, provided the Braille device part works.

Unfortunately, I'm no programmer so I definitely can't do this, I just hope the ideas might help achieve something.
Keep going, zkline! Don't settle for a "no".

[zkline]

Hi there

I have no intention of settling. I feel like I'm at a bit of an impasse right now—I think the problem is that Braille devices aren't nearly as capable as everybody seems to assume. The problem in this case is that 40 characters literally means 40 characters in a horizontal line, and that assumes every space is filled without room for anything else.
I think DFHack is an excellent place to start. Seeing as I've got that working on OS X, at least, I imagine Linux will be comparatively trivial.
Has anybody been able to do any work on that pure ASCII tileset idea? The big problem with the Linux screen reader is its inability to  understand the default set. Like I say, it vocalizes "null," a lot, but otherwise has great cursor tracking abilities.

[Wimopy]

Doesn't the game have a text print mode? Wouldn't that solve it? There's a post in DF General Discussion that mentions it. It disables mouse use, which I guess you don't really need anyway. Correct me if I'm wrong. What it also disables is key combinations with shift, so you would need something other than that, but that can't be so hard to solve.

I still think utilising the Braille device might work for the map view, but with a character that would mean "break here", then it would start the next row of symbols on the screen. I'll go with your verdict though, you're the final user.

Could someone look into print modes? I'm going to sleep now as I have a terrible headache, but it definitely sounds like print modes deserve a check.

[Button]

Hi there

I have no intention of settling. I feel like I'm at a bit of an impasse right now—I think the problem is that Braille devices aren't nearly as capable as everybody seems to assume. The problem in this case is that 40 characters literally means 40 characters in a horizontal line, and that assumes every space is filled without room for anything else.
I think DFHack is an excellent place to start. Seeing as I've got that working on OS X, at least, I imagine Linux will be comparatively trivial.
Has anybody been able to do any work on that pure ASCII tileset idea? The big problem with the Linux screen reader is its inability to  understand the default set. Like I say, it vocalizes "null," a lot, but otherwise has great cursor tracking abilities.

Zkline,

The following is an image of the complete default tileset. Can you tell us which symbols it has trouble with?



You can find this image at http://upload.wikimedia.org/wikipedia/commons/f/f8/Codepage-437.png .

Also, does your Linux screenreader include color information, and is there a way to make it do so?

[zkline]

Um…

It's an image of a tile set. I'm totally blind. I'm afraid I have no way, short of OCR software, to get anything out of that. So I can't tell you precisely which characters give me fits, but a good rule of thumb is anything which isn't in the7-bit  ASCII table—things like smiley faces and blocks for walls and so on, will be an issue.

As far as color, yes, my Linux reader can definitely give me the color of a given character. I'd need to check each individually but it's doable.

[Button]

Sorry, I thought you meant that your Linux screen reader was able to work off an image. If it can't, a tileset isn't going to help - the tileset only changes the image shown, not what will be reported to DFHack.

We might be able to add some custom sounds to your screen reader though. What's its name?

[zkline]

Maybe "tile set," wasn't the right term to use. I've been having most success at the moment using the text printing mode, so whatever characters ar used by that is what I'm seeing.

My screen reader is called Speakup, http://linux-speakup.org. I think modifying it is a problem, since this is a Linux kernel module and thus kind of low-level. DFHack, though, is able to do things on its own pretty well, so I don't think we need to touch the screen reader at all.

So basically, I went into the init.txt file and set Print_Mode:Text. I'm seeing mostly comprehensible output, though the reader chokes on a lot of the characters which aren't standard ASCII. I have no way to  access the regular game interface at the moment otherwise.

[Button]

OK, here's the first line of Code Page 437 in text format. Hopefully this should be at least partially readable. Let me know the numbers of the unreadable symbols. If this works, I'll transcribe the rest of the table.

The entries are in the format of a symbol and then the number of the symbol on the code page, for reference.

☺ 1
☻ 2
♥ 3   
♦ 4
♣ 5
♠ 6
• 7
◘ 8
○ 9
◙ 10
♂ 11
♀ 12
♪ 13
♫ 14
☼ 15

[zkline]

I'm afraid that under Linux these all show up as "null." Perhaps it's possible to get them to read properly, but they don't read at all right now.

The frustrating thing is that I also have access to a Mac, which *does* read these symbols properly but doesn't let me track the cursor very well, at least not in Terminal. So I have two screen readers, neither of which is entirely satisfactory.

To save the trouble I can guarantee things will start reading properly around 032, which I think is ASCII space. I can't vouch for 16 to 31.