12 Aug, 2013, Zeno wrote in the 21st comment:
Votes: 0
Davion said:
Idealiad said:
Nice work plamzi, looks like a good start. Are you aware of Orrin's http://mudgamers.com/ site? It was/is an attempt at what you have here. I don't think he advertised it very much though.


I don't think the 2 are quite the same. This webapp is revolutionary. Plamzi is basically allowing all other MUDs to use the same webapp Bedlam uses. This app is amazing. This is a true modernization of the client. Wait till people can go beyond status bars. Really amazing Plamzi!


I just tried the site out, but the web app didn't seem like very much? What am I missing?
12 Aug, 2013, plamzi wrote in the 22nd comment:
Votes: 0
Zeno said:
I just tried the site out, but the web app didn't seem like very much? What am I missing?


It's only been 3 days, and the road is long :) First, I have to get close to here. Then, I have to keep going.

Some things would probably not even be possible for a generic web app. But I'm hoping that the result will be differently awesome at some point:

Imagine that you could log into a game for the first time, and immediately see modules like health bars, chat and group panels created by others, or a vector-based overhead map generated by the explorations of other players before you. Imagine that players and admins of games can create and submit such modules, leveraging GMCP, MSSP, or just regexes, and those modules would immediately become available to any and all players using the web app. Imagine not ever having to worry about porting your advanced scripts/triggers/aliases from one computer to another. or about not being to install your favorite MUD client on some system. Imagine that your gaming activities are tied with those of others on other games, creating a social gameplay experience even if the game you're playing does not have a wide player base.

As a MUD admin, imagine that you only have to list your game to get a sophisticated, newbie-friendly web app pointed at it, and tools to promote it on a modern-looking portal.
12 Aug, 2013, Zeno wrote in the 23rd comment:
Votes: 0
In this modern age, that makes complete sense. But how do you plan to handle the differences in all the MUD types out there and parsing HP formats, etc?
12 Aug, 2013, plamzi wrote in the 24th comment:
Votes: 0
Zeno said:
In this modern age, that makes complete sense. But how do you plan to handle the differences in all the MUD types out there and parsing HP formats, etc?


The same way that a desktop app does, only better :) Using the plugin model, with everything hosted in the cloud.

For example, I already have two health bar modules. One is a minimal one positioned under the input box, the other is graphical. These modules can have public methods for initialization and updates.

We then leave it to players / developers of a given game to supply the code (JS) needed to drive a given module. The app already supports GMCP, e. g., that they can parse, or can supply hooks for regex parsing if needed. Technically speaking, we just have to include a JS file editable by the end user on the web app page in order to provide them with the most flexible API any desktop MUD client has ever had.

When a plugin for a given game is published, the web app will know to offer it to other users connecting to the same game. So, games with interest in leveraging the portal app will offer an increasingly customized experience to their players.
12 Aug, 2013, Ateraan wrote in the 25th comment:
Votes: 0
plamzi said:
The recent drama surrounding TMC has prompted me to start practicing what I've been preaching for a while. Namely, that we need a modern gateway site with a solid web-based client that will lower the bar for new players. And it would appear that we also need a good forum site for existing mudders (even if TMC does come back).

Introducing http://www.mudportal.com.


Very nicely created. I like it alot. And thanks for putting Ateraan on there!
12 Aug, 2013, plamzi wrote in the 26th comment:
Votes: 0
Ateraan said:
Very nicely created. I like it alot. And thanks for putting Ateraan on there!


You're welcome. But you need to allow receiving PM msgs if you want a reply to yours :)
13 Aug, 2013, Ateraan wrote in the 27th comment:
Votes: 0
plamzi said:
Ateraan said:
Very nicely created. I like it alot. And thanks for putting Ateraan on there!


You're welcome. But you need to allow receiving PM msgs if you want a reply to yours :)


Oops, didn't notice that option. :redface:
13 Aug, 2013, Runter wrote in the 28th comment:
Votes: 0
Does this suffer from the same limitations as other proxy software? I'm assuming it does with what I'm about to say.

