Print

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

[Meph]

Ah, thank you. I did that change of the ticks myself, completely forgot that you had it set to 100 here. Thats why I was surprised a bit. There is also feedback whenever the script finds gloves and adds the handedness tags.

somehow I get the feeling that profit should start a "dfhack" section in this list, with all the links to custom written scripts and plugins. Otherwise these things get lost so fast...

[Ogamaga]

Has anyone tried to use "simple embark" with r3 or know how to try it?

[TDarksword]

The status section?  You mean in the current soul, or is there a caste field elsewhere in the status section?  I'll check that again.  Where is the were caste stored?  I poked through the syndrome and curse structures using the Lua interface but didn't find anything obvious.

Did you get anywhere with this Telgin?

I am having basically the same problem.
Changing unit.caste causes it just to change immediately back after I unpause even if unit.status.current_soul.caste and unit.status.souls[0].caste have been changed (and those two don't change back after unpause)

Has anyone tried to use "simple embark" with r3 or know how to try it?

I think I saw mention somewhere earlier in the thread that it is broke as there is a requirement to embark with 7 dwarves. I think there was a work around mentioned though by using the multi-race embark to get around this.

[Telgin]

Did you get anywhere with this Telgin?

I am having basically the same problem.
Changing unit.caste causes it just to change immediately back after I unpause even if unit.status.current_soul.caste and unit.status.souls[0].caste have been changed (and those two don't change back after unpause)

Not yet.  Admittedly I haven't had much time to play with it since then.  I'm sure the answer is simple, probably just changing the caste number somewhere else.  Darned if I know where though.  Maybe somewhere not in the units vector?  Can't imagine why it would be elsewhere.

[TDarksword]

Did you get anywhere with this Telgin?

I am having basically the same problem.
Changing unit.caste causes it just to change immediately back after I unpause even if unit.status.current_soul.caste and unit.status.souls[0].caste have been changed (and those two don't change back after unpause)

Not yet.  Admittedly I haven't had much time to play with it since then.  I'm sure the answer is simple, probably just changing the caste number somewhere else.  Darned if I know where though.  Maybe somewhere not in the units vector?  Can't imagine why it would be elsewhere.

I tried changing it in historic too, no effect.. Hmmm wonder where else it is.

[Rumrusher]

Did you get anywhere with this Telgin?

I am having basically the same problem.
Changing unit.caste causes it just to change immediately back after I unpause even if unit.status.current_soul.caste and unit.status.souls[0].caste have been changed (and those two don't change back after unpause)

Not yet.  Admittedly I haven't had much time to play with it since then.  I'm sure the answer is simple, probably just changing the caste number somewhere else.  Darned if I know where though.  Maybe somewhere not in the units vector?  Can't imagine why it would be elsewhere.

I tried changing it in historic too, no effect.. Hmmm wonder where else it is.

you could change it under the enemy section of the unit list. which has the were caste and wererace files needed.

[Ashery]

Alright, time for some basic questions and such about .lua scripting as I'm tired of digging through a bunch of sources and trying to reinvent the wheel.

The core functionality I'm looking for is the ability to modify the skill levels of certain dwarves, and while there are a bunch of examples in the last twenty odd pages that do just that (Most based off of vjek's), they all only utilize two methods for selecting who'll be modified: All dwarves (Useless to me) and the currently selected dwarf (Impractical as I'll be modifying 18-90 dwarves for each trial and likely doing over two dozen trials per world, although only one world is planned at the moment). They also all don't currently include more nuanced modifications, but that would be straightforward to modify.

My first thought regarding the selection process revolves around giving all dwarves a numeric nickname and adjusting the skills of all dwarves with nicknames divisible by x (n = n + x), but I've no idea about both where to start implementing that on the scripting side and if it's even possible to do so. Alternatively, I might be able to do the same with something a bit more hard coded, but that'd likely require a bunch of filters for dead units and the like as well as not necessarily leaving me with 1/x of the dwarves modified.

Once the selection process is tackled, the scripting necessary to allow the user a finer degree of control over the skill levels should be straightforward (Define a bunch of local variables that require user input and call it a day). Hell, I could just modify the script directly/hard code the values it changes the skill level to for each trial.

I might also need to zero out all dwarves with preexisting military skills, but if the nickname method works, I can simply not give them a nickname and exclude them from the sample that way. There are also a number of preexisting scripts for this and, unlike the portion where I increase skills, this is something that will only be done on a per-world basis and so there'll be a lot less effort involved if I have to brute force it.

Outside of that, the only other scripts I'm looking at are the one that triggers a migrant wave (I'm assuming it bypasses the liaison check/set pop cap, so correct me if I'm wrong) and the object creation one (Uniform gear quality. Less variables the better), both of which I'd be able to wrap my head around easily on my own. With both of those setup, I'd be able to get a new world ready for trials in <30min. But that still leaves me needing to figure out how to get the skill modification script setup...

[Rumrusher]

You want the dwarf manipulator to have a abililty to edit the skills of a unit? I think someone here made a morul script.

[GiantUrist]

I've been trying to use binpatch on the Mac OS X version of dwarfort.exe, but no luck. I tried both binary binpatch from the command-line as well as the script when DFHack is running. I saw that the hack/patches folder only has SDL and Linux patches, so I am guessing that there aren't any binary patches for OS X (yet).

Can somebody confirm and/or shed some light on this issue? I am willing to learn how to make those patches myself if that is at all possible.

Thanks in advance,

[TDarksword]

Did you get anywhere with this Telgin?

I am having basically the same problem.
Changing unit.caste causes it just to change immediately back after I unpause even if unit.status.current_soul.caste and unit.status.souls[0].caste have been changed (and those two don't change back after unpause)

Not yet.  Admittedly I haven't had much time to play with it since then.  I'm sure the answer is simple, probably just changing the caste number somewhere else.  Darned if I know where though.  Maybe somewhere not in the units vector?  Can't imagine why it would be elsewhere.

I tried changing it in historic too, no effect.. Hmmm wonder where else it is.

you could change it under the enemy section of the unit list. which has the were caste and wererace files needed.

Ahh ha, yep changing unit.enemy.normal_caste fixed it. Though I did need to make sure I was upgraded to find that, as in dfhack 34.11r2 that didn't exist

But yeah Telgin you need to change
unit.enemy.normal_caste (changing this is what causes the transformation message. So if you change this and not unit.caste, unit.caste will be updated with a transformation message)
unit.current_soul.caste (not sure this is needed, though might mess some things up if soul and actual caste's don't match)
and probably the historical figure caste (for completeness).

[danaris]

I've been trying to use binpatch on the Mac OS X version of dwarfort.exe, but no luck. I tried both binary binpatch from the command-line as well as the script when DFHack is running. I saw that the hack/patches folder only has SDL and Linux patches, so I am guessing that there aren't any binary patches for OS X (yet).

Can somebody confirm and/or shed some light on this issue? I am willing to learn how to make those patches myself if that is at all possible.

Thanks in advance,

There has, as yet, been no official effort to get binpatches working for OS X. The Linux ones may have some applicability, or may not.

If you come to the #dfhack channel on Freenode and ping Delvin (me), assuming I've got some free time I'm willing to help you stumble about in the dark trying to find stuff... (This will be more likely during weekdays in American Eastern time.)

[Telgin]

Did you get anywhere with this Telgin?

I am having basically the same problem.
Changing unit.caste causes it just to change immediately back after I unpause even if unit.status.current_soul.caste and unit.status.souls[0].caste have been changed (and those two don't change back after unpause)

Not yet.  Admittedly I haven't had much time to play with it since then.  I'm sure the answer is simple, probably just changing the caste number somewhere else.  Darned if I know where though.  Maybe somewhere not in the units vector?  Can't imagine why it would be elsewhere.

I tried changing it in historic too, no effect.. Hmmm wonder where else it is.

you could change it under the enemy section of the unit list. which has the were caste and wererace files needed.

That did the trick.  I was confused and never found these numbers because in my version of DFHack at least, it's under a unit's unknown8 struct.  Perhaps that was renamed in the most recent release?

Either way, setting the normal_caste number and stepping or unpausing the game caused the victim to immediately change to what I wanted.

[TDarksword]

Did you get anywhere with this Telgin?

I am having basically the same problem.
Changing unit.caste causes it just to change immediately back after I unpause even if unit.status.current_soul.caste and unit.status.souls[0].caste have been changed (and those two don't change back after unpause)

Not yet.  Admittedly I haven't had much time to play with it since then.  I'm sure the answer is simple, probably just changing the caste number somewhere else.  Darned if I know where though.  Maybe somewhere not in the units vector?  Can't imagine why it would be elsewhere.

I tried changing it in historic too, no effect.. Hmmm wonder where else it is.

you could change it under the enemy section of the unit list. which has the were caste and wererace files needed.

That did the trick.  I was confused and never found these numbers because in my version of DFHack at least, it's under a unit's unknown8 struct.  Perhaps that was renamed in the most recent release?

Either way, setting the normal_caste number and stepping or unpausing the game caused the victim to immediately change to what I wanted.

Yep same problem I had. in 34.11r2 it is under .unk8, need to update to 34.11r3 for it to be under .enemy.

[vjek]

Spoiler (click to show/hide)

Alright, time for some basic questions and such about .lua scripting as I'm tired of digging through a bunch of sources and trying to reinvent the wheel.

The core functionality I'm looking for is the ability to modify the skill levels of certain dwarves, and while there are a bunch of examples in the last twenty odd pages that do just that (Most based off of vjek's), they all only utilize two methods for selecting who'll be modified: All dwarves (Useless to me) and the currently selected dwarf (Impractical as I'll be modifying 18-90 dwarves for each trial and likely doing over two dozen trials per world, although only one world is planned at the moment). They also all don't currently include more nuanced modifications, but that would be straightforward to modify.

My first thought regarding the selection process revolves around giving all dwarves a numeric nickname and adjusting the skills of all dwarves with nicknames divisible by x (n = n + x), but I've no idea about both where to start implementing that on the scripting side and if it's even possible to do so. Alternatively, I might be able to do the same with something a bit more hard coded, but that'd likely require a bunch of filters for dead units and the like as well as not necessarily leaving me with 1/x of the dwarves modified.

Once the selection process is tackled, the scripting necessary to allow the user a finer degree of control over the skill levels should be straightforward (Define a bunch of local variables that require user input and call it a day). Hell, I could just modify the script directly/hard code the values it changes the skill level to for each trial.

I might also need to zero out all dwarves with preexisting military skills, but if the nickname method works, I can simply not give them a nickname and exclude them from the sample that way. There are also a number of preexisting scripts for this and, unlike the portion where I increase skills, this is something that will only be done on a per-world basis and so there'll be a lot less effort involved if I have to brute force it.

Outside of that, the only other scripts I'm looking at are the one that triggers a migrant wave (I'm assuming it bypasses the liaison check/set pop cap, so correct me if I'm wrong) and the object creation one (Uniform gear quality. Less variables the better), both of which I'd be able to wrap my head around easily on my own. With both of those setup, I'd be able to get a new world ready for trials in <30min. But that still leaves me needing to figure out how to get the skill modification script setup...

You could always just iterate through the first however-many-you-want with remove_all_skills and then use a modified armoks_blessing on the same however many.

If you don't want to pick them manually or automatically, pick the first 18 or 90.

On the other hand, whatever your goal is, the Object Testing Arena may help?

[Maklak]

I play a mod with spells and I would find the "showunitsyndromes.rb" script quite useful, but I just got a bunch of errors from it. I saved the r3 version to hack/scripts directory, loaded the game and run the script, but it didn't work. I'm using the WINE version of Dwarf Fortress with dfhack r3, under Linux Mint. Other things work normally for me.

Here are the errors:
[DFHack]# showunitsyndrome
Dwarves
`Pierce' townvalley trianglebook cherish
E: NameError: undefined local variable or method `print_syndrome' for main:Object
 ./hack/scripts/showunitsyndrome.rb:786
 ./hack/ruby/ruby-autogen-defs.rb:390:in `each'
 ./hack/ruby/ruby-autogen-defs.rb:390:in `each'
 ./hack/scripts/showunitsyndrome.rb:786
 ./hack/scripts/showunitsyndrome.rb:904:in `[]'
 ./hack/scripts/showunitsyndrome.rb:904
 ./hack/scripts/showunitsyndrome.rb:903:in `each'
 ./hack/scripts/showunitsyndrome.rb:903
[DFHack]# showunitsyndromes
E: Errno::ENOSPC: ./hack/scripts/showunitsyndromes.rb:33:in `write': No space left on device
 ./hack/scripts/showunitsyndromes.rb:33
 ./hack/scripts/showunitsyndromes.rb:33
 (eval):787:in `load'
 (eval):787
 (eval):787:in `catch'
 (eval):787
[DFHack]# showunitsyndromes
E: Errno::ENOSPC: ./hack/scripts/showunitsyndromes.rb:33:in `write': No space left on device
 ./hack/scripts/showunitsyndromes.rb:33
 ./hack/scripts/showunitsyndromes.rb:33
 (eval):34:in `load'
 (eval):34
 (eval):34:in `catch'
 (eval):34

After a reset:
[DFHack]# showunitsyndromes
Dwarves
`Pierce' townvalley trianglebook cherish
E: NameError: undefined local variable or method `print_syndrome' for main:Object
 ./hack/scripts/showunitsyndromes.rb:786
 ./hack/ruby/ruby-autogen-defs.rb:390:in `each'
 ./hack/ruby/ruby-autogen-defs.rb:390:in `each'
 ./hack/scripts/showunitsyndromes.rb:786
 ./hack/scripts/showunitsyndromes.rb:904:in `[]'
 ./hack/scripts/showunitsyndromes.rb:904
 ./hack/scripts/showunitsyndromes.rb:903:in `each'
 ./hack/scripts/showunitsyndromes.rb:903
[DFHack]# showunitsyndromes
E: Errno::ENOSPC: ./hack/scripts/showunitsyndromes.rb:33:in `write': No space left on device
 ./hack/scripts/showunitsyndromes.rb:33
 ./hack/scripts/showunitsyndromes.rb:33
 (eval):787:in `load'
 (eval):787
 (eval):787:in `catch'
 (eval):787
[DFHack]#