[Zhiroc]

Originally Posted by Mabus Again, I believe a Java application of a MUD client would be best.

I agree. People seem to think that Java is only good for applets.

With Java Web Start, you can provide a hyperlink that will launch the game--download the jars, or check existing jars for updates. And then it can leave an icon on the desktop for you so you don't even need the link.

So as long as Java is installed, launching is easy.

[Threshold]

Originally Posted by Mabus Java is truly multi-platform, as long as the computer has Java installed.

That is, unfortunately, a bigger if than it should be. And then the larger problem is WHICH version of Java do they have installed?

I remember a client discussion here a few months ago, where Logos shared some data they had about which version of the JVM people had installed. I remember being surprised at how many people did not have java installed at all, or who had an extremely old version of it.

[shadowfyr]

Originally Posted by Aeran The issue is that people need to learn that follow standards is a good thing. It should not matter what MUD client people use. It is of little interest. What should matter is that those MUD clients are capable of handling the protocols used. It reminds me of Microsoft when they didn't seem to understand why they should follow standards in Internet Explorer. Look at MXP. There's quite a few similar protocols used in different clients. E.g Iron Realms use one that is closed to their own client. Some MUDs have even tried to extend MXP but didn't suggest the extension to be included in next version of the official MXP protocol. Clearly that didn't work well as clients that did follow the standard couldn't handle the new feature. Similarly there has been very little discussion about possible improvements to MXP on its development forum. I think the main problem here is that people don't cooperate that much between MUDs/clients. Perhaps they rather go their own way.

Actually, the problem with MXP is that Zugg refuses to fix his own spec to clarify how it should be implemented, so that the muds use them correctly. Result is that they use zMud to test it, and like a web browser, the client just parses things anyway, even in situations it shouldn't, according to the specification, if you read it literally. So, the spec says one thing, the client does something else, and no one has a clue what the frack is going on. Its kind of hard to improve something when the guy that wrote the spec can't even agree on what it should be. Mind you, he and Nick Gammon did discuss it, and Zugg agreed that there should be "some" agreement on what it really is supposed to do in some cases. Nothing ever happened.

But yeah, there is a clear standards problem, and no one willing to step forward and say, "This is what needs to happen.", or any group willing to set them collaboratively.

[TheDisciple]

Originally Posted by Aeran The issue is that people need to learn that follow standards is a good thing. It should not matter what MUD client people use. It is of little interest. What should matter is that those MUD clients are capable of handling the protocols used. It reminds me of Microsoft when they didn't seem to understand why they should follow standards in Internet Explorer.

Bad analogy. In the era of IE dominance, however IE did things was the standard for all practical purposes. Everything else was just a circle-jerk the rest of the browserfolk threw together so at least they wouldn't be fighting each other so much as they tried to eat into IE's 95%+ market share. Microsoft had everything to lose and nothing to gain by following the standards that the losing players in the market created without consulting them.

There isn't really an IE of the MUD world, unless you consider WoW to be it, in which case everyone else should start implementing their UI.

[shadowfyr]

Originally Posted by Threshold That is, unfortunately, a bigger if than it should be. And then the larger problem is WHICH version of Java do they have installed? I remember a client discussion here a few months ago, where Logos shared some data they had about which version of the JVM people had installed. I remember being surprised at how many people did not have java installed at all, or who had an extremely old version of it.

What is the fascination with Java anyway? As you say, it may not be installed, it may be the wrong version, etc. And, its too C like for my tastes. Too much syntax that barely human readable, and then only if you know what it means in the first place. Its not exactly noob friendly, and its rather unlikely that anyone is going to write a Java client, then use Lua, for example, as its internal "scripting" system. So, if you want to write plugins, you are stuck learning a language that isn't that friendly to start with.

[Zhiroc]

Originally Posted by shadowfyr What is the fascination with Java anyway? As you say, it may not be installed, it may be the wrong version, etc. And, its too C like for my tastes. Too much syntax that barely human readable, and then only if you know what it means in the first place. Its not exactly noob friendly, and its rather unlikely that anyone is going to write a Java client, then use Lua, for example, as its internal "scripting" system. So, if you want to write plugins, you are stuck learning a language that isn't that friendly to start with.

At my place of work, we have a 75K line Java application we use for a key business application. It's pretty rock solid, in that it doesn't crash, it doesn't corrupt data, and it performs pretty well. It's written for Java 1.4.2 (which is somewhere in the vicinity of 5-6 years old now), and runs on 1.5 or 1.6 too. The concern about versions is overblown.

As for readability, I find it not as readable as C (which is a pretty clean language for the most part), but more readable than C++. Though I don't count readability all that high, I guess. I love Perl, and it is only one small step up from APL or TECO (there, I've dated myself...)

I don't see anything wrong with writing the core application in one language, and then imbedding a scripting language in another. zMUD and mushclient both do this. Having thought about this before, I also had an inclination that doing this shields the application itself from some malicious or just erroneous scripting. If you implement your scripting in the same language as the client, I think I'd want to see some pretty good sandboxing between them.