1. All of the data is going through Plamzi's server. This is also a vector of attack by someone who is able to compromise Plamzi. We have no way of knowing the security level of Plamzi's server, if data is logged, etc.

2. Loads of users from the same IP(s).

3. Additional latency. This depends on the geographical location of the proxy, the mud, and the user.

4. Running untrusted javascript is a bad idea. In other words, running code from Plamzi on Plamzi's site may be fine, but running code from Locke on Plamzi's site is another story.

Please be aware of these when making your decision. There's differences here other than just native mud client, or in the web browser.

Plamzi, If I got some of this wrong please do correct me.
13 Aug, 2013, quixadhal wrote in the 29th comment:
Votes: 0
Runter said:
4. Running untrusted javascript is a bad idea. In other words, running code from Plamzi on Plamzi's site may be fine, but running code from Locke on Plamzi's site is another story.


ROFLMAO…. "Ever since I started using Planzi's cool new web client, my OLC seems to be disabled???"
13 Aug, 2013, Scandum wrote in the 30th comment:
Votes: 0
Runter said:
2. Loads of users from the same IP(s).

MTTS suggests a solution: http://tintin.sourceforge.net/mtts

The MUD can cycle through the client's terminal types and read out the MTTS terminal type which contains a bitvector indicating if the client is a proxy client. Next the server can request the IPADDRESS value through NEW-ENVIRON which a MTTS supporting proxy should support.

Perhaps not the ideal way to go about it, but it works. You can also detect Windows telnet using NEW-ENVIRON while you're at it.
13 Aug, 2013, plamzi wrote in the 31st comment:
Votes: 0
Runter said:
Does this suffer from the same limitations as other proxy software? I'm assuming it does with what I'm about to say.


This is good stuff. Will stick it in a FAQ at some point.

Runter said:
1. All of the data is going through Plamzi's server. This is also a vector of attack by someone who is able to compromise Plamzi. We have no way of knowing the security level of Plamzi's server, if data is logged, etc.


True. Your options:

A. Let me worry about the site security, realizing the worst that can happen is one of your game clients can go down for a while. Trust me that I won't be snooping your players and (I guess) stealing any credit card info they may type while playing. In exchange, you get free exposure and a web app you don't have to manage.

