Print

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

[feelotraveller]

Excuse the double post, but a couple of minor issues I've not noticed before with gridviews: in order of ascending nuisance. (Using linux-64 version that I built yesterday with the offset fix.)

a) The gridview Socail & Cultural (as displayed in tab) is called Social && Cultural in the Grid Views dock.

b)

2017-Oct.-24 03:14:19.743 WARNING   core   unidentified column type in set "Other Social" ! [/home/hope/Desktop/Dwarf-Therapist/src/viewcolumnset.cpp:153] (ViewColumnSet)

Does this refer to the old 'Socai-Alt'?

c)

2017-Oct.-24 03:14:19.748 WARNING   core   gridview "UNKNOWN" was not loaded because a view with this name already exists [/home/hope/Desktop/Dwarf-Therapist/src/viewmanager.cpp:185] (load_views)

Checking gridviews shows there is a default gridview by name UNKNOWN that appears empty.  Since it is default user cannot delete.  Additionally it seems DT is trying to write a second copy of the gridview on connection to DF.

[Clément]

Excuse the double post, but a couple of minor issues I've not noticed before with gridviews: in order of ascending nuisance. (Using linux-64 version that I built yesterday with the offset fix.)

I think double posting is required for me to receive the notification. It is not even the same day anyway.

a) The gridview Socail & Cultural (as displayed in tab) is called Social && Cultural in the Grid Views dock.

In some Qt texts the ampersand is used for keyboard shortcuts (the underlined letter you often see in menus), it needs to be doubled to actually display. I would need to encode the string in these cases, but I don't know a Qt function that does that.

b)

2017-Oct.-24 03:14:19.743 WARNING   core   unidentified column type in set "Other Social" ! [/home/hope/Desktop/Dwarf-Therapist/src/viewcolumnset.cpp:153] (ViewColumnSet)

Does this refer to the old 'Socai-Alt'?

c)

2017-Oct.-24 03:14:19.748 WARNING   core   gridview "UNKNOWN" was not loaded because a view with this name already exists [/home/hope/Desktop/Dwarf-Therapist/src/viewmanager.cpp:185] (load_views)

Checking gridviews shows there is a default gridview by name UNKNOWN that appears empty.  Since it is default user cannot delete.  Additionally it seems DT is trying to write a second copy of the gridview on connection to DF.

Typos I made in default_gridviews.dtg, that is what you get for editing this kind of file with a text editor (game_data.ini is even worse with some part out of order). I should find a better way to edit them.

[Clément]

b) and c) should be fixed.

I finally decided to use reaction classes for matching general parchment and paper plant (only papyrus currently) preferences. It seemed the best way.

I am approaching the end of my "paper" branch. I have added new offsets. I can find the values for linux and windows, but again I will need help for OSX. The new offsets are "reaction_class" and "prefix" in the "[material_offsets]" section.

To get the correct values, you can download the updated export-dt-ini.lua script for DFHack, replace the old one in your "hack/scripts/devel" folder, start DF (with DFHack) and run "devel/export-dt-ini" in the DFHack console (no need to load a fortress). If everything works as expected, it should have created a "therapist.ini" file in your DF folder. Find the requested offsets or the copy whole file.

[Clément]

New version released: 38.1.0

This version mainly extends default grid views and improves the role preferences system. Generic material preferences can now match preferences by material state or reaction class instead of flags only.

Changelog:

• added Blacksmith role in default "Roles" grid view
• added memory layout for DF 43.05 on OSX 64 bits
• re-added pdf manual compilation with Latex
• extended "Social" grid view with artistic and scholar skills
• added Paper, Parchment and Paper plant generic preferences in custom role dialog
• added specific preferences for papers, leathers, wools, silks, parchments and paper plants in custom role dialog
• changed some material names to be closer to DF
• added the ability to use the custom role dialog when not connected to a fortress (specific preferences are not available until connected to a fortress)
• fixed win32 0.43.05 memory layout
• fixed some widgets not displaying correctly
• fixed art preference name on 64 bits platforms
• fixed "Cloth" preference matching papers
• fixed a crash when using the custom grid view dialog when not connected to a fortress

