[MUD-Dev] Java and Javascript

[Jon A. Lambert]

On  1 Mar 98 at 16:20, Sauron wrote:
> Jon A. Lambert wrote:
> >      At an even deeper level a good interface will have a macro or
> > script language to program multiple clicks or key-sequences
> > (operations) using conditionals and looping constructs.  These may
> > also be mapped to buttons or key-sequences.  This client language
> > should be aware of its host environment to some extent.  This would
> > mean that something like JavaScript's or VBScript's awareness of the
> > host browser would be ideal.  Or WordBasic's awareness of the Word
> > environment.   The mud client language should be aware of the mud
> > client as a host and nothing outside of that sandbox.
> 
> Just a side note, this is all fine and dandy for someone with some
> familiarity with a scripting language, however, what about all the
> Joe-shmoos out there who wouldn't have a clue where to begin? 

There may be some confusion or difference of opinion as to what might 
constitute a good and easy to use scripting language for the 
"average" joe.  It could resemble C, Perl, Basic or could be 
represented visually with component diagrams.  I'm leaning towards 
the latter.

> It may
> be possible to create some standard distributable scripts to give
> them, however, I really do prefer the idea of using some sort of
> language server-side that was linked to a specific user/char (I love
> the MushCode idea, I find it much more useful and easier to use the
> VBScript).

Actually I'd like to amend my earlier statement about the client 
language only being aware of the client environment.  I think it 
should also be aware of the server environment.  

Client components could be shared, or even discovered.  Picking up
an object or possesing a skill might provide additional components
to be available within the client session.  The server exposes the 
objects to the client and the client is aware of their properties
and interface.  So your favorite character is 'self-registered' 
with the client.

I think that server programmed objects and the client programmed 
objects should be interoperable. 

> > I just got a new copy of MushClient, I was using an older version that
> > did not have the client language additions.  So I'll give it a look
> > see.
> 
> I have the latest version of MushClient and I have not yet once
> found a real need for scripts with it.
>

The mud servers you log into have no coupling with the client beyond
the text stream.  And this text stream has no meaning or format, 
except to the person running the client.  Well, except for the 
occasional line feed or ansi color code.  The real interface to the 
mud is still done server-side.  The client is merely a programmable 
keyboard. It does have one big advantage though.  It can be used with 
any mud.  

A programmable generic client sees:
"There is a silver sword here."

So the script language must parse the statement and derived action 
from it.  Not an easy task for the non-programmer.

However the client I'm envisioning would actually get passed a 
lightweight sword component.  The component would register 
itself with the client and could be referenced in client side 
scripts.  

--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--