@skew Adding onto Skew's, I actually use one regexp to get all of my names into one highlight along with telling the system to only highlight it if it's a word by itself! To avoid the Mae vs Maelstrom thing. It's: ((Name1|Name2|Name3|Name4)(?!(\w|-))). You can do however many names you want divided by | (which is just an OR marker). I personally find it easier to just have the one highlight.

@testament For triggers the order of operation can sometimes be an issue. Or it least it seemed that way for me and the multiple triggers I have set to highlight names, change text when in quotes, etc.

@pondscum said in How To Strip Comtitles in PennMush:
It does seem to be admin level, and whilst I staff on the game in question, I'm clueless with code.
charformat, alas, is also a code-y thing. It's just one you can set on yourself instead of channel-wide.
If you're admin and just want to turn off comtitles completely without fussing with code, just set the channel "notitle" as @Bobotron said above.

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

I loved the toys, but they were fragile as all heck. I remember having the dune buggy that turned into a flying thing, and the egg-shaped robot that turned into ... a ... scooter... that was also egg-shaped.

@thenomain I think you tucked this in on the core I still have collecting dust somewhere. It is pretty nifty. Can recommend. (I know it has the one you put in that reads the client window width, at least.)

@derp said in Setting up a builder Bit:
they will be regularly running searches and doing privileged @dols to fix things and ensure consistency
You would be better off giving them additional see_all powers. A builder already controls everything it owns.

@jennkryst Hardly a minor necro.
I just decided to take a look and would note for people's benefit that the game apparently moved, it is now at
mushhaven.com Port: 2526
No idea what it is like yet but somebody has said hello after I logged in as a guest? Which is a plus.

As of last night Raevnos pushed the SQLite branch to master which means PennMUSH has the json_query() and json_map() functions for parsing JSON strings. The code for PennMUSH to receive JSON data is already there but not hooked to anything, so it should be a quick fix to allow Penn to receive JSON and pass it to a handler.
The website never needs to send softcode, that was just an example. For a lot of things, you will want dedicated commands that are just used by the website to generate a JSON response that don't have a terminal equivalent (e.g. context menus, player lists, etc). But for something like a +finger or +who you can show the standard text in the terminal, show a popup version with links and images on the side, embed links and images directly in the terminal text, or some combination of the 3.

Also keep in mind no tutorial can possibly cover every eventuality - while dealing with different platforms and Linux distributions, not to mention hosting companies' interfaces and internal procedures a great lot of things can go differently than the original write-up. We're not even talking about errors per se, just... stuff where you need someone with a minimal understanding of Linux (or, in some cases, the specific MU* codebase you are setting up) to remove small roadblocks.
But that's why having a community comes in handy. If you have a specific problem, ask.

@bad-at-lurking So you are specifically against weeaboos and otaku characters. Which helps answer things a bit.
... but leaves you with slim pickings. I can't think of anywhere that lacks the sort of player who makes those characters. Even ignoring the occasional wiki-pic that someone just uses Anime or Anime-ish artwork, there are folks who go out of their way to put the trope into a game they normally wouldn't work in. (Doing this sort of thing is my favorite game. Making a character from X setting in Y game, but still somehow functions close to the way they do in X).

Part of what's confusing about the wiki family page is that it's describing multiple methods -- and a fair bit of it is not up to date.
I have managed to make it work through this method:
https://www.mediawiki.org/wiki/Manual:Wiki_family#Multiple_wikis_sharing_common_resources
I can confirm that the list of things they say you can share is no longer accurate; I can't recall which of the folders isn't viable to share off hand, but at least one of them is no longer shareable by 1.30.x.
That may not be what you want, though; which option you go with is going to depend a lot on your end goals.
Are you looking to run one game with access to multiple wikis? If so, look at that option. (This is what I was doing when I was able to make this work -- a core wiki with the RPG data, a private staff wiki for issues and behind the scenes metaplot notes or dev, and a player-side wiki. If this is what you're doing, you or whoever is doing your setup probably also want to look at Interwiki to port data from one to the other easily.)
If you are looking to run multiple games that are completely independent from each other, potentially run by different people to provide general hosting, you or whoever is handling your server foo should take a look at the Zero to MUX thread; Nemesis describes means of setting up multiple users and handling the installs more distinctly that way -- and you would explicitly not want to use the 'shared resources' option described above, as your various game runners may want to use different extensions or combinations thereof (some of which have a habit of breaking or losing support between mediawiki updates).
You're less looking for a mediawiki person here, and more looking for a server admin. This is better news than you may think; more people are familiar with server foo than the weird minutiae and vagaries of mediawiki in particular.
Suggestion: list the extensions you want to use here. Some have additional requirements and dependencies, and these requirements may better inform your server admin how to handle your setup.