Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 10 11 [12] 13 14 ... 53

Author Topic: Fortress Overseer 0.70.1 - !Open Source! 3D Visualizer - 31.25-34.11 Support  (Read 373562 times)

thewonderidiot

  • Bay Watcher
    • View Profile

Apparently I did something stupid again: I assumed that the error related to libOpenThreads.so since that was a newer file than the one in the normal Overseer. But apparently it wasn't the cause of the problem, the error persists:
Code: [Select]
Drawing z-level 140
Error reading file: DataInputStream::DataInputStream(): The version found in the file is newer than this library can handle.
Overseer/DFO: line 3:  7549 Segmentation fault      ./Overseer

Gah... apparently you can't use models saved with newer versions of OSG with older versions -_-; If you're okay with not having fortification tops or stairs, deleting the models in the models folder will let Overseer run. I'll port back the older models (or build the latest OSG) when I get the chance.
Logged

Ghostbird

  • Bay Watcher
    • View Profile

Ah, thanks for this solution, I'll use that for the time being. I'm gonna try it right now.

EDIT:
Code: [Select]
Drawing z-level 140
Overseer/DFO: line 3:  7631 Segmentation fault      ./Overseer

Another segmentation fault this time. I wonder if it means "Model not found" :)
« Last Edit: October 19, 2010, 11:12:10 am by Ghostbird »
Logged

thewonderidiot

  • Bay Watcher
    • View Profile

Ah, thanks for this solution, I'll use that for the time being. I'm gonna try it right now.

EDIT:
Code: [Select]
Drawing z-level 140
Overseer/DFO: line 3:  7631 Segmentation fault      ./Overseer

Another segmentation fault this time. I wonder if it means "Model not found" :)
*sigh* It does, apparently I missed detection for the stairs. Hold on, let me port back the models.

EDIT: http://filevo.com/kmh0msbq2a6t.html There, converted back to .obj and then back to ive again with the older version of OSG. /crosses fingers
« Last Edit: October 19, 2010, 11:23:01 am by thewonderidiot »
Logged

Ghostbird

  • Bay Watcher
    • View Profile

Great! It works! The first thing I noticed was that the tower I build, and which in my imagination was tall, was pretty stubby and short actually. It's because I imagined the distance between Z-levels to be about 1.5 times the size of the X,Y grid. It kinda puts things in perspective.
EDIT: Picture of my fortress.
Spoiler (click to show/hide)

EDIT: For those that want to get this to work on linux, I run three things:

First a script to allow programs to access each others memory.
Code: [Select]
sudo sysctl -w kernel.randomize_va_space=0
sudo sysctl -w kernel.yama.ptrace_scope=0

Then I run Dwarven Fortress by clicking the link in the application menu or in Nautilus. (running it from terminal gives memory access problems, see a few posts below.)

Then (after loading my game in DF) I run a script to start Overseer:
Code: [Select]
cd ~/Overseer
export LD_LIBRARY_PATH=`pwd`
./Overseer
sudo sysctl -w kernel.randomize_va_space=1
sudo sysctl -w kernel.yama.ptrace_scope=1
This script also disables the cross-process memory access after closing Overseer, since it's a pretty nasty security weakness.
Of course people who aren't particularly worried about security can simply allow the cross-process memory access once and not disable it after running overseer.
Those people who are worried about security can probably run the script to set the variables to 1 directly after starting DF.

NOTE: I run this in three scripts, since I tried to concatenate the first two, and noticed that Overseer couldn't access the memory of Dwarven Fortress.
My guess is:
Setting the variables only applies to processes started afterwards. As ./df is launched from the same script, it's running as a child process of the script (or somesuch) and thus isn't a process started after the variables have been altered.
« Last Edit: October 19, 2010, 04:37:46 pm by Ghostbird »
Logged

thewonderidiot

  • Bay Watcher
    • View Profile

Excellent! Thanks for helping get the Linux stuff ironed out. :)
Logged

