Topic: FotF: Dwarf Fortress 40d17 (Read 124840 times)

Baughn · « **Reply #165 on:** February 08, 2010, 04:39:25 am »

Well, the problem is libgcc/libstdc++. If the installed version is different from the one DF was compiled against - not older, just /different/ - things then tend to mess up and crash.

Of course, they tend to mess up and crash anyway, so maybe it's just because I have no clue whatsoever how to distribute binary software on linux. I've never found any guide on how to do it.

isitanos · « **Reply #166 on:** February 08, 2010, 05:02:37 am »

Quote from: Baughn on February 08, 2010, 04:39:25 am

Well, the problem is libgcc/libstdc++. If the installed version is different from the one DF was compiled against - not older, just /different/ - things then tend to mess up and crash.

Of course, they tend to mess up and crash anyway, so maybe it's just because I have no clue whatsoever how to distribute binary software on linux. I've never found any guide on how to do it.

They have at least one good thread on that at StackOverflow: http://stackoverflow.com/questions/1209674/shipping-closed-source-application-for-linux/1242738#1242738

According to this guy the famous $ORIGIN option also loads libraries in your custom path before looking in the system folders, so after all I don't know if it would fix the problem on Ubuntu 9.10.

Maybe link against an older version of libgcc/libstdc++ that you can find in the Linux Standard Base: http://ldn.linuxfoundation.org/lsb/make-your-app-portable ?
Any linux user can install the lsb, so it could be the solution. Of course, I don't know if using the lsb will limit you in your choice of other libs.

The other solution is to have volunteers package DF for the popular linux distros and find specific workarounds for each of them; courageous users of less mainstream distros can be left to struggle with the source code (who knows, might actually be easier

)

Malicus · « **Reply #167 on:** February 08, 2010, 06:14:25 am »

I have a bug that nobody seems to have reported yet, even though I pretty much only embarked before getting distracted with other things. When pressing two arrow keys to try to move the cursor or view diagonally (that is, the standard arrow keys OR the numpad arrows (in either state of numlock)), only the vertical arrow seems to register if they are both pressed at once. If an arrow key is held and the cursor/view has already started moving in that direction, then holding an arrow key on the other axis moves diagonally (in a stair step sort of manner, as it is registering both directions being held rather than converting it to diagonal movement, but this is what happens in 40d16) as expected. Moving diagonally using the 1/3/7/9 keys on the numpad works fine.

Edit: I'm on Windows XP, for whatever it's worth.

Baughn · « **Reply #168 on:** February 08, 2010, 06:58:53 am »

"Any linux user can install the LSB" simply isn't accurate, unfortunately. In particular, it doesn't exist on Arch, meaning at least that I wouldn't be able to run DF.

It also doesn't include most of the other required libraries, so usability is definitely questionable.

One other option I've been thinking about is to write a script that compiles DF (well, libgraphics) on first run, including any missing dependencies. That might work better, but it'd be a lot of work.. ah well.

The other option is to simply bundle *every* library, preferably by statically linking them. I'll look into that first.

==

Malicus: I've noticed, and am looking into it. Should be fixed soon.

Jesus05 · « **Reply #169 on:** February 08, 2010, 07:35:24 am »

Anothe interest BUG

When i try Legend->Export detailed map->Standart biom+site map
Game write "Export of colloumn 1 complete" and nothing hapens...
i wait some time and click ESC game say "Export of colloumn 2 complete"

then i try clicking other key, one click

+one to complete collumns i cilck?click, click ... 267 collumns and i gather normal bitmap in may game directory.

Phwoar · « **Reply #170 on:** February 08, 2010, 08:08:57 am »

Quote from: Baughn on February 08, 2010, 06:58:53 am

The other option is to simply bundle *every* library, preferably by statically linking them. I'll look into that first.

I believe most libraries are distributed under LGPL, which I believe means, if you're not aware, that if you want to statically link them, you also need to release your code under at least an equally unrestrictive license, which Toady doesn't.

I don't see a huge problem with how it's done now. LD_LIBRARY_PATH works as intended. It makes sense for your software to always check its own surroundings for named libraries before checking default system libraries. What if I had a package called libgraphics installed in /usr/lib/? I definitely wouldn't want that to take precedence over our libgraphics in df_source/libs.

LD_LIBRARY_PATH is clunky, but it's not the reason that isitanos is having trouble.

Baughn · « **Reply #171 on:** February 08, 2010, 08:20:08 am »

That is not exactly true.

LGPL simply specifies that the code has to be easily replacable, not how it happens. As it turns out, libgraphics' source code *is* available, and the SDL bits can be replaced simply by recompiling libgraphics. That's good enough for the license.

Phwoar · « **Reply #172 on:** February 08, 2010, 08:52:09 am »

I've re-checked, and I'd say you're right.

SDL is released under LGPL 2.1, which fits your interpretation. LGPL 3 is apparently more pervasive, per what I thought, in that code that interacts with the library also needs to be available under the LGPL.

May be worth checking if any of the other libraries used are released under v3.

