Print

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

[expwnent]

It is a cool application, it's just hard to do.

[expwnent]

Actually, what you were saying is probably better as an interaction. You'd only need special EventManager support if you wanted to do something like make any body part that attacks a metal golem get bruised. I do plan on doing the interaction trigger thing, as we've discussed in other threads.

[Roses]

Actually, what you were saying is probably better as an interaction. You'd only need special EventManager support if you wanted to do something like make any body part that attacks a metal golem get bruised.

Yes, I have it working as interactions right now and it works well (especially since you can specifically tell the creature how often to use the attack, so you don't get a string of tail swipes in a row and then none for awhile).

I do plan on doing the interaction trigger thing, as we've discussed in other threads.

And I greatly look forward to it. The amount that could be done with an interaction trigger is astounding. And much of my scripts are already written in such a way that they could truly benefit from it.

[Meph]

Does this new system work, if the reaction is set to repeat 'R', and does it not trigger, if an active reaction 'A' is cancelled?

These are my only gripes with AutoSyndromes as it is, that repeat doesnt work, and that cancelling gives you the product for free.

[expwnent]

I'm pretty sure I fixed both of those a year ago. Are you sure you've tested it lately?

[expwnent]

Well this is awkward.

It looks like there's been very memory research on interactions. So little, in fact, that I don't know how to get the list of interactions a unit can do, and I can't even get the attack verb and defend verb of an interaction given a pointer to it. Until that's done, I essentially can't do an interaction event. Maybe I can do something awkward and horrible that still technically works, but it'll be harder than I expected.

[Roses]

Yeah, I've noticed that there hasn't been much research done on interactions.

[expwnent]

Good news! The event works. It reads the attack string and defend string from the game log directly. It does NOT check that the string is correctly associated with an interaction that the attacker should be able to do. The only problem is that if the attacker and defender are on the same tile and have the same name as it shows up in the game log, then it can't figure out who did The Thing so it doesn't fire the event at all.

Now all I have to do is write up an interaction-trigger script and we'll be good to go.

edit: Done.

[Roses]

Thats great news!

Can I get an example of how it works?

Also, have you finalized the standardization? If so I will begin to look at my scripts and how to move them over to the new system.

[expwnent]

I'm almost done with the complete overhaul I wanted to do. I'll have a beta release ready in a day or two. With that you'll have loads of examples and you'll be able to actually test stuff.

For an example of interaction-trigger:

Code: [Select]

interaction-trigger -onAttackStr "casts a magic spell" -command [ devel/printArgs "here are the special argument values: " \\ATTACK_VERB \\DEFEND_VERB \\ATTACKER_ID \\DEFENDER_ID \\ATTACK_REPORT \\DEFEND_REPORT ] -suppressAttack -suppressDefend


[Roses]

Couple Questions:

1. I'm guessing that the -onAttackStr is the CDI:VERB, correct?
2. This means that the need for SYN_CLASSes is a thing of the past right?
3. supressAttack and suppressDefend means that the game won't generate the VERB and VERB_TARGET announcements?
4. What is the difference between ATTACK_VERB and ATTACK_REPORT?

This is looking great. I am sure I will have more questions as I go through and modify my scripts.

[expwnent]

1. Yes.
2. Yes! The goal was to get rid of silly things like that entirely.
3. Precisely, yes. You still get the "The unit is fighting!" announcement, but it doesn't show up in the log. I'll see what I can do about that.
4. ATTACK_VERB is the CDI:VERB string. ATTACK_REPORT is the index of the report which contains that string.

[expwnent]

As for conventions, look at the scripts/modtools folder. Basically I like things to work like that. Have a comment explaining briefly what the script does. Use utils.parseArgs and a validArgs table. Document what all the arguments do. That sort of thing.

[Meph]

3. Precisely, yes. You still get the "The unit is fighting!" announcement, but it doesn't show up in the log. I'll see what I can do about that.

Now you got my curious.

One of the big problems for players, when using a lot of interaction based features, is that the texts appear in the combat log. It spams it full, making it hard to follow, as well as making it hard to find actual combat. If the VERB and TARGET_VERB could be somehow automatically blocked from the combat log, and instead used as an announcement, that would help a lot.

[expwnent]

It already does that. If you want I'll look into preventing the "Unit 2 is fighting!" announcement and the big red R showing up on the left too.

Code: [Select]

modtools/interaction-trigger -onAttackStr "attack verb" -suppressAttack -suppressDefend

That should do it if you don't want to actually trigger anything. I might have made it so you have to have a command, but if you just say -command [ ] then maybe it'll magically do what you want. I haven't tried.

PS: I included the delete-invader-items script you were asking about a few weeks ago. See the r5e1 thread for the download link.