ROM Prompt Bar Example/Tutorial

[jeniferirwin]

#class {prompt.tt} {open};
#split {0} {2};

/*
    PROMPTBAR EXAMPLE SCRIPT FOR ROM-BASED MUDS

    After quite a lot of tinkering around and experimenting on a couple
    different MUDs, I've developed what I believe to be the most beautiful
    prompt in the world. (I'm very humble, you see.)
    
    This particular prompt uses the above split statement to create a
    'statusbar' region to display nicely formatted values in.

    I would guess that prompt customization is usually one of the first
    things that people try to do when they get into scripting beyond simple
    aliases and triggers, so I decided to make this file as a bit of a
    prompt tutorial for people who are new to tintin++ scripting.
    
    Maybe it can even show scripting veterans a trick or two as well!
    
    It is possible to change the width of the prompt by fiddling with the
    formatting numbers in build_bits and build_chunks. On MUDs with a lot
    of prompt tokens available, you can make lots of chunks and construct
    huge 78-column superprompts that are a treat to behold.

    You will notice that this script does not actually make use of tintin++'s
    built-in #PROMPT functionality. The reason for this is that when I tried
    to use that functionality for my superprompts, it just didn't go well. I
    feel that I have more control when I make my own aliases and actions.

    NOTE: This script has some experimental formatting in it. I thought it
    might be easier to read really long #format statments if written thusly:

    #format {varname}
        {%fmtstring}
            {$var to insert}
            {$var to insert}
            ...
    
    For example:
    
    #format {list_of_names}
        {%s, %s, %s}
            {$person[1]}
            {$person[2]}
            {$person[3]}
            
    This wouldn't be needed for all format statements, only the ones that go
    over 80 columns or are just a bit messy to look at.
*/


/*
    THE SETPROMPT #ALIAS
    
    On ROM-based MUDs, these are usually the basic prompt tokens and what
    they mean, but this script can be adapted to other tokens too:

    %h -> current hp              %H -> max hp
    %m -> current mana            %M -> max mana
    %v -> current move            %V -> max move
    %g -> gold                    %s -> silver
    %a -> align                   %X -> experience to level
    %c -> carriage return
    
    The reason that I have the string '=PROMPT=>>' prefixed to the prompt
    below is so that it is almost impossible that the MUD (or another mortal
    player) would be able to output a fake prompt to me, accidentally or
    otherwise. You can set this prefix to whatever you like. Think of it as
    a password that you're using to validate your prompt. You will have to
    change this string in the #ALIAS, #GAG and #ACTION below.
    
    The #GAG statement is important because it keeps us from having to see
    the raw ugly prompt. We only want to see the nicely colored prompt bar!
    
    With this alias present, you can just type 'setprompt' to immediately
    make your in-game prompt compatible with this script, assuming the prompt
    tokens work as described in the list above.
*/


#GAG {=PROMPT=>>};

#ALIAS {setprompt}
{
    #send {prompt =PROMPT=>> %h|%H|%m|%M|%v|%V|%g|%s|%a|%X%c};
};

    
/*
    THE PROMPT #ACTION

    Several things happen when we receive our prompt from the MUD.

    First, we collect all of the values into 'raw' variables, stripping any
    whitespace off of either side.
    
    Then we update the 'prompt bits', which are the smaller building blocks.
    Prompt bits are each individual prompt value, but padded with spaces and
    colorized.

    Then we update the prompt chunks, which are the bigger building blocks.
    Chunks are groupings of bits, and they are visually grouped within square
    brackets.

    Then we finally update and show the prompt itself, building it out of the
    chunks.
    
    You will notice in the action and in the functions that I enclose all the
    code in #class statements. This is to make sure that all of our variables
    belong to this class, and can easily be cleared out en masse if the class
    is killed.
*/

