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.
Entire forum
➜ MUSHclient
➜ General
➜ Has anyone heard of "INFOBAR"
|
Has anyone heard of "INFOBAR"
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Plazgoth
USA (10 posts) Bio
|
| Date
| Fri 31 Jan 2003 04:19 PM (UTC) |
| Message
| | The mu* I play has a feature called "infobar". Basically when you type infobar it is supposed to display your hp/mp at the bottom of the screen and as the mu* output scrolls by those numbers do not scroll up but get updated on regular basis. It's sort of like a speedometer at the bottom of my mu* output. Well the feature works fine and dandy if I use standard telnet to get in the game. But once I try using mushclient it does not work at all. I have tried looking at all the options in the "output" configuration and cannot figure out how to get it to work. I know in standard telnet I have it using VT100 so that is what i typed in Mushclient but the infobar still does not work. Any help will be greatly appreciated. | | Top |
|
| Posted by
| Shadowfyr
USA (1,788 posts) Bio
|
| Date
| Reply #1 on Fri 31 Jan 2003 07:11 PM (UTC) Amended on Fri 31 Jan 2003 07:24 PM (UTC) by Shadowfyr
|
| Message
| The reason for this is due to the fact that Nick has not added any character positioning function to the client. I suspsect that the bar you are talking about does something like this:
Save current position.
Gotoxy 1,24
Show bar.
Restore last position.
Since mushclient doesn't support the positioning functions, it simply ignores them and you just get a scrolling page. One possible fix is to use a trigger and scripting to capture and omit the offending line, then place the information on the built in infobar in the client.
There has been some discussion as to how the client should handle such text positioning, which has as yet gotten no place. Again Nick, I personally don't see the reason for it not being supported. True, any method that is used to buffer prior lines or log the changing text would be ugly and unwieldy, but I haven't seen any client, even back in the 80s-90s with BBSs, that haven't generated slightly screwy logs from such. Most treat the logged text as though anything without a hard return is on the same line and handle the scrollback by making it only track what actually scrolls off. Yes, this is inaccurate, but no one has ever come up with a better way to do it and it works well enough for playing, which is the point, not if the buffer remembers every single character and line on the display. Games that generate a display, but never scroll any data simply never produce a buffer of the text recieved (unless they include a clear screen command which in most terminals and even in the DOS window, is technically 'generate height + 1 blank lines and return cursor to 1,1', thus technically do produce a 'scrolled' page). Such screen rewrite do still produce a usable log file, even if they never 'scroll' the buffer. As far as I know, short of using the logged output as the back buffer, all clients that support such would do it that way. The arguement that 'most' muds don't use it is like arguing that most people never use more than reverse, park, nuetral and foreward on a stick shift so you should just eliminate all the other redundant gears. This would have no effect on about 90% of the people that buy them, and then only drive them on the road, but the people that go off road are bound to notice. ;) lol | | Top |
|
| Posted by
| Nick Gammon
Australia (23,120 posts) Bio
Forum Administrator |
| Date
| Reply #2 on Fri 31 Jan 2003 10:51 PM (UTC) |
| Message
| Yes, we have discussions like this every now and then. :)
For one thing, I am opposed to adding features that may appeal to only a small number, but bloat the program and make it less reliable. There are a host of problems with supporting cursor addressing. For example logging, but also triggers. Does this status text cause a trigger to fire? If so, when? Does a status line terminate a previous line for triggering purposes? What happens if you get disconnected? Does the "protected" line go or stay?
MUSHclient isn't a telnet program, and telnet programs are not good for playing MUDs. They are trying to do different things. It is like saying "I would like a sports car, but it would be great if it could carry 30 passengers, like a bus". The fact that you can see sports cars on the road, and also see buses, does not mean you can successfully make a vehicle that will do both.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,120 posts) Bio
Forum Administrator |
| Date
| Reply #3 on Fri 31 Jan 2003 10:53 PM (UTC) |
| Message
| | If you want to keep track of your HP etc. you can make a simple trigger that displays info on the status line, or see this post colour status bar which shows how you can do a colour status bar. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Shadowfyr
USA (1,788 posts) Bio
|
| Date
| Reply #4 on Sat 01 Feb 2003 01:37 AM (UTC) |
| Message
| I do agree in principle Nick. I the case of what he is talking about it is a definite problem. One solution however would be to treat 'any' request to alter the position of the cursor as though it was a newline. This would allow correct triggering. As for the other issues, as I have stated, even true telnet systems can't, don't and probably won't ever handle back buffers and logging of such things 100% prefectly. Most don't even try beyond what I have already described.
I do think that it is a feature that 'could' be used in some cases for nice effects, but in most cases you could argue that MXP color and inline pictures are rarely actually used as well. At least from what I have seen. The question I guess is how much bloat it would really cause and if allowing people to simply turn off support for it would really slow things down significantly. However, I must admit that one 'major' issue is how GUI environments are very unfriendly to such basic ASNI support as this and blinking text. :p It 'should' be relatively simple, but I have a fealing that the environment may make it unintentionally quite difficult.
In the best of worlds all such positioning would be replaced with real video animations and things like Mushclient's own info bar. Unfortunately there is almost as much outright hostility toward use of such things in some circles as there are for design of an LPC driver/library that is easy to install and use (because it would apparently encourage people to produce worse crap than some of the new muds already contain) or your own belief that some features are unnecessary. My own feeling is that such completely artificial limits imposed by client can have an unintentional negative effect. But that just is my opinion.
It does however create a problem for people that recogize Mushclient's capabilities, but literally can't use it due to such limits. If I had needed such.... | | 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.
15,116 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top