Better Places Code
-
Before the other thread veered off into places code (especially since @ixokai and @Thenomain deleted their posts before I could quote them :)), this is something I've been contemplating for awhile.
I hate the old-school places code, and I know I'm not alone because I've literally not seen anyone use it since the late 90's. Things I hate:
- Using 'tt' to pose everything just pisses me off (and half the time I forget to do it)
- Two people are having a fierce argument at the other table but you can't see it because they're all using table-talk. So something that you should be reacting to ICly is either missed, or requires them to double-pose "Bob and Joe argue" to the main room.
- Having "Round Table" "Small Table" and "Square Table" with arbitrary space limits and nonsense like that is a pain to configure when you're building.
- Don't even get me started on the clunkiness of moving chairs from one table to another.
- Phantom people left behind when they log off / leave. The auto-clear code never worked right on any MUSH I was on.
But the idea of being able to have smaller scenes in a big room is a useful one. It's just the execution that kinda sucks.
For AresMUSH I basically have a clean slate, so it makes me wonder... how can we do this better? Make it more useful and dynamic? I have some ideas but I'd like to hear from the gallery.
-
Hey, I re-created places from scratch for The Reach.
https://github.com/thenomain/Mu--Support-Systems/blob/master/places.txt
I re-implemented the classic Places, but made it based upon a function. And orderly. And everything goes through a single command. And easy to add to a location. And easy to have locations with infinite seats (set as '0'). And fixed clearing people out. And even made it check the entire game for other places they may be logically connected to and remove them from there if they join another place in another room.
The one thing that I want to add is the ability to have 'groups', an idea that came from ... well, I'm not reading my own code, but I think it was Metro? or LA? It was recommended to me from someone long ago on Haunted Memories.
Some games used to use 'mutter' code to leak bits of what's said to the room.
I've played with the idea of parsing anything that is not inside double-quotes ("...") as poses to the rest of the room.
Staff need to be able to monitor a place without taking up a 'place'. Monitoring code needs to exist in general, and is one of the many, many, many reasons I made it function-based.
It's also made making your own room-parent-output for places very easy.
I can't think of a character shortcut that I'd use for places. the backtick (`) is occasionally used for 'ooc' chatter. That should be implemented more. edit: It looks like I use the pipe (|) for emitting to the place.
I suppose you could hook into the pose code, tho fair warning, posebreak already does that.
Posebreak must parse in places code.
That's my napkin-list for now.
-
I just want +places like Schmitt did them on Second Pass. It didn't hide poses from other people in the room, but it color-coordinated a start to your pose so that people could easily see who was posing in their particular area. And anyone could set up a +place with no hassle. While it did require a change in what you posed, the + to start whatever you'd normally use to pose was simple enough. No chairs/number of seats, just join and leave an area and be done with it.
It was my first introduction to any sort of places code, and I was super confused when I came across what I guess is the more classic, traditional version, because it seemed so strange and difficult and unwieldy to me.
-
@Thenomain said in Better Places Code:
The one thing that I want to add is the ability to have 'groups', an idea that came from ... well, I'm not reading my own code, but I think it was Metro? or LA? It was recommended to me from someone long ago on Haunted Memories.
I am the one who coded LA's "clusters" code, which were backwards compatible with the historical places, but supplanted them. A pre-specified "place" was just a special case of a cluster, which was any grouping of people.
You "join x", and if x is in a cluster, you're added to their cluster. If they are not, a new one is made. "tt" speaks to your current cluster. If you leave the room or "depart" you are removed from the cluster. It worked fairly seamlessly.
( This also fully supported both spying (ie, someone obfuscated joining a cluster) and detecting a spy (dude with more auspex sees you join) )
All that said, I'm never implementing it again (not that it was super complicated or anything) and I probably won't ever use it if anyone installs it on a game. I just... don't want to. I think rooms are the nice, ideal, perfect granularity of defining a scene, in my opinion. If there's certain scenes temporarily "owning" a location issues? Easily solved with TP/RP rooms. (These should have a way to flag as temporarily public)
And I just don't want to tt |foo all the time. Emitting is ingrained in my fingers now, and I can remember how many times I messed up and emit out of a tt when I didn't mean to. Not to mention the abstraction of these perfect little private bubbles inside a larger room doesn't make sense to me.
I like RPing in rooms.
But you guys who want to, go ahead. All power to you
-
A few places in the 90s were running mutter combined with places, so everyone in the room got snippets from conversations that way. How come that wasn't continued.
I enjoy places code because its easer to have 5-10 people in a location without it a mess of mismatched conversations of non-relevance.
I'm just a surge protector doing my job, sir.
-
@Lotherio said in Better Places Code:
A few places in the 90s were running mutter combined with places, so everyone in the room got snippets from conversations that way. How come that wasn't continued.
I hated that too, because the code would use randomness to determine what's overhead, and while it was sometimes funny, it simply had no basis in reality. Its as likely to out something whispered as yelled.
-
@ixokai said in Better Places Code:
But you guys who want to, go ahead. All power to you
So ... thanks?
I just... don't want to.
Then ... don't. I honestly don't know why you're posting.
I think rooms are the nice, ideal, perfect granularity of defining a scene, in my opinion.
The reason table systems were more widely implemented in the first place was because people on the balcony were spamming their scene to those in the ballroom or people who were trying to have a nice, quiet conversation on the elegant seats closest to the closed room that they know a murder is currently taking place and they are the lookout.
Not all of us want to shove these into one location, and I for one don't want to make the balcony a separate room, nor do I think it's appropriate for it to be a temproom. Making exits opaque or asking everyone to remember that there is such a thing as a transparent exit adds to the complexity of role-play, not simplifies nor enhances it.
edit:
@Lotherio said in Better Places Code:
How come that wasn't continued.
Because after the late 90s/early 00s, we pulled back from the idea that everything needed coded. We no longer have language code, either. Then the number of coders whom existed went down to a small handful, so the less that needed coded the more a game can accomplish.
-
@ixokai The cluster idea is similar to what I was thinking. If poses and emits were automatically color-coded with the regular pose/emit commands, and all it did was change the color (or add a prefix or something) it would probably be pretty low-hassle.
On BSP the space code did emits kinda like that:
[RAPTOR_108: Trajan] Trajan's raptor is consumed by a brilliant flash of light. Only empy space remains.
[RAPTOR_216: Sunny] 216 turns into formation of a triangle as the three Raptors make their way and the countdown begins. The time for butterflies and jitters are pushed aside, this one is all or nothing. A fold in space begins as Sunny follows in tandem with 108 and the bright flash of light is all that is seen, then they are gone from sight.
I dislike mutter code but it's just a peeve. I prefer transparency, especially for the monitoring and logging reasons others have mentioned.
-
@ixokai said in Better Places Code:
@Lotherio said in Better Places Code:
A few places in the 90s were running mutter combined with places, so everyone in the room got snippets from conversations that way. How come that wasn't continued.
I hated that too, because the code would use randomness to determine what's overhead, and while it was sometimes funny, it simply had no basis in reality. Its as likely to out something whispered as yelled.
To me it came out like this: https://www.youtube.com/watch?v=Vt4Dfa4fOEY
I liked it because honestly if you're half listening to another conversation, you don't control what you hear, but you pick up on certain words your ears are familiar with. The frustrating part is if you wanted something good to be overheard like 'positive ..... she's pregnant ... unwanted ...' but you get something stupid like 'she is .... again ... not that ...'
It was more an issue when someone at a place wanted to get attention from someone outside the place ... then the could just emit to the room instead of trying mutter or muttered places.
I'm just a surge protector doing my job, sir.
-
Any implementation of places must be:
-
Accepted by the community. This has to be mentioned separately since it's the hardest part; you can make perfect code and it'd still fail if people don't use it because they've never used it before so it's not part of their established habits.
-
Its primal function MUST be to reduce spam for EVERYONE, not just those using it. That's half the point of this entire operation - if having 8 people in a room is spammy as hell you've lost me. If the scene has 8 people and me and two friends are in a +place but we get the spam total of 8 (3 for our own poses, 5 for the 'unplaced' players) then who cares?
-
Easy to use. If it requires more than two commands total - the equivalent of @emit and say, for instance, and/or perhaps lacking a convenient easily memorable alias it can still fail.
-
Allow for easy switching between addressing the room at large and your +place. You might want to leak some things or maybe not, but you should be able to at will. Notice how this can easily conflict with (2); such is the way of things.
-
-
@faraday said in Better Places Code:
I dislike mutter code but it's just a peeve. I prefer transparency, especially for the monitoring and logging reasons others have mentioned.
Transparency is easier to code, too.
Clusters are a must.
Option to make all places look like their own in-locaton channel system seems alright. I would probably opt to keep it more quiet.
@Arkandel said in Better Places Code:
- Its primal function MUST be to reduce spam for EVERYONE
Disagreed. Its prime function is to create an in-game logical separation within a physical play-space. Reducing spam is a high priority, but we already have a few commands that reduce spam: Page and @Emit for two.
And you know how much I hate spam.
-
@Thenomain said in Better Places Code:
@ixokai said in Better Places Code:
But you guys who want to, go ahead. All power to you
So ... thanks?
I just... don't want to.
Then ... don't. I honestly don't know why you're posting.
Because I was trying to share insights with what I did when I /did/ get asked to code a wannabe-next-generation places replacement. I can just not if you prefer.
-
@Lotherio said in Better Places Code:
The frustrating part is if you wanted something good to be overheard like 'positive ..... she's pregnant ... unwanted ...' but you get something stupid like 'she is .... again ... not that ...'
That is the main reason why I hate it. If I can see the original pose:
Joe gapes, "Wait, what? She's HERE?!" He realizes he said that a little too loudly and lowers his voice. "I thought she wasn't coming until Tuesday?"
I can choose appropriately how to react to it, instead of relying on some code to give me "Wait... she... Tuesday".
Also as a compulsive logger, it's a PITA when you've got someone taking the log for a group scene and they don't get the whole pose.
-
I'm not going to give you permission or not to opine, but your post was entirely "I don't code it nor use it", which doesn't answer the original question: How can we make it better.
Unless your answer is: Dump it. In which case I engaged with this by explaining why I don't think it's worth dumping. I'm challenging your notion, so we can come to better understanding on what works, what doesn't, and how to improve both.
(note: I have a gigantic peeve when people tell me that I'm allowed to do something they think is stupid. Eatabagofdicks.)
-
@Thenomain said in Better Places Code:
@Arkandel said in Better Places Code:
- Its primal function MUST be to reduce spam for EVERYONE
Disagreed. Its prime function is to create an in-game logical separation within a physical play-space. Reducing spam is a high priority, but we already have a few commands that reduce spam: Page and @Emit for two.
And you know how much I hate spam.
Although I made the disclaimer about the primary reason for this you are technically correct, which I am loathe to conceit is the best kind of correct.
There are primary two issues with large scenes:
-
They are too spammy.
-
Pose order becomes tricky even for characters who aren't interacting with each other at the time.
There are additional issues people have brought up here - such as logging this stuff somehow, which is a huge pain in the ass if we consider privacy as a goal at all for +places, and how to allow things to best leak into the 'general' scene, but IMHO we need a good approach for those larger issues at a minimum.
- He who takes offense when not intended is a fool. He who takes offense when intended is a greater fool.
-
@Arkandel I was less concerned with cutting spam than I was with organizing the spam, to make it easier to pick out the bits that are relevant to you.
But to your point... would it help if there was a consistent pattern? For example, stuff in your own place is always prefixed with
^^^^ PlaceNameand stuff in other places is always prefixed with**** OtherPlaceName? Then you could configure your MUSH client to filter out crap in other places if you didn't care, or chuck it into a spawn window or something?(The prefixes are just brainstorm-y examples; don't get hung up on them :))
-
@faraday For me it would help at least. I'm not sure if that's the same for everyone, since not everyone uses a telnet client with spawn capabilities (the fools).
-
This post is deleted! -
@faraday said in Better Places Code:
@ixokai The cluster idea is similar to what I was thinking. If poses and emits were automatically color-coded with the regular pose/emit commands, and all it did was change the color (or add a prefix or something) it would probably be pretty low-hassle.
I'd be careful of using color, because what people like and dislike in color is so variable and up to personal preferences. The prefix thing I wouldn't hate (and the prefix can be color coded, I mean we tolerate channel names having colored text).
On BSP the space code did emits kinda like that:
[RAPTOR_108: Trajan] Trajan's raptor is consumed by a brilliant flash of light. Only empy space remains.[RAPTOR_216: Sunny] 216 turns into formation of a triangle as the three Raptors make their way and the countdown begins. The time for butterflies and jitters are pushed aside, this one is all or nothing. A fold in space begins as Sunny follows in tandem with 108 and the bright flash of light is all that is seen, then they are gone from sight.
Yeah, that's not so bad. But does it actually improve anything? The scene will still be spammy and hard to follow if its got a bunch of people in it. And if it doesn't make the scene less spammy, you're going to end up with these little magic perfect bubbles of privacy in a room with crickets between them. Unless you add in mutter. (shudder)
I dislike mutter code but it's just a peeve. I prefer transparency, especially for the monitoring and logging reasons others have mentioned.
Agreed.
@Thenomain said in Better Places Code:
I'm not going to give you permission or not to opine, but your post was entirely "I don't code it nor use it", which doesn't answer the original question: How can we make it better.
You're forgetting to read what came before "I don't want to code it or use it", and I can't tell anymore if you're doing it on purpose just because or if you missed it.
I said I coded LA's clusters code, and explained how it worked (and its features are what I'd consider the bare minimum of a places system). To say in more general terms and use more words then I think are strictly nessecary but since you couldn't really get it out of the original post:
The 'place' as the unit of players talking is one we didn't like for all kinds of reasons, for one requiring them to be established before hand, for two their fundamental limits of the model (what places exist on a football field?). So we ditched that but kept some backwards compatible support for using pre-defined places if someone could be bothered to put them in a room.
The real abstraction we called a cluster, and defined it as basically an arbitrary group of players who self-determine if they're in, or not in, a given cluster. Cleanly exiting (either by moving to another room, joining another cluster(WITHOUT having to depart, I should have mentioned in my first response), or via 'depart') is as important as cleanly joining (either by join # or join person: if person is sitting at a 'place' named Table, then 'join person' should be functionally identical to 'join 1').
Supporting being in a place secretly, and detecting spies, should be general enough but able to hook into a random RPG system.
If you can manage to make it easy enough to talk into a place without significantly changing the UI of talking on the mush, I'd call it a miracle, but I'm not holding my breath. I find getting tt | right to be painful. But no one could think of a better idea that worked with the mush on LA.
That's what we had on LA for solving the place problem.
I'm still betting on: you can't make it better. You're reinventing rooms.
-
@ixokai, my thought on it has been addressed already:
@Arkandel said in Better Places Code:
Any implementation of places must be:
- Easy to use. If it requires more than two commands total - the equivalent of @emit and say, for instance, and/or perhaps lacking a convenient easily memorable alias it can still fail.
Rooms are not useful for cases where the separation between scenes is not black-and-white. To me it's like saying, "Who needs folders? Just create another partition." Because the logical relation between two sets of files is important, and I don't need to go through all the work to set up and all the peculiarities to make them either partially or or not-at-all logically connected.
Or in other terms: A place is something that is logically connected to things around it. A room is something that is logically separated from things around it.
It's no more re-inventing rooms than phone code is re-inventing page. (And I haaaaate phone code, yet a huge number of people demand that I add it whenever I'm around. Stupid phone code. Rar.)
I agree about channel-izing places, tho. I do think a large point of places code is to reduce spam, and once people culturally start using it to react to things at other tables, the option to opt-out is removed from you.