Ghostbird

  • Bay Watcher
    • View Profile

No problem, I love messing around with programs until they work.

EDIT: It seems Maverick is very picky about allowing cross-process memory access. I have to start Dwarven Fortress by clicking the start script, because when I start it from terminal, it doesn't allow me to access the memory. I think this has something to do with the way multiple terminals share a process structure. How this works exactly I do not know, but it is easily observed when you open multiple terminals, "xkill"-ing one window kills them all. I'll just put it up here, in case someone else runs into the problem. I prefer to run a lot of things from terminal, and I only found this out by accident.

EDIT:
When I run overseer, it starts out smoothly, but after a few minutes it bogs down to approximately 1 FPS. Is that normal? It seems it either renders stuff that shouldn't be rendered, or has a memory leak somewhere. (Which wouldn't surprise me, with the hacking into another program's memory and all. But then again that's a part of computer science that I've never tried out myself... yet.)
« Last Edit: October 19, 2010, 02:26:21 pm by Ghostbird »
Logged

MagmaMcFry

  • Bay Watcher
  • [EXISTS]
    • View Profile

So...


Code: [Select]
$ sudo sysctl -w kernel.yama.ptrace_scope=0
error: "kernel.yama.ptrace_scope" is an unknown key

What do I do with this?
Logged

thewonderidiot

  • Bay Watcher
    • View Profile

Ignore it. It means you don't have ptrace protection in your kernel so it doesn't need to be disabled.
Logged

MagmaMcFry

  • Bay Watcher
  • [EXISTS]
    • View Profile

Well, it still doesn't work...

EDIT: Oh, I was using 0.31.16.
Still, 0.31.14 connection says
Code: [Select]
The version found in the file is newer than this library can handle.
EDIT2: I have a freaky semi-upgraded 10.04. But that doesn't matter now, I got it (almost) running.
« Last Edit: October 19, 2010, 04:02:53 pm by MagmaMcFry »
Logged

Ghostbird

  • Bay Watcher
    • View Profile

Can you post the error you get? And what distro are you using?
I have to use both of these:
Code: [Select]
sudo sysctl -w kernel.randomize_va_space=0
sudo sysctl -w kernel.yama.ptrace_scope=0

Note that if you use one of the more recent Ubuntu versions, you may have to muddle around a bit before you can access the memory through the DFhack library. Ubuntu has pretty good defences against memory hacking attacks. For example I have to run DF by clicking the icon, instead of using terminal (see one of my posts above).

EDIT: I got that "newer than it can handle" error when I used the models that were built with a newer version of OSG. Thewonderidiot fixed it though. He put the link to the correct models up a few posts back.
« Last Edit: October 19, 2010, 04:06:25 pm by Ghostbird »
Logged

thewonderidiot

  • Bay Watcher
    • View Profile

The internet here is too terrible to be uploading anything largish tonight, I'll update the tarball on dffd tomorrow when I'm on campus. Until then, use the models I posted on filevo.
Logged

Ghostbird

  • Bay Watcher
    • View Profile

I notice that the stairs models you put up, are upside down. I haven't looked at the fortification ones yet.
Logged

thewonderidiot

  • Bay Watcher
    • View Profile

I notice that the stairs models you put up, are upside down. I haven't looked at the fortification ones yet.

Really? *sigh* It was a 1-1 conversion and back, I have no idea why OSG would screw that up. I hate OSG -_-;
Logged

Ghostbird

  • Bay Watcher
    • View Profile

The fortifications have been turned 90 degrees (1/2 π).
Logged

MagmaMcFry

  • Bay Watcher
  • [EXISTS]
    • View Profile

I've still got this error (31.12 and 31.14):

Code: [Select]
...
Drawing z-level 56
Drawing z-level 57
Error reading file: DataInputStream::DataInputStream(): The version found in the file is newer than this library can handle.
Logged
Pages: 1 ... 10 11 [12] 13 14 ... 53