Posts made by Ashen-Shugar

@auspice said in How much Code is too much Code?:

THERE IS NO SUCH THING AS TOO MUCH BOOB.

@faraday said in How much Code is too much Code?:

That really works? It boggles my mind that it would irritate anyone any more or less than being sitelocked. Like… you just click the disconnect button? Goes back to: people never cease to surprise in the ways they interact with code.

I know, right!?? Who knew.

You have to feel out the Troll that's attacking, but I find those who go out of their way to get the ban, to the point of even saying they want the ban or the ban is the only way to make them stop, if you stop them by another method, it annoys them to no end.

The person I did this too hated me so much he hunted me down on several servers, just to be able to tell me how much he hated me.

Made my day.

@sunny said in Code systems that make it easier to get on with the business of roleplaying:

I looooove:

Code that always highlights/colors my name, server side.

• @toggle me=extansi
• @extansi me=<colorcode your name here>
• @toggle me=variable (this allows your pose/say to be colorized when you talk)

Code that highlights/colors speech a different color omg so amazing.

• This would require end-code systems by the administration. Lots of easy ways to do this though (on any platform honestly)

Poseorder code to see where I am

• help speech_prefix (this is a prefix that works before all say, pose, and emits)
• help speech_suffix (this is a suffix that works after all say, pose, and emits)

Code that lets me read my alts' @mail.

• mail/share *myalt
• mail/number *altwhoshared
• mail/check *altwhoshared=message-number

M1963's activity requirement notification code

• this tends to be system by system with various watcher code

Also weather code even though people mostly don't do it any more I like it when games are snowing.

• This is a hard animal to do as the only 'real' weather code that's publically available is Keren's weather system. Which is out dated, cumbersome, and coded like vomit. Did I mention the vomit? The buckets of horrible vomit?

I notice a lot of people ask this in Rhost, so answered above for ya

@thenomain said in How much Code is too much Code?:

But then, I spend way too long coding even the simplest thing.

This.

This right here is what I and others have spent a horrible amount of time in Rhost to help with.
We made dev-end tools to give people more options to work outside of MUSH to do so.

These tools are:

1. @doors -- A method to estabish a TCP/IP connection from within the game to an outside source.

Pros:

• It is a simplistic interface to allow any TCP/IP connection.
• It allows async connectivity so you can mush while connected to the external application
• It allows a fairly unlimited number of connections to external services
• It comes standard with a MUSH/MUD/MOO door

Cons:

• It uses TCP line mode and not character mode
• You have to write your own TCP/IP interface for each connection you want
• You have to know C code to write your connection interface

@DOOR
  Command: @door 
  Switches: STATUS, OPEN, CLOSED, LIST, PUSH, KICK
  
  @door provides control over arbitraty TCP connections that are opened from
  inside the mush to some external program or service.
  
  In order for a door to be available a C-code module must first be loaded by
  an Admin(*), or compiled statically into the mush server.
  
  To see what doors exist on your system, type: @door
  
  (*) Not available in RhostMUSH 3.2.4p15 and earlier.
  
  See 'DOOR SYNTAX' on a quick listing of commands and what they do.
  
  See Also: DOOR_OPEN, DOOR_PUSH, DOOR_CLOSE, DOOR_LIST, DOOR_STATUS, 
            DOOR_KICK, DOOR_WRITING, INTERNAL_DOORS, DOORED, DOOR SYNTAX

2. execscript()
   Execscript allows you to call an external application, script, binary, or anything else, regardless of the language it is written in, and scrapes the results as a native function to the mush. this allows you to integrate anything externally as an internal function call. Very useful for integrated coding.

Pros:

• It allows you to execute any external binary/script/function/feature as a native MUSH function
• It allows you to push and pull data from this.

Cons:

• There is no real 'call back' feature to it
• You can not have execscript() call internal code interactively and must pass data to and from it
• You can't run processes in the background and scrape the data at the same time

