13 Aug, 2013, plamzi wrote in the 41st comment:
Votes: 0
Ssolvarain said:
It was early on. I'll take another look, thanks.


Small note: The text stays after sending, but becomes selected, so you have the option to press 'Enter' to re-send easily, or just type a new command to overwrite the previous one. That's pretty standard behavior in most clients.
13 Aug, 2013, Ssolvarain wrote in the 42nd comment:
Votes: 0
only on zmud/cmud as far as I'm aware. It's obnoxious as a builder because I have to backspace in order to view what I'm looking at.
13 Aug, 2013, Zeno wrote in the 43rd comment:
Votes: 0
I'm with Ssol on that, I use MUSHclient and always have my input clear. I think it's an option to save the last input in MUSHclient, but I can't stand it.
13 Aug, 2013, plamzi wrote in the 44th comment:
Votes: 0
Ssolvarain said:
only on zmud/cmud as far as I'm aware. It's obnoxious as a builder because I have to backspace in order to view what I'm looking at.


You mean you need to be able to send an empty line feed easily?

My primary focus is not builders, but I'll definitely throw this into the configurable options when I get to that.
13 Aug, 2013, Hades_Kane wrote in the 45th comment:
Votes: 0
And see, I'm of the opposite opinion on that. I have my MUSHClient configured to keep commands in the input line, just highlighted so I can backspace to clear, start typing to clear + have a new command, or enter to repeat. I would find it difficult to play in a client that didn't have that behavior :p

Making that configurable would probably be good, seems both sides feel strongly about it.
13 Aug, 2013, Dean wrote in the 46th comment:
Votes: 0
Zeno said:
I'm with Ssol on that, I use MUSHclient and always have my input clear. I think it's an option to save the last input in MUSHclient, but I can't stand it.


This.

I don't mind if it defaults to save last input so long as I have a way to turn it off.
13 Aug, 2013, KaVir wrote in the 47th comment:
Votes: 0
plamzi said:
You mean you need to be able to send an empty line feed easily?

I'm a compulsive enter-hitter, I'll have the mud open in one window while I work in another, and if there's no activity for a while I'll hit enter a few times to make sure it's not frozen or lagged.

It's rare for me to want to repeat the same command though. When I tried using a client with that option in the past, I kept accidently spamming the public channels with my last chat.
14 Aug, 2013, Scandum wrote in the 48th comment:
Votes: 0
plamzi said:
MSDP is already being intercepted, so we're on our way to leveraging your good work.


If you want to test MSDP automapping (as defined in the spec) there is slackhalla.org:6969 which uses a table and is subsequently similar to the GMCP implementations I've seen.
14 Aug, 2013, Lyanic wrote in the 49th comment:
Votes: 0
KaVir said:
It's rare for me to want to repeat the same command though. When I tried using a client with that option in the past, I kept accidently spamming the public channels with my last chat.

I can attest to that. I've seen him do it before.
14 Aug, 2013, Runter wrote in the 50th comment:
Votes: 0
Quote
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.


This is not correct. There are different zones of trust with javascript. At the very least malicious user submitted javascripts could interfere with the game in question. That's *definitely* more dangerous than running code all written by Plamzi, or some mudclient author. At the very least people need to know the differences between opening a mud from zmud on the zmud list, and opening a mud (and presumably javascripts) on your webapp. There needs to be a sane policy for vetting these plugins before they're just ran.

Quote
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.


Different games require different levels of responsiveness, but let's example an extreme example where latency will be a concern. If I ran a mud in singapore, where I live, and then a player in singapore connects through your proxy, and then back to singapore, it's taking what should be a 5ms response and turning it into a 600-1000ms response. That's 150 times more latency. Yes, if everyone is in north america it's probably not much of an issue.

The solution most companies do to combat this is through services that automatically connect to the server with the nearest geographic location. amazon has some hosting services that make it relatively painless, but by default this isn't the case and it can cost money.
14 Aug, 2013, Runter wrote in the 51st comment:
Votes: 0
Kelvin said:
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.


To some people their hobby is important. Just because there's a vector of attack out there doesn't mean you should open the door for even more.

The point I was trying to make is that putting all the eggs in one basket (many peoples accounts to many muds) is much more dangerous than your neighbor packet sniffing your wifi to get your password to Realms of Dragon Lore 5. Plus, it's much more of an accessible vector of attack for people the information is relevant to. Like people who also play on the same game, or someone with an axe to grind in the community.
14 Aug, 2013, Ateraan wrote in the 52nd 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 :)

