Mux Logger Objects



  • @thenomain

    Thanks!

    (Also what's horrible?)


  • Coder

    @derp said in Mux Logger Objects:

    (Also what's horrible?)

    Horrible:

    DROP TABLE IF EXISTS mush_poselogger_status; 
    CREATE TABLE IF NOT EXISTS mush_poselogger_status
    (
        status           INT            NOT NULL, 
        description      TEXT, 
    
        PRIMARY KEY (status)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
    
    INSERT INTO mush_poselogger_status VALUES (0, ''); 
    INSERT INTO mush_poselogger_status VALUES (1, 'NOW LISTENING'); 
    INSERT INTO mush_poselogger_status VALUES (2, 'NO LONGER LISTENING'); 
    INSERT INTO mush_poselogger_status VALUES (3, 'START OF SCENE'); 
    INSERT INTO mush_poselogger_status VALUES (4, 'END OF SCENE'); 
    

    Sure, I couldn't have just made it an enum, could I.

    Horrible:

    &_header Poselog Front-End=wheader(%0)
    &_footer Poselog Front-End=wfooter(%0)
    &_divider Poselog Front-End=wdivider(%0)
    
    &_notice Poselog Front-End=[ansi(xh, GAME:)] %0
    &_alert Poselog Front-End=[ansi(r, >%b, nh, %0, nr, %b<)] %1
    
    &_lbuf Poselog Front-End=config(lbuf_size)
    &_isstaff Poselog Front-End=isstaff(%0)
    

    The _ makes them dark and wizlocked. I'd moved on to &.xxx since then, to make it a bit easier to maintain. And easier to type.

    There are other things, but those are the main ones.


  • Coder

    @Thenomain Okay, so, again, I do not have any pose logger code. I have +repose, and while that could be tweaked to be a logger (and frankly I'm intending to do so), in it's present state it is not.

    @Derp On Fate's Harvest, we have code that essentially allows you, the player, to @create an object and then use the Pose Logger command to turn it into a Pose Logger. You turn it on, it listens to the room, when you're done, you turn it off, then it can output the code in WikiMedia template format.


  • Coder

    @skew

    The pose logger isn’t yours?

    Man, you should totally take credit for it.

    Again, I can disassemble it for anyone with permission.


  • Coder

    @skew said in Mux Logger Objects:

    @Thenomain Okay, so, again, I do not have any pose logger code. I have +repose, and while that could be tweaked to be a logger (and frankly I'm intending to do so), in it's present state it is not.

    @Derp On Fate's Harvest, we have code that essentially allows you, the player, to @create an object and then use the Pose Logger command to turn it into a Pose Logger. You turn it on, it listens to the room, when you're done, you turn it off, then it can output the code in WikiMedia template format.

    For a non-penn game, make sure that the logger re-uses the same attribute names, otherwise over a period of time you can get some serious db bloat from hashed attribute names.

    All mushes (except PennMUSH) uses hash entries for attributes, so its something to keep in mind.

    Though MUX and Rhost have a @dbclean that will clean out unused attributes which can greatly save db space and memory use.


  • Coder

    @ashen-shugar I've literally never heard this before... Just to be clear, my repose code works by creating a new attribute (something like d.time.poser-dbref with the pose as the data) with each new pose, then wipe()s those attributes after X minutes. You're saying that, even though I wipe(), the hash key for each attribute will continue to grow? And @dbclean will simply fix that up no problem?

    And for the record, Thenomain's poselogger logs in SQL, so no issue there. The other poselogger has each player create an object, which could potentially be a problem.


  • Coder

    @skew said in Mux Logger Objects:

    @ashen-shugar I've literally never heard this before... Just to be clear, my repose code works by creating a new attribute (something like d.time.poser-dbref with the pose as the data) with each new pose, then wipe()s those attributes after X minutes. You're saying that, even though I wipe(), the hash key for each attribute will continue to grow? And @dbclean will simply fix that up no problem?

    And for the record, Thenomain's poselogger logs in SQL, so no issue there. The other poselogger has each player create an object, which could potentially be a problem.

    The hash will continue to grow for any new attribute name. If the attribute is always d.time.poser-#3 it'll not have to hash a new attribute, but yes, any new attribute hashed, if 'time' is the actual secs() would absolutely enter a new hash.

    Do a @list hash on your MUX/TM3/Rhost game and pay close attention to the line:

    Vattr stats:  25793 alloc, 37 free, 18392422 name lookups
    

    The allocs are how many actual attribute hashes you have defined. That's unique user-defined attributes in your database. The larger that is, the more memory it will take up.

    Each hashed attribute takes up a small number like 256 bytes. Almost laughable, until you get a million of them :)

    @dbclean goes through and wacks any attribute that is not currently being seen as 'in use'.

    In use is defined by any attribute currently set on something.

    Make sure to @reboot after your @dbclean to free up the unused memory (since it's the only way to release the memory back to the OS)


  • Coder

    @ashen-shugar Thank you!


  • Coder

    FWIW, my loggers intentionally use &LOG-<#> obj attributes, exactly for the reason of not exploding the vattr table. It uses a lot of attributes but it reuses them from the last longest scene.


  • Coder

    @ixokai said in Mux Logger Objects:

    FWIW, my loggers intentionally use &LOG-<#> obj attributes, exactly for the reason of not exploding the vattr table. It uses a lot of attributes but it reuses them from the last longest scene.

    Eyup!

    Mine tend to do wrap-around queueing.

    So how I do it is if I say 'log the last 500 lines' I log like LOG_0 through LOG_499, then once it hits MAX_LOG value (which is 500) it wraps around back to LOG_0.

    I have a CUR_LOG value that tells what log number it's at, then essentially apply a mod to it based on MAX_LOG and set that to CUR_LOG. When I display the logs in order, I go from CUR_LOG - 1 to 0, then MAX_LOG down to CUR_LOG.

    That way it's always in numerical order on the last 500 logs.

    never have to @wipe it, never have to worry about anything else. It's a fire and forget logging system.


  • Coder

    I just store in an SQL table. So much more satisfying.

    Once @Chime told me that it had hit several gigabytes, but it had been recording every pose in the OOC room.

    For five years.


  • Admin

    @thenomain Future MUSH historians will thank you!


  • Coder

    @arkandel said in Mux Logger Objects:

    @thenomain Future MUSH historians will thank you!

    The OOC room for The Reach?

    I deleted them at her request.

    Future MUSH historians will thank me.