Print

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

[milo christiansen]

reaction-trigger is really nice for some things, but the good old auto-syndrome can't be beat for others.

I wonder how hard it would be to make a modern version... I'm a little busy right now, but I may have time to play with it some in a week or so.

[Dirst]

Just out of curiosity, has anyone looked into how boogeymen, demons and normal animal clusters get spawned by the game?  The current version of create-unit uses a trick mifki figured out to use Arena Mode momentarily, but there is still some instability which says to me that at least some of the data structures used in Fort Mode are uninitialized.

Boogeymen appear out of nowhere; animals and demons appear out of nowhere but pulling from abstract populations.  The Starting Seven and the initial migrants might call the same function, or might be completely different because they're built from the ground up to be citizens.  Getting access to that method from DFHack would be the holy grail of spawning creatures, or even just the constructor for a unit would ensure that we don't miss something that might have evaded DF Structures.

What kind of instability?

There probably aren't entirely separate constructors for citizens and non-citizens. There's probably some method(s) DF uses to turn units into citizens, but unit doesn't have any virtual methods, so finding those methods would require a lot more disassembly and manual searching for each build of DF.

It crashes fairly regularly if Roses' attack.lua is used on a spawned creature in 0.43.  I circumvented the need for that script in my mod and things seem better, but I still get the occasional crash a few seconds after a creature is spawned.  The attack issue might be an anon that changed between 0.42 and 0.43, but the remaining crashes sound to me like an uninitialized value somewhere that is only relevant sometimes.  Unfortunately it's a crash-to-desktop so it doesn't leave behind much to troubleshoot.  There is nothing in stderr.log after the call to create-unit.

[Meph]

reaction-trigger is really nice for some things, but the good old auto-syndrome can't be beat for others.

I wonder how hard it would be to make a modern version... I'm a little busy right now, but I may have time to play with it some in a week or so.

You have no idea how I feel right now. The lack of autosyndrome is the reason I could not update MasterworkDF and almost gave up modding. Took a break for over a year and then came back, put in over two-hundred hours of work to slowly and painstakingly update the mod... still not done...

Lethosor: Here the save. https://www.dropbox.com/s/j529lbe1vgc2kpn/Dwarf%20Fortress%20-%20Meph%20Edition.rar?dl=0

I added the entire game folder, because everything is heavily modded. Its the newest dfhack release. Just open the Onload.ini in the raw folder, I made comments at the top.

tl;dr:
- Embark, look at the kitchen. It has 4 test reactions, 3 to armor an animal, 1 to transform it. The one that transforms it will crash the game. I already pastured a rat on the workshop.

[milo christiansen]

Be happy! You have piqued my interest, and I will work on it just as soon as I have Underhive Settlement done.

[lethosor]

I don't know how to distinguish between the two options you mention.

Option 1:
- You run the command
- DF crashes immediately

Option 2:
- You run the command
- DF does not crash immediately
- Later, maybe when the MUTATE_RAT_TO_GIANT reaction occurs, DF crashes

The difference is that in the first case, modtools/reaction-trigger is crashing, and in the second, modtools/add-syndrome is crashing.

Anyway, thanks for the save - hopefully it'll help us fix the issue. I've reported it on the tracker, although 0.43.05 is taking priority for now.

It crashes fairly regularly if Roses' attack.lua is used on a spawned creature in 0.43.  I circumvented the need for that script in my mod and things seem better, but I still get the occasional crash a few seconds after a creature is spawned.  The attack issue might be an anon that changed between 0.42 and 0.43, but the remaining crashes sound to me like an uninitialized value somewhere that is only relevant sometimes.  Unfortunately it's a crash-to-desktop so it doesn't leave behind much to troubleshoot.  There is nothing in stderr.log after the call to create-unit.

Does attack.lua succeed on non-spawned creatures? And are you saying create-unit crashes even without attack.lua?

No script should be touching anon fields (although apparently create-unit is one of the few that does). Is attack.lua on Github anywhere? It could be an issue with either script, or both.

(Also, information about crashes in stderr.log is very rare. The last command you ran is probably there, and relevant, but of course you would know that already.)

[Dirst]

