As always, apologies if this has already been addressed. I searched, couldn't find it.
How do we make a Quiet Room totally quiet? As is, the rooms show connect/disconnects, and while it's not a huge thing, it really can be a pain on a bigger game.
I asked @Thenomain once upon a time, and he said that he and @Chime did some stuff and things and it was all done server-side. Any chance anyone remembers? (@Thenomain does not.)
Edit: This is on TinyMUX
@Rook Derp. That'd help. It's TinyMux.
This isn't going to solve your issue or answer your question. BUT. When I ran a MUX, I hacked the sourcecode to remove those messages on basic moves, since my game required all the exit code and teleport was only allowed via coded commands that had it's own emits.
I really should download and compile the source and go in and look at the most recent MUX code, from a wiz/config standpoint. I know Brazil and I talked about the differences between Rhost and MUX at one point, on this very subject.
The only TinyMUX that allows 100% complete quiet in rooms is @Chime's fork:
I've looked at the source, and it shows that the messages should be squelched if the room is set BLIND?
BLIND
FLAG: BLIND(B)
When set on an object that can move, the '<object> has arrived.',
'<object> has left.', and '<object> goes home' messages that would normally
be generated and delivered to the new and old locations are suppressed.
When set on an object with location, the '<object> has arrived.',
'<object> has left.', '<object> goes home', '<player> has connected.',
'<player> has disconnected.', and '<player> has partially disconnected.'
messages are that would normally be generated and delivered to everyone at
that location are suppressed.
Not sure why the help says 'an object with location' there, as the sourcecode says:
if ( !quiet
&& !Blind(thing)
&& !Blind(loc))
@Rook said in Quiet Quiet Rooms?:
I've looked at the source, and it shows that the messages should be squelched if the room is set BLIND?
Yes, that's one of it.
This was not folded into core TinyMUX because of issues with other games using the BLIND flag on rooms that are doing purely what is mentioned in the documents.
Chime's fork also fixes some issues with gigantic searches that were crashing The Reach. If it hasn't been folded into the main source then I should tag Brazil.
Mind you, she's also reorganized things in a more UNIX-y way, so let me see if I can find the outright patch.... And alas, I cannot. She does have a patch that you can apply to the standard TinyMUX source.
One could easily diff the two move.cpp files and produce a patch.
Nice of you to volunteer. 
Diff created, and in reading through it... it seems like Chime is doing more than just simple changes to move.cpp in comparison to trunk MUX. I cannot find much in the top-level documentation, but the diff suggests renaming of HAVE_REALITY_LVLS to REALITY_LVLS, some mention of FIRANMUX configuration calls and so forth, in addition to the expected touches to various functions in the code itself.
Might be safe to use against a game, might not.
Disclaimer: I am not a maintainer of either of these codebases, so use at your own risk, quasi-obviously.
Hi! (As always nudge me in other media if I'm not responsive here; thanks @Misadventure!)
Several things:
My fork is designed for change a variety of things for the sorts of games I was working on. There are two pertinent branches; 'mechanipus' which is more or less the 'master' type branch containing all of the various changes, and 'mechanipus-rebased-vs-git_dev' which is a rebased (change collected and minimized set of diffs) version vs one of Brazil's dev branches.
In this rebased one, all the main patches are separated out as major functional changes covering the bits people find separately interesting:
https://github.com/lashtear/tinymux/commits/mechanipus-rebased-vs-git_dev shows the commit history for that resulting branch, with them always re-ordered so my customizations are at the end (independent of chronology). You can click on any of the hash-ids to see patch data for that change.
Or, in command line form:
git clone https://github.com/lashtear/tinymux.git
cd tinymux
git checkout mechanipus-rebased-vs-git_dev
git log --abbrev-commit --sparse --decorate --pretty=oneline
Which will give you a display something like:
| Hash-Id | Commit comment |
|---|---|
25c302a9 |
(HEAD -> mechanipus-rebased-vs-git_dev, origin/mechanipus-rebased-vs-git_dev, mechanipus-rebased-vs-git_brazil) Add a basic .gitignore file |
65416020 |
Change bare 'think' to not alter idle() time |
6b19bbb9 |
Cause command lookups on master room objects to consider parents |
2af2f13b |
Try 64000 char lbufs for the Reach. Change the Boyer-Moore-Horspool implementation to account for larger LBUF_SIZE |
5fd60802 |
use BLIND on rooms to really silence messages |
In your case, you are only interested in that last one there. Hot damn I'm a markdown badass.
git show 5fd60802
Which will give you
commit 5fd6080286dc36fe7ba6673a208dbfb445a6d056
Author: Emily Backes <lucca@accela.net>
Date: Wed Sep 28 22:46:09 2011 -0700
use BLIND on rooms to really silence messages
* Covers X goes home.
* Covers connected/disconnected/partially disconnected.
* Works even with REALITY_LEVELS configured.
This is for quiet rooms and character freezers, and allegedly breaks
other games that use BLIND rooms for some other purpose.
Based on 37c8fcf06b34f57ad9f06b060acdcbe37521cc32 but with changes to
REALITY_LEVELS support.
diff --git a/mux/game/text/help.txt b/mux/game/text/help.txt
index af4df527..1cb90c5f 100644
--- a/mux/game/text/help.txt
+++ b/mux/game/text/help.txt
@@ -5021,10 +5021,15 @@ BLIND
FLAG: BLIND(B)
- This flag suppresses the '<who> has arrived.' and '<who> has left.' messages.
- When set on a player, the messages caused by their movement are suppressed.
- When set on a location, the messages for everyone entering or leaving that
- location are suppressed.
+ When set on an object that can move, the '<object> has arrived.',
+ '<object> has left.', and '<object> goes home' messages that would normally
+ be generated and delivered to the new and old locations are suppressed.
+
+ When set on an object with location, the '<object> has arrived.',
+ '<object> has left.', '<object> goes home', '<player> has connected.',
+ '<player> has disconnected.', and '<player> has partially disconnected.'
+ messages are that would normally be generated and delivered to everyone at
+ that location are suppressed.
This flag can only be set by Wizards.
diff --git a/mux/src/move.cpp b/mux/src/move.cpp
index eb481dac..901107a7 100644
--- a/mux/src/move.cpp
+++ b/mux/src/move.cpp
@@ -676,7 +676,9 @@ void do_move(dbref executor, dbref caller, dbref enactor, int eval, int key, UTF
if ( (loc = Location(executor)) != NOTHING
&& !Dark(executor)
- && !Dark(loc))
+ && !Dark(loc)
+ && !Blind(executor)
+ && !Blind(loc))
{
// Tell all
//
diff --git a/mux/src/netcommon.cpp b/mux/src/netcommon.cpp
index d389d5a1..1b0a60ee 100644
--- a/mux/src/netcommon.cpp
+++ b/mux/src/netcommon.cpp
@@ -1058,25 +1058,15 @@ static void announce_connect(dbref player, DESC *d)
int key = MSG_INV;
if ( loc != NOTHING
&& !( Hidden(player)
- && Can_Hide(player)))
+ && Can_Hide(player))
+ && !Blind(loc))
{
key |= (MSG_NBR | MSG_NBR_EXITS | MSG_LOC | MSG_FWDLIST);
}
dbref temp = mudstate.curr_enactor;
mudstate.curr_enactor = player;
-#ifdef REALITY_LVLS
- if (NOTHING == loc)
- {
- notify_check(player, player, buf, key);
- }
- else
- {
- notify_except_rlevel(loc, player, player, buf, 0);
- }
-#else
notify_check(player, player, buf, key);
-#endif // REALITY_LVLS
atr_pget_str_LEN(buf, player, A_ACONNECT, &aowner, &aflags, &nLen);
CLinearTimeAbsolute lta;
dbref zone, obj;
@@ -1206,22 +1196,12 @@ void announce_disconnect(dbref player, DESC *d, const UTF8 *reason)
key = MSG_INV;
if ( loc != NOTHING
&& !( Hidden(player)
- && Can_Hide(player)))
+ && Can_Hide(player))
+ && !Blind(loc))
{
key |= (MSG_NBR | MSG_NBR_EXITS | MSG_LOC | MSG_FWDLIST);
}
-#ifdef REALITY_LVLS
- if (NOTHING == loc)
- {
- notify_check(player, player, buf, key);
- }
- else
- {
- notify_except_rlevel(loc, player, player, buf, 0);
- }
-#else
notify_check(player, player, buf, key);
-#endif // REALITY_LVLS
if (mudconf.have_mailer)
{
@@ -1354,22 +1334,12 @@ void announce_disconnect(dbref player, DESC *d, const UTF8 *reason)
key = MSG_INV;
if ( loc != NOTHING
&& !( Hidden(player)
- && Can_Hide(player)))
+ && Can_Hide(player))
+ && !Blind(loc))
{
key |= (MSG_NBR | MSG_NBR_EXITS | MSG_LOC | MSG_FWDLIST);
}
-#ifdef REALITY_LVLS
- if (NOTHING == loc)
- {
- notify_check(player, player, mbuf, key);
- }
- else
- {
- notify_except_rlevel(loc, player, player, mbuf, 0);
- }
-#else
notify_check(player, player, mbuf, key);
-#endif // REALITY_LVLS
raw_broadcast(MONITOR, T("GAME: %s has partially disconnected."),
Moniker(player));
free_mbuf(mbuf);
If you aren't using my fork (which now has a few other rather invasive changes)-- then THAT patch there is your best bet.
Quick explanation: Brazil got the ifdefs for reality_lvls wrong and the result is it emits a bunch of extra messages if your game is built with them. He disagreed, and cited incompatibility with other game(s)-- likely Firan, but I haven't talked to anyone on that side and didn't immediately see what the conflict would be. In any case, the patch is certainly compatible with new games that want this behavior, so there it is.
It is by will alone I set my mind in motion. It is by the juice of Coffea arabica that thoughts acquire speed, the table acquires stains, the stains become a warning. It is by will alone I set my mind in motion.
@Chime aside from being closed for a few years and so probably no longer a consideration, Firan also never used reality levels; all of Firan's stuff was bundled under the --enable_firanmux switch (except for the Penn-compatible inline SQL stuff which was pulled out into its own define).
I dunno which game was the breakage case.
Edit: Firan did have a lot of movement specific logic needed for the follow command and the IC footprint tracking, which might've been a consideration in modifying move.cpp. But none of that was in the reality level defines.
Thank you, @Chime!
Hate to do this, but can anyone break down how to apply this patch in very, very simple terms? I can get into the console as necessary, I know what git is, I just have no idea how to apply a patch to a game. Or, well, most anything else linux-related.
Thank you all!
@skew said in Quiet Quiet Rooms?:
Thank you, @Chime!
Anytime!
Hate to do this, but can anyone break down how to apply this patch in very, very simple terms? I can get into the console as necessary, I know what git is, I just have no idea how to apply a patch to a game. Or, well, most anything else linux-related.
Sorry for being a bit terse. I spend most of my waking hours at some sort of unix prompt (Linux or otherwise). First, you'll need several tools. If you don't have administrator (root) access, then hopefully your host has already got these installed. On deb-derived systems (Debian, Ubuntu, Mint, etc etc) you'll want something like
$ sudo apt-get update
... some lines downloading package lists ...
$ sudo apt-get install build-essential g++ make patch tar bzip2 wget git
... some lines describing additional packages it wants to install ...
... question about if that's okay (say yes, generally) ...
... many lines about downloading and installing each package ...
If the tools are already there, then you won't need to do that.
$ cd
$ mkdir mux-src
$ cd mux-src
$ wget ftp://ftp.tinymux.org/tinymux-2.12/alpha/3/mux-2.12.0.3.unix.tar.bz2
--2017-05-09 23:35:06-- ftp://ftp.tinymux.org/tinymux-2.12/alpha/3/mux-2.12.0.3.unix.tar.bz2
=> ‘mux-2.12.0.3.unix.tar.bz2’
Resolving ftp.tinymux.org (ftp.tinymux.org)... 52.34.23.255, 2600:1f14:2a0:2201:ab7d:7d:8dd3:57fc
Connecting to ftp.tinymux.org (ftp.tinymux.org)|52.34.23.255|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /tinymux-2.12/alpha/3 ... done.
==> SIZE mux-2.12.0.3.unix.tar.bz2 ... 1080619
==> PASV ... done. ==> RETR mux-2.12.0.3.unix.tar.bz2 ... done.
Length: 1080619 (1.0M) (unauthoritative)
mux-2.12.0.3.unix.tar.bz2 100%[===============================================================================>] 1.03M --.-KB/s in 0.09s
2017-05-09 23:35:06 (11.6 MB/s) - ‘mux-2.12.0.3.unix.tar.bz2’ saved [1080619]
$ tar xjvf mux-2.12.0.3.unix.tar.bz2
mux2.12/
mux2.12/INSTALL
mux2.12/SGP
mux2.12/CHANGES
mux2.12/LOCAL
mux2.12/REALITY.SETUP
mux2.12/NOTES
mux2.12/src/
mux2.12/src/move.cpp
mux2.12/src/Doxyfile
mux2.12/src/autoconf.h.in
mux2.12/src/muxcli.h
... many more files unpacking ...
$ git clone https://github.com/lashtear/tinymux.git
Cloning into 'tinymux'...
remote: Counting objects: 59424, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 59424 (delta 0), reused 0 (delta 0), pack-reused 59422
Receiving objects: 100% (59424/59424), 18.34 MiB | 17.20 MiB/s, done.
Resolving deltas: 100% (46787/46787), done.
Now, you should be in a folder called 'mux-src' right underneath your homedir, with the tar.bz2 archive of upstream tinymux from Brazil and a git checkout of my quirky version.
$ ls -laF
total 1080
drwxr-xr-x 4 lucca lucca 4096 May 10 00:01 ./
drwxr-xr-x 104 lucca lucca 12288 May 9 23:56 ../
drwxr-x--- 5 lucca lucca 4096 Feb 13 2016 mux2.12/
-rw-r--r-- 1 lucca lucca 1080619 May 9 23:35 mux-2.12.0.3.unix.tar.bz2
drwxr-xr-x 11 lucca lucca 4096 May 9 23:58 tinymux/
$ cd tinymux
$ git show 5fd6080286dc36fe7ba6673a208dbfb445a6d056 > ../blind-room.patch
$ cd ..
$ ls -laF
total 1088
drwxr-xr-x 4 lucca lucca 4096 May 10 00:03 ./
drwxr-xr-x 104 lucca lucca 12288 May 9 23:56 ../
-rw-r--r-- 1 lucca lucca 4606 May 10 00:03 blind-room.patch
drwxr-x--- 5 lucca lucca 4096 Feb 13 2016 mux2.12/
-rw-r--r-- 1 lucca lucca 1080619 May 9 23:35 mux-2.12.0.3.unix.tar.bz2
drwxr-xr-x 16 lucca lucca 4096 May 10 00:03 tinymux/
Now we have that same bit plus that blind-room.patch file. Now before you start suggesting that it'd be really handy if we kept all those patches somewhere easy to access-- that's exactly what any revision control software (like git) does. Anyway, time to apply.
$ cd mux2.12
$ patch -p2 <../blind-room.patch
patching file game/text/help.txt
patching file src/move.cpp
patching file src/netcommon.cpp
Congrats. You now have a tinymux tree from Brazil but with just that one patch of mine added. If you were instead building from his git repo, you could do this all much easier with the git cherry-pick command, but you probably aren't. If building against an archive export of his git tree, change the parameter to -p1 because of the slightly different directory structure.
This should work for most any 2.12 or 2.10 version, though if you use 2.10 the file offsets are slightly different, so you would see instead:
$ cd mux2.10
$ patch -p2 <../blind-room.patch
patching file game/text/help.txt
Hunk #1 succeeded at 5009 (offset -12 lines).
patching file src/move.cpp
patching file src/netcommon.cpp
Yes; git, patch, diff, etc are all rather clever and indispensable tools that I can't imagine getting through my day without. Game should build as normal with these changes.
As always, apologies if this has already been addressed. I searched, couldn't find it.
How do we make a Quiet Room totally quiet? As is, the rooms show connect/disconnects, and while it's not a huge thing, it really can be a pain on a bigger game.
I asked @Thenomain once upon a time, and he said that he and @Chime did some stuff and things and it was all done server-side. Any chance anyone remembers? (@Thenomain does not.)
Edit: This is on TinyMUX