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.4%)

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

211 (32.7%)

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: 642

[Truean]

Spoiler (click to show/hide)

The ctrl+f5 key combo has a bit of history behind it.

Stonesense and Dwarf Fortress are both 32bit programs. what this means is that they have a memory usage limit of 2Gb, no matter what your system has.

Originally, Stonesense ran separately from Dwarf Fortress, in it's own process. This meant that it had that 2GB for itself, and if it crashed, it just crashed itself, and DF was fine. Unfortunately, this uses very slow system calls to read the memory from DF, which meant that things tended to run slow in general.

Then a bunch of things happenned. The first was stonesense becoming multi threaded. This meant that the DF memory could be read at the same time that SS was busy drawing pretty pictures. But this meant that two copies of the viewed area of the fort needed to be loaded at once. This meant double the memory usage, but it also was double the speed, so it was good.

However, enough changed with stonesense that the full screenshot no longer worked. I didn't really feel up to the task of getting it to work again, so I disabled it. the main problem was that the loading was no longer sequential, so it was like deciding that you want to cook for 10 times the number of people, while your minion is already at the store buying groceries.

Then DFhack changed, and stuck itself into Dwarf Fortress directly. This means direct access to DF's memory, which means much faster reads, and SS can now read much more than it was able to before. Things like dwarf inventories and mist all came from this.

Unfortunately, the downside of this was that because they are both the same program, the 2GB memory limit is shared between DF and SS, which means when I finally went and fixed the large screenshot feature to work again, the fort pretty much had to be loaded into memory twice, once for DF itself, and once for stonesense. This means that if your fort takes more than a single GB, which most do, then trying to do a full screenshot will cause a crash as everything runs out of available memory. The solution to this was to disable the screenshot feature again because having a crash button is bad.

Finally Caldfir came along, my hero, and fixed the screenshot feature so that it uses far, far less memory than before, making things not crash, making the only limit the size of the resulting image, because videocards have their own limits, but zooming out fixes that, at the cost of detail. This is what the latest version of stonesense uses, but I don't know at which specific version it was implemented, but I can only assume that the version you are using was before this.

I see, thank you very much for this.

Question: Would the latest version of stonesense run on DF 31.25? If so, then downloading it should be a simple fix?

[Rose]

Sadly, it won't. Backporting stonesense to an older DF is possible, but may not be necessarily easy.

[Truean]

Sadly, it won't. Backporting stonesense to an older DF is possible, but may not be necessarily easy.

Understood and appreciated. I'll have to backdoor in large scale screenshots. Will do . Should only take a few hours with a large fort.

[Isher]

Sorry to sound impatient (I am not, really) what does the timeline look like for .11 release? Waiting on DFHack first? Out in a few days/weeks/months? I saw someone linked to Japa somewhere saying soonish but I can't tell if that comment's been walked back some (and I can't currently find it).

[Rose]

waiting on DFhack release.

[guitarxe]

I've heard of some kind of large address aware "patch" for DF floating around. What effect would that have on SS and the out of memory issue with the CTRL+F5?

[SalmonGod]

I've heard of some kind of large address aware "patch" for DF floating around. What effect would that have on SS and the out of memory issue with the CTRL+F5?

Here's the original thread for that.

[chrisadams3997]

Also, if we're going to be using blender for making items, we should keep a template file so that everybody has the same lighting between items.

I'm cleaning up my default file right now and can upload it.  I've got the light source (a 'sun' lamp) setup as well as the camera, and I've got a few reference objects sized for walls and floors already in there, and I'm working on the basic geometry for all the different ramp configurations.  Having all that ironed out and standardized would make it easier for others to develop rendered sprites, and keep them halfway compatible, no doubt about.

[Truean]

Here we have four z levels in frame. The topmost level is reserved almost exclusively for utilities, water and power. In the new version, this would be where minecart tracks would be laid. Minecart "stations" would surface over where they would otherwise cross water lines, thereby avoiding infringement.
The bottom three are a "super z level"

What you're looking at is a test fill of the water system at the dual intake from the stream (which for some reason always shows up as ice). Notice the artificial lake/wilderness slowly filling up. The water there is pouring down, from a room with a floor drain, three z levels. Various tunnels connect the otherwise segmented portions of the artificial lake. It is possible I will place dwellings under the bottom of the lake with glass windows or ceiling tiles looking up through the clear water.... Undecided as of yet.

This is just an unsaved test fill of the system, which works perfectly to date and provides water all the way across the entire map, to the bathhouses and hospital.

Question: why does the stream show up like that? Is it something I'm doing or? Not very important and just a "for looks" question, so back burner priority.

[Rose]

Regarding the streams, that, right there, is what we in the industry call a bug.

[chrisadams3997]

Alright, soon as I started playing with ramps, I realized quickly that my very simple lighting solution used for the walls (moving a single sun lamp until I got roughly the right affect) wouldn't hold up under different angles:

Spoiler (click to show/hide)

Epic Fail. lol.

But... not being one to give up, I've been playing around with different lighting setups and now have a rather satisfactory one I think.  It uses one main sun/hemi lamp with three others for highlights from specific directions to mimic the lighting traditionally used for blocks and ramps in stonesense:

Spoiler (click to show/hide)

And for comparison, side by side with the traditional pixel art:



And of course, The Blender File, anyone feel free to play with it and let me know if you come across any problems with different types of geometry than what it was tested in.  The scene includes all the lights and the camera, is setup for 128x128 renders, but that's easy to change, and two pieces of geometry, one being called "Block" (visible by default), that is the correct size and position to make walls out of, and "Floor"(hidden by default), which happens to equal the difference between the height of the block and the height of a perfect cube (the wall is not a cube, it's shorter), and is positioned above the "Block".  That's to use it easily for boolean operations for things like ramps where you have to separate the top from the bottom (see the sprite sheet for them if you don't know what I'm talking about, it'll make more sense), but it can also be moved down to the xy grid to actually use for modeling a floor out of it.

