Print

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

[Dutchling]

What do these colours signify?

Spoiler (click to show/hide)

[RusTit]

What do these colours signify?

It's nobles.

Spoiler (click to show/hide)

[Clément]

Hi, I have some problems using the DFHack's export-dt-ini script. Maybe I should ask on DFHack thread, but since it is a DT specific script, I hope there is someone understanding it well reading this thread.

I was trying to see I could make DanFritz version work on Windows 64bits and it seems that the offset generated by the script where wrong. The value of "rdelta" was wrong (truncated I guess), replacing the value with the base address from DT gave the proper offsets.

Then I remembered that I was using an old beta of DFHack, and the internal getRebaseDelta should use a 64 bits value already, so I updated to the latest release. But it did not work. I deleted the "hack" folder before extracting the one from the new version again to make sure I get only updated files.

I got errors from these two lines:

Code: [Select]

address('knowledge_category',df.activity_event_ponder_topicst,'knowledge_category')
address('knowledge_flag',df.activity_event_ponder_topicst,'knowledge_flag')Each line give this error:

Code: [Select]

E:\Games\Dwarf Fortress\hack\lua\memscan.lua:309: Cannot reference field activity_event_ponder_topicst.knowledge_category: not found.
stack traceback:
        [C]: in method '_field'
        E:\Games\Dwarf Fortress\hack\lua\memscan.lua:309: in function 'memscan.field_ref'
        ...ames\Dwarf Fortress/hack/scripts/devel/export-dt-ini.lua:54: in local 'address'I commented them, but the offsets are still wrong because of "rdelta".

Is this a real bug or did I do something wrong with my dfhack install?

PleaseBugMeNot's DT seems to use the invalid addresses. I guess there is some kind of weird hack to fix them in this version, because the ones I get with a fixed rdelta almost work with my own build of DanFritz's version (I am missing the names, but the skills work).

By the way, a few remarks on DT code:

• Return values from ReadProcessMemory and WriteProcessMemory are not checked.
• get_last_error does not work if something is logged before calling it (printing overwrites the error code).
• MemoryLayout::read_hex reads 32 bits values (not critical since the proper offsets fit in 32 bits, but the invalid ones were not read correctly).

[Quietust]

Hi, I have some problems using the DFHack's export-dt-ini script. Maybe I should ask on DFHack thread, but since it is a DT specific script, I hope there is someone understanding it well reading this thread.

The "export-dt-ini" script is part of DFHack, so you should report any problems with it in the DFHack thread, not here.

[edit] Incidentally, this should fix the "not found" errors:

Code: [Select]

address('knowledge_category',df.activity_event_ponder_topicst,'knowledge','category')
address('knowledge_flag',df.activity_event_ponder_topicst,'knowledge','flags')


[Clément]

You are right, the bug part is more a DFHack problem (the crash mainly, the rdelta value may actually be correct).

But looking at both DFHack and DT source code, I am very confused at what the addresses in the ini are supposed to be exactly.

The export-dt-ini prints "addr - rdelta" and if I understand DFHack source code correctly, rdelta is the difference between DEFAULT_BASE_ADDR and the actual base address. But DT add this value directly to the base address (in MemoryLayout::address). I thought I could fix the script by writing "addr - 0x140000000 - rdelta" but I actually need to use 0x13fc00000 to get the correct value. Are DFHack and DT disagreeing on the base address?

I will post this in DFHack thread too, I may need help from both side to understand that.

[edit]Thanks, your lines fixed that problem, you should send the patch, this version has the wrong lines.

[Clément]

I tried again on top of Hello71's branch. My patches are uploaded there for any one interested.

• dfinstancewindows: fix Hello71's fix
• cmake: Add unicode definitions for windows builds

These fix some problems with Hello71 modifications.

• dfinstancewindows: fix error checks

Fix and add some error messages. Even if not critical, it should be useful for anyone. But it can be hard to rebase onto another branch.

• dfinstancewindows: fix default base address for win64
• memorylayout: fix reading 64 bits hex values

The important fixes. They are very simple and they should be easy to rebase onto other branches.

Skills, attributes, ... show correctly, but like with DanFritz's, names are still missing. The error log is different though.

Edit: names are fixed by adding "string_cap_offset=0x0018" in the ini. There are stil a few errors in the log.

[Shabdez]

Hello fellow Dwarf Therapist users,

I´ve already started a similar post in DF Gameplay Questions, but got no answer that would clarify my issue. So I try it here, sorry for double post.

Can someone please explain what "XP-Penalty -92% [RAW: 8%]" for all social and almost all non-weapon combat skills is actually meaning?
I´m seeing this with an unmodified creature_standard.txt. However, after adding [SKILL_RATES:100:NONE:NONE:NONE] to the RAW (in order to stopp decay) it changes to:
"XP-Penalty -101% [RAW: -1%]"

The DT Readme has nothing on this and searching the web does not show any information and I´ve really tried it for HOURS now.
Unfortunately, unlike XP from civil tasks combat XP is not fixed so I can´t make a simple test fight with and without the skill decay stopp entry.

Specifially I would like to know:
Does "XP-Penalty -92%" mean a dorf is only getting 8 % of the XP that he would normally gain from executing a task? That would be a quite serious XP cut for a default setting.
Why are only combat and social skills affected? EDIT: I was wrong, also some of the civil labors are affected. But still, why not all skills?
Can I use [SKILL_RATES:100:NONE:NONE:NONE] safely without slowing down XP gain although DT reads it as -101%?

