Recc/Squee/Kudos Code?
-
I'm looking for a code similar to +recc +squee +whatevertheheckelse that might already be floating around out there.
The general idea is to allow players to use a command to give kudos to their follow players. Unlike most of the other systems, I don't want this to translate to any sort of benefit (such as experience points or whatever). It should just be informational, and display on screen, and log.
For anyone who hasn't used similar, this would be something like +kudos Name=This person is a very good RPer or +kudos Name=This person gave me help or +kudos Name=This person cracked a hilarious joke.
It's just fluff. So, anything out there?
-
&cmd.+kudos_give ###=$+kudos =:@pemit %#=[set(pmatch(%0), _kudos.[time()]:%1)]You give %0 a +kudos!;@pemit [pmatch(%0)]=[name(%#)] gives you a kudos! Check +kudos.
&cmd.+kudos_view ###=$+kudos:@pemit %#=[iter(lattr(%#/_kudos.*), [inum()]: [get(%#/%i0)], , %r)]
(I have no idea how well this will work or if it even works, it's just a beginning sketch/idea. Take and edit as much as you want or as little.)
-
@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.
-
What's the intended goal for this though? I mean what's the essential difference between +recc skew and page skew=Hey, that RP was great, thanks! ?
I can see social recognition being a tool (with some caveats about popularity contests) if it's somehow publicised so that hopefully people driving roleplay are given some additional peer kudos to motivate them, but what's the reasoning behind this?
- He who takes offense when not intended is a fool. He who takes offense when intended is a greater fool.
-
@Arkandel I'm looking for code. Not a discussion of intended reasoning behind it, unless that reasoning is necessary to write the code.
Feel free to theory craft in another thread.
-
All code starts with a purpose. Asking the purpose helps design the code.
EG if this is meant to be a pat on the back, then no, do not store it is the design. If this is meant to be a history of praise available to all, you need to state that. If its just a list of who has ever praised the person, by PC name and not charobj#, it needs to state that.
how to invoke it
who can see it
what does it store -
Sigh.
@skew said in Recc/Squee/Kudos Code?:
The general idea is to allow players to use a command to give kudos to their follow players. Unlike most of the other systems, I don't want this to translate to any sort of benefit (such as experience points or whatever). It should just be informational, and display on screen, and log.
I think this is pretty clear. Sometimes a cigar is just a cigar, people.
-
@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. -
Been there done that.
And yeah, it's entirely doable. We've been doing it for decades. "A waste of space" has not been that much of a concern for a Mu* for about ten years. I think the closest I've come to slowing down a game is half a second, which even then bothers me to the point of doing code judo to fix it.
I've never coded on a game quite as large as Firan, but I've come pretty close. What I'm saying here is that yes SQL is better, but there's no critical muppet-arms flailing as you run away from an on-game log model.
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos -
@Mercutio @Thenomain SQL is my preference, anyways.
But if I'm going to archive things, I'd just do it within SQL, and not from anything inside the game. Which is to say, push to shove, I'd love to shift way more of the doin' things onto SQL.
Though, to be honest, I have a hard time thinking in terms of years, when it comes to MUs. I've been in this hobby for like 3 years and have played on half a dozen games, none of which have lasted longer than a few years.
Still, I think I'd want a 'within the last week' command, then maybe an 'all' command. Then, eventually, all would not truly be all, but maybe just the last many months. Then a 'are you really friggin' sure this is spammy' super all command.
-
@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.)
-
My long-haul is three years, but I also code for portability. Coding portability with SQL is not quite but close to as bad as coding portability for Mediawiki hooks. Nnnngh.
I've broken a game before, but it's entirely due to lbuf and nothing else. A smart selection of lattr() statements and organization of data and it can fit. That said, the game only broke because who wasn't me someone decided it was a great idea to list every single rote, book and home-made, from Mage in the stat lookup system instead of creating a different system for it.
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos -
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.
-
@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. -
@Mercutio It's TinyMUX. We have MySQL running just fine. It's in-line, but for what I want to do, there shouldn't be an issue.
We already use the SQL connection for +help and +news, as well as xp logs. (along with a custom 'rep point' system, which is just a redone version of xp logs).
-
Here's my cookies system. It probably doesn't do exactly what you want but you could probably adapt it.
Technically it depends on my core systems, but IIRC there are just a few functions it needs, like line() and padstr() from the Global Functions.
-
@skew said in Recc/Squee/Kudos Code?:
Would you imagine storing all the historical kudos onto a single attrib on the player bit?
No. You'd end up with one giant attribute that's hard to deal with and read.
-
@Tat has done this on XF (feeding into @faraday's +cookie system) because she fell in love with the +comp system on the now-defunct Second Pass. Where it was, indeed, just a way to leave nice notes for other players and let them see them after the fact.
Tat can talk more specifically about it if she ever wanders back, but basically every character gets a Comp object and all the comps for a player are stored there. Of course, I know there are limits for how many attributes a single object can hold, so I guess some day we may run into that.