Notes:

• Some material names have changed, since specific preference are based on names, you need to check and update any specific material preference you may use in your custom roles (e.g. "linen fabric" → "linen", "rubber tree wood" → "rubber wood", …).
• Cloth preference was updated in default roles to not match paper, but it need to be updated in custom roles too (delete and re-add).
• When I wanted to compile DT on 32 bits Linux for testing, I discovered that DT does not compile any more. This is because of the write_string method, it half-broken on 64 bits too (it compiles but I would not recommend to use it, it crashes DF when quitting). I will fix that in a later release when I find a new way to write string in DF memory. I am also planning to make 64 bit DT work with 32 bit DF.
• Material changes require new offsets. They are missing from the current OSX memory layouts. Material names will not display correctly, reaction-based preference matching will not work.

Windows builds are also available on DFFD (win32, win64).

[feelotraveller]

I probably should have read here first - but since I did not a couple of bits of feedback on building with an Arch based 64 bit.

1) The building of the manual by latex gave me problems.  I now have texlive-bin installed (need for qpdfview) but not the much larger texlive-core package. The cmake process detects /usr/bin/latex but then finds neither the htlatex command nor the biber command.  The compile then fails to build the manual and fails to build therapist.  (I got it to compile therapist by deleting 'add_subdirectory(doc)' from CMakeLists.txt.)

2) Once compiled therapist runs successfully but on attempting to connect to a fortress it crashes with segmentation fault.  Results of three attempts below: 

Code: [Select]

2017-Oct.-29 11:42:27.853 ERROR core READ_RAW: "Bad address" READING 1024 BYTES FROM "0x007fffc22048a800" TO 0x7fff68aa5730 [/home/user/Desktop/Dwarf-Therapist/src/dfinstancelinux.cpp:156] (read_raw)
Segmentation fault

2017-Oct.-29 11:43:14.009 ERROR core READ_RAW: "Bad address" READING 1024 BYTES FROM "0x007fffc22048a800" TO 0x7ffc4ec2a390 [/home/user/Desktop/Dwarf-Therapist/src/dfinstancelinux.cpp:156] (read_raw)
Segmentation fault

2017-Oct.-29 11:51:08.364 ERROR core READ_RAW: "Bad address" READING 1024 BYTES FROM "0x007fffc22048a800" TO 0x7fff0369daf0 [/home/user/Desktop/Dwarf-Therapist/src/dfinstancelinux.cpp:156] (read_raw)
Segmentation fault

[Clément]

1) The building of the manual by latex gave me problems.  I now have texlive-bin installed (need for qpdfview) but not the much larger texlive-core package. The cmake process detects /usr/bin/latex but then finds neither the htlatex command nor the biber command.  The compile then fails to build the manual and fails to build therapist.  (I got it to compile therapist by deleting 'add_subdirectory(doc)' from CMakeLists.txt.)

You can ignore the missing commands, they are not really required. Your problem is missing extra tex package. Building the manual is disabled if latex is missing but I forgot about the case of incomplete latex.

2) Once compiled therapist runs successfully but on attempting to connect to a fortress it crashes with segmentation fault.  Results of three attempts below: 

Code: [Select]

2017-Oct.-29 11:42:27.853 ERROR core READ_RAW: "Bad address" READING 1024 BYTES FROM "0x007fffc22048a800" TO 0x7fff68aa5730 [/home/user/Desktop/Dwarf-Therapist/src/dfinstancelinux.cpp:156] (read_raw)
Segmentation fault

2017-Oct.-29 11:43:14.009 ERROR core READ_RAW: "Bad address" READING 1024 BYTES FROM "0x007fffc22048a800" TO 0x7ffc4ec2a390 [/home/user/Desktop/Dwarf-Therapist/src/dfinstancelinux.cpp:156] (read_raw)
Segmentation fault

