25 Nov, 2010, Motley wrote in the 1st comment:
Votes: 0
Hello Guys,

I am just starting to get to get to grips with writing a simple MUD engine. My main purpose is to use the development to learn Scala. I have found that, when learning a new language, a project to work on really helps and writing a MUD looked like fun. So I am not trying to create the next killer virtual world. :-)

With Scala being on the JVM it gives me all of the Java libraries to play with, so to start with I decided to write a very simplistic little chat server that I could telnet into and broadcast messages. So going for a nave implementation to start with I just created a Socket for a connection that I could read and write to.

Anyway the problem that I am having is having a prompt that stays on the bottom of the console and being able to write incoming messages from other clients above this with out interfering. Unfortunately this is proving very tricky. I wondered if you had any suggestions on how I could go about getting it to work?

I assumed that it would be fairly straight forward its just a console app right? Looking around though it seems that console IO beyond vary basic reading and writing can be tricky in Java. So far I have tried using many combinations of escape characters to try and insert above the current line but I keep ending up with weird offsets or overwriting when I dont want to or loosing the prompt characters .

I know I could tray and go with a library like telnetd but I wondered if there was something obvious I was missing here? Or is it not possible with standard Java IO?

I tried to do some homework before pestering here and looked for inspiration in Groovy MUD and Ring MUD but they both use telnetd and I couldnt find the relevant code in CoffeeMUD.

Any suggestions?
Cheers,
Dan.
25 Nov, 2010, lockewarrior wrote in the 2nd comment:
Votes: 0
I apologize in advanced for this being so brief, but you are on the right path with telnetd.

It should provide terminal I/O support with multiple terminal types, as well as LINEMODE, TTYPE, NAWS, ECHO, etc.
25 Nov, 2010, Motley wrote in the 3rd comment:
Votes: 0
Thanks no probs on being brief, that is as I suspected.

I was just wondering if there was any way to do it 'raw'. I am suspecting not but… it is worth asking.

:-)
25 Nov, 2010, chrisd wrote in the 4th comment:
Votes: 0
A lot of MUDs simply send their prompt to the user after sending any other output, so you end up with a terminal like:

You move west.
prompt > east
You move east.
prompt >


I gather from what you're saying that you would like to keep the prompt at the bottom (or one line above the bottom) so that it's not caught in the scrollback like that. As far as I'm aware you'll need to use VT100 escape codes to achieve such a thing. I don't actually know any of them, but I'm sure someone (Scandum?) will chime in soon with further information. Suffice it to say that it is possible, but unfortunately not widely supported by MUD clients.
26 Nov, 2010, Scandum wrote in the 5th comment:
Votes: 0
There's some information at this post, and I wrote some more on the subject some posts down.

http://www.mudbytes.net/index.php?a=topi...

There's more info on vt100 in other topics.
26 Nov, 2010, Runter wrote in the 6th comment:
Votes: 0
To be clear this is a nontrivial problem for beginners in any language. But its not a language barrier. To accomplish this you really must control the client. By default the console is just echoing anything it gets. Through cursor manipulation with the vt100 protocol you can achieve this.
26 Nov, 2010, Motley wrote in the 7th comment:
Votes: 0
Thanks guys this has been helpful.

I has playing with escape codes but I didn't know about scrolling regions which may help.

What I was wanting to do was have the input stay at the bottom of the screen and new output get printed above it. The problem with just re-printing the input prompt is is the user is halfway through typing and some ut put arrives from something else happening I don't want that 'lost'.

As an aside I played with getting telnetd set up last night, I expected hours of pain trying to integrate it with Scala. I was very surprised to find that even with my current understanding of Scala it just pretty much worked as expected.

Cheers,
Dan.
26 Nov, 2010, quixadhal wrote in the 8th comment:
Votes: 0
Just be aware that if you're using telnet and allowing any old connection, some (many) of the folks connecting won't be able to make use of those fancy vt100 escape sequences because they're either on a terminal that doesn't support them, or they're using a client (tinyfugue/mushclient/zmud) which has its own idea about screen layout.

The issue can be solved easily by requiring a custom client, in which case you'd just use something like GNU readline or ncurses to manage the display. But… the audience here doesn't like that kind of talk. It makes them nervous. :blues:
28 Nov, 2010, Runter wrote in the 9th comment:
Votes: 0
I like that kind of talk. I've been quietly working on a project that will require a specified client.
28 Nov, 2010, Cratylus wrote in the 10th comment:
Votes: 0
OP, keep in mind that you don't have to be 100% according-to-Hoyle vt100 compliant.

There may be purists lurking about, but ultimately the reality is that the hobby has always been about adequate
compromises (and sadly all too often, inadequate ones) and full-spec compliant anything is pretty rare and
largely unnecessary as far as I've seen.

So, do not feel like you have to live up to Scandum's or Quix's expectations of what your server should do with their client.

Having said that…

Your main problem with this thing you want to do isn't spec implementation or compliance. A weekend or two of
hammering your forehead against your keyboard will work out what you need to do. Your main problem appears to be
not knowing your audience. The majority of mudders use line-mode telnet clients that are unable or unwilling to
handle character mode, which is required to do what you want.

The mud codebase I maintain does the thing you say, keep the propt at the bottom…but only if the player has
explicitly enabled character mode, and it only works if their client supports character mode.

I'm not too sure what your prompt scheme would do on CMUD, ZMud, MUSHclient, GMOO, etc, but I can
tell you it looks freaky wrong and intolerable when you use those clients in character mode on my codebase. I
expect it would be the same on yours. And most mudders use those line-mode-only clients.

