Print

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

[Sinned]

Great work Toady, keep it up

Still I'm not touching it till some of those Military issues are fixed. :/ Kinda disappointed those are so low priority it seems Defending myself is pretty high up my list.

[Dark_T_Zeratul]

Just had a mayor die.   

He did NOT get replaced (2 seasons)...  All military stopped working.   Cannot appoint new military people or replace current ones.  Cannot create a working squad anymore.

Did you start a new fortress, or load an old save? Toady said that while he fixed the mayor issue he couldn't do anything about existing duplicate mayors in old saves.

[Corbald]

For those having issues with a black/blank screen when using partial print, try PARTIAL:0, instead of PARTIAL:1/2/whatever. Seems to work for me, though I had terrible screen tearing or blinking issues with previous versions when using that settings. If you DO have tearing/blinking, try using the VSYNC setting. I'm getting roughly twice the FPS with this new version and PARTIAL:0. That's roughly 20gfps and less than (10cps) up to 30-40gfps and (20cps) where gfps == graphical frames per second, and (cps) == cycles per second, or 'the one in brackets.'

[greycat]

Running on Linux (Arch for those wondering) went just fine for me right up until a seemingly random segfault somewhere around midwinter

Me too, on Debian 5.0 (with a few backported packages -- I know I've backported libvorbis and libogg in particular).  Segmentation fault, core dumped.  (I don't have core dumps disabled as you appear to have.)

Code: [Select]

(gdb) bt
#0  0x1f543d28 in ?? ()
#1  0x0868ca56 in equip_infost::upgrade_squads ()
#2  0x086900d1 in equip_infost::upgrade_squads_as_necessary ()
#3  0x086d21cd in advanceplot ()
#4  0x082063ee in viewscreen_dwarfmodest::logic ()
#5  0xb7317a58 in interfacest::loop ()
   from /usr/local/src/df_linux/libs/libgraphics.so
#6  0x083c751f in mainloop ()
#7  0xb72f8bc5 in enablerst::async_loop ()
   from /usr/local/src/df_linux/libs/libgraphics.so
#8  0xb72f909d in call_loop () from /usr/local/src/df_linux/libs/libgraphics.so
#9  0xb7700f7b in ?? () from /usr/lib/libSDL-1.2.so.0
#10 0x00000000 in ?? ()
Looks like another military bug.   Anyway, that's gotta be better than nothing.  I hope it can help.

Just in case it's relevant, here are the libraries it's using:

Code: [Select]

griffon:/usr/local/src/df_linux$ ldd ./libs/Dwarf_Fortress
linux-gate.so.1 =>  (0xb77a2000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb76df000)
libgraphics.so => /usr/local/src/df_linux/libs/libgraphics.so (0xb72ac000)
libstdc++.so.6 => /usr/local/src/df_linux/libs/libstdc++.so.6 (0xb71bd000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7197000)
libgcc_s.so.1 => /usr/local/src/df_linux/libs/libgcc_s.so.1 (0xb7188000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb702d000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7014000)
libasound.so.2 => /usr/lib/libasound.so.2 (0xb6f51000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6f4d000)
libdirectfb-1.0.so.0 => /usr/lib/libdirectfb-1.0.so.0 (0xb6ee6000)
libfusion-1.0.so.0 => /usr/lib/libfusion-1.0.so.0 (0xb6ede000)
libdirect-1.0.so.0 => /usr/lib/libdirect-1.0.so.0 (0xb6eca000)
libvga.so.1 => /usr/lib/libvga.so.1 (0xb6e69000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb6add000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb6aa1000)
libopenal.so.1 => /usr/lib/libopenal.so.1 (0xb6760000)
libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0xb6704000)
libSDL_image-1.2.so.0 => /usr/lib/libSDL_image-1.2.so.0 (0xb66e9000)
libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb6667000)
libncursesw.so.5 => /lib/libncursesw.so.5 (0xb6628000)
/lib/ld-linux.so.2 (0xb77a3000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb661f000)
libx86.so.1 => /lib/libx86.so.1 (0xb661c000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb6604000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb657e000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb6573000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb6533000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb6444000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb6441000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb643e000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6439000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb641d000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6419000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb6364000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb62f8000)
libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0xb62a5000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6280000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb6261000)
libtiff.so.4 => /usr/lib/libtiff.so.4 (0xb620c000)
libz.so.1 => /usr/lib/libz.so.1 (0xb61f7000)
libGL.so.1 => /usr/lib/libGL.so.1 (0xb6194000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6168000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb615a000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6151000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb614e000)
libXi.so.6 => /usr/lib/libXi.so.6 (0xb6146000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb6140000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6136000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb610f000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb609a000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb6098000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6080000)
libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb6056000)
libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0xb6052000)
libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0xb604b000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb6022000)
libogg.so.0 => /usr/lib/libogg.so.0 (0xb601c000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb6016000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb600e000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb5fe8000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb5fe5000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb5fe0000)

[LordMelvin]

Okay, slight hitch with my download of the Linux version...

64bit Ubuntu 10.04 on an acer aspire one netbook, 1.6ghz 64 bit atom, 2 gigs ram, gma 950

