Print

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

[lethosor]

A brief 0.43.05 update:

DFHack is getting to the point where it can be compiled as 64-bit and run with a 64-bit DF without dying completely. Finding offsets so it can actually do useful things with DF is a bit harder, since jjyg's scripts choke on some changes brought around by MSVC 2015 and GCC 4.8, and most don't work at all with 64-bit DF, and he's away for another week or so. Mifki has been working on more scripts to locate things for 64-bit DF (many thanks there), and NCommander got 32-bit Linux working, from what I remember.

Note: If you've been using the "world.cur_savegame" structure in any personal scripts, it turns out that it has probably never existed - all of those fields (save_dir, save_version, etc.) are world fields instead. Mifki should have fixed occurrences of these in DFHack, but for anyone else using that structure, plan to make changes there.

[Dirst]

Thanks for the update lethosor!

As for my detecting embark, the onload.init runs just before the embark screen loads rather than just before the fort loads... which means unfortunately rummaging through history won't work, but fortunately I only need to detect the embark screen.

For a new fort the onload.init runs while df.global.gps.screen.value is 0, and then it becomes 219 when the embark screen is ready for user input.  It is also 219 in fort mode and arena mode and while a saved game is reloading, so I'm not sure what that value is really supposed to represent.  But, since you can't get to "screen 0" in an active fort it's good enough for my purposes.

This is good luck, because I can't make heads or tails out of the .events in the entity, nor can I find the .activities.

[Snafu]

Can any DFH dev (or appropriate scripter) say if a command to copy orders in the new (0.43.x) management screen (similar to military screen) is being worked upon?

Initially placing orders is very useful, but when you want to have pretty much the same order conditions for thread, cloth, (individual) clothes/armour pieces etc etc it can quickly become a timewasting PITA

I guess I'm asking for /user-defined/ order templates.. (preferably independently saved so they can be used across embarks/worlds, but the initial ability to do the above would help immensely!)

[lethosor]

We've been mostly working on 0.43.05 support, not features. We're also not very psychic and don't usually work on suggestions without them being suggested first.
(I've added that on the issue tracker, which is a good place to suggest things, since they're less easily-buried there than here.)

[Snafu]

Tks Leth; I wasn't aware of a suitable place to add requests, that's why I posted here. I'll use the tracker in future, when I remember

Perhaps amend the first post to include that link for suggestions rather than only bugs, or will that overwhelm you?

[Teneb]

I got a question about item-trigger: does -onStrike also work for ammo?

[Roses]

I got a question about item-trigger: does -onStrike also work for ammo?

Don't think so, but there is projectile-trigger for ammo

[Teneb]

I got a question about item-trigger: does -onStrike also work for ammo?

Don't think so, but there is projectile-trigger for ammo

Oh, thanks.

By the way, I'm trying to use create-unit and reaction-trigger to spawn a creature, but it's not working (but isn't spitting an error in the dfhack window either). Here's the code:

Code: [Select]

modtools/reaction-trigger -reactionName SPAWN_DEBUG -command [ modtools/create-unit -race GOLD_HOUND -caste DEFAULT -civ_id \\LOCAL -group_id \\LOCAL -domesticate -location [ \\LOCATION ] -age 1 ]

[Dirst]

On a phone at the moment so I can't check, but make sure the parameters are right.  Might be civId and groupId.  In any case, it ought to throw an error unless reaction-trigger suppresses that for some reason.

[Teneb]

On a phone at the moment so I can't check, but make sure the parameters are right.  Might be civId and groupId.  In any case, it ought to throw an error unless reaction-trigger suppresses that for some reason.

Well, it was part of the problem. changing civ_id to civID spits this out:


While I'm at it, when using create-unit with interaction-trigger, how do I make it so that the created creature is of the same group as the unit performing the interaction?

EDIT: Changing -civ_id \\LOCAL -group_id \\LOCAL to -civ_id a -group_id a made them spawn. But now I'm running into some weirdness. Sometimes, it spawns a single one, but others it spawns multiple. I've noticed a few things about this: if I repeat the reaction, it will always spawn the same number every time. The number change when I close DF and open it again. The multiplied creatures will fight each other, and only each other. If I spawn two groups of two creatures, each will only fight it's own pair.

[Dirst]

Well, it is definitely -civId and -groupId (note the camelCaseCapitalization), and \\LOCAL will make them aligned with the player's fort which ought to be aligned with the person performing the reaction.

[Teneb]

Well, it is definitely -civId and -groupId (note the camelCaseCapitalization), and \\LOCAL will make them aligned with the player's fort which ought to be aligned with the person performing the reaction.

\\LOCAL is simply not working for me, instead getting me the error I pasted above. Anyway, it's mostly working now, just have no idea why it's sometimes spawning multiple creatures who then proceed to try to murder each other. Any idea why that's happening?

On an unrelated note, are the any plan to allow for projectile-trigger to, well, trigger based on the item type of the projectile rather than its material?

[Roses]

When using it in interaction-tigger you need to add an extra \

[scourge728]

I have a feeling once this updates something will break

[Warmist]

For a new fort the onload.init runs while df.global.gps.screen.value is 0, and then it becomes 219 when the embark screen is ready for user input.  It is also 219 in fort mode and arena mode and while a saved game is reloading, so I'm not sure what that value is really supposed to represent.  But, since you can't get to "screen 0" in an active fort it's good enough for my purposes.

The gps.screen.value iš the first tiles ( upper left corner) character. So it might fail with fps display on ( or off)