Thanks for your help.

[RedDwarfStepper]

Just if someone else stumbles over this: using the newest (0.43.05-r07) Lazy Newb Pack/ PeridexisErrant's Starter Pack with its default settings of dfhack will prevent DT from connecting to DF, at least on Windows.
To get it working you have to comment out the line

Code: [Select]

enable title-versionin the dfhack.init in or around line 214
The reason is probably that DT searches for a window with the name "Dwarf Fortress" and having the "title-version" plugin enabled changes the name of the window...

[Hello71]

Just if someone else stumbles over this: using the newest (0.43.05-r07) Lazy Newb Pack/ PeridexisErrant's Starter Pack with its default settings of dfhack will prevent DT from connecting to DF, at least on Windows.
To get it working you have to comment out the line

Code: [Select]

enable title-versionin the dfhack.init in or around line 214
The reason is probably that DT searches for a window with the name "Dwarf Fortress" and having the "title-version" plugin enabled changes the name of the window...

my fork searches for both window name "Dwarf Fortress" and executables named "Dwarf Fortress.exe".

[lethosor]

Just if someone else stumbles over this: using the newest (0.43.05-r07) Lazy Newb Pack/ PeridexisErrant's Starter Pack with its default settings of dfhack will prevent DT from connecting to DF, at least on Windows.
To get it working you have to comment out the line

Code: [Select]

enable title-versionin the dfhack.init in or around line 214
The reason is probably that DT searches for a window with the name "Dwarf Fortress" and having the "title-version" plugin enabled changes the name of the window...

No it doesn't. You're thinking of the title-folder plugin. "title-version" adds the DFHack version to the upper left corner screen. It doesn't change the window title at all.

[Shabdez]

Hello fellow Dwarf Therapist users,

I´ve already started a similar post in DF Gameplay Questions, but got no answer that would clarify my issue. So I try it here, sorry for double post.

Can someone please explain what "XP-Penalty -92% [RAW: 8%]" for all social and almost all non-weapon combat skills is actually meaning?
I´m seeing this with an unmodified creature_standard.txt. However, after adding [SKILL_RATES:100:NONE:NONE:NONE] to the RAW (in order to stopp decay) it changes to:
"XP-Penalty -101% [RAW: -1%]"

The DT Readme has nothing on this and searching the web does not show any information and I´ve really tried it for HOURS now.
Unfortunately, unlike XP from civil tasks combat XP is not fixed so I can´t make a simple test fight with and without the skill decay stopp entry.

Specifially I would like to know:
Does "XP-Penalty -92%" mean a dorf is only getting 8 % of the XP that he would normally gain from executing a task? That would be a quite serious XP cut for a default setting.
Why are only combat and social skills affected? EDIT: I was wrong, also some of the civil labors are affected. But still, why not all skills?
Can I use [SKILL_RATES:100:NONE:NONE:NONE] safely without slowing down XP gain although DT reads it as -101%?

Thanks for your help.

Feeling kind of lost now. Not a single reply. Can someone at least confirm that in their DT session Potash Making does or does NOT look like this (without mods, vanilla raws):
http://imgur.com/a/oKyM0

[Clément]

Feeling kind of lost now. Not a single reply. Can someone at least confirm that in their DT session Potash Making does or does NOT look like this (without mods, vanilla raws):
http://imgur.com/a/oKyM0

I have the same with PleaseBugMeNot's version but not with Hello71's. I cannot say who is right and who is wrong.

By the way, I pushed two more commits fixing some false positive when searching windows on Windows (writing it like that looks confusing), and fixing reading squad orders (I am guessing for this one but it seems to work).

I tried to fix more errors but a lot of them looks like they happen because of uninitialized memory from DF. I am not sure what to do with them.

[RedDwarfStepper]

Just if someone else stumbles over this: using the newest (0.43.05-r07) Lazy Newb Pack/ PeridexisErrant's Starter Pack with its default settings of dfhack will prevent DT from connecting to DF, at least on Windows.
To get it working you have to comment out the line

Code: [Select]

enable title-versionin the dfhack.init in or around line 214
The reason is probably that DT searches for a window with the name "Dwarf Fortress" and having the "title-version" plugin enabled changes the name of the window...

No it doesn't. You're thinking of the title-folder plugin. "title-version" adds the DFHack version to the upper left corner screen. It doesn't change the window title at all.

lethosor you're absolutely right - my mistake & apologies - the reason for this was part wishful thinking when reading the dfhack manual while having around 100 save folders and hoping 'title-folder' would actually tell me which was the current save folder, and part being too tired to notice what happened when I activated the plugin.

[a52]

Having the same SSL context/memory layout crashes as Abalieno. Tried installing OpenSSL and reinstalling the memory layout, neither made a difference.

Somebody mentioned that worlds made in 32-bit then transferred to 64-bit may be the problem, and that is the case with my world.

[lethosor]

Somebody mentioned that worlds made in 32-bit then transferred to 64-bit may be the problem, and that is the case with my world.

Whoever told you that was wrong. The issue you're having is inherent to your DT build on your machine, and isn't specific to a save.