2017-Oct.-29 11:51:08.364 ERROR core READ_RAW: "Bad address" READING 1024 BYTES FROM "0x007fffc22048a800" TO 0x7fff0369daf0 [/home/user/Desktop/Dwarf-Therapist/src/dfinstancelinux.cpp:156] (read_raw)
Segmentation fault

I have a similar crash if I remove the "reaction_class" from the memory layout.

Check that the memory layout you are using is up-to-date (there should be a line in the log "Detected Dwarf Fortress version "v0.43.05 linux64" using MemoryLayout from ...").

If that is still happening, I will need a backtrace, preferably with a debug version (add "-DCMAKE_BUILD_TYPE=Debug" in your cmake options). To get the backtrace, run DT width gdb: "gdb ./DwarfTherapist", from gdb command line: "r" to run the process and "bt" when it crashed to get the backtrace.

[feelotraveller]

Yes my memory layout was up to date and I was getting (just) past that point.  Here's the backtrace.  For my erudition - it was the assert message you needed, right?  Including it all in case I'm wrong:

Spoiler (click to show/hide)

$ gdb ./DwarfTherapist
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./DwarfTherapist...done.
(gdb) r
Starting program: /home/user/DwarfFortress/df_linux/DwarfTherapist
[New LWP 9243]
qt5ct: using qt5ct plugin
2017-Oct.-29 21:47:07.805 INFO   core   Dwarf Therapist "38.1.0" starting normally. [/home/user/Desktop/Dwarf-Therapist/src/dwarftherapist.cpp:186] (setup_logging)
2017-Oct.-29 21:47:07.805 INFO   core   Runtime QT Version 5.9.2 [/home/user/Desktop/Dwarf-Therapist/src/dwarftherapist.cpp:187] (setup_logging)
[New LWP 9244]
[New LWP 9245]
[New LWP 9246]
qt5ct: D-Bus global menu: no
[New LWP 9247]
2017-Oct.-29 21:47:07.962 DEBUG   core   setting up connections for MainWindow [/home/user/Desktop/Dwarf-Therapist/src/mainwindow.cpp:166] (MainWindow)
2017-Oct.-29 21:47:07.986 INFO   core   beginning to read settings [/home/user/Desktop/Dwarf-Therapist/src/dwarftherapist.cpp:213] (read_settings)
2017-Oct.-29 21:47:08.000 INFO   core   finished reading settings [/home/user/Desktop/Dwarf-Therapist/src/dwarftherapist.cpp:264] (read_settings)
2017-Oct.-29 21:47:12.998 INFO   core   attempting connection to running DF game [/home/user/Desktop/Dwarf-Therapist/src/mainwindow.cpp:405] (connect_to_df)
2017-Oct.-29 21:47:13.001 INFO   core   adding valid layout "v0.43.05 linux64" checksum: "0xaf8cc86c" SHA: "8ce8499aeda22c2efaf3896aaaa4cb6b13a8b998" [/home/user/Desktop/Dwarf-Therapist/src/dfinstance.cpp:105] (DFInstance)
2017-Oct.-29 21:47:13.005 INFO   core   Dwarf fortress path: "/home/user/DwarfFortress/df_linux" [/home/user/Desktop/Dwarf-Therapist/src/dfinstancelinux.cpp:283] (find_running_copy)
2017-Oct.-29 21:47:13.035 INFO   core   Setting memory layout for DF checksum "0xaf8cc86c" [/home/user/Desktop/Dwarf-Therapist/src/dfinstance.cpp:1044] (set_memory_layout)
2017-Oct.-29 21:47:13.035 INFO   core   Detected Dwarf Fortress version "v0.43.05 linux64" using MemoryLayout from "/home/user/DwarfFortress/df_linux/share/memory_layouts/linux/v0.43.05.ini" [/home/user/Desktop/Dwarf-Therapist/src/dfinstance.cpp:1049] (set_memory_layout)
2017-Oct.-29 21:47:13.035 INFO   core   Connection to DF version "v0.43.05 linux64" established. [/home/user/Desktop/Dwarf-Therapist/src/mainwindow.cpp:429] (connect_to_df)
2017-Oct.-29 21:47:13.036 DEBUG   core   Loading language translation tables [/home/user/Desktop/Dwarf-Therapist/src/languages.cpp:59] (load_data)
2017-Oct.-29 21:47:13.036 DEBUG   core   Loading generic strings from "0x019144f8" [/home/user/Desktop/Dwarf-Therapist/src/languages.cpp:73] (load_data)
2017-Oct.-29 21:47:13.036 DEBUG   core   generic words 2195 [/home/user/Desktop/Dwarf-Therapist/src/languages.cpp:75] (load_data)
2017-Oct.-29 21:47:13.110 DEBUG   core   reading material templates [/home/user/Desktop/Dwarf-Therapist/src/dfinstance.cpp:597] (load_main_vectors)
2017-Oct.-29 21:47:13.111 DEBUG   core   reading syndromes [/home/user/Desktop/Dwarf-Therapist/src/dfinstance.cpp:604] (load_main_vectors)
2017-Oct.-29 21:47:13.111 DEBUG   core   reading item and subitem types [/home/user/Desktop/Dwarf-Therapist/src/dfinstance.cpp:608] (load_main_vectors)
2017-Oct.-29 21:47:13.111 DEBUG   core   reading colors, shapes, poems, music and dances [/home/user/Desktop/Dwarf-Therapist/src/dfinstance.cpp:624] (load_main_vectors)
2017-Oct.-29 21:47:13.111 DEBUG   core   reading base materials [/home/user/Desktop/Dwarf-Therapist/src/dfinstance.cpp:631] (load_main_vectors)
2017-Oct.-29 21:47:13.111 ERROR   core   READ_RAW: "Bad address" READING 1024 BYTES FROM "0x007fffba22533800" TO 0x7fff9bea7d50 [/home/user/Desktop/Dwarf-Therapist/src/dfinstancelinux.cpp:156] (read_raw)
ASSERT: "asize >= 0 && asize <= aalloc" in file /usr/include/qt/QtCore/qvector.h, line 540

