MU Soapbox

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Muxify
    • Mustard

    Recc/Squee/Kudos Code?

    MU Code
    8
    18
    4099
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • skew
      skew last edited by

      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?

      Thenomain 1 Reply Last reply Reply Quote 0
      • Cobalt
        Cobalt Tutorialist last edited by

        &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.)

        skew Arkandel 2 Replies Last reply Reply Quote 0
        • skew
          skew @Cobalt last edited by

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

          M Cobalt 2 Replies Last reply Reply Quote 1
          • Arkandel
            Arkandel Admin @Cobalt last edited by

            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.
            skew 1 Reply Last reply Reply Quote 0
            • skew
              skew @Arkandel last edited by

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

              1 Reply Last reply Reply Quote 2
              • Misadventure
                Misadventure last edited by

                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

                I have a waggish sense of humor.

                1 Reply Last reply Reply Quote 0
                • Thenomain
                  Thenomain @skew last edited by

                  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.

                  “If you wish to make an apple pie from scratch, you must first invent the universe.”
                  ― Carl Sagan, Cosmos

                  1 Reply Last reply Reply Quote 1
                  • M
                    Mercutio @skew last edited by

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

                    Liminality @ Elder Tale Online

                    Thenomain skew 2 Replies Last reply Reply Quote 0
                    • Thenomain
                      Thenomain @Mercutio last edited by

                      @Mercutio

                      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

                      M 1 Reply Last reply Reply Quote 0
                      • skew
                        skew @Mercutio last edited by

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

                        1 Reply Last reply Reply Quote 0
                        • M
                          Mercutio @Thenomain last edited by Mercutio

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

                          Liminality @ Elder Tale Online

                          Thenomain 1 Reply Last reply Reply Quote 0
                          • Thenomain
                            Thenomain @Mercutio last edited by

                            @Mercutio

                            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

                            M 1 Reply Last reply Reply Quote 1
                            • M
                              Mercutio @Thenomain last edited by

                              @Thenomain

                              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.

                              Liminality @ Elder Tale Online

                              1 Reply Last reply Reply Quote 0
                              • M
                                Mercutio last edited by Mercutio

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

                                Liminality @ Elder Tale Online

                                skew 1 Reply Last reply Reply Quote 0
                                • skew
                                  skew @Mercutio last edited by

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

                                  1 Reply Last reply Reply Quote 0
                                  • faraday
                                    faraday last edited by

                                    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.

                                    1 Reply Last reply Reply Quote 2
                                    • Cobalt
                                      Cobalt Tutorialist @skew last edited by

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

                                      1 Reply Last reply Reply Quote 1
                                      • Roz
                                        Roz Banned last edited by

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

                                        1 Reply Last reply Reply Quote 0
                                        • 1 / 1
                                        • First post
                                          Last post