Zugg Software :: View topic - [2.28] Packet breaks with #say in the middle foul up triggers

Posted: Fri Jun 20, 2008 3:19 pm

So having learned from your comments how Cmud can and will display a #say statement between packets I think I have a case where this is causing a problem.

Example:

Posted: Fri Jun 20, 2008 3:30 pm

If you want to look at an example of the #debugfile output for this I don't have it and it would be very spammy if I did have it. It should look exactly like the other umteen packet break examples I recorded for the ATCP bleedthrough issue if you want to grab one of those.

Posted: Fri Jun 20, 2008 4:30 pm

This is normal and cannot be fixed. Unless the first partial packet is in the middle of an ATCP or other control sequence, the text from the #SAY will always show up between the two packets. CMUD has no way to know that the first packet isn't just part of your MUD prompt or something. Both packets just look like normal text.

#SAY and #ECHO *are* delayed and placed at the end of the current network buffer (unlike #SHOW which is executed immediately). So if the MUD sends a lot of stuff at once, even if with multiple packets, then you won't always see the #SAY between the packets. But it is still very possible for that to happen as you mentioned and absolutely nothing that can be done about it.

Since you seem to see these problems more than most people I think you might be able to tweak your network packet properties somehow to increase your packet size. When I was testing the ATCP problems in previous versions, I certainly learned that the packets are *not* being broken at the server end.

Sometimes ISPs will break packets. and sometimes your router will do it, and there are also some settings in Windows to do it. You might do some Google searching or maybe someone else can post more information on how you might mess with your packet sizes in Windows.

Posted: Fri Jun 20, 2008 4:46 pm

Btw, many years ago in zMUD I played with something like this. That was before some MUDs used IAC-EOR, but the idea was that #SAY would only output after a newline was received. The idea of "waiting" for something form the MUD before outputting the results of #SAY was a disaster. You never want to wait for something that might not be received. For example, if the connection has timed-out or something.

Posted: Fri Jun 20, 2008 5:02 pm

I wonder if an exception could be made for MUDs that properly use EOR like they should. If a MUD uses EOR properly, and you know it does, either because the user's told you it does or because you've detected that (somehow - no idea if that'd work often enough to be worthwhile), then you know that a packet boundary without a newline or an EOR isn't a prompt. MUDs that can't use the protocol properly can be left in the cold Cool

Posted: Fri Jun 20, 2008 6:46 pm

Well, CMUD would still need to wait for the EOR character. Like I said, I dabbled with that kind of stuff in zMUD and doing any sort of waiting for something from the MUD just runs into all sorts of trouble. You have to do the wait in a background thread so that the entire application doesn't come to a halt while waiting for the EOR to be received. And doing output to the screen (or accessing any UI elements) from a thread is very tricky and difficult. It would be a huge amount of work and would probably cause all sorts of new unstable thread bugs that would be hard to track down. All for something that would only benefit on a handful of MUDs that use EOR.

zMUD has worked the same as this for over 10 years and this is the first time I have really gotten a serious request for this. And I honestly thing that ReedN can fix the problem even better himself via tweaking some TCP/IP window settings on his computer or on his router to minimize the packets being broken.

Posted: Sat Jun 21, 2008 12:00 am

For the next couple of weeks I'm still in Malaysia and that may be the cause of it, I don't know how many intermediate locations might be tweaking my network packets. I'll see how much this affects me when I get back to Oregon and have a decent internet provider again.

If this is still an issue at that point, I'll have to brainstorm. I could delay printing text myself if I was able to know from Cmud whether I was in a non-terminated line (when the mud uses EOR and hasn't finished a line properly either designated as a prompt or otherwise with a newline). That way it would just be setting a system variable on your side and I could take the hard actions of delaying the print on my part. But perhaps it won't come to that. I'll see if what happens when I'm back in the US.

Posted: Mon Jun 30, 2008 12:02 am

One other thing I've noted. The case above deals with a line without formatting on it. If I print/say occurs in between packets where some formatting was going on it messes up the text when it tries to continue printing the text on the next line. Is the formatting state properly saved in the cases where there is an intervening say/print between packets?

Posted: Tue Jul 01, 2008 4:53 pm