Thread 1 "DwarfTherapist" received signal SIGABRT, Aborted.
0x00007f58daab88a0 in ?? ()
(gdb) bt
#0  0x00007f58daab88a0 in ?? ()
#1  0x0000000000000000 in ?? ()
(gdb)

[Clément]

If it is an abort that append later, you will need to add a breakpoint: use the command "b dfinstancelinux.cpp:156" before "r".

This really look like an invalid material offset. Give the output of

Code: [Select]

grep reaction_class "/home/user/DwarfFortress/df_linux/share/memory_layouts/linux/v0.43.05.ini" to be sure.

Check the updater settings (Options → General → Updates). Is it enabled? If it is make sure the Owner/Repository is Dwarf-Therapist/Dwarf-Therapist.

[feelotraveller]

Indeed you were right.    I still had the memory layout from 38.0.  Thank you for your patience.

Had a quick look at the cloth/paper preferences and they seem to be working well.  I am assuming the the preference for papyrus sheet is included in the 'papers' general category? 

Gridview/role feedback
1) The Wordsmith skill is missing.  (My scholars are waiting.  )
2) Drag and drop is broken for me when editing gridviews.  I was rearranging the order of roles in a custom gridview.  Not sure when I last used it but it was working, potentially pre-64 bit?

And finally, could you say a bit more about DF crashing when quitting therapist.  I've yet to experience it as therapist has closed without having this effect but I have yet to unpause a game with 38.1.  What use conditions are likely to trigger it, and possible workarounds for safe(ish) use with linux 64 in the meantime.  (Sorry to be so high maintenance but I prefer to be on latest version and hope that the odd bits of feedback I can give will offset it to some extent.)