#ACTION {=PROMPT=>> %1|%2|%3|%4|%5|%6|%7|%8|%9|%10}
{
    #class {prompt.tt} {open};

    #format {prompt[raw][hpcur]}  {%p} {%1};
    #format {prompt[raw][hpmax]}  {%p} {%2};
    #format {prompt[raw][mncur]}  {%p} {%3};
    #format {prompt[raw][mnmax]}  {%p} {%4};
    #format {prompt[raw][mvcur]}  {%p} {%5};
    #format {prompt[raw][mvmax]}  {%p} {%6};
    #format {prompt[raw][gold]}   {%p} {%7};
    #format {prompt[raw][silver]} {%p} {%8};
    #format {prompt[raw][align]}  {%p} {%9};
    #format {prompt[raw][tnl]}    {%p} {%10};

    #nop {
        The _null variable below doesn't actually do anything. These
        statements are written this way because if the functions don't get
        explicitly assigned to something, they will try to send their output
        to the MUD, and we don't want that. 
        
        Assigning to a local garbage variable is a way to force a function
        call to happen silently. Local variables disappear once the body they
        are in finishes executing, so _null will simply vanish after this
        action has concluded.
        
        I know that it is possible to use aliases instead of functions so
        that I don't have to do this weird null assignment. Here's why I
        don't do that: Using aliases as pseudo-functions can cause your alias
        list to get really cluttered and hard to navigate in a hurry. My
        belief is that if the user isn't meant to type in a given command to
        accomplish a task, it should probably be a function, not an alias.

        Beginners: You might notice that this comment is enclosed differently
        when compared to comments at the beginning of the file. That's
        because the C comment format doesn't work for in-body comments. If
        you're commenting inside of an alias, function or other tintin++
        command, you must use this 'nop' format to do so.
    };

    #local {_null} {@build_bits{}};
    #local {_null} {@build_chunks{}};
    #local {_null} {@display_prompt{}};

    #class {prompt.tt} {close};
};

#FUNCTION {build_bits}
{
    #class {prompt.tt} {open};

    #format {prompt[bits][hpcur]}  {<010>%+6s}  {$prompt[raw][hpcur]};
    #format {prompt[bits][hpmax]}  {<110>%+6s}  {$prompt[raw][hpmax]};
    #format {prompt[bits][mncur]}  {<020>%+6s}  {$prompt[raw][mncur]};
    #format {prompt[bits][mnmax]}  {<120>%+6s}  {$prompt[raw][mnmax]};
    #format {prompt[bits][mvcur]}  {<040>%+6s}  {$prompt[raw][mvcur]};
    #format {prompt[bits][mvmax]}  {<140>%+6s}  {$prompt[raw][mvmax]};
    #format {prompt[bits][gold]}   {<130>%+6s}  {$prompt[raw][gold]};
    #format {prompt[bits][silver]} {<170>%+7s}  {$prompt[raw][silver]};
    #format {prompt[bits][align]}  {<100>%+13s} {$prompt[raw][align]};
    #format {prompt[bits][tnl]}    {<160>%+12s} {$prompt[raw][tnl]};
    
    #nop {
        Those last few bits are padded with a lot of space because in this
        example, our bottom prompt bar holds fewer values than the top bar.
        These values are being padded more to help the bottom bar reach the
        same column length as the top bar.
    };

    #class {prompt.tt} {close};
};

#FUNCTION {build_chunks}
{
    #class {prompt.tt} {open};

    #format {prompt[chunks][hp]}
        {<110>[%s<010>/%s<110> hp]<070>}
            {$prompt[bits][hpcur]}
            {$prompt[bits][hpmax]};

    #format {prompt[chunks][mn]}
        {<120>[%s<020>/%s<120> mn]<070>}
            {$prompt[bits][mncur]}
            {$prompt[bits][mnmax]};

    #format {prompt[chunks][mv]}
        {<140>[%s<040>/%s<140> mv]<070>}
            {$prompt[bits][mvcur]}
            {$prompt[bits][mvmax]};

    #format {prompt[chunks][coins]}
        {<130>[%sg %ss<130>]}
            {$prompt[bits][gold]}
            {$prompt[bits][silver]};

    #format {prompt[chunks][align]}
        {<100>[%s al<100>]}
            {$prompt[bits][align]};

    #format {prompt[chunks][tnl]}
        {<160>[%s tnl]}
            {$prompt[bits][tnl]};

    #class {prompt.tt} {close};
};

#FUNCTION {display_prompt}
{
    #class {prompt.tt} {open};

    #format {prompt[rows][top]}
        {%s %s %s}
            {$prompt[chunks][hp]}
            {$prompt[chunks][mn]}
            {$prompt[chunks][mv]};

    #format {prompt[rows][bottom]}
        {%s %s %s}
            {$prompt[chunks][coins]}
            {$prompt[chunks][align]}
            {$prompt[chunks][tnl]};

    #showme {$prompt[rows][top]}    {-3};
    #showme {$prompt[rows][bottom]} {-2};

    #class {prompt.tt} {close};
};

#class {prompt.tt} {close};

[jeniferirwin]

A couple of examples of superprompts that were made using this approach:

Abysmal Realms

Procedural Realms

[scandum]

That looks nice and clean.

One thing you could do is add:

#GAG {=PROMPT=>>};
#VAR {prompt} {};

That should add the prompt variable to the class, and then you wouldn't need to use #class open/close within each function.

Once the prompt variable is added to the class you should be able to modify it without it being removed from the class, as long as you don't use #unvar.

[jeniferirwin]

Oooh, that's awesome, I didn't realize that! I'll be using that to make scripts a bit tidier in the future, thank you!