Posts made by Ashen-Shugar

Here's our Pyewacket (Norwegian Forest Cat) at 2 years old beside a full grown Thor (our Bombay). Thor is just shy of 14 pounds.

That is a full sized door that my wife uses for crafting they are laying on.

Pyewacket still has 3 more years to get full sized.

This is the one I picked up. It's a fun modern look and the ergonomics on it are fantastic (at least for me)
https://www.amazon.com/Zuo-Modern-Unico-Office-Chair/dp/B001VA6MB4

You probably want to put a @lock/use on yourself as well.

@arkandel said in Do we need staff?:

True, but there's no way to systematize right.

No, I have to argue with this.

The way to 'systematize' right is frankly up to the people running the game.

If it's not right for you (the queen's you) then it's none of your damn business. Leave them have their right and go somewhere else.

Too many people try to force their version of right on everyone else, and then we wonder why the hell we have problems.

I'm honestly not aware of the db writing in encrypted mode of any form, it should be a method of binary and/or compressed format.

If it's being compressed it's likely in ZLIB format of some sort.

Otherwise the binary structure can be found in db_rw.cpp.

Be careful with the open db as well, lots of mu* engines don't like having an external application actively reading the data while it's open.

I know that Brazil writes data in UTF8 and he has his own hash routine that does the hash tables in svdhash.cpp which is likely his indexer tree.

Anyway, all the reading of a db flatfile should be in db_rw.cpp, the hash in svdhash.cpp, and any object/attribute content handling in db.cpp and attrcache.cpp.

MUX's current github is at: https://github.com/brazilofmux/tinymux

Those will be the files of interest. Good luck.

@seraphim73 said in Do we need staff?:

I do think that system is very, very important if you want to have minimal staff, and I think that the importance there is simple Chargen where questions should be minimal, sheets should not be complex, and combat should be either automated or so frickin' simple that anyone can run it after trying it once (I don't know... flipping a coin to decide who wins, maybe).

... and maybe more than 1-2 staff so when the 1-2 staff have family emergencies, RL emergencies, RL important circumstances, or heaven forbid family vacations or even waking up one morning saying 'I think I'll go walk in the park instead of logging in', that people who think their online personas and players are special little snowflakes don't feel enraged that someone dared think real life had a higher priority than a game.

Sadly yes, I'm speaking from experience of having delt with people like this. They're eventually on every game. Kinda like a disease.

@coin said in New +txt/+email/etc code for TinyMUX:

@tragedyjones said in New +txt/+email/etc code for TinyMUX:

Agree with on bottom for newest texts.

No one asked you, SIR.

If it was a choice, I'd choose the top, but I'd suggest having it as a config option. It should theoretically be insanely simple to alter the list based on a simple config option, so just do that and people can have the way they want.

@skew said in Quiet Room:

If you're using TinyMUX (which I know you are), there's no way to squelch the connect/disconnect (and the leave/arrive?) messages unless you have @Chime's fork. Which a certain cephalopod has just recently informed me has had a very minor update to handle some SSL something something something.

MUX 2.12 seems to already have arrive/leave handled by blind (on target player or location).

So to add this functionality to connect/disconnect, you need to edit netcommon.cpp in three locations.

One to handle connect/reconnect
One to handle disconnect
One to handle partial disconnect

You look for this section:

        if (  loc != NOTHING
           && !(  Hidden(player)
               && Can_Hide(player)))

And modify it to this:

        if (  loc != NOTHING
           && !(  Hidden(player)
               && Can_Hide(player)) && !(Blind(loc) || Blind(player)))

You should then be good to go.

@bobotron said in How To Strip Comtitles in PennMush:

@ashen-shugar

Maybe? Set a chatformat on yourself, to strip before() the name but after() the channel tag? I've honestly never played around with @chatformat.

@chatformat can distingush a message without a comtitle, so theoretically you could set something like:

@chatformat me=%5

@bobotron said in How To Strip Comtitles in PennMush:

@roz

You can set individual channels to not have comtitles through @chan/privs channel=notitles which does it on a per-channel basis. Setting the thin to 0 does it for every channel.

Hum... just realized something... what about @chaformat?

@auspice said in How To Strip Comtitles in PennMush:

But agreed, more com systems need ways to gag them on your end. I don't know a way on Penn personally.

