Print

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

[Random_Dragon]

That's what the orographic precipitation is supposed to do, unless something else is going on.

So that's the obvious cause eliminated, I assume? Good to see at least.

[Veroule]

I looked at the chroot stuff...  and it just said "then you build the kernel as usual".  I never did that (installed Ubuntu from an iso), so I don't really know what to do.  I'm not sure I'm Linuxy enough to accomplish any of these methods.

This reference might help: https://wiki.ubuntu.com/DebootstrapChroot

[Khym Chanur]

Burned most of the day trying to fix the worlds with the same seed that produce different results...  it's hard to tell when it has been narrowed down.

Running a worldgen on Linux under Valgrind I got a lot of "Conditional jump or move depends on uninitialised value", so it might be an unitialized memory problem. If you compile on Linux with the flags set to generate debugging info then you can get Valgrind to give you function names, file names and line numbers where it happens.  Even if those aren't the cause of the bug you're looking at you should fix them anyways, since they might start causing bugs in the future.

[FantasticDorf]

Burned most of the day trying to fix the worlds with the same seed that produce different results...  it's hard to tell when it has been narrowed down.  I turned off trade and it went away, but that doesn't mean trade is responsible -- it could be something in how the goods are produced, or how the resource types are decided, or the populations creating the goods (those all seem not to be the cause, but it only happens 1 out of 4 times once trade is off, so it's difficult to pick up the right problem).   And so on.  It's hard to nail these down, but hopefully I can find the root cause and sort it out.  Presumably there's some difference in initial conditions, some outside factor (like a clock call), or some out-of-bounds situation somewhere, but I haven't found anything obvious yet.

To have a guess and just throwing out a suggestion as to what your problem might be, generating/deciding all the objects spontaneously or in some kind of order by picking out what's been sold already on the list might have something to do with it. If you've got to apply the CPU to bring these objects into being (given that wagon clutter does contribute to total fortress clutter, as per caps on seed gathering when wagons are docked up) and maintain them moving inside a 'container' (going to be a bumpy ride moving across so many tiles, given that lots of water in oceans can only bear to sit still in a stable manner) then also the memory aspect of having to allocate all those items appropriately to the relevant tags and load them in if they were sold to the trader, a quite hefty task though not exactly groundbreaking.

My suggestion to test this out, is to remove all explicit entity tags that affect trade (all the tool tags too besides from common domestic pack/pull so that trade can still come in), that should help you narrow down at-least one cause by means of deduction (as you mention it might be other factors outside that bear upon trade) and identify core industries that might cause a spanner in the works.

Meat and wood without trade agreements are relatively uncommon goods on the screen and a good place to start if entity tags are bare.

[soulsource]

You definitely need just one version of the -dev packages, as those contain architecture independent headers and should therefore be the same for amd64 and i386.

That's just not true.

Ooops, sorry. I don't know how I got that mixed up. On Debian based distributions the -dev packages do indeed contain more than just headers - they also hold the static libraries, which of course are architecture dependent. But still, if one doesn't statically link, having one version of -dev packages should suffice.

[mifki]

You definitely need just one version of the -dev packages, as those contain architecture independent headers and should therefore be the same for amd64 and i386.

That's just not true.

Ooops, sorry. I don't know how I got that mixed up. On Debian based distributions the -dev packages do indeed contain more than just headers - they also hold the static libraries, which of course are architecture dependent. But still, if one doesn't statically link, having one version of -dev packages should suffice.

They're putting them to the right places, or something... it won't find libs unless proper packages installed. But of course that's just a package management issue, you can get libs from anywhere else (even from the same conflicting packages), put them anywhere and configure paths - that's just not the easiest way for Toady.

[Toady One]

Running a worldgen on Linux under Valgrind I got a lot of "Conditional jump or move depends on uninitialised value", so it might be an unitialized memory problem. If you compile on Linux with the flags set to generate debugging info then you can get Valgrind to give you function names, file names and line numbers where it happens.  Even if those aren't the cause of the bug you're looking at you should fix them anyways, since they might start causing bugs in the future.

I should set that up again.  I'm not sure it'll run fast enough without optimization, and their page says "Use of -O2 and above is not recommended as Memcheck occasionally reports uninitialised-value errors which don't really exist," but in this case...  false positive probably less likely than me screwing something up.

...

It's world gen trade, unfortunately, which is completely different.

I did find one issue with dance skill application at the end, which caused the seed to jump the rails, but that happens after world gen is over when it is finalizing the sites.  There's still a problem, and hopefully I can fix it today.

edit: Fixed the world gen trade problem and had a medium 100y generate the same way three times, so perhaps that's good for now.  Have valgrind running -- it's pretty slow, but manageable, and it seems to be logging further points of interest, so I'll keep messing with that for a bit before trying chroot.

[Max™]

Did another bitness comparison with 25k pop cap instead of 15k like the first time, went to 300 years instead of running for a set time.

Spoiler (click to show/hide)

Code: [Select]

test64
start: 10:38:30
stop: 10:54:01
finished: 10:54:34 (year 300)
16:04 total worldgen

64 bit pops:
>60553 Dwarves
>32485 Humans
>51199 Elves
>36119 Goblins
>5738 Kobolds
>Total: 186094

Code: [Select]

test32
start: 10:56:30
target: 11:12:01 (year 286)
stop: 11:13:24
finish: 11:14:05 (year 300)
18:05 total worldgen

32 bit pops:
>54795 Dwarves
>28097 Humans
>45384 Elves
>27181 Goblins
>8280 Kobolds
>Total: 163737
Wound up with 23k higher population on the 64 bit world despite finishing nearly 2 minutes earlier than the 32 bit world. The extra two minutes were all from year 286 to 300, which is yet another data point towards the later years being faster on 64 bit.

[ChangelingVenom]

Did another bitness comparison with 25k pop cap instead of 15k like the first time, went to 300 years instead of running for a set time.
...
Wound up with 23k higher population on the 64 bit world despite finishing nearly 2 minutes earlier than the 32 bit world. The extra two minutes were all from year 286 to 300, which is yet another data point towards the later years being faster on 64 bit.

Thanks Mat for the !!SCIENCE!! C:

[int_ua]

I looked at the chroot stuff...  and it just said "then you build the kernel as usual".  I never did that (installed Ubuntu from an iso), so I don't really know what to do.  I'm not sure I'm Linuxy enough to accomplish any of these methods.

If you already have 64bit Ubuntu installed these commands should setup the needed chroot for you (replace trusty with precise everywhere if you want 12.04 instead of 14.04):

Code: [Select]

sudo apt-get install ubuntu-dev-tools
mk-sbuild --arch=i386 trusty # Currently, first time it needs to be executed twice, unfortunately, please comment if you know how to omit this.
mk-sbuild --arch=i386 trusty

# Allowing the same home folder to be used
echo "$HOME                 /home/$USER  none  rw,bind  0  0" | sudo tee -a /etc/schroot/sbuild/fstab
Then you can use the chroot with just

Code: [Select]

schroot -c trusty-i386After that command you should be in the same home directory, but in a different ubuntu "installation", where you can install a completely different set of packages (well, in that case it will be the same set, but with different arch) and should be able to build the game with the same script you've used before. But notice that it won't have sudo by default, you'll have to manage it with another command, executed from the main system, not inside the chroot (using a different tab or TTY for that may be convenient):

Code: [Select]

sudo schroot -c source:trusty-i386 -u root
In my case the basic chroot took only 670 Mb of space:

Code: [Select]

$ sudo du -sh /var/lib/schroot/chroots/
670M    /var/lib/schroot/chroots/
With default bash prompt settings ($PS1) you should easily differentiate between chroot and non-chroot sessions by a prefix in parentheses:

Code: [Select]

(trusty-i386)~ $
If you don't have 64bit Ubuntu installed yet, I'd recommend Lubuntu http://cdimages.ubuntu.com/lubuntu/releases/trusty/release/ in this particular case, because it's still have a desktop UI but that takes much less resources.

[Toady One]

I already followed the instructions before trusty replaced precise...  hopefully that's not a huge issue.  I installed the packages that came up, and I have a build running.  I'm not sure if there are going to be problems at link, but promising so far!

edit: http://www.bay12games.com/dwarves/redist/df_32test_linux.tar.bz2

This doesn't run from the 64-bit linux (can't find libSDL-1.2.so.0 and many others -- due to missing i386 versions?  not sure).  From inside the chroot, it only runs if I switch to TEXT mode, and the audio fails.  I'm not sure how much of that has to do with the configuration of the chroot vs other problems, or what I can fix.