Once I make all the basic geometries for the different ramps, I'll post them in blender files so they can be appended to the default scene easily.

[MarcAFK]

... that granite is freaking beautiful, just letting you know.

[Rose]

Incidentally, I still havent figured out what happenned to the ramp tops.

[chrisadams3997]

Incidentally, I still havent figured out what happenned to the ramp tops.

Yeah... I've wondered about that... but I've kind of gotten used to it by this point.

Edit:
Working on these, not ready to show in stonesense yet as I've got to clean up edges in paint shop to make them tile better -- the downside of using complex geometry -- but making some progress:

Spoiler (click to show/hide)

[arclance]

It's been awhile since I have run stonesense in dfhack and when I tried today I just get a black window which can only be closed by killing Dwarf Fortress (with die or pkill).

Here is a backtrace of stonesense crashing with dfhack v0.34.10 r1.

Code: [Select]

./dfhack -g
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /media/Linux_Data/Dwarf_Fortress/Test_Fortress/0.34.X/df_34_10_linux/df_linux/libs/Dwarf_Fortress...(no debugging symbols found)...done.
(gdb) run
Starting program: /media/Linux_Data/Dwarf_Fortress/Test_Fortress/0.34.X/df_34_10_linux/df_linux/libs/Dwarf_Fortress
ERROR: ld.so: object './hack/libdfhack.so' from LD_PRELOAD cannot be preloaded: ignored.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

(Dwarf_Fortress:24615): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libaurora.so: wrong ELF class: ELFCLASS64
[New Thread 0xf45ceb70 (LWP 24630)]
[New Thread 0xf3dcdb70 (LWP 24631)]
Loading bindings from data/init/interface.txt
New window size: 1600x500
Font size: 20x20
Resizing grid to 80x25
Resizing font to 20x20

Resetting textures
[New Thread 0xf2e7db70 (LWP 24637)]
[New Thread 0xf267cb70 (LWP 24638)]
DFHack is ready. Have a nice day!
Type in '?' or 'help' for general help, 'ls' to see all commands.
[DFHack]# [New Thread 0xf1e7bb70 (LWP 24639)]
                                             stonesense
[New Thread 0xe3cffb70 (LWP 15659)]
[New Thread 0xe34feb70 (LWP 15660)]
Stonesense launched
Using allegro version 5.0.5 r1
[DFHack]#
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xe34feb70 (LWP 15660)]
__pthread_mutex_lock (mutex=0xd2d2d2d2) at pthread_mutex_lock.c:50
50 pthread_mutex_lock.c: No such file or directory.
(gdb) bt full
#0  __pthread_mutex_lock (mutex=0xd2d2d2d2) at pthread_mutex_lock.c:50
        __PRETTY_FUNCTION__ = "__pthread_mutex_lock"
        type = <optimized out>
#1  0xf74b07d6 in pthread_mutex_lock () from /lib32/libc.so.6
No symbol table info available.
#2  0xf6aea10f in ?? () from /usr/lib32/libX11.so.6
No symbol table info available.
#3  0xf6b009c4 in XrmQGetResource () from /usr/lib32/libX11.so.6
No symbol table info available.
#4  0xf6af7f7d in XStringToKeysym () from /usr/lib32/libX11.so.6
No symbol table info available.
#5  0xf6b26c45 in _XimParseStringFile () from /usr/lib32/libX11.so.6
No symbol table info available.
#6  0xf6b30f39 in _XimLocalOpenIM () from /usr/lib32/libX11.so.6
No symbol table info available.
#7  0xf6b1df3d in _XimOpenIM () from /usr/lib32/libX11.so.6
No symbol table info available.
#8  0xf6b09f0a in XOpenIM () from /usr/lib32/libX11.so.6
---Type <return> to continue, or q <return> to quit---
No symbol table info available.
#9  0xf304880e in xkeybd_init_keyboard ()
   from ./stonesense/deplibs/liballegro.so.5.0
No symbol table info available.
#10 0xf300e05b in al_install_keyboard ()
   from ./stonesense/deplibs/liballegro.so.5.0
No symbol table info available.
#11 0xf30e0825 in stonesense_thread(ALLEGRO_THREAD*, void*) ()
   from /media/Linux_Data/Dwarf_Fortress/Test_Fortress/0.34.X/df_34_10_linux/df_linux/hack/plugins/stonesense.plug.so
No symbol table info available.
#12 0xf301328f in thread_func_trampoline ()
   from ./stonesense/deplibs/liballegro.so.5.0
No symbol table info available.
#13 0xf30469b6 in thread_proc_trampoline ()
   from ./stonesense/deplibs/liballegro.so.5.0
No symbol table info available.
#14 0xf73bdc39 in start_thread (arg=0xe34feb70) at pthread_create.c:304
---Type <return> to continue, or q <return> to quit---
        __res = <optimized out>
        __ignore1 = <optimized out>
        __ignore2 = <optimized out>
        pd = 0xe34feb70
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-147005452, 0,
                4001536, -481303528, -1082275920, 1459860888},
              mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0},
            data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#15 0xf74a351e in clone () from /lib32/libc.so.6
No symbol table info available.