Print

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

[lethosor]

I would remove (or rename) the "hack" folder (and "stonesense" if it exists) first, assuming you don't have anything important in them.

[Mrandom]

Hi, to what extent does "modtools/force" work in 40.24 now? Or is it going to be replaced by "spawn-unit" in the future?

[Putnam]

It works entirely, except for sieges. I've been working on siege spawning, but that seems to rely on some variables that I cannot modify at all.

EDIT: This isn't working either:

Code: [Select]

modtools/reaction-trigger -reactionName WISH_DB_ADV -command [ dragonball/wish -unit \\WORKER_ID ]
I tested that with print-args and it printed nothing.

[Dirst]

During all of this current_soul searching, has anyone happened upon the values required to make a creature into a functioning member of the fort?  When I use warmist's spawn-unit script to make an animal, it's fine for hostile ones but unreliable for friendly ones.  Giving it the player's civ_id will make it appear "Tame" on the units list (and keep it from attacking) but "Not Tame" on the z/Animals list (which prevents it from being a pet) even if I gm-editor its training level.  I recall reading that the creature can revert to hostile when the game is saved and re-loaded, but I haven't witnessed this personally.

Comparing the gm-editor screens for a natural specimen and a spawned specimen hasn't gotten me anywhere, but that's because I'm not familiar with the object model.  If someone can point me to the proper attributes and values, I think I can make the Lua code changes necessary.

The immediate use of proper fort membership would be to enable war-training and such for spawned animals, and I have plans for assigning specific creatures as pets of specific dwarves in a later expansion.

And, it doesn't get said nearly often enough that DFHack and the other third-party tools are awesome and invaluable additions to the DF game and community.

Did you give it the civ_id for both unit.civ_id and unit.status.current_soul.civ_id? I was able to turn animals into tame members that appear as tame both in the units screen and the z/animals. Although this was with already existing animals, and not those spawned by the script. (I also changed all of the unit.animal tokens to -1, not sure what effect that actually has though)

I couldn't find a civ_id attribute under unit.status.current_soul, but I did find two attributes that fix the is-it-tame-or-not dilemma:

unit.flags1.tame = true
unit.training_level = 7

The problem is that for some reason no one in this fort is adopting any pets (natural nor spawned), so I can't be sure this is everything needed.  I did notice that my Starting Seven have

unit.flags1.tame = false
unit.training_level = 9

Those are the default values that a spawned unit would have.  Is there a way to spotcheck a creature for being an intelligent race/caste before I set these flags?  It could be hacked by checking if the species matches the player's civ, but that won't be robust to multi-species forts that are just around the corner.

Edit: Success! New test embark, and this time the spawned critter was adopted right away.  Now to see what happens if I bring in a domesticated dwarf.

Edit 2: Okay, the dwarf spawned with no relationships (and thus no religion), which I expected.  He doesn't have a dream, so something is unfinished there.  The game is fine leaving him with no name, he's listed as Peasant (tame) on the units list, and will take labor assignments.  I'm glad he didn't show up on the z/animals list

So, this is not the way to make a well-rounded citizen for your fort, but it'd be unrealistic to expect that.  For now, no need to spotcheck for intelligent species since citizen forging is beyond the current version's capabilities anyway.

[Putnam]

Is there a way to spotcheck a creature for being an intelligent race/caste before I set these flags?  It could be hacked by checking if the species matches the player's civ, but that won't be robust to multi-species forts that are just around the corner.

Code: [Select]

local caste=df.creature_raw.find(unit.race).caste[unit.caste]
if caste.flags.CAN_SPEAK and caste.flags.CAN_LEARN then
    --stuff
end


[Dirst]

Is there a way to spotcheck a creature for being an intelligent race/caste before I set these flags?  It could be hacked by checking if the species matches the player's civ, but that won't be robust to multi-species forts that are just around the corner.

Code: [Select]

local caste=df.creature_raw.find(unit.race).caste[unit.caste]
if caste.flags.CAN_SPEAK and caste.flags.CAN_LEARN then
    --stuff
end


Of course, the minute I decide that it'd be a lot of work for little practical benefit, you go ahead and build it.  Must be part dwarven

