Code Crowing: Thenomain Edition
My Github grows and I guess I wanted a place to say: This is here, please use it, I think it's pretty awesome.
None of this is what I would consider the absolute must have code of a Mux: Bboard, Mushcron, Anomaly Jobs, @Whence, and Events. If you're not using these five systems, you should.
I have a place for most of my stuff. These systems are small and most of them are not copy/paste and call it done, tho I do get there eventually.
And now, on with the crowing.
I'm not the biggest fan of Anomaly Jobs, but I'm just going to have to be in the minority until I can come up with a suitable replacement. Some games use it so heavily that adding to it might feel like a trip down to the local doctor's for your weekly leeching.
These games have come up with a way to sort out player or even other staffer requests, put them in the right bucket, assign them to the right +jgroup, and let the staff figure out what to do with them next.
The Jobs Request System is essentially a complete rewrite of The Reach's
+req, in such a way that it should be trivial to add to.
Drop it into Muxify and viola.
Code Object Data Parent
Most of my code objects end up being filled with attributes. I mean, filled. Here's an idea if what I mean:
Thenomain types -=> think attrcnt( #209 ) 64
Sixty-four attributes to do what? This is
Wiki News and Help <wnh>, and all it does is looks at a database and pulls a file. The nWoD 2 data dictionary has 595 attributes for Core and Demon. I mean it. I like using attributes.
What I don't like is losing track of what's where. Here's an old, old trick that has been used quite a lot:
@desc object=lattr( %! )
Well that's good, but what about sorting them so that all the
&cmdattributes are together? Okay, what if you use
&c? How about sorting them with headers? Why not do this, or that, ot this other, or, or, or ...
:::::::::::::::::::::::::. WoD Health System <whs> .:::::::::::::::::::::::::: Desc is null for this code object. ..: Data :.................................................................... d.data-dictionary d.health-types d.stat-funcs ..: Commands :................................................................ c.hurt c.heal ..: Functions :............................................................... f.conv-type f.do-some-dmg f.healhurt-workhorse f.min-dmg f.do-some-dmg.push f.healhurt-errorcheck f.reverse-max-health f.do-some-dmg.wrap ..: Displays :................................................................ display.health-bar display.health-detail display.health-descr display.current-health-descr :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::. 17 attributes .::
This is the result of the Code Object Data Parent. Muxify. Copy. Paste.
If I had a "must have for Mux" code, then this is it, an informational blob to help people get up to speed on the code around them. It's not fit for everything; don't use it on a gigantic code system like Anomaly Jobs, but for pretty much every other project I find it almost indispensable.
Thenomain last edited by Thenomain
Did You Know: Off-Site Backups
#!/bin/bash # # takes the last two touched files and uses the google drive cli # # the last two touched files will be the flatfile (*.tar.gz) and # the sql file (*.sql.gz) # # this is pretty specific to eldritchmux # BACKUPS="/home/mu/eldritch/game/backups" BINLOC="__REDACTED__" GDRIVEFOLDER="__REDACTED__" # for DUMP in $(ls -Atr $BACKUPS/*.gz | tail -2) do $BINLOC/drive-linux-amd64 upload -f $DUMP -p $GDRIVEFOLDER done
Does it work? Boy howdy does it work. We have it running 10 minutes after the other two backups: One for Flatfile, one for SQL. (Are you using SQL and not backing it up? Why?) That is, the
| tail -2means it will back up the two most recently touched (usually created) files in the directory. Adjust this number for the number of files that count as "recent".
Likewise thanks to @Chime for her earlier work on Mu* server maintenance, for the SQL dump script this is also using.
Thenomain last edited by Thenomain
A Full-Featered Character Approval System
From the Explanation:
Characters tend to go through a number of various states, from completely new to dead. This part of the character generation system keeps track of that.
Here is the help file: http://eldritch.mechanipus.com/w/index.php/Help:Chargen_2
This can be translated to any Mux with four spare user-defined flags. It would be trivial to change the code from 'cg/<status>' to 'app/<status>'.
I think this is pretty fucking cool code to have, and I finally think it's done. Please share.
Alzie last edited by Alzie
On pennmush, separating out Commands, Functions, Data and Displays is even easier thanks to Attribute trees. It's one of the things I like about pennmush. Mux is very annoying in that respect, because seeing a giant list of attributes isn't useful to anyone, Pennmush actually formatting it in a tree is useful Also, lattr respecting the levels is even better. That being said, attribute trees in pennmush are easily the most misunderstood thing that new coders encounter and that ultimately breaks their code when they first get started, especially if they're used to mux's version of lattr.
What unformatter do you use, Thenomain? I know you say 'drop in Muxify', but the way you document things doesn't get that stuff filtered out, so either I go through and manually pick it all out or there's a whole bunch of Huh?'s and mail complaints. That doesn't seem right, so I'm assuming you are using a different unformatter? (I'm tempted to go write my own)
Bobotron last edited by
Attribute trees are love.
What unformatter do you use, Thenomain?
I started in my own editor, then switched over to Muxify. If you're getting mail complaints, this is my older unformatter.
To use Muxify with this stuff, you'll need to do three things:
- Grep edit
\\ --and possibly comment `* ... *' around my infamous notes to myself.
- Indent everything but the first line of an attribute.
2a. Sometimes you'll have to comment out 'test' code, too.
- BEWARE: I do use
c.<xxx>\*sometimes, where the
*is literal! Muxify doesn't like this. I cannot help that yet.
Attribute trees are love.
Meh. I prefer my own solution. But then, doesn't everyone prefer what they prefer.
- Grep edit
So I'm starting over in my attempt to create a single framework for who, where, and all the commands that are like who and where, like hangouts and finger. Where is who + location, hangouts is where + room information. Finger is who + player object information.
So far I have: who, where, finger, staff, duty, name, idle sweep. (I'm told the idle sweep is the most adorable idle sweep.)
I've even started adding preferences to the setup. For example, I like separating out people in 'who' who are idle for more than 2 hours. I imagine that some people don't like this idea (it's never really caught on), so there's now a single attribute to change this behavior. And because it's all on the same object, this also stops graying out people in 'who' who are idle.
Enjoy. Updates to follow.
I would petition you to add +watch to this framework, for two reasons: 1) +watch is effectively +who, but constrained to a specific list; 2) when using +who and +where, it can be very useful to see people you're watching for be highlighted.