[Clément]

Indeed you were right.    I still had the memory layout from 38.0.  Thank you for your patience.

Why was it the old memory layout? Did you copy only the executable or use "make install"? If it is a broken script from me, I need to know.

I am assuming the the preference for papyrus sheet is included in the 'papers' general category?

"papyrus" is in the "Papers" category, but you can also use "Paper plants" in "~ General Materials" to match any material with the PAPER_PLANT reaction. Only papyrus has this reaction in the current vanilla game, but mods or future version may add others.

Gridview/role feedback
1) The Wordsmith skill is missing.  (My scholars are waiting.  )
2) Drag and drop is broken for me when editing gridviews.  I was rearranging the order of roles in a custom gridview.  Not sure when I last used it but it was working, potentially pre-64 bit?

Both work for me. Wordsmith is the first skill in the last (fifth) group in "Social & Cultural" (you may need to add the tab since the name changed).

And finally, could you say a bit more about DF crashing when quitting therapist.  I've yet to experience it as therapist has closed without having this effect but I have yet to unpause a game with 38.1.  What use conditions are likely to trigger it, and possible workarounds for safe(ish) use with linux 64 in the meantime.

Writing strings on Linux replace the string data pointer with a buffer that was not properly allocated. This make DF crash when it try to deallocate the buffer, this can happen when quitting (destroying the string after saving), it doesn't seem to corrupt the save, or when replacing the string (changing the same string from the game after it was changed from DT). The safe workaround is to not change strings from DT.

I am experimenting with injecting a call to std::string::assign instead so the memory is managed correctly.

(Sorry to be so high maintenance but I prefer to be on latest version and hope that the odd bits of feedback I can give will offset it to some extent.)

The feedback is welcome. Actually, if you like testing, since you have to compile anyway, consider using the last version from the master git branch instead of releases (or even development branches if you feel adventurous). It can help detect new bugs earlier (and you also get the bug fixes earlier).

[Hello71]

And finally, could you say a bit more about DF crashing when quitting therapist.  I've yet to experience it as therapist has closed without having this effect but I have yet to unpause a game with 38.1.  What use conditions are likely to trigger it, and possible workarounds for safe(ish) use with linux 64 in the meantime.

Writing strings on Linux replace the string data pointer with a buffer that was not properly allocated. This make DF crash when it try to deallocate the buffer, this can happen when quitting (destroying the string after saving), it doesn't seem to corrupt the save, or when replacing the string (changing the same string from the game after it was changed from DT). The safe workaround is to not change strings from DT.

I am experimenting with injecting a call to std::string::assign instead so the memory is managed correctly.

tip: ptrace is painful enough as it is, don't try to reimplement ld.so, I suggest just shell out to gdb. it will have minimal problems as long as you make sure that df is stopped by SIGSTOP and not just by ptrace attachment.

[Clément]

Finding the symbol is easy, my problem is with ptrace. It modifies the program counter when I resume execution (similar to this). The current code is not affected by that, do you have an idea why?

Edit: found the solution in gdb source code:

Code: [Select]

/* Set the program counter for process PTID to PC.  */

static void
i386_linux_write_pc (struct regcache *regcache, CORE_ADDR pc)
{
  regcache_cooked_write_unsigned (regcache, I386_EIP_REGNUM, pc);

  /* We must be careful with modifying the program counter.  If we
     just interrupted a system call, the kernel might try to restart
     it when we resume the inferior.  On restarting the system call,
     the kernel will try backing up the program counter even though it
     no longer points at the system call.  This typically results in a
     SIGSEGV or SIGILL.  We can prevent this by writing `-1' in the
     "orig_eax" pseudo-register.

     Note that "orig_eax" is saved when setting up a dummy call frame.
     This means that it is properly restored when that frame is
     popped, and that the interrupted system call will be restarted
     when we resume the inferior on return from a function call from
     within GDB.  In all other cases the system call will not be
     restarted.  */
  regcache_cooked_write_unsigned (regcache, I386_LINUX_ORIG_EAX_REGNUM, -1);
}


