Volund has an improved version of SceneSys. I've not done any new MUSH project coding in a while since my stint at trying to get the Entity Framework going. (Graph based SQL backing for MUSH storage. Hit a big roadblock.).
You can find his package around on... GitHub I think it is?
SceneSys does not chuck into MediaWiki through SQL. It uses the Semantic Forms' ability to take POST requests and sends logs through that medium.
MediaWiki changes its SQL schema too often. So that was a far more viable method of doing it.
I do have some code laying around somewhere to pull pages from SQL. But it's not clean, nor can I recommend it.
You may want to look into just isolating this to Semantic Properties. That'd make your life a LOT easier.
@skew
Just in case I missed it. What Codebase is this on? There's a Softcoded SQL Wrapper for PennMUSH that'd make this quite easy and clean to do.
Yeah, on my side this was like, making over 40k objects and one object to track a few things with just that many attributes. Loading the Database took ages, and then doing an lsearch(all) or a grep(that object) made things go boom.
@Thenomain I like to plan for the long run. (Also, some databases handle this far better than others. I've brought PennMUSH to its knees a few times testing things like this out.)
@skew said in Recc/Squee/Kudos Code?:
@Cobaltasaurus About where my head was. Would you imagine storing all the historical kudos onto a single attrib on the player bit?
I think toss it all onto SQL, cause I love SQL and it loves me.
This.
There is no way an attribute could hold this info. And storing it on a many_attribs object is just a waste of space on most MU* bases. And can in fact negatively affect your database. If you really want to log all of them, SQL is the way to go. And for the sake of making queries easier, you may want to seperate / DELETE FROM & INSERT INTO job you run once a year that moves things from an Active to a Historical table. That way your SELECT queries won't grind to a halt if you expect a large sum of kuddos.
There's talk on M*U*S*H to make it an official patch you can ifdef.
This should not be hard, depending on how much you want to differentiate.
@descformat on a parent for descs
@conformat on a parent for people
@exitformat on a parent for exits
Mind you, it won't hide things from the hardcoded 'examine' or just doing lexits(). But the question is, do you really need that level of hiding?
For the standard interactions, just @hook/override SAY, EMIT, POSE. Or, use a parented @lock/interact, though players might override that if they know about it.
@lock some exits if you really need to.
If you are going to create your own, make sure to use @message and speech().
@message respects a lot of the locks, such as interact-lock, and makes proper spoofing easier.
I would not keep track of dbrefs on a master object. Use a simple lsearch() making use of lock-based searching. Example:
lsearch(all,etype,players,elock,chan`public:on)
This way, you don't have to clean up if a character is removed, or you recreate a person. lsearch() based on locks is very fast.
You don't even need to use @fo. You can just do:
$alias *:+channel %0
Or
$alias *:@chat channel=%0
There is also a common hardcode patch to add mux channel aliases sitting around somewhere, if you have shell access.
@Rook said:
@Thenomain said:
Oh, and no calling player data with
u().Quoted for truth.
Assuming you're working in TinyMUX. It's safe in PennMUSH, as it gets evaluated with the permissions of the object it is on.
That aside, I found it useful to - if you have SQL access and are using MediaWiki - to have it automatically generate the wiki link if a player has one. Or rather, if a page exists with the character's name.