Print

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

That's right

That is right

[Cult of the Raven]

I would be really excited if Stonesense had a lot more complete zoo of animals. I hate that questionmark, but I don't have time to draw things myself. Also, the ability to easily make custom workshops.

[EBannion]

Stonesense wo'n't work for me...

I unzipped the .rar of the most recent Slate version and put the folder on my desktop (which I usually do, to make sure things work before finding them a permanent home) and ran the stonesense.exe, and it immediately tells me that 'Stonesense has stopped working' and does its usual windows 7 'searching for a solution to the problem'.

I have tried putting the Stonesense folder in my DF folder as well, and I have tried running it as administrator. What am I doing wrong? Please help - this is a beautiful tool, and I ca'n't believe I have gone so long without using it! DF is open, and I have my game loaded, and I've tried while it is both paused and unpaused.

[Dante]

My (non-technical, just greedy) perspective, for what it's worth.

1) Displaying Mist Tiles:

I guess this would be more useful now with forgotten beasts, but still inly important in some fairly specialised settings, e.g. waterfall megaprojects, miasmatic hell fortresses, Everything Is On Fire, etc. Would be nice to have, though, like everything on the list.

2) Zooming In/Out:

I mainly use Stonesense for screenshots, so this would be a very useful feature. I'm not sure about the need for an additional bird's eye view. I guess if you wanted a schematic you could annotate in order to show a sequence of events, and didn't want to take a video?

3) Full Object Display:

In the light of the usefulness of Stonesense for screen capture, this would make it cross the line between 'very useful' and 'most useful' 3rd party df tool, for me.

export pretty screenshots with all the innumerable details.

Yes yes yes yes yes yes.

4) Better Object Tiles:

I don't know about any of the technical stuff, of course, but even a surrounds-check hack would be an improvement (assuming it didn't damage fps too much, for those who are using it 'live').

5) Better Auto-Coloring Palette:
6) "Oversized" Tiles:

Interesting, but I'm not personally too fussed about these (assuming I understand the payoffs correctly).

In short, a render function (with zooming and full object display) would be first on my wishlist for the next direction in Stonesense dev.

[Jiri Petru]

6) "Oversized" Tiles:
For the present engine, breaking up Ramp gemoetries into a Bottom and Top segments is needlessly complex, and creates uneccesary extra/separate sprites for the engine to display for a given tile object. Allowing for Tiles/Floors that were oversized by, perhaps, 8 transparent pixels on every egde (+16 pixles wide/tall) would both allow for some flexibity in creating non-cubic tiles (ala Beefmo's new stone tiles), single-graphic ramps (rather than splitting them between a "floor" and a "tile".

Oh yes, please. I really want oversize trees that look like proper trees, not like dwarf-size bushes. I might even try to draw some 

[kaypy]

3) Full Object Display:
Though framerate would be crippled if Stonesense were to render every object in realtime, could we create a static "Full-Rendering" mode that would show every barrel, stone, bloodstain, stockpile, bin, sock, and so on in a static view? This would keep the game smooth for people who are using SS paralell ti DF as an in-game visualizer, while also allowing people who want to export pretty screenshots with all the innumerable details.

Actually, we had this working in the previous version, and you can get full object display with pretty negligible framerate impact. You just need to cache things rather than trying to read everything all the time. The algorithms are all ready in the objects branch. It just needs to be rejigged for the newer DFHacks (assuming object support is back)

