I always cringe when someone mentions Immersion within MU*'s.
Main reason, after a given time, it appears to always be taken to extremes by at least one party in a group and it just drives things uncomfortable. Granted, it doesn't happen all the time, but enough to make me wary of it.
So for the most part, whenever anyone brings up Immersion in a mush environment, I always envision this:
What might get me off my keaster and RP on a mush is a superhero game based entirely on the second string heros.
Ergo, the ability to blow off hats, or shine shoes, tie strings/ropes, ability to make lightbulbs light up, ergo the powers that are pretty much pointless and worthless in nearly every category.
And have a game based entirely on these type of 'heros'.
@skew said in How to type `quit` and quit PennMUSH?:
@ashen-shugar said in How to type `quit` and quit PennMUSH?:
Not tried it in PennMUSH, but you could maybe modify aliascnf.dst with something like
command_alias QUIT quitThat’s server side, yes? Nothing I can do player-side?
&CMD`QUIT wizobject=$quit:@boot/silent/port [first(iter(ports(%#),if(lte(idle(%i0),1),%i0)))]
Not tried it in PennMUSH, but you could maybe modify aliascnf.dst with something like
command_alias QUIT quit
@autumn said in Resetting your #1/God/Admin password:
A very slightly easier version of #2 for TinyMUSH is to redefine GOD to the dbref of a character you do know the password for -- then recompile and restart. The TinyMUSH source code I have at hand is about ten years old, but it's probably still in flags.h:
#define GOD ((dbref) 1)
This has the advantage of allowing only the specified player to change #1's password; but it makes it even more important to change it back right away, because there's probably some code on your game somewhere that depends on #1 being God.
Most excellent. That totally slipped my mind as a valid solution. Thanks for the reminder!
I added it to the main post with credits to you.
@thatonedude said in Using an SSD as cache (Windows 10):
You could go spanned or striped drive (one logical drive made of two or more physical drives). Striped is faster but the drives need to be the same size. This is just a suggestion to use the spare SSD. The alternative could be to turn it into an external drive for backups and the like (get the kit to make it pretty).
For me I don't think there is much to gain trying to us the ssd for caching but that's just: the level of complexity vs the payout , divided by my lazy, equals fuck that.
Not entirely sure how much Windows 10 writes in the cache, just be aware SSD's are limited by the number of writes. On systems that used SSD's as temp storage with a crap-ton of writes, I've seen SSD's die in a few months. This was, however, production level temp space, and I doubt you'd have to worry with Windows 10 cache drives, but I've never sat down and spent time on how much Windows writes in caches nor how often.
I'll leave it up to those who have far more experience than I do.
I have seen on various mushes where resetting the GOD password (or administrative account password) is becoming more and more the norm. Most from people who pass on databases to others to use and manipulate.
So, I'll cover here the various codebases and how to change the password.
TinyMUSH 3 nor MUX have no built in tools or mechanisms to change #1's password within the game. However, there are a few ways this can be achieved.
find the process
$ ps aux|grep mush
tmuser 17229 0.0 0.0 24712 2816 pts/0 S 11:28 0:00 ./bin/netmush -c netmush.conf -l netmush.log -p netmush.pid -t ./text -b ./bin -d ./data -g netmush.gdbm -k netmush.db.CRASH
attach to the process. In this case PID 17229
$ gdb -p 17229
...
...
lots of text spams here
...
Attaching to process 17229
Reading symbols from /home/tmuser/TM3/tinymush-3.2/src/netmush...done.
...
lots more text here
(gdb) call atr_clr(1,5)
(gdb) quit
A debugging session is active.
Inferior 1 [process 17229] will be detached.
Quit anyway? (y or n) y
Detaching from program: /home/tmuser/TM3/tinymush-3.2/src/netmush, process 17229
Note: atr_clr is an internal function to clear an attribute. This is just like if you did in game &myattr foo. Attribute '5' if you check attrs.h (in the src directory) is A_PASS or your password attribute. So you are essentially clearing your password.
At this point you can connect to #1 without a password. At the connect screen just type:
co #1
if (God(victim)) {
notify_quiet(player, "You cannot change that player's password.");
return;
}
In MUX you will see a line like this:
if (God(victim))
{
bool bCan = true;
if (God(executor))
You need to comment this out like so:
/* Commented out
if (God(victim)) {
notify_quiet(player, "You cannot change that player's password.");
return;
}
*/
In MUX you would change it to this:
/* if (God(victim)) */
if ( 0 )
{
bool bCan = true;
if (God(executor))
Then you need to recompile
$ make clean; make
Now restart your mush in the game (Or ./Startmush or ./Startmux respectively if you shut it down)
@restart
Now you should be able to change #1's password from any wizard account.
Make sure you revert your changes at this point or wizards will always be able to newpassword GOD. I don't think you want that 
So revert your changes:
if (God(victim)) {
notify_quiet(player, "You cannot change that player's password.");
return;
}
Or for MUX change back to:
if (God(victim))
{
bool bCan = true;
if (God(executor))
Recompile
$ make clean; make
And restart your mush process from #1
@restart
You should be good to go now.
You may also modify flags.h in both MUX and TinyMUSH to change the dbref# of your GOD character. This requires that you must already know the dbref# of an existing player that you can log into or this method is pointless. Do not assign it to a guest character. Ever.
In flags.h look for the following line:
#define GOD ((dbref) 1)
Change the '1' to a dbref# of a player you know the password to, again, non-guest player. So if your player had dbref #12345, you would change the '1' to '12345'. Assuming that the dbref was #12345, it would look like this after editing:
#define GOD ((dbref) 12345)
At this point you'd recompile the source. Always make sure to make clean:
$ make clean;make
Once you have, start the mush or reboot the mush and log into the player you have defined as the GOD player. Once you do, newpassword #1 to a new password. In the example below I set it to 'abc123':
@newpassword #1=abc123
Log into #1 to make sure the password took:
co #1 abc123
Now you need to revert back your changes. Revert your flags.h changes and recompile.
#define GOD ((dbref) 1)
$ make clean; make
Now, log restart your mush and you should be good to go.
$ vi netmush.db.flat
Go down to the line that starts with !1
...
lots of stuff before this
...
!1
"Wizard"
0
-1
-1
-1
0
-1
1
-1
1000
4115
0
16
0
0
1524934266
1524934266
0
>30
"Sat Apr 28 11:50:16 2018"
>49
"20 20 20 20 20"
>38
"20 20 20 20 20"
>5
"XXNHc95o0HhAc"
...
lots of stuff after this
...
Remember above in step 2 where I showed the numeric value for the password was '5' in attrs.h? Notice the line at the end here that has >5. In the flatfile the > parameter is a declaration that the following numerical value is an attribute. The line after it will be the content of that file. Change this to "". This will make it an empty password. So, change to:
>5
""
If that doesn't work for whatever reason, feel free to change it to the default password of 'potrzebie'. TinyMUSH still uses DES encoding. For reference it was included above, so change it to:
>5
"XXNHc95o0HhAc"
Do note for MUX it uses SHA1 password encoding so you need to change it to this instead
>5
"$SHA1$X0PG0reTn66s$FxO7KKs/CJ+an2rDWgGO4zpo1co="
Now, the fun part. Loading in your flatfile. Do this from your 'game' directory. Make SURE you have a clean data directory prior to doing this. dbconvert does not like overwriting files and you will hork your database. So my suggestion, move everything to a subdirectory.
First, make sure your game is shutdown
Second, move all the files to a subdirectory.
$ cd data # assuming you're in the game directory
$ mkdir storage
$ mv * storage
$ cd .. # to go back to the game directory
Now, let's load up your flatfile. This is assuming your mush flatfile is in your game directory. You will be exeucting this from the game directory. For TinyMUSH you would issue this command:
$ ./dbconvert -c netmush.conf -d ./data -D netmush.gdbm -X ./data/netmush.gdbm < netmush.db.flat
For TinyMUX you would issue this command, and from the data directory, not the game directory:
$ ./db_load netmux netmux.flat netmux.db
At this point, you should be good to start your mush back up. For TinyMUSH:
./Startmush
For MUX:
./Startmux
With Penn, just use the pre-defined password utility to change #1's password. You must first @shutdown your mush prior to issuing this.
# issue help on the command
$ ./utils/pwutil --help
# wipe #1's password
$ ./utils/pwutil.pl -z --wipe 1 game/data/outdb.gz
# set #1's password to 'forgetful'
$ ./utils/pwutil.pl -z --set 1 --password forgetful game/data/outdb.gz
At this point, bring your mush back up:
./restart.dst
Andddd, that's it.
First, if you already have an immortal in the game you can change #1's password within a running game by making a change to your netrhost.conf file and rebooting. Use any editor of your choice, I will show with 'vi'.
$ vi netrhost.conf
At the bottom right before the line '# this is the last line. This should always be the last line.' add this line so it looks like this:
newpass_god 1
# this is the last line. This should always be the last line.
Now, reboot your mush
@reboot
At this point you can change #1's password from any immortal.
But hey, what happens if you don't have an immortal? Also easy:
newpass_god 777
# this is the last line. This should always be the last line.
Now, again, @reboot
@reboot
At this point, #1's password will be the default password 'Nyctasia'. So just log in with that as a password. It is case sensitive.
co #1 Nyctasia
Remove the newpass_god line from your netrhost.conf file
# this is the last line. This should always be the last line.
And @reboot again to make sure the changes are gone.
@reboot
Andd, that's it.
The example changes the password to account 'Foo' (which in this case is account#1):
Quoted from @Griatch. Thanks!
evennia changepassword Foo
Password:
Password again:
Password changed successfully for user 'Foo(account#1)'
Knowledge is knowing you know nothing
@auspice said in Hello MSBites! Grade your administrators.:
@insomnia said in Hello MSBites! Grade your administrators.:
@auspice Belatedly, and may not be an issue with the new area; and probably not easily doable with this forum because it seems pretty lacking in easy code things, but what about for ads locking them to a group. The game owner would have to say MSBPoster 1, and MSBPoster2, are staff, could you add them to our group, and then if someone leaves staff the Game owner would have to contact you guys to have them removed from the group for official threads.
But you could also still allow random people to post because they just found this really cool game and want people to know about it and lock it up. If a game then wants an official ad made they could ask for a group. I mean if you are proud of your game and staffing, why not have a badge by their name?
Not sure if groups can work this way or not, but they seem under-used.
It's an interesting idea, but...
still adds to the whole 'pile of work for the moderators.'
I also def. wouldn't make badges on a per-game basis. That definitely adds a lot more work.
Now, I will consider, as I look at new forum software, the ability for someone to lock their own thread and add other poster permissions. That might help.
If I could lock a thread and add, say, Derp as an approved poster, that would help a lot.
But right now, I really want to be able to trust the forum at large to behave and keep to posting in approved areas without having to use other tools that require a lot of extra work on the mod's part. We're all adults. We should be able to go 'Oh, AnotherMUX put up an ad thread? I wanna talk about it. I should go see if there's a thread in Constructive.'
Don't know if it may help, but maybe an option that requires a poster wait a full hour before posting in the same thread after their last post?
This should allow sufficient time to 'cool down' from personal attacks against them on such instances, or allow someone to think on responses for technical or deep-thinking posts instead of knee-jerk responses.
We can't make people pull back how they feel or how they think, but it's relatively easy to enforce someone take the time to do so.
I wouldn't mind waiting an hour for a next post if it means overall the forum becomes more positive.
The hardest thing to deal with on the internet is realizing where people are coming from. This doesn't just mean mentally or emotionally, but physically. How someone grew up in India is absolutely different how someone grew up in Israel, or Australia, or what have you.
We forget about this. We refer to someone and subconsciously we fall into a falsity that this is just like someone next door and will automatically refer to how I feel, think, and believe because, hey, how can they not?
So we make comments based on that, and low and behold, someone somewhere gets insulted as what you didn't even mean as a personal attack suddenly is one. And who knows, deep down you may or may not have meant it as a personal attack. Fact is, it's irrelevant.
Our posts should be clear in rhetoric and done so if we write something it can be mostly clear what our intention is without falling back on tripe on local jargon or quirks of speech that others will look at and think 'wtf are you talking about?'.
It's a hard medium to discuss on without a face to face, but it's all we have. Let's try to make the most of it?
@thenomain said in Hello MSBites! Grade your administrators.:
@ashen-shugar said in Hello MSBites! Grade your administrators.:
@thenomain said in Hello MSBites! Grade your administrators.:
Because you were kind of a dick to people for liking TinyMUX.
Only MUX 1.x and TinyMUSH.
I got annoyed of people always whining about it eating their databases
What is a niche hobby without shoddy equipment? Where is the excitement if everything works smoothly? Next you’re going to say that clear documentation is good or something.
Absolutely. I love my documention clear always, you can even say I love it ever clear. Preferably in a glass, mixed with koolaid, straw optional.
@thenomain said in Hello MSBites! Grade your administrators.:
Because you were kind of a dick to people for liking TinyMUX.
Only MUX 1.x and TinyMUSH.
I got annoyed of people always whining about it eating their databases 
@auspice said in Hello MSBites! Grade your administrators.:
And for the sheer amount of time that went on it was just like, 'wow. these people really, really think I'm worthless.'
This.
This right here in a very generic way describes the issue that a lot of people on the internet as a whole have.
I want you (the general you out there) to think about this real hard.
Why would someone who you have never met, have likely never seen, know nothing about, likely has no knowledge of you as well, nor likely has a reason to even find out, have any bearing to state that you would be worthless or not.
And an even better question. Why should you care?
Just, you know, food for thought?
@thatguythere said in Hello MSBites! Grade your administrators.:
@ashen-shugar
In your post you seem to imply that "catty, cliquish, and thrive on negativity" doesn't go along with holding a professional job. If you think that is the case you really need to work in more offices or be very grateful for the ones you have worked in.
Sure it does. But most highly professional jobs don't have this as HR tend to go down on them like a ton of bricks.
And again, stop with the assuming.
@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.
@misadventure said in Mush Online Training:
You can start it as an online discussion if that seems helpful.
However, it would do best as a web page or wiki. Documentation is there when you need it.
You know, this gets me thinking.
There are people who have made interactive on-line tutorials for python, ruby, bash/shell scripting, php, html, and various other languages.
Why couldn't we do something similar with mush code?
I am absolute crap at web design, but for those of you who are experienced at it, what do you think it'd take to do something like that?
Do you think it would be worthwhile?
I obviously don't want people to invest time if it'll never be used.
@thatguythere said in Mush Online Training:
I think to social part would be hard to teach since there is no one set standard.
Oh, I fully agree on this. It's a quagmire and why I stated it's different for each person and each environment you play on.
It's why I stressed it's good to just touch on things you found not to do. No set examples, but overall generalizations.
Things that for us would be no brainers like mass-mailing people when you're disgruntled hate-mail could be covered and consequences of those actions. Things that can be applicable to most situations, and not nitch-groups is what I'm looking for if that helps clarify?
@nemesis said in Mush Online Training:
Yes, I know there's online tutorials. But having classroom based learning is always a better way to pass on knowledge as it can do some question and answer sessions not available by page-flipping.
I also have a ton of helpful links at the end of my what to do when your mush is attacked link.
Ok peeps.
This is my suggestion. We hold classes on how to mush.
This will include passing knowledge of coding for those specific 'classes' and for learning how to socially interact with others in a mush medium. This would include social and RP mushes.
Coding is a no-brainer. We would talk about both softcoding on a mush and hardcoding on a mush. Those of us who are experienced will talk about things to watch out for on advanced systems. For those who are active with Evennia or AresMUSH we could do similar. While I know python and ruby I don't know either codebase well enough to talk about coding for those, so others will have to take over that spot. But then that's why I'm reaching out to you all
Now, I want to specifically touch on the social interaction. This is a very dangerous kettle of fish as each person has their own style and each mush has their own needs.
So my thoughts on social interaction is a study on what not to do over what to do.
Basically pass on all the faux paus and mistakes we've all been through. Things not to do. Like when you went too far in administering a game and chased people off. Or those times you wish you put your foot down harder than you did. Basically have a course on what you learned with 20/20 hindsight so others can learn from our mistakes.
Because I think if we instill into people what not to do. Finding what they can do will be all the more easy and enjoyable for them.
I think having scheduled training sessions on a central calendar where people can show up would also help bring in new people. One of the biggest things for new people is the steep learning curve, so let's combat that.
Thoughts?
Edit:
Because it honestly was such a great idea, I quoted @apos post here:
@ashen-shugar I personally might further divide it up into useful sub topics for social like, "How do you get involved in stories", "How do you handle conflicts you find oocly frustrating", "What are the differences between MU RP and other rp formats", etc. That might keep people's input more focused.
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.
