@Seamus They currently have access to virtual objects, which is fun, but I get what they want. I was looking at doing something like the first so I'm glad to see I'm not the only one who thinks that would be feasable. I would probably actually build a "forge" command that would just straight up make the item according to spec.
Still curious about what other people do to secure their code and objects from accidents and bad actors.
I've been spending a lot of time scotchguarding the code I've been writing, which I find satisfying mostly because it helps me verify my logic in big nested blocks of code. When I say scotchguarding, I mean protecting it from an accident and not actually securing it against bad actors. For me, this is mostly checks and locks to make sure that player inputs don't clash with each other. If you're a dragonborn, you shouldn't be able to take the hill dwarf subrace.
I have been taking some forms of input and passing it through secure() or escape() or flagging certain attributes as NO_EVAL. It strikes me that this is probably something I should always be doing, and yet that also feels like overkill so I've been only using it when interacting with objects that are INHERITing some sort of elevated permissions.
Now, I'm looking at a very cool feature request that would like the ability to let an object act like a weapon and actually interract with the character sheet and roller. Mostly because they saw a softcoded version and really liked it, but they want to use the weapon as an object. They'd like to put a sweet desc on it, for instance. I like the idea because they can pass that magic item around and there is no ambiguity as to who has the object, and because I can dump them into a treasure chest and they can open it like a gift.
This is probably fine for the 4 or 5 people I run a D&D game for. This will not scale well if the code goes public, because I instantly see counterfeitting becoming an issue.
What steps do you take to secure your code and objects, and why? I'm coming at this from a MUX perspective, but I'm curious about everyone's practices.
There may be a better name for it, but skills are in an alphabetical list right? This works fine until you get to Knowledge, which breaks into Knowledge: Arcana, Knowledge: History, Knowledge: Weird Campaign Thing #1, etc. They're just a bunch of blanks in the middle of the list to be filled in when appropriate. Maybe six are standard, and the rest are totally meant to be specific to your game. Profession does the same thing, but for literally any job you could have.
So having those in the middle of a list you want to reference by position could be a challenge. If I wanted to keep that, and I may, I just have to break them out into a parallel list. Which means adapting the standard character sheet, but I'm already adapting an entire game, why wouldn't I update the character sheet to reflect the medium?
I'm looking forward to working on the health system because I sort of expect it to be easier. It's just integer math. But d20 stuff is weird and I'll get it done and then I will remember "Oh you think you're clever? Now account for level draining attacks" and I'll have to go get a beer and think about it for a while.
@Thenomain Good catch on the missing attribute. I actually have it but had omitted it in the sample code. You've given me a lot to think about. For instance, position-based probably won't work with Pathfinder because of exploding knowledge/profession skills unless I put them somewhere else. 5th Edition at least just calls the skill "arcana" and it's on all the sheets.
@Thenomain Because of familiarity or because it is easier to manipulate the data? Good to know about the character sheets that you've made.
Some things are pretty constant, like WoD or d20 attributes. On the other hand, there are definitely some variations in skills. I was attempting to err on the side of caution by referencing a list of allowed items. Those, however, had to be matched to a value somewhere. I tend to want to think of these things as nested dictionaries in an optimal case, or paired lists with matching indices.
I've made these sorts of things before in spreadsheets, but pass by reference is getting really heavy. I get the feeling that I may be making things harder by trying to do them in a modular way.
To look at it from a D&D perspective, I'm expecting a situation where it is easier to mix() lists to derive the following:
Athletics = Proficiency Bonus + Attribute Bonus + Skill Ranks
&_5E.CHAR_PROFICIENCY obj=2
&_5E.CHAR_ATTRBONUS obj=[1] 2 1 0 0 0
&_5E.CHAR_SKILLRANKS obj=2 2 2 [4] 3...
&_5E.SKILLS codeobj=Acrobatics Animal_Handling Arcana [Athletics]...
I guess that really does read as more complicated than simply adding 3 attributes, even if it does mean you'd have to retool it if you wanted to run something like Pathfinder.
@Cheesegrater Perfect, thank you. Not what I would have expect it to be called, but it's such a frequent use case that I figured it had to be there somewhere.
Is there an elegant method in MUX to add the contents of two lists together at each indexed position?
For example:
a = 1 2 3 4 5 6
b = 10 20 30 40 50 60
result: 11 22 33 44 55 66
I already created something to add individual attributes together to create a, and it works but it is not elegant and not extensible.
It should be much easier to deal with indexing an array than dealing with six different attributes using extract() or some other function.
I've always assumed that character sheets usually looked more like:
&PHYSICAL %#=2 3 3
&STRENGTH %#=extract(u(%#/PHYSICAL),1,1)
&DEXTERITY%#=extract(u(%#/PHYSICAL),2,1)
...
Is this kind of array thinking fundamentally flawed, making it better to be verbose and explicit and not worry so much about extensibility?
I suppose I could set players as BLIND upon entry into the game area, but I'm not sure of a good way to know when to unset that flag. Returning home would bypass the conventional escapes.
Changing the player's parent to a nested parent upon entry runs into the same problem.
I wish there was a way to do like a zone player parent: when you are in this zone, this is your parent.
Any other way to do this besides blinding every single room in the area?
@ThatGuyThere Perhaps I should have said they are superfluous in my environment with properly set@*succ @*fail and @*drop messages. The rooms are not set as teleport_ok and the area amounts to a game board. It's basically multiplayer IF, with coded areas, NPCs, and the like.
There seem to be a few options to suppress the "has left" and "has arrived" tags in TinyMUX.
Set the BLIND flag on the location (or player).
It completely suppresses the tags but still executes @*succ and @*fail messages. I don't think it's possible for a parent object to pass its flags to children, however.
Set @*leave messages.
@leave and @oleave are supposed to decide what the player and others see when you leave a thing or room, but this seems to happen in addition to the tags.
The tags are superfluous in an environment with properly set @*succ @*fail @*drop messages. Is there a better way to remove them than blind every room?
Thanks @Ashen-Shugar @Lotherio. That's about what I figured, but it was worth asking.
Is there a good way to restrict attribute visibility to a list of objects (players, rooms, things) contained in an attribute list somewhere?
I know it can be restricted via underscore, or with attribute ownership as attribute owners can read the attribute on an object even if they don't own the object. Visible is too open.
A good example would be if you wanted to have a clan that could issue an arbitrary command and see the names of everyone in that clan... but you only wanted members already added to that clan to run the arbitrary command.
@Ashen-Shugar Looks like that won't work for MUX, sadly. While I can pipe commands I execute directly, like look %0, +finger %0 winds up calling something that @pemits the data back. I am guessing that since +finger %0 invokes @pemit, it's not actually returning anything that can be piped. The executed command is @switch. @pemit is just a possible result.
I tested it thusly:
&test.finger me=+test.finger *:+finger %0 ;| @set me=F.Result:%|
&test.look me=+test.look *:look %0 ;| @set me=L.Result:%|
L.Result was the exact result of looking at me couched in a @wait. F.Result put the +finger info on the screen and didn't create the attribute.
I get why mail() returning read, unread, sent is privileged info, but we commonly put it out there so it's frustrating.
Save for this piece, I've written a short command that iterates through my list of alts and tells me the last time I signed into them and if they're in danger of being deactivated due to disuse. It would have been nice to add unread mail count as well. Currently I'm just spamming myself with +finger for each and that's just wasteful.
@Ashen-Shugar Thanks, I'll look into that. As awkward as this could be, it's less awkward than going to a coder and saying "Hey, I wrote this and other people might find it useful. Look it over and install it?" Not everyone has the same use cases and it feels like criticizing the coder to suggest stuff like that.
For whatever reason, almost all +finger commands let you see other players unread @mail messages but mail() is wiz only for anyone but yourself. Trim() would let me excise the part I need, but is it possible to get the result of +finger info a form I can use trim() on?
@Thenomain said in What is out there? Hard and soft codebases of choice.:
However, for that bridge, Mushcode is far more capable than Evennia, at present. A huge reason is because Mush has immediate feedback tools.
The documentation available for Mush is also, although ancient, creating and building on foundations. The documentation I've seen for Evennia is instructive but my small peeve that "how to start an existing game" was missing is exactly the kind of thing that frustrates me about it.
It's also been around a lot longer. You do amazing and complex things, but even having access to your Github repository still means a fair bit of sanitizing and testing before things are up and running. I do love the way you format the code, though. It's much easier to read conceptually.
@faraday said in What is out there? Hard and soft codebases of choice.:
I agree that having a low "time to project" / "time to playing around" threshold is important. I think @WTFE brought up a great point earlier about bridging the gap from player to MUSH developer.
I'm not sure that it will ever be a low time to project, just a "lower" time to project. A low time to project would be literal step-by-step in the shell or the game with a bundle of documents intended to directly copied and pasted, or auto-said into the game. That doesn't bridge the gap, but that's probably the absolute floor. The only way to do it easier might be a DigitalOcean droplet already configured, or something.
There's two sides though, right? I like actually playing with the code, even if I'm really impatient and would sometimes just like to fork my own copy of the @Whirl / @Cheesegrater Tenebrae code to revive my college D&D group. I don't learn anything that way, but sometimes I don't want to learn. I've noticed many coders don't play so much anymore. I wonder if that's the temperament that makes them good coders or if they can't get on a game without seeing it as work.
@Thenomain said in What is out there? Hard and soft codebases of choice.:
I make fun of the SGP for being horrible code, but it is clear and simple and is a fantastic learning aid.
This is why I like the SGP. I think I've rewritten every one of them at some point, and taking apart the code and making my own probably taught me more about mushcode than anything else.
The more I work on MU type games, the more I realize that I've been interacting with the game as an abstraction. A lot of the commands I use frequently are someone else's commands, whether something like the common +finger and +watch, or something more specialized like non-wizard targeted build tools, character creation, +accolades, and so on.
@Ashen-Shugar said in What is out there? Hard and soft codebases of choice.:
One big thing we do have with Rhost is we have a built in execscript. This is a built in function that allows you to interactively execute external script/binaries/other as a local built-in function and be able to scrape the results off it.
This sounds amazing. How fluid is it between in and out of game? Would it be possible to have it interact with a chatbot in a meaningful way, then? That was something I was always interested in. I mean, you can sort of do it already by having a bot connect to a bit flagged ROBOT I guess.
@Griatch Not a derailment at all, that's exactly the kind of thing I wanted to hear. I've poked at TinyMUX, Penn, Rhost, Evennia... I installed that Ruby based sample game. Everything is a little different, and it seems like the majority of things translate between them. But there are differences, and my sampling isn't deep enough to really know what they are and why one might be better than another in some cases.
Further, some systems have very active developers of softcode and that's also an important draw. If you can talk to @Cobaltasaurus or @Thenomain or @Ashen-Shugar or you (or more, I can't list all of you coders, but I'm glad you're here) about the code they wrote instead of using decade old castoffs or three week old undocumented experiments, then that's also really important.