Yes, the formatting state should be properly saved. If you run into a specific case where a #say/print messes up the formatting, then post the raw input/output message data from the Script Debugger window so I can see exactly what is happening.

Posted: Wed Jul 02, 2008 12:39 am

Here's an example when I have a #say statement contained in an ATCP trigger. The context is that I have a flag set to lookup the next room (because I suspect the mapper isn't on my current room). When I've found the room it prints that it found the correct room, thus causing this issue. I artificially put in a #say to assure that it shows the issue:

The "[1;35m" is the issue:

Posted: Wed Jul 02, 2008 1:00 am

Yes, doing a #SAY in an ATCP trigger will have this problem. During an ATCP trigger, you are essentially working in "server mode" where CMUD is still at a low level of processing. The ATCP trigger processing is done at a much lower level than normal trigger processing. So the formatting state while in an ATCP trigger is still in the "server state" and not in the "user state".

In fact, I hesitate to recommend doing *any* output to the screen from an ATCP trigger. If you have to output anything from an ATCP trigger, it's probably best to use #SHOW since it treats the text as if it was received from the MUD (which keeps it within the server context).

If you find a problem with #SAY effecting formatting outside of an ATCP trigger, let me know.

Posted: Wed Jul 02, 2008 1:51 am

Couldn't the 'server state' be exited before the code for the ATCP trigger is run? So the ATCP trigger matches and finishes 'server state' and then executes the code from the trigger. Is that possible?

Or if it needs to run the code in 'server state' it could just execute the #say statements at the end after the 'server state' has finished.

As always, users tend to do things that shouldn't be done if they are at all possible to do. If this truly shouldn't be done, could Cmud ensure it won't with one of the suggestions posted here?

Posted: Wed Jul 02, 2008 3:01 pm

I dunno, it's not really been Zugg's philosophy in the past (as I understand it) to stop CMUD being able to do things like this. It's useful, for example, when you're setting up ATCP triggers for the first time, because you can tolerate it looking a bit poo then. But beyond that, it's just one of those things.

One thing you could try is using a very short alarm or an event to print the text.

Posted: Wed Jul 02, 2008 4:16 pm

It doesn't seem like as a user I should be able to execute things while Cmud is in a 'server state'. So perhaps if it wrapped up the detection of the trigger in server state, exited server state and then executed the code for the trigger. But I'm really guessing here because the first I knew about a server state was Zugg's post in this topic.

Posted: Wed Jul 02, 2008 4:20 pm

In cases like that I use #MESSAGE since it should disrupt the MUD output or it's flow at all, and to my understanding can't be trigger off of either.

Posted: Wed Jul 02, 2008 5:02 pm

Now you know why zMUD/CMUD doesn't normally trigger on anything at the "raw" network level. Sorry if it's confusing, but it was better to add ATCP triggers so that advanced users could use them to perform advanced functions on IRE MUDs. ATCP are not like normal triggers as I have explained. Yes, I could probably spent a lot more time making them more useable in the future. But I didn't want to hold up an important feature like this just because there were certain things that didn't work well. Most people who needed ATCP triggers just needed to capture data into variables and did not need to alter the MUD output during the ATCP trigger.

But this is my typical frustration too. I add a feature like ATCP support that is requested by several people. But I can't spend a month on making it perfect because there are too many other things that need to be worked on. So I release the new feature anyway so that 90% of the people who wanted it are happy. But then the other 10% of people come along and complain that it's not perfect. Makes me wish sometimes that I never bothered to add any new features.

So yes, of course this could be improved. Just like there are hundreds of other little things like this that could be improved. For example, CMUD shouldn't let you enter non alphanumeric characters into the name of a Class. But all of those things take time, and I'm only one person. I have to prioritize what I work on.

Posted: Thu Jul 03, 2008 2:09 am

Don't get me wrong, I love having ATCP available, it makes things so much easier I can't even begin to describe. The things I can do now with ATCP make this type of side effect of very little consequence.

Please don't interpret my posting of bugs to be complaints, as I'm just trying to help work towards a better CMud for myself (and for everyone else as well). I know you've planned to work on the mapper now and so if this type of thing needs to be ignored indefinitely to prioritize then I'm not complaining.