EXECSCRIPT()
  Function: execscript(<script name> [,<arg 0>,...,<arg 9>])
  
  Note:  This function issues a shell interpreter so will have some
         overhead compared to calling it natively through an API.
  
  Requirements:  /usr/bin/timeout (on MacOSX link to /usr/local/bin/gtimeout)
                 script/binary existing in ~/game/scripts and chmod u+rx
                 @powered EXECSCRIPT GM or higher
                 Set SIDEFX (with the sideffect EXECSCRIPT enabled)
  
  This function executes a script called <script name> in the game
  directory's sub-directory 'scripts'.  It is case sensitive and strips
  illegal characters (like, .., /, $, etc) from the script name.
  
  This requires the EXECSCRIPT @power of GUILDMASTER to use the function.
  It requires the ARCHITECT level to allow the use of passing arguments
  to the script.  Unlike other powers, this power is not inheritable.
  
  You can pass a maximum of 9 arguments to the script not including the
  script name.
  
  The following variables are available from inside the scripts called:
    MUSH_PLAYER       - [%!] dbref# of player followed by name of player.  
    MUSH_CAUSE        - [%#] dbref# of cause followed by name of cause.  
    MUSH_CALLER       - [%@] dbref# of caller followed by name of caller.  
    MUSH_FLAGS        - the flags of the player.
    MUSH_TOGGLES      - the togglesof the player.
    MUSH_OWNER        - dbref# of player's owner by name of owner.
    MUSH_OWNERFLAGS   - the flags of the player's owner.
    MUSH_OWNERTOGGLES - the toggles of the player's owner.
  
  Examples:
    > say execscript(hello.sh)
    You say "hello from the script."
    > say execscript(hello.sh,test)
    You say "hello from the script with args: 'test'"
  
  See 'writing scripts' for help on dos and don'ts in writing execscripts.
    
  See Also: POWER EXECSCRIPT, exec_secure

3. The lovely API interface.
   This is a full grown http header based API call. It's similar to a RESTful API in how it works, but is header driven. You pass it arguments via headers to execute code and tell the MUSH how it's to parse the results.

Pros:

• A fully interactive and restful(like) API that is entirely header driven
• Allows you to push and pull data to and from the mush and execute mush code from within any external app
• Anything that talks normal HTTP 1.1 via liburl or normal url calls will be able to use the API
• Allows rapid connectivity to the mush and has no restrictions on what it can execute

Cons:

• No real callback feature, though you can work around it by having the API use execscript()
• If you queue data from an API you have to use a second API call to gather the results
• No persistent API connection
• No SSL layer (currently) is available

API
  Topic: API
  RhostMUSH has a process where it allows API connections to happen on another
  port.  It requires to have the api_port specified to a unique port for the
  API handler, then various optional config parameters to optimize how the
  API works.  The API, unlike normal connections, allows any valid dbref# to
  talk to the mush from the API engine.  It does this through multi-factor
  authentication including host match and password authentication.
  
  Keep in mind, the API port is NOT the mush port.  It is a different port.
  There is also quite a lot of protection on the API port which will
  automatically disable the object or the IP from connecting if abused.
  
  It uses Basic Authorization and encapsulates.  Example of using curl for
  login authentication to the API's object would be:
             curl --user "#123:foobar"
  The dbref# would be #123, and the password you want to authenticate would
  be 'foobar'.
  Example curl commands that are used for the API handler are:
  GET Examples (this is from a command line using the 'curl' application)
> curl -X GET --user "#12:ya" -H "Exec: [lnum(10)]" --head http://localhost:2222
  
  POST Example: (this is from a command line using the 'curl' application)
> curl -X POST --user "#12:ya" -H "Exec: @emit hi!" --head http://localhost:2222
  
  To have a target dbref# enabled for API processing, please alert a staff
  on your game as it requires staff approval and authentication to enable
  the dbref# to be useable for the API sub engine.
  
{ see 'help api return' for expected return codes }

Granted, this is not a perfect solution for coders, but I believe it empowers them to do a lot of things in MUSH that would normally be impossible to even consider and contemplate.

Hopefully as time passes RhostMUSH will continue to 'grow up' and continue to be a 'Big Boy'

@mietze said in How much Code is too much Code?:

@surreality i think for some people the coded stuff /does/ enhance their RP and creativity though. I wouldn’t want to say that someone who enjoys it isn’t being just as creative. I know some of the crisis stuff of RfK drove people nuts but I liked the narrative aspect (it described something of concern/going wrong in your monitored territories), because it allowed me to be super creative in how I narrated back how I would attempt to solve in conjunction with the roll.). Other people would have found it stifling or busywork though.