6) "Oversized" Tiles:
For the present engine, breaking up Ramp gemoetries into a Bottom and Top segments is needlessly complex, and creates uneccesary extra/separate sprites for the engine to display for a given tile object. Allowing for Tiles/Floors that were oversized by, perhaps, 8 transparent pixels on every egde (+16 pixles wide/tall) would both allow for some flexibity in creating non-cubic tiles (ala Beefmo's new stone tiles), single-graphic ramps (rather than splitting them between a "floor" and a "tile".

One thing to bear in mind here is that anything "behind" must be drawn before anything "in front". Across levels, this means anything below must be drawn first. If a sprite crosses levels, then the bottom half must be drawn with the bottom level, and the top must be drawn with the top level. Thus two separate sprites.

Also, on the topmost level displayed, you really don't want to draw the entire ramp, just the bottom half. The alternative looked bad with extra ramp bits poking up all over the place.

[Djohaal]

I think earlier in the queue should be some way of cycling rotation of stairs and other directional sprites so we can have properly algined stuff with our fort's architecture. I don't wanna be a nitpicker, but I find the current solver for alginment of stairs incapable of figuring out my fort's architecture.

[Gabriel A. Zorrilla]

there's your problem.

you need 4.9.19

Carp! Compiled the latest Allegro 4.9.20 and still getting this error:

In file included from /opt/stonesense/Block.h:3,
                 from /opt/stonesense/Block.cpp:1:
/opt/stonesense/common.h:34:27: error: modules/world.h: No such file or directory
make[2]: *** [CMakeFiles/stonesense.dir/Block.cpp.o] Error 1
make[1]: *** [CMakeFiles/stonesense.dir/all] Error 2
make: *** [all] Error 2

[Rose]

Here's a list of Graphical Display issues, suggestions, concepts, etc. for the consideration of the team, and for open discussion.

1) Displaying Mist Tiles:
Vapor clouds, like steam, miasma, magma-mist, etc, do not display as yet. I recall an earlier branch with particle mist on a beach, but haven't seen it since. Can mists be displayed, and if so are they handled with some simple catch-all that can pull appropriate colors and all that, or must different mist IDs be handled individually? I'd rather like to use textured alpha-tinted cubes if possible rather than particles, but either work.

The previous mist support was in 40d. The guys doing DFHack have not yet figured out how they work in the new DF version yet.

2) Zooming In/Out:
Being able to change the zoom level to get a closer picture, or zoom out to get a larger overland picture would be very nice for high-res screens that display at finer resolutions, or lower-res screens that. Is it possible with the current engine? If so, what sort of difficulties are in the way of changing the zoom level? Alternatively, there is the potential for doing an alternate Bird's Eye terrain map, using a set of tiny isometric tiles that would display a much larger area?

This is... complicated. it's possible, but would require either a major re-write, or expensive work-arounds.

3) Full Object Display:
Though framerate would be crippled if Stonesense were to render every object in realtime, could we create a static "Full-Rendering" mode that would show every barrel, stone, bloodstain, stockpile, bin, sock, and so on in a static view? This would keep the game smooth for people who are using SS paralell ti DF as an in-game visualizer, while also allowing people who want to export pretty screenshots with all the innumerable details.

As soon as DFhack supports items (there's partial support right now, just not sure the status on it) Stonesense will... probably.

4) Better Object Tiles:
Many object tiles, like plants, boulders, or pebbles, define the nature of the tile they're on (plants default the tile to grass [VEGITATION], pebbles to stone, etc.) However, plants grow in the desert, and when they are harvested, the tile below it is discovered to be sand, and not grass. Are plants, boulders, etc. treated as Floors to DF? Can we retrieve tile-type information (Dirt, Sand, Grass) in addition to the object type in the tile? Can we only know that the tile contains a Dead Plant, or can we know that it is a Dead Plant on Sand, or a Live Grass tile? If we can't get more tile details, would it be possible for SS to check, when displaying one of these tiles, for whatever tile type made up the majority of adjacent tiles, and estimate what the floor under it should be? It'd be similar to the Gem/Ore Vein display concept. Objects that override tile type that I know of are Dead Plant, Live Plant, Tree/Cactus/Mushroom, Boulder, Pebbles, and perhaps Webs. There may be more now too. Same concept would work for creating Floor-type Brook Tiles (they could pull from the material of the Tile type they're on top of).

Currently, Stonesense can read the tiletype, and the material the tile it's made from. the tiletype shows weather it's a boulder, a tree, etc, and the material says weather it's made from peat or sand. Currently, the only way to guess weather there should be grass under it is to make assumptions based on soil type, but that wouldn't work well. The Gem/Ore display works differentley, in that there's actually up to 3 materials being defined per tile. Floor-type brook tiles, on the other hand, are doable.

