Print

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

[Roses]

Unfortunately the towards and away from propelling isn't working right now. In my next update, which shouldn't be too long now, I will have working versions.

EDIT: I am having way to much fun writing scripts, and not getting nearly enough actual modding done. Just created a script that works as shooting a projectile (like material emission), but it can shoot anything (i.e. ammo, weapons, boulders, armor, whatever item you want). Tested it out by creating a 'bullet' ammo and then giving a unit an interaction that shoots a dozen bullets a second. Tore apart the poor goblin...

And you can even change the range and chance to hit! Now to figure out how to make it take actual ammo from the unit firing. And figure out if I can speed up the bullets at all.

[Deon]

That is amazing! I will gladly use it to make machinegun turrets .

[Roses]

Unfortunately it still relies on needed to get the casting unit (which has difficulties as explained in previous posts). I have actual decided that I may be able to investigate the material emission interactions for help in finding both the casting and targeted unit. Since they are both needed for the interactions, that information should be available somewhere in DFHack. I think that will be the best way.

[Warmist]

You could use projectiles. They have info about hitting target and who shot it. So interaction that shoots a projectile + eventful.onProjItemCheckImpact might help though i have not experimented very much with it.

[Roses]

Actually, what I was hoping to be able to do is tie into the interaction itself, for example;

Code: [Select]

[INTERACTION:TEST1]
[I_SOURCE:CREATURE_ACTION]
[I_TARGET:A:MATERIAL]
[IT_MATERIAL:MATERIAL:INORGANIC:SOME_INORGANIC:SPATTER_LIQUID]
[I_TARGET:B:CREATURE]
[IT_LOCATION:CONTEXT_CREATURE]
[I_TARGET:C:CREATURE]
[IT_LOCATION:CONTEXT_CREATURE]
[IT_MANUAL_INPUT:target]
[I_EFFECT:MATERIAL_EMISSION]
[IE_TARGET:A]
[IE_TARGET:B]
[IE_TARGET:C]
[IE_IMMEDIATE]If I was able to access each of the three targets at the moment the interaction is cast, then I would have the caster, the target, and an inorganic. I could then read off the inorganic a script to run. This is all just theoretical now as I haven't actually looked at the innards, but it seems reasonable that I might be able to do something of this sort.

[Meph]

Sounds perfect for the cannon siege engine creature I wanted to do for the humans...

Warmist, what ever happened to your dragonfire siegeengine?

[Warmist]

Sounds perfect for the cannon siege engine creature I wanted to do for the humans...

Warmist, what ever happened to your dragonfire siegeengine?

Waiting for next dfhack release... Also there is a crapload of other small building mods that i'm procrastinating instead of finishing

[Roses]

Actually, what I was hoping to be able to do is tie into the interaction itself, for example;

Code: [Select]

[INTERACTION:TEST1]
[I_SOURCE:CREATURE_ACTION]
[I_TARGET:A:MATERIAL]
[IT_MATERIAL:MATERIAL:INORGANIC:SOME_INORGANIC:SPATTER_LIQUID]
[I_TARGET:B:CREATURE]
[IT_LOCATION:CONTEXT_CREATURE]
[I_TARGET:C:CREATURE]
[IT_LOCATION:CONTEXT_CREATURE]
[IT_MANUAL_INPUT:target]
[I_EFFECT:MATERIAL_EMISSION]
[IE_TARGET:A]
[IE_TARGET:B]
[IE_TARGET:C]
[IE_IMMEDIATE]If I was able to access each of the three targets at the moment the interaction is cast, then I would have the caster, the target, and an inorganic. I could then read off the inorganic a script to run. This is all just theoretical now as I haven't actually looked at the innards, but it seems reasonable that I might be able to do something of this sort.

So looking through the df-structures, I don't see anything about material emission interactions. In fact, I really don't see anything about interactions at all except for in df.syndrome.xml and it just seems like that is about syndromes not interactions (despite them being listed as creature_interaction_effect). Any idea if this information exists somewhere and maybe just hasn't been categorized yet?

EDIT: In the interaction raws stored in DFHack there is a reference to each of the three targets of a material emission interaction. Now presumably, every time an interaction is used it is linked to the raws and filled out (much how creature and items are created, except the interaction is not persistent) The only question remaining is if it is possible to catch the interaction when it is used and pull this information from it.

[Roses]

Sorry for the lack of updates, I have been busy with RL stuff recently.

However, I do have one thing to post, it's a ReadMe! You can find it in the github release. It's not very pretty, but it outlines all the scripts, what they do, and gives very basic examples. Note that the ReadMe is ahead of the currently available scripts. As I upload the new scripts and update the old I will include even more examples.

[expwnent]

All I am trying to do is reliably get the target and user of an interaction when it is used. Like how you can currently say \UNIT_ID, I would like to instead have \TARGET_ID and \USER_ID.

The only way I have found so far is to read announcements (generated from CDI:VERB and CDI:TARGET_VERB) to determine the users name and find the unit that way. The problem with that method is when there are several interactions being used at once, I have not found a reliable way to make sure the correct announcement is tied to the correct action. It may be that the announcements (VERB and TARGET_VERB) are linked in some way, if that is the case then I could read the targets announcements and determine from there, although it may have the same problem as it does now, where many interactions, used simultaneously, results in incorrect assignment of \USER_ID.

Figuring out when a unit used an attack or interaction on another unit is probably possible, but difficult. I'll put it on my todo list for EventManager and expose it to eventful when it works. I probably won't have it for the next dfhack release, but that's definitely a cool thing that I'd like to support with something like syndromeTrigger, some sort of interactionTrigger plugin that monitors combat and interactions.

