Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ General ➜ Frustrated with GetLinesInBufferCount
Frustrated with GetLinesInBufferCount

It is now over 60 days since the last post. This thread is closed.     Refresh page

Posted by Magnum   Canada  (580 posts)  Bio
Date Fri 18 Oct 2002 09:40 AM (UTC)
Message 

/World.Note World.GetLineInfo (World.GetLinesInBufferCount, 1)

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:
Quote:

The line number can be from 1 (the first line) to the number of lines in the output window. You can use "World.GetLinesInBufferCount" to find how many lines are currently in the output window. This number is different from the sequential number of the line since the world opened. For example, if your buffer size is 5000 lines, and you have received 8000 lines, then the last line will be line 3000 in the buffer but "actual line number" (selector 10 below) will return 8000.

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...


/World.Note World.GetStyleInfo(World.GetLinesInBufferCount-1,1,1)


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. :(
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #1 on Fri 18 Oct 2002 09:26 PM (UTC)
Message
Quote:

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.


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.

Quote:

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


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

Quote:

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.


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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #2 on Sat 19 Oct 2002 12:38 AM (UTC)
Message
Thanks, Nick.

Your suggestions should make the task much easier than I thought. Cool. :)
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #3 on Sat 19 Oct 2002 04:33 AM (UTC)
Message
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
Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #4 on Sat 19 Oct 2002 08:24 PM (UTC)

Amended on Sat 19 Oct 2002 08:25 PM (UTC) by Shadowfyr

Message
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:

if perc > int(test) then
  world.colournote gfore,backc,output
else
  world.colournote wfore,backc,output
end if

should be:

if perc > int(test) then
  world.colourtell gfore,backc,output
  world.colournote world.normalcolour(8), world.normalcolour(1), " "
else
  world.colourtell wfore,backc,output
  world.colournote world.normalcolour(8), world.normalcolour(1), " "
end if

--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
Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #5 on Sat 19 Oct 2002 08:48 PM (UTC)
Message
--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
Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #6 on Sun 20 Oct 2002 01:25 AM (UTC)
Message
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
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

17,082 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home