from a fresh download, for simplicity's sake:

31.04:

double-clicking on the df script starts dwarf fortress (and there was much rejoicing, until I went to 'create squad on the military screen...)
terminal command df from the df_linux folder gives the results of a df command anywhere (any reason not to change that script name? anything calling back to it?)
calling the 'df' script with its full path starts dwarf fortress, with some terminal feedback re:sound selection, etc.

by contrast, in 31.05

double-clicking on the df script does nothing
terminal command df from the relevant folder gives the Diskspace Free results of a 'df' command on any unix system.
running the script from the folder with the full path so as to avoid that bit of system confusion results in this error:

Code: [Select]

./libs/Dwarf_Fortress: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory

I attempted to symlink libncursesw.so.5 from /lib to df_linux/libs with no change.

Anyone else have similar issues? problems? solutions?

[Ratboy]

For those having issues with a black/blank screen when using partial print, try PARTIAL:0, instead of PARTIAL:1/2/whatever. Seems to work for me, though I had terrible screen tearing or blinking issues with previous versions when using that settings. If you DO have tearing/blinking, try using the VSYNC setting. I'm getting roughly twice the FPS with this new version and PARTIAL:0. That's roughly 20gfps and less than (10cps) up to 30-40gfps and (20cps) where gfps == graphical frames per second, and (cps) == cycles per second, or 'the one in brackets.'

Yeah, that made it work ~100-110 fps - same as standard mode.

[greycat]

terminal command df from the df_linux folder gives the results of a df command anywhere (any reason not to change that script name? anything calling back to it?)

Even if you renamed it to DF or something, it still wouldn't work like that.  You need to type ./df (or ./programname in general) to run a program in the current directory in Unix.  This is for security reasons.  Someone might put a malicious "ls" command (or "sl" etc. to catch typos) in a common directory like /tmp.  Then, later when someone (hopefully root) stumbles across it and accidentally runs it, their trap is sprung.  Omitting the current directory from the search path is the only workaround that avoids both of those problems.

[LordMelvin]

Even if you renamed it to DF or something, it still wouldn't work like that.  You need to type ./df (or ./programname in general) to run a program in the current directory in Unix.  This is for security reasons.  Someone might put a malicious "ls" command (or "sl" etc. to catch typos) in a common directory like /tmp.  Then, later when someone (hopefully root) stumbles across it and accidentally runs it, their trap is sprung.  Omitting the current directory from the search path is the only workaround that avoids both of those problems.

thanks! The more you know...

of course that doesn't help with the main problem, the shared library not found issue

[Baughn]

Ratboy: You're supposed to say "PRINT_MODE:2D", not PRINT_MODE:PARTIAL:2D, or whatever you're doing. That would just confuse it.

[Footkerchief]

Ratboy: You're supposed to say "PRINT_MODE:2D", not PRINT_MODE:PARTIAL:2D, or whatever you're doing. That would just confuse it.

Yet another reason to have a real interface for the init options.

[Djohaal]

Ratboy: You're supposed to say "PRINT_MODE:2D", not PRINT_MODE:PARTIAL:2D, or whatever you're doing. That would just confuse it.

Yet another reason to have a real interface for the init options.

Actually I think someone with the coding skillz could set up a simple external .exe UI to configure the init settings... it would be a nice addon, maybe it could even save init profiles for fort swapping and yadda... It would need to be updated whenever the core init changes however.

[balrogkernel]

in 0.31.05 i threw a skeletal yeti and a zombie alligator into the magma pit in the arena.  they don't die, they just keep making smoke. 

[Leperous]

Even if you renamed it to DF or something, it still wouldn't work like that.  You need to type ./df (or ./programname in general) to run a program in the current directory in Unix.  This is for security reasons.  Someone might put a malicious "ls" command (or "sl" etc. to catch typos) in a common directory like /tmp.  Then, later when someone (hopefully root) stumbles across it and accidentally runs it, their trap is sprung.  Omitting the current directory from the search path is the only workaround that avoids both of those problems.

thanks! The more you know...

of course that doesn't help with the main problem, the shared library not found issue

http://www.bay12forums.com/smf/index.php?topic=57492.msg1287565#msg1287565

Install that (those?) and then type sudo ldconfig to refresh the library cache thingystuff.

[Taranli Maren]

running the script from the folder with the full path so as to avoid that bit of system confusion results in this error:

Code: [Select]

./libs/Dwarf_Fortress: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory

I attempted to symlink libncursesw.so.5 from /lib to df_linux/libs with no change.

Anyone else have similar issues? problems? solutions?

I have this same problem.  After I created a symlink (to /lib/libncursesw.so.7) I instead get the following error,

Code: [Select]

./libs/Dwarf_Fortress: error while loading shared libraries: libncursesw.so.5: wrong ELF class: ELFCLASS64
I also have Ubuntu 10.04 64-bit.

Edit: Solved this by installing the lib32ncursesw5 package in Synaptic Package Manager, as suggested above.  Don't need the symlink either.

[Hippoman]

posting for updates. and to download soon.