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