Stuff from Ixokai

From Museon Softcode Package

Foundational functions:

safestr-attr(text) -- turns an arbitrary string into a predictable attribute name; basically runs secure() then converts spaces and colons to underscores. cleanstr-attr(text) -- inverses the above (minus stuff killed by secure), turning underscores into spaces.

In my code, I have a standardized data storage format. No matter what I'm storing, I store it all the same way. Everything is either a "standard structure", or it's a list. All lists are pipe delimited. I have found it very useful to have /one/ solid way to store data, be it a player's stats, their xp votes, or-- anything

A "standard structure" is for me in the format of: key1~value1|key2~value2|key3~value3

Support functions for standard data:

safestr-struct(text) -- basically kills pipes and tilde's, converting to @PIPE@ and @TILDE@ cleanstr-struct(text) -- reverses the above

struct-get(dbref, attribute, key) struct-set(dbref, attribute, key, value) -- This is NOT a sidefx. You call it via &attribute dbref=[struct-set(dbref,attribute,key)]. It goes out and grabs the current contents of the attribute, kills any version of the key already present, and adds a new key~value pair. struct-list(dbref, attribute) -- returns a list of all keys in attribute struct-del(dbref, attribute, key) -- also not sidefx, deletes the key.

I have a struct-setx and struct-getx which are "sidefx" versions for rare purposes. On one game, they actually had a different storage format pre-existing, so I just adjusted the struct-* functions.

I *personally* don't like to assume that if I'm seeking data on a player, #4, that it will be stored on them. So I always "setr(t,resolve-target(#4))" and use that. On most games, it'll pass through to #4. On one game where I was coding with this basic foundation for, this player-data was all stored on a separate object.

obj-get(name) -- This is object discovery, returns a name of a globally registered object.

I then built on top of the foundational functions; e.g., stat-get(target,stat) was actually a call to struct-get(...) etc, etc. But I won't go into rp stuff yet :)

attr-sort(attribute-list, header) -- Basically this is just a sortby() call so that if you have ATTR.1 ATTR.10 ATTR.11 ATTR.2 ATTR.3 ... ATTR.9, it'll sort them according to the numeric value if you call attr-sort(lattr(dbref/ATTR.*),ATTR.). I end up doing that a lot.

We'll need to NOT use columns() directly; Rhost's version is very different, and it will devour ANSI. I can provide a non-ANSI eating version. On other platforms we can call the native one, but it should be in a wrapper like museon-column() or some such.

I *personally* also like, but doubt I'll convince anyone else, the colorcfg() system I designed for elseMU. Basically it was an enhancement of the standard UI ("skin") functions, and had the syntax of:

"[colorcfg(%#,title,This is my text)]" or "[colorcfg(%#,syntax command,+help)] [colorcfg(%#,syntax argument,bbs)]"

Title is basically a text class; there are a number of text classes, such as title, exit name, exit link, exit frame, syntax command (stuff people type that's always the same), syntax argument (Stuff people type that changes), character name, ... and so on and so forth. There were about 4 classes used in ui-header() alone. (outer frame, inner frame, line, .. etc)

The game has a default color scheme; they may also (if they choose) provide any number of other color schemes. A user can choose any one of those schemes they want; one example was a "mostly mono" one that only highlighted in white and only for a rare, rare thing (like syntax). That for the people who don't like a lot of ANSI. The user can also just /set/ any of those classes to be any particular color they want.

This allowed the game to set a color scheme and skin; but the user to override at will without having to !ANSI. The downside? It's a bit annoying to code.

Anyhoo, them's my ideas for now.

--Ixokai