Named registers via setr() and setq()
One of the absolute worse things about softcode is its register system. The need for such a thing is great, and our code is littered with things like %q3,%q4,%q5, which can make sense when you're writing things. But looking back at something even as short as a week later usually means trying to figure out what in the world %q3 is. Or worse yet, getting them mixed up.
Something I've been whining for on MUX as well is named registers. RhostMUSH is the only one I know of so far that has this. Basically, something like this would be legal:
> think [setr(SOMEVAR, value)][r(SOMEVAR)]
value
So now you've got a nice, named variable that can be self-documenting. I'm begging for something like this as my games are extremely code heavy. My background is in BattletechMUX, which has a Penn port under experimentation, and I'm considering using it instead of MUX for my next project. The selling feature of our kind of game is how code-heavy it is. Everything from combat to econ is very detailed and complex, so the lines start adding up very quickly and it can be painful to look through more than a few %q registers.
- Kelvin McCorvin's blog
- Login or register to post comments
Click 
There are a few tickets for
There are a few tickets for something similar on the dev site, mostly suggesting either using setr()/r() like Rhost (I think?), or a new setx()/x() function (which is what TM3 does), by the looks of it. It might not hurt to open another (or comment on one of those) to bring it up to the top again, though. (dev.pennmush.org is the official source management/bug tracker/feature request/etc site for Penn.) The quickest way to get something in is always by writing it yourself and submitting the patch, though, if you're able to.
Good call, I commented on a
Good call, I commented on a few of the old ones, although I'm not sure that'll draw up any attention.
This would definitely be awesome for the complex kind of things we have to write to go along with our combat system and econ. Sometimes there just isn't way to avoid juggling a handful of registers, which gets to be pretty confusing.
Commenting
I tend to write most of my code off-MUSH and comment it that way, but a couple of possibly-useful ways to comment registers are by using a comment attr, like:
or using the @@() comment function where you actually set the registers, with some variation on
Not quite as clear as actually being able to name the registers, I know, but it's a start.
setx and x in softcode:
A stopgap:
@create setx object
@power setx object=many_attribs
&tree setx=Tree for variables
@startup setx=@wipe me/tree`** ; &counter me=1
&counter setx=1
@set setx/tree=no_command
&fun_setx setx=if(cor(cand(%qx,visible(%@,v(tree`%qx))),1[attrib_set(me/counter,inc(setr(x,v(counter))))][attrib_set(me/tree`%qx,%@))]),attrib_set(me/tree`%qx`%0,%1)
&fun_setxr setx=u(setx,%0,%1)%1
&fun_x setx=if(visible(%@,v(tree`%qx)),v(tree`%qx`%0))
@startup some admin object=@function setx=setx,fun_setx ; @function x=setx,fun_x ; @function setxr=setx,fun_setxr
A bit of explanation:
I key it to a counter so that it's kept across queue entries: "think setx(foo,bar) ; @wait 5=say x(foo)" will say "bar". If I wiped it whenever %qx was unset, then it would lose that feature.
This has a requirement that only the object that set it (%@) or any object that can examine it (passes visible()) can use x() to fetch its registers. (This prevents people from doing "think setq(x,5)[x(foo)]" to sneak a look.
Any object that doesn't have permission gets a new %qx set and its own setx() set of attributes. This may be handy with
localize() or ulocal().
This gives us one feature that makes it a bit more useful than typical q-registers:
If you do: "think setq(x,foo) ; @wait 5=setq(x,bar) ; @wait 10=say r(x)", you will say 'foo', because the registers are copied for each entry. But with the above setx()/x(), It's basically a 'pointer' that's kept across, so the above command using setx()/x() instead of setq()/r() will say 'bar'.
(Note: I just wrote this up here without running on a mush. Untested, so use at your own risk.)
--
My kingdom for a minute of silence!
TM3 does this
TinyMUSH 3 offers arbitrarily-named registers for setq() and setr(), accessed via r() or %q:
setq(VAR, value) or setr(VAR, value)
r(VAR)
%q<VAR>
These are handled exactly like %q0 through %qz.
The current patchlevel also has a function called qvars() which parses a list and sets each element into a variable.
For instance, let's say I have D&D-style character sheet data. I can do:
&STATS funcs = Str Int Wis Dex Con Cha
&GET_STATS_FN funcs = [qvars(v(STATS),get(%0/DATA))]
&SET_STATS_FN funcs = [set(%0,DATA:[iter(v(STATS),r(##))])]
Now I can just do a u(GET_STATS_FN,%#) to grab the enactor's stats, for instance, and it's all nicely set into r(str) (or %q<str> if you prefer), r(int), r(wis), etc. for manipulation. If I changed any stats, I can just call u(SET_STATS_FN,%#) at the end of my code block. No need to mess with list positions and whatnot -- just get variables, do stuff, save variables, good to go. (You can use arbitrary delimiters in the lists, so you can store complex data this way, too. You could always use a wildmatch() or regmatch() to read formatted, non-list data into variables, too, and then write a save function that spits it out.)
(As Talvo mentioned, TinyMUSH also offers named "permanent" variables which are persistent but are not saved in the database, via setx() et.al., but frankly, the register behavior, identical to %q0 et.al., is what you want 99% of the time...)