Posts made by Alzie

@griatch said in A directory of MU*'s that's actually good:

Evennia (and, I presume, Ares) use a custom in-built protocol for our game-lists. There is however also an "established" mud standard for this. It's called Mud Server Status Protocol MSSP and works so that the listing website regularly connects (over telnet) to the game and retrieves the data. Evennia does support this but I don't know if any of our devs ever bothered to register with a site that uses it. Not sure if the traditional mush servers have support for MSSP but it's common in traditional MUDs since KaViR's C code snippet supports it.
.
Griatch

I used evennia for my Fading Suns game and it worked fine on mudconnect using MSSP.

For further discussion, my side of the internet was having this discussion back in 2003:

http://www.mudconnect.com/SMF/index.php?topic=78156.0

TLDR: We need to change the way that data is sent since every codebase was written to depend on one line at a time output, but no one actually wants to do that.

At least for this thread, it sounds like @Griatch and @faraday are trying to do that.

@surreality I am going to actually start a game this year...Maybe...Hopefully. I will try.

@griatch said in The Death Of Telnet: Is It Time To Face The Music?:

tintin++ client which will interpret the semi-colon ; as a new client command

Except that has nothing to do with telnet and everything to do with a decision that the developer of Tintin++ made.

@faraday said in The Death Of Telnet: Is It Time To Face The Music?:

• A GUI, so I don't have to remember/type obscure command-line syntaxes just to do everyday stuff.

So a better Mu client, which has nothing to do with telnet.

• Standard text formatting like bold and italics and links.

That can be done easily.

• To edit a pose after I've posed it, like you can in any other forum or text chat program.

You have the same problems here with telnet that you do with any other platform really. Though certainly those problems will be easier to overcome without telnet.

• Graphics embedded in descs and character profiles.

Already have graphics over telnet.

• An integrated MUSH and wiki so you don't have to update your wiki page when in-game data changes.

Nothing to do with telnet. Based on how you design your data layer.

• To configure a game without /grabbing attributes in obscure formats off of obscure objects.

Design decision.

• To code in a normal programming language, not line-by-line interpreted commands pasted into a telnet client.

Again, design decision.

• To play with a decent experience from a web browser, when I'm not at my normal computer.

Nothing to do with telnet.

This is really my problem any time this comes up. All of these things get listed and telnet gets blamed for them, but none of them have anything to do with telnet. Would it perhaps be easier to fix these things if you don't have to account for telnet? Sure. Of course it would.

I'm not saying that we need to keep telnet, but what I am saying is stop saying that telnet is the only reason we can't have these things. You know that's not true. If we want these things, we can do them now without erasing telnet. Would it require more work? Possibly.

Edit: As an actual productive suggestion, since that will be the next question posed, We could accomplish 90% of these things if we made a new mu client that wasn't from 1995. @Sparks has helped with a lot of this already with atlantis being modern, but not all platforms have a semi-decent modern client. Potato, even, was written in TCL and the interface definitely shows it.

@surreality The loudest ones usually don't understand what you're doing anyways, but it's certainly not conducive to any of the developers 'give a fuck' rating if everyone keeps telling us how little they want it. Hope the project goes well.

Regarding this talk of the next version of Mu, however, what do you want out of the interface? Everyone keeps clamoring for the removal of telnet. Fine, but you're just replacing that with something else. If not telnet, it will be some other form of server-client communication. Maybe you do that through HTTP Requests, Maybe you make your own protocol (Relevant XKCD), Maybe you do it by email, Maybe you do it by wikis or forums or Maybe you just decide to do it by database queries (Relevant XKCD).

We're all talking about eliminating the data source, but that has nothing to do with the interface. People wanted HTML in Telnet, so pueblo exists. People wanted sound in Telnet, so we came up with ways to do that (IRC used a protocol command, Muds had MSP). People wanted really involved GUIs with Graphics and what not, so they made entire GUI Clients (see Batmud Client, or the many plugins for Mushclient that create GUIs for games).

So we change to another data source, the popular idea so far seeming to be a database backed RESTful front end, but what do you actually want out of that interface? What should it do differently? It's still only going to have text to display to you. How should the text look differently? Yeah, we can do some better things with CG that way, but we could do the same things with telnet and pueblo.

I'm not the old man on the corner telling everyone not to advance, but maybe we should actually talk about what we want out of the advancement? At least a semi-clear goal.

@cobaltasaurus I see you took that one out of the code bucket. You should definitely list merits that have RP connotations as people like to list those anyways.

