Zugg Software :: View topic

Sorcerer Joined: 15 Apr 2011 Posts: 809

It's very possible that I'm that misunderstanding how refresh rate works, so I'll try to summarize my understanding of it here:

With a refresh rate of 0, CMUD will only refresh the screen at the end of a packet, no matter how big that packet is.
With any other number as a refresh rate, CMUD will refresh the screen after that many lines, and also at the end of the packet if that number hasn't been reached.

If I'm totally wrong here, please let me know, and forget about the rest of this note.

If I'm right, with a non-zero refresh rate, if a packet has fewer lines than the refresh rate, the screen should only get refreshed once, at the end of the packet. It shouldn't get refreshed in the middle, since the line quota for refreshing hasn't been met. Similarly, with a refresh rate of zero, the screen should also only get refreshed once, at the end of the packet, since that's what refresh rate zero does. Am I wrong in either case here?

If I'm right once more, refresh rate zero is not working. I tested this with aardwolf's rank command, which sends about 300 lines in one packet. I used the raw input/output option of the script debugger window, I am positive that everything is being sent in one packet, and there are no GA/EOR markers in it as far as I can tell, not knowing what those are. If it would actually show GA and/or EOR in the output, then there are none. (EDIT: I disabled Use GA/EOR in my preferences and tested this again, with the same results, so I'm positive that's not affecting it). I tested this 4 times, these were the results.
1) With a refresh rate of 1000, the screen only gets refreshed once, at the end of the packet. I don't see the rest scrolling by, I only see the last 30 lines or so of the output (the height of my window). This is expected, since only 300 lines are being sent, and it's not supposed to refresh until 1000 are sent, or until the end of the packet is reached. (EDIT: This also confirms that everything is being sent in one packet).
2) Then I moved my refresh rate up to 30 and sent the same command. This time I saw the entire 300 lines scrolling by, but very quickly and jerkily. It looked like it was being refreshed every 30 lines or so.
3) Then I moved my refresh rate up to 1 and sent the same command. I still saw all 300 lines scrolling by, but it was much smoother and took longer to scroll by. These first three cases, if I understand refresh rate correctly, are working right.
4) Finally, I set my refresh rate to 0 and send the same command once more. Again, if I understand refresh rate correctly, this should have only refreshed the screen at the end of the packet, not at all in the middle. It should have looked exactly like it did when my refresh rate was 1000. I was surprised to find that of the three cases above, refresh rate 0 most resembled case 3, a refresh rate of 1. It definitely isn't only refreshing at the end of the packet, since if that was the case, I wouldn't see any scrolling, only the last 30 or so lines of the output, which simply isn't happening.

Hope this helps track down the bug, if there is one.
Daern

Posted: Fri Apr 22, 2011 6:34 pm

You understand it correctly. That is how it is supposed to work.

I suppose it's possible that some "fix" over the past couple of years has messed up the case of setting refresh to zero. I'll add this to my list to look at. But honestly, I'm not too concerned about this. The zero setting was never a viable setting for normal use since it would cause you to miss seeing a lot of stuff on the screen. And you can mimic the zero setting by just setting it to a very large number (like your case #1).