Hi folks, i'm struggling to receive a long text string from a button return, it seems to work fine up to 39 characters, but if I receive any button text reply from a BTT packet longer than around 40-45 characters I start to get corrupted data back in my reply string.

I'm not 100% sure but I think that the length identifyer is always maxed to, but I may have that wrong, i'm searching for a chr[0] termination on strings but the corruption is problematical - and i'd like to receive long replies.

In fact, i'd like to receive buttons about 256 characters long - but I guess I can keep on hoping for that eh .

Actually my length problem could be fixed if Cflags was included in the BTT packet

I just tested a dialog button with the typein maxed to 95 and was able to receive 95 chars without any issues.

OK, so it's me, but are you absolutely sure? I only ask because i've packet decoded and every single time byte 39 is value 5 and byte 40 is value 0, which terminates the string, after which is random data (it is the correct length but not what is typed). I'm either not understanding the ISP_BTT format or it's bugged.

Looking at what i'm seeing arrive on the socket - I honestly dont see how the problem is within my scope.

Accepting that you have tested this and it worked for you, i'm running the hunch that another factor is polluting the result, so this is one of my button declares - would you mind testing the same button please and seeing what happens?

This is where i'm decoding the BTT packet


LFS Version: Dedicated Server X2.

Ok, good news, bad news. You're not crazy, it is a bug. But apparently only if you go through a dedicated host. I.e. i did my testing connecting directly to an LFS client and all worked. Then i set up a server and connected a client to it and my insim code to the server. Now text from the dialog is always 42 bytes followed by zero bytes and even with those bytes, the last few are garbage.

And it's not a dedicated server problem, it looks like a problem with how the client and server communicate and what gets passed on. I.e. i also set up a client/server where the server was the full LFS and then i tested the dialog on both the server and client. The server version came through clean, the client version got munged.

BTW, you were talking about length earlier and that it's always maxed out. Do you mean the TypeIn byte? If so, that byte does not tell you how much text you have received but what the initial legal limit was on the button creation.

Thank you, you had me totaly dumfounded when it worked for you! We now need a Scawen .

On the length thing, when I first wrote my button interpreture i'd figured it out, then moved on and promptly forgotten about it until I came across this bug, I realise that it's the 0 char termination - I just use length as a maximum for the loop but actually I should use while/wend as it'd be faster.

Thanks for the report. Now noted for investigation. I don't know if it's host-side or guest-side until I catch it in the debugger.

Also fixed another guest-side bug that Victor found - INST_ALWAYS_ON does not work on guest buttons sent from the host, unless the guest happens to have its own InSim connection.

It may be that Test Patch X3 should go on the auto updater system for these fixes and another few fixes for reported bugs.

The fix turns out to be on the guest side (as is the ALWAYS_ON fix).

My plan is to release X3 dedi and guest on Friday as usual for a patch.

Then if X3 goes well I guess it will probably go on the auto updater.

Thank you Scawen, that's saved my bacon