Bay 12 Games Forum
Dwarf Fortress => DF General Discussion => Topic started by: zkline on October 28, 2014, 02:12:50 pm
-
Hi All,
I'm a fan of DF stories who happens to be totally blind. This makes playing the game in its current state kind of impossible. I've posted on this topic several years previously, but this thread (http://www.bay12forums.com/smf/index.php?topic=90229.0) was understandably lost to the mists of time.
I'm writing again in hopes that some ore meaningful progress might be made this time around. One notion proposed last time involved DFTerm, which I'm given to understand is no longer being developed.
I don't mean to come off as nagging by bringing this up again. :) I just want the opportunity to play this game I've heard so much about, if at all possible, independently. I don't know what kind of access people have to the underlying game information these days, but hope the situation hasn't gotten worse. Any new insight into this sort of question would be greatly appreciated.
Thanks much,
Zack.
-
I have trouble imaging how DF would work for a blind person because I don't know what sorts of solutions a blind person would consider workable. Can you describe what a workable interface might be like? How do other games resolve this? What about real-time strategy games, which seem to me most similar to DF? Is there a blind version of Starcraft, for example?
I would love to give this some thought but I would like to better understand the problem from a blind person's perspective.
-
Hell, dude, well done for trying. The only way I could really think of would be by instructing another person.
-
I found this website about making games blind-accessible and read through the guidelines:
http://www.blindcomputergames.com/
Basically it seemed to be saying that games should use as much text as possible and should have that text voiced. Well, DF is nothing but text, so that's really not a problem. So what about the most dead-simple, obvious solution? What if everything in the menus was voiced, and every tile in the field of play were voiced? For a sighted player, you use the 'k' key to move over tiles and there's a text display of what's on the tile. Even sighted players can't tell what's on a tile just by looking at it (at least not when they first start playing). So what if everything were voiced? And anything that pauses the game (like a goblin ambush) could be voiced as well. Would that work? It would take some getting used to but it doesn't seem *all* that different from what any DF newbie experiences. I imagine this could be very workable especially on a smaller embark.
-
Hi there,
Unfortunately there are few realtime strategy games to serve as demonstrations. We don't have anything quite like StarCraft. One we do have is something called SoundRTS, which is kind of like a simplified Warcraft in terms of setting, at least. See http://jlpo.free.fr/soundrts/ (http://jlpo.free.fr/soundrts/)
In my previous discussions on the topic the amount of text DF uses was definitely commented on. The look command came up as something to consider, and a project called DFHack was seen as a promising starting point. Basically, my screen reader needs to be able to tell me what's being shown to everybody else. A big problem is that the default interface for DF is SDL-based, which is totally unreadable to screen readers no matter how textual it looks.
As for playing with someone else, that's always possible, and I've had quite some fun playing some games that way, but I'd really rather play things when the mood strikes me, if possible. :)
-
DFHack can already manipulate the default view and and transform and manipulate data, so I would think it would be possible to pipe the readout into a second application that could read off whatever the menus or Look/View K/V keys were showing you. I guess it would be challenging to play DF that way, but DF is pretty damn challenging anyway and not for anyone who wants to do things the easy way.
-
I don't know that much about how blind users interact with computers as it is. I imagine that commands could be memorized, most seeing users have done so already. The challenge is with display of dynamic information, and I can't imagine anything less than a refreshing braille terminal being sufficient.
-
Braille is one option, though not something I think is as essential as it looks. For one thing, Braille devices available to most blind people, me included, only display a small amount of info at a time. I have something which displays around 40 characters worth, give or take, and it's around $2,500.
I think the pause feature of DF will be invaluable. I happen to be using a Mac, which has a great built-in screen reader.
If I may ask, is super detailed access to information all that important most of the time? During, say, a goblin invasion or whatever it might very well be, and I suppose fortress planning is very important. I think most of that can be done while the game is paused though, letting me analyze information at leisure. Isn't a lot of the day-to-day important stuff already conveyed by announcements?
-
Hey i remember that thread.
You're really stubborn, ill give you that.
As for if detailed acces, yes its crucial. One missed tile in a wall, one missed invader can cost you a whole fort is lost
Unless you are playing on really low fps, its easy to get sensory overload, even if you are very perceptive.
-
It sounds to me like there's way too much information here for Braille to be useful.
I play DF paused most of the time. Maybe I'm just slow, but I'm not one of those people who leaves a fortress running unattended. I pause, do stuff, unpause long enough to make sure it is working, then pause again. I would imagine you could analyze things at leisure while paused, yes. During goblin invasions it would be the same as anything else, you would scroll around with K and V and listen to whatever was on the tiles. Since each fortress starts from scratch you would have time to get familiar with the layout as you went along and you would probably have a good idea of what your fortress looks like in your head. I do a lot of my fortress planning when I'm not even at the computer, just imagining it in my head. You can control the size of your embark, so you could do a small 1x1 embark and it would be less to deal with (there is plenty to do in a 1x1 embark, especially since you can control what sorts of resources and geographical features are present in the embark). I would imagine the Mac's built in screen reader would be very helpful.
-
As for if detailed acces, yes its crucial. One missed tile in a wall, one missed invader can cost you a whole fort is lost
Unless you are playing on really low fps, its easy to get sensory overload, even if you are very perceptive.
He could cap the FPS so it played slower. As for missing a tile, yeah, that goes for sighted players too. I lost a whole fort yesterday because I opened a volcano and forgot to close a floodgate. Oops. Sight didn't do me much good.
-
I had several posts like this http://www.bay12forums.com/smf/index.php?topic=138754.msg5430441#msg5430441 on my thread. Unfortunately I didn't go any further with this mostly because I too don't understand very well what needs to be done.
-
I had several posts like this http://www.bay12forums.com/smf/index.php?topic=138754.msg5430441#msg5430441 on my thread. Unfortunately I didn't go any further with this mostly because I too don't understand very well what needs to be done.
Would it be best to run it by toady?
-
I hate to say it, but I don't think I can give a straightforward answer for what needs to be done. The problem is that, as far as I know, nobody has done much quite like this before. The scope of the project is pretty huge, and I think the only way we're going to get anywhere is if we are willing to experiment a little bit.
A start would be a way of accessing the interface, through a third-party program or otherwise. there's supposed to be a full text mode for Mac, but it doesn't seem to be supported in the newest releases, if it ever was. DF Term was an excellent start in that direction.
As for my being stubborn, yes, I've definitely been called that. I just don't believe that there is no solution, in most cases, if people are willing to think outside the box a little bit, so to speak. Needless to say, I'm willing to provide feedback and test any ideas anyone would care to experiment with.
-
I hate to say it, but I don't think I can give a straightforward answer for what needs to be done. The problem is that, as far as I know, nobody has done much quite like this before. The scope of the project is pretty huge, and I think the only way we're going to get anywhere is if we are willing to experiment a little bit.
A start would be a way of accessing the interface, through a third-party program or otherwise. there's supposed to be a full text mode for Mac, but it doesn't seem to be supported in the newest releases, if it ever was. DF Term was an excellent start in that direction.
It's technically not a problem to implement some sort of text mode on os x, to pass screen text to another app or whatever else. But I don't see how this alone will help to understand the map which isn't quite "readable".
-
Fair point. The map is the big stumbling block. The way I've solved this problem with NetHack or similar games was to have a separate "review cursor," which could move around and tell me what was on each tile, or at least what the symbol for each tile is. It's kind of slow, perhaps, but it will let me get a feel for things.
Another idea worth considering is landmarks, or whatever other name you want to use for them. The issue with these games is that 99% of the map is visual clutter. It's important for simulation purposes but your eye skims over it most of the time. A way to move from one point of interest to another, perhaps with a coordinate system in order to tel me where I am at any time, would go a long way. Does this make any sense?
-
Fair point. The map is the big stumbling block. The way I've solved this problem with NetHack or similar games was to have a separate "review cursor," which could move around and tell me what was on each tile, or at least what the symbol for each tile is. It's kind of slow, perhaps, but it will let me get a feel for things.
Another idea worth considering is landmarks, or whatever other name you want to use for them. The issue with these games is that 99% of the map is visual clutter. It's important for simulation purposes but your eye skims over it most of the time. A way to move from one point of interest to another, perhaps with a coordinate system in order to tel me where I am at any time, would go a long way. Does this make any sense?
On a mac you can edit data/init/init.txt and change the PRINT_MODE option to TEXT and GRAPHICS to NO. It will run in a console as a text aplication.
If that let you work around SDL, what you did for nethack will probably work for df. If your text reader can tell you what the look commands is returning, you have most of the game covered.
-
On a mac you can edit data/init/init.txt and change the PRINT_MODE option to TEXT and GRAPHICS to NO. It will run in a console as a text aplication.
No it's not supported on OS X.
-
Yeah, I was going to chime in and say it isn't supported. :( The comments in init.txt are apparently outdated. I'm not too surprised, since this was originally Windows-Only if I remember, but it does make this whole process a bit less straightforward.
-
Fair point. The map is the big stumbling block. The way I've solved this problem with NetHack or similar games was to have a separate "review cursor," which could move around and tell me what was on each tile, or at least what the symbol for each tile is. It's kind of slow, perhaps, but it will let me get a feel for things.
I don't see why this couldn't work for DF. Yeah, it would be slow, but you could play. You could pause the game anytime and move the cursor around if you needed to figure out what was going on. So the Nethack thing is a voice, right? In DF it would be something like "Engraved obsidian floor" and "rough basalt wall" and "farmer on a plump helmet plot" and "goblin archer on grass". DF does not have graphics per se, so a sighted person isn't really seeing any of this either. It's an abstract symbol plus your imagination.
-
Fair point. The map is the big stumbling block. The way I've solved this problem with NetHack or similar games was to have a separate "review cursor," which could move around and tell me what was on each tile, or at least what the symbol for each tile is. It's kind of slow, perhaps, but it will let me get a feel for things.
I don't see why this couldn't work for DF. Yeah, it would be slow, but you could play. You could pause the game anytime and move the cursor around if you needed to figure out what was going on. So the Nethack thing is a voice, right? In DF it would be something like "Engraved obsidian floor" and "rough basalt wall" and "farmer on a plump helmet plot" and "goblin archer on grass". DF does not have graphics per se, so a sighted person isn't really seeing any of this either. It's an abstract symbol plus your imagination.
I think jumping between points of interest as per zkline's suggestion is essential too - you probably don't want to hear "grass.. grass.. grass.." twenty times while moving to goblin archer.
-
I remember the first thread for this.
Not that I think I could really comment much, I don't think there is a more elegant solution than having a cursor read out the contents of a selected tile. With sound there isn't an option to convey information in any way that isn't listing one at a time.
-
Unfortunately, yes, sound does suffer from that limitation. Somebody mentioned an interactive fiction-style interface in the original thread, I don't know if it was mostly intended as a joke. Text overviews of what can be seen are another way to go, I suppose.
FOr starters I need a way to access the menus and generate a world and so on. At the moment I can't even do that because the SDL interface isn't accessible. I don't expect it will ever become so on its own because of the way SDL works. What are we able to do with third-party programs?
-
Wow, zkline. I'm really amazed! I mean, I've seen "blind" people play video games before (not completely blind), but this is truly extraordinary! Living proof that the bay12 community is truly beyond quality.
I'm just curious here: what program do you use to play? I assume some software that "reads" the information out to you, but I don't see that working with dwarf fortress.
-
I have a program which comes with my Mac, called VoiceOVer. It's also incidentally available for iOS devices, not that we'll see DF for one of those anytime soon. I can play games, though most of them are for iOS or Windows, Mac gaming for the blind is distinctly lacking. :(
But I can't play Dwarf Fortress yet. That's what this thread is about. I know I can play with other people at the controls, but I'd rather not have to depend on someone else's mood. :)
-
Oh, well I'm sorry to hear that. Yeah, I agree, there is certainly a severe lack of support for the blind in the games department. I can see why you'd love to be able to play it yourself, having heard many stories from the friends you play with.
Ugh, I hate giving reassurances and not being able to do anything. Have you considered eye surgery?
-
Sadly, fixing my eyes or whatever isn't really an option for me—I was born super early and my optic nerve is the problem. Besides, it'll be kind of impractical and expensive even when the tech does become available, and I've lived twenty plus years of my life without too many issues.
All told I think making a computer game—a complicated and insane one, but still just a game, playable would probably be easier. ;)
-
Well, haha, I don't mean get optical surgery just to be able to play this game! But I see what you mean.
How often do you play (with others at the controls) dwarf fortress? And how did you do it before, exactly? (meaning, how did you manage playing with other people: )
Ugh, I really don't do player counselling. So, looks like all I can say is "best of luck"! I know, even typing it out makes me cringe.
-
On a mac you can edit data/init/init.txt and change the PRINT_MODE option to TEXT and GRAPHICS to NO. It will run in a console as a text aplication.
No it's not supported on OS X.
My bad, the comment in init.txt misled me and it tried it on linux.
At worst, a virtual machine is an option, but that would mean using Orca or another program.
-
Uhm... really interesting topic...
I could have a suggestion, but i'm not a programmer and english is not my main language, so i apologize in advance fir everything stupid i could say.
using sounds to "read" the world seems the way to go, but reading each single cell would be problematic at least. You would end hearing only "grass, grass, goblin on grass, grass, grass".
But, what if you could express what the program is reading not with "read text" but with simple sounds?
An "empty" (grass, soil, stone) could be expressed maybe with a low humming sound, different for pitch and intensity to differenciate maybe stone and grass, and units would be instead expressed with normally voiced text.
Also, to avoid the "hunt that goblin cell by cell" thing, the reading program could use a reading grid that would read, lets say, a 3x3 or 5x5 grid and express the position of interesting things with a "radar" sistem using a surround sound sistem ( a good headset would be more than sufficient, or you could use a 5.1/7.1 sistem).
So i'm figuring...
Your pointer is at a coordinate. You hear a low ambience sound that makes you understand that you are surrounded by stone floors. Another, different sound pointing the north means there is a wall in that direction. A ping in the wesr indicates something interesting there. You move your pointer closer, the ping gets stronger, and when you are directly pointing at it a voiced text tells you there is a dwarf farmer there. Different pings can indicate different thing.
That way you could experience the surroundings without a voice telling each thing.
-
The thing with DF though is that you need to be able to differentiate between all kinds of different materials, the difference between granite and cassiterite and galena is very important, but there's no way you could fit all of the ores and trees and bushes and such into a range of tones while still being distinguishable.
-
Yeah, but you could have a simple tone that tells you it is metal or rock, and a voiced text that say exacly what are you lokking at when you need it.
-
Also, to avoid the "hunt that goblin cell by cell" thing, the reading program could use a reading grid that would read, lets say, a 3x3 or 5x5 grid and express the position of interesting things with a "radar" sistem using a surround sound sistem ( a good headset would be more than sufficient, or you could use a 5.1/7.1 sistem).
I was thinking that instead of having to hunt for the goblins, he could just zoom to them from the units menu. Or maybe he doesn't need to zoom at all -- he really just needs their coordinates so he can picture their location in his head. This would avoid the "grass...grass....grass..." issue.
-
Does it have to be Fortress Mode? We might be able to get something that would work for Adventure Mode, modeling it after the old text-based MUD layout. "You are on grass. There is a goblin marksman 3 squares to the north. There is a goblin spearman five squares to the northeast. There is a raven 10 squares up. On your square there are limestone pebbles, Uzeth Ngoname's corpse, and 10 articles of clothing."
-
It doesn't have to be Fortress mode, I suppose, but I would hate to feel like I was missing a lot of what makes DF unique. I think that's largely a Fortress mode thing.
Tones and other audio cues are definitely something else to consider. They might lessen the cognitive load, so to speak, or at least speed up my ability to process information. I think 80 to 90% of the work is probably getting around the SDL interface issue, and the rest is gravy.
One thing I think works in this game's favor is that it represents 3D space with a series of 2D plains. That helps a lot with conceptualization, because I can imagine, say, a hill or a tree or whatever as being X z-levels high. This is kind of a tangent to the main point, but still at least interesting.
As for playing with other people, I haven't done it in a while, and they largely described things in broad detail and took general orders from me… "Let's dig a tunnel into that rock face," or "Construct workshops at this level," and so on. It really depends on the skill of the person describing, and their familiarity with the game. We use similar techniques to play turn-based games like Civilization. The ironic thing is that Civ is much less likely to become accessible. :)
-
I think a set of simple sounds getting more complex with the detail level is a good start of an idea.
To start, I can tell you is what a sighted player sees, to give you an idea of what combination of solutions is needed.
By default, the primary screen in fortress mode has three vertical sections. The leftmost is the map, the center one is the menu, and the rightmost is an overview map that is pretty much useless. You can turn off that overview map without losing anything important. Some additional bits of information are located around the edges of the screen including the number of idle dwarves, the current frames-per-second performance, the current z-level, and the phase of the moon.
Additional screens are all-text, though some have a vertical scroll-bar along the edge. This should be easy to reformat with DFHack. Some of the status screens are divided into vertical columns which might give a screen reader trouble. Some even have "tabs" along the top, that bring up different sub-screens. This would be more challenging to fix with DFHack, but perhaps not insurmountable.
The main screen is quite cluttered, but I am confident that DFHack could scrape all of the textual data from the game engine and report it in a friendlier format.
The problem is the map part of the main screen. Each tile has one of 256 glyphs, one of sixteen foreground colors and one of sixteen background colors. The tile can also be flashing, meaning it alternates with another glyph with its own colors. The player can use hotkeys to get detailed information about a tile, but the combination of glyph and colors is supposed to tell the player what is going on. I don't see any way of encoding 65536 possible tile images times hundreds of onscreen tiles, but some simplification seems possible without losing the underlying simulation.
The people who make graphics packs for DF routinely alter the tiles and colors used to represent things in the game. There is no reason one could not set all unmined tiles to one specific glyph, all furniture to a different specific glyph, and so on. Maybe have three or four glyphs for creatures, depending on how much clutter one is willing to endure. A simple sound-based representation of that can be the first level of detail.
The foreground color can encode a second level of detail. Among unmined tiles, one color for all soils, one color for normal sedimentary stones, one color for all gemstones, etc.
The background color can encode a third level of detail, which should probably be reserved for state information like "injured creature" or "wet stone" or "designated for digging."
A keypress can be used to interrogate a tile for additional detail, such as the game's current look command.
This map would be difficult for a sighted person to interpret, but easier to convert into sound. I'm not sure what the current norm is in representing two-dimensional structures in sound, but I'm imaging a sonar ping from the cursor with some type of multi-channel sound system. If you want to go all out, folks have figured out how to make the game render multiple z levels, and it's theoretically possible to make that sonar ping three-dimensional.
If we go with the sonar idea, there is no reason to limit the map to what appears on a monitor screen. If one can interpret sonar pings out to N radius, have the game render out 2N by 2N tiles centered on the cursor. A hotkey can be assigned to a DFHack script that reports the current cursor coordinates when the player wants to get his bearings.
All Dwarf Fortress input consists of keypresses, so it should be trivial to configure any input device to control Dwarf Fortress. The issue is that a good number of those commands depend on the cursor position.
By the way, other than the glyph assignments and cursor coordinates script, I personally have no idea how to build any of the things I mentioned.
-
That overview is very helpful. Thanks :) I had some idea of the layout of the screen in general, but it's nice to get more information.
The way audio games in general tend to convey information is via stereo sound. The idea is that you can judge a sound's location relative to your character by how loud or soft it is, and also what direction it's in. Sonar as a concept hasn't really been tried before, I don't think.
I just thought of a good RTS game which I didn't mention before. It's kind of DF-like, though obviously much simpler in scope. It's called Castaways (https://p9.secure.hostingprod.com/@www.kaldobsky.com/ssl/audiogames.php), and it uses a simple 2D grid system. It does, however, have the basic DF-style named characters, job assignments, and so forth. It's also free. :)
-
That overview is very helpful. Thanks :) I had some idea of the layout of the screen in general, but it's nice to get more information.
The way audio games in general tend to convey information is via stereo sound. The idea is that you can judge a sound's location relative to your character by how loud or soft it is, and also what direction it's in. Sonar as a concept hasn't really been tried before, I don't think.
I just thought of a good RTS game which I didn't mention before. It's kind of DF-like, though obviously much simpler in scope. It's called Castaways (https://p9.secure.hostingprod.com/@www.kaldobsky.com/ssl/audiogames.php), and it uses a simple 2D grid system. It does, however, have the basic DF-style named characters, job assignments, and so forth. It's also free. :)
I was thinking that the glyph can be represented by a sound, and when requested the foreground color adds a second sound, and then the background color could add a third sound. They could either play in series or actually be on top of each other, I have no idea which would actually be helpful. The interface issue I'm having is how on earth to represent a twenty-by-twenty grid of these things.
The representation for a marble wall would be, for example, a "w" glyph with a foreground color indicating it is composed of flux stone. Suppose that is color 4, which typically renders as dark red. However, our DFHack renderer reports the 4 as a distinct second sound. To learn that it was in fact marble, you would need to inspect that tile explicitly.
Fortunately, Dwarf Fortress can be told to use two completely different colors for describing an item in text and displaying on it screen with one annoying exception of contaminated surfaces. This means that despite drawing the marble wall in "dark red" for the player, it can actually appear white to your dwarves, who do have have favorite colors.
-
If we want to fiddle with sound-based solutions, playing in sequence is probably better. If we play over top of one another they might tend to get confused.
I just got the current version of DFHack, by the way. It doesn't really do much good right now, but it's nice to have a text console, even if I'm not really sure what if anything I can do with it at the moment. I've also tried connecting to the SSH DF server, but can't actually seem to run a game from there. :(
-
The thing with DF though is that you need to be able to differentiate between all kinds of different materials, the difference between granite and cassiterite and galena is very important, but there's no way you could fit all of the ores and trees and bushes and such into a range of tones while still being distinguishable.
That's in vanilla, but 1. we could have a simplified version, like Accelerated DF mod, maybe simpler, and 2. there could be several levels of details - first, metal sound, then additional information if requested.
And also some way of understanding current position - maybe just coordinates, maybe also with some verbal description.
-
A dfhack plugin could be made that goes through the screen tiles, the way that TWBT multilayer needs to do, and tell you if anything "interesting" is on the screen, aka units, enemy, friendly, animal, etc., and then add keys to cycle cursor over each type, for example Ctrl-1 to cycle through all units on screen, Ctrl-2 for enemies, etc.
A big issue that nobody touched on so far i think is DwarfTherapist :)
-
A question: is that material important at the time it's mined out of the rock, or once it's been stockpiled? This is where the text and look commands can come in handy I think. DOesn't the game stop to announce that you've struck galena, or whatever?
Just wondering how necessary it is for me to know what a given tile of stone is, or more to the point how often I need to know. To an extent the frequency I need that knowledge will help dictate how it can best be conveyed.
-
Playing the base game without DFHack, a normally sighted user would have to look at the stone a lot.
For example let's say you want to mine some galena (an ore of silver), which you discovered when one of your residential tunnels crossed its path. The galena vein is this twisting feature that snakes back and forth across dozen of tiles on the map, but the player initially only sees a little bit of it where it's exposed to the tunnel. Then you have to manually designate each tile to mine, either carefully marking one tile at a time as it's exposed, by digging some more shafts to expose it, or by brute force clearing the whole area in a big rectangle. It's a bit of a chore, and normally would involve a lot of feedback between looking at the screen to see the newly exposed ore, monitoring your dwarves progress as they follow your orders, and using the cursor & keyboard to designate new digging jobs.
Fortunately, in this specific case, there is a command in dfhack called "digv", that is "dig vein". It automatically designates the entire vein for mining without disturbing the surrounding stone, simply by placing the cursor once over a tile with galena and running the script once.
Once the galena is in your stockpiles you don't actually have to look at it as much, you only need to know a few specific bits of info like: how much ore remains in the stockpiles, how many silver and lead bars you have smelted, and whether the stockpile with the galena in it is near your smelter.
-
With dfhack we can do pretty much anything in terms of providing custom UI and simpler ways to do things. Like marking veins and other POIs and then providing a list to quickly jump to certain ore and so on. I mean, again, special simplified edition of DF is better than no DF at all.
-
I guess you have a point. I just hope whatever simplifications are being contemplated they won't undercut the experience too much. I don't want to feel like I'm missing a core part of what makes the game special. Lists, alternative interfaces or whatever are probably just great, it's when you think about removing material types or whatever I get wary.
For starters, is it possible to make DFHack generate a world for me? Since I can't really use the main game interface at this point it would be a good way to begin. :)
-
It is possible for DFHack to know what screen is displayed and pipe the information on that screen to the DFHack console or a file or any application that accepts streams.
When you hit create new world, it would be something like the following. At any point in this menu, you can hit "escape" to abort or "y" to start generating.
Please wait.
World size: Medium.
(Down)
History: Medium.
(Left)
History: Short.
(Down)
Number of Civilizations: Medium.
(Down)
Maximum Number of Sites: Medium.
(Down)
Number of Beasts: Medium.
(Right)
Number of Beasts: High.
(Down)
Natural Savagery: Medium.
(Down)
Mineral Occurrence: Sparse.
(Right)
Mineral Occurrence: Frequent.
(y)
Like I said, just about the entire game can be put in a text format. It's the map that gives me pause.
To start, we can certainly simplify the menagerie of stuff in the game with a small handful of types for each thing. One or two materials of each type, one or two domestic creatures, and so on, just to work the kinks out of the interface without overwhelming the playtesters.
-
...it's when you think about removing material types or whatever I get wary.
I wouldn't worry about removing material types changing much gameplay wise, there are SO MANY different materials that their sheer number makes them cumbersome to process. What happens in the mods is instead of displaying "limonite" or "magnetite," they display "iron ore" and all regular stone is called "stone" and all flux stones are called "flux stone." The only visible difference between many materials (especially stone) during gameplay is the colour. Weight also varies slightly, but not so much that dwarf travel time is massively changed.
tl;dr: Don't worry about removing materials, there's too many anyway and the rocks don't matter unless you're a geologist.
-
In that case, I withdraw my objections :) You have a point about making something I can easily playtest.
-
This is some amazing stuff we have here.
Bay12 is a awesomely weird place. Puppy falls in dwarf mode and DFblind in general discussion.
-
Hrmm. A thought. As I understand it, something that could have issues that come up is that DF also has vertical levels as well as horizontal levels. But then I had a thought. Some rather fascinating shenanigans still went down in the earliest, albeit simpler days of DF(Boatmurder) Taking one of those builds as something to work off of might eliminate some of the difficulty of the current build.
Merp. Speculation.
-
I don't think the vertical levels are as troublesome as all that… It's a simple enough concept for me to grasp, perhaps surprisingly. I think of it kind of like a camera, for lack of a better way to put it, looking at portions of, say, a hill or what have you. As I understand it, you have to build connected stairways or ramps to travel between levels anyway.
I'm not discounting Boatmurdered. ;) I loved reading that even if I couldn't see the screenshots, I just hope we can work from something more recent.
-
To correctly make Dwarf Fortress Blind accessible, the proper technology would have to be used to both allow the player to communicate to the game, have the game communicate to them, allow a non confusing way to understand what is happening in the game, and allow the player to make changes in the game ALL at the same time.
I think using a Refreshable Braille Display (though expensive) could allow for a better way to reference what is currently happening in the game during pausing. You do need to know what you have done and have not done... and pausing the game should allow you as the player to take in more information. This would allow the player to see what their fortress currently looks like, to feel what is currently where... and give some mental perspective with what is occurring. Since DF is all text based, it should be theoretically possible.
Going forward with more theory... it would be nice if someone invented a magnetic metal pad, with separated cells, that instead of raising off the pad mechanically... could raise and provide vibration through magnetics. If the pad cells were filled with a Ferrofluid, the fluid could form small circles depending on on a metal pad below. The magnetic field would have to be very well, and its likely the ferrofluid would have to be responsive more so to certain levels of vibration to help with the magnetic containment.
-
This is a more specific case of what is sometimes described as "decluttering". In human factors research, it's well known that when people are under stress (such as fighter pilots who are being shot at), they need an interface that is aggressively streamlined to just the minimum information they need to do the job at hand.
It is sometimes useful to talk about the bandwidth of an interface. The human visual system is by far the highest bandwidth interface a standard person has, easily capable of distinguishing two spatial dimensions (X: left-right, Y: up-down) and depending on definition, one to three colorimetric dimensions, with partial/synthetic information on a third spatial dimension (depth), and a temporal dimension (the "optical flow" analysis built into our wetware is quite sophisticated).
Audio is usually considered the second highest bandwidth; it has partial / synthetic information on two spatial dimensions (radial and elevation, loosely), intensity (which may or may not reflect distance), "color" (tone), and some better temporal processing, including some fairly interesting waveform processing that allows us to perceive harmonics, beat frequencies, and the like.
So, Dwarf Fortress has a famously cluttered interface. On the one hand, we want to dramatically pare down the information it tries to present; on the other hand, we want to present the crucial information in as usable a fashion as possible.
For the first, as noted already there are mods designed to reduce the internal variety that doesn't directly affect game play. For example, instead of a bin containing 3 dog leather, 5 naked mole rat leather, 1 bat leather and so on, these mods simplify the raw files so there is only one (or very few) sorts of leather; the bin might simply say 26 leather, which would take a screen reader far less time to read off. These are usually designed for people on low-memory computers, but should be adaptable for your purposes.
There are also settings in the init files which will help, such as not randomly varying the tiles used for the ground; personally, I find that looks cluttered even with good eyesight and turn it off.
From the other perspective... it seems logical that the fast way to scroll around would need to have a preview that is tone based. Perhaps a scale that ran from low pitch tones to high pitch tones something like the following:
* Open space
* Water
* Grass, dirt, snow, and other natural floors
* Rough stone floor
* Smoothed stone floor
* Engraved stone floor
* Solid dirt
* Solid ordinary stone
* Solid flux
* Solid ore
* Building, construction, etc.
* Your dwarves
* Tame / trained animal
* Traders, guards, etc.
* Wild animals
* Hostile mundane forces
* Megabeasts, necromancers, forgotten beasts, and other special problems
* Magma
Ideally the interface would allow you to quickly scroll around the map, listening to the tones, and then pause the cursor when you got where you were going; the tone would fade over a second or so, and then read the contents of the square to you. This would allow such activities as exploring the edge of a river or cliff audibly, and particularly aid in finding things that are significantly different than their surroundings.
So, instead of it having to read out loud:
Grass. Grass. Grass. Sandy Loam. Grass. Yak. Grass. Goblin Archer.
you might have:
do do do re do fa do ti
If you were interested in a dual-tone systems, either left vs. right ear, or as two-tone chords, you could do some more sophisticated discrimination, possibly combined with octaves. Perhaps the left ear could play a tone based on the floor type, and the right ear play a tone based on what the tile was occupied by (air, stone, goblin, barrel of booze, whatever) ; in the case of solid stone, they would be the same.
I'm not the right sort of expert to design the "audio browser" software, but I don't think there's any fundamental reason it couldn't be done, and DFhack may already include most of the software hooks that would be needed. Or possibly, and somewhat ironically, 3D viewers such as stonesense; the underlying task of taking the Dwarf Fortress screen info and presenting it in a different medium is similar. (You could even look at it as a 1D viewer.)
-
Great idea. It would be awesome if you could have that and somehow put the screen into braille >.>
-
That theoretical discussion was superb, Miuramir. Thanks for outlining things…
Unfortunately I'm not an expert of any sort. I can provide feedback on anything someone might be willing to slap together, but I don't know enough about DF or audio to do much myself. I've thought about looking at the DFHack API to see if I can do anything, but am not sure how friendly that would be to someone who hasn't written a substantial program before.
So I hope we can find someone who either has such experience already, or is willing to experiment. I wish I had more substantive ideas to offer, but I'm afraid I'm fresh out right now. I have faith that something can be done, though.
I appreciate the enthusiasm and interest shown by everybody on these boards. Thank you, Bay12.
-
I would love to help with this and get you in the game but I don't have the technical background to really contribute much.
It is good though to see the DF community coming out with so many ideas and suggestions.
-
Currently least clear for me is how to implement map navigation. This is directly related to the question, how much information you can keep in your head, and how your "current position" should be represented - as absolute coordinates, ie. currently you're at (30,11), and you remember that main entrance is at (14, 20) and so on. Or relatively - you press a key and hear "your base is north-west 10 tiles, gold ore is to the east" (you first define such landmarks). Or maybe something else, well, I never tried to play with my eyes closed and to remember where is everything, so probably you have better understanding here. Small and micro embark areas are possible but that's still a lot of tiles, and even more z-levels.
Currently I'm working on a project not directly related to this topic, but which will greatly help here as well when finished. I can't tell more at the moment, but anyway the map and navigation is the most difficult part to do.
-
The problem with Dwarf Fortress's map is that it is very dense. Even a simple flat outside area is a mixture of grass tiles, shrub tiles, trees, and boulders.
So having each type of tile emit a sound from its location is just going to be an awful lot of noise on a twenty-by-twenty map. Reporting one tile at a time won't work either because individual items you need to place can be up to five-by-five tiles.
I think it might be possible to have an adjustable "hearing range" around the cursor. That allows for sweeping large areas to search for tiles that are different, then focusing down in cluttered areas.
I thought it might be helpful to be able to filter out specific sounds on the fly, such as toggling off the sound for floor tiles. That could get confusing unless the settings were very obvious such as on a Braille board. Having the toggle simply lower the volume of that type might work better, but I have no experience with using this kind of interface.
I would not worry about getting lost in the map. The game already supporters assigning function keys to specific locations, and there is already a clunky system for putting a note on a tile. A hotkey to report coordinates would be easy as well.
-
To correctly make Dwarf Fortress Blind accessible, the proper technology would have to be used to both allow the player to communicate to the game, have the game communicate to them, allow a non confusing way to understand what is happening in the game, and allow the player to make changes in the game ALL at the same time.
I think using a Refreshable Braille Display (though expensive) could allow for a better way to reference what is currently happening in the game during pausing. You do need to know what you have done and have not done... and pausing the game should allow you as the player to take in more information. This would allow the player to see what their fortress currently looks like, to feel what is currently where... and give some mental perspective with what is occurring. Since DF is all text based, it should be theoretically possible.
That's what i had in mind. There are limited characters on such a keyboard, but the hierarchical layering of symbols under broad situational categories could help. Still, if it is beyond reach of most blind people we're back to square one, and i admit it's not by itself a elegant solution.
-
Sadly, even if a cheaper display were available, you need a screen reader to interface with them, typically. The way most of them do it is braille what's spoken, with custom support for special cases sometimes. It's more trouble than it's worth I'm afraid.
That being said, I'm intrigued by your secretiveness, mifki. :) I wish you every success with whatever this project is.
-
Sadly, even if a cheaper display were available, you need a screen reader to interface with them, typically. The way most of them do it is braille what's spoken, with custom support for special cases sometimes. It's more trouble than it's worth I'm afraid.
That being said, I'm intrigued by your secretiveness, mifki. :) I wish you every success with whatever this project is.
Yeah, mifki had a strange mood that produced the Text Will Be Text plug-in, and is now a Legendary Understater.
Given the expense of Braille boards, it's not feasible to stack a bunch of them to depict the map. But one could still be an indicator independent of the reader. Something like continual display of the cursor's coordinates, or some status toggles, or the title of the current screen. A real attempt at an interface for the blind should not depend on specific specialized hardware... but there's no point in ignoring it if it's there.
-
I hope that this succeeds! I'm no coder and have already been mind-blown by trying to imagine true blindness and how that changes the ways you interact with things.. Concepts like color perception.. anyway! I thought I'd link this here, just for its informative value (plus the guy is awesome..): https://www.youtube.com/channel/UCld5SlwHrXgAYRE83WJOPCw?spfreload=10 A link to his youtube channel..
Through my mostly useless brainstorming on the concept of playing a game with no visuals I've started to think of an all-audio game.. It'd be a roguelike, of course, with randomized equipment, monsters, quests and map gen and character building.. You would start out in the center of a 3x3 grid with the option to travel in any cardinal direction (some could be blocked occasionally as well, depending on location), and as you walk new areas are created and areas outside the 3x3 grid are 'unloaded', so you can never go back, but you're also never lost.. New towns would generate (they'd be a randomized name plus shops and quest givers) and quests would reward on completion so you wouldn't have to return to town, dungeons would teleport you out on completion..
The basic idea is to add plenty of mini-events that have good, bad, and neutral outcomes to influence which direction you travel, like hearing a rustle in the woods that may be a hidden enemy, or nothing, or a friendly NPC or quest-giver hiding in a bush.. Or seeing the glow of a campfire could lead to a recently-vacated campsite to rest at, or a merchant or other traveler, or a group of scruffy goblins standing over a couple dead humans) Each feature that would normally use a UI (equipment, stats page, level-up page) would have a very clear and easily accessible audio help command that quickly details the available options..
And then imagine integrating a Dwarf Fortress-clone combat targeting system..
Patrick Stewart or Micheal Caine can do all the voice acting.. ;) Just imagine Jean Luc Picard saying, "You slash the giant swamp leech in the body with your elemental serrated broadsword of plasma +14 and the part disintegrates. Your foe falls and the battle is over. You gain seventy-three experience points and need two hundred and seven to advance. Your skill with broadswords grows and you feel more competent."
Is there anything like this out there already, roguelike or otherwise? And if not, then why not? Its no more complex than interactive 'choose your path' books, just out with text and in with spoken word (and a focus shift away from storytelling and towards loot/level-ups/monster-killing).. If ascii graphics are attractive to devs for their ease of use and simplicity, then what is there to say about no graphics? :)
I don't want this post derailing the glorious goal of this thread at all, though, just wanted to throw the idea out there in hopes that it may inspire someone who has the power to create it (and without starting an odd thread about an all-audio game out of nowhere)
-
Some of these more complex ideas sound great, but I suspect zkline would be pleased to have a simple mod that just used the Mac's VoiceOver feature to read off what was on the tile. It's not the best solution but it seems like it would get him started and also give him the ability to provide feedback on what works and what doesn't, what is useful and what isn't.
-
Yes, exactly. :) I'd love to start with a simple solution and work upwards from there if needed.
The problem right now is that the interface isn't really useable for me. I would love to see the text mode implemented in OS X, perhaps, or at least a way to get started on the world generation and embark process. I feel like starting simple is probably more practical anyway. We can always build up.
-
It seems to me that if DFHack/VoiceOver combined could read aloud what was on the menus and whatever is revealed by K on the map tiles, that it would be enough for you to go in and start fooling around with the game. It would be crude but it would work. And then, once you got an understanding of how things are laid out, you'd be in a much better position to start suggesting better, more workable solutions.
EDIT: As far as embarking goes, it would be easier for one of us to create and send you a nice 1x1 embark to start with. Later on we could think about how to set things up so you can do your own embarks. But I suggest keeping everything dead simple for phase 1.
-
I think the most basic version would also require a way to read out what screen you're "looking" at, too. (For main screen, it should say the Z level you're on). Also, the menu reading should have two modes: one which reads everything, and one which reads only what's selected. And there needs to be a quick and dirty way to see if you're paused or unpaused, because yeah.
How moddable/expandable is the logging on DF? SoundSense already plays sounds based on log events - would it be possible to log the user's keypresses or the text on the screen? That would make a basic version trivial to implement as a SoundSense pack.
The vanilla Hotkey system seems like it would be a boon for blind players, and expanding it could be extremely helpful.
The existing DFHack prospect tool could also be very useful, if you added ways to filter what you're looking for to avoid information overload. An interactive prospect tool could let you select the e.g. ore you're looking for and zoom to it.
-
This is an interesting problem...
I'm going to ignore a lot of problems, and assume some solutions have been found. Lets assume we have a utility to print the map, contextual game information about each tile may or may not be imported, and its implementation shall remain abstract.
There is a serious problem about how to, in as few words as possible, describe the scene. If we could provide a description of the scene, we could automatically create points of interest, which is very much what our eyes do, skim through the details. What about something like a 2D regular expression engine? What I mean is a way to define 2D shapes that can quickly be searched through the map, and match to specific phenomenon. Workshops and multi-tile buildings are a good example, geographic instances such as rivers or more complexly, hill slopes and canyons. Instead of playing a tone or saying "grass" for each tile just to express the map, we could have a few words spoken about that hill, those goblins, the bridge, and that forge. It wouldn't negate the need to vocalize tiles with the look command, but it would reduce the tedium involved with painting the scene.
There are details to argue about, such as having different "views" for the vocalization of the scene. Maybe a geographic oriented "view" that specifies all geographic phenomenon in explicit detail, such as shape of the hill, height, distance from other hills, distance from cursor, angles involved, material covered in, etc...
"There is a hill covered in grass approximately 30 tiles northwest of the cursor. It is 8 tiles high. It is 20 tiles south of a canyon that runs east-west The canyon is approximately 55 tiles north of the cursor."
A threat or unit view that generalizes groups of units, their general location from the cursor, their general location from nearby units or groups of units...
"There is a pack of wolves approximately 90 tiles east of the cursor. The pack of wolves is 15 tiles north of a sheep. The nearest dwarf is 120 tiles northwest of the pack of wolves."
There could be other "views," even a general view that tries to stitch together details from all of the views. Maybe even levels of detail. And I think it would be very important if each pattern were parameterized and named when a view is vocalized, and their "name" could be used in conjunction with some menu/hotkey to move the cursor between them. Maybe even an option to save the "name," because it might not be saved when a view is vocalized again. That way we could easily switch back and forth between our militia and the invading goblin squad, or quickly switch between workshops and that hill you're building a tower on.
Another useful feature would be flood functions. Its annoying to find the whole in a wall you thought secure when you can see. It would be useful if we could perhaps set to flood markers, and see if they can touch each other, as well as trace the route between them. That way you could set a marker outside your wall, and inside your wall, lock up, and see if there is a path. If a path were found, it would be vocalized, and there would be an option to trace along it. Perhaps, for the sake of geo-spatial recollection, the tracing function would force the cursor to stay on its path while tracing, but would allow the user to use the number pad to manually trace, having a tone for a successful trace, and a tone for choosing a wrong direction. In addition we could have a similar feature allowing you to "look" at the surrounding tiles without tracing (or failing to trace) there.
Example: A marker is set outdoors, a marker is set indoors. The pathing function states there is a path.
Example continued: Curious where the path is, the player uses a hotkey, and the tracing function begins. Using '.' it traces to the next tile, using any of the 9 keys on the number pad, it attempts to trace in that direction. The player hits '8' repeatedly taking the cursor north (towards the entrance) until it fails to trace north. Curious about whats in the way, the player "looks north" with alt+8, and sees a tree has sprung up in the walk way. The player, not caring about it at the moment hits '.' to skip past the tree, then continues north with '8'. Eventually the path veers to the west, until after 9 tiles west from where the path veered. a diagonal path is found through the wall.
-
Unfortunately, yes, sound does suffer from that limitation. Somebody mentioned an interactive fiction-style interface in the original thread, I don't know if it was mostly intended as a joke. Text overviews of what can be seen are another way to go, I suppose.
I suggested an interactive fiction style in the original thread. It's a long term goal.
I do have a suggestion for a possible quick fix if you're up for it.
As discussed before OSX can't play DF in TEXT mode but you still can sort of. The idea is to remote login to DF running TEXT mode in a tmux session on a linux box. Hopefully VoiceOver can read terminal. Setting this up might take some time depending on you computer skill level.
tmux it's a terminal multiplexer enabling a number of terminals to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached. But tmux more than create a persistent DF game in TEXT mode to access on your mac.
tmux allows multiple clients access the same session viewing the same output and interact in real-time. This will allow collaborative games to be played. In addition to a fun game with multiple human player clients. A non-human client can connect to session to screen scrape data to assist game play.
The long term interactive fiction idea is possible if you are scraping data already. Counting the number of leaves/tree trunks, ore, gems, workshop, natural formations, characters, creatures and be able to put a description together based on % and location of those tiles on screen.
Non-human clients can send inputs too. Putting together a more verbose description than you'd expect.
Take an example starting fort. The computer client moves up and down a few z-levels sees the trees are in fall colors and see they are pears and cherry. Scans back and forth with look noting which dwarves are on screen, references the units list for their current job. A quick check the status screen for the date/stats and you have a story if you fill in the gaps.
Composed it's something like this; It's Mid-Autumn on the 11th of Sandstone in the year 250. Two groundhogs are in the North under the dense cluster of pear and cherries trees which are in in their full autumn colors. Fath the Miner is sitting idle while Onol the Carpenter is in her workshop making barrels. Tun, Fikod, and Uutok are busy storing items. The Broker, Zasit prepares so see off the caravan before the winter closes trade routes. But all is well in Shootdabbled because food and drink stores are strong.
That's a long term goal for now lets see if VoiceOver plays nice with terminals. First is setting up the linux box. If anyone has a server they can setup DF on that would be awesome. Otherwise it's a virtual machine on mac or possible installing linux or running it off a liveUSB install from a old PC.
After thinking more there are probably better ways to do all that. This wouldn't be a bad first step.
-
That sounds intriguing at least. :) VoiceOver can read Terminal well enough. I haven't touched Linux in quite a while… if anybody else is up for setting up a server I'd be much obliged. I think there was already something like that over ssh, maybe using a custom hack of Gamelaunch? I can't find the thread this early in the morning.
-
So what can be done first? Don't want Zkline to wait another three years before anything happens
-
I used to play Achaea, a MUD (completely text based game), a few years back and I know several people that had incredibly well-known characters are blind. The reason I mention this, is because the Wilderness maps look and act basically like the DF world map. I remember when seafaring was introduced a person was complaining about the waves ^^~~~^^ yelling at him. The combat is also very complex, real-time, no pauses, PvE and PvP. Tanris used to be insanely good, top headhunter if I recall correctly. Sailing is also impressive, as it involves navigating a changing maze of waves, that read like DF (ASCII style).
I thought I recalled a discussion on the programs used, but it has been seven years or so, so it's going to take me a while to see if I can find it again (no promises). Regardless, the fact that it can be done might be a starting point at least. Lusternia and Imperium, also made by Iron Realms, similarly have visually impaired folk who play them. Best of luck to you.
-
I used to be a god in Achaea. I wouldn't recommend the IRE games since Jeremy took over though.
One of the other gods was blind actually. You need a reader, they are not cheap. But it works because the text can be read. I can't think of a way to make it work with an ASCII game.
-
I've played IRE games off and on before, never had a lot of interest in going long term, but I know they are popular among a certain set of bind people.
As far as ASCII games go, I've had great success playing NetHack, Adom, and other rogue-likes with screen readers. I think the basic principle is sound. The pausable realtime nature of DF makes things harder as we've seen, but… :)
Has anybody been able to set up a lInux server by any chance? I can at least try that in text mode and see what happens.
-
The IRE games are, imo, the best of the MUDs I have played. I say that will minimal fond memories after leaving, and while advising people avoid them.
Achaea is particularly toxic. We had a blind player (incidentally) who three known griefers plotted to rape IRL. The producer merely gave them a stern talking to instead of, you know, deleting their characters and banning their IPs and reporting them to the police. People overheard this stuff too, and though later some of them went to the blind player and apologized because they heard it, they never spoke out publicly about it. That was the kind of behavior in Achaea. There were a lot of players I liked interacting with, but there were also a lot of bad apples.
I played Aetolia and Lusternia for awhile. I loved Aetolia, but the population is small, and getting a functional "system" is almost impossible. People want you to pay money for absolute garbage when you are used to the systems available in Achaea.
Lusternia's problem was that there were only a few select ways to steal, and everyone acted like it was griefing. I love playing a thief, that's my thing. I'll ransom most stuff back to people, I just want to steal and be hunted. Plus, the system for handling cause facilitated pvp less than the mark system from achaea, which I found preferable. Population, ability to steal, and mark system were the highlights of achaea and the only redeemable factors imo.
-
http://smf.cataclysmdda.com/index.php?topic=8042.0 Thought I'd leave this here.. A post from the CataclysmDDA forums about a MUD game called Infected, which specifically mentions that it was made with limited-sight usability in mind :) Figured I'd throw it out there, in case it sounded appealing and you hadn't heard of it..
-
Hi zKline,
I'm sure you'll figure this out soon enough. I personally think webfortress is your ticket to ride. You can check that thread out here: http://www.bay12forums.com/smf/index.php?topic=144956.0
The reason I bring up webfortress is because you can get just about any bluetooth refreshable braille reader to read off safari. With that reader you should be able to skate up and down the display as much as you please. Menus, maps (if web fortress is using alt attributes)... all of that would be accessible to you.
Another option though is using an older version of DF that does still support TEXT output to a terminal. BRLTTY has full ASCII support and plugs into refreshable braille readers too. Really doesn't matter how many characters output at once on the screen -- a cheaper 18 or an ungodly expensive 40+. The older version of DF is still fun... that's why we are all still around; it only got better. :)
I personally don't think you'll have any issues interpreting the maps eventually. Holy cow, it took most of us quite a bit of time to decipher it ourselves before more sophisticated tile sets came along.
Also maybe one of these tileset geniuses around here could build you an ASCII-128 tileset. I'm not sure how far back version-wise you'd need to go or even if the characters were hard-coded. It's been so long, someone else who remembers may need to chime. Who cares if some of the letters are repeated. I'm sure with some imagination it could be done.
-
Hey, thanks for the WebFortress info. :)
Initial inspection doesn't seem too accessible—I see the chat interface and a frame which VoiceOver/Safari seem to think is empty. I think that's probably the game screen, and I can't get anything out of it.
Perhaps it really is empty, but I suspect what's going on is that it's using Flash, or some other technology. I'll keep poking around,but am not super optimistic.
On an unrelated note, a blind friend has suggested to me via Twitter that the DF mac UI has suddenly become at least a bit more accessible. He claims to be able to go through world generation at least. I'm not sure why. I need to download the newest version, I guess. :)
On yet another unrelated note, happy Dwarven thanksgiving. This is the day we thank the high programmers for all their work in bringing this game to us. :)
-
Initial inspection doesn't seem too accessible—I see the chat interface and a frame which VoiceOver/Safari seem to think is empty. I think that's probably the game screen, and I can't get anything out of it.
Perhaps it really is empty, but I suspect what's going on is that it's using Flash, or some other technology.
Sorry about that. That's too bad. I honestly hadn't checked it out myself but it looks promising.
I don't know how savvy you are with programming, but what you really need is create a dfhack braille module. The Rendermax plugin changed the game here with dynamically replacing graphics in the game. Other plugins like TWBT have move forward with this to do a lot of amazing things. The code is there for review, but it seems to me it could revised to override tileset data with a custom translation into ASCII-128 -- that is, replacing all the extended ascii with true-type. It may or may not be a big undertaking. This technology has progressed so much just in the last few months I am way behind. It seems though braille could be an option that can be turned on via TWBT.
-
Here's a project that might help: http://www.bay12forums.com/smf/index.php?topic=145944.0. It's a remote interface protocol for DF.
-
I'm sure you'll figure this out soon enough. I personally think webfortress is your ticket to ride. You can check that thread out here: http://www.bay12forums.com/smf/index.php?topic=144956.0
Webfortress is based on Canvas element, it's not more textual than the original DF interface and will not work with screen readers.
-
Wow, when I read about this I just had to register as a user. Hey all!
I am no programer, but I find things like this intrigin. Being able to play DF blind won't be an easy task, but after reading I might have a suggestion.
When I first heard your problem I thought "How to do this?" My first thought was of Lego. But having someone build you a lego model of every z-level in
DF would be kinda of insane. Not to mention it had to be updated every "tick".
Alot of people have been going on the sound way of doing things, me I googled the Braille board and think I have a solution.
Now be warned, as I said I am no programmer so I can't help you make the program, but from what I read it can display about 40 characters and
uses a 128-bit interface.
Dwarf fortress uses extended ascii, wich is is alot more, BUT, there is the graphical tile set. Nobody said it had to display small
images of dwarfs, nor that it had to display more then 128 diffrent items, even if there are alot more.
Now before I ramble to long, let me ask you, how does your Braille board display its text? Is it 1 row 40 charecters or is it more like
4 times 10? Since you can't see whats comming I will give an example, I take for granted that if you highlight a piece of text it will be able to display it.
So for example:
A B C B A *newline
B C A C B *newline
C A B A C *newline
B C A C B *newline
C A B A C *newline
End example.
Could it display this, or something simular to it? It might not be a lego model, but you should be able to "get a feel" for the fortress this way.
As long the Braille board displays two rows or more of text it should be doable, hard, but not impossible.
Now once we know if it could display a 10 by 2, 10 by 3 or even better a 8 by 5 area we will be cooking with charcoal.
I head that a couple of years ago someone developed a bot for fishing in world of warcraft. The metod it used was that it scaned the screen for
the float and then monitored it, and once there was a bite it clicked it and pulled it in. My thought is to develope a program that uses a tileset and then displays it
on the brille board. Now what about menus and the like I hear people ask... wait for it.
Also what about the fact that there is over 100 diffrent types of rock? Thats is what we are going to solve first.
A tileset i basicly a 8 by 16, or something like that, pixels of information. First, color code the first pixel... (ehh, just figured you probably don't have a clue what colors are, so when I mention colors please think of shaped like triangle or circle or the like instead.)
First color code the first pixel, lets say Red. That means that every tile on the screen will form a grid, this would be used to sync the program to your display. After that put in a color for each typ of tile, animal/dwarf/craft/stone. By hotkeying these you could filter out alot of information. The brille board will display something like:
G for grass, U for unit and C for crafts. Once you find something you can hit the hotkey and get more detailed information. Example you find an area that is S S S S S and the next row is the same only lowcaps s s s s s. Hmm, just figured I don't know if a board can display big and small cap, ANYWAYS, the next row could be F F F F F instead. S for Stone and F for floor. You now know that you have floor tiles and to the north of them you have a stonewall. Pressing the hotkey for stones. The first row, S S S S S. Would change to G B L O E. Wich would translate to something like Gold, brtium, lignite, ortheclas and galena.
You will only be able to "see" 40 tiles at a time of your fortress, but I it is the best I can come up with. Oh and even if DF shows extended ascii, there is nothing that says that the tileset can't have the same image for 2 diffrent objects, with the color code and hot keys it would still be filterable, (don't know if thats even a word, but I hope you get my point.) Combine this with SoundSense to play sounds to match the text. It plays, for instance, combat sound when there is a fight. Once you hear this you can press "A" on the keyboard and bring upp a text list that tells you exactly what has happend. (and for the non blind people, this text would be read by a text to speak program or the like, just like this text is). Then zoom to the location and you should be able to see something like G D U G G translated to Grass, dirt, unit, grass, grass. Once you hit the filter key it might tell you that the U for unit really is a Dog. scroll around a bit and you might find another U and once filtered it will tell you that this is a dwarf.
Units and objects in dwarf fortess can overlapp, but even if you can see, we can't see whats in a pile of units or pile of crafts without looKing at it using a hotkey. However the game tries to fix this by changing the displyed item every now and again, no reason to see why your board shouldn't be able to do the same.
Now that I think about it, this isn't to diffrent then what the StoneSense, or what ever the plugin was called, did. It took the info of dwarf fortress and dispalyed a isometric image of the plane, this should in theory be simplier. Skip the part of a program that read the screen info for you, if there is a program out there that can read the dwarf fortress and display it already, it shouldn't be that
hard to change what it displays. Instead of showing a isometric tile of dirts it could display a D instead... add on top the filter to show for instance "s" for all stones untill you change to a what kind of stone filter and you should be able to "see" the world, so to say. Alsong as it only shows 40 tiles worth.
The problem as I see it would be that the program that "talks" to your brallie board would have to be a background application so that you still could move around the fortress with one hand, as you look on the fortress with your other. (Please don't say at this point that you are one handed aswell as blind...)
Do we have the dev of StoneSense here somewere? oh, and another programmer that would be willing to change it to only display 40 tiles and implement a filter on top of that?
Once that part is done all that is left is the menues and embark part. The menus will need to be linked to an output that makes it text that is either read when highlighted or printed on the ballie board.
Once you hit the button for a menu it could display the menu, and once a tool or option is selected go back to the view of the playfield. I see no reasonto why one shouldn't be able to access the data of a for instance the fortress stockpiles when you can access the info on what animal is on what tile.
AS for embark. There is a "the search", tell it what type of area you want to have. River, Aquafier and so on and search. Here non blind people see 3 maps, world, area and local. The world map will be hard, but the area map and the local map should be rather easy, if I ain't totaly wrong the small world map is the same as the area map. After all there is only so many tiles. Once you have searched the area map will show recommendations, this would be rather simple since the tiles that has them will change to to an X every few seconds, and finding it will the board shouldn't be hard. Then once you have the area in question, press the filter button to change to the local map. There arn't that many tiles and the info text displays all you need to know, it will take some time, since it will have to tell you what the area that is currently marked contains. Like this area is cold, has savage beasts, contains clay and a river.
It will take time to get an understanding for what is what, granted, but that is something everyone has to learn as they start playing dwarf fortress.
Now I only wish I was a programmer so I could help make the program for you, but sad to say I am not.
I am sure that would there be a way for me to do that, I would capture the whole blind gaming community.
I hope my long rant can be of use to you, and that what ever text-to-speech or what ever will be able to translate my poor english into something understandable.
We all have our problems, and there are solutions for all of them, if we only can find the right person to help us with it.
Best regards.
The Row.
-
Hey there. :)
I hate to deflate possibilities which seem good on the surface, but the Braille display doesn't display more than, in my case, 40 characters at once. It can display text from two physical lines at once, but it separates them with a special "new line," character which in itself takes up one spot on the display, if not more. I can "pan," the display along a line of text which lets me move the viewing area, so to speak, but keeping position in a case like that is hard.
On a more positive note, I finally decided to set up a Linux virtual machine to experiment with DF text mode. I've just generated a world. The next step, I guess, is to either get DF hack running on the VM, or to connect to the VM via SSH and see what happens. :)
-
if it's not rude to ask, how much did the braille display cost you? Those things can't be cheap.
-
Not rude at all. :) You're right, those things aren't cheap.
My display cost $3,000, but thankfully the rehabilitation organization in my state was willing to get it, in the interests of finding me a job. It's hard to get the bureaucracy to work, but sometimes it does. :)
So I connected to my Linux VM from the Mac, and ran into a small problem—the Mac reads all the characters properly, but it's hard to get them to shut up. SO I hear something like "full block, full block, full block…" "unequal to," etc. It's better than my native Linux screen reader just saying "null," over and over. ;)
-
TheRow here again.
Aww... to bad. I was hoping the board would be able to act as your eyes on this one.
Nice to hear that you got the VM up and running thou.
As for "full block" I think thats actully a tile. I am impressed by the fact that the reader can even ID that symbol. But I can undersstand that it will take foreever to hear a screen full of symbols.
Since the board idea I have didn't work lets look at the current system you have up and running. It sounds like (no pun intended) that you can now see/hear the playing field? Correct me if I am wrong.
If this is the case, there might be a way to speed it up by replacing the reading program with a music one. I do belive someone suggested it before with a Do, re, me... and so on scale.
I usally play the game with a tileset, so I don't know for sure what full block represent. But my question is, since it seems that your "reader" can read alot of diffrent objects it might be able to read notes, as in music sheets. One idea that struck me is that it might be able to change the font to a music sheet, meaning that the game will instead of reading questionmark, quotetationmark and so on read the muscic tone De, Re, B flat and so on. I found one called MusiQwik font Created in 2000 by a Robert Allgeyer at this adress http://www.fontspace.com/robert-allgeyer/musiqwik . Go to the site and "see" if it is possible that your reader can read sheets of music, and we will see what we can cook up from there. It might be so simple as to replace the font in DF with a music sheet one. However I might be totaly misstaken about how the reader "reads" most likley I am, since if I made a reader I would have it read the ascii-table and not the ascii-sign shown to make it compatible with alot of diffrent fonts. but it is worth a shot, you never know what kind of person programed the reader. As I said before, I am no programmer.
If this doesn't work, we might be back to the point were the most realistic way to make this work is to have some kind of interpeter program read of the the symbols in DF and convert and maybe even filter them to something more usefull.
This project might take time, but if you are used to bureacracy then this should be a brease.
Best Regards TheRow.
-
The "full block" is character 219, which is used for the border around the edges of the screen, tiles that have been designated for digging, ice walls, and part of the Trade Depot. So when you hear "full block" eighty or so times, it's the top or bottom edge of the screen.
This points to an issue that tileset makers have dealt with for a while: Dwarf Fortress is so detailed that even a set of 256 characters requires re-using symbols. I'm pretty sure that one of the tasks will be to come up with a simplified set of raws so that things can be represented at a summary level in sound or Braille. For example, "q" for any quadruped creature with foreground and background colors to distinguish specific types. From what zkline said earlier, sequential sounds are more useful than chords, so maybe every tile in the radius-5 region around the cursor emits stereo-located sound for the main tile character, and the two follow-up sounds are only for the tile under the cursor.
We have a lot of flexibility is assigning the tiles and colors for most game items, but several things are hard-coded. Water and magma have fixed colors we can't change, most workshops have hard-coded tiles, all night creatures have a tile of Ñ, and some creatures are procedurally-generated with random letters and/or colors. If we use a stock tool to read the screen, we simply have to put up with occasional random bits. Anything that will render in sound is going to be custom-built, so it should be better-equipped to render strange things.
-
And by the way, $3000 for a Braille board?! It seems impossible that these cost more to make than the computers attached to them. I remember back in the 1990's that a TDD cost several hundred dollars, but the relay services started to accept 110-baud terminal connections from PCs and gave TDDs real competition for the first time. Now they cost about $75 and come bundled with a lot of extra features.
There is some interesting work on 3-D displays that are effectively pin boards controlled with solenoids. Those happen to be able to display Braille, and may be the competition that Braille boards need to get reasonable prices.
-
The area I found all those full blocks was actually the embark map. It made the region selection process difficult, because even telling the mac to ignore punctuation didn't shut up the announcements. I guess it doesn't consider fancy unicode characters to be punctuation in the traditional sense.
It's more progress than I had before, at any rate. :) The tricky thing is that my Linux screen reader has better terminal navigation—it keeps its position when I move up and down from line to line, for instance, but the Mac reads the default character set better.
So it's a start, in some form. :)
-
Do you know if there's a way to make the screen reader output to a text or markup file, instead of to a sound file/to system out-sound? If we could get the map written into a text file then we could do some neat stuff. Letting you read out a summary of only what's changed, for example.
-
THeoretically, yes. The problem with this idea is that it can't output to two places at once, as far as I know. Even if it could, I think it's far less work to interact with DF directly rather than trying to shoehorn in a third-party screen reader. :)
We already have access to a lot of info from DF in realtime, via DFHack, etc. The screen reader output would be a far less elegant way to get to the same sort of thing.
-
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.
-
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. :)
-
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.
-
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.
-
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.
-
bump
-
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".
-
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.
-
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.
-
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?
(http://upload.wikimedia.org/wikipedia/commons/f/f8/Codepage-437.png)
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?
-
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.
-
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?
-
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.
-
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
-
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.
-
OK I just had an idea.
What's the DFhack script you're using to output the symbols to console? If we mod the script with a map of symbol to speakup-readable-string, that would take care of this problem significantly more easily!
I was thinking you wanted to mod the game files so that nothing would use symbols that couldn't be pronounced, which isn't possible - but modding the dfhack script is way more possible. Please direct me to the script and I'll dig in :-).
-
There isn't any DFHack script at the moment.
The feature I'm using is built into DF—at least on Linux. That's why I think we could do a lot with DFHack. :)
To do what I'm doing, go to data/init/init.txt, and set Print_Mode to Text.
-
Hm. Mmkay.
Proposal for alpha DFHack for the Blind Script:
- Bind 'print to dfhack' to a key of choice
- When key is pressed, if a cursor is on the screen, DFHack prints out the x-y-z coordinates of the tile, and the contents of the tile, to the DFHack console.
- If no cursor is on the screen, DFHack prints out "No cursor."
You've tested the screen reader on the DFHack console, right? If it updates, will it speak the new lines automatically, or will it read through the whole console?
-
Yeah, the DFHack console reads just fine. It can be set to read new lines automatically, and I can scroll back to read old ones too, if I need that.
I wonder what else we could use commands in DFHack to do? :)
-
The documentation for DFHack is located at https://github.com/DFHack/dfhack/blob/master/Readme.rst (https://github.com/DFHack/dfhack/blob/master/Readme.rst)
Maybe someone can come up with a plug-in that allows the player to load a game from the DFHack console. As it is, you'd have to put a saved game folder under the data/save folder, for example data/save/region1, then launch the game. The first choice will be to continue playing. With DFHack set to default settings, you press Enter three times to get into that saved game. Press k to get a cursor on the screen, and you can then use the "probe" and "cprobe" commands in DFHack to get information about a tile and a selected creature, respectively. It's unlikely that the cursor will happen to be on a creature, though.
When you are done poking around, issue the "die" command in DFHack to kill the game.
-
Has anyone thought of using Soundsense?
Soundsense reads data from the game console and plays sounds in response to certain strings. DFHack can print data to the console. Between them, a great deal could be done. Pretty much everything essential to gameplay, at any rate.
Including flavor text for everything would require either a lot of extra work or an additional program that printed certain console output to a text reader, but that can come later.
-
Has anyone thought of using Soundsense?
Soundsense reads data from the game console and plays sounds in response to certain strings. DFHack can print data to the console. Between them, a great deal could be done. Pretty much everything essential to gameplay, at any rate.
Including flavor text for everything would require either a lot of extra work or an additional program that printed certain console output to a text reader, but that can come later.
Yeah, that was brought up a bit ago, but the level of logging and additional sound design makes it a long-term project.
I'm interested to know if zkline's gotten probe/cprobe to work?
-
I recommend copying/moving this to the modding board for extra, code-keen eyeballs (wow. no pun intended xD)
-
I was going to mention Soundsense myself. You could pop over to Suggestions and place one for mouse support with the ability to port whatever's under the cursor to a third party tool. Because one of the major problems you'll face once you get down to actually using the k button is that it won't let you do anything. So you'll have to log how far you went in what direction to reach your destination, then cancel out of k, find the right button in the menu for whatever you're building, and then retrace your steps. If you could use the mouse, and have a reader built into it, then you could use it to autolook and cut out a step.
Even us sighted folks could use that sort of feature.
-
To be honest it's hard for me to imagine a sound-based interface that merely reads out the contents of the screen being a practical way to play the game. Given that the screen is a matrix of something on the order of 50x50 symbols, and a typical fortress can easily fill many screens, it's hard to imagine any real management getting done even if the readout found some way of simplifying screens significantly, say 100 symbols per screen (a 25x reduction from our hypothetical 50x50=2500 symbols, no trivial task)
Given the frequency with which experienced players can miss fortress-ending fun creeping around on-screen despite the fact that they can survey an entire screen at once, I'm not sure even the (admittedly much better) solution of reading out whatever's under the mouse cursor at the moment would help that much.
In short, despite the game's primary display being textual glyphs, it's hard for me to imagine programmatically presenting the game as text in a manner that is satisfying and complete while also succinct enough to allow for reasonable rates of play.
-
I dunno, I have no experience playing anything blind but DF is probably one of the better games to play because the same information is available from more than one place. The fortress itself is represented on the map but one could also look at a list of workshops and rooms and get a reasonable idea of the layout. Units are represented on the map but also in the units list. If this cross-referenced data were presented in an intelligent way I don't see much of a problem with maintaining a mental map of the fort or with keeping track of changes....?
If Button's suggestion were implemented with smart audio outputs for standard DF menus, and some custom audio outputs to present other information that would be good? I don't know of any Text To Speech libraries that'd be useful.
-
There isn't any DFHack script at the moment.
The feature I'm using is built into DF—at least on Linux. That's why I think we could do a lot with DFHack. :)
To do what I'm doing, go to data/init/init.txt, and set Print_Mode to Text.
For some reason it was not listed as a bugfix, but TEXT print mode works on OSX as of version 0.40.24. So the next version of DFHack should give you a choice of machines to use.
-
For some reason it was not listed as a bugfix, but TEXT print mode works on OSX as of version 0.40.24.
Tentatively fixed text mode error on OSX (lethosor)
http://www.bay12games.com/dwarves/mantisbt/view.php?id=5677 was also resolved.
-
The idea that just popped in my head on this would be a haptic force feedback glove that lets the wearer "feel" the layout of the screen by moving the cursor around. Since the brain automatically stitches the sensations together, you would be able to feel the walls, corridors, etc. and possibly change the feedback types for each tiletype, to tell where the stairs are in relationship to the corridors, rooms, gates, etc. Combined with a vocal feedback device (like Soundsense) that announced events and read the logs to the player, the only real issue would be menu-heavy information overload moments like the trade interface, diplomat reports, etc.
Combat would require a lot of pausing to reread the screen, but most people play combat with lots of pause time anyway.
This is not a short-term solution. It would make someone a pile of money who wanted to code it, because it is not just the blind who would find it very useful indeed. I am not that person, but hopefully someone sees this and grows rich :)
-
SO I don't know if necro-ing threads is okay if I'm the OP :) But I figured I should do this rather than start a third thread for my ramblings.
I've been bitten by the DF bug again, and have talked to some of the people behind my Linux screen reader. The reason it fails to read a lot of the characters is that they are beyond 255 unicode, which is the maximum it supports.
So I'm now wondering how much of the DF display can be modded to display from 0 to 255? It doesn't matter that CodePage 437 uses those values internally, what seems to matter are the Unicode translations. This is more information than I've had before on why it fails, at any rate.
Also, I've created http://www.bay12forums.com/smf/index.php?topic=157486.new#new (http://www.bay12forums.com/smf/index.php?topic=157486.new#new) in hopes of making a much simpler change to make adventure mode more playable.
I don't know how long my enthusiasm will last before I get swept up in the accessibility issues again, but here we are. :)
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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. :)
-
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.
-
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 (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 @.
-
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.
-
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 :D
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.
-
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.
-
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.
-
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?"
-
I believe so. If you have yiur cursor over something, then hit escape and then Designate, you should have the corner of your grid where your cursor was.
((Ps, if you manage to get things going smoothly, post your fortresses status once in a while. This is some Hall of Legends type shit right here.))
-
Okay, I've managed to channel into a cavern, and have a staircase going down/up from that initial excavation. Liberal use of the look command helps a lot, along with using F1 to get back to my wagon.
Some initial impressions: it's hard to tell where the tile I've selected to designate is in relation to others without constant looking. I've mentioned this question before, and I think it would really help if I could keep the text-mode cursor on the game's idea of the selected tile most of the time. That way I can use my screen reader's review keys to move around without starting off at a random point. Maybe this kind of thing can be done with DFHack?
Speaking of DFHack, is it possible to run this with Print_Mode:Text? I wasn't sure how I'd bring up a console in that case—is there some unused punctuation symbol, a la Quake or the like? :)
The other thing which is kind of annoying at the moment is the way text mode handles redrawing the screen. The Look command output is only redrawn if it changes significantly, and my screen reader cues off those changes. So if I've got several cavern floors with the same stone or whatever, it won't actually repeat them, even though it probably should. This is more a technical issue, and I don't know how much can be done about it.
Finally, I noticed that sometimes tiles blink between two symbols. This is really annoying from an accessibility perspective, because the reader reads the blinking every time. Particular culprits seem to be letters/creatures, but I noticed my > stairway doing it too.
Despite my griping, I'm actually feeling pretty optimistic. This is going to be slow, but I'm confident things can be done to make things a lot easier. Honestly, that terminal cursor question will help 95% of the way on its own.
-
The game sometimes flashes between two symbols when there are two or more "important" items in a tile, for example a rough gem sitting on a staircase or a tiger in a cage. When two or more creatures are on the same time, it will alternate between them with a very irritating animation in between of / - \ | / - \ |
Creatures in an unusual state will also flash, such as sleeping or enraged.
Not sure how if that behavior can be prevented in the main interface, but the iOS remote might be able to include an option for flashing.
-
I am now going to vote for this on the Hall of Legends. Seriously tho, this is like one of those inspirational stories you read about people saying F.U. to unfortunate circumstances and ignoring limitations. Except, you know, nerdier.
-
Heya.
You, sir, are a stubbornly persistent and awesome person.
Also PTW because this is the most epic thing I've seen in the past year.
-
I believe so. If you have yiur cursor over something, then hit escape and then Designate, you should have the corner of your grid where your cursor was.
Important: this is only true if you're using DFHack (specifically DFHack's "tweak stable-cursor", which is enabled in the default configuration).
Speaking of DFHack, is it possible to run this with Print_Mode:Text? I wasn't sure how I'd bring up a console in that case—is there some unused punctuation symbol, a la Quake or the like? :)
You can run commands with the dfhack-run script in the DF folder. If you run "./dfhack-run command-prompt", that will open a command prompt in-game, which might be more convenient. It's worth noting that neither of these methods will work with interactive console commands, like "liquids" (although "gui/liquids" will still work).
-
So I'm running into the quandary of sticking with the current version or migrating back to version 0.40 (?) for DFHack support. I use ArchLinux, so the current version is available pretty easily.
Does anybody more experienced have thoughts on this? I guess if I want to try out DF Remote I need to use the older version for now anyway. :)
-
Does anybody more experienced have thoughts on this? I guess if I want to try out DF Remote I need to use the older version for now anyway. :)
DF Remote will be useless for you right now, and by the time I add some map reading to it, it will support 0.42 I suppose :)
-
So I'm running into the quandary of sticking with the current version or migrating back to version 0.40 (?) for DFHack support. I use ArchLinux, so the current version is available pretty easily.
DFHack supports 0.42 - the only releases so far are alphas, but they're fairly stable.
https://github.com/dfhack/dfhack/releases
-
So, I haven't managed to make much more progress, partially because I got sidetracked into messing with DFHack a bit, but…
A few idea to make things a bit easier to understand:
- It would help a lot if the type of the selected tile could be displayed when designating. Even if you're technically designating a rectangle, until I can be sure where the game's cursor is it seems to be pretty easy to select something unintended.
- On a similar note, maybe a script could take the "d," command from Look and start designation with the selected tile set as the start of the rectangle? Just for ease of use. :)
One more question, am I right in assuming that designation works rather like selecting cells in a spreadsheet? Moving right makes the rectangle 2x1, 3x1, etc, but moving up would make it 3x2, 3x3, selecting the tiles to the "left," of the cursor? Sorry if this is hard to understand, I always struggled a bit with spacial concepts.
Thanks for the thoughts and support. :)
-
when marking designations, i can only talk about how it's done with mousecontrol plugin:
you mark either two opposing corner blocks of the designation area.
when creating buildings, you enlarge the area by using u m h and k and it adds around the cursor position, always north, south, nord etc and east, west, east, west etc.
unifying the way building and designating would be a huge improvement to the game.
-
There is a difference between designating a room from an existing built furniture such as bed, armor stand, table, or chair.
A player would normally use the q key and move the cursor over the furniture.
For example I q over the bed, at which point I press r, and begin designate a room.
DF automatically pre-selects a default room size of around 4x4 or 5x5 in size.
This pre-selects is reduces when there are walls and doors, so a bed in the middle of a 3x3 room, will pre-select a 4x4 area which includes the 3x3 room and the adjacent walls and door.
Pressing the plus or minus key increases the diameter of that room size with the bed at its center.
Pressing enter at that point makes that designation of the room's size.
If I recall correctly, the menu choices will be to resize the room, assign an owner, and free the room from current owner.
There is also designation for creating stock piles or zones.
P for stockpile goes to the stockpile menu.
Usually this is the time to set what kind of of stock pile it is.
There are default settings such as Food, Stone, Armor, etc.
There is also a c for custom, the t for settings which allows you to choose a combination of from what is stocked, to materials such wood or metal, and even quality of items such as finely crafted to artifact.
Move the cursor to where to place the stockpile.
Pressing enter starts the designation from that cursor position.
This cursor position is the anchor point of the square or rectangle, or even single tile.
Moving one right makes is 1x2, then moving one down makes it 2x2 with the anchor point from the upper left corner.
If instead from the anchor point, moving up one and left one, this will make the size 2x2 also, but the anchor point will be on the bottom right corner instead.
Pressing enter again commits to the size of that stock pile with the selected type of stockpile from either the defaults or custom settings.
And there is d designation for mining floors, up or down ramps, combinations of up/down stairs, channel. And then the plant gathering and cutting down trees. And also the smooth stone and carve fortification. They will all follow the anchor point, and resizing the x-y or width and height; and also the z-axis for the depth.
--
Anyway, one idea I use a Hotkey, by default the key F1 centers on the wagon. I am just not sure where the cursor is after pressing it.
This will give you a constant starting location.
I think dfhack has a function to get current cursor position, and move to cursor position.
That will help dictating (voice to text) and feed it to dfhack console perhaps?
-
I've been thinking about how DFHack could improve accessibility - would it help to write stuff about the current screen in-game to a log file (i.e. would screen readers be able to deal with that)? This could include screen type, sidebar mode, various selections, cursor position and items under the cursor, and a variety of other things. It could also get rid of the Linux/OS X requirement for PRINT_MODE:TEXT, assuming it's usable enough.
-
Thanks. Designation with D at least works pretty much like I expected, I think. :)
The one thing with seems confusing is that, as far as I know, the text-mode terminal cursor and the game's idea of the cursor don't have much to do with each other. Can any DFHack people chime in on this? It's kind of hard to explain what I mean by "terminal cursor," I guess, since it isn't always obvious to people who don't rely on screen readers all the time.
Re: a log file, that's definitely an idea. Particularly on the OS X side it might make things easier, since OS X's accessible terminal support is iffy at best. I think in general DFHack has a lot of potential to help for accessibility, I just wish I knew more of what could be done with it.
-
Yeah, I know what cursor you mean. It's a bit hard to figure out exactly where on-screen DF's cursor is in order to position the terminal cursor, though.
I'll look into logging. It seems that this can be used to speak the contents of a log file as it's generated on OS X, and presumably there would be alternatives on other platforms:
tail -f log.txt | while read line; do echo $line | say; done
-
Some high level concepts, idea.
DF announces "a vile force of darkness has arrived."
App 1, call it "Make Log Source." Voice command: Make Log Source. This would be an executable that queries information via dfhack.
Some example function, unit screen for those marked with "Invader" title.
The initial siege will have at least 1 enemy on the map.
Or a more simple example is when a FB shows up.
Normally, I can zoom into the announcement. k over the enemy, and see the description.
If a script in dfhack can do that and append to an external file with: x, y, z position, name, description.
Let's call this external file "Log Source"
App 2, call it "Parse Log Source." Voice command: Parse Log Source. This will be dfhack dependent with its own database.
This will read the info from the file "Log Source" and add to or update its database.
Example:
Urist, title militia commander, last known location is x,y,z = at room 2 bedroom. Latest position is at the wagon.
Bax, title goblin bowman, new entry, location is 1,1,1 = top left of map?
So doing it this way, you don't need to read / interpret the df screen when you probably pick and choose which entity you are interested in that shows up in the unit screen.
In this case an invader or Uninvited guest.
-
Yeah, something like tail -f was what I was thinking too. I admit that piping it through a separate audio command hadn't occurred to me, though it makes sense. :)
Thanks for looking into this.
-
I think mifki has already done some of this abstraction already while creating the iOS remote. My understanding is that it re-creates the content that would show up on screen from DFHack-like sources, rather than reading the screen. This is very different from mifki's other, better known tool called Text Will Be Text which does impressive feats with the on-screen graphics.
Dwarf Fortress's on-screen cursor is normally not persistent, putting an invalid value in the coordinates when there is no need for a mark on the screen. But a DFHack plugin called stable-cursor remembers where the cursor was and puts it back there the next time an on-screen cursor is needed, assuming you have not scrolled away from that part of the map.
A simplified version of stable-cursor could keep the on-screen cursor centered on the screen at all times, maintaining a "cursor" position even when the cursor would not normally be displayed. Keeping things centered would help with any future rendering tools that come later, whether they are audible or Braille. It also allows for simple terminal commands like "where am I" and "jump to" and "bookmark". The bookmarks could be hotkey locations or notes; I'm not sure which would work better.
where am i
25, 45, 105. Open space.
go to 25 45 104
where am i
25, 45, 104. Granite floor.
bookmark 5
go to bookmark 2
-
Ahh, I wondered what exactly Stable Cursor did. :) Thanks for clarifying that. I've occasionally seen an X, somewhere on screen. I take it that's DF's indicator for something.
I think the mini-map just confuses things, because I can't tell where the main one ends and the mini-map starts. So I'm going to probably want to get rid of it using Tab, I imagine.
-
Yeah, the "X" is DF's cursor. Dirst, the issue is that the terminal cursor (the one that's used when typing commands in the terminal) jumps around in PRINT_MODE:TEXT, depending on where the last character was drawn to the screen.
Also, I could be wrong, but I'm pretty sure mifki's iOS remote is just streaming (part of) the map data. Of course, all of the menus are obtaining data through DFHack, but that's generally pretty easy to do with DFHack (an interface is harder).
-
A "Really Stable Cursor" is little more than an array of three integers. Keeping the map centered on the virtual cursor is the hard part. Sounds like the terminal cursor whips around like mad when the map scrolls, but (re)printing the center character after each update will force the terminal cursor to stay where it is expected.
-
To be more clear, the terminal cursor follows the last changed character drawn to the screen. Redrawing the same character won't move it, and that character that the cursor doesn't even have to be on the map - it just has to have changed since the last frame. In my case, it's often the FPS counter.
-
To further confuse this issue, ncurses, the library text-mode DF uses, is designed to optimize redraws so the screen isn't totally redrawn unnecessarily. Only parts of the screen which change are redrawn. The downside to this is that my screen reader doesn't read anything which is "identical," between frames. That's why I run into trouble using the default Look command, because often the same tile information is present and isn't properly read.
For what it's worth, Cataclysm, another roguelike I've managed to get some accessibility into recently, decided to force redraw the entire screen each turn. That helped quite a bit all on its own. :)
-
Sorry for the double post. :)
I decided to try DFHack under OS X today, and the probe command has proven helpful, if more than a bit verbose. I was using standard print_mode for a change, and only able to do anything because I memorized key sequences. This isn't all that different from the way some blind gamers play fighting games, I gather.
I think I understand now that the game only really has a selected tile in certain modes. The thing which text mode could theoretically give me that standard can't yet is a sense of what's happening when I'm not in one of them. I think a lot of the appeal seems to come from the combination of watching the little dwarves and the text announcements? :) At any rate, it's been interesting thus far, if nothing else.
-
The ASCII graphics plus that announcements and battle reports try to convey that story unfolding.
I would see a goblin ascii character in one spot, then an arrow moving towards a dwarf, and the arrow disappears in the dwarf's spot.
There may be some sound effect to that. Looking at it, gives a general picture of a goblin shooting a dwarf with an arrow and it seems to hit the dwarf.
Pressing R will open the report, and I still have to find the battle report for the goblin shooting an arrow; or the battle report for the dwarf being shot by the arrow.
Pressing enter on the report will give a verbose text of the battle. If the arrow punctures the liver. If the dwarf pulls out the arrow out, and falls unconscious.
The issue of following the battle of many units is figuring out who attack whom.
All Goblin Bowman will be describes as Goblin Bowman.
But Bax the Goblin Bowman will have a battle report from his perspective.
Likewise, the default titles for dwarves show up. Urist the Recruit will be in the reports as Goblin Bowman strikes the Recruit in the lower body, piercing the liver.
Without custom titles, it gets hard following the battle reports after the fight.
-
So I made a couple of interesting discoveries today, at least one of which is semi-related to DF accessibility.
If I set Speakup, my text-mode Linux screen reader, to "highlight tracking," one of a few ways it can handle the cursor, it seems to keep relatively close to the position of the selected tile when doing look/designate/whatever. Knowing that selected tile is indicated by an "X," helps. It's not quite enough to be confident in what I'm doing, but it's better than it was.
I've also discovered a way to send things to the speech synthesizer directly, bypassing Speakup's character handling. If you write Unicode into /sys/accessibility/speakup/synth_direct, it will be spoken by the synthesizer, even if it's outside of the 0 .. 255 range. This isn't as helpful as it could be, if only because I don't know of a way to use this direct processing all the time.
Of course, this is only tangentially related to DF, per se. Still, I figured it was worth mentioning here because, say, a DFHack script might be able to send log text directly to the synthesizer someday. I don't know. :)
-
Maybe if you wrote to the file on the fly?
-
That sounds good in theory. It strikes me that we don't necessarily need to write the Unicode characters themselves so much as what they represent. If anything, writing "smiley face," would require me to remember that a smiley face is a dwarf.
I imagine the log file aspect lethosor is looking into would probably work similarly, getting as much of the underlying data as possible via DFHack. THere's no right way to tackle something like this. My day job is accessibility and usability testing, but I'm afraid the Web Content Accessibility Guidelines aren't super helpful here. ;)
-
Hi zkline, I went ahead and built that Where-Am-I and bookmark thing I described. This post is the instructions, and the next post has the Lua scripts inside "code" blocks.
The first block of code should be saved in your DF folder under /raw/scripts/bookmark.lua
The second one in /raw/scripts/goto.lua
The third one in /raw/scripts/whereami.lua
Please let me know if there is a more convenient way to get the scripts to you. If this works and is helpful, I'll package it as a proper mod or ask the DFHack devs if they want to include these in the core distribution.
bookmark.lua
This script defines, updates and deletes persistent bookmarks on the map. A bookmark may have almost any single-word string as its name, but numbers are not recommended. Bookmark also includes a calibration command because I was unable to find a way to reliably read the dimensions of the on-screen map.
bookmark help
Prints a short summary of bookmark commands.
bookmark calibrate
Issue this command while the cursor is in the middle of the screen. The best time to do this is immediately upon loading the fort, and pressing 'k'. This will let the mod translate between "top left corner of the screen" and "center of the screen."
bookmark list
Lists all current bookmarks, if any.
bookmark drop foo
Deletes a bookmark named foo.
bookmark clear all
Deletes ALL bookmarks. Note the space between "clear" and "all" as a safety feature.
bookmark foo
Creates or updates the bookmark named "foo" at the current cursor location. If the cursor is not present, and calibration has been performed, the bookmark will be set as the center of the on-screen map.
goto.lua
This script will move the map (and cursor if it is present) to a specific location. Note that it cannot function unless "bookmark calibrate" has been performed. The goto script has two modes: bookmark and coordinates.
goto help
Prints a short summary of the goto commands.
goto foo
Moves the map to the bookmark named foo, if it exists.
goto # # #
Moves the map to the specified X, Y, Z coordinates.
whereami.lua
This script reports your current location as X, Y, Z coordinates. This always works if the cursor is present, otherwise it depends upon "bookmark calibrate" to determine the center of the on-screen map. whereami will also report if the current location is recorded as a bookmark.
Known issues:
This version has minimal error checking. For now, avoid jumping too close to the edge of the embark area. I'm not sure if the graphical glitches are due to the core game, or to some other DFHack module I happen to be running.
-
Lua code:
-- bookmark script v1.00
-- Set and clears persistent bookmarks on the fort map.
-- Enter "bookmark help" for a list of reserved names.
local args = {...}
local bookmarks = dfhack.persistent.get_all("BOOKMARK",true)
local calibration = dfhack.persistent.get("_BOOKMARK")
if args[1] == "help" then
print([[bookmark.lua
Enter "bookmark foo" to create a bookmark named "foo" at the current location.
Any one-word string may be used except the following reserved words:
"bookmark help" prints this command summary.
"bookmark calibrate" sets the cursor location as the center of the screen.
"bookmark list" prints a list of existing bookmarks.
"bookmark drop foo" erases the bookmark named "foo".
"bookmark clear all" erases all current bookmarks, note the space between "clear" and "all".
]])
elseif args[1] == "list" then
if bookmarks then
for _, bookmark in ipairs(bookmarks) do
print(bookmark.value .. ": " .. bookmark.ints[1] .. " " .. bookmark.ints[2] .. " " .. bookmark.ints[3])
end
else
print("No bookmarks defined.")
end
elseif args[1] == "clear" and args[2] == "all" then
if bookmarks then
local count = #bookmarks
for _, bookmark in ipairs(bookmarks) do
bookmark:delete()
end
print("Deleted " .. count .. " bookmarks.")
else
print("No bookmarks are defined, so no action taken.")
end
elseif args[1] == "calibrate" and not args[2] then
local pos = {}
local offset_x
local offset_y
pos = copyall(df.global.cursor)
if pos.x == -30000 then
print("Cursor is not present. Cannot calibrate.")
else
offset_x = pos.x - df.global.window_x
offset_y = pos.y - df.global.window_y
dfhack.persistent.save({key="_BOOKMARK",value="Calibration data",ints={offset_x,offset_y}})
print("Calibration complete.")
end
elseif args[1] == "drop" and args[2] then
if bookmarks then
local del = false
for _, bookmark in ipairs(bookmarks) do
if bookmark.value == args[2] then
bookmark:delete()
print("Bookmark " .. args[2] .. " deleted.")
del = true
end
end
if del == false then print("Bookmark " .. args[2] .. " not defined, so no action taken.") end
else
print("No bookmarks are defined, so no action taken.")
end
elseif args[1] and not args[2] then
local pos = {}
pos = copyall(df.global.cursor)
local make_new = true
if pos.x == -30000 then
if calibration then
name = "Center:"
pos["x"] = df.global.window_x + calibration.ints[1]
pos["y"] = df.global.window_y + calibration.ints[2]
pos["z"] = df.global.window_z
else
print([[
Not calibrated. Either use the cursor or "bookmark calibrate" with the cursor in the center of the screen.
]])
end
end
if bookmarks then
for _, bookmark in ipairs(bookmarks) do
if bookmark.value == args[1] then
bookmark.ints[1] = pos.x
bookmark.ints[2] = pos.y
bookmark.ints[3] = pos.z
bookmark:save()
print("Bookmark " .. args[1] .. " updated.")
make_new = false
end
end
if make_new == true then
dfhack.persistent.save({key="BOOKMARK/"..args[1],value=args[1],ints={pos.x,pos.y,pos.z}})
print("Bookmark " .. args[1] .. " created.")
end
else
dfhack.persistent.save({key="BOOKMARK/"..args[1],value=args[1],ints={pos.x,pos.y,pos.z}})
print("Bookmark " .. args[1] .. " created.")
end
else
print([[
Invalid command. Use "bookmark help" for help.
]])
end
-- goto script v1.00
-- Move the screen to a bookmark or a set of XYZ coordinates.
-- Enter "bookmark help" for a list of reserved names.
local args = {...}
local bookmarks = dfhack.persistent.get_all("BOOKMARK",true)
local calibration = dfhack.persistent.get("_BOOKMARK")
if args[1] == "help" then
print([[bookmark.lua
Enter "goto # # #" to move the screen to a set of XYZ coordinates.
Enter "goto foo" to move the screen to be centered on bookmark "foo".
"goto help" prints this command summary.
Note that goto cannot function unless "bookmark calibrate" has been performed.
]])
elseif args[1] and not args[2] then
if bookmarks then
if calibration then
local pos = {}
local xcoord = df.global.cursor.x
for _, bookmark in ipairs(bookmarks) do
if bookmark.value == args[1] then
pos["x"] = bookmark.ints[1]
pos["y"] = bookmark.ints[2]
pos["z"] = bookmark.ints[3]
end
end
if pos.x then
if xcoord ~= -30000 then df.global.cursor.x = pos.x end
df.global.cursor.y = pos.y
df.global.cursor.z = pos.z
df.global.window_x = pos.x - calibration.ints[1]
df.global.window_y = pos.y - calibration.ints[2]
df.global.window_z = pos.z
print("Now at " .. args[1])
else
print("Bookmark " .. args[1] .. " not defined.")
end
else
print([[
Not calibrated. Use "bookmark calibrate" with the cursor in the center of the screen.
]])
end
else
print("No bookmarks defined.")
end
elseif args[1] and args[2] and args[3] then
if calibration then
local xcoord = df.global.cursor.x
if xcoord ~= -30000 then df.global.cursor.x = tonumber(args[1]) end
df.global.cursor.y = tonumber(args[2])
df.global.cursor.z = tonumber(args[3])
df.global.window_x = tonumber(args[1]) - calibration.ints[1]
df.global.window_y = df.global.cursor.y - calibration.ints[2]
df.global.window_z = df.global.cursor.z
print("Now at " .. args[1] .. " " .. args[2] .. " " .. args[3])
else
print([[
Not calibrated. Use "bookmark calibrate" with the cursor in the center of the screen.
]])
end
else
print([[
Invalid command. Use "goto help" for help.
]])
end
-- whereami script v1.00
-- Reports coordinates of the cursor if it is present, or the center of the screen if not.
-- Also lists any bookmarks set for these coordinates.
local bookmarks = dfhack.persistent.get_all("BOOKMARK",true)
local calibration = dfhack.persistent.get("_BOOKMARK")
local pos = {}
pos = copyall(df.global.cursor)
local valid_pos = true
local name = "Cursor:"
if pos.x == -30000 then
if calibration then
name = "Center:"
pos["x"] = df.global.window_x + calibration.ints[1]
pos["y"] = df.global.window_y + calibration.ints[2]
pos["z"] = df.global.window_z
else
print([[
Not calibrated. Either use the cursor or "bookmark calibrate" with the cursor in the center of the screen.
]])
valid_pos = false
end
end
if valid_pos == true then
print(name .. " " .. pos.x .. " " .. pos.y .. " " .. pos.z)
if bookmarks then
for _, bookmark in ipairs(bookmarks) do
if bookmark.ints[1] == pos.x and bookmark.ints[2] == pos.y and bookmark.ints[3] == pos.z then
print("Bookmarked as " .. bookmark.value)
end
end
end
end
-
Dirst, this seems to work very well on first inspection. I've only managed to test on the mac so far, because I don't have DFHack for my Linux install yet. But I was able to bookmark my wagon and successfully explore a bit, and zoom back to the bookmark again.
Thanks for writing these scripts. If I run into anything weird I'll let you know. For the record, I figured "raw," meant "the dfHack installation directory." :)
-
That works, too. The "scripts" subfolder under "raw" is supposed to be for mod-specific scripts, and gets copied to your save folder. It is earlier in the search path than the main DFHack scripts folder, but other than that it doesn't really make a difference.
I did get some pointers on reading the map size, so hopefully a new version won't require that calibration step.
-
.... I think the previous 4 posts were in english.
I think....
Thats about all i got from reading that.
-
There were some English words in there.
-
S'just Lua, guys, it's not Cthulhu.
(Note:I do not actually know Lua, I may be wrong about its eldritchness.)
-
Here is some more of that CthuLua stuff. This version dispenses with the calibration step thanks to lethosor's help. It also reports the Z level as it shows on the screen instead of the internal offset, and now does sanity checks on your goto coordinates.
Unfortunately, fixing the Z broke compatibility with bookmarks from the previous version. Hopefully those were only used in test forts.
-- bookmark script v1.01
-- Set and clears persistent bookmarks on the fort map.
-- Enter "bookmark help" for a list of reserved names.
-- Version 1.01 removes the need for the "calibrate" step and harmonizes reported Z with screen display.
local args = {...}
local bookmarks = dfhack.persistent.get_all("BOOKMARK",true)
if args[1] == "help" then
print([[bookmark.lua
Enter "bookmark foo" to create a bookmark named "foo" at the current location.
Any one-word string may be used except the following reserved words:
"bookmark help" prints this command summary.
"bookmark list" prints a list of existing bookmarks.
"bookmark drop foo" erases the bookmark named "foo".
"bookmark clear all" erases all current bookmarks, note the space between "clear" and "all".
]])
elseif args[1] == "list" then
if bookmarks then
for _, bookmark in ipairs(bookmarks) do
print(bookmark.value .. ": " .. bookmark.ints[1] .. " " .. bookmark.ints[2] .. " " .. bookmark.ints[3])
end
else
print("No bookmarks defined.")
end
elseif args[1] == "clear" and args[2] == "all" then
if bookmarks then
local count = #bookmarks
for _, bookmark in ipairs(bookmarks) do
bookmark:delete()
end
print("Deleted " .. count .. " bookmarks.")
else
print("No bookmarks are defined, so no action taken.")
end
elseif args[1] == "drop" and args[2] then
if bookmarks then
local del = false
for _, bookmark in ipairs(bookmarks) do
if bookmark.value == args[2] then
bookmark:delete()
print("Bookmark " .. args[2] .. " deleted.")
del = true
end
end
if del == false then print("Bookmark " .. args[2] .. " not defined, so no action taken.") end
else
print("No bookmarks are defined, so no action taken.")
end
elseif args[1] and not args[2] then
local pos = {}
pos = copyall(df.global.cursor)
pos.z = pos.z + df.global.world.map.region_z
local make_new = true
if pos.x == -30000 then
name = "Center:"
dm = require('gui.dwarfmode')
pos["x"] = df.global.window_x + math.floor(dm.getPanelLayout().map.width / 2)
pos["y"] = df.global.window_y + math.floor(dm.getPanelLayout().map.height / 2)
pos["z"] = df.global.window_z + df.global.world.map.region_z
end
if bookmarks then
for _, bookmark in ipairs(bookmarks) do
if bookmark.value == args[1] then
bookmark.ints[1] = pos.x
bookmark.ints[2] = pos.y
bookmark.ints[3] = pos.z
bookmark:save()
print("Bookmark " .. args[1] .. " updated.")
make_new = false
end
end
if make_new == true then
dfhack.persistent.save({key="BOOKMARK/"..args[1],value=args[1],ints={pos.x,pos.y,pos.z}})
print("Bookmark " .. args[1] .. " created.")
end
else
dfhack.persistent.save({key="BOOKMARK/"..args[1],value=args[1],ints={pos.x,pos.y,pos.z}})
print("Bookmark " .. args[1] .. " created.")
end
else
print([[
Invalid command. Use "bookmark help" for help.
]])
end
-- goto script v1.01
-- Move the screen to a bookmark or a set of XYZ coordinates.
-- Enter "bookmark help" for a list of reserved names.
-- Version 1.01 removes the need for the "calibrate" step, harmonizes reported Z with screen display, and checks bounds on target coordinates.
local args = {...}
local bookmarks = dfhack.persistent.get_all("BOOKMARK",true)
if args[1] == "help" then
print([[bookmark.lua
Enter "goto # # #" to move the screen to a set of XYZ coordinates.
Enter "goto foo" to move the screen to be centered on bookmark "foo".
"goto help" prints this command summary.
]])
elseif args[1] and not args[2] then
if bookmarks then
local pos = {}
local xcoord = df.global.cursor.x
for _, bookmark in ipairs(bookmarks) do
if bookmark.value == args[1] then
pos["x"] = bookmark.ints[1]
pos["y"] = bookmark.ints[2]
pos["z"] = bookmark.ints[3]
end
end
if pos.x then
dm = require('gui.dwarfmode')
if xcoord ~= -30000 then df.global.cursor.x = pos.x end
df.global.cursor.y = pos.y
df.global.cursor.z = pos.z - df.global.world.map.region_z
df.global.window_x = math.max(pos.x - math.floor(dm.getPanelLayout().map.width / 2), 0)
df.global.window_y = math.max(pos.y - math.floor(dm.getPanelLayout().map.height / 2), 0)
df.global.window_z = pos.z - df.global.world.map.region_z
print("Now at " .. args[1])
else
print("Bookmark " .. args[1] .. " not defined.")
end
else
print("No bookmarks defined.")
end
elseif args[1] and args[2] and args[3] then
local pos_x = tonumber(args[1])
local pos_y = tonumber(args[2])
local pos_z = tonumber(args[3]) - df.global.world.map.region_z
local max_x = df.global.world.map.x_count - 1
local max_y = df.global.world.map.y_count - 1
local max_z = df.global.world.map.z_count - 1
if pos_x > max_x or pos_y > max_y or pos_z > max_z or pos_x < 0 or pos_y < 0 or pos_z < 0 then
print("Target out of range.")
else
local dm = require('gui.dwarfmode')
local size_x = dm.getPanelLayout().map.width
local size_y = dm.getPanelLayout().map.height
local half_x = math.floor(size_x / 2)
local half_y = math.floor(size_y / 2)
local window_x = math.min(math.max(pos_x - half_x, 0), max_x - size_x)
local window_y = math.min(math.max(pos_y - half_y, 0), max_y - size_y)
local xcoord = df.global.cursor.x
if xcoord ~= -30000 then
df.global.cursor.x = pos_x
df.global.cursor.y = pos_y
else
df.global.cursor.y = window_y + half_y
end
df.global.cursor.z = pos_z
df.global.window_x = window_x
df.global.window_y = window_y
df.global.window_z = pos_z
if xcoord == -30000 and (pos_x ~= window_x + half_x or pos_y ~= window_y + half_y) then
print("Too close to edge. Now at " .. window_x + half_x .. " " .. window_y + half_y .. " " .. pos_z + df.global.world.map.region_z)
else
print("Now at " .. pos_x .. " " .. pos_y .. " " .. pos_z + df.global.world.map.region_z)
end
end
else
print([[
Invalid command. Use "goto help" for help.
]])
end
-- whereami script v1.01
-- Reports coordinates of the cursor if it is present, or the center of the screen if not.
-- Also lists any bookmarks set for these coordinates.
-- Version 1.01 removes the need for the "calibrate" step and harmonizes reported Z with screen display.
local bookmarks = dfhack.persistent.get_all("BOOKMARK",true)
local pos = {}
pos = copyall(df.global.cursor)
pos.z = pos.z + df.global.world.map.region_z
local name = "Cursor:"
if pos.x == -30000 then
dm = require('gui.dwarfmode')
name = "Center:"
pos["x"] = df.global.window_x + math.floor(dm.getPanelLayout().map.width / 2)
pos["y"] = df.global.window_y + math.floor(dm.getPanelLayout().map.height / 2)
pos["z"] = df.global.window_z + df.global.world.map.region_z
end
print(name .. " " .. pos.x .. " " .. pos.y .. " " .. pos.z)
if bookmarks then
for _, bookmark in ipairs(bookmarks) do
if bookmark.ints[1] == pos.x and bookmark.ints[2] == pos.y and bookmark.ints[3] == pos.z then
print("Bookmarked as " .. bookmark.value)
end
end
end
-
Since this really isn't the appropriate place to be sending potentially Eldritch code back and forth, I started this thread (http://www.bay12forums.com/smf/index.php?topic=157631) in the Modding area.
-
*Stares slack jawed at the previous post. Eyes begin to glaze over. Suddenly shakes head*
"Woah, What? Where am i?"
-
"Inside a thread THAT'S NOT A ROLEPLAYING THREAD. Get back to your
hole board." :P
-
zkline - great respect for you! Seriosly. I have little post-suggestion for future experiments - to use desktop for blind(i forget it's name, you said that it's has not enough sympols previosly in this topic) + sound note. Like touching-code for liter(abcd...) and sounds for color and Upper or normal symbols.
But i'm really glad to see that this long research been crowned with success!
And other suggestion - you can try to create something like community game, probadly with youtube translation... and a lot of other beards help you in situation, that now you can't solve. As for me, i'm really intresed to see somethink like this!
-
Hi zkline and anyone else not terrified by that earlier Lua script stuff, I got version 1.02 (http://www.bay12forums.com/smf/index.php?topic=157631) to now give a very brief description of the tile when you type whereami in the DFHack console. For example,
whereami
Cursor: 73 74 148, SOIL WALL
Obviously there is a lot more information available, but I wanted to keep the responses very short. The idea is to detect when the ground level changes, not to re-create the game's look or DFHack's probe.
-
Thanks for this, Dirst. :)
Sadly, I lost access to my Linux system, and thus, relatively pleasant text-mode DF. Thanks, Windows 10 for overriding boot entries without permission. :/ I haven't had the patience to repair things yet.
I would love to be able to play without need for text mode, however. Has their been any luck with logging?
-
Here's the script I have so far: https://github.com/lethosor/dfhack-scripts/blob/master/acclog.lua
A more easily-downloadable ("raw") version: https://raw.githubusercontent.com/lethosor/dfhack-scripts/master/acclog.lua
I couldn't come up with a great name for it, and I really haven't had a lot of time to work on it, being busy with other DFHack maintenance stuff. Right now it just logs the selected items in the title, options, and load game menus, although I've been putting in extra work to make adding new things easier.
Anyway, let me know if the logging works and is usable (it writes to acclog.txt in the DF folder), and if it's too verbose/terse/whatever. I'll probably make the messages customizable at some point, but they're not at the moment.
-
Hey, All,
Just wanted to pop back in here to say I finally restored Linux access again. So DF is once again maybe sort of playable.
I'm tempted to focus on adventure mode this time around, if only because I have been craving somethings super sandboxy of late. There are some problems with it too, of course, but less so than fortress-building.
I'll continue to poke at different screen readers, in hopes I can get one which reads the characters properly. That would be an excellent start. :)
-
So DF is once again maybe sort of playable.
"DF" and "playable" in the same sentence? I think you misunderstand this game :)
Welcome back!
-
So I found an old, barely-supported Linux screen reader called YASR. It's hardly ideal, but it at least reads more of the characters than my default one does. It calls some walls in adventure mode "A-Circumflex." I'm not sure if that's accurate or just because it doesn't know how to pronounce their actual symbol.
The fundamental problems still remain, namely that the terminal cursor doesn't follow my character/the game cursor very well. This is of course pretty specific to Print_Mode:Text. the regular SDL is still unusable.
-
i never palyed this game without a graphicset, so i can't tell you what an A-Circonflex represents, but it's an A with a Circonflex (the small "roof") above.
-
It's "Circumflex", not "Circonflex".
I suspect that's showing up because your graphics set changes some stones to use that tile, which obviously doesn't work in PRINT_MODE:TEXT. Unless you're using a plain ASCII tileset, in which case I'm not sure what the issue is. Maybe a screenshot would help in that case (not sure quite how hard that is).
Anyway, I was just thinking about the logging script I started back when this thread was active. Unfortunately, I haven't made much progress due to other work on DFHack - it's taking a lot of time to get the 64-bit version working.
Did you ever test that script, by the way? (It's "acclog.lua", linked above or here (raw version) (https://raw.githubusercontent.com/lethosor/dfhack-scripts/master/acclog.lua)). It looks like it just supports the title and options screens for now. I'm not sure how useful logging to a text file is, so let me know if there's a way to improve that.
-
Hey Lethosor,
I just tested your script on OS X, which is where my only really reliable DFHack installation can be found. I could probably get it working under linux, but just need to put in the effort.
My instinct was to run "tail -f acclog.txt | say", which would have sent each line of the script to the Mac speech system as it came in. I'm not sure if it's a failure in the way the script writes its info, or what. At any rate, I heard no speech when trying this.
I confirmed that it is indeed adding new information to the end of the file with every arrow key press. Also, "say", on its own, accepts lines from the keyboard and says them with each press of Enter.
So this isn't a very encouraging start, but I'm not sure what the problem is. I'm 99% sure it isn't on your end though.
-
It's "Circumflex", not "Circonflex".
well, i only know that one from french classes and they call it that way :P
-
This is an amazing thread--and this post of mine is more for notification because I've been trying to find details and advice on this matter (for me and for my friends because inclusivity is an awesome thing I love seeing happen in more and more areas). Just a tiny PTW here. :)
-
My instinct was to run "tail -f acclog.txt | say", which would have sent each line of the script to the Mac speech system as it came in. I'm not sure if it's a failure in the way the script writes its info, or what. At any rate, I heard no speech when trying this.
Yeah, it's buffered. I think once 4 KB of text gets written to the file, it'll be spoken all at once. Obviously that's not very useful. :)
Try this:
tail -f acclog.txt | while read line; do echo $line | say; done
It's "Circumflex", not "Circonflex".
well, i only know that one from french classes and they call it that way :P
Sure enough, that's what it is in French. Whoops.
-
Thanks, Lethosor! That works as I'd expect, more or less.
It may just be a peculiarity of my setup, but I seem to move directly from "Object Testing Arena," to "Continue playing," with no "exit," option. I wonder if something weird is going on with the keyboard.
At any rate, the text is read properly, which is an excellent proof of concept, at least for the menus.
-
That's weird. What if you move up from "Continue playing"?
Anyway, one thing I noticed was that navigating the menus too quickly causes all of the intermediate options to be spoken, which takes some time. How much of an issue is that? I could try changing the script to call "say" or something else directly, which would allow it to cancel excessive lines.
-
That's weird. What if you move up from "Continue playing"?
Anyway, one thing I noticed was that navigating the menus too quickly causes all of the intermediate options to be spoken, which takes some time. How much of an issue is that? I could try changing the script to call "say" or something else directly, which would allow it to cancel excessive lines.
Nope, moving up gets me straight to "Objec Testing Arena." This is using ordinary OS X arrow keys, if that matters—don't have a number pad regularly set up on this Macbook Air.
Also odd, "Continue playing," and "Start playing," are showing up on the same screen. I could have sworn they were mutually exclusive. I haven't noticed any problems with taking too long to speak, for what that's worth, though for practical use calling a speech system directly is probably better longterm.
-
"Continue playing" appears if you have at least one world with an active game.
"Start playing" occurs if you have at least one world that is generated but has no active game.
If you have more than one world generated, both can appear.
-
Huh. I erased the data/save directory, just to be sure. I shouldn't have worlds of any kind.
-
That would be my fault. Basically, the menu items on that screen are represented by IDs stored in a list (where 0 = Continue playing, 1 = Start playing, etc.). Instead of translating IDs to descriptions properly, the script is translating the cursor position to a description instead (0 = first item, 1 = second item), which only works if all possible menu items are present.
Edit: okay, try re-downloading the script.
-
Ahh.
This works as I'd expect now, thanks for the quick fix. :)
-
Hey All,
Sorry for the double post. This is perhaps more applicable to Adventure mOde, but I wanted to pass along this link (http://forum.audiogames.net/viewtopic.php?id=19707). It's a more traditional roguelike which has been modded to be much more accessible to the blind.
I don't know how much sound/speech ability we get with mods for DF, but it's at least a thing to demonstrate the possibilities. :)
-
I'm popping here cause quite frankly you deserve a lot of respect for playing this game while blind.
And well you have my mad respects man.
-
I'm popping here cause quite frankly you deserve a lot of respect for playing this game while blind.
And well you have my mad respects man.
That and his forts are better than any of mine. and i can see. Which demonstrates a superb amount of Stubborness and Intelligence on his part
-
Hey, all,
I've been playing Cataclysm lately, which isn't DF, though does share some of the big "open world," aesthetic.
I'm dropping back in here to say that I'm still very much interested in this game, though don't know if we're better off focusing on Adventure mode for now. Considering the original age of this thread, perhaps it's appropriate that I reappear on Easter.
I do hope some more programming work might be done on some of the accessibility ideas mentioned. I wish I had the coding talent myself.
-
Glad to see u don't forget DF) 8)
I wish community help you more
-
The curses-based mode on Linux is still my best shot at playing this game, as things stand. I wish that weren't the case, as the Linux screen reader comes with some pretty hefty limitations.
The biggest issues are getting a sense of what the map looks like, and being able to explore it. The DFHack plugins mentioned earlier in this thread do quite a bit to help with that, but it's still a somewhat odd experience. I really should re-download the game. I wish there were a way to get the terminal cursor to stay in a predictable spot, that would help a great deal for adventure mode, at least.
-
doesn't "mousecontrols" have stable cursor?
-
Possibly, but as a blind gamer a mouse is mostly useless for me. :) The cursor I'm talking about isn't the DF cursor at all, it's the cursor used to "draw," windows in terminal/text print mode. I think earlier posts in this thread went into a bit more detail about the distinction.
-
I think I found a way to get the terminal cursor over the fortress mode cursor (k, q, etc.). I'm not sure about adventure mode, though. Is there a specific location you're thinking of?
-
I think I found a way to get the terminal cursor over the fortress mode cursor (k, q, etc.). I'm not sure about adventure mode, though. Is there a specific location you're thinking of?
I was wondering about having the terminal cursor over the player character, if possible. That makes most traditional roguelikes more or less playable by default. The flow would be something like, "move the terminal cursor over the PC at the end of processing every turn."
-
Just trying to keep this thread alive :)
I reinstalled DF on my Linux machine, and despite segmentation faults on startup two times out of three, I've managed to generate a world and create an adventurer. The most pressing problem right now involves the way my screen reader handles blinking characters. Every time the character blinks, it gets repeated, so I hear a constant stream of "U," "U," "u," when trying to get a feel for the map.
I can disable my program's reading of new text entirely, but that requires me to scan the screen manually every turn just in case a new message shows up. This is hardly ideal.
Unfortunately, I gather that there's no way to disable the blinking, even in text mode. I take comfort in the fact it seems kind of annoying visually too.
-
Yes, the blinking can get quite annoying sometimes. I like the way Cataclysm handles stacked items a lot better. For those who dont know: in cataclysm, the background just indicates that there is more than one item, and you have to look manually to see it. However, cataclysm also has a "list of viewable objects/monsters" screen, which I imagine to be quite useful for you. unless cata is SDL-based too?
-
Cataclysm does have an SDL version, but also has a regular Curses/console-based port. It's far more playable for me than DF is at the moment. The ability to disable blinking, and its handling of the terminal cursor, are big reasons for that. :)
-
has anyone tried involving Toady into this? i imagine he would have an idea or two...
-
I'd love to get his perspective on this, if only to see if some relatively small changes could be made to the Linux console version. Those would go a long way to making the game more pleasant. The larger, or non-console changes, might be more of a community project, since I realize this is super specialized to begin with.
-
Future of the fortress blud
-
Future of the fortress blud
Or the suggestions forum. Future of the Fortress isn't really intended for suggestions.
Anyway, disabling the blinking characters (which I assume are multiple creatures/objects on a tile or creatures with some sort of status indicator) is something Toady would probably have to do.
-
Anyway, disabling the blinking characters (which I assume are multiple creatures/objects on a tile or creatures with some sort of status indicator) is something Toady would probably have to do.
There must be a counter somewhere which the rendering code uses for blinking, so we could reset it, but I couldn't find it.
-
Anyway, disabling the blinking characters (which I assume are multiple creatures/objects on a tile or creatures with some sort of status indicator) is something Toady would probably have to do.
There must be a counter somewhere which the rendering code uses for blinking, so we could reset it, but I couldn't find it.
I was thinking about that. For all I know, though, it could be something that's used in several places that wouldn't be safe to reset (e.g. SDL_GetTicks()).
-
Would SDL_getticks be useful in the Curses display mode? I don't know much about how that API works.
-
Oh, true, that probably wouldn't work. It does seem that the flashing icons get slower as the game gets slower, at least in fortress mode. I know there's a counter for the number of ticks that have passed, which some DFHack tools use, so it's possible that Toady uses that too.
-
Oh, true, that probably wouldn't work. It does seem that the flashing icons get slower as the game gets slower, at least in fortress mode. I know there's a counter for the number of ticks that have passed, which some DFHack tools use, so it's possible that Toady uses that too.
I tried all fields in enabler and gps, nothing worked, which is strange.
-
Hey, this is still going.
This should be quite doable. There is already a utility (soundsense) that reads from the game log as stuff goes into it. And DFHack can read anything in the game and output anything to the log. So if someone makes a utility similar to soundsense that reads the log to a text-to-speech program, a lua script could handle the rest.
I'm pretty handy with lua, so I might work with that part if I get the time. It's a shame this isn't in the modding forum, since this would definitely be a modding project.
For adventure mode, this should be quite playable. Fort mode is a bit iffy, since there's so much going on at any given moment and a lot is dependent on precise positions and pathing, but it might be abstracted to a certain degree.
And given the popularity of Drunk Fortress, I can see Blind Fortress becoming a thing even among sighted players. DF players have a thing for additional challenge and novelty.
-
I volunteer to try and get Toady this way!
Do you want me to make a modding thread for this too? I havn't worked with DF mods (or any mods) before, so i cant write it, but if you tell me what kind of mod or program we need Id be happy to start a discussion about it, maybe someone will be interested.
EDIT: as i can see TheBiggerFish has already send him this way.
-
Thanks all. :)
I was checking this out of interest, and it seems I've been on here in some form or other since at least 2011. It would be nice to be able to play on my own after six years or so :)
-
Allright everyone, Toady made a statement on this matter in his latest future of the fortress reply. for your convenience I have included a copy below:
The latest discussion about blinking characters isn't as straightforward as a bit-flip -- there are a lot of interleaved timers and so forth, so it's a mess to turn it on and off, and it's also not simple to use background to convey a state like a creature on a ramp (since background colors mean different things already and we'd need to sort that out somehow). There'll be complications like this, and there might not be time to rewrite things a certain way, but I'm up for suggestions or places where I can help on my end (as opposed to mods etc.).
-
I'm afraid it's hard to make suggestions without knowing more about the internals. At the moment, my experience is limited to the "real," text-mode provided by the Linux console and my screen reader. The blinking is annoying enough that I can't really spend a lot of time in either game mode without feeling like I'm going to go insane :)
-
zkline, I sent you a PM but perhaps you haven't read it. I think I can fix the blinking problem for you but I need to know a little about your setup.
-
This thread inspired me into studying the concept of advanced interactive book.
In other words - imagine DF generation and interaction powers fitted into a text only interface that is even optimized for TTS or sort of.
When you can avoid all the tiles and just describe the location in general while maintaining great level of details.
Which, obviously, is a great load of work, but I almost can see it say, for adventure mode. Since I am that kind of player in first place.
Edit: though not saying I can see into how to make it with DF. Was rather speaking about start-with-scratch project.
-
Sorry for responding so late. I forgot about this thread. As for the flashing text in ncurses mode, I think this is probably fixable without modding DF. Basically, ncurses interfaces to the terminal using escape sequences. In Un*x (including Linux), there are many different protocols for the terminals, and you can specify the protocol using your TERM environment variable -- of course the terminal application you use has to support the protocol.
So, having said all that, different terminal applications (and protocols) have different capabilities. Flashing is one of those capabilities. If you claim that your terminal application can not support flashing, then ncurses will not send you the escape sequence for flashing characters. To do this you have to set up a custom terminfo entry for your terminal (type "man terminfo" into the console for all the gruesome details).
I've never actually played with this stuff, but I'm quite confident I could get it to work, so feel free to reply to this if you would like me to give it a go. I'm actually just out the door for a trip to Canada, but I will probably have some time starting this weekend.
-
Sorry for responding so late. I forgot about this thread. As for the flashing text in ncurses mode, I think this is probably fixable without modding DF. Basically, ncurses interfaces to the terminal using escape sequences. In Un*x (including Linux), there are many different protocols for the terminals, and you can specify the protocol using your TERM environment variable -- of course the terminal application you use has to support the protocol.
So, having said all that, different terminal applications (and protocols) have different capabilities. Flashing is one of those capabilities. If you claim that your terminal application can not support flashing, then ncurses will not send you the escape sequence for flashing characters. To do this you have to set up a custom terminfo entry for your terminal (type "man terminfo" into the console for all the gruesome details).
I've never actually played with this stuff, but I'm quite confident I could get it to work, so feel free to reply to this if you would like me to give it a go. I'm actually just out the door for a trip to Canada, but I will probably have some time starting this weekend.
Enjoy Canada. :) This sounds like a promising idea, I use the default Linux terminal type normally, of course. The idea of writing a custom terminfo entry never occured to me, I wonder if Curses would throw a fit?
-
I don't think DF uses curses blink feature or anything like that.
-
I don't think DF uses curses blink feature or anything like that.
Not even in the pure tetx mode? That surprises me. The blinking has to happen somehow, and I don't know of a way to do it on a terminal without something like Curses or Terminfo.
-
I agree with mifki here. I've only ever seen terminals that support blinking between a given character and nothing, while DF typically switches between multiple characters on a tile (and sometimes uses an animation to switch between them). As far as I can tell, DF is just redrawing any characters it needs to change without relying on the terminal's blinking capabilities.
-
My apologies if this is unrealistic or has been previously mentioned, but this thread reminded me of a sensory replacement device I recently read about (I think it was in the New Yorker, or something). It uses light electric stimulation to map visual information to the tongue, and I think a blind man uses it to rock climb. On a conceptual level, it could offer an interesting way to supplement text-to-voice if the DF map info could be effectively sent through the device (say, transmitting a 3x3 grid to the tongue displaying walls, trees, etc. and using voice for detail). Seems like the price is around $10,000 USD though, so again, unrealistic.
http://www.wicab.com/faqs
-
Hey, all. Happy 2018. Please see below for your pro forma blind DF ramblings.
More seriously, I can't seem to quit. :) I've been thinking about DF again, and just checked into DF Remote, and was greatly pleased to see it's still a going concern. At this point I believe the actual game UI is kind of a lost cause, but I remain somewhat hopeful for alternatives.
Sadly, my sensory replacement devices are overdo, so I remain more or less where I was last time. I'm trying to get into accessibility in a professional context, which is probably not all that helpful for this project, but still…
Anyway, I'm back, for… The third or fourth time? :) I've los count, and hope I'm still welcome, even if I am stubborn. ;)
-
Sorry for the double post, but…
There are a couple interesting developments today on my end. I discovered an alternative screen reader which has somewhat better control over exactly how I review the terminal than the default Mac accessibility solution. For the curious, it's called TDSR, and you can grab it from Git here (https://github.com/tspivey/tdsr). The really important thing about this program is that it keeps the review cursor positioned in the proper column when moving up and down, which my regular Mac reader struggles with..
I've also discovered what happens when you cap the FPS. As an experiment, I tested capping it at 1, and noticed that the problem of my readers announcing blinking characters was much lessened. The game is of course a lot slower, but I don't want to claw my ears off as much now. ;)
So this is at least a positive step even if it isn't a solution. I'm going to keep at it :)
-
Glad to see what topic has some progress, not so glad that i can't do anything usefull at the moment. Anyway, good luck.
-
Actually, I've managed to make considerably more progress, thanks to the folks on the DF subreddit. I've discovered that the text-mode DF plays reasonably well with my Windows screen reader. I've made inroads at a small fort with a couple stockpiles, and am hoping to make more progress today.
The blinking and terminal cursor issues still remain, but I'm feeling a lot more optimistic than I have recently. i think there is a lot of promise for the future here.
-
have you tried editing the raws to make the game way too easy, just so you can test the interface and controls?
i know this removes a lot of FUN, but it could help for a beginning.
-
I haven't. I'm not quite sure where I'd begin doing that. So far, the controls are easy enough to use, though I'm not nearly as efficient as sighted gamers would be. The ability of my screen reader to tell me color is invaluable, though I'm not quite sure what some of it means—I know Red is a blocked workshop, but what is magenta/purple? :)
The most time-consuming task is probably making sure that I know where my cursor is, bookmarks can definitely help with that if I remember to use them. The screen reader also isn't as efficient as it could be about reading tiles I'm looking at, I often have to search manually for the tile contents. I want to be able to run DFHack commands from the console, but for some reason ctrl-shift-P isn't working as I'd expect.
I need to get a demo of my setup up sometime soon, I think it might be fun/educational to show where the issues are.
-
DFHack keybindings don't work in text mode, and Ctrl-Shift-P wouldn't be possible to support in any case. You could try running command-prompt with dfhack-run, although I'm not sure if that's more convenient than just using dfhack-run by itself.
-
I thought "curses" was just the name of the tilesheet until now. Does the curses_640x300.png tilesheet come from the (n)curses wrapper or did Bay12Games create it?
-
I think that the default symbol set is based on the old DOS CP437, actually. I guess Bay12 just chose it :-) i’d be curious to know what the history behind that decision was though.
-
It is a CP437 font, but I'm not sure where it came from or if Toady made it himself. The "curses" name dates back to at least 0.23.130.23a, possibly as far back as the first version of DF, so that's well before DF supported ncurses. My best guess is that the name comes from PDcurses or another Windows curses implementation which old games like these (http://www.bay12games.com/curses/) used, possibly including old versions of DF.
Anyway, I've added the ncurses cursor control idea to the DFHack issue tracker, so hopefully it won't get forgotten.
-
You could try getting in touch with Barry Ellis (https://twitter.com/OneSwitch) - he's an expert in computer game accessibility, and a thoroughly nice guy.
-
Thanks for mentioning him. :) I'm also going to reach out to folks in the broader audio gaming community. If nothing else, more ideas are always welcome.
For the moment, I'm going to try an get a demo of my current system up. Audio is a lot easier for me to record, so you'll get to listen to the dulcet tones of my screen reader pronouncing random characters at lightning speed. :)
-
I wonder if DF might work as an 'interpreted' game?
The stories that you love about DF require a great leap of imagination to get from the screen to the narrative. The user interface is an absolute horror show from an accessibility point of view, and the user has to ignore big chunks of stuff and heavily imagineer their way around others.
But perhaps what might work would be for an experienced, sighted DF player to act as an interface to the interface. This would involve describing the environment, reporting on events, answering queries and interpreting actions. A bit like a D&D GM would, for instance, but using DF as the story engine rather than maps, dice and character sheets.
If we were smart, we could make an effort to record the requests and responsse, with a view to at some point using machine learning techniques to replicate the interpreter. And who doesn't want voice-controlled fortresses!
Obviously the big difficulty is having intepreters generous with their time (probably not that hard actually) and synchronising player and interpreter session times (tougher). An alternative would be to conduct them asynchronously, e.g. via the forum, but you might get a glacial pace then.
-
I wonder if DF might work as an 'interpreted' game?
Sure it can work. It's a matter of make "building blocks" made of functions. Game data is available, so one level of interpreting is to display them in a 2D ascii graphics despite that game data is in 3 dimensions.
There are some tools existing such as in DF Remote that sends a cube of x, y, and z coordinates of the map already with every object in it.
So those "building blocks" are low functions. Simple info such as "what is the location of the object", "is it hostile", "is it food", "is it a weapon".
Then there needs to be some mid function that encapsulates an object that is more summarized for the user.
An example, "House of Urist". It is 3x3 room. Wood floors. Stone walls. Stone roof. It has a willow wood bed, a granite coffer, a copper cabinet. It has clothes inside the cabinet. There is a backpack on the floor with 2 rations, and waterskin with 3 units of drinks. Where it is located in the map.
How much detail will the user need to know is putting those low functions of the objects into a summarized chunks of digestible "audio".
Another a "Goblin Lasher." It is hostile, it has a whip, and in xyz location.
A higher level function is to provide data for the user how "House of Urist" is related to "Goblin Lasher."
If the goblin just entered the map, then not much relation with the house.
When the goblin moves closer, then House of Urist can help provide a point of view on where the goblin is in the map.
Machine learning is nice and all, but I think a framework to allow users to define these object relationships, save them for future use and re-use will be more practical.
The stories that you love about DF require a great leap of imagination to get from the screen to the narrative. The user interface is an absolute horror show from an accessibility point of view, and the user has to ignore big chunks of stuff and heavily imagineer their way around others.
True. But Toady does not create the stories either. He provides all these data to intermingle. The stories come from users reading the info and making their on connections.
So there is no need to try to make sense of the data by code. Just need to make those text and data object make sense using audio output that describes game things that are presented in 3 dimensions.
But perhaps what might work would be for an experienced, sighted DF player to act as an interface to the interface. This would involve describing the environment, reporting on events, answering queries and interpreting actions. A bit like a D&D GM would, for instance, but using DF as the story engine rather than maps, dice and character sheets.
Fortress mode is already like this. The game story in on-going. The 7 starting dwarfs will go hungry and thirsty by themselves and hunt vermin and drink murky water without user action from game start.
Let's start with a scenario with a default embark that has food, drinks, building materials. Enable auto-labor even.
Well we start with 7 dwarfs, and a wagon in xyz. How will the player want to interact with the game?
The answer will the provide coders how to approach it.
If we were smart, we could make an effort to record the requests and responsse, with a view to at some point using machine learning techniques to replicate the interpreter. And who doesn't want voice-controlled fortresses!
Obviously the big difficulty is having intepreters generous with their time (probably not that hard actually) and synchronising player and interpreter session times (tougher). An alternative would be to conduct them asynchronously, e.g. via the forum, but you might get a glacial pace then.
Time goes fast when you're having fun.
-
I've definitely had fun playing DF with a friend acting as my "eyes and hands," so to speak. It's a thing I want to get back into. Granted, this requires people who's schedules match up—not always a given, and a way to exchange info.
DF-Remote intrigues me because it's on iOS, and iOS had a well-developed accessibility system already. All in all, I'm in favor of multiple ways to access the game, and the text-mode system is just one of them, though probably the most complete so far.
-
I've mentioned this already to you I think but will repeat here for everyone. Are you interested only in "complete" DF experience, or you're ok with some simplification and automation? As you probably know, there's even a DF-AI project which plays the game by itself. But in our case, since the biggest problem is the map, I can imagine, for example, instead of working with each tile separately, building a fortress using pre-defined blocks like a puzzle. You choose a block type, which includes digging, placing buildings and assigning them, and then where to place it relative to already present blocks.
That's just one idea and also I realise other blind players may want different level of detail and control, but still it's a big difference whether something like this is acceptable or not.
-
Speaking for myself, some simplification is okay as long as it doesn't detract too much from the…richness of the experience. I wasn't aware of DFAI. I do know that there will be some blind people who would much prefer the full game, however.
-
You could try getting in touch with Barry Ellis (https://twitter.com/OneSwitch) - he's an expert in computer game accessibility, and a thoroughly nice guy.
Thanks. I contacted him and he also included some other guys in the conversation who may know more about blind accessibility. We'll see where this gets us.
-
Here (https://www.dropbox.com/s/titufvllwvgwxxj/DF%20Windows%20Demo.mp3?dl=0) is a somewhat rambling demo of text-mode Dwarf Fortress with the Jaws for Windows screen reader. The Embark screen is an accessibility nightmare, but I'm otherwise pretty happy with how things turned out. I apologize for the poor audio quality.
Edit: Here's (http://dffd.bay12games.com/file.php?id=13505) a DFFD link. :)
-
nice voice. the reader would be way too fast for me to even get a glimpse of what it reads. i guess you're used to it, but i think i'd just get really frustrated listening to it.
-
Re: Character 9619
This page (https://www.andmine.com/ascii-codes-html-table-reference/index.php?start=9000) refers to 9619 as a character that looks like a chess board, a grid of alternating color and white.
Looking at the DF wiki, tile types (http://dwarffortresswiki.org/index.php/DF2014:Tile_types_in_DF_memory), that character could be a stone wall that is partially mined.
-
I'm interested in the Windows screen reader software itself.
And I am curious if it can be customized; or even if there are open source that can be used to make modifications or similar projects.
Links, names should be enough to so I can google stuff while it's slow at work, or I'm free to do other stuff while at home.
-
Re that odd character, I suspect that my program is misidentifying the number, somehow. I've run into that kind of thing before. A partially-mined wall doesn't make a lot of sense, considering I hadn't done any mining at that point.
The program I was using is called Jaws for Windows. It's not open source at all, but has a proprietary scripting language. Here (http://www.freedomscientific.com), have a 40-minute demo. :)
There is an open-source screen reader called NVDA (https://www.nvaccess.org), but its default handling of the cursor makes playing DF and roguelikes in general a lot more difficult. This might be something that you could change with scripting, but I'm not sure how.
-
zkline:
I haven't read this whole thread yet, but I got far enough to know you were trying to use DFTerm at one point years ago. I wanted to point out that as long as you are still using the 32-bit version of the game, that the Server will still work, and I have been updating the list This post here (http://www.bay12forums.com/smf/index.php?topic=50643.msg7694806#msg7694806) covers up to 0.44.05.
I put a poll up here (http://www.bay12forums.com/smf/index.php?topic=169853.0) asking if people were still using the DfTerm Server, because I wasn't sure if I was just being a nuisance. Feel free to let me know if this is helpful for you.