[Bo-Rufus CMVII]

I would remove (or rename) the "hack" folder (and "stonesense" if it exists) first, assuming you don't have anything important in them.

Thanks

(Keywords for future searchers: upgrade dfhack update dfhack)

[Mrandom]

It works entirely, except for sieges. I've been working on siege spawning, but that seems to rely on some variables that I cannot modify at all.

EDIT: This isn't working either:

Code: [Select]

modtools/reaction-trigger -reactionName WISH_DB_ADV -command [ dragonball/wish -unit \\WORKER_ID ]
I tested that with print-args and it printed nothing.

"force" is a great feature, one of my favorite, in fact. Excuse me if I'm using it in a wrong way, but it seems not working on r7 and r10...The only eventType that works are Caravan and Migrants, and I cannot specify a civ id after "-civ" for Caravan but can only use entity enums like "FOREST", "PLAINS", "MOUNTAIN", etc.

Here are some test cases I tried both under r7 and r10:

Code: [Select]

modtools/force -eventType CivAttack -civ EVIL   // Invalid eventType, line 58
modtools/force -eventType FeatureAttack -civ EVIL // nothing happens, FeatureAttack is an enum from eventType, probably replacement for CivAttack
modtools/force -eventType Caravan -civ PLAINS // a random (maybe the first?) human civilization sends a caravan
modtools/force -eventType Caravan -civ 5034(entity-id) //cannot write field time_event.entity:incompatible pointer type, line 76
modtools/force -eventType Migrants // works regardless of -civ
modtools/force -eventType Caravan(or Diplomat) //game crash, probably need error catch for the second arg?
modtools/force -eventType (AnyOtherType) // nothing happens
modtools/force -eventType (InvalidEventType) //often throws an error, occasionally crashes the game. probably an error check would be better?

Test environment:
Platform: Windows 8.1
Settings: default pop cap, no aquifer, Mayday graphics, default dfhack utilities

Also I wonder what exactly to expect from all the Wildlife event types and NightCreature. I managed to make "WildlifeCurious" to work inconsistently by editing some args in the gui/gm-editor. It generated animals like gray langur or honey badger.
 

[Putnam]

IIRC it was never supposed to be entity IDs.

Also, r7 and r10?

[Mrandom]

Oh I thought the LNP integrated utilities use the LNP's version number. My bad. My DFHack version is 0.40.24-r3.

The "-help" print-out includes the following: "
-civ entity
        specify the civ of the event, if applicable
        examples:
            player
            MOUNTAIN
            EVIL
            28
"

So I thought "28" is an entity ID. What is it then? A raw-entity ID?

[Putnam]

Huh, weird. I should probably do a passover of the force code.

EDIT: My previous problems with my onload.init file was mainly a problem with the way I was calling it using the script command from a lua init, making it so that, if done in adventure mode, it would load in a context where events wouldn't properly run.

[yxe]

Hi,

I have a problem with the enhanced stock view...

Currently it doesn't resize itself to the screen size, and the description length of the items its too short and some descriptions
can't be readed.

Spoiler (click to show/hide)

there is some option where I can change this ??

[expwnent]

It works entirely, except for sieges. I've been working on siege spawning, but that seems to rely on some variables that I cannot modify at all.

EDIT: This isn't working either:

Code: [Select]

modtools/reaction-trigger -reactionName WISH_DB_ADV -command [ dragonball/wish -unit \\WORKER_ID ]
I tested that with print-args and it printed nothing.

Ok, it must be broken. I'll take a look.

[Putnam]

It works entirely, except for sieges. I've been working on siege spawning, but that seems to rely on some variables that I cannot modify at all.

EDIT: This isn't working either:

Code: [Select]

modtools/reaction-trigger -reactionName WISH_DB_ADV -command [ dragonball/wish -unit \\WORKER_ID ]
I tested that with print-args and it printed nothing.

Ok, it must be broken. I'll take a look.

Nope.

EDIT: My previous problems with my onload.init file was mainly a problem with the way I was calling it using the script command from a lua init, making it so that, if done in adventure mode, it would load in a context where events wouldn't properly run.

[expwnent]

Haha I guess I need to improve my reading comprehension. Thanks.