B. You already have the option of configuring your portal "play" buttons to take users directly to your own web app, or if you insist, a page with installable clients. (However, that won't stop someone else from listing your game or pointing the portal app to it.)

C. If you run your own websocket proxy, the web app can be pointed directly to it, easily.

D. You can, at any given point, rip off the portal app code and host it locally on your web server. I'll make sure the core modules have the appropriate licensing to allow that.

Runter said:
2. Loads of users from the same IP(s).


The proxy is already configured to send the IP via ATCP/GMCP. I can easily add MSDP or even TTYPE methods of sending the user IP. If there's still a concern, see some of the options above.

Runter said:
3. Additional latency. This depends on the geographical location of the proxy, the mud, and the user.


Based on some experience, my guess is latency won't be an issue in most cases. In a typical setup, latency will be greater than that of a software app, but if it is only by a little bit, even advanced users of clients like Mudlet and MUSHClient may come to see the web app as a viable alternative.

More importantly, think of the web app as a discovery tool for non-mudding gamers. They're not going to compare the latency to that of a desktop MUD client. If they can play your game normally via the portal, they can get hooked.

Runter said:
4. Running untrusted javascript is a bad idea. In other words, running code from Plamzi on Plamzi's site may be fine, but running code from Locke on Plamzi's site is another story.


The user-modifiable javascript will all be running on the client-side (not, e. g. as part of a node.js app). There is no such thing as trusted client-side code.

I will of course be taking the normal security measures with any code running server-side.
13 Aug, 2013, Kelvin wrote in the 32nd comment:
Votes: 0
To be fair, most of us are playing these MUDs through un-encrypted telnet. I understand people pointing out some security concerns, but let's be real: Most of you are already hideously insecure (telnet users), and are foolish to send anything like credit card #'s or username/passwords you use for important stuff over the line.
13 Aug, 2013, Tijer wrote in the 33rd comment:
Votes: 0
one thing i will say is the web app needs to report peoples proper ips, because otherwise you will have what used to happen with the mudconnector telnet client.. where you'd end up with people using that to circumvent site bans…
13 Aug, 2013, KaVir wrote in the 34th comment:
Votes: 0
Zeno said:
In this modern age, that makes complete sense. But how do you plan to handle the differences in all the MUD types out there and parsing HP formats, etc?

My MSDP snippet supports something similar - it defines 5 buttons (each with a name and command) and 5 gauges (each with a name, colour, current value and maximum value), the idea being that it could be customised by each mud and utilised by any GUI plugin or script that supports either MSDP or ATCP. There are quite a few muds using my snippet, so in theory it would already be possible to use it.
13 Aug, 2013, plamzi wrote in the 35th comment:
Votes: 0
KaVir said:
Zeno said:
In this modern age, that makes complete sense. But how do you plan to handle the differences in all the MUD types out there and parsing HP formats, etc?

My MSDP snippet supports something similar - it defines 5 buttons (each with a name and command) and 5 gauges (each with a name, colour, current value and maximum value), the idea being that it could be customised by each mud and utilised by any GUI plugin or script that supports either MSDP or ATCP. There are quite a few muds using my snippet, so in theory it would already be possible to use it.


MSDP is already being intercepted, so we're on our way to leveraging your good work.

I'm now working on the publishing framework for web app customizations. I'm thinking of "modules" and "drivers". The module is the insulated view + controller displayed in the UI, the drivers are the methods that drive one or more modules for a given game. In many cases, the modules can be shared across multiple games, or cloned off and adapted if needed.

People would be able to create these code blocks as editable content (using ACE code editor). When tagged appropriately, they will be injected into the right place for the right server.

I'm getting pretty excited. If you have any Javascript wizards to send me, please do!
13 Aug, 2013, Lyanic wrote in the 36th comment:
Votes: 0
plamzi said:
I can easily add MSDP or even TTYPE methods of sending the user IP.

Please do. That would be great.
13 Aug, 2013, Ssolvarain wrote in the 37th comment:
Votes: 0
plamzi said:
Ssolvarain said:
The client is clunky, though. Not a fan of it.


Care to elaborate? Also, which browser?


Umm… mostly it not clearing the command line after hitting enter, and the inability to use the up arrow to repeat a command if I do want to do so. Most people I know started off with GMUD, and eventually upgrade to Z/CMUD or Mushclient. I know people have some beef with GMUD for its technical stuff, but for a beginner (which I think you're trying to target) its one of the best clients to start with because of its ease of use. So it makes sense to me that it would copy at least the basic behavior of it.

Using latest version of Chrome.
13 Aug, 2013, plamzi wrote in the 38th comment:
Votes: 0
Ssolvarain said:
plamzi said:
Ssolvarain said:
The client is clunky, though. Not a fan of it.


Care to elaborate? Also, which browser?


Umm… mostly it not clearing the command line after hitting enter, and the inability to use the up arrow to repeat a command if I do want to do so…

Using latest version of Chrome.


The exact behavior you're describing is working for me ATM on latest Chrome.

Can you clear cache and try now? Maybe you caught me in the early hours of the site when the app was not all there.
13 Aug, 2013, Ssolvarain wrote in the 39th comment:
Votes: 0
It was early on. I'll take another look, thanks.

It does, it seems. I still don't like the command line not clearing, though.
13 Aug, 2013, Ssolvarain wrote in the 40th comment:
Votes: 0
Oh, for some reason it's posting some extra characters when you connect to End of Time. Could you take a look whenever you get a chance and lemme know what's causing that?
20.0/279