Okay fixed it. You should be able to reply and I think you did with a test message.
14 Aug, 2013, Ateraan wrote in the 53rd comment:
Votes: 0
Tijer said:
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…
Did that ever stop? That was my biggest beef with the Flash Client. With the server side required everyone logging in, does so with your IP not their own.
14 Aug, 2013, Scandum wrote in the 54th comment:
Votes: 0
Runter said:
This is not correct. There are different zones of trust with javascript. At the very least malicious user submitted javascripts could interfere with the game in question. That's *definitely* more dangerous than running code all written by Plamzi, or some mudclient author. At the very least people need to know the differences between opening a mud from zmud on the zmud list, and opening a mud (and presumably javascripts) on your webapp. There needs to be a sane policy for vetting these plugins before they're just ran.

Using MSSP a trusted email address can be obtained, which can be used for a verification code to create a trusted user account, which in turn would be able to submit scripts.

There's still the problem of people of low moral character, like Locke, to create a MUD and do something malicious. It's not Plamzi's job to stop criminal behavior though, only to assist the authorities when it happens.
14 Aug, 2013, plamzi wrote in the 55th comment:
Votes: 0
Runter said:
Quote
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.


This is not correct. There are different zones of trust with javascript. At the very least malicious user submitted javascripts could interfere with the game in question. That's *definitely* more dangerous than running code all written by Plamzi, or some mudclient author. At the very least people need to know the differences between opening a mud from zmud on the zmud list, and opening a mud (and presumably javascripts) on your webapp. There needs to be a sane policy for vetting these plugins before they're just ran.


I misunderstood your initial question–I thought you were looking at it from a Game Admin perspective. From the viewpoint of a Portal user, of course I'll let people choose what plugins are being run on the page, just like people choose what plugins to install and run for their Mudlet or MUSHClient.

The CMS has a flexible user group system, so people would be able to see not just the username of the code author, but also if they are game admins, or even stats about how many other players are using this particular plugin.

If I get fabulous contributions that can enhance any game, they will be vetted by me before they're integrated into the core. Rest assured I am thinking about the issues you mentioned, and others. It's not going to be a free-for-all, just a dynamic framework in the best of senses.


Runter said:
If I ran a mud in singapore, where I live, and then a player in singapore connects through your proxy, and then back to singapore, it's taking what should be a 5ms response and turning it into a 600-1000ms response. That's 150 times more latency. Yes, if everyone is in north america it's probably not much of an issue.

The solution most companies do to combat this is through services that automatically connect to the server with the nearest geographic location. amazon has some hosting services that make it relatively painless, but by default this isn't the case and it can cost money.


I'm not as big as Amazon, yet ;) For now, I guess I'll just have to let individual game admins decide how much time to invest in promoting or customizing their Portal app. But even if they spend 0 time, I am hoping that at some point enough generic UI modules will be accumulated where my client would be able to add value to their game.

A 600-1000ms response doesn't prevent new player conversion. If a new player using the Portal gossips in your global game channel asking how to improve responsiveness, they have been converted. You'll know how to refer them to another client, I'm sure.
14 Aug, 2013, Runter wrote in the 56th comment:
Votes: 0
Quote
A 600-1000ms response doesn't prevent new player conversion. If a new player using the Portal gossips in your global game channel asking how to improve responsiveness, they have been converted. You'll know how to refer them to another client, I'm sure.


Okay, well, if your response is the player can use your portal to find another client then fine. But 600-1000 MS latency is definitely not okay, something people should also be aware of, which was the purpose of my original point being made.
14 Aug, 2013, plamzi wrote in the 57th comment:
Votes: 0
Runter said:
Quote
A 600-1000ms response doesn't prevent new player conversion. If a new player using the Portal gossips in your global game channel asking how to improve responsiveness, they have been converted. You'll know how to refer them to another client, I'm sure.


Okay, well, if your response is the player can use your portal to find another client then fine.


That, plus my earlier response that if you have a Websocket proxy (trivial to install if you have the permissions), then the web app can be pointed directly to it.


To respond to some other questions, IP forwarding is already not an issue, and it will be shared in every way that people request. I think the people who are already working with me on testing and improving the client for their games can attest that I'm not TMC :)
14 Aug, 2013, Rarva.Riendf wrote in the 58th comment:
Votes: 0
I am with Hades for keping the command BUT highlighted so If I type anything it is automatically replaced.
It allows repetition (or editing) of the last command easily and still allow a new command to be entered directly.
15 Aug, 2013, Skol wrote in the 59th comment:
Votes: 0
Great stuff, thanks plamzi!
Any thoughts on MXP integration?
15 Aug, 2013, plamzi wrote in the 60th comment:
Votes: 0
Skol said:
Great stuff, thanks plamzi!
Any thoughts on MXP integration?


Well, my humble goal is to dethrone Mudlet, zMUD, and MUSHClient. So I think you can read my thoughts on MXP integration.

BTW, the web app has been re-skinned and re-factored. I'm already accepting game submissions, and any day now the door will open on customizations.
40.0/279