The hardest thing I believe with coding systems is to be honest, we really don't have that many real dedicated coders in this micro-industry.

And those few coders we do have tend to not want to code in mush, but in another language be it ruby, python, or even php/javascript/web.

This is a failing of a lot of codebases. They tend to gear to a single language system, and MUSH while incredibly powerful for what it is, is an exceptionally esoteric language that requires a special type of insanity to get good at.

Why I tip my hat at Evennia and Ares who use mainstream languages.

Why I took pages out of other people's books and empowered RhostMUSH to be coded, optionally, in any language the coder wants, with obvious caveats for interface and/or speed limitations.

One thing we, as coders, can do for the end user, even if that end user is another coder?

Empower them. Give them the tools needed to do what they find fun and enjoyable. And make life easier for them to do what they enjoy and want to do.

@thenomain said in How much Code is too much Code?:

@ashen-shugar said in How much Code is too much Code?:

That's when you tell them to just screw off and go away right?

Yeah, like either you or I are any good at that. We've worked so hard to become wizards that for some reason we feel that we have to use those powers for Good or we're not using them right.

Well, once someone annoyed me and eventually forced me to make the Medusa Object.

Them: I'm going to keep coming back until you boot me! (insert other random profanities, whining, and petulance here)
Me: ... ok (tap tap tap)
...
...

Ashen-Shugar has dropped Medusa Object.

...
...

Life from that point on was just hell for the guy.

For those curious, here's the Medusa Object

