[Ohrrpgce] Chained auto-set tags

[Ralph Versteegen]

On Fri, 23 Nov 2018 at 02:56, Ralph Versteegen <teeemcee at gmail.com> wrote:
>
> Oh dear, far too long an email, and mostly thinking out loud...
>
> A new user was asking in the Slime Salad Discord server (a half a
> dozen new people have appeared in the last week or two - due to KBB?)
> how they could create an NPC that appeared based on three tags instead
> of two.
> You have two poor options to combine tags: use textbox conditionals or
> scripts (when should the script run?)
>
> Every time I add a tag condition to something I wonder whether I
> should make two or even more tags. But without some kind of freeform
> way to add conditions and effects (like you would have in a visual
> programming environment), adding more means more clutter and
> complexity.
>
> Then I had an idea: tags which are autoset based on multiple other
> tags (either AND or OR). Let's call them chained tags for the moment.
> You'd edit them in the tag editor. The tag editor ought to (try to?)
> disallow loops.
>
> And then I remembered the Conditions I added 8 years ago (the test
> editor is still in the SPAM menu) which can be either a tag check or a
> ==/<>/</<=/>/>= check on a global variable. The ability to check a
> global variable was never worth the complexity before. It may stillnot
> be worth the trouble, since any script that sets a global could just
> set a tag at the same time. But I think we might support setting
> globals from Custom in future, eg to count things in-battle like Pepsi
> requested or textbox "increment global" conditionals. And this way, we
> can just using full-blown Conditions in one place and magically gain
> the ability to check globals everywhere, instead of a whole lot of
> inconsistency as to where they're available. (Now "chained tag" seems
> like a bad name.)
>
> I've partially implemented this in Game, while editing, saving and
> loading are missing:
> https://bitbucket.org/rbv/ohrrpgce/commits/73020c0d10bb49ecc84c914620741172375435ed?at=chained_tags
> (I'm amused to see Bitbucket say that I have 99+ branches. I just
> pushed 10 new ones...)
>
> However, supporting checks on globals creates a problem.
>
> Currently all autoset tags are recomputed by evalitemtags and evalherotags.
> And any time a tag may have changed, autoset or not, tag_updates is
> called (currently it only updates npc and menu item visibility).
>
> Recomputing all chained tags any time a global is changed would be
> crazy, but there could be a cache of globals named in Conditions. It
> would still be inefficient, especially in the new script interpreter.
> Even then, all chained tags would need recomputing (or else, a tree of
> "depends on" links is needed), and it would require a topological sort
> to update them in the right order.
> So instead, I made istag recompute the value of a chained tag when
> asked about it (so istag becomes recursive). Far simpler and probably
> more efficient unless istag gets called lots. Though the chains might
> get pretty long; I can imagine people using them heavily, e,g, "Task X
> done" autoset based on "Task X-1 done" plus other stuff, or test
> whether you have a steel weapon by checking 30 different item autoset
> tags.
>
> However that only deals with half the problem; tag_updates would still
> need to get called whenever any Condition global is changed.
> I would just suggest getting rid of tag_updates calls and instead call
> it unconditionally each tick (except when a textbox is up). But that
> seems like too big a backcompat headache for scripts which could
> possibly expect NPCs or menu items to update immediately after
> flipping a tag. Well.. how likely is that, really?
>
> I guess I could just add an extra tag_updates call after scripts are
> run, in case a global changed, plus anywhere else we set globals in
> future, and document that changing a global variable doesn't cause
> NPCs/menu items to update instantly (chained tags will update
> instantly).

Hmm, yes, I should just do that and use what I already implemented;
the minor delay in NPCs/menu items is so insignificant it might not be
worth documenting anyway. And the implementation can always be changed
later