ftelnet.norip.xfer seems to have RIP clicking support?

[maliciouspastry]

Hello! Tried updating to the latest fTelnet today and everything is working fine except now when i left click on the applet (just to take focus and such) it seems to be sending RIP codes to the BBS, as input boxes show input and others just take the options in the string sent.

I am using the norip version with xfer as the title states. Something new go into the client that needs a Option set?

Thanks!

[rickparrish]

Mouse reporting was added to fTelnet to support the Synchronet Minesweeper door. This is off by default though, so if fTelnet is sending mouse reports then that means the server asked for them at some point.

Can you provide a hostname:port, username/password, and steps I can follow to reproduce the behaviour? I'll take a look at what sequences are being sent -- it's possible the server is enabling mouse reporting at some point, then trying to disable it before showing an input box, but fTelnet is not handling the disable sequence so mouse reporting stays on unexpectedly.

[maliciouspastry]

Sure thing,

Telnet: bbs.archaicbinary.net (23)
Websocket: bbs.archaicbinary.net (11235 WSS)

Website: archaicbinary.net

Currently I have 'downgraded' the fTelnet client to my previous version, do you have a way to use the newest one against the WSS host/port?

Edit: I put the latest version at https://archaicbinary.net/index2.php

You can use guest/guest to login, but wont need to go that far, ESC twice on the first screen and then just choose Login, its a normal text input from Mystic BBS. Clicking will send the strings here.

I don't believe I am sending any specific codes to enable RIP at all. It's enabled before loading any of my code, its just standard Mystic BBS at these stages.

[rickparrish]

Yeah, looks like the first thing it sends after connecting is ESC[?1000h, which enables mouse reporting (which is something unrelated to RIP -- SyncTerm and fTelnet (and maybe other clients) support mouse reporting in plain-old ANSI mode, which allows for games like Minesweeper to work really well as a BBS door).

So one fix would be to have your system not send ESC[?1000h when the client connects, so then mouse reporting would stay in it's default-off state.

If that's not doable, then another option would be to put ESC[?1000l (that's lowercase L) into your "press esc twice" screen, so then the mouse reporting gets toggled off.

If it helps, this is what I see logged when connecting (after the telnet negotiation junk):

~27[?1000h
~12                           ~13~10                                      ~13~10~27[1;1H~27[2J
~27[?7h~27[40m~27[2J~27[40m~13~10~13~10~27[0;1m~27[15C~27[32m~250~250~250~27[0;32m~250~250~250   ~27[1;30mA ~27[0mR C H A I C~27[5C~27[32mB ~27[37mI N A R Y   ~27[32m~250~250~250~27[1m~250~250~250~13~10~27[37m-.   ,-;"`-:-.   ~27[0m,-;"`-~27[32m:-.   ,-;"`-:-.   ,-;"`-:-.   ~27[1;30m,-;"`-:-.   ,-;"`-:-.   ,-;~27[5;1H~27[37m`=`,'=/~27[5C`=`,'~27[0m=/~27[5C~27[32m`=`,'=/~27[5C`=`,'=/~27[5C`=~27[1;30m`,'=/~27[5C`=~27[0;32m`,'=/~27[5C`=`,'=/~13~10  y==/~27[8C~27[1my==/~27[8C~27[0;32my==/~27[8Cy==/~27[8C~27[1;30my==/~27[8C~27[0;32my==/~27[8Cy==/~13~10,=,-<=`.    ~27[1m,=,-<=`.    ,=~27[0m,-<=`.    ,=,-<~27[1;32m=`.    ,=,-<=`.    ~27[0;32m,=,-<=`.    ,=,-<=`.~27[8;1H-'   `-=~27[1m_,-'-'   `-=_,-'-'   ~27[0m`-=_,-'-'   ~27[1;32m`-=_,-'-'   `-=~27[0;32m_,-'-'   `-=_,-'-'   `-=~27[9;1H~27[0m~27[255D
~27[26C~27[2B...the internet is dead...~27[37D~27[2BHit [~27[1;37mESC~27[0;37;40m] twice within ~27[1;37m15~27[0;37;40m seconds to continue...~27[63D

Non-printable chars are represented as ~ and then their ASCII value, so ~27 is the start of an escape sequence

[maliciouspastry]

Your right, it is sending it. I was not able to find this string in my ANSI file or anything else. Decided its probably before anything I can control in Mystic. Took a hex editor, loaded up mystic.exe and yup, its the first thing it sends.

[?1000h��������ÿÿÿÿ����|CLMystic BBS Version 1.12 A49������ÿÿÿÿ&���Copyright (C) 1997-2024 By James Coyle���connect�����XTERM���LINUX���ANSI����SYNCTERM����ANSI-BBS

This setting is hard-coded into Mystic, so I don't know what other Mystic sysops are doing, maybe they don't know about it, maybe they are disabling it using ESC[?1000l

I'll go the "correct" route and try using the disable command. Thanks for the assistance!

[rickparrish]

I wonder why Mystic is sending the mouse-enabling code if it's not then handling the mouse events.

And the mouse-enabling in fTelnet is recent-ish, so maybe nobody else has noticed yet.

[maliciouspastry]

I'm not sure, but its the first thing in sent via Mystic (looking at hex editor).

I've noticed it in a few other mystic boards, but I don't think the sysops are seeing it in action by not clicking on accident/etc. Maybe they update and just don't check, not sure.

Either way this is not a fTelnet issue at all, its 100% Mystic. I hex edited mine out due to how I handle the system but easily can be done with a ANSI file or whatever.

I have taken this "feature" and created a small GUI for my board to offer a "clicking button" launcher. Very simple. Also I had to send some more codes for SyncTERM to return the same vales as fTelnet. Either way, they match now and was able to create the buttons.

[rickparrish]

OK, will close this issue for now then. If by chance the Mystic devs think fTelnet should be doing something different regarding that command, feel free to reopen.

Out of curiosity, does SyncTerm do the same thing when you click while in an input box? If not, then maybe there is something that I should change in fTelnet.

[maliciouspastry]

I have not noticed the behavior in SyncTERM at all, using Mystic and using RMLib for all my projects.

I only got SyncTERM to accept mouse clicks when I sent it the 1002, 1003, or 1006. I had to use 1006 to get same coords as fTelnet, cterm.txt refers to it as "1006 - SGR encoded extended coordinates". My system sends the 1000h to enable it on fTelnet and then sends the 1006 to enable it on SyncTERM, and turns both off when it no longer needs mouse clicks.

I don't know why a simple 1000h does not do it in SyncTERM but does in fTelnet, maybe they are waiting on another code like I am sending.

[rickparrish]

I updated my Synchronet login screen to send ESC[?1000h, and found that clicking in SyncTerm caused garbage to be put into the input buffer, but DIFFERENT garbage than what fTelnet was sending.

Turns out my non-SGR mouse reporting was completely broken, because when I reviewed the SyncTerm code to see how it sends non-SGR mouse reports, I didn't really think about what it was doing and implemented it wrong.

For example it has a bit where it does '!' + x and I interpreted that as "send ! and then send the x coordinate", but really it was doing arithmetic. So if our x coordinate was 10 I would send !10 but really I should have been sending + (because ! is 33 plus 10 for x = 43, and + is 43)

I just pushed a fix for this, and then tested on a random Mystic system and found that clicking does not stuff garbage into the username box anymore!

[opicron]

I should have looked at the current issues before I went fixing the old source. Thanks for your continued support of fTelnet ;)!

[rickparrish]

Glad you came across this, I forgot that this had already been fixed!