Footkerchief · « **Reply #173 on:** February 08, 2010, 09:30:10 am »

alway reports a crash on the farm plot screen:

Quote from: alway on February 05, 2010, 03:38:06 pm

While playing d17, I went to set up plants to be planted, went from b(summer) to c(autumn), hit enter and game crashed. Hitting enter may or may not have to do with it, as I was doing it very quickly.

Edit: upon further investigation, it appears to be due to the c menu having less items than the b menu. By default, when going from b to c, there is no option selection as there should be (and as there is in d16). Hitting enter when there is no item selected likely causes some sort of null pointer issue.

Edit 2: investigating even further, it seems the issue also happens whenever going from a larger menu to a smaller with an element farther down on the list than the last element of the new list (for example plump helmet on b is farther down than the last item on lists a,c, and d, and likewise plump helmets on c are farther down than the last element of d, ect).
Fix should be relatively simple, just add code which does something similar to:
Code: [Select]
if(currentPosition > newList.length) newPosition=newList[end]

Someone else in there confirmed it too.

Baughn · « **Reply #174 on:** February 08, 2010, 09:47:13 am »

You should mention the bug in the DF bug forum; it's not a libgraphics problem. However, doing so is probably pointless right now.

==

I'd only be linking SDL and libsndfile statically, both of which use the LGPL 2.1 license, so no problem there.

Bdragon · « **Reply #175 on:** February 08, 2010, 10:13:59 am »

Quote from: Jesus05 on February 07, 2010, 10:58:52 pm

RepeatKey + Stock->Stones.
When select in stock Stones it take many time and for this time work Repeat when time is go Cursos is far away from Stones (if its no so Big time and cursor no check again Stones then it stay Infinity)

I see this as well. It's like it's starting the repeat timer too early -- anything in the stocks screen that takes a bit to compute will cause the cursor to jump to another item when trying to move the cursor to it.

I'm seeing a similar problem with map movement. I have a rather slow-running fort (5-9 fps with lag bursts), and in the new version, switching z levels (which sometimes causes pauses of over a second if I'm not paused) causes the camera to shoot up into the sky or down several z-levels. The same thing is happening for horizontal scrolling during laggy times.

Additionally, sometimes after pausing, the framerate stays low (13-20ish?) forever after pausing, instead of jumping back up to 102-103 after a few seconds. (I've always assumed the few seconds of low framerate after pausing on this fort is due to chronic pathing issues -- total population is 247, about half of it animals, and I have some major chokepoints in my highest-traffic path.) Going to the zoom screen or announcements screen seems to fix this.

Forgot to add-
This is on Linux. (Gentoo, 40d17.)

Jamp · « **Reply #176 on:** February 08, 2010, 11:12:26 am »

I finally got df git compiled (32 bit chroot) to debug with symbols, but gdb reads none and file says that binary is stripped. I guess I am doing stupid things, but can't get it working.

build log:

Spoiler (click to show/hide)

SConscript:

Spoiler (click to show/hide)

when I reproduce bug, bt throws just a bunch of mem addresses..

Baughn · « **Reply #177 on:** February 08, 2010, 11:56:26 am »

The DF executable is stripped, libgraphics is not.

At least the last few frames of the backtrace should have names. Post the whole thing anyway, okay?

Baughn · « **Reply #178 on:** February 08, 2010, 02:09:45 pm »

Input change: When returning input, future key-repeats are now set relative to the current time, not when they were *supposed* to happen; this means the repeat rate may vary, which is apparently desirable behavior in case of lag. I was wondering.

Further, by taking greater care to keep distinct keypresses distinct, you no longer lose diagonal movement if you press down and left simultaneously.

Linux users get first crack, as usual.

CobaltKobold · « **Reply #179 on:** February 08, 2010, 03:41:06 pm »

Quote from: Baughn on February 08, 2010, 09:47:13 am

You should mention the bug in the DF bug forum; it's not a libgraphics problem. However, doing so is probably pointless right now.

It's your input code, since this cannot happen in d16, as I pointed out in that thread.

News:

Author Topic: FotF: Dwarf Fortress 40d17 (Read 124840 times)

Baughn

Re: FotF: Dwarf Fortress 40d17

isitanos

Re: FotF: Dwarf Fortress 40d17

Malicus

Re: FotF: Dwarf Fortress 40d17

Baughn

Re: FotF: Dwarf Fortress 40d17

Jesus05

Re: FotF: Dwarf Fortress 40d17

Phwoar

Re: FotF: Dwarf Fortress 40d17

Baughn

Re: FotF: Dwarf Fortress 40d17

Phwoar

Re: FotF: Dwarf Fortress 40d17

Footkerchief

Re: FotF: Dwarf Fortress 40d17

Baughn

Re: FotF: Dwarf Fortress 40d17

Bdragon

Re: FotF: Dwarf Fortress 40d17

Jamp

Re: FotF: Dwarf Fortress 40d17

Baughn

Re: FotF: Dwarf Fortress 40d17

Baughn

Re: FotF: Dwarf Fortress 40d17

CobaltKobold

Re: FotF: Dwarf Fortress 40d17