Virtual Split Screen in TF: a theory
I've mentioned this to a couple people already, but I figured I'd go ahead and post it for anyone who might have the skill and inclination to write it.
Years ago, TFPREFIX became a standardized 'add-on' in the MU world. Keep this in mind, because it's useful to the rest of this post.
While I was working on PIGLet, the natural 'next step' after ascii graphics would have been animated ascii graphics. Last time I publicly discussed this, there were lots of ideas being exchanged and even some progress demonstrated (@prompt is cool, but apparently not immediately handy to what I have in mind).
What I picture in my mind as the end solution is a 'split-screen' view: 10 lines of "console" (this is the new part, read along for explanation), followed by normal output from the MU, followed by input window.
The biggest obstacle during discussion was that TF5 doesn't natively support split-screen output window (to divide the output per above). But, this past week, I put a few other pieces together in my head which can work as an initial work-around for getting this ball rolling.
A custom tf definition (ala /def) which uses TFPREFIX with a hook for CONSOLE window lines. This /def would use some basic math to do a full screen refresh (kind of clunky, but at least it's a way to get this thing started) of:
> Last
>
> ten
>
> lines
>
> of
>
> CONSOLE
> OUTPUT
> -- separator line --
> Remainder dedicated to
...
> normal output.
> -- separator line --
> input
> window
... this would likely need to be a full-screen refresh once-per-transmission (from server to client) -- thus the 'clunky' reference above. But still, it seems possible.
I know height() can be retrieved (THROUGH tf) from PuTTY, so... it appears all the tools are here for making: ascii movies, enterprise view screens, realtime D&D (nethack?) maps, etc..
Personally, I do not have the necessary tf skill to put this together.
Anyone out there have the necessary tf skill to put this together so that the artsy-fartsy types can start work on making pretty stuff while the clients/servers have a chance to get on the same page? If so, please post!
- Trispis's blog
- Login or register to post comments
Click 
Depicting Moments in Time
Below, you will find an arbitrary example of how I would imagine sending "console" information.
This has implications of 'global' as well as 'personal' application (i.e., it's assumed this could be an "either one and/or both" application, so I'm rolling with 'both', generically, for now.).
@@
&C [get(me/~)]=[null(iter(lnum(0,9),pemit(%#,get(%#/TFPREFIX)C[itext(0)] [u(me/C`[itext(0)])])))]
@@
&C`0 [get(me/~)]=[mudname()] - [name(%#)] - Connected: [timestring(conn(%#))] Idle:
&C`1 [get(me/~)]=
&C`2 [get(me/~)]=
&C`3 [get(me/~)]=
.
.
.
Okay, stop.
Before taking this example any further, it's important to note that it's the &C attribute which is controlling it all; and, that it is sending a 'protocol'-based data unit. Specifically the 'C<line num>' information unit. It is here that the 'application' (this softcode) speaks to the client, identifying where/how the information is displayed. And, thus, it is here that a protocol must evolve if this is to happen at all.
However, it appears that line numbers will be one of the rudamentary units of overall design, bringing to rise a few points which can be elaborated and/or commented upon.
* it doesn't matter whether the lines are numbered 0-9 or 9-0. one way works as well as another - but, it is a decision which must be made at this precise location in the information exchange process and should not be decided by softcode alone. in the end, though, it must be agreed upon by both the application and the client.
* if the display design expanded to manage 'per pixel' information (pixel == single character display unit) , the protocol may or may not need further adjustment, but it's still a feature which should not be dictated by softcode alone. nonetheless, it is a potential worth considering (e.g., the ability to send a 'sequence of colorized ascii and/or unicode characters' to be displayed in a single location on screen - managed by the client - to allow more than one-per-second 'frame rate' in animations).
Finally, note that it is at the location of this 'protocol' - the connecting point between application and client - that the servers and clients can work on developing these features in more efficient - hardcoded - manners... possibly eventually working in those @prompt features in some way.
But, of course, this is all just a theory...
How about MUSHclient?
Doing this in tf will be painful.
Doing this in mushclient, maybe much less so.
MUSHclient supports, for each world, a separate window called 'notepad', and has a scripting language that allows you to write to, clear, redraw, etc. in the notepad window. So you could write a mushclient script that detects certain kinds of output from the world and then does stuff in the notepad window (which can be stacked up vertically, horizontally, whatever, with the world window).
This doesn't change the end that you're describing, but might let you actually implement this with much less work.
Marquee the sod.
Painful, but possible, in tf.
Painful (if you don't know any of the scripting languages), but possible, in MUSHclient.
Painful (if you're unfamiliar with spawn windows), but possible, in SimpleMU.
Back in April when I was planning for the Arts Fest, I had already asked myself the question: Can this be done?
The answer was: Sure. SimpleMU and MUSHclient can do it, but...
... can it be done in TF?
I think I've now resolved the answer to that question.
... at least theoretically.
And, afterall, this is just a theory.
I'd say: Painful, not worth
I'd say:
Painful, not worth it, in tf.
Tricky, with a learning curve, in MUSHclient and SimpleMU.
Worth
The 'worth' of doing it in TF is immeasurable for one reason.
If it gets done in TF, it gets ported to all other clients capable of supporting it.
If it gets done in MUSHclient, it becomes a MUSHclient novelty.
Understanding the social dynamic of the MU-niverse - knowing the universal impact of this butterfly's wing flaps - is as important as the protocol (mentioned above) necessary to support the process.
I disagree. The work
I disagree.
The work necessary to make it work in tf is entirely tf-specific. Teaching it to handle another screen region with ncurses or slang or whatever library it uses is a totally hardcode operation specific to tf. Then writing tf macros to handle the output from the server is specific to tf.
You'd have a proof of concept, but nothing portable/transferable.
You're right in only one sense, I think: If MUSHclient and SimpleMU both implemented this (fairly painless), the tf maintainers might ignore it - because it's not worth their effort. If tf implements it (painful), the MUSHclient and SimpleMU maintainers probably would provide scripts for it, but only because it's relatively painless for them!
And
You're right in only one sense, I think: If MUSHclient and SimpleMU both implemented this (fairly painless), the tf maintainers might ignore it - because it's not worth their effort. If tf implements it (painful), the MUSHclient and SimpleMU maintainers probably would provide scripts for it, but only because it's relatively painless for them!
Isn't that what I said?
p.s.
In my mind, it's not worth it to do it at all (at least not worth it to me to apply my coding skill to the task), if it's not client-indifferent on the softcode end. Not sure about you, but... personally, I won't waste a keystroke on softcode that doesn't work in all popular clients (and I'm beginning to apply that philosophy to popular servers as well - what's the point in writing something if it only works in some niche envirionment?).
Javelin is right here, on a
Javelin is right here, on a MOO where i admin the @list command was updated so that if you provided a 'with prefix' option to it it would swap the line numbers for the TFPREFIX (eg. TF>), then you just set a Mushclient trigger up to watch out for that prefix and when it finds it start sending it to the notepad window and omit the output from the screen.
So much you can do with mushclient triggers.
Possibly useful
Found this script
http://home.insightbb.com/~nathanj/achaea/scripts/prompt.tf
which creates an additional 'status line' using realtime data from the game.
screenshot here at the very bottom of the page.
Expand this notion so that it manages an array (lines, spaces, etc.) and voila: Console in a separator-box.
The only thing left thereafter is developing the protocol for sending data. Once the protocol is defined, other clients can write supporting scripts.
(Thanks to Mark @ Imagine.)
Aha
I never knew about the status_height variable. That could indeed be just what you need.
See /help status area
Neat.