[Ohrrpgce] Chained auto-set tags

[James Paige]

Ooh!

I like the idea of having tags that can be turned on by combination of
there tags. It seems like a powerful feature, and global checks is a nice
extension.

I am also happy to see that old conditional work you did get dusted off. :)

I am worried about the idea of changing the re-checking of evalitemtags and
evalherotags

I often write scripts that grab npc handles in the same tick as the tag
change that made the npc visible, and I wouldn't want to be writing wait(1)
in between doing a thing that changes a tag and storing an NPC handle that
became available because of the tag



On Thursday, November 22, 2018, Ralph Versteegen <teeemcee at gmail.com> wrote:

> 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
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20181122/4f24086b/attachment.html>