[T3] Request for feedback on extensions

Authoring TADS
1

I’ve been working on doing a bug-fix and source release of It, and in the process I’ve been cleaning up a couple of extensions I wrote as well. I’d appreciate any feedback on them before I release them officially.

Easy Listing allows you to print lists with message parameter substitutions, similar to the way I7’s list printing works. It’s already been released on this forum, unofficially. The version attached to this post is functionally identical to the one I posted previously; it’s just undergone a slight name change and had the documentation cleaned up a bit. If anyone has been using it since I posted, please let me know how it’s going! I only used it for one thing in It, so I haven’t tested it much yet.

reaction.t (still lacks a snappy name) lets you use BeforeAction and AfterAction objects for reactions instead of beforeAction() and afterAction() methods. With It, I had a bunch of NPCs reacting to all sorts of different actions and situations. If I’d packed it all into their beforeAction() and afterAction() methods, the resulting code would have been a nightmare to read and debug. Splitting it off into individual BeforeAction and AfterAction rules made it so much easier to work with.

Since I used it a lot in It, I’m fairly confident that reaction.t is stable. There are almost certainly improvements that could be made, though.

Please take a look and let me know if you find any bugs or have any suggestions for either of the extensions!
reaction.zip (4.46 KB)
easyListing.zip (3.04 KB)

2

Without having tested it, I’d say reaction.t looks very nice indeed – quite useful and well thought-out.

Rather than commenting out the condition property, you might make condition = true by default and then, at the end of isActive():

//... return condition;

…rather than testing if (propDefined) and so forth. Would that work?

I really ought to come up with an idea for a game so I can try using some of these new features…

3

Thanks!

I was wondering that myself yesterday, when I was tidying up the documentation. I feel like I considered it when I wrote the extension and then decided to use propDefined() instead, but I can’t remember the rationale behind that decision. Possibly so that you can tell whether condition has been specifically set by the author or not? That could maybe be useful, I guess… It certainly doesn’t look like using “condition = true” instead would cause any problems.

4

It occurred to me today that it would be a good idea to make sure that reaction.t’s “priority” property worked the same way as any similar properties in adv3. (At the moment, Reactions with the lower-numbered priorities run first, and the default priority is 50.) So I looked up a few other classes and discovered that even within adv3, priority-type properties aren’t implemented consistently. AgendaItem gives priority to the lowest-numbered agendaOrder, but Thing.vocabLikelihood, TopicEntry.matchScore and the verify result logicalRank all give preference to higher values. AgendaItem.agendaOrder, TopicEntry.matchScore, and logicalRank default to 100, but Thing.vocabLikelihood defaults to 0.

I think the way Reaction currently works is definitely wrong, though. Since the property is called “priority”, you’d expect low priority items to have low priority values, and high priority items to have high values, which is the opposite of how it currently works. I could change it around, or maybe the best solution might just be to rename the property.

Or maybe I could stop over-thinking this and go to bed instead. That also sounds good.

5

I’ve made some changes and bug-fixes to reaction.t. Attached version 0.2 below.

Changelog:

  • changed priority ordering from lowest-first to highest-first and made the default priority 100 to match similar properties in adv3
  • simplified handling of the “condition” property
  • fixed a remarkably stupid bug where I’d done all the work to implement RoomBeforeAction and RoomAfterAction classes except, y’know, actually implement those classes
  • changed Reaction.isActive to always return nil if isDone is true (previously this only worked if isOneOff was also true, but authors might want to set isDone manually on other kinds of Reactions as well)
  • added credits module

Obviously, since I never finished implementing RoomBeforeAction and RoomAfterAction, they haven’t been tested at all yet. They shouldn’t give any problems, but… I’ll do some testing on them tonight, if I have time, or on the weekend.
reaction.zip (4.74 KB)

6

The Actionater?

I’m still fresh to TADS and Inform, though I’ve been into IF for thirty years (I may have actually used Inform a while ago, but it was a while ago - perhaps I am mixing it up with something different), my nephew just started school, so I’m keen to make some nice things for when he learns to read…

I’ll have a try of those extensions, and get back to you sometime soon…