Print

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

I consider it an essential part of Dwaf Fortress, and can't play without it.

119 (18.5%)

I use it for pretty screenshots, but otherwise don't use it during play.

210 (32.6%)

I only try it occasionally.

174 (27%)

I have no idea why I'm even in this thread, I don't use it.

141 (21.9%)

Total Members Voted: 641

[Kishmond]

Stonesense is crashing both itself and DF when run. The window comes up showing an initial view, but I guess it's crashing when trying to update it live. Is there a static version or something I can run? I just want to take screenshots.

None of the logs show relevant info, and I definitely have the latest Visual C++ stuff.

[PeridexisErrant]

Is there a static version or something I can run? I just want to take screenshots.

Armok Vision might be good for you.

[DragonDePlatino]

Hey, I've got a question! If someone created a Stonsense tileset optimized for the 8-bit colorspace (256 colors) and ran Stonesense in 8-bit color mode, would it speed up the program's performance?

[therahedwig]

I don't actually think so because graphics cards these days are not optimised for 256 colours... But I guess it take less ram...?

Then again, I didn't program this, maybe Japa will prove me wrong

[Rose]

Stonesense hasn't had an 8-bit color mode for years.

the very very old version did, though, and that might have helped, but now everything is done using 3D acceleration, and that would not effect anything.

[DragonDePlatino]

Ah, that's a shame. I've actually spent the day wrestling with the 8-bit palette, and it's disheartening this wouldn't actually improve anything.

[utunnels]

Ah, that's a shame. I've actually spent the day wrestling with the 8-bit palette, and it's disheartening this wouldn't actually improve anything.

Bit it looks good anyway. So it is not all for nothing. 

[Rose]

It might be possible to write a shader that can use 8-bit images to change colors of things, but I wouldn't know how to do that.

[Fugsnarf]

I've looked around and haven't found an answer to this, so I'll just post it here. I'm really enjoying Stonesense, but the dwarf sprites have been bothering me as they aren't the clean, pixely dwarf sprites I've seen in just about every screenshot. Instead they appear to be taken from this folder labeled large_128 and sized down. I'm not sure what this is, but I just want my dwarf sprites that are in dwarves.png. This is what my game currently looks like: http://puu.sh/hORma/c77cb5e62e.png

The dwarves are not very pretty. Is there a simple solution to this? I've done a good bit of fiddling around and can't figure it out. By editing the index file to block out large_128 and include clothed_Dwarves.xml, color_Dwarves.xml, and Dwarves.xml I came up with this: http://puu.sh/hORO4/5e27e39335.png

The sprites I have that I want are these: http://puu.sh/hORVq/e683b28394.png

[Rose]

Something like those dwarves are still there, but they may have to be added to the index.txt.

I can't tell you what to add till monday.

Also the current dwarves, you can zoom in with . And ,  to see all the details like their clothing.

[Dirst]

As the mod-management functionality of starter packs improve, they are leaving behind the tools like Stonesense that use their own folders for data.  I hope this is a relatively straightforward fix, and re-usable for other projects like Armok Vision, but would it be possible to put save-specific Stonesense data somewhere in the raw folder?  I'm not sure if it should be tucked away inside raw/graphics or off to the side like raw/visualizers, but just a way to have an index and relative file structure of items that supersede the generic stuff in the main stonesense folder.

Basically, replicate what DFHack does with its raw/scripts folder.  That will allow modders to include content for the visualizers that's portable enough for a starter pack to handle intelligently.

The only complication is what to do with the top-level index in the save folder.  It might be easier for the visualizer to scan all .txt files for indexes rather than depend on the starter pack merging the indexes properly.

[Rose]

Thing is, there's no real reason to have a different stonesense config per save. If a save doesn't have something, it just won't show up.

Of somebody mods in pet dragons with custom scale shearing workshops, and makes stonesense graphics for them, they just have to be added to the same stonesense config as everything else, and they'll be use for any scale shearing workshops it finds.

the only thing you would have to do to merge a separate pack with the rest would be to add a folder to the central index. Doesn't need to have the same folder structure of stock stuff.

[Dirst]

Thing is, there's no real reason to have a different stonesense config per save. If a save doesn't have something, it just won't show up.

Of somebody mods in pet dragons with custom scale shearing workshops, and makes stonesense graphics for them, they just have to be added to the same stonesense config as everything else, and they'll be use for any scale shearing workshops it finds.

the only thing you would have to do to merge a separate pack with the rest would be to add a folder to the central index. Doesn't need to have the same folder structure of stock stuff.

Yeah, I don't really foresee a player having radically different graphics in different saves, so it's kinda overkill as a feature.  This is entirely to make the mod-manager folks comfortable with handling visualizer data.  They're fine with arbitrarily complicated file structures within raw/, but anything outside of that folder risks them becoming responsible to maintain N different custom merge logics, and I understand their hesitation there.

The functionality I'm envisioning is a spot inside the raw/ folder that Stonesense scans for indexes without requiring all mods to be in the same index.txt file, and understanding relative paths from (1) that spot and (2) the generic content store.  That lets the mod manager import the content, and it allows two independent mods to co-exist without any complicated text merging.  To comport with player expectations, per-save stuff should have precedence over generic stuff.

I'm not sure who is going to want Awakened Stones and Daleks in the same game, but it shouldn't fall to the player to merge indexes by hand.

The most complicated use-case could be putting beards on female dwarves.  That requires taking precedence over the generic DWARF creature, but ideally referencing the assets that already exist in the standard location.

Any per-save awareness wouldn't push out widely until a new version of DFHack is published (probably with the next version of DF itself), so there's every reason to think this through and make sure it's a mechanic that's lightweight for the devs and works well for Armok Vision etc. that will consume similar data.

[Bakaridjan]

I've finally built a fortress that I would like to look at so I downloaded DFHack with Stonesense for Mac. It's loading fine and I can see a small section of my fort, but none of the keys seem to be working. I can move around with the arrow keys and up and down Z-levels with "<" and ">" but that's it. Without being able to zoom out, I can't really get any of the views I want. I searched but couldn't find much info about Mac and keybindings. Is this a known issue or do I have a unique problem? Or, more likely, am I missing something painfully simple about how to work my keyboard. Thanks for any help with this.

[lethosor]

It's a known issue. Input has never worked on OS X, and nobody really knows enough about Stonesense and Allegro to fix it. Japa was talking about moving Stonesense to a separate process, probably using remotefortressreader like Armok Vision, which should fix that as well as the frequency/severity of Stonesense crashes (which wouldn't bring down DF).