MU Soapbox

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Muxify
    • Mustard
    1. Home
    2. Ashen-Shugar
    • Profile
    • Following 2
    • Followers 3
    • Topics 15
    • Posts 272
    • Best 116
    • Controversial 0
    • Groups 3

    Ashen-Shugar

    @Ashen-Shugar

    Coder

    497
    Reputation
    321
    Profile views
    272
    Posts
    3
    Followers
    2
    Following
    Joined Last Online

    Ashen-Shugar Unfollow Follow
    Politics Coder Creator

    Best posts made by Ashen-Shugar

    • What to do when your mush is attacked

      Ok, I've seen people ping a few times on here asking how to go about blocking people who are attacking their game, so I'll cover TinyMUSH3, PennMUSH, MUX2, and RhostMUSH on ways to cockblock attackers on your games. Please keep in mind my knowledge on Penn, TM3, and MUX is a wee bit rusty, but I'm fairly certain I've covered the majority.

      I also placed links at the end of this document to point to various tutorials on learning MUSH code, Ruby, and Python (for AresMUSH and Evennia respectively) which should prove helpful for those new to mushing.

      -----------------------------------------------------------------------------------------------------------------
      First, TinyMUSH3:
      TinyMUSH3 allows the base set that MUX2 allows, and some additional features customized for the codebase.

      Site Restrictions:
      Syntax ingame: @admin <param>=<IP> <MASK>
      Syntax tinymush.conf file: <param> <IP> <MASK>

      Parameters:
      forbid_site -- forbid the IP from connection entirely
      guest_site -- allow guests from the IP
      register_site -- forbid new player creation from the IP
      suspect_site -- mark connections with the SUSPECT flag

      Example: (assume player is from IP 12.12.20.200)

      @admin guest_site=12.12.20.0 255.255.255.0
      

      This blocks all IP's from 12.12.20.1 through 12.12.20.255 which is the preferred start for blocking since most people have DYNAMIC IP addresses and not STATIC IP addresses.
      NOTE: TinyMUSH3 allows CIDR (/24 instead of 255.255.255.0) notation from TinyMUSH 3.2 on.

      Keep in mind @admin is NOT persistent. When you reboot or restart your mush, those values are no longer there. To make them permanent you need to use the .conf file method.
      Example:

      forbid_site 12.12.20.0 255.255.255.0
      forbid_site 12.12.20.0 /24
      

      To make any .conf file change take effect, the system will have to be @restarted.

      Now for Limits:
      To set:

      @admin command_recursion_limit=50
      

      or in your .conf file

      command_recursion_limit 50
      

      command_recursion_limit (default 50) -- number of commands that can be nested from another command
      command_invocation_limit (default 2500) -- number of commands that can be called in a single command queue
      function_cpu_limit (default 60) -- amount of time, in seconds, that a command is allowed to process. Anything over this will be aborted.
      function_invocation_limit (default 2500) how many functions can be called from a single command
      function_recursion_limit (default 50) how many times a function can call itself
      instance_limit (default 100) -- this has to do with TM3's construct feature and limits the amount of memory-based structures allowed in-game
      lock_recursion_limit (default 20) -- amount of times a lock is allowed to be called
      notify_recursion_limit (default 20) -- number of times notify() can be called recursively. Notify() is an internal call to TinyMUSH3 that handles the messaging bus. So it's essentially a low-level run away process handler for potential bad coding 😉
      player_queue_limit (default 100) -- total number of queue entires a player may have at any one time
      player_alias_limit (default 10) -- total number of @aliases a player may have
      propdirs_limit (default 10) -- PROPDIR in TinyMUSH3 is in effect a localized 'parent' you can assign an object to inherit attributes from a list of dbref#'s. Kinda silly, but there we go.
      register_limit (default 50) -- amount of setq registers a player can define
      retry_limit (default 3) -- number of times a player can attempt to connect to a player before being disconnected
      stack_limit (default 50) -- number of stack entries allowed with push()
      structures_limit (default 100) -- number of structure()'s allowed
      variables_limit (default 50) -- number of unique variables (tm3-ism) allowed per target
      wildcard_match_limit (default 25000) -- number of recursion attempts allowed for wildcard/regexp matching
      zone_recursion_limit (default 20) -- maximum number of zones that can be chained

      Commands:
      @boot -- boot player from game
      @nuke/@toad -- destroy/remove player from game (note: TM3 has @nuke aliased to @destroy/override)
      @disable -- disable logins
      @newpassword -- change target's password

      Flags:
      To set:

      @set *player=slave
      

      SLAVE -- When set the player can not issue any command that could potentially change the database
      GAGGED - player can not talk
      STOP -- Once a $command is matched, no further command searching will occur
      CONSTANT -- only the #1 player (God) can set attributes on the target
      WATCHER -- allows a player to monitor player connects/disconnects
      NOSPOOF -- allows you to see enactor of a @pemit, @emit, say, pose, etc. Can be spammy
      FIXED -- target can not teleport

      -----------------------------------------------------------------------------------------------------------------
      And now, MUX2/TinyMUX:
      You will notice early on that MUX2 and TinyMUSH3 hale from the same parent codebase as the restrictive qualities are nearly identical minus customizations between codebases

      Site Restrictions:
      Syntax ingame: @admin <param>=<IP> <MASK>
      Syntax tinymush.conf file: <param> <IP> <MASK>

      Parameters:

      forbid_site -- forbid the IP from connection entirely
      guest_site -- allow guests from the IP
      noguest_site -- disallow guests from the IP
      nositemon_site -- stop spamming logs of connect/disconnect
      register_site -- forbid new player creation from the IP
      suspect_site -- mark connections with the SUSPECT flag

      Example: (assume player is from IP 12.12.20.200)

      @admin forbid_site=12.12.20.0 255.255.255.0
      @admin forbid_site=12.12.20.0 /24
      

      This blocks all IP's from 12.12.20.1 through 12.12.20.255 which is the preferred start for blocking since most people have DYNAMIC IP addresses and not STATIC IP addresses.
      NOTE: MUX2 since 2.7 allows CIDR notation (ergo, /24 instead of 255.255.255.0)

      Keep in mind @admin is NOT persistent. When you reboot or restart your mush, those values are no longer there. To make them permanent you need to use the .conf file method.
      Example:

      guest_site 12.12.20.0 255.255.255.0
      

      To make any .conf file change take effect, the system will have to be @restarted.

      Now for Limits:
      To set in-game:

      @admin function_invocation_limit=25000
      

      To set in .conf file:

      function_invocation_limit 25000
      

      allow_guest_from_register_site -- allow guest to connect to register sites (boolean)
      function_invocation_limit (default 2500) how many functions can be called from a single command
      function_recursion_limit (default 50) how many times a function can call itself
      lock_recursion_limit (default 20) -- amount of times a lock is allowed to be called
      notify_recursion_limit (default 20) -- number of times notify() can be called recursively. Notify() is an internal call to TinyMUSH3 that handles the messaging bus. So it's essentially a low-level run away process handler for potential bad coding 😉
      player_queue_limit (default 100) -- total number of queue entires a player may have at any one time
      retry_limit (default 3) -- number of times a player can attempt to connect to a player before being disconnected
      stack_limit (default 50) -- number of stack entries allowed with push()
      zone_recursion_limit (default 20) -- maximum number of zones that can be chained
      parent_recursion_limit (default 50) -- maximum number of parents that can be chained
      pcreate_per_hour (default 100) -- maximum number of player creations allowed an hour
      references_per_hour (default 500) -- maximum number of @references allowed an hour
      user_attr_per_hour (default 5000) -- maximum number of attributes a player can create new per hour
      mail_per_hour (default 50) -- maximum number of mail allowed per hour

      Commands:
      @disable -- the ability to disable all logins except staff
      @icmd -- disable commands based on player or room/location
      @nuke/@toad -- destroy a player
      @boot -- boot a player from the game
      @newpassword -- change target's password

      Flags:
      To set:

      @set *player=slave
      

      SLAVE -- When set the player can not issue any command that could potentially change the database
      GAGGED - player can not talk
      SITEMON -- allows a player to monitor player connects/disconnects
      NOSPOOF -- allows you to see enactor of a @pemit, @emit, say, pose, etc. Can be spammy
      FIXED -- target can not teleport

      -----------------------------------------------------------------------------------------------------------------
      And now, PennMUSH:

      You will see PennMUSH is a unique animal and has... very little to do with the TinyMUSH/MUX method of restrictions, and I may miss a few and if I do, please message me and I'll update this ASAP.

      Site Restrictions:
      @sitelock <args>=<parameters>

      Examples, to block specific player:
      @sitelock/player PLAYERNAME=RESTRICTION
      Examples:

      @sitelock/ban/player Buttclown
      @sitelock/register/player Buttclown
      

      First example bans (forbids) the player from his current IP
      Second example disallows new players (registers) from his current IP

      Examples, to block specific sites:
      @sitelock IP=RESTRICTION
      Examples:

      @sitelock *.buttclown.com=!connect
      @sitelock *.mildlyannoying.com=!register
      @sitelock *.aol.com=!connect,Guest
      

      First example bans (forbids) anyone connecting from that site
      Second example registers anyone connecting from that site
      Third example blocks only guests from that given site.

      As you can see, it does allow hostnames unlike TinyMUSH3 and MUX, and also allows wildcarding. Which is much nicer.

      Limits:
      @config/set PARAMETER=VALUE (only lasts until reboot/restart)
      @config/save PARAMETER=VALUE (#1/God only -- and permanent)

      Examples:

      @config/set max_attrs_per_object=50
      @config/save max_attrs_per_object=50
      

      max_attrs_per_object -- maximum attributes allowable per object
      max_guests -- maximum number of guests allowed
      connect_fail_limit -- maximum number of times in a 10 minute window someone can fail to connect to a player
      startups -- disable @startups from triggering on start (useful if hackers)
      player_creation -- globally enable/disable player creates at connect screen
      guests -- enable/disable guest connects
      safer_ufun -- enable/disable the use of safer ufunctions
      function_side_effects -- enable/disable the use of SIDEEFFECT functions
      player_queue_limit -- max entries a player can have in a queue
      max_depth -- max recursions a @lock can have
      function_recursion_limit -- max recursions a function can call itself
      function_invocation_limit -- maximum functions allowed per command
      queue_entry_cpu_time -- maximum cpu a queue entry is allowed
      max_aliases -- maximum @aliases a player can have
      max_parents -- maximum parents allowed in a chain
      call_limit -- maximum depth of the stack the parser is allowed to have

      Commands:
      @boot -- boot the player from the game
      @nuke -- destroy/remove the player from the game entirely
      @newpassword -- change target's password
      @disable -- disable logins

      Flags:
      To set:

      @set *player=fixed
      

      NO_TEL -- Stop teleporting period
      FIXED -- stops from using @tel/home
      SUSPECT -- Set suspect
      GAGGED -- stop from talking
      Z_TEL -- stops from teleporting out of the zone

      -----------------------------------------------------------------------------------------------------------------
      And now, RhostMUSH:

      RhostMUSH is an combination of, well, everything. And because of the flexibility and customizations, can be daunting, but here we go:

      Rhost allows two ways for site restrictions.
      Site Restrictions
      @admin PARAM=SITE IP
      @admin PARAM2=WILDCARDHOST

      NOTE: Since Rhost 3.2.4p13 Rhost allows CIDR notation (/24 instead of 255.255.255.0)

      The first method:
      Example:

      @admin forbid_site=12.12.20.0 255.255.255.0
      @admin forbid_site=12.12.20.0 255.255.255.0 3
      @admin forbid_site=12.12.20.0 /24 3
      

      The first example hardforbids the site from connecting.
      The second example forbids the site from connecting after 3 connects have already been allowed. This allows connections but stops spamming.
      Both options are available for all site parameters.

      forbid_site -- forbid site from connecting
      register_site -- disallow player creation from site (set to 0.0.0.0 0.0.0.0 to disable player creation entirely)
      suspect_site -- set site suspect
      noguest_site -- disallow guest from connecting.
      noauth_site -- disallow AUTH IDENT lookups
      noautoreg_site -- disallow site from auto-registration on connect screen
      passproxy_site -- allow IP to bypass auto-proxy blocking
      nodns_site -- don't do DNS/RDNS lookups
      forbidapi_site -- don't allow API connections from site

      For the second method we have: (wildcards optional)
      Examples:

      @admin forbid_host=*.buttclown.com *.bob.com !*.foo.com
      @admin forbid_host=*.buttclown.com|3
      

      First example blocks wildcard buttclown.com, bob.com, and removes foo.com
      Second example adds buttclown.com and forbids after 3 connections.

      tor_localhost -- the hosting server that will monitor and block TOR connections
      noautoreg_host -- the hostname for blocking autoregistration
      passproxy_host -- the hostname to bypass proxy blocking
      validate_host -- disallow email from autoregistration
      forbidapi_host -- hostname to forbid api
      mysql_host -- hostname for the MySQL server
      register_host -- hostname to stop player creation
      forbid_host -- hostname to stop connections
      suspect_host -- hostname to set suspect
      noguest_host -- stop guests from connection
      nobroadcast_host -- stop site monitor chatter for site (still logs)

      The following specific other options are useful for site restrictions:
      @goodsite -- attribute to set on target player to specify what wildcard IP's -are- allowed to connect from (IP only, no hostname)
      @badsite -- attribute to set on target to specify what wildcard IP's are not allowed to connect from (IP only, no hostname)
      NOCONNECT -- flag to set on player to stop connections
      Examples:

      @goodsite #1=127.0.0.1
      @badsite *twink=12.12.20.*
      

      And now, the configuration list of hell:
      Examples:
      Ingame:

      @admin function_invocation_limit=25000
      

      In netrhost.conf file:

      function_invocation_limit 2500
      

      authenticate -- toggle to specify authentication (AUTH) lookups
      max_players -- max players allowed to connect to the mush at any time. The default for this is 40 less than the current maximum allowed based on server specifications to avoid DoS/DDoS. This ceiling is impossible to go past.
      cpu_secure_lvl -- define how the mush will treat those who hit the CPU limit. 0 is just stop 1 is halt the owner, 2 sets FUBAR, 3 sets NOCONNECT and boots, 4 does all of 3 and sets register, 5 does all of 3 and sets forbid
      cpuintervalchk CPU load before engaging CPU protection (default 5% system load)
      cputimechk CPU time in seconds before CPU protection (default 5 seconds)
      heavy_cpu_max (default 50) heavy cpu intensive features are auto-tagged this for additional cpu protection. This is how many times it can be called per 'command'
      max_cpu_cycles (default 3) number of times a target can hit the CPU alert before restrictive measures via cpu_secure_lvl is enacted
      max_lastsite_cnt (default 20) number of connections from a site allowed a minute
      min_con_attempt (default 60) seconds to check for max_lastsite_cnt
      lastsite_paranoia (0-3) sets restrictive level to use if max_lastsite_cnt is reached. 0 is take no action. 3 is forbid
      max_sitecons -- (default 50) absolute maximum number of connections a specific site can have online at any time.
      max_pcreate_lim -- number of connect creates allowed per minute
      max_pcreate_time -- time allotted between pcreate lim checks
      pcreate_paranoia -- (0-3) sets restrictive level to use if max_pcreate_lim is reached.
      spam_limit -- maximum number of commands allowed by a player per minute if set SPAMMONITOR (default 60)
      player_queue_limit -- maximum queues allowed per player at any time (default 100)
      wizard_queue_limit -- maximum queues allowed for a wizard at any time (default 1000)
      function_invocation_limit -- (default 2500) maximum functions allowed per command
      function_recursion_limit -- (default 50) maximum number of times a function can call itself.
      secure_functions -- switches internal permissions of old-processing functions to be more secure, but breaks backward compatibility
      fascist_teleport -- players can't teleport out of anything they don't control or isn't set JUMP_OK
      restrict_home -- lock down the 'home' command to specific bitlevel
      restrict_home2 -- toggle enable/disable 'home' from those set NO_CODE
      restrict_sidefx -- specify what bitlevel SIDEEFFECT functions will work
      sideeffects -- specify what sideeffects are allowed
      sidefx_maxcalls -- how many sideeffects are allowed per command
      max_vattr_limit -- maximum unique user-attributes a player can create for his lifetime
      wizmax_vattr_limit -- maximum unique user-attributes a wizard can create for his lifetime
      vlimit -- maximum attributes allowed per object
      wildmatch_limit -- maximum number of wildmatches allowed per command
      lock_recursion_limit -- maximum lock recursion per command
      notify_recursion_limit -- maximum notify's allowed (internal notify call)
      nonindxtxt_maxlines -- maximum number of lines allowed to be read from @log
      max_percentsubs -- maximum percent substitutions allowed per command
      max_dest_limit -- maximum number of items that can be @destroyed by a player for a lifetime
      wizmax_dest_limit -- maximum number of items that can be @destroyed by a wizard for a lifetime
      safer_passwords -- enforce strict @passwords
      newpass_god -- allow newpasswording #1
      nospam_connect -- consolidates logs on people who attempt to keep trying to connect while forbidden
      examine_restrictive -- lockdown who can examine/@decompile
      ahear_maxtime -- maximum ceiling in seconds an @ahear is allowed to process
      ahear_maxcnt -- maximum recursions @hears are allowed
      cluster_cap -- ceiling on the number of cluster members allowed
      cluster_func_cap -- recursion ceiling on the cluster function handler
      includecnt -- number of times @include is allowed per command set
      includenest -- number of recursions @include is allowed
      lfunction_max -- maximum number of @lfunctions allowed a player
      safer_ufun -- make u() become protected in evaluation
      max_name_protect -- maximum number of @protect alises a player can have
      float_precision -- floating point precision you want allowed. from 0 to 48
      functions_max -- maximum number of @functions allowed to be defined
      parent_nest_limit -- maximum parents allowed in a parent chain
      imm_nomod -- is the NOMODIFY flag only allowed to immortals?
      start_build -- specifies if new players will or will not start with the WANDERER flag -- This defaults to '0' meaning they have the WANDERER flag which restricts all building.
      admin_object -- the @admin object that you can use to set permanent config settings in-game
      file_object -- the master override for all .txt files. this allows you to either set softcode to all those .txt files (like connect.txt) or design custom commands at the connect screen.
      access -- change access of various commands
      func_access -- change access of various functions
      config_access -- change access of various config options
      flag_access_set -- set who can set flags
      flag_access_unset -- set who can unset flags
      flag_access_see -- set who can see flags
      flag_access_type -- typecast permissions on flags
      toggle_access_set -- set who can set toggles
      toggle_access_unset -- set who can unset toggles
      toggle_access_see -- set who can see toggles
      toggle_access_type -- typecast permission on toggles
      proxy_checker -- set permission restriction level on dynamic proxy detection. Please note, use this sparringly and only if you absolutely have to. The Good news: this will detect most proxies, most of the time. It does this by scanning and comparing the MTUand MSS values and scraping the TCP header for overhead. most proxies require this padding to actually, well, proxy the information out. This means that MSS and MTU values will almost always be a different size for anyone and anything that uses a proxy. Now, the Bad News. Anyone coming out from a business SOCKS server, Firewall, DMZ, or, well, just coming out of a business will likely be identified by a proxy. You use your android device to mush? That's a proxy as well since the android TCP layer is ontop of a java stack. IPhone? Same beast. Pretty much any mobile device will be seen as a proxy, which is accurate, but likely not the type of people you want to block. Sooo, again, use this sparringly. I suggest enabling it to a level to allow monitoring, and only crank it up to deny if you're being directly attacked.

      Special commands to monitor/set security:
      @snoop -- Yup, it exists. This is an optional log or real-time monitor of a player
      @newpassword -- change target's password
      @aflags -- list permissions of attributes or set up global prefix restrictions based globally, by target, by enactor, or by sub-group
      @log -- control system logs
      @logrotate -- rotate logs real-time or verify current status of log file
      @api -- control who can set/unset/config/use the restful-like API interface
      @blacklist -- load in the blacklist which is created with the script tor_pull.sh that queries and pulls down the majority of public proxy IP's
      @tor -- control real time TOR proxy protection
      @freeze/@thaw -- real time queue freezing and thawing for sandboxing queues live
      @icmd -- control individual, room, or zone based access control of all commands a player can access
      @nuke/@toad/@turtle -- destroy and/or convert a player to a non-player.
      @recover -- recover a @nuked or @destroyed item from the database. This can be done until the object is @purged. Works like a recycle bin.
      @snapshot -- make a live snapshot image dump of the targetted dbref# for safe keeping
      @boot -- boot the player
      @disable -- disable logins to all but staff
      @flagdef/@toggledef -- in-game alter permissions of flags and toggles
      @site -- remove site permissions set via @admin foo_site (like forbid_site, suspect_site, etc)
      @limit -- assign limits (@destroy, user-attribute, or @lfunction) to target player. This has the effect of enabling, disabling, or overriding the global values for max values. so you can use this, for example, to disable a player's ability to set any user-defined attributes requiring them to only use @va-vz, @desc, and so forth.

      Well, wasn't that fun. Now we get to @toggles and @set flags:
      Toggles:
      Example:

      @toggle *player=forcehalted
      

      CPUTIME -- returns extremely useful data on runtime values of a command that executes
      FORCEHALTED -- allows you to @force something even if it's halted
      LOGROOM -- log everything the room sees. This is intended for IC purposes and will notify the player that logging is going into the room
      MAIL_LOCKDOWN -- stop wizards from being able to see other people's mail.
      MONITOR/MONITOR_AREG/MONITOR_SITE/MONITOR_CPU/MONITOR_VLIMIT/MONITOR_etcetc -- drilldown of all the in-game broadcasts for most of the built-in game RhostMUSH monitoring. CPU overloads, attribute caps being reached, success/failed connect attempts, and so forth. Ergo, day to day monitoring needs. The MONITOR foo in Rhost is very beefy, so please refer to the wizhelp on all the MONITOR @toggles for more information.

      Flags:
      Example:

      @set *player=slave
      

      WANDERER -- restrictive flag. Set on all new players by default unless configured otherwise. Stops all building/creating and requires removal before building allowed.
      GUILDMASTER -- first tier of staff bit
      ARCHITECT -- second tier of staff bit
      COUNCILOR -- third tier of staff bit
      ROYALTY -- this is your vanilla Wizard on other mushes
      IMMORTAL -- this is essentially #1 and 'all powerful'
      BACKSTAGE/NOBACKSTAGE control flags specifying who can control things set BACKSTAGE
      FUBAR -- stop from doing absolutely everything except ':' and '"'. Nothing else.
      SLAVE -- this also stops ':' and '"'. Used in combination with FUBAR to make a statue.
      INDESTRUCTIBLE -- nothing can destroy the target, not even #1
      NO_CODE -- stops target from doing all but the most basic commands and functions
      NO_CONNECT -- target can not log in
      NO_EXAMINE -- target can not be examined/@decompiled except by wizards
      NO_MODIFY -- target can not be modified except by wizards (or optionally just immortals)
      NO_MOVE -- target can not be moved by any means
      NO_TEL -- target can not be teleported, use teleport, or use home
      NO_PESTER -- target can not use whisper or @pemit
      NO_POSSESS -- target can not log into their player more than twice
      SPAMMONITOR -- target can not issue more than 60 commands a minute

      @depowers: -- These are tiered and inheritable from the player. Meaning permission levels can be decreased or removed entirely.
      Example:

      @depower/councilor *player=wall
      

      WALL -- disable walling
      STEAL -- disable getting items/gold
      WIZ_WHO -- disable wiz who
      BOOT -- disable boot
      FORCE -- disable @force/@sudo
      MASTER -- disable access to the master room
      NUKE -- disable @nuke/@toad/@turtle
      OVERRIDE -- disable overiding locks (wizards do this by default)
      TEL_ANYTHING -- disable teleporting anything
      POWER -- disable access to @power
      MODIFY -- disable ability to modify things
      CHOWN_OTHER -- disable ability to chown things you don't own
      UNL_QUOTA -- disable unlimited quota (useful on staff)
      GIVE -- disable the ability to give... anything...
      NOGOLD -- disable the ability to give or take gold
      PASSWORD -- disable ability to change passwords
      PERSONAL_COMMAND -- disable the ability to use any $commands on anything you own
      LONG_FINGERS -- disable all remote access features
      CREATE -- disable the ability to create anything
      CLOAK -- disable the overpowered wizcloaking ability from wizards
      PAGE -- no page for you!!!
      LOCK -- you can't pass locks. Ever. At all. Sucks to be you.
      COMMAND -- you can't use any $command. Anywhere. Only hardcoded commands for you!
      EXAMINE -- you can't examine/decompile or use any method to list attribs
      FREE -- everything is going to cost you gold
      TEL_ANYWHERE -- you can't teleport anywhere
      PCREATE -- disable wizards ability to create players
      QUOTA -- more more quota control for you
      CHOWN_ME -- you can't chown anything to yourself
      ABUSE -- you can only use $commands on things you own. Nothing else, including master room.
      SEARCH_ANY -- disable all db searching tools
      RECEIVE -- you can't receive anything
      DARK -- you can't go dark, and even if you miraculously were set DARK it'd not work for you.

      IMPORTANT NOTE: Wizards in RhostMUSH by default override all locks and have a unique ability called 'wizcloaking'. If a wizard is set DARK and UNFINDABLE then they become cloaked (like a Romulan bird of pray) and will be undetectable by any means except by another wizard. Immortals have a super-cloak ability that makes them invisible to Wizards in addition. As shown above, there is a @depower to disable cloaking if it's abused.

      ABOUT IMMORTALS: Immortals treat as #1. Seriously. They can do anything and everything. They have commands at their fingertips to literally hack and edit the database live, and naturally if they don't know what they're doing, can crash the mush, because of all this raw editing capabilities. Only set Immortal those who absolutely need it or you absolutely trust. Head coders, for example, should likely have an Immortal bit. Also, Immortals by default override pretty much every restriction in the game. A player set NO_TEL? Um yea, immortal can still @teleport them. This is intentional, because it's assumed Immortal's code should just work. So keep that in mind while coding. Cheers.

      For help identifying the twink, please refer to identifying the buttclown by IP

      -----------------------------------------------------------------------------------------------------------------
      And now, Evennia:
      For help in securing up your Evennia game (Thanks Griatch!)

      -----------------------------------------------------------------------------------------------------------------
      And now, AresMUSH:
      For help in securing up your AresMUSH game (Thanks Faraday!)

      -----------------------------------------------------------------------------------------------------------------
      And for those who really need to know code better I'll add some nice links here at the end.

      Mush:
      Central Hub
      Nick Gammon's Mush Setup Tutorial
      Javin's Mini-Mush Tutorial
      SW1k1 Mush Tutorial
      Kirra's Mush Tutorial for Beginners
      David King's Tutorial
      Amberyl's Mush Manual
      Javelin's Guide for Mushcode gods
      Algol's Mush Security Guide
      Ashen-Shugar's MUSH Security Tips
      RhostMUSH's in-game Coding Tutorial
      Faraday's Practical Coding

      Evennia:
      The Basic Tutorial
      Python for Beginners
      CodeCademy Online Python Tutorial
      Interactive Python Tutorial

      AresMUSH
      AresMUSH coding
      Learning Ruby in 20 minutes
      The Ruby Tutorial
      CodeCademy Online Ruby Tutorial

      ** Edited: Sun March 11th, 2018 23:05 CST **

      posted in Mildly Constructive
      Ashen-Shugar
      Ashen-Shugar
    • RE: Critters!

      Our Norwegian Forestcat Pyewacket






      posted in Tastes Less Game'y
      Ashen-Shugar
      Ashen-Shugar
    • RE: The Cat Thread

      @Arkandel said in The Cat Thread:

      @Ganymede said in The Cat Thread:

      (3) doesn't need a fucking sitter every time my partner and I go out because OMFG WHAT IF HE WAKES UP IN THE MIDDLE OF THE NIGHT?!?!?!?.

      <squints>

      What kinda super-cat do you have that doesn't wake up at 4 am, find that the food dish is only 1/3rd full then starts wailing like the world is on fire?

      posted in Tastes Less Game'y
      Ashen-Shugar
      Ashen-Shugar
    • RE: Make it fun for Me!

      It's a weird way to think about it, but I almost wish that all mush players as a prerequisite to mushing spend a month doing just one thing.

      Watching soap operas.

      Seriously. This puts into their mind how long-term stories work, how badly jointed ad-hoc story lines work. How plot-injection works. How character shields work for specific players or NPC's. How absolutely unrealistic some plots are. How unfair situations are but yet can still be enjoyable.

      How it's not real life.

      Think of it as a good study for what is considered by most a good recipe for a long-term world environment.

      Then apply that to mushing.

      It's scary how much that can make sense.

      posted in Mildly Constructive
      Ashen-Shugar
      Ashen-Shugar
    • RE: Critters!

      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.

      posted in Tastes Less Game'y
      Ashen-Shugar
      Ashen-Shugar
    • RE: Need Help. Deranged Person!

      MUX:

      @admin noguest_site=IP.HERE MASK.HERE
      Example: @admin noguest_site=123.123.123.0 255.255.255.0 (for a /24 mask)

      Penn:
      @sitelock <sitemask>=<options>
      Example: @sitelock *=!guest

      Rhost:
      @admin noguest_host=SITEMASK
      Example: @admin noguest_host=*

      Cheers.

      posted in MU Questions & Requests
      Ashen-Shugar
      Ashen-Shugar
    • RE: Hello MSBites! Grade your administrators.

      @krmbm said in [Hello MSBites! Grade your administrators.](/post

      You are blaming the envelope because you don't like the person who wrote the letter. The reason the place is catty and cliquish is because MU*ers are catty and cliquish. The reason it spills into this forum is because this forum is what we have.

      MU*ers are not cool winners who thrive on positivism. We're anti-social pretendy weirdos who have grievances we want to air.

      Sorry, gotta disagree here.

      The loudest mudders are catty, cliquish, and thrive on negativity.

      The majority of mudders are actually fair individuals. Most hold professional jobs, have families, and provide positive outlooks to things around them.

      Please don't box us in to a stereotype.

      posted in Announcements
      Ashen-Shugar
      Ashen-Shugar
    • RE: The Crafting Thread

      Guess it's not overly crafty, but I write poetry and roast coffee.

      My wife's the crafty one.

      She's a costume designer and milliner. She designs the hats from scratch, most are made from leather, velvet, or other such things.


      posted in Tastes Less Game'y
      Ashen-Shugar
      Ashen-Shugar
    • RE: Need Help. Deranged Person!

      @enoch said in Need Help. Deranged Person!:

      @ashen-shugar Thank you, sir!

      Be aware that if this is a consistent butthead, they likely will have access to a ton of various proxy sites, like TOR, Ninja, HideMyAss, and so forth.

      If you need to siteblock based on specific IP's, hit me up. I have a list of semi-current IP addresses for most known proxies, and while it won't be anywhere near the current full list (which amounts to the millions including all the private dark sites), it covers the majority of the public accessible ones.

      Blocking people from proxies becomes a battle of attrition. The goal isn't to block every proxy in existence. The goal is to block enough of them so that it takes far more time for them to find new proxies than it does for you to block them. At that point it tends to no longer be 'fun' for the troll and they tend to move on to other activities.

      posted in MU Questions & Requests
      Ashen-Shugar
      Ashen-Shugar
    • RE: Hobby-related Resolutions/Goals for the coming year... ?

      Got a ton of green coffee beans for Christmas.

      So my New Years resolution.

      1. Roast all the several pounds of green coffee I received.
      2. Grind all the coffee I roast in part #1.
      3. Binge-drink all the coffee I grind in part #2.
      4. Sit back and wait for the time to slow down after my 100th cup of coffee.

      posted in Mildly Constructive
      Ashen-Shugar
      Ashen-Shugar

    Latest posts made by Ashen-Shugar

    • RE: Critters!

      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.

      posted in Tastes Less Game'y
      Ashen-Shugar
      Ashen-Shugar
    • RE: Buying Shit

      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

      posted in Tastes Less Game'y
      Ashen-Shugar
      Ashen-Shugar
    • RE: Useful code on player bit

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

      posted in MU Code
      Ashen-Shugar
      Ashen-Shugar
    • RE: Do we need staff?

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

      posted in Mildly Constructive
      Ashen-Shugar
      Ashen-Shugar
    • RE: Reading the MUX dbm database with Python

      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.

      posted in MU Code
      Ashen-Shugar
      Ashen-Shugar
    • RE: Do we need staff?

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

      posted in Mildly Constructive
      Ashen-Shugar
      Ashen-Shugar
    • RE: New +txt/+email/etc code for TinyMUX

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

      posted in MU Code
      Ashen-Shugar
      Ashen-Shugar
    • RE: Quiet Room

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

      posted in MU Questions & Requests
      Ashen-Shugar
      Ashen-Shugar
    • RE: How To Strip Comtitles in PennMush

      @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
      
      posted in MU Questions & Requests
      Ashen-Shugar
      Ashen-Shugar
    • RE: How To Strip Comtitles in PennMush

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

      posted in MU Questions & Requests
      Ashen-Shugar
      Ashen-Shugar