Frustrated with GetLinesInBufferCount

Should that not repeat the latest line in the output window (with the styling stripped)?

It doesn't seem to work properly for me. More often than not, I just get a blank line outputted instead of what was the latest line.

Same problem if I use World.GetStyleInfo.

From the online help for GetLineInfo:

Huh?
If your buffer size is 5000 lines, and you have received 8000 lines, then should not the last line be 5000?

Clearly I am dumb on this one, since my buffer size IS 5000, and if I CTRL-HOME I see that stuff has scrolled off beyond the buffer size, yet if I "/World.Note World.GetLinesInBufferCount" the answer is < 5000.

Anyway...



Seems to work somewhat, although it seems a bit erratic... but maybe that's the rest of the code I am working with (It's someone else's, that I am attempting to edit).

Ahh... I think I just discovered part of the problem. The prompt, of course.

If the prompt is displayed, then GLIBC is indeed the latest line, with the prompt. If there is no prompt, then GLIBC is blank, and GLIBC-1 is actually the latest line.

In Other words, GLIBC is the line number where the next string output will be displayed. Often, this is the next blank line that hasn't actually been displayed yet.

This isn't reliable to function on, though, since the placement of new strings (on a prompt line or not) are far too chaotic to attempt to track them.

GRRRR!

I could configure the mud to newline when it shows a prompt, but then my input commands often end up at the end of incoming lines, which looks rather unappealing visually. Also, more blank lines, and I have enough of those already.

Well, so far it looks like my exploration into colourstyles is a dismal failure. I may have to look to ShadowFyr to write my stuff for me.

Shadowfyr: This all came about because of the "HitBar" plugin. I noticed it prints the "HP: [" in grey rather than blue, which is my configured health bar colour. In other words, I saw that it was grabbing the wrong colour style, and wanted to figure out why).

Man, I'm cranky cause there is no food in the house and I am starving. My apologies. :(

MUSHclient always has a "current" line, even if it is blank. That is, if the last line has received a newline, then it creates a new, blank, one to receive incoming text. In GetLineInfo look at:

2: length of text (short)
3: true if newline, false if not (boolean)

You could test "length of text" to be non-zero, or "newline" to be true. If not, go back a line or two until it is.



Documentation error. I have amended that to read "around 5000".



For efficiency reasons MUSHclient actually discards lines in blocks of 100 when the buffer fills up, so the line count will actually be in the range 4900 to 4999 if your buffer size is 5000, which explains the results you are getting.

I have amended the page for GetLineInfo to explain both those points.

Thanks, Nick.

Your suggestions should make the task much easier than I thought. Cool. :)

Oops.. Actually I hadn't notived that magnum, my own hitbar is normally colored using a trigger (to make it a different color that other stuff that may use that color). So I didn't realize the bug was there. If you manage to find a way to correctly patch it, please do so and send me the fix so I can update my version. ;) lol

Oops again.. I forgot the real reason for doing this. I had assumed as I said that the prompt was gray (not having seen it in the normal color since about a week after starting to play) so I figured this would solve a problem with prompts.

What problem? AoD is lazy about them and assumes that any line in the client 'prior' to a prompt will look like>

Esc[32m Hello there!Esc[30m

Been a while since I used ansi codes, so I could be partly wrong with my example. lol But the point is that normally all lines are terminated with the default text color, usually low-intensity white (i.e. gray). Mushclient generated lines do not do this, so the prompt if it arrives after one of these lines ends up the same color as the last style used in the note or tell produced by the client. Thus the plugin should use world.colournote world.normalcolour(8), world.normalcolour(1), " " as the
last line, not world.colournote gfore, backc, " ". Also, this bit:

--Nick-- This imho should be a default behavior anyway. While it is true that technically this should be done correctly by the muds, many of them do cheat once in a while when they think they can get away with it and not having the color from tells and notes reset to the 'normal' color, like 99.9% of mud sent lines means, adding this extra step each time. More importantly, since the length of the line may possibly be exactly 80 characters, not being able to imbed such a style change at the end with a NULL string can create an additional problem in the form of an unintended line wraps. :p

--Nick-- You really need to make sure to read these.. :p

I just discovered that this doesn't work>

world.colournote world.normalcolour(8), world.normalcolour(1), " "

Neither do the following>

world.colournote "#" & hex(world.normalcolour(8)), "#" & hex(world.normalcolour(1)), " " - Gives an expected end of statement error.

a = "#" & hex(world.normalcolour(8))
b = "#" & hex(world.normalcolour(1))
world.colournote a, b, " " - Is just plain wrong.

and as every one knows quite well... Using &h instead of "#" is flacky, since it messes up with stuff like "00FFFF" and didn't seem to work right when I tried it anyway (neither did the form 0xFFFF from VBscript). Put simply world.normalcolour(x) returns a value that when converted to hex is backwards. i.e. it is Blue, Green, then Red, while the string needed is Red, Green, then Blue. :p There appears to be no 'easy' way to get around this... We either need some way to return each color component seperately or to retirieve the color in the correct format. Otherwise what should have been a one line command becomes a minimum of 5 lines (this assumes a mathematical solution, but other way could be far worse).

These commands are after all intended to simplify matters, not make then worse. ;) lol

Here is an example Nick>

a = world.GetLinesInBufferCount
b = world.getlineinfo(a-1,11)
world.note b
c = world.getstyleinfo(a-1,1,14)
d = world.getstyleinfo(a-1,b,14)
world.colournote "#" & hex(c),"black",hex(c)
world.note hex(d)

The result of the one that uses the returned color is not the color that was returned and there is not only no easy way to convert it to the right order, but some commands won't accept or bug on versions that use the correct order of bytes. :p