As someone who is constantly pushing the automation/no-automation line, I'll give you my experience @Ganymede - though you didn't ask for it.

RFK was probably the most ridiculous example of automation I can point to. I would wager that it could stand up to Firan by the shear amount of automation it contained. There was automation that people never saw. There was automation that other staff never saw. There was automation being done on a google calendar to place territory crisis in their dates and send notifications to staffers. RFK was a clusterfuck to code for, but interacting with RFK was made as easy as possible since pretty much everything was automatic.

On the other hand, RFK was a clusterfuck. It didn't toe the line between automation and staff interaction, it obliterated it and put a sign over the grave. This was a point of contention. Either you really liked this feature or you took one step on the game, found that even the guest character was assaulted with a myriad of automated systems and ran the fuck away.

This is a line I find that I toe a lot. I'm heavily on the side of automation. At some point, we gotta admit that we can't do this manually for a myriad of reasons. On the other hand, there are those that don't like the automation. I see both sides. The more we automate, the less we know what players are doing. Knowing what players are doing is at least thirty percent of staffing in this hobby, so certainly any time you remove a tool that people use to know their players there is an understandable amount of discomfort.

There's always this line between don't automate too much and automate this more. This is going to be one of the biggest discussions moving forward really. Moving forward and modernizing the Mu* world is going to be talking about automation. You can make the UI better, you can add a web interface, you can change the underlying architecture and all these things are a good change, but until we change the way we look at the game then we'll still just be going through a bunch of commands in a different client to do a single, simple thing.

That's why Web Based CG is such a big deal. That's a ton of commands taken away from players and staff, but put into an easily understood and condensed form. The player doesn't care what it looks like behind the scenes, just that it does what they put in. Staff doesn't care how the system makes the players, they just care that it does.

TLDR (For the rest of you): Ya'll need to embrace chrons/events/timers.

@ganymede said in Alternative Formats to MU:

@alzie said in Alternative Formats to MU:

The only place that this template method would fail is with CGs with special constraints, such as NWOD and Specialties, but like you said, you can't be everything to everyone and at some point if you're trying to be universal, you have to lose out on some features.

Specialties, Gifts, Rituals, Devotions, Threnodies ...

Gifts, Rituals and Devotions are pre-defined spots on a sheet. They don't require the extra work that specialties do (Being attached to a skill, Customized to what a player inputs). Threnodies could even be attached to a player sheet really, though they'd be harder to do since they have multiple moving parts.

Really, since I had to come back and think about this, it would be fairly easy to attach specialties to players and a specific skill. So you wouldn't even really lose out on specialties. I suppose if you worked hard enough, you could do that with threnodies, maybe.

The problem there would be having a CG template that could understand advanced command definitions and that's a different sort of problem. Maybe have it read columns from the table?

@faraday said in Alternative Formats to MU:

Just a trivial example, let's say you want to have "Race" as a new chargen field for your space-game-with-aliens. With either telnet-only or web-only you'd only need to touch two things: the command/screen to set it, and the one to display it. But when you try to support both, you now need to have the telnet command to set it, the telnet command to display it, the web screen to set it, the web screen to display it AND the Rest API to allow it to be set via web. And help files for all of that. And oh-by-the-way they're in different languages, because web uses Javascript/HTML and the backend uses Ruby.

I mean, this is a design issue. It's an easily solved design issue too. You can easily template out CG.
The only place that this template method would fail is with CGs with special constraints, such as NWOD and Specialties, but like you said, you can't be everything to everyone and at some point if you're trying to be universal, you have to lose out on some features.

@arkandel If we're talking about travel specifically, My personal opinion is that no game needs a grid. It's an expected feature of a game, but the reality is that nobody actually RPs in 90% of the rooms most games have. The reality is that you could open a game with a clear theme and maybe 10 important, constantly used locations alongside a coded RP Room creation wing and it would work just as well.

The problem is that if you do this, people will stare at you like you're fucking nuts.

@lotherio said in Alternative Formats to MU:

I mean, honestly, wasn't that the entire point of going from MUD to Mux to MUSH to whatever, more players could softcode while playing inside the box to accommodate whatever system was floating their boat that day?

No.

Mud -> Mush:

• Removal of the imposed security settings from the server (Muds actually have a strict role based permission hierarchy built in)
• Allow anyone to alter the game by adding objects or rooms (Because of the hierarchy, only people with a specific permission level or higher can alter the game on muds)
• You may think the internal scripting language was a reason, but mud's already had that. It was the first two.