@@ This is the main medusa object -- An alternative to site-banning
@@
@@ This was created to counter-act the subset of trolls that get a kick
@@ of being able to force a site-admin to sitelock them.  They believe
@@ it as some weird badge of honor or entitlement and get a tickle out
@@ of it.  However, I find turning them into an object lesson as a, well,
@@ object annoys the hell out of them.  So I came up with this tool.
@@
@@ Essentially add their wildcarded DNS site to &SITES.  If you have IP only
@@ then use the IP, it's fine.  If you have a 'good' player, add them to 
@@ the excempt list (their dbref#) and it'll bypass them from being medusa'd.
@@
@@ The existing SITES is ones from a known troll, provied for your pleasure.
@@
@@ Versioning:
@@ Owner              Date       Description
@@ ------------------ ---------- --------------------------------------------
@@ Ashen-Shugar       07/18/2017 Original deployment
@@
@create Global: The Medusa Object=10
@Aconnect Global: The Medusa Object=@swi/f [!!and(wildmatch(v(sites),lookup_site(%#)),!match(v(exempt),%#))]=1,{@set %#=slave fubar}
@Adisconnect Global: The Medusa Object=@swi/f [!!wildmatch(v(sites),lookup_site(%#))]=1,{@set %#=!slave !fubar}
@Startup Global: The Medusa Object=@dolist search(eplayer=[lit([hasflag(##,guest)])])={@swi/f [hasflag(##,connect)]=0,@set ##=!fubar !slave}
&SITES Global: The Medusa Object=<sites go here>
&VERSION Global: The Medusa Object=1.0.0 07/18/2017
@set Global: The Medusa Object=INDESTRUCTABLE SAFE INHERIT

This essentially sets anyone connecting from the matching sites FUBAR and SLAVE, which disables every single command (including LOGOUT and QUIT) that the player can issue while on your game.

They find it annoying. Fancy that!

This will only work on RhostMUSH. You can likely tweak it for non-Rhost, but remember, non-Rhost games don't have the FUBAR flag.

@thenomain said in How much Code is too much Code?:

@ashen-shugar

Take the aggregate of all your code. Try to imagine the outcome. Remember that there are people logged in all the time asking you for ridiculous things like, "Can you create a setting that removes just the ANSI from comtitles?"

Those people are RPing. Strange, isn't it?

That's when you tell them to just screw off and go away right?

No wait, I actually helped you that time. Man, you must have caught me at a good time

On a serious note regarding this...

> comhelp comset
ComSys: Help for Version 1.2.0 of AshComV2 [09/22/2017]
------------------------------------------------------------------------------
Syntax: comset[/switch] <channel> <value>

This lets you set specific channel (or system wide) settings for various
settings for the comsystem. Current settings are:
     1 - NOANSI
     2 - NOANSI/NOCOMTITLE
     3 - NOCOMTITLE

NOANSI specifies you do not wish to see any ansi (except chan name)
and will muffle all other ansi with the exception of
the 'To:' option with player names. This is intentional.
The NOCOMTITLE option snuffs you receiving player comtitles
on the specified channel.

You may specify +all to specify system-wide settings as it specifies
all channels.

The specific options are available for the comset command:
/set - this will set (or modify an existing) channel with
          the specific value you specify. If you speicify +all it will purge
          all other entries as it assumes you set global overrides.
          This option requires a channel and a value between 1 and 3.
/unset - this will remove the specified channel (or +all) from the
          options. You must remove +all before setting individual
          channels. This is intentional.
          This option requires a channel name only.
/list - this lists what channels (if any) you have options on.
          This does not require any additional arguments.
------------------------------------------------------------------------------
ComSys: Individual Topic Help completed.

Cheers

@thenomain said in How much Code is too much Code?:

@arkandel said in How much Code is too much Code?:

3. Keep coders busy, otherwise who knows what they'll end up doing with their free time.

RP for once, maybe?

No... wait... what?

I don't understand. RP? Rabid Poodles? Huh? No, wait, it's getting dark out, I'm confused, help! Help!!

Well, funny I should speak up with my background of being an insane, well, coder, but here we go.

I think in the long scope of things, people forget a very important key of mushing.

At the end of the day, regardless of the emotional attachment, time invested, or IC and OOC engagement, it's still just a game.

On this very important, yet overlooked point, coding should make this enjoyable for the end user. Full stop.

At the end of the day, the code you do should answer a very simple question:

Does this code help make this game enjoyable to the player and help them find enjoyment?

If the answer is no, short of it being a required administrative tool or important back-end code, the answer should be obvious.

I noticed I never covered how to actually find the twinks, so I'm covering that here, since the post would be over 32,000 characters otherwise.

-----------------------------------------------------------------------------------------------------------------
How to go about finding the twink

Ok, I just realized I never had anything covered on how to actually run down and discover the twink that's attacking you.

Let's assume the IP of the person attacking you is 172.217.4.36. For those curious, that's an IP for www.google.com. Now, you are likely curious how to go about tracing this person down and block as much as you can. So, first, let's go for the obvious.

How do I know that IP is google?
Easy, I did a reverse lookup on the IP.

$ dig -x 172.217.4.36

; <<>> DiG 9.9.10-P2 <<>> -x 172.217.4.36
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56859
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;36.4.217.172.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
36.4.217.172.in-addr.arpa. 21599 IN	PTR	lga15s46-in-f4.1e100.net.
36.4.217.172.in-addr.arpa. 21599 IN	PTR	ord38s18-in-f4.1e100.net.
36.4.217.172.in-addr.arpa. 21599 IN	PTR	lga15s46-in-f36.1e100.net.
36.4.217.172.in-addr.arpa. 21599 IN	PTR	ord38s18-in-f4.1e100.net.
36.4.217.172.in-addr.arpa. 21599 IN	PTR	lga15s46-in-f4.1e100.net.
36.4.217.172.in-addr.arpa. 21599 IN	PTR	lga15s46-in-f36.1e100.net.

;; Query time: 56 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Dec 04 11:50:45 CST 2017
;; MSG SIZE  rcvd: 193

NOTE online web based dig can be found at https://www.digwebinterface.com/
Make sure to select 'Reverse' as the option you want.

Hum, DNS shows corporate, but let's see if we can find anything more about it...

$ nslookup 172.217.4.36
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
36.4.217.172.in-addr.arpa	name = lga15s46-in-f4.1e100.net.
36.4.217.172.in-addr.arpa	name = ord38s18-in-f4.1e100.net.
36.4.217.172.in-addr.arpa	name = lga15s46-in-f36.1e100.net.
36.4.217.172.in-addr.arpa	name = lga15s46-in-f36.1e100.net.
36.4.217.172.in-addr.arpa	name = lga15s46-in-f4.1e100.net.
36.4.217.172.in-addr.arpa	name = ord38s18-in-f4.1e100.net.

Authoritative answers can be found from:

NOTE For the online web interface for nslookup try https://centralops.net/co/
Nope, nothing much more, but that's ok...

1e100.net, if you're used to google will recognize that right off the bat, but if you are not, you can dig further...

$ whois 172.217.4.36

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#


#
# The following results may also be obtained via:
# https://whois.arin.net/rest/nets;q=172.217.4.36?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#

NetRange:       172.217.0.0 - 172.217.255.255
CIDR:           172.217.0.0/16
NetName:        GOOGLE
NetHandle:      NET-172-217-0-0-1
Parent:         NET172 (NET-172-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       AS15169
Organization:   Google LLC (GOGL)
RegDate:        2012-04-16
Updated:        2012-04-16
Ref:            https://whois.arin.net/rest/net/NET-172-217-0-0-1


OrgName:        Google LLC
OrgId:          GOGL
Address:        1600 Amphitheatre Parkway
City:           Mountain View
StateProv:      CA
PostalCode:     94043
Country:        US
RegDate:        2000-03-30
Updated:        2017-10-16
Ref:            https://whois.arin.net/rest/org/GOGL


OrgTechHandle: ZG39-ARIN
OrgTechName:   Google LLC
OrgTechPhone:  +1-650-253-0000 
OrgTechEmail:  arin-contact@google.com
OrgTechRef:    https://whois.arin.net/rest/poc/ZG39-ARIN

OrgAbuseHandle: ABUSE5250-ARIN
OrgAbuseName:   Abuse
OrgAbusePhone:  +1-650-253-0000 
OrgAbuseEmail:  network-abuse@google.com
OrgAbuseRef:    https://whois.arin.net/rest/poc/ABUSE5250-ARIN


#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#

NOTE For online whois, use http://ping.eu/ns-whois/ ... make sure to click 'full info'.

Therreeeeee we go. Notice the OrgTechName ... 'Google LLC' Yup, that's Google!
Now, let's assume this is an IP that you want to absolutely, beyond all measure block.
You have a few things you can do.

First, you can try the *.1e100.net that came from the nslookup. That should work for the RDNS blocking checks.

@sitelock *.1e100.net=!connect
@admin forbid_host=*.1e100.net

Second, you can look above from the whois output above for a section similar to the CIDR or NetRange at the start. That, my good friends, is the subnet that this person is coming from. If you block that entire subnet, you have just nailed down their entire ISP subnet that they use. Bam, gone!. Keep in mind, other users may also use this ISP, so you may want to verify anyone currently using them first.

Ways you can check on your mush

@search eplayer=match(get(##/lastsite),*.1e100.net)
@search eplayer=match(get(##/lastip),172.217.4.*)

Ok, so no one else uses that IP, it's free to block.

@admin forbid_site=172.217.0.0 /16

And done.

Now, you ask what if they're using a proxy?
Good question. There's no easy solution to that, but one thing you can do is find out what proxy group they're using, then manually go through and add every IP from that site. How do you find it?
Believe it or not, it's fairly easy.

Google search for the IP, again, we're assuming 172.217.4.36 is the attacker.
So now you would google search for:

172.217.4.36 proxy

The first one or two pages of google's search will identify public proxies (if they exist) that host that IP address. So it's your job at this point to go to those proxy sites, grab the ENTIRE list of IP addresses, and then add them to your forbid_site lists. It's painful, it's long, but as I stated earlier, blocking people who use proxies is a war of attrition. Your job is to make finding new proxies harder for them than it is for you to block. And honestly cutting and pasting the entire list of IP's from these proxy sites is not that difficult.

The only pain is before you know it, you're hitting 30,000 or more IP's blocked, but such is life.

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 **

@calibraxa said in Need Help. Deranged Person!:

@scar said in Need Help. Deranged Person!:

telecornjc?

Looks like it. A user named Telecornjc put up a redirect on their main page to a page called 'fuck you'.

It's obviously not your common troll then. He could actually spell.

So he wins a small dipshit award, bravo claps for him

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

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.

@miss-demeanor said in Hey you motherfuckers.:

@ashen-shugar Yeah but... that person actually has a parachute! That
wuss. We jump in with big smiles and nothing else.

It adds easier penetration when you land arse-naked on the sharpened spike at the bottom.

And yes. I speak of experience. It's my fifth time jumping in!

Sadly, doing the required Russian Kazatsky Dance once landed, is near impossible.

@coin said in Hey you motherfuckers.:

you pulled yourself back in, tho.

so.

XD

@thenomain said in Hey you motherfuckers.:

@miss-demeanor

Hi. My name is Thenomain and I’m a tweed robot coding in an outdated, outmoded, word salad of a coding language.

https://sourceforge.net/projects/mnbotmolitor/

One of my favorites was playing a senile mage called 'Frump'.

He was actually a deity with severe dementia, but had a skill bind that required him to not knowingly hurt anything alive by direct or indirect means.

The fun part of this character? Whatever he would imagine (in his dementia-spurred brain) would become a reality.

It would not be uncommon to have him walk over a pit and just stand in mid air.

The general commentary would be something like:

Party Member: Frump, um... careful of that pit?
Frump: head scratches what pit?
Party member: The pit you're currently hovering over?
Frump: *stamps foot down, you hear a dull 'thump' I'm standing on the ground.
Party member: No, it's a pit.
Frump: just blinks like player is stupid nooo, I would know if I was hovering

Second party member comes over to Frump, walks up to him and immediately falls into the pit shouting in agony

Frump: Hey! I"m standing over a pit! (immediately falls into the pit)

hear a whump, and someone dusting himself off

Frump: At least the pit didn't have any traps like spikes in it.
Party Member: Actually the pit... [muffled]

is immediately silenced by the other party members

Yes. The pit did have spikes.

The beauty of this? The party members started to realize that Frump on the odd occasion could twist reality to make what he believed to be real, well, real.

So someone picks up a rock, walks up to Frump and says 'Hey, isn't this the most BEAUTIFUL diamond you have ever seen?'

And well, sometimes Frump will agree, it's a beautiful diamond. Other times he's wondering why you're holding the most deadly spider in the world in your palm.

There's just no telling with good ol' Frump...

@auspice

This is the one I recently got for my work days.

Works well for my needs.

https://redhat.corpmerchandise.com/ProductDetail.aspx?did=26009&pid=200696

@theonceler said in Yes! More Micro-transactions! (Activision, WB Games and EA appreciation thread):

The games you want just don’t make enough money.

Boy it’d be nice to embed a tweet right here, but whatever, read this tweet storm from game biz journo Mike Futter. He does a good job of running down the changes that are getting single player buy-and-done games canceled while P2P goes on strong. The gist is that $60 per person just isn’t enough these days and season passes patched the problem for a while but now even they aren’t doing it anymore.

This is like saying all those poor multi-billion dollar companies don't make enough on their web sites so need to just apply those billions of ad-spaces to make up for their losses.

Yea, pull the other one. It's got bells on it.