Print

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

Faster than 40d, no problems

42 (26.1%)

Faster than 40d, problems

72 (44.7%)

No slower than 40d, no problems

14 (8.7%)

No slower than 40d, problems

16 (9.9%)

Slower than 40d, no problems

2 (1.2%)

Slower than 40d, problems

3 (1.9%)

Doesn't work (please explain)

12 (7.5%)

Total Members Voted: 160

[kutulu]

I voted 'does not work' but have since managed to hunt up all of its odd library dependencies(d11 included the startlingly old libc it wanted, but did not include the strangely new libtiff -- not that it even uses libtiff!).  It seems rather faster now but more testing is obviously required.

The libtiff issue is well known.  Blame Debian (I think) for renumbering the libraries to be different from the upstream, but libtiff.so.4 == libtiff.so.3 for any recent libtiff.

As for libc -- it doesn't ship a libc, but it does ship a libstdc++, but it also works just fine with the libstdc++ from gcc 4.4, so I'm not sure why you even had to think about it.

[Baughn]

I thought Veroule was also doing a piece?  He messaged me about updating the keyboard stuff again, and some other things I think, but I didn't know if that was coming up this time specifically and I don't know how often you guys write each other about things.  I could set up something with the current patches sometime in the next few days if there's nothing else headed my way.

Creating a shared library is the main thing. All the other changes are things we can do so much faster if we had that; I, for one, am waiting until I get closure on that patch before doing anything else.

Although the ICC stuff is nifty. That's fundamentally orthogonal, though; it doesn't affect the code in the least, just the build process.

[Sabotage]

I'm not sure if this is a problem with this version or I'm missing something.

Whenever I gen a map, or use a pre-genned (pre this version) map and find a location with a magma pipe evident (enabled to be shown in the embark profile) I cannot for the life of me find the said pipe when I actually embark. On one map I went to the lowest Z level and mined in every direction... nothing. No caps, no evident pipe on the surface and yet even the finder says there's a pipe there. This has happened twice now in this version. I went to D10 and tried it with a new map as well as the pregen one I was using and I could clearly see the pipe no matter where I went.

This is Mac OSX if that matters.

[Dogun]

Heads up, in the linux version:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:"./libs"

FYI, if LD_LIBRARY_PATH is null, the string becomes ":./libs" which means "current directory" and "./libs" - probably not what was intended.

[Dogun]

I voted 'does not work' but have since managed to hunt up all of its odd library dependencies(d11 included the startlingly old libc it wanted, but did not include the strangely new libtiff -- not that it even uses libtiff!).  It seems rather faster now but more testing is obviously required.

The libtiff issue is well known.  Blame Debian (I think) for renumbering the libraries to be different from the upstream, but libtiff.so.4 == libtiff.so.3 for any recent libtiff.

As for libc -- it doesn't ship a libc, but it does ship a libstdc++, but it also works just fine with the libstdc++ from gcc 4.4, so I'm not sure why you even had to think about it.

And if you want to make it work without poluting your system, try something like:
ln -s /usr/lib/libtiff.so.3 /path/to/dwarffortres/libs/libtiff.so.4

[Veroule]

I am actually very well along with the updates for the keyboard.  I have everything I was aiming at writing tested and debugged.  The final stages included some more optomizing/cleaning of the loop code, and that is just about done as well.  I should have a patch fully asssembled by the end of the week.

One of the things I found is that this patch may not fix all the layout issues.
When I was testing setting up the bindings the SDL didn't behave as expected.  I created the binding for '*' and the keysym that SDL gave with the event was '8' instead of '*' .  The documentation for the SDL seems to indicate that it should have produced '*' as the keysym.  I am not too concerned about this since anyone can rebind such keys, but at some point I will see if I can fix it.

The issues with accented, circumflexed, etc. characters should all be fixed.  It should be if you can type it, you can bind it.

[kutulu]

I voted 'does not work' but have since managed to hunt up all of its odd library dependencies(d11 included the startlingly old libc it wanted, but did not include the strangely new libtiff -- not that it even uses libtiff!).  It seems rather faster now but more testing is obviously required.

The libtiff issue is well known.  Blame Debian (I think) for renumbering the libraries to be different from the upstream, but libtiff.so.4 == libtiff.so.3 for any recent libtiff.

