Ralph Versteegen
2018-11-22 13:56:38 UTC
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).
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).