Retro (textbased) Client

[juman]

I spend most of my days in a Linux console so the graphical interfaces out there are nice but they limit the amount of time I can play unfortunately. So I am drawing out the plans for a textbased GUI with a Ncursesinterface. Think of the first version as an advanced telnetclient but I think that with some shortscut-keys etc you can give quite a nice gaming experience even though it is just a text version.
 So I wonder if there is any more users that is looking for something like this or ay developers that would be interested in helping out with coding?

/juman

PS: I know there is some version of TinyFugue out there with similair functionality but it still miss some features. :DS

[burper]

I spend most of my days in a Linux console so the graphical interfaces out there are nice but they limit the amount of time I can play unfortunately. So I am drawing out the plans for a textbased GUI with a Ncursesinterface. Think of the first version as an advanced telnetclient but I think that with some shortscut-keys etc you can give quite a nice gaming experience even though it is just a text version.
 So I wonder if there is any more users that is looking for something like this or ay developers that would be interested in helping out with coding?

/juman

PS: I know there is some version of TinyFugue out there with similair functionality but it still miss some features. :DS

I've thought about this from time to time. I remember using tinyfugue way back when, back in the days of my 1200bps modem.

I'd be interested in trying out whatever you come up with. One thing you might consider building in from the start is a pluggable board interface, so with some future work you could make everything but the board be retro, but still be able to easy-click the moves and have something nicer to look at while playing.

One aspect of the telnet experience that is lost completely when moving toward a gui, is the strict sense of all events flowing along the same time scale, e.g. when someone makes a move, logs in or out, shouts etc... Its' a disadvantage to have everything mangled together, but there is something nice about it too.

Would you use CLIP?

[juman]

I'd be interested in trying out whatever you come up with. One thing you might consider building in from the start is a pluggable board interface, so with some future work you could make everything but the board be retro, but still be able to easy-click the moves and have something nicer to look at while playing.

Would you use CLIP?

One idea I have is to try to get it a bit like the Internetbrowser Elinks which actually supports the mouse even though it is in console mode and connected by telnet. Haven't got a clue how they have done that but it would be a neat feature. Making it pluggable would also be a good thing for those who want to use a combined gui but I think that is something for some later versions.

Using CLIP seems to be the easiest and most stable way of going at this so yes I am thinking about using that.

[don]

CLIP is excellent for ease but is a bit noisy.  I wish it'd been around when I programmed my GUI.  Burper's mention of sequential text processing is interesting.  It does add a flavor to FIBS.  In my GUI, for which I would have to dig thru stacks of paper for source code, there is no limit to windows, and comments whether shouts, kibitz, message or tell can be piped into any and all windoze selectively.  (The method of doing so is a bit cludgy)

One facet of telnet I've never seen handled is the packet out of order error.  It results in many disconnects.  The solution is to key your program to wait for any expected response from FIBS before it sends any new messages.  For example:  A shout needs a "you shout" response.  When you see a FIBS-quake, this is usually what is occuring, and most of the GUIs get booted, when the fastest reconnect is simply to fail to be disconnected by the error.

--
don

[burper]

CLIP is excellent for ease but is a bit noisy.  I wish it'd been around when I programmed my GUI.  Burper's mention of sequential text processing is interesting.  It does add a flavor to FIBS.  In my GUI, for which I would have to dig thru stacks of paper for source code, there is no limit to windows, and comments whether shouts, kibitz, message or tell can be piped into any and all windoze selectively.  (The method of doing so is a bit cludgy)

One facet of telnet I've never seen handled is the packet out of order error.  It results in many disconnects.  The solution is to key your program to wait for any expected response from FIBS before it sends any new messages.  For example:  A shout needs a "you shout" response.  When you see a FIBS-quake, this is usually what is occuring, and most of the GUIs get booted, when the fastest reconnect is simply to fail to be disconnected by the error.

--
don

Is there really a "packet out of order" problem, or are you playing loose with the terminology here? That would be a TCP stack problem. Do you really mean when fibs does not ack a command you send too soon after a previous one?

CLIP was made to be more parsable, but these days there is no shortage of cpu and higher level languages to parse with, so building a non-CLIP protocol client shouldn't be that bad.

[don]

yes

[gammboy]

burper:  Don, would you like peas or carrots?
don: yes



GB

[NIHILIST]