As for libc -- it doesn't ship a libc, but it does ship a libstdc++, but it also works just fine with the libstdc++ from gcc 4.4, so I'm not sure why you even had to think about it.

And if you want to make it work without poluting your system, try something like:
ln -s /usr/lib/libtiff.so.3 /path/to/dwarffortres/libs/libtiff.so.4

Or, even easier, install your distro's copy of the SDL_image package, which is the only reason DF even needs libtiff to begin with, and get rid of both local libs in one step.  I've removed every library from the df/libs folder except fmodex, and that's only because I can't find a Gentoo x86-emul package with fmod in it.

--K

[Baughn]

Indeed. I'll do my very best to get DF into Portage proper come next release (eg. non d-series).

[Andir]

Indeed. I'll do my very best to get DF into Portage proper come next release (eg. non d-series).

I'd hope that it's more than a 40e release though.

[Elvin]

I don't suppose there's a way to make this compatible with Mike Mayday's graphics? I get migraines looking at the regular models, but those ones seem to be okay with me. So, is there a way to do it? I am not at al experienced with graphics mods, so I have no idea what i'd have to do.

[kutulu]

I don't suppose there's a way to make this compatible with Mike Mayday's graphics? I get migraines looking at the regular models, but those ones seem to be okay with me. So, is there a way to do it? I am not at al experienced with graphics mods, so I have no idea what i'd have to do.

Someone posted directions earlier in this thread on how to do it, but the basic idea is:

* Convert all of Mayday's .bmp files to .png files
* Edit all of Mayday's .txt files that reference *.bmp to reference *.png
* Install a stock 40d11 copy of df
* Replace the entire raws and data/art and data/graphics folders with the ones from the Mayday build.

There are more details, including specifically which files to convert and which files to edit and what folders to copy where, in the earlier post.

--K

[kutulu]

Indeed. I'll do my very best to get DF into Portage proper come next release (eg. non d-series).

Not sure it's portage-ready, honestly.  Even if there was an emul package for fmod, and all of the lib/ folder hijinks were gone, the problem still remains that you have to install and run DF as the same user because the binary, data, and user data files all go into the same place.

--K

[FlexibleDogma]

I don't suppose there's a way to make this compatible with Mike Mayday's graphics? I get migraines looking at the regular models, but those ones seem to be okay with me. So, is there a way to do it? I am not at al experienced with graphics mods, so I have no idea what i'd have to do.

Someone posted directions earlier in this thread on how to do it, but the basic idea is:

* Convert all of Mayday's .bmp files to .png files
* Edit all of Mayday's .txt files that reference *.bmp to reference *.png
* Install a stock 40d11 copy of df
* Replace the entire raws and data/art and data/graphics folders with the ones from the Mayday build.

There are more details, including specifically which files to convert and which files to edit and what folders to copy where, in the earlier post.

--K

Mike Mayday has 40d11 up now, no muss no fuss:
http://mayday.w.staszic.waw.pl/df.php

[Baughn]

Indeed. I'll do my very best to get DF into Portage proper come next release (eg. non d-series).

Not sure it's portage-ready, honestly.  Even if there was an emul package for fmod, and all of the lib/ folder hijinks were gone, the problem still remains that you have to install and run DF as the same user because the binary, data, and user data files all go into the same place.

I have ways.

[Slinkyfest]

Hermm, just downloaded the latest version df_28_181_40d11_win and every time I attempt to run dwarf fortress.exe it crashes on me. Full or windowed. Never had this issue before. Wondering if its because I have a new monitor. Running at 1360x768. Windows XP Pro. In the windows error report it states that the following file is to blame (or related to the issue?)

C:\DOCUME~1\Josh\LOCALS~1\Temp\bd0d_appcompat.txt

Just moved to the new place and I would dearly love to butcher some kittens for their sweet, delicious flesh.... mrhmmmm delicious kitty stew... *cough* Right, anyways, thoughts? Perhaps changing the resolution will help. Imma do that now actually. Be right back

EDIT 1:

Nope changing the resolution, it does nothing! Went from 800x600 and up and Im getting the same error message. Oh, and apologies if this should go in the bugs section however as it was using the speed-modded version I figured it was appropriate. Now I have the resolution set to 1920x1080. Im going to try older versions now.

EDIT 2:

Even with the unspeed-modded version im getting the same error... Sigh, this bites. Ah well, back to the drawing board. Any by drawing board I mean staring at the wall.