For now, if you monitor the combat logs regularly, you ought to be able to do something clever in your particular case. Just keep track of which units are fighting and hope you don't get conflicts on a frame by frame basis. You can even delete things from the announcements list if you want to trigger something you can see with a script that you don't want the user to see. Poke around the announcements and combat logs and see what you can do. I'll bet the combat logs will be more helpful than you think, especially since individual units have combat logs as well as the global announcement log, log log log blah this sentence is too long and says log too many times. Hopefully you'll kind of sort of get what I'm saying. I'm being vague because I haven't really thought about it much.

[Roses]

All I am trying to do is reliably get the target and user of an interaction when it is used. Like how you can currently say \UNIT_ID, I would like to instead have \TARGET_ID and \USER_ID.

The only way I have found so far is to read announcements (generated from CDI:VERB and CDI:TARGET_VERB) to determine the users name and find the unit that way. The problem with that method is when there are several interactions being used at once, I have not found a reliable way to make sure the correct announcement is tied to the correct action. It may be that the announcements (VERB and TARGET_VERB) are linked in some way, if that is the case then I could read the targets announcements and determine from there, although it may have the same problem as it does now, where many interactions, used simultaneously, results in incorrect assignment of \USER_ID.

Figuring out when a unit used an attack or interaction on another unit is probably possible, but difficult. I'll put it on my todo list for EventManager and expose it to eventful when it works. I probably won't have it for the next dfhack release, but that's definitely a cool thing that I'd like to support with something like syndromeTrigger, some sort of interactionTrigger plugin that monitors combat and interactions.

For now, if you monitor the combat logs regularly, you ought to be able to do something clever in your particular case. Just keep track of which units are fighting and hope you don't get conflicts on a frame by frame basis. You can even delete things from the announcements list if you want to trigger something you can see with a script that you don't want the user to see. Poke around the announcements and combat logs and see what you can do. I'll bet the combat logs will be more helpful than you think, especially since individual units have combat logs as well as the global announcement log, log log log blah this sentence is too long and says log too many times. Hopefully you'll kind of sort of get what I'm saying. I'm being vague because I haven't really thought about it much.

That would be great if you could look at it for a future DFHack release.

Right now I am using the announcements and combat reports and it works fairly well. When a script is run I check the global announcements and read backwards to find the first combat report with the correct type (146 or 147 for interactions depending on if they are the target or the user). Perhaps I should also look into personal combat reports to cross check. I bet if the targeted unit has a combat report its global id will only be off from the users by 1 (you would hope), so that might be an easy way to verify the correct combat report gets read.

I suppose another thing I could do is add another argument to the script so that it reads only reports with that string in it, then only interactions of the exact same kind would interfere with each other, instead of all interactions.

[expwnent]

PS: Overall I'm amazed and impressed at how effectively people are using autoSyndrome and syndromeTrigger. To you and the other people who have used it a lot, what extensions would be useful to you? I've only done enough testing on them to confirm that they work, so I don't know what would be handy for convenience. In general, if it can be done with an lua script and keeping the plugins as they are, then it should be, (like the random chance script), but if there's a simple extension that would make more things possible, or would be much easier to do in C++ than in lua, then I could do that.

[Meph]

The probability of the PRODUCT of the reaction triggering autosyndrome should be the chance that autosyndrome triggers. So PRODUCT:5:1: should have a 5% chance of starting autosyndrome. See Urist mcteellox ProbabilitySyndrome. It could be included in AutoSyndrome directly. Have a look at it, it even allows to add X different scripts, but only one triggers. So for example you add 10 products with 10% each, it will trigger exactly one and discard the rest.

If a reaction that would triggers AutoSyndrome is active and then cancelled, Autosyndrome triggers, without using up any reagents. This leads to exploits.
 

[expwnent]

The probability of the PRODUCT of the reaction triggering autosyndrome should be the chance that autosyndrome triggers. So PRODUCT:5:1: should have a 5% chance of starting autosyndrome. See Urist mcteellox ProbabilitySyndrome. It could be included in AutoSyndrome directly. Have a look at it, it even allows to add X different scripts, but only one triggers. So for example you add 10 products with 10% each, it will trigger exactly one and discard the rest.

If a reaction that would triggers AutoSyndrome is active and then cancelled, Autosyndrome triggers, without using up any reagents. This leads to exploits.

If I end up doing interactionTrigger then if I did it that way I would have to implement ProbabilitySyndrome twice, one for each. It's easy enough to write an lua script that does random probabilities, so it would be a better design to just say "always run this script which triggers other scripts with certain probabilities" than "sometimes run this script". It is a good programming practice to separate logical components so they can be reused. I admit I should have written something like ProbabilitySyndrome myself in lua, but I still maintain it shouldn't go in autoSyndrome.

It's also more powerful this way. In df, I believe all reaction probabilities are independent, so you can't have a 10% chance of making a superdwarf and a 90% of killing the unit. It would instead by a 9% chance of making a dead superdwarf, a 1% chance of a living superdwarf, and so on. If you roll the dice yourself, you get to say how they get used.

Are you sure the cancellation bug still happens in r4? I'm positive I attempted to fix it and tested it several times.

[Roses]

I'm not sure if this would be something you would want to try and tackle in autoSyndrome, or if it is better left to a lua script, but some way to check that the application of the syndrome was successful and to give back the components (or take them) depending on if it failed (or succeeded)