[Ohrrpgce] Chained auto-set tags

[Ralph Versteegen]

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