Making TConsole::printOnDisplay work on miniconsoles

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Making TConsole::printOnDisplay work on miniconsoles

Post by SlySven »

Yes, but currently the user cannot include in the arguments to the Lua echoAnsi() command you've made, raw ANSI escape codes as you have written them. This is because the storage system is based on writing the script as an element in an XML file and XML format version 1.0 prohibits all the ASCII characters in the range \x01 to \x1f (\01 to \37 so including the \27 or ASCII "Esc" you've used) with the exceptions of tab {\x09}, line-feed and carriage-return {\x0a and \x0d} (or possibly the other way around, I can never remember which is which :roll: ). OTOH if Vadim has got together an escape system so that tokens that represent those control codes {my suggestion was for things like "&esc;" for the ASCII Escape character} so that the file gets saved and displayed and edited with the escapes but they get converted to the actual ASCII codes when sent to the MUD server or compared to input from the Server then we will have cracked the problem. :D

I, personally, am interested in the Mud Master Chat Protocol aspect - though I don't recall that handling ANSI ESC codes (in the messages) though Scandum's (effectively a reference) implementation in TinTin++ did colour the messages to make them stand out and as TinTin++ is a console MUD client would need to use those codes to embed the coloured text sent to either a tty (eg. linux console {non-GUI} session) or psuedo-tty (eg. xterm in a GUI X11 session). One thing I recall though is that MMCP is a peer-to-peer communications protocol so client and server is a bit of a misnomer as the instances on each host should be capable of the same things (which does include relaying messages between other hosts that can not see each other and with care taken to ensure no messages loop between other hosts that CAN see each other; also is a requirement for a fixed block size (500 bytes) file transfer protocol to move files between two hosts and group and private messages systems besides the default everyone see everything unless ignored!) An issue that I had the last time I looked over Scandum's code was that it was IPv4 only whereas it really ought to be dual, simultaneous, protocol 4 and 6 - indeed that was the original reason I got me a (free) IPv6 tunnel brokered by the (nice pair of) guys who run the almost world-wide SixXS tunnel broker service as my ISP does not offer IPv6 connectivity and I realised I would need it to test the stuff I might eventually get around to doing. :geek:

Zah
Posts: 12
Joined: Fri Nov 29, 2013 11:07 pm

Re: Making TConsole::printOnDisplay work on miniconsoles

Post by Zah »

I want to clean up my code and remove some of the unnecessary functions I made before I submit a pull request. In regards to tokenizing the escape character, I see the value in that too. I use XML a lot for work and naming the token &esc; fits well for this case.

As far as the the tintin++ it does render the ansi colors to the terminal directly. Mudlet translates those codes into their RGB equilvents in the TBuffer::translateToPlaintext function one character at a time.

Yeah my "client" is a true client at the moment because it has zero support for being a server. It doesn't support the MMCP file transfer or "snooping" features either. Part of the problem is that I would have to create a pool to handle multiple lua socket connections. Vlad did give me a hint on this though when he explained on launchpad that coroutines can work (so long as they don't interact directly with mudlet through echo(), print() etc.) so the next thing I am planning is putting together a message queue so coroutines can write messages to the MQ and mudlet will deque the messages and execute them. I'd rather the socket connections live inside coroutines because sometimes sockets behave badly. If that doesn't work just right I may look at either moving the chat client to Qt or having seperate lua containers for each server/client in another way.

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Making TConsole::printOnDisplay work on miniconsoles

Post by Vadi »

SlySven wrote:Yes, but currently the user cannot include in the arguments to the Lua echoAnsi() command you've made, raw ANSI escape codes as you have written them. This is because the storage system is based on writing the script as an element in an XML file and XML format version 1.0 prohibits all the ASCII characters in the range \x01 to \x1f (\01 to \37 so including the \27 or ASCII "Esc" you've used) with the exceptions of tab {\x09}, line-feed and carriage-return {\x0a and \x0d} (or possibly the other way around, I can never remember which is which :roll: ). OTOH if Vadim has got together an escape system so that tokens that represent those control codes {my suggestion was for things like "&esc;" for the ASCII Escape character} so that the file gets saved and displayed and edited with the escapes but they get converted to the actual ASCII codes when sent to the MUD server or compared to input from the Server then we will have cracked the problem. :D
I haven't solved that issue, I just used a workaround in my script that needed to deal with it.

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Making TConsole::printOnDisplay work on miniconsoles

Post by SlySven »

<aside> Must confess I never did find out whether TinTin++ MMCP was "global" to all the sessions it could run simultaneous or was specific to the initiating session, i.e. did an incoming CHAT message get shown on all sessions if one was multi-playing or just the one that issued the "#CHAT {INIT} {<port number>}" command - never got around to checking. I was using it to slave a second PC accessing a LAN shared ramdisk containing the TinTin++ map file so I could have a heavily enhanced (using custom home made room drawing glyphs in the private area of a Unicode font) full screen map on the second instead of #SPLITing the display on the primary PC.

Because of the need to manage multiple background TCP links to the MMCP peers with, ideally low latency, to keep the "#CHAT PING" times down, I think that the engine for this will need to be in the C++ core. On the bright side it is probably a candidate for running in one or more separate thread(s) and might I suppose be able to share some code with the IRC client.</aside>

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Making TConsole::printOnDisplay work on miniconsoles

Post by Vadi »

I think we should make it possible to do in Lua. Lua is very performant, and we don't want every protocol (some with user counts in hundreds) out there bloating up the core.

Zah
Posts: 12
Joined: Fri Nov 29, 2013 11:07 pm

Re: Making TConsole::printOnDisplay work on miniconsoles

Post by Zah »

Okay I cleaned up the code, and submitted a pull request.
https://github.com/Mudlet/Mudlet/pull/222/files
Bonus: I also added support for the &esc; token to echoAnsi. :D
Code: [show] | [select all] lua
--with embedded escapes
echoAnsi("\27[0;1;31;40m<REDTEXT>\n\27[0m\n")
echoAnsi("HelloWorld","\27[0;1;31;40m<REDTEXT>\27[0m\n")
--with the new &esc; token
echoAnsi("&esc;[0;1;31;40m<REDTEXT>\n&esc;[0m\n")
echoAnsi("HelloWorld","&esc;[0;1;31;40m<REDTEXT>&esc;[0m\n")
This has been an encouraging and fun experience. Now off to play with coroutines and the message queue ideas. 8-)

Post Reply