@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.

@Rince This looks promising and I'm setting it up now. I've been pondering what system to use for an Eclipse Phase game. This might be the one.

@Lotherio I have been thinking of the necessary functions for a system like this, and I have come to the conclusion that it is much more workable if you don't attempt to implement it as an economy and go with a currency approach instead.

To only approach it as currency, you should only need the following:

Staff: create currency, destroy currency, global balance, and paycheck
Players: transfer currency to player, transfer currency to object (if you want player vending), pay currency to object (if you have OOC equipment vending or rent)

You can get more complicated than that, but if you create/destroy currency you never have to worry about the difficulty of generating a closed loop economy. Create/destroy is used for quest rewards or non-standard purchases. Global balance shows the funds of all characters. Paycheck is a monthly cron job to call create for each player according to an attribute, like resources or a fiat allowance.

Transfer currency to player is a direct payment for a good or service. If a player owns a vending machine, it's just transfer to object, which then transfers to the owner player.

I would suggest rent money be destroyed, even if a player character owns the building. They need to reflect their spending balance with the same attribute, like everyone else as there is no depreciation.

This has been interesting to think about, and with sufficient soft coding I'm sure you could make a real estate game. Was that the intention, or just to have money in the pocket?

@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.

1. 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.

2. 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?