Reminds me of the code I had on Angelic Layer MUSH. I had a CRON running that'd store data into SQL after grabbing from weather underground. As Angelic Layer MUSH was 2 years behind real-world, and weather underground had historical METAR data, I could grab stuff form the Tokyo Airport.
Don't think they had an API at the time. And just reading their pages was a bit annoying.
@somasatori
I wasn't offended or anything of the like. Just amused at the expression. I believe it even came from TinyMUSH code re: SQL and its implementation.
More on-topic though.
@surreality
Quirky timeouts? I presume that means you're using async SQL for TinyMUX?
@ixokai said in PennMUSH & DBREFs:
Anecdotally, and entirely in hearsay, I've heard Penn's database loads and saves get pathologically slow with even a moderately large database.
I can not provide any supporting evidence for this claim but have heard it several times from reliable sources.
This is true, when you hit around 40k objects.
High number of Attributes on singular objects however, cause far more slowdown than the object count.
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.