Mush -> Mux:

• Mux is Mush
• The only real differences here are in how the platform reacts to players and how softcode evaluates booleans

@roz said in Alternative Formats to MU:

When I've been using it, I have indeed been speaking about the specific carrier protocol, which is one of the things limiting development.

To preface this, Roz certainly isn't the only one so far to have this sentiment, but Roz is the quote on this page.

Telnet, the protocol, is only as limiting as you make it. The telnet protocol, itself, only governs connecting to a server, sending data between you and this server, then disconnecting. What that data is, how the server responds to it and what rules govern your communication with the server are outside the scope of the telnet protocol. The telnet protocol is a communications protocol that governs a connection and transmission procession with another client.

I think there's a confusion here that if we allow backwards compatibility with telnet it's an all or nothing agreement. This isn't true. You could allow a telnet client to connect and make the same commands people have always been used to, but also provide a web client that runs off a restful API. These things are not mutually exclusive.

@lotherio I think you're possibly the only person i've met that likes the Mush Lisp-like language.

I only buy PDFs. Which pretty much limits me to drivethrurpg. I'm the kind of guy that likes to search things. I dislike obtaining them from other sources because they're usually scans and that means I have to spend 30 minutes - a couple hours OCRing them into searchable text. Even then, it's not the greatest result.

On the other hand, my reliance on PDF books means that some of the older companies (Cough Warhammer Cough) are slow to push their books out to PDF. And that when they do, they aren't chaptered or OCRed or have shitty indexes or TOCs. Etc. All kinds of issues. Because the PDF was an afterthought.

I mean, look, I want a PDF because I want to find shit in the book faster. I don't want to spend 25 minutes thumbing through pages, scanning them for a thing. IF I did, I would buy the hardcover/paperback.

@arkandel Well, there was Viaduct, but I absolutely never finished it.

@Thenomain and @surreality I tried to do mush in a box with docker, but I found that some of the codebases react strangely when you put them in a virtual environment. I was never able to figure out why, exactly. Rhost and Penn were fine. Mux wouldn't resolve paths, for some reason. I'm not sure what it was trying to use to resolve its paths or what it was adding to it. I never tried Ares or Evennia, but I imagine Evennia and Ares would work just fine being Python and Ruby.

@faraday All evidence to the contrary given that RFK's web interface was widely popular even in its half finished stage.

I feel like we always bring up this web interface discussion and some people always say 'No one will ever do that,' but the evidence is that people will in fact be perfectly happy using a web interface when a good one is available.

@scarbearer Could use a builder. I got 2 staffers for admin things. Still working on the code side. Not in too much of a hurry.

@bored said in [L5R] Giri - Now Hiring:

@alzie

They've already posted several updates that made pretty major changes, so there's every reason to believe they will keep doing that. The rules that exist in a month, several, or whenever it actually hits print could be pretty different.

I'm actually already using the 2.0 Beta version rules.

@bored said in [L5R] Giri - Now Hiring:

For instance, there's a lot of discussion about the skill groups not being very well designed right now, as certain areas are over-represented (the Artisan group) while many of what people consider pretty fundamental skills are not included or sufficiently differentiated (no Ride skill, somewhat odd perception rules in the newest update, etc). So I don't think you can assume even those lists are finalized.

Ride is listed as a subskill of Survival on p.106 in the 2.0 beta rules. So it goes under the Trade Group and Survival Skill. Though I understand some people want it to be an independent skill.

Pretty much every discussion about the skill system I see though is only about there being no specific skill to roll to examine a room. Yet, there's absolutely nothing stopping people from adding the skill to their campaigns. Scholar already has the appropriate approachs for it and Water has already been noted as the ring used for investigations.

There's a lot of flexibility here and it's radically different compared to 4e for sure. It's gonna take some getting used to, but the difference between 4e's giant list of skills and 5e's broad approach based skill system isn't a reason to not open a game. I actually like the 5e way better due to the amount of GM customization it allows and the fact that the approach system forces players to think about their RP.

@bored Are there particular reasons you have issues with the beta rules on a mu? I've read the beta PDF. There are 5 rings, 5 skill groups and GM/Player defined specialties. The roller is going to have to be a mix of automation and player agency, but I don't see that being a reason to not have a MU. I've seen no major mechanic that would stop a Mu from working in the vein of say TBZ's time mechanic. Even converting the down time system is doable.