Print

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

[lethosor]

Any news on win x64 DF 0.43.05 memory layouts yet? Thanks in advance guys!

64-bit layouts aren't hard to generate. The issue is actual support for 64-bit DF, which is still experimental.

[anewaname]

And how is saying that it should be called an "instruction" instead of a "guide" relevant to your gaining an understanding of what the listed steps will require you to do? Would changing the word give you a better ability to understand?

There is difference between these terms, you can google it. I've seen two of your links, but I don't understand how to "tell cmake where qt can be found". Is it something I have to do with environment variables? I installed both cmake and qt, Qt Creator was able to see cmake and it copied some files (Qt5Core.dll, Qt5Gui.dll etc.) into cmake\bin folder.

You could add the QT filepath to your path environment variable, or when you run cmake you can add the path there using this...

So I think your issue goes back to "The Qt5 cmake modules are provided by Qt5 itself, so you need to tell cmake where qt can be found." and the solution may be to run cmake using the command line like "cmake -DCMAKE_PREFIX_PATH=<path_to_source>". The QT5 manual here says "In order for find_package to be successful, Qt 5 must be found below the CMAKE_PREFIX_PATH, or the Qt5<Module>_DIR must be set in the CMake cache to the location of the Qt5WidgetsConfig.cmake file. The easiest way to use CMake is to set the CMAKE_PREFIX_PATH environment variable to the install prefix of Qt 5." I don't know which of the QT5 folders you need to point that setting at, but this seems like the step needed.

When you run any application at the command line, there are usually switches or parameters values that can be added to the command line that will modify how the application runs. In this case, that "-DCMAKE_PREFIX_PATH=<path_to_source>" will cause cmake to look for files at the filepath you replace <path_to_source> with, and then cmake will use it to find the qt5 stuff in that folder tree). It is still a guess if it will work, but it is why the creators of cmake added CMAKE_PREFIX_PATH as an input for their program, so cmake can find files outside of the cmake folder structure. Your QT Creator likely did not add all of the files needed.

Regarding "instruction", "guide", and the internet... Go there yourself and watch out for the banana peels. I have an Oxford Concise dictionary, a figurative point of view, and no need to go further.

[feelotraveller]

I got another instance of roles weighting being reported as unduly positive. 

As far as I have been able to make out this occurs when the top cell of the table changes (but not always when it changes...).  This is an old problem that I have experienced (sporadically) for some years both on linux and windows and 32bit and 64bit versions (of linux).  But this time I managed to make a save while the game was paused and made a reproducible and reversible workaround.  I can upload/mail the savegame if it would help but since the problem (well certainly the workaround...) involves custom preferences it might not reproduce on the other end (but then again it might).  Also happy to try to investigate further but need simplish instructions on what to do/try.

Reading data after the highest cell on the table has changed (Urdim/Herbalist) I get this.  Before this everything was normal.  Note that all dwarfs are reported as better than average at everything... 



I make a new custom role that is a straight copy of the default Herbalist role (but named Herb so it does not replace) and the spreadsheet report returns to normal.  Herb is not used by any grid view.



Removing the custom Herb role returns the spreadsheet to the all positive distribution.

[anewaname]

I got another instance of roles weighting being reported as unduly positive. 

Spoiler (click to show/hide)

As far as I have been able to make out this occurs when the top cell of the table changes (but not always when it changes...).  This is an old problem that I have experienced (sporadically) for some years both on linux and windows and 32bit and 64bit versions (of linux).  But this time I managed to make a save while the game was paused and made a reproducible and reversible workaround.  I can upload/mail the savegame if it would help but since the problem (well certainly the workaround...) involves custom preferences it might not reproduce on the other end (but then again it might).  Also happy to try to investigate further but need simplish instructions on what to do/try.

Reading data after the highest cell on the table has changed (Urdim/Herbalist) I get this.  Before this everything was normal.  Note that all dwarfs are reported as better than average at everything... 



I make a new custom role that is a straight copy of the default Herbalist role (but named Herb so it does not replace) and the spreadsheet report returns to normal.  Herb is not used by any grid view.