It crashes fairly regularly if Roses' attack.lua is used on a spawned creature in 0.43.  I circumvented the need for that script in my mod and things seem better, but I still get the occasional crash a few seconds after a creature is spawned.  The attack issue might be an anon that changed between 0.42 and 0.43, but the remaining crashes sound to me like an uninitialized value somewhere that is only relevant sometimes.  Unfortunately it's a crash-to-desktop so it doesn't leave behind much to troubleshoot.  There is nothing in stderr.log after the call to create-unit.

Does attack.lua succeed on non-spawned creatures? And are you saying create-unit crashes even without attack.lua?

No script should be touching anon fields (although apparently create-unit is one of the few that does). Is attack.lua on Github anywhere? It could be an issue with either script, or both.

(Also, information about crashes in stderr.log is very rare. The last command you ran is probably there, and relevant, but of course you would know that already.)

Oh I understand that the stderr.log isn't going to have Null pointer in .enemy structure... scrawled by a bloody finger.  Was just pointing out that no other script had run since.

I'll need to check attack on normal units, as I said I just worked around it.  attack.lua is included with Masterwork under raw/scripts/unit, I don't know where the original repository is.

[Roses]

reaction-trigger is really nice for some things, but the good old auto-syndrome can't be beat for others.

I wonder how hard it would be to make a modern version... I'm a little busy right now, but I may have time to play with it some in a week or so.

You have no idea how I feel right now. The lack of autosyndrome is the reason I could not update MasterworkDF and almost gave up modding. Took a break for over a year and then came back, put in over two-hundred hours of work to slowly and painstakingly update the mod... still not done...

Lethosor: Here the save. https://www.dropbox.com/s/j529lbe1vgc2kpn/Dwarf%20Fortress%20-%20Meph%20Edition.rar?dl=0

I added the entire game folder, because everything is heavily modded. Its the newest dfhack release. Just open the Onload.ini in the raw folder, I made comments at the top.

tl;dr:
- Embark, look at the kitchen. It has 4 test reactions, 3 to armor an animal, 1 to transform it. The one that transforms it will crash the game. I already pastured a rat on the workshop.

Hopefully my finishing up of my wrapper script will alleviate all of your concerns. It is only in a semi-usable state at the moment, but it does allow for all of the functionality that auto-syndrome had plus so so much more. I currently use it to select specific castes and genders for interactions and to keep genders across transformations with a single command. Honestly, I can't think of a single thing that auto-syndrome did that scripts don't do currently. And if there is, that functionality should be added to existing scripts. For instance

Code: [Select]

modtools/reaction-trigger -reactionName MUTATE_RAT -allowNonworkerTargets -command [ wrapper -unitSource \\TARGET_ID -unitTarget \\TARGET_ID -aclass CLASS_NAME -script [ modtools/transform-unit -unit \\TARGET-race RAT_GIANT -caste MALE -suppressAnnouncement ]  ] ]Would only target a creature if it has CLASS_NAME as a specific creature class (note that it may require an extra \ or two, I can't test at the moment, but I know checking for creature classes and syndrome classes is something the script does correctly). And in fact there are better ways with the wrapper script than declaring unitSource and unitTarget including choosing creatures within a certain radius of the initiating worker. For example, I think the best way to do it would be,

Code: [Select]

modtools/reaction-trigger -reactionName MUTATE_RAT -allowNonworkerTargets -command [ wrapper -unitSource \\WORKER_ID -target civ -radius [ 10 10 2 ] -maxtargets 1 -aclass CLASS_NAME -script [ modtools/transform-unit -unit \\TARGET-race RAT_GIANT -caste MALE -suppressAnnouncement ]  ] ]That will do a single target within 10x10x2 of the workshop and transform them only if they have the creature class CLASS_NAME

As for attack.lua, that script comes from my repository and is in raw/scripts/unit/attack.lua. I see no reason that a spawned creature should be any different than a non-spawned creature since attack.lua only influenced the actions of a unit. If there is indeed a difference between the actions of a spawned creature and a normal creature that really needs to be worked out in create-unit.lua. Please let me know if how and when attack.lua is crashing, as that is one of the few scripts that I have thoroughly tested in Arena, Fortress, and Adventure mode. Note that between the last version and this version certain anon fields were given names (particularly attack velocity and attack hit chance). If the script hasn't been correctly updated it may still be trying to access anon fields that are actually named fields.

