27 Nov, 2016, Rarva.Riendf wrote in the 1st comment:
Votes: 0
testing of the problem can be done on arcanenites.com 7000 command to activate/deactive mccp is simply mccp
The problem appeared somewhere in time, and unfortunately, I do not seem to be able to find the version of my code that "worked"…. (it may be cause at the time I used mushclient…and that it maybe worked in it as well as in gmud, have to check about it)
So here is the problem: If I log, with mccp disabled, and then enable it, then disable it, then reenable it; it sends the compressed buffer. if I disable mccp it goes normally, but from there I cannot ctivate mccp again and have it works. if I log with mccp enable in char config, same problem as well as soon as I disable it, I cannot activate it anymore
I used the debugger to check what method are called and variable value, nothing different from first activation to second one. So basically it muse be some negociation that I have to do again, but I do not know wich, I pretty much just copy pasted code without looking too much into it. I use Kavir protoccol handler. If anyone had the same problem, or have a protocol test that would detect the problem that would be nice to drop a msg to explain where I need to look.
The problem is sligthly different if I use http://www.mudportal.com/play In this client if I quit the char with mccp enabled (working) next time I log, it forces mccp off and if I activate it , it goes wrong straight away.
and in Gmud it works fine (and I checked, it works fine in mushclient as well)
Funny thing though, the "clear" command only works in Gmud and in pure telnet….
Either my code is really funky or clients are weirds…
i have problems with re-negotiating mccp after a copyover on mudlet, but all other clients it works well… ive looked looked looked and looked a bit more but cant seem to work out why it happens, only occurs with mudlet, i know theres issues where mudlet tries to negotiate mccp1 as mccp2, but after removing mccp1 i still have the exact same issue… So i blame the clients myself :)
29 Nov, 2016, Rarva.Riendf wrote in the 3rd comment:
Votes: 0
Heh, still it is not sastisfying :) Maybe there are some workarounds for those client. I noticed something else a litttle funky if I send the 'clear' command then some mxp data, it goes straight to text in mudlet. :) works in mush though, (but the clear command still does nothing at all in it) Annoying :) makes me lose a lot of time in trying to solve my code :) When it may not even be mine the problem :p
Heh, still it is not sastisfying :) Maybe there are some workarounds for those client. I noticed something else a litttle funky if I send the 'clear' command then some mxp data, it goes straight to text in mudlet. :) works in mush though, (but the clear command still does nothing at all in it) Annoying :) makes me lose a lot of time in trying to solve my code :) When it may not even be mine the problem :p
Which version of mudlet? Older versions (pre 2012) would disable mccp when requested, but wouldn't flag the option as available to be re-negotiated so once you turned it off, it was off until you reconnected.
01 Feb, 2017, Rarva.Riendf wrote in the 5th comment:
Votes: 0
3 delta and 3 iota versions act the same. Once disabled on server they do not allow to activate it again, and they treat the compressed stream as normal text. I have problems with most clients, I think the only one that works (telnet support wise) for me is Zmud…
And not all problems are the same. So hard to tell who is the culprit, me or them. I have the clear screen command fail in many client, and work in other…so well…maybe it is my fault since no one else complain. But I do not see what i could do wrong. I would need a trusted client to be sure.
Haven't been here in a while. It does seem to be like an issue in the client - would be happy to get any cases we can reproduce and such.
05 Mar, 2017, Rarva.Riendf wrote in the 8th comment:
Votes: 0
It is quite easy to test. You create a char on arcanenites.com 7000 and you just type mccp once you are logged on. Depending on which config flag it is, it either activate or deactivate it. If you logged with it inactivated it works the first time when you activate it , then send gibberish if you deactivate/reactivate, if you log with it already activated, you will deactivate it, and when activating it it will send gibberish. Pretty consistent behaviour. On other client, if activated, you can have gibberish send directly when you log (as with the otherwise webclient that a member of the forum made) (cant remember name atm…will look if you are interested)
Thanks! I was testing a patch someone provided to Mudlet at https://bugs.launchpad.net/mudlet/+bug/1... and it seems to be working, so expect this to be fixed in Mudlet soon.
The other thing - for another topic - is that the MUD doesn't seem to send a GA nor a newline signal when it's done sending all data, so Mudlet doesn't 100% know when to display received data on the screen. For this reason, there's a small delay between the first lines and the prompt showing up on screen. Usually there's an option to enable either one to be sent but I couldn't find it on this MUD.
I remember discussing this recently with some one who didn't get that Mudlet does not claim VT100 compatibility - so sending it ANSI ESC codes that would clear the 25 screen lines and return the cursor to the top-left on a VT52 or later terminal is not a good idea - if you really, really, really want to put a blank screen in front of the user the best hope for you would be to ensure you negotiate NAWS and take a note of how many lines the Mudlet client reports that the user currently has for their "main" console for your MUD and then send that many new lines to scroll the existing content off the screen (and hope the user does not have a trigger to nuke empty lines of MUD output)…
For the record - part of the reason we do not respond to that sort of command is that having the Server modify output that has been received and processed is not going to happen - you send stuff to Mudlet - you cannot change your mind about it afterward…
14 Aug, 2018, Rarva.Riendf wrote in the 14th comment:
- if you really, really, really want to put a blank screen in front of the user the best hope for you would be to ensure you negotiate NAWS and take a note of how many lines the Mudlet client reports that the user currently has for their "main" console for your MUD and then send that many new lines to scroll the existing content off the screen (and hope the user does not have a trigger to nuke empty lines of MUD output)…
Or the clear screen ansi esc code could juste be interpreted by the client side like that. Basically what some other clients are doing. It basically is what most people need anyway, just making the old text 'disappear' from the viewer. Like the world disappear when you blink your eyes.
command to activate/deactive mccp is simply mccp
The problem appeared somewhere in time, and unfortunately, I do not seem to be able to find the version of my code that "worked"….
(it may be cause at the time I used mushclient…and that it maybe worked in it as well as in gmud, have to check about it)
So here is the problem:
If I log, with mccp disabled, and then enable it, then disable it, then reenable it; it sends the compressed buffer. if I disable mccp it goes normally, but from there I cannot ctivate mccp again and have it works.
if I log with mccp enable in char config, same problem as well as soon as I disable it, I cannot activate it anymore
I used the debugger to check what method are called and variable value, nothing different from first activation to second one.
So basically it muse be some negociation that I have to do again, but I do not know wich, I pretty much just copy pasted code without looking too much into it. I use Kavir protoccol handler.
If anyone had the same problem, or have a protocol test that would detect the problem that would be nice to drop a msg to explain where I need to look.
The problem is sligthly different if I use http://www.mudportal.com/play
In this client if I quit the char with mccp enabled (working) next time I log, it forces mccp off and if I activate it , it goes wrong straight away.
and in Gmud it works fine (and I checked, it works fine in mushclient as well)
Funny thing though, the "clear" command only works in Gmud and in pure telnet….
Either my code is really funky or clients are weirds…