[feelotraveller]

Why was it the old memory layout? Did you copy only the executable or use "make install"? If it is a broken script from me, I need to know.

Not your problem rather pebkac at this end.  Copied executable and not share folder, automatic updates turned off again, probably by me. Even more embarrassingly went by terminal output in regard to finding ini rather than checking date/version manually.

Gridview/role feedback
1) The Wordsmith skill is missing.  (My scholars are waiting.  )
2) Drag and drop is broken for me when editing gridviews.  I was rearranging the order of roles in a custom gridview.  Not sure when I last used it but it was working, potentially pre-64 bit?

Both work for me. Wordsmith is the first skill in the last (fifth) group in "Social & Cultural" (you may need to add the tab since the name changed).

Should have been more specific.  Wordsmith skill does not appear in the custom roles dialogue. Further investigation reveals a "Prose" skill in that dialogue which I assume is the one that I want (since Wordsmith affects the quality of the prose).  Advise renaming.  The skill appears correctly in other places such as the Social & Cultural gridview and tooltips/dwarf details.

Drag and drop definitely broken for me.  An image, behaviour is the same when trying to reorder sets:



The window is frozen in that position, while the mouse pointer remains mobile having either a green + or a red diagonally crossed circle attached and does not to respond clicking.  Most keyboard input is also disabled including power key, although the printscreen key still works, as does esc which clears the freeze and mouse pointer but also the drag and drop action. The gridview order remains unchanged.  Output from terminal gives nothing with either normal of debug (gdb) versions.  When you say it works for you is that with a 64 bit linux version?  Is there more information I can give that might help identify the issue?

Thanks for the comments on paper and strings workaround - now crystal clear .

Yes I will try learning with github. (Pursuing these issues here since already raised.)

[Clément]

It is very confusing: Prose is Writer's skill, Writing is Wordsmith's skill. I did not choose the names myself. The solution is to use the same word everywhere but which one? (the skill name or the name of the dwarf using the skill) The skill tooltip may need to be reversed too: "Musician: novice music" should become "Music: novice musician" (that's how it is used in game).

The grid view editor works for me on Fedora 26 (64 bits) with Qt 5.7.1 (it seems too old, I may have an issue with my updates). What is your distribution and Qt version? I will try to reproduce it in a VM.

[feelotraveller]

Ah, that's where it came from.  (I'm not familiar with df.structures.)  I have a definite preference imperative for having the skill named the same in different places (so on the gridview, at the tooltips, at dwarf details, and in the roles) regardless of what that name is.  Embarking with Wordsmith gives wordsmith as displayed by DF (and Writer gives writer), and really that should be the final arbiter, yes? I have never seen a dwarf with 'prose' or alternatively described as 'dabbling prose', etc. nor does the wiki list it as a skill.  I don't really understand what is going on with df.structures there since that seems to be a list of labours or perhaps professions and not skills yet it is titled df.skills.     Quietust would be the person to ask, or perhaps Lethosor, but others might know.  Perhaps the structures get used a bit differently (by Toady) with the newer professions/skills is all I can think.  There is not the issue of naming the Writing or Wordsmithing labour to consider such as you get with Plant Gathering/Herbalist.

[As an aside, since it is not relevant here but I did mention it. It is possible I have the use of Wordsmith skill incorrect... but I don't think so.  Anyway both Wordsmith and Writer are involved when scholars produce works, effecting two different parts of the writing, how well it conveys its technical aspects (writer skill I thought) and how well it reads (wordsmith skill, sort of the poetic side of technical writing).  Poet, however, is not involved and is used by performers.]

I am currently running Manjaro (xfce) and Qt 5.9.2.  I have not noticed any issues with drag and drop in other places.