[Hetairos]

Is there a way to make the teleport.lua script run with DFHack 0.34.11-r5? I'm trying to apply this fix, but if I just drop the script into the scripts folder all I get is the following syntax error.

[lethosor]

For one thing, the error message would be more readable if you could actually copy and paste the text. Assuming the reason you didn't is because you're on Windows, you can do it by right-clicking in the console and/or right-clicking the console title bar.

Anyway, is line 15 "]====]"?  Is line 4 "--[====["? Where did you get the script from? If you got it from https://github.com/DFHack/scripts/blob/master/teleport.lua, did you make sure to click "Raw" and download that?

[Dirst]

As for attack.lua, that script comes from my repository and is in raw/scripts/unit/attack.lua. I see no reason that a spawned creature should be any different than a non-spawned creature since attack.lua only influenced the actions of a unit. If there is indeed a difference between the actions of a spawned creature and a normal creature that really needs to be worked out in create-unit.lua. Please let me know if how and when attack.lua is crashing, as that is one of the few scripts that I have thoroughly tested in Arena, Fortress, and Adventure mode. Note that between the last version and this version certain anon fields were given names (particularly attack velocity and attack hit chance). If the script hasn't been correctly updated it may still be trying to access anon fields that are actually named fields.

I was referring to the attack.lua packaged with Masterwork (since that's what these particular end-users would be using), and I agree the fault is probably in create-unit.  That attack script does not touch any anon fields.  Just hoping that working under 0.42 and broken in 0.43 turns out to be a decent clue in fixing create-unit, since I'm not the only person who pokes at it.

[Hetairos]

For one thing, the error message would be more readable if you could actually copy and paste the text. Assuming the reason you didn't is because you're on Windows, you can do it by right-clicking in the console and/or right-clicking the console title bar.

Anyway, is line 15 "]====]"?  Is line 4 "--[====["? Where did you get the script from? If you got it from https://github.com/DFHack/scripts/blob/master/teleport.lua, did you make sure to click "Raw" and download that?

No, I got it from here. The one you posted gives me this:

Code: [Select]

G:\Gry\df_34_11_win\hack\scripts/teleport.lua:31: attempt to call field 'invert' (a nil value)
stack traceback:
        G:\Gry\df_34_11_win\hack\scripts/teleport.lua:31: in main chunk
        (...tail calls...)

[lethosor]

There's no way that script you linked to could possibly have worked, ever. You could try changing "==tonumber" to "=tonumber" on lines 15, 16, and 17, but there could be other issues too.

The one in the DFHack/scripts repo was added in 2014, so it's not too surprising that it wouldn't work with 0.34.11. It looks like it relies on a few features for argument processing that were added in 2014, too.

[milo christiansen]

The one in the DFHack/scripts repo was added in 2014, so it's not too surprising that it wouldn't work with 0.34.11. It looks like it relies on a few features for argument processing that were added in 2014, too.

Replace the argument processing and that script will probably work. AFAIK teleporting is a fairly simple matter of changing the creature's position (unit.pos).

[Putnam]

The one in the DFHack/scripts repo was added in 2014, so it's not too surprising that it wouldn't work with 0.34.11. It looks like it relies on a few features for argument processing that were added in 2014, too.

Replace the argument processing and that script will probably work. AFAIK teleporting is a fairly simple matter of changing the creature's position (unit.pos).

Just doing that will cause horrible issues down the road, since every single pos that a unit's teleported from while standing will be permanently inaccessible unless actions are taken to prevent that or fixes are done down the road (the former, naturally, being preferable, though I think DFHack currently comes with an occupancy fix script). teleport.lua included in DFHack already does this.

[Hetairos]

Considering I'm going to savescum anyway and the ony units I really need to teleport are outside the map, that might not be a problem.

But I'd rather be careful and not have it mess up caravans or something again. Too bad I have no clue how to Lua.