Subject: re: gui and m**

From: [email-masked] (Frank Crowell)
Date: Tue, 24 Aug 1993 08:47:00 -0700

actually a ms windows to MOO is not too difficult to do.

a simple windows client can dial up to a unix account, run your
unix client, and log into the mud.  after that, you can start
adding your own hacks, er design to the windows client.

of course if your PC box is on internet, you can write a 
ms windows client that uses tcp/ip hooks.  i know of one
company the provides such a package. 

The hard part is to figure out the extensions and to write to
something that resembles a standard.  For example, there are
some BSX ideas that i like; RIP is becoming increasingly
popular with BBS, and so on.

somewhere last year i suggested (and got beat up for it) that
instead of hacking the server, hack the unix client.
If you want to simulate BSX type stuff, it could be done
without making any changes to your server.  So you write your
windows client the way you would like the muds to really 
behave, and you hack you unix client to fit that model. 

-frank

-- 
[Maddog's VirtualStuff Emporium          [email-masked]]

---

From: Forrest Aldrich <[email-masked]>
Date: Tue, 24 Aug 1993 10:11:01 -0700

Through e-mail, Frank Crowell writes:
| 
| a simple windows client can dial up to a unix account, run your
| unix client, and log into the mud.  after that, you can start
| adding your own hacks, er design to the windows client.
[ ... ]

	Exactly as I think... but:

| of course if your PC box is on internet, you can write a 
| ms windows client that uses tcp/ip hooks.  i know of one
| company the provides such a package. 
[ ... ]

	Well, there are also a number of pd packages that provide TCP/IP
	stuff.  A couple of things that come to mind are KA9Q, NOS (its
	predicessor), and WAMPES.  These are popular with hamradio enthusiasts,
	and run on PCs, as well as UNIX.

	There are also the WINSOCK routines, of which I know nothing about.

| The hard part is to figure out the extensions and to write to
| something that resembles a standard.  For example, there are
| some BSX ideas that i like; RIP is becoming increasingly
| popular with BBS, and so on.
[ ... ]

	My problem right _now_ is getting information about these.  In particular,
	I figured that I would start out trying to understand how RIP works...
	But I can't afford to keep dialing up long-distance to their main BBS
	in hopes of answers.  The author doesn't have a regular email address
	that I know of.

	Someone mentioned to me the use of Hypertext.  This is a term I am
	familiar with, but don't really understand what it means.

	My basic idea was to set up some means of symbols, strings, and such
	that would be sent to the client which would in turn act locally upon
	them.  I don't know how quickly a standard could be set for this, as
	all of this is relatively new as a whole.  I would imagine once I
	figured out how RIPterm did its 'thing', with permission of the author,
	some concepts could be adopted.  Otherwise I would start from scratch.

	Have you any suggestions?

	I'm the originator of this thread... didn't realize there was actually
	so much interest in it.  I'm glad there is, this means many, many
	good ideas can come forth.

	As far as this being interfaced with the MOO... I have thought that
	perhaps verbs could be programmed to do the Hypertext and interpretations,
	etc... but then again, might it be quicker to have an actual server hack
	that would act when told to be in 'server' mode, sending the equivalent
	of "SoandSo says, 'I hate lemon pie.'" in Hypertext/symbolic mode that
	would be interpreted by the client.  

	My initial idea for this interpretation would be to have the display window
	split up into 3 areas:

	private messages/whispers (with paging... a la "More..." for the queue)
	---------
	Public messages/etc
	---------
	input/typing area

	What's more, a special screen editing environment for capturing, editing,
	and creating verbs would be essential.  It would be nice to have some
	Hypertext that would grab the output of a verb listing and format it
	properly, locally... etc etc.

	The options are limitless, really.  

	Someone mentioned graphics... and what my original intention was about
	this.  My original intention is to have some graphical representations
	of everything, not necessarily a 3D view of where ever you go within
	the MUD, that could come later once a decent client/server relationship
	was established.

	One concern that comes to mind is, for example, if there is a new type
	of ICON you wish clients to have, developing a means by which to interpret
	the *.ICO (MSDOS/WINDOWS) file into Hypertext and then back into a *.ICO
	file...  how would you do this?  Or would there be another, easier way
	to transfer this data (perhaps an embedded ZMODEM protocol?)... and
	that would hopefully lead to a decent means by which to upload and edit
	stuff from Core to Core... without the need to do everything from scratch
	again.

| somewhere last year i suggested (and got beat up for it) that
| instead of hacking the server, hack the unix client.
[ ... ]

	::Grin::!!!  I would imagine that it would need to be a little of both
	here.  Some changes in the server, and client... with the latter being
	more flexible to these changes unless such is developed with verbs
	in the server.

| If you want to simulate BSX type stuff, it could be done
| without making any changes to your server.  So you write your
| windows client the way you would like the muds to really 
| behave, and you hack you unix client to fit that model. 
[ ... ]

	This would be easier... although I don't know much about BSX... and
	doubt that BSX would run on my system (SYSV, SCO UNIX)... but I'm 
	open to ideas.

	Right now, as mentioned above, I'm looking for information about
	how other clients are doing their job right now for ideas.... at
	least to start.  At this point, I'm in the middle of chicken
	scratches on paper.  Not having any experience with designing a client
	like this makes things difficult, which is why I am hoping for some
	input from outside and the list.

	Thanks!

	Forrest