As for scripting for Java applications, I came across this web page: Open Source Scripting Languages in Java. I haven't looked too carefully though. I think some might be based on native code, making the cross-platform advantage less so. But I think some are pure Java implementations of the scripting engines.

If a user needs to install Java to run a client, I don't see that as too onerous a requirement. After all, other than raw telnet, no OS comes with a MUD client pre-installed. And once you install the core JRE, you can use Java web start to download the client itself, and keep it up to date. I think that works very well.

[Voidrider]

For the most part, all of this discussion is far beyond my pea-sized brain but it made me wonder something. Are most/all of mud clients that are integrated into web-browsers using Java?

I was just wondering because recently I went to check out a mud that was mentioned to me by someone at a shop and it was that type. It was clunky as hell and the first time since pre-1995 that I had ever actually been affected by lag in a text game. I attributed it to the fact it was working through the browser though.

[shadowfyr]

Originally Posted by Voidrider For the most part, all of this discussion is far beyond my pea-sized brain but it made me wonder something. Are most/all of mud clients that are integrated into web-browsers using Java? I was just wondering because recently I went to check out a mud that was mentioned to me by someone at a shop and it was that type. It was clunky as hell and the first time since pre-1995 that I had ever actually been affected by lag in a text game. I attributed it to the fact it was working through the browser though.

Well, lets be clear. There is Java and JScript. If your are running IE, then some clowns Java client is likely to be running in the later. It should be noted that one reason Mushclient's developer doesn't recommend using "any" language linked via ActiveScript (the component that ties IE to JScript) anymore is because we had people doing this sort of stuff a lot:

<trigger
  match="fred says, *"
  sendto=12>
 <send>other.note "%1";</send>
</trigger>

Mushclient uses this to execute arbitrary code inside triggers, timer, etc., by fast loading the code into the engine, running it, then dumping it again. ActiveScript seems to have a garbage collection bug, which causes it to slowly swallow memory up, when ever you make the sort of calls above. In other words, ActiveScript based "languages" are ***not*** stable in certain uses. They also often have wacky integration issues, which caused Nick to abandon attempts to try to include more of them, after PHP kept exploding on him for no damn reason. This issue though seems to be in how the people that code the Windows versions of the languages integrated them with ActiveScript.

But, yeah, presumably if you have firefox, you probably have some version of Java, so, except for version differences, which *can* cause odd bugs, it could work in all browsers. There are a lot of ifs in that, for something as complex as a client, even without introducing the question of, "What if some fool tries to make it run in MS' garbage excuse for a Java system?"

[shadowfyr]

Originally Posted by Zhiroc I don't see anything wrong with writing the core application in one language, and then imbedding a scripting language in another. zMUD and mushclient both do this.

Mushclient goes a bit past that. If you use something other than Lua, you have a selection of like 7 ActiveScript based languages, from VB to Ruby, and even JScript (ugh!). Its recommended though that if you are going to use "on demand" calls to script that is generated partly, or completely, by a trigger, etc., you avoid those and go with Lua. No memory leaks that way. While there is a "main" file you can use, its recommended only for testing. When you get it working, the recommendation is to move all triggers, timers, aliases and code need to a plugin. While means exist to look for, look at variables in, and do some other things between the main script and plugins, or between the plugins themselves, they are *all* sandboxed from each other. Unless you code them so they can communicate, only things like the order their triggers fire, and if certain things like omitting the line from output, will cause interference between them. In other words, stuff that you can't avoid having interfere, if you allow them at all. And then, you can even, when using Lua, sandbox the Lua implementation on your own machine, either to remove restrictions for IO, like disk access, or to add functions, common code, enable features, etc.

Client is kept from serious interference, to a fair extent, from the script, the scripts can't interfere with each other, for the most part. And, once you have stuff in a plugin, anyone with the same client version or higher can simply drop a copy of that plugin into their's and have it work, without needing to code for something like zMud's plugin interface, which, unless I am mistaken, requires a compiler to do anything with it.

It could probably be useful to add a "few" additional restrictions to what plugins can change in the main world/client, since that isn't as clearly sandboxed, and prevent unloading of other people's plugins, etc. But, this wasn't considered at the time to be a big issue, and it wouldn't be that hard, probably, to add in some requirement that the client go, "Plugin 'Myprompt', ID: ... is attempting to change the ansi color settings. Allow or deny this?", and the like, when ever it tries to make such a change and you set a security level (also not in the client) to tell it, "Ask before letting a plugin change the world file itself."

Oh, and versions are "not" overblown. Tell that to the people running "complex" applications that do a lot of memory shifting and the like, like Azureus. It is pretty "stable" at this version of both the client and the Java its running it. Not *that* long ago there where bugs in Java that caused serious problems with certain parts of the client's operations. There where also some in the client itself, but it wasn't at all one sided.