Removing the custom Herb role returns the spreadsheet to the all positive distribution.

While that definitely is a bug, it is a relatively harmless one, and might not get attention until it is irking someone who has the coding skills to hunt it down. I've noted something similar to it (or maybe it was the same issue) a couple of times but iirc, a re-read of the data while on the Roles tab fixed it also.

[Carch]

so there is a (highly experimental?) sortof version of DT that works with df 0.43.05? I tried to read the last few pages to figure out how to get it to work, but I just end up confused. is there any way someone can give a download link of sorts that doesn't require a full understanding of github or something (i get lost easily. < <)

[Rose]

In Windows, it's x86 only, but there's an experimental x64 Linux version somewhere.

[Carch]

ahh. I see. thanks for the reply.

[lethosor]

I think someone was working on 64-bit Windows support, but I don't know if there's a build anywhere.

[feelotraveller]

I got another instance of roles weighting being reported as unduly positive. 

Spoiler (click to show/hide)

As far as I have been able to make out this occurs when the top cell of the table changes (but not always when it changes...).  This is an old problem that I have experienced (sporadically) for some years both on linux and windows and 32bit and 64bit versions (of linux).  But this time I managed to make a save while the game was paused and made a reproducible and reversible workaround.  I can upload/mail the savegame if it would help but since the problem (well certainly the workaround...) involves custom preferences it might not reproduce on the other end (but then again it might).  Also happy to try to investigate further but need simplish instructions on what to do/try.

Reading data after the highest cell on the table has changed (Urdim/Herbalist) I get this.  Before this everything was normal.  Note that all dwarfs are reported as better than average at everything... 



I make a new custom role that is a straight copy of the default Herbalist role (but named Herb so it does not replace) and the spreadsheet report returns to normal.  Herb is not used by any grid view.



Removing the custom Herb role returns the spreadsheet to the all positive distribution.

While that definitely is a bug, it is a relatively harmless one, and might not get attention until it is irking someone who has the coding skills to hunt it down. I've noted something similar to it (or maybe it was the same issue) a couple of times but iirc, a re-read of the data while on the Roles tab fixed it also.

Yep, just being hopeful...    In my experience a change in the dataset is neccessary (but not always sufficient) to restore 'normality'.  Thought it worthwhile to document the most effective workaround I have found although other things sometimes work.  Without having seen the code I suspect this one may need more than rudimentary skills (depending on -lack of- code documentation) and thought a working example for reading values in debug mode - if that is possible - might be useful.  No harm done if I am just blowing hot air. 

[Hello71]

I think someone was working on 64-bit Windows support, but I don't know if there's a build anywhere.

I'm not aware of any issues that would prevent my branch from working on Windows, as long as a suitable memory layout is provided. (but I haven't tried it, so it *probably* doesn't work.)

[Urist McScoopbeard]

When you've had a mac for a billion years, and find out that Dwarf Therapist DOES work on mac...

[soul4hdwn]

so while the .ini is found, the memory addresses aren't?  i'm feeling just how wonderful therapist is... fingers dieing trying to assign jobs.

[feelotraveller]

so while the .ini is found, the memory addresses aren't?  i'm feeling just how wonderful therapist is... fingers dieing trying to assign jobs.

Um, more information would definitely help...

Just taking a wild guess - running windows 64 bit DF 43.05 with windows 32 bit 43.05 memory layout?

[soul4hdwn]

i'm honestly not sure. i grabbed the 0.43.05 windows.ini from links for two other utilities.  therapist connected to fortress program but crashed when attempting to grab dwarves.

i'm basically returning from version 0.40.xx; so i downloaded into a separate folder install of 0.43.05, downloaded "beta" dfhack (which runs fine despite warnings), added phobius "just graphics" set, and the necessary .ini file mentioned above found in a link in a visualizer thread and somewhere else i forgot.

edit ok so... i'm completely wrong in the sense that 1) the .ini was for 32 bit 2) and ontop i might have downloaded wrong DF as someone pointed out to not simply click "download" but go into "all versions" first.

[Rose]

You can't connect to a 64bit DF with just ini changes.

The therapist program needs to be modified quite a bit to be able to connect.