I miss my 1963 Pontiac Catalina. Is there anything you can do about that ?

NIHI

[juman]

Well I am about 50% done for a first beta. Not much to show yet but for the moment it looks like this...

[kev_et]

I've tried 2 graphical clients, and I found them far too confusing. I currently play over telnet, but anything with ncurses/readline support would be great.

I could help out with the programming, but looking at the screenshot I would say you're doing fine on your own.

[kev_et]

I don't know how far you've got, but I'm after a function and don't really want to write it myself, so I'm hoping you might have something similar already, that I could pilfer

I currently play all my games by doing something like

telnet fibs.com 4321 | tee -i /home/kev82/FibsGames/`date | sed 's/ /_/g'`

What I'm after is a function that will parse a type 2 board such as this one

Code Select Expand


   13 14 15 16 17 18       19 20 21 22 23 24
  +------------------------------------------+ X: lego - score: 0
  |                  |   |     X  X     X  X |
  |                  |   |     X  X     X  X |
  |                  |   |              X  X |
  |                  |   |              X  X |
  |                  |   |                   |
 v|                  |BAR|                   |    5-point match
  |                  |   |                   |
  |                  |   |                 O |
  |                  |   |                 O |
  |                  |   |              O  O |
  |          X       |   |  X  X     O  O  O |
  +------------------------------------------+ O: kev_et - score: 4
   12 11 10  9  8  7        6  5  4  3  2  1

  BAR: O-0 X-0   OFF: O-8 X-0   Cube: 1  turn: lego


into a convenient data structure so, I can figure out all the moves of the game.

Thanks.

[fergy]

Is there really a "packet out of order" problem, or are you playing loose with the terminology here? That would be a TCP stack problem. Do you really mean when fibs does not ack a command you send too soon after a previous one?

The only protocol related problem I'm aware of is the "run-on" message problem that is discussed in the CLIP documentation. I've never seen a packet out of order issue, and if there is one, it certainly isn't a TCP stack problem, but it could be a threading issue in the FIBS server software. But again, I have never heard of such a problem.

It may be that a client sends a flurry of messages together, and I seem to recall that it is possible to overload the server's message processor so that some of the messages are discarded. In general, it is better to throttle packet sending somewhat to avoid that problem.

Of course, if we had access to the server code, or there was someone who cared about it, we could know exactly what goes on in the server.

CLIP was made to be more parsable, but these days there is no shortage of cpu and higher level languages to parse with, so building a non-CLIP protocol client shouldn't be that bad.

CLIP offers other advantages over the non-CLIP protocol, mostly around better information about logged in users, and there is little reason to not use it. However, if the intent of this retro client is to just display messages, the formatting of the non-CLIP protocol is more human-friendly.

[juggler]

I currently play all my games by doing something like

telnet fibs.com 4321 | tee -i /home/kev82/FibsGames/`date | sed 's/ /_/g'`

What I'm after is a function that will parse a type 2 board such as this one

Code Select Expand


   13 14 15 16 17 18       19 20 21 22 23 24
  +------------------------------------------+ X: lego - score: 0
  |                  |   |     X  X     X  X |
  |                  |   |     X  X     X  X |
  |                  |   |              X  X |
  |                  |   |              X  X |
  |                  |   |                   |
 v|                  |BAR|                   |    5-point match
  |                  |   |                   |
  |                  |   |                 O |
  |                  |   |                 O |
  |                  |   |              O  O |
  |          X       |   |  X  X     O  O  O |
  +------------------------------------------+ O: kev_et - score: 4
   12 11 10  9  8  7        6  5  4  3  2  1

  BAR: O-0 X-0   OFF: O-8 X-0   Cube: 1  turn: lego


into a convenient data structure so, I can figure out all the moves of the game.

Hi,


I'd suggest to create another account (strictly spoken not legal, but for this purpose ok I think) and watch yourself with the client board type (is it 3) which is easier parsable.

Regards,
Peter aka the juggler

[kev_et]

Thanks, I hadn't considered that, but it might be the easiest way to go.

[juman]

Well my programming is put on ice as it took too much time. But giving the idea of using tee I have some other ideas that seems to work. I will present them here when they are fully up and running. But I need some tips on how to parse the rawboard format and put it toghether to an ascii board. Any tips, ideas on how to best do that in Perl?