Mudlet 3.0.0-delta (preview #4)

Sharidin
Posts: 3
Joined: Wed Mar 17, 2010 5:24 pm

Re: Mudlet 3.0.0-delta (preview #4)

Post by Sharidin » Mon May 09, 2016 7:51 am

I tried most of the instructions I could find, there were different ones here and there, wiki and forums etc... Just can't get it to compile. Apparently the preinstall includes those ppas and they still give error and on compile it cannot find some -dev libraries, it seems like they are not available in 16.04, yet? In any case, I went back to 2.1 and might be using Wundersys instead so it should be OK until a stable 3.0 release comes out, take your time to make it right. I'm a developer myself and know the hardships! :D

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

Re: Mudlet 3.0.0-delta (preview #4)

Post by SlySven » Mon May 09, 2016 7:06 pm

Specifically on the lua errors you mention - Mudlet uses lua 5.1.x but as that is no longer the latest it may be that the "system" ones that you (or Ubuntu) has are later ones that do not work with Mudlet - off the top of my head I am not sure how to ensure that you have both 5.1 and whatever later version your system wants for other things and that if you are compiling the application yourself that it is linked with lua5.1 - it may well come down to a numeric suffix in the right place I suppose.

Sharidin
Posts: 3
Joined: Wed Mar 17, 2010 5:24 pm

Re: Mudlet 3.0.0-delta (preview #4)

Post by Sharidin » Tue May 10, 2016 2:48 pm

Indeed, it was mainly a problem of package issues. I managed to fix the problems with Svof not installing in Mudlet 2.1 in Ubuntu 16.04 LTS. Apparently, there were missing installations. I had to install the following official packages: lua5.1, lua-zip and lua-filesystem. Once all three were installed Svof and the new mudlet mapper worked perfectly! Will be looking forward to a stable 3.0!

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

Re: Mudlet 3.0.0-delta (preview #4)

Post by SlySven » Tue May 10, 2016 11:04 pm

Sharidin wrote:... Will be looking forward to a stable 3.0!
We all will! :geek:

User avatar
bozimmerman
Posts: 11
Joined: Tue Jul 09, 2013 1:40 am
Location: Round Rock, TX
Contact:

Re: Mudlet 3.0.0-delta (preview #4)

Post by bozimmerman » Wed Jul 27, 2016 4:42 am

Vadi wrote:...
Please provide all feedback and problem reports on 3.0.0-delta here! Feature requests can be done in our dedicated thread.
Bug report in 3.0-delta

Less-Than-Signs are confused with the beginning of MXP tags in the following situation:
1. MXP is activated through handshake (server sends WILL MXP, mudlet sends DO MXP)
2. Later, MXP is turned back off from the server (server sends WONT MXP, mudlet sends DONT MXP)

After this, the less-than-signs < are not shown, as they are still being confused with MXP tags, even though both sides have agreed to turn this off.

This commonly happens in CoffeeMud because the server turns on MXP right away to show the intro graphics, but after login, may find that the user personal settings are to keep it off...

Feel free to contact me for further details. You can reproduce at coffeemud.net:23

- Bo

P.S. Normally I try to fix things like this with client-specific hacks, but the MXP handshake happens before the terminal type response is received. :(

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

Re: Mudlet 3.0.0-delta (preview #4)

Post by SlySven » Wed Jul 27, 2016 11:44 pm

So the Server is given permission to turn MXP ON by Mudlet during Telnet Sub-option negotiation - after all, the server MUST treat the setting, like ALL sub-options, as being OFF until it and the client agree to it and then enable it ...! I'm not too familiar with MXP but I am aware that Mudlet's implementation is not perfect in that area. Even a cursory read of the limited documentation that Zugg of C/ZMud fame created suggests that our code does not handle the mode locking correctly - but I think one of our leaders has commented (I'm paraphrasing here!) that MXP is a bit of a kluge anyhow and that getting something that works for the majority of variety of server implementation is hard enough with the parts that have been properly "nailed down".

tl;dr; is it possible to make terminal type detection happen before MXP negotiation?

User avatar
bozimmerman
Posts: 11
Joined: Tue Jul 09, 2013 1:40 am
Location: Round Rock, TX
Contact:

Re: Mudlet 3.0.0-delta (preview #4)

Post by bozimmerman » Thu Jul 28, 2016 7:38 am

SlySven wrote:So the Server is given permission to turn MXP ON by Mudlet during Telnet Sub-option negotiation - after all, the server MUST treat the setting, like ALL sub-options, as being OFF until it and the client agree to it and then enable it ...! I'm not too familiar with MXP but I am aware that Mudlet's implementation is not perfect in that area. Even a cursory read of the limited documentation that Zugg of C/ZMud fame created suggests that our code does not handle the mode locking correctly - but I think one of our leaders has commented (I'm paraphrasing here!) that MXP is a bit of a kluge anyhow and that getting something that works for the majority of variety of server implementation is hard enough with the parts that have been properly "nailed down".

tl;dr; is it possible to make terminal type detection happen before MXP negotiation?
Yes, it would be possible, but, well, I didn't want to mention it, but mudlet did not seem to be responding to term type codes -- I figured it was intentional? Anyway, the answer is yes: we COULD basically look for "mudlet" and then NOT negotiate MXP until the user is logged in, IF mudlet told us it was mudlet.

However, it would still be very nice if mudlet could stop parsing MXP tags whenever mudlet tells the server DONT MXP. :)

- Bo

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

Re: Mudlet 3.0.0-delta (preview #4)

Post by SlySven » Fri Jul 29, 2016 7:57 pm

IIRC Mudlet (even the 2.1 release) will return something for a TTYPE (24) sub-option negotiation. At present it is a fixed string of the following: the 2.1 Release: will return "Mudlet 2.1.0", since then the development branch had a fixed string of: "Mudlet 3.0.0dev" until I got at it and now it will be "Mudlet " followed by three dot-separated numbers (e.g. "3.0.0") and if it is NOT a release version there will be a build suffix (THIS SHOULD 8-) BE THE DEFINITIVE test of whether it is a "release" or "development" build), hopefully beginning with a hyphen - at present the latest preview release will report "Mudlet 3.0.0-delta" though at the time of writing Vadim really wants me to help to get an "-epsilon" out there!

If there are Hackers / *nix Distribution packagers of the actual Mudlet client out reading this, there could you respect this version naming scheme and put a suffix on any patched versions you release? It helps to keep things clearer as to which version people are commenting on! The string is set in two places: in the qmake and top-level cmake project files respectively - and they should have the SAME value...

For the record, according to RFC1091 the string is case insensitive and should contain only ASCII characters and be a maximum of 40 characters (the use of a space between the word Mudlet and the version string is a bit iffy as far as I can see, it may be replaced with a hyphen '-' in the future ;) ) - I do have intentions to provide selectively less details for repeated server requests for this sub-option as per section 6 of the above RFC - though this will not trigger any changes to behaviour, i.e. the first response could be "Mudlet 3.0.1-dev" the next "Mudlet 3.0.1" and finally just "Mudlet" which would be repeated once to indicate the end of the list before restarting. I am aware of MTTS (the creation of Scandum, the current maintainer of the TinTin++ MUD client) and I do want to shoe-horn that in eventually...!

User avatar
bozimmerman
Posts: 11
Joined: Tue Jul 09, 2013 1:40 am
Location: Round Rock, TX
Contact:

Re: Mudlet 3.0.0-delta (preview #4)

Post by bozimmerman » Fri Jul 29, 2016 9:16 pm

Thanks for your response SlySven!

Are you sure about the TTYPE thing? I have a wireshark pcap showing the server sending the following bytes:

Code: Select all

0000  8c 89 a5 c6 d8 07 00 24  1d 1d e8 86 08 00 45 00   .......$ ......E.
0010  00 5e 36 c2 40 00 40 06  80 36 c0 a8 01 0a c0 a8   .^6.@.@. .6......
0020  01 47 00 17 fb 53 5e 7c  09 0c 95 93 fd 39 50 18   .G...S^| .....9P.
0030  00 2e 38 82 00 00 0a 0d  43 6f 6e 6e 65 63 74 69   ..8..... Connecti
0040  6e 67 20 74 6f 20 43 6f  66 66 65 65 4d 75 64 2e   ng to Co ffeeMud.
0050  2e 2e 0a 0d ff fa 18 01  ff f0 ff fb 56 ff fb 5b   ........ ....V..[
0060  ff fb c9 ff fb 5a ff fb  45 ff fb 1f               .....Z.. E...
It starts on 0050, the 5th byte. As you can see, it's literally the first telnet code sent.

I tried several things, including prefacing it with a WILL TTYPE, but that didn't help. A response just never arrives. I've attached the full pcap. (P.S., my original bug is about the 3.0 delta, and I did also observe this behavior on 3.0 delta -- this particular test was done with 2.1 because it's what I had on my work computer.)

If you see something I'm doing wrong, I would be forever in your debt to point it out, but this procedure DOES work with other mud clients....
Attachments
mudlet21-cm-handshake.zip
zipped version of the mudlet21 pcap
(25.16 KiB) Downloaded 506 times

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

Re: Mudlet 3.0.0-delta (preview #4)

Post by SlySven » Sat Jul 30, 2016 4:28 pm

The code starting at 0x55 is

Code: Select all

ff fa 18 01 ff f0
corresponds to IAC SB TTYPE SEND IAC SE (where TTYPE is the 0x18 sub-option). You say "it's literally the first telnet code sent" but where is the previous

Code: Select all

ff fb 18
corresponding to IAC WILL TTYPE?[/i] Obviously your server will need to wait for the IAC DO TTYPE from the Mudlet client before it sends (possibly multiple times) the IAC SB TTYPE SEND IAC SE

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests