[Ohrrpgce] Chained auto-set tags

Ralph Versteegen teeemcee at gmail.com
Thu Nov 22 16:25:58 PST 2018


Also, we could add an "update npc visibility" command just for the
case where you modify a global and want NPCs dependent on autoset tags
to immediately update.
On Fri, 23 Nov 2018 at 13:23, Ralph Versteegen <teeemcee at gmail.com> wrote:
>
> There would be no changes to when evalitemtags and evalherotags are
> called. I was only suggesting adding an extra call to tag_updates
> after interpret_scripts.
> But OK, good to know that people do actually depend on the "set tag"
> function calling tag_updates.
> Although, I think all the other calls to tag_updates would become
> unnecessary if tag_updates were instead called immediately before
> updating NPCs/heroes and before displayall, because those are the only
> things, aside from scripts, that actually depend on visibility being
> updated.
> On Fri, 23 Nov 2018 at 13:06, James Paige <Bob at hamsterrepublic.com> wrote:
> >
> > 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
> >
> > _______________________________________________
> > Ohrrpgce mailing list
> > ohrrpgce at lists.motherhamster.org
> > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org


More information about the Ohrrpgce mailing list