There is no 'built in' way, per say, but you can do some clever trickery with @hook.

You essentially do a @hook/ignore and code in logic against @chan/title so that if length() is > X or if player = Y don't allow comtitles.

That should effectively lock down the size of the comtitle and also tag an ability to entirely ban set player(s) from being able to set comtitles entirely.

You could even skim the command to verify only certain comtitles were allowed.

As far as I'm aware, I think that's about all you can do (short of hardcode mods) to block comtitles.

EDIT:

Ooo, what do you know... there's a way to block titles entirely off channels, but you still need @hook if you want dynamic control.

> help @channel priv
  The <privs> for @channel/add and @channel/privs should be a space-separated
  list of priv names, or a string of priv chars, from the list below:

  * "player" (P) - players may use the channel
  * "object" (O) - non-players may use the channel
  * "admin" (A) - only royalty/wizards/chat_privs may use the channel
  * "wizard" (W) - only wizards may use the channel
  * "quiet" (Q) - channel will not show connection messages
  * "open" (o) - you may speak even if you aren't listening to the channel
  * "hide_ok" (H) - you may hide from the channel who list
  *  "notitles" (T) - chantitles are not displayed in channel messages 
  * "nonames" (N) - player names are not displayed in channel messages
  * "nocemit" (C) - @cemit is prohibited on the channel
  * "interact" (I) - Interaction rules (defined in local.c) are applied to the channel
  * "disabled" (D) - noone can join or speak on the channel

  The default privs are determined by the 'channel_flags' @config option.

  Example:
    > @channel/add Public=player quiet open nocemit

Penn:
@lock/speech (on location)
@lock/interact (on player)
GAG flag (on player)
@hooking say and pose

MUX & TM3
@lock/speech + Auditorium [flag] (on location)
SLAVE flag (on player)
@icmd (on location or player)
REALITY LEVELS
@hooking say and pose

Rhost:
@lock/speech + Auditorium (flag) (on location)
SLAVE flag (on player)
FUBAR flag (on player)
@icmd (on location, player, or zone)
REALITY LEVELS
@hooking say and pose

There's probably a few clever ways I didn't touch, but that's the majority of the ways to lock down a room (or a player in a room) from talking.

@thenomain said in Arx on github:

@ashen-shugar said in Arx on github:

I generally kill people who use tabs in source code.

FITE ME.

(edit: lolkittens)

@shincashay said in Code Suggestions:

Maybe just keywords then. +help fight and then Clippy appears.

Did you mean +help combat?

Naw for reals just aliases that pull up the same thing.

Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

@wyrdathru said in Arx on github:

Now, what about tabs or spaces, camelCasing or PascalCasing, Li-nux or Lin-ux and more!

LET THE BLOODSPORTS BEGIN

I generally kill people who use tabs in source code.
3 or 4 space indent, and keep standard.

And Camel/Pascalcase is ugly in other languages (like C/C++) and I prefer a modified title-case with a C prefix declaration.

i_my_var for ints, f_my_var for floats, s_my_var for strings/array/chars, p_my_var for pointers, and so forth.

It's an older school method for naming convention but it's hard for me to switch to anything 'new' after using it for nearly 40 years. Old dog, new tricks, that kinda thing.

MUX side, Requires wizard/#1 access to @hook, and is an ugly work around, but:

1.  @hook/igswitch @decompile
2.  @create HookDecompile
3.  @set HookDecompile=inh safe
4.  &CMD_DEC HookDecompile=$@decompile/* */*:@break [not(match(%0,tf))]=@pemit %#=Unrecognized switch '%0' for command '@decompile'.;@pemit %#=TinyFugue > &%2 [setr(0,locate(%1,%#,*))]=[get(%1/%2)]

As for Potatoe, not used enough to hack, sorry.

@sonder said in Wiki to MU solution/MU to Forum:

I was just wondering if anyone can help me out and install the wiki-to-game solution that we have on Fallcoast currently on the new game. It's the function that allows us to update the news files on the wiki and have it translate to the game.

We also have something where old jobs are archived on the Forum for later research and perusal.

Thanks.

Using Penn, dump and pull to mysql (or when done their @http port maybe)
Using MUX, dump and pull to mysql.
Using Rhost, dump andpull to mysql or use execscript() or use the API

Them's about it short of hacking the hardcode.

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

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