[SatelliteOfLove]

Thanks again for all of the hard work, Toady (et al.).  Players who are normally on Linux-based machines (such as myself) sincerely appreciate it.

[Cexp]

http://www.bay12games.com/dwarves/redist/df_32test_linux.tar.bz2

Seems to work for me on 32-bit Ubuntu Saucy (13.10), at least as well as the previous release did in terms of needed libs (SDL and audio do work).

[int_ua]

I already followed the instructions before trusty replaced precise...  hopefully that's not a huge issue.

Not an issue at all for 9 months, until April 2017: https://wiki.ubuntu.com/Releases

This doesn't run from the 64-bit linux (can't find libSDL-1.2.so.0 and many others -- due to missing i386 versions?  not sure).  From inside the chroot, it only runs if I switch to TEXT mode, and the audio fails.  I'm not sure how much of that has to do with the configuration of the chroot vs other problems, or what I can fix.

It works great, including sound, world generation and embark tested on the same 64bit system with 32bit libraries I've used to play DF before. I'm sure it's the missing i386 libraries in your case. As for running in the chroot - yeah, because there's no graphical server (X server) in the chroot and it doesn't have access to the one that's on the main system. Not sure how to make it work with graphics from chroot, do you need it for testing?

[Toady One]

Nah, I just wanted to post what I was seeing in case it was broken.  So I guess that's it for 32?  I'm messing around with valgrind some more for the day, and I can pull together a giant all-versions official release for tomorrowish to see how painful it is.