Duncan R. said: Hi @Kurt. Just wondering if you had any more thoughts on: 1. A dedicated comment function or a change to --| so that if you put it in front of another valid command it won't execute it? Only useful for debugging but easier than cutting and pasting code in/out of a scriptcard script while developing. 2. And did you think of any other way I could fudge passing variables between scriptcard macros? I haven't tried using the load/save parameter yet, but that was going to be my next attempt. Just wondered if these were possible or not. For #1, how about a "log" statement that would spit out a line to the API Console log if #debug was turned on and do nothing if it isn't? See below for #2 David M. said: That second one would be tricky. I'm assuming your thought is to have a master scriptcard execute and output a button linked to another scriptcard macro that would use a roll created by the master card? The only thing I can think of is some kind of read/write commands to an variable/object scoped to the scriptcard namespace (or to State, I suppose, though it seems like it wouldn't be necessary to persist between sessions). Master scriptcard writes, then subordinate scriptcard reads it. The subordinate scriptcard would need to do some checking to ensure the value existed (responsibility of the macro writer). The hypothetical read command should probably also delete (or have option to delete) the stored variable/object once it it is read to avoid potential downstream shenanigans. If optional, could allow for hitting that original button several times if needed. Some interesting (potentially useful) things could happen if the subordinate scriptcard also wrote values. Chaining sequences and whatnot. This starts to get into some pretty Meta territory, though. Might be just more of a thought experiment, depending on Kurt's roadmap/priorities and if he really wants to start opening that can of worms. Also, he's going to run out of ASCII special character prefixes eventually, haha! Yea, --S and --L store variables to state (currently no way to delete them, but I'll work on something). That is likely the only way to pass things back and forth. I guess you could store items as attributes on characters (maybe make a dummy character to store them) and use chatsetattr to set them and the normal attribute notation to read them. And that last part (Also, he's going to run out of ASCII special character prefixes eventually, haha!) is why I started implementing things as functions with --~ :) My current plan for v0.0.15 is to add three new functions: "range", which handles min, max, and clamp (limit a value to be between a min and max), "round" which supports up, down, floor, and ceil, and "stringfuncs" which I've currently got planned for strlength, substring, and replace. Might be a couple of other string functions that would be worthwhile to implement.