5) Better Auto-Coloring Palette:
I'd rather like to standardize the Autocoloring Palettes used to colorize greyscale tiles, dwarves, etc. Where are these colors defined, and is it possible to redefine them on the user's end, similar to how colors can be redefined in the DF raws? If there's nothing else for it, I could take one of the programmers aside and discuss color theory, and brainstorm some equations for shifting Hue, Value, and Saturation to create a series of 8-color gradients from a palette of single, pre-defined RGB color values.

Currently, colors are defined in three places: colors.xml, which defines RGB values for whatever materials are defined, the init.txt, which defines the 16-color pallet that is the same as in DF, and RGB values taken from DF. the 16-color pallet is used for dwarf labor colors, and the RGB values taken from DF are used for skin and hair.

All coloring is done via multiply blending at the moment, because any other blending type would require me to write openGL shaders, which I don't know how to do.

6) "Oversized" Tiles:
For the present engine, breaking up Ramp gemoetries into a Bottom and Top segments is needlessly complex, and creates uneccesary extra/separate sprites for the engine to display for a given tile object. Allowing for Tiles/Floors that were oversized by, perhaps, 8 transparent pixels on every egde (+16 pixles wide/tall) would both allow for some flexibity in creating non-cubic tiles (ala Beefmo's new stone tiles), single-graphic ramps (rather than splitting them between a "floor" and a "tile".

As stated before, splitting up tiles is the only way to ensure that the draw order is correct.
enlarging tiles by 8 pixels on each side is doable, but can cause draw-order issues.

there's your problem.

you need 4.9.19

Carp! Compiled the latest Allegro 4.9.20 and still getting this error:

In file included from /opt/stonesense/Block.h:3,
                 from /opt/stonesense/Block.cpp:1:
/opt/stonesense/common.h:34:27: error: modules/world.h: No such file or directory
make[2]: *** [CMakeFiles/stonesense.dir/Block.cpp.o] Error 1
make[1]: *** [CMakeFiles/stonesense.dir/all] Error 2
make: *** [all] Error 2

Stonesense it currently using some allegro version between 4.9.19 and 4.9.20. it would require me to spend a little time with it to get it to work with 4.9.20+
I'll get to it eventually. >_>

[EDIT]
Also, the only thing stopping me from displaying blood right now is lack of blood sprites, and.. hm... actually, I think I have some.

[Andir]

Also, the only thing stopping me from displaying blood right now is lack of blood sprites, and.. hm... actually, I think I have some.

...Just happen to have some laying around? :p

[Maxxeh]

I'd happily draw some, and i'm sure other people would too! I think variety would be the biggest challenge.
having different blood sprites for each facing, so a 6 tile pool of blood would connect to eachother would look nice. is it possible to have various sprites for each thing?

So a blood smear/splatter could have 10 different sprites for example, so it doesn't get repetitive. 

I'm going to assume that having a splatter facing a different direction depending on where it came from is impossible

also, blood colour change = vomit   lol

[Rose]

I'll see what I can manage, but what is likeley: puddles of blood will probably be connected with neighboring ones, they will probably be able to be colored according to what type of blood it is, and I will also be able to shade it according to how much blood is on the tile, or use a different sprite for more blood, either one.

[peterix]

Well, what we have on blood coverings:
it's a one-channel bitmap on top of the map blocks... so a set of such bitmaps, one for each type of covering. This can be anything the material system supports - there are a few 'static' types like mud, vomit or cave-in rubble and then there are the crazy new things... we have some little info on blood, because that's pretty common. No guarantees on modded stuff tho. If someone adds a new type of liquid, there's a pretty good chance there won't be a way to detect that easily.

So it's possible to know that there's something like snow, vomit or cat blood on a tile, and the amount of stuff. No idea about colors tho. The 40d compatible versions had a few preset covering types with fixed colors, but now it's all crazy.

[jaked122]

I love the visualizer, but I don't think that toady wants there to be a remote interface for Dwarf Fortress, that is if I remember DFTalk correctly.

[Rose]

yeah, snow is already used, and I'm working on getting more out of it.

[Gabriel A. Zorrilla]

Stonesense it currently using some allegro version between 4.9.19 and 4.9.20. it would require me to spend a little time with it to get it to work with 4.9.20+
I'll get to it eventually. >_>

<_<
>_>

I'll try 4.9.19 at home, there is no in-between version.