So, unless you're looking to make a custom client, as the dread whispers thus far have hinted, or you plan a
mudding revolution, you should probably consider having the player be able to choose which mode to play in,
rather than force character mode.

-Crat
http://lpmuds.net
30 Nov, 2010, Motley wrote in the 11th comment:
Votes: 0
Again thanks for the input. I spent a little time hacking around after reading a little more in the directions you guy's pointed me and managed to get pretty much the effect I was after. Admittedly at the moment this as just in a terminal but baby steps.

For the moment all I am really after is a basic text input system I can run for the command line. I did start to become aware, as some of you have pointed out, that there is a more complex issue regarding clients and what players like to use. Which I will need to think about, I am not sure how that fits into my ideas…

I hope that I don't seem too heretical here :-) I am not a seasoned MUD player, I just liked playing text adventures as youngster and it seemed like a fun idea to do a simple multi-player text adventure for this project. My end goal is probably some kind of web interface, with basic text input as a stepping stone. I guess this falls into custom client?

So perhaps it is not really a MUD I am writing. I am asking here, and I hope you don't think I am intruding, as you guys are the best group I have found to discuss some of the shared problems that I will face.

You have all been helpful so far thanks :-)

Regards,
Dan.
30 Nov, 2010, plamzi wrote in the 12th comment:
Votes: 0
Motley said:
Again thanks for the input. I spent a little time hacking around after reading a little more in the directions you guy's pointed me and managed to get pretty much the effect I was after. Admittedly at the moment this as just in a terminal but baby steps.

For the moment all I am really after is a basic text input system I can run for the command line. I did start to become aware, as some of you have pointed out, that there is a more complex issue regarding clients and what players like to use. Which I will need to think about, I am not sure how that fits into my ideas…

I hope that I don't seem too heretical here :-) I am not a seasoned MUD player, I just liked playing text adventures as youngster and it seemed like a fun idea to do a simple multi-player text adventure for this project. My end goal is probably some kind of web interface, with basic text input as a stepping stone. I guess this falls into custom client?

So perhaps it is not really a MUD I am writing. I am asking here, and I hope you don't think I am intruding, as you guys are the best group I have found to discuss some of the shared problems that I will face.

You have all been helpful so far thanks :-)

Regards,
Dan.


If your end goal is something playable in a browser, your server probably shouldn't be telnet-based, or at least not telnet-only. The telnet clients running inside browsers are basically standalone JAVA apps and I'm not sure you'll have any control over cursor placement inside those. There's a telnet library for PHP CURL, but it can't keep a sustained telnet connection… Basically, connecting a browser to a telnet server presents a technical challenge.

What you probably want is a basic web-server as the network foundation rather than telnet. This server would keep a synchronized view of the virtual world, and should be capable of receiving GET requests at a minimum, outputting XML or JSON data as a response to a client page where the response is rendered.

If a browser page is your client/renderer, then the status prompt issue becomes meaningless – you can just have a div whose contents show the player's status information and put that div anywhere on the page you want.
30 Nov, 2010, Motley wrote in the 13th comment:
Votes: 0
My plan was to define a basic interface so that I can communicate with the data model (MUD). I can then have implementations that render the response, either to vt100 marked up text or later html. As a basic example. It reality there would be a touch more (or less*) to it than this but basically the problem seems to come down to:

get text commands in
send text info out

telnet is one option for this as it html, other options could potentially be web services, direct socket to a bespoke client etc.

As to what I am actually going to do, I don't really know yet there is a certain appeal in raw text :-) so I am keeping my options open, there is more than enough work to do at the moment on modeling the world, parsing input, acting on input, creating responses etc.

:-)

Regards,
Dan.

* I would not get directly involved with html but use a web framework, probably seeing as I am learning Scala, Lift. But I want to limit what I am dealing with for now and get a better handle on the core language before also trying to learn a new web framework.
01 Dec, 2010, Scandum wrote in the 14th comment:
Votes: 0
VT100 is supported by Zmud, Cmud, and TinTin++, as well as most telnet clients and a couple of web based clients.

For client side interfaces you can look at data protocols like MSDP and GMCP, which will work with Mushclient.

For a full comparison see: http://www.mudpedia.org/wiki/Comparison_...
02 Dec, 2010, quixadhal wrote in the 15th comment:
Votes: 0
If you design a communications protocol which both your client and server use, you can eliminate a great deal of unneeded code from the server. My suggestion is using something like JSON as a message container. You could also use XML, something else, or roll your own. The idea is, if the server always talks in properly formatted packets, it doesn't have to care so much about bad formatting of input, nor about trying to fudge the display to look a certain way on different kinds of clients.

The client side can then handle formatting the output for the user, and verifying that user input is in the correct format. IE: You type "kill orc", the client parses it and sends a KILL packet with "orc" as the target. The server only needs to validate the target, not parse the whole command. If the client has a button for "kill" and the notion of a pre-set target, the server still gets the same packet, even though the user didn't actualy type anything.

NOTE: In this model, your web server would be the client, since it is what would be generating the packets from various web page activity. Since you can't (yet!) keep tcp streams open via a browser, you'd need to have a scheme to validate the user-id and session-id to make sure multiple players don't cross the streams.
02 Dec, 2010, Tonitrus wrote in the 16th comment:
Votes: 0
quixadhal said:
you'd need to have a scheme to validate the user-id and session-id to make sure multiple players don't cross the streams.


There's something very important quixadhal forgot to tell you. Don't cross the streams. It would be bad.
0.0/16