Print

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

[negocromn]

You are right it still crashes. Why won't this work for me?

Is there a 32 bit version of dwarf therapist I can use with the 64-bit application? I'd really like to play the 64-bit DF (I've never played before) but I am clear that I'd need Therapist. Anyone that could help me try to get this working I'd be super grateful toward.

I'm using the dwarf therapist that comes in the latest masterwork pack, it works fine with DF 0.43.05.

[Drowchyld]

You are right it still crashes. Why won't this work for me?

Is there a 32 bit version of dwarf therapist I can use with the 64-bit application? I'd really like to play the 64-bit DF (I've never played before) but I am clear that I'd need Therapist. Anyone that could help me try to get this working I'd be super grateful toward.

I'm using the dwarf therapist that comes in the latest masterwork pack, it works fine with DF 0.43.05.

Is that different then the starter pack?

EDIT: googeled, found, downloaded, copied out that one's Dwarf Therapist. Started my 64 bit and ran the new DT... when it reads dwarves it crashes. So no change.

[PatrikLundell]

32 bit and 64 bit won't work together. If 64 bit doesn't work for you I'd try to use the 32 bit version with the 32 bit version of DF. Currently the benefit of 64 bit over 32 are mostly negligible, unless you plan on doing large embarks (something like 6*6 and up), in which case you'll get a horrible FPS after a short while, but DF won't die due to lack of addressable memory. Note that "currently" isn't the same as "for all future": the 64 bit step is an important enabler for the future, but that doesn't mean you absolutely have to use that version before things settle down.
Finding and fixing your problem would be the best, of course, in particular if it's something many people may be affected by.

Masterworks is a mod so a masterworks pack would definitely be something different than the starter pack, but I have no idea if the DT component is different.

[Drowchyld]

My DF 64 runs fine and works. I just cannot get DT to run with it. Many tell me DT is more or less essential to be able to play the game, realistically. I've the required software needed so I dunno why its instantly crashing for me. Would have no clue how to track this type of thing down myself.

[lethosor]

32 bit and 64 bit won't work together.

I think you might be thinking of DFHack. Technically, since DT and DF run in separate processes, DT could access DF's memory regardless of whether its architecture matches DF's or not. However, I believe there was some issue on Windows with 32-bit programs not being able to use the Windows APIs needed to access 64-bit DF's memory, or vice versa (but I imagine the first would be more likely).

Is there a 32 bit version of dwarf therapist I can use with the 64-bit application?

Even if there were, I don't think it would help. Even though some of the issues with 64-bit DT could be due to it being 64-bit, more of them are likely due to DF itself being 64-bit, which requires significant changes to how DT reads data from DF. A 32-bit DT that interfaced with 64-bit DF would still have the same issues.

[PatrikLundell]

Which is why I suggested you might want to try to work around the problem by trying 32 bit DF + 32 bit DT. The alternatives are:
- Locate the problem yourself, and fix it yourself or provide enough info for someone else to do so.
- Wait for someone else to run into the same problem and either fix it or find enough info for someone else to fix it.
- Run without DT, possibly using the Manipulator instead. DT isn't "essential", but it makes things a lot easier. The Manipulator makes a few things easier as well, and some may even be done better with the Manipulator. However, neither is essential, as many vanilla players can testify to.
- Try the 32 bit route. If it fails you're back to the alternatives above and have lost some time. If it works you may try future versions to see if they agree better with your hardware/software and switch when it does (The DF saves are compatible [obviously a 64 bit one using too much memory won't work with 32 bits]: world generation isn't as compatible as it should be, but that's a completely different issue).
- Wait for new versions to see if the issues have gone away.

Comments on lethosor's comments:
As far as I understand it, a 32 bit DT that would access 64 bit DF correctly would have to be made specifically for that purpose, since it would have to somehow "understand" and navigate via the 64 bit pointers in the DF data structures. It's probably possible to do (as long as the resulting addresses are reachable by the 32 bit application), but I wouldn't consider it worth the trouble (the easier task, of a 64 bit DT interpreting a 32 bit DF is probably better done by having separate versions). These guesses do not take any API issues into account.

[lethosor]

...it would have to somehow "understand" and navigate via the 64 bit pointers in the DF data structures. It's probably possible to do (as long as the resulting addresses are reachable by the 32 bit application)...

Any memory addresses DT reads from DF aren't normal "pointers", so it doesn't matter whether DT can reach those addresses or not. For example, DT could tell the OS to read some bytes from DF's memory, get back "12345", and then tell the OS to read data from DF's address "12345".

However, getting a single DT build that supports both 32-bit and 64-bit DF is even more work, from what I remember, so it's easier for DT to just support DF builds that match its own architecture.

[PatrikLundell]

Ah, virtual addresses. Using OS calls would make it easier to "translate" pointers, but you'd still have to know whether to read 4 or 8 bytes, and I would guess the OS calls would be separate as well. Still, separate versions and no cross reading would probably make the best use of the effort spent.

[xordae]

Having the same issue as Drowchyld right now with the various 64-bit DT builds floating around. Once it actually managed to connect and load dwarves, but every other time it's crashed on startup or when trying to read dwarves. Also when exiting.

[Drowchyld]

Update.

The 64-bit DF starter pack was updated yesterday, May 1st. I tried the new version and Therapist still crashed on load.

[Porpoisepower]

I got it working... but I don't dare run it for more than necessary.  Tends to cause BSOD's.

[lethosor]

I got it working... but I don't dare run it for more than necessary.  Tends to cause BSOD's.

Are you using the term "BSOD" as a synonym for "crash", or do you mean an actual blue screen? User programs, particularly ones like DT, should definitely not be able to cause blue screens on their own, although I suppose they could trigger one indirectly if you're having hardware issues.

[kilakan]

From some digging I have a standalone version of dwarf therapist that works with the newest version for windows.  You need to use the x32 version of dwarf fortress, but it's running great on my windows 10 x64 machine regardless.  I uploaded here http://puu.sh/vPNTW/01ce09dd7a.zip thanks a lot to Quietust for the init file, figured once I got that in and working that someone else might appreciate that if they don't know how to edit .init files.

[lethosor]

Is that the build from GitHub or something else (i.e. where did you find it)? Also, DF uses INI files, not "init" files (that extension is used by some DFHack scripts).

[Porpoisepower]

I got it working... but I don't dare run it for more than necessary.  Tends to cause BSOD's.

Are you using the term "BSOD" as a synonym for "crash", or do you mean an actual blue screen? User programs, particularly ones like DT, should definitely not be able to cause blue screens on their own, although I suppose they could trigger one indirectly if you're having hardware issues.

Actual blue screen of death.  I (almost) never get them on that PC, but got 2 or 3, running the bit DT.

Normally BSODs are the result of errors between the drivers and the kernel. But not always, and remember that DT spends a lot of time in another application's memory space, another application not really designed for that level of interfacing. A couple wrong memory writes and you can royally screw something up, and generally you are dealing with pointers, memory references and maybe some assembly language.  You can do really strange things with those tools, and yes even crash the kernel.  Modern processors and memory have mostly eliminated the need for that level of control, and most modern languages/libraries are built for automatic garbage collection and other high level wizardry so developers can spend their time on content.   
So there are a lot less system crashes than there used to be, and the majority of them are in fact HW failures and driver issues.