General Overview

UnTar

tar zxvf tintin.dyrdex.tar.gz

Setup

I stupidly wrote all paths relative to executing everything from within the /tintin directory. So, first off:
cd /tintin

Main Connection Command

./src/tt++ newtin/main.tin

(Probably want to setup a shell alias to do this for you). 
I have this in my .bashrc:  
alias runtin='~USERNAME/tintin/tt++ ~USERNAME/tintin/newtin/main.tin'

main.tin script explained:

1 Alias, 1 Event, 3 Actions

#ALIAS          {go %0} {#ses %0 realmsofdespair.com 4000;%0;PASSWORD;&& \x0D && #split};

Usage: go CHARACTER

This opens the session realms. 
Assigns the session name as your character name. 
It also enters the character name to the realms login screen, followed by your password.
It then hits enter twice to pass the welcome screens. 
It then tries to split the screen, however, this part doesn't really work and can be removed probably. 

#EVENT          {SESSION CONNECTED} {#VARIABLE {char_connected} {%0}};

This event creates a variable named $char_connected based on whatever value you entered in the login alias (i.e. your character name)

#ACTION         {Welcome to Realms of Despair} {.....

This action fires upon the Welcome message. Using the char_connected variable established upon #EVENT above, it then reads the char's config. 
#CLASS ${char_connected}_up {read} {newtin/characters/${char_connected}_up_stuff.tin}

This reads the characters unique configuration and loads those actions/aliases under the class name CHARNAME_connected_up. 

Next, standalone 'modules' are loaded: 
#CLASS {nowrite} {read} {newtin/mod_config.tin};

These are loaded under the class 'nowrite'. 
There is nothing setup to write aliases/actions in this class to a file upon quitting, so thus, they remain in their original files 
and don't get written under your character or class config. There are many modules being loaded by this, 
read newtin/mod_config.tin to see, then read each of the modules themselves to see what they do. 


Finally, it runs the 'score' command in game, which is used to set other variables. Then just 'looks' so you know where you are upon login. 

#ACTION         {Class: %0 %1} {

This is triggered by the Class line in the 'score' command send above. This sets the $char_class to your class. 
This then reads in the class config by regex'ing your class against the values in this config: 
#CLASS {nowrite} {read} {newtin/scripts/class_genre_conf.tin}

Based on which line the regex of your Class matchs in that file, it reads the corresponding class config from: 
/newtin/classes/CLASSNAME.tin

Finally there is an action based on my membership in Dragonslayer, which set's up some stuff based on the heal/recall names used by DS, allows me to restock from their potion storages containers, and navigate around their hq to do things like restock recalls.

You could remove this, or revamp it for other organizations.

Important Usages when connected as such

I've mentioned the classes I've setup a few times now. To explain:

Things setup in your specific character config are loaded under a class named CHARACTER_connected_up. By default this class is OPEN after login.

That means any new aliases or actions you setup are setup under that class.

Upon quitting the game, that class is written out to your individual character config. Thus, saving your new stuff.

However, you may not want to actually do that, you may want to save new stuff to a CLASS config, or, not save it at all.

There are aliases setup by which you can change which class is OPEN on the fly.

classwrite
  -Open the 'class_connected' class, and anything setup while this is open is written to your CLASS config upon quitting. 

charwrite
  -Open the char_connected_up class. and anything setup while this is open is writen to your CHARACTERS config upon quitting. 

Read /newtin/scripts/quitscript.tin to see how those happen. 
That quitscript.tin is one of the 'modules' loaded via mod_config.tin. 
 (so main.tin loads modules from mod_config.tin, which loads the 'quit' module from scripts/quitscript.tin)

All other scripst that get loaded or read will have headers/footers that do so under the "nowrite" class, so they don't get written out upon quit. 
i.e. they stay in their original script, and don't end up in a specific char/class config.

Also, I never got the #split command to work correctly to give you a clean line to enter new text upon at the bottom of the terminal.

If you see a bunch of #split stuff in scripts, it's all me attempting to put that at various points to make it work, and none of them work. 
So, I setup an alias 'line' you can use to give yourself a clean input line. 
However, a new problem is that this screws up the heal/hit triggers because it overwrites the prompt that stuff works upon. 
Solution is to actually switch to using the tintin prompt instead of the realms prompt. Kinda started that, but not ready yet.

Modules

Let's look at the various modules that get loaded when main.tin calls mod_config.tin.

mod_config.tin itself: 

#CLASS {nowrite} {open};                     --Open 'nowrite' class so all this stuff is global and not tied to a char/class. 
#READ newtin/scripts/dirslist.tin;           --A list of speedwalking directions. Not Complete. 'goBLA' to go to area shorthand name BLA
#READ newtin/scripts/quitscript.tin;         --An alias for 'quit' so that it saves char/class aliases/actions to their respective configs. 
#READ newtin/scripts/idlescript.tin;         --A simple script so that your character doesn't dissappear into the void or get auto-logged-off
#READ newtin/scripts/basic_utilities.tin;    --A LOT in here. I keep adding to it. I've commented the script itself, and not everything there is functional yet. 
#READ newtin/scripts/onoffs.tin;             --Enable/Disable specific triggers for specific purposes. Re-apply spells as they run, turn autofight on/off, etc. 
#READ newtin/scripts/speech_logging.tin;     --Set up logging of speech lines to a file (at /tintin/speech_log.tin)
#READ newtin/scripts/inv_vars.tin;           --My attempt to setup inventory tracking so I could setup auto-restocking triggers. Not complete at all. 
#CLASS {nowrite} {close};                    --Closes the 'nowrite' class because we're done loading stuff. 
#CLASS {nonfight_recast} {read} {newtin/scripts/nonfight_recast.tin}    --auto recasting of failed spells when NON-Fighting, cuz fighting is different case. 
#CLASS ${char_connected}_up {open};          --Opens the standard character class so that any new stuff you do goes to THAT characters config. 

Most other functions within these scripts rely on setting variables for things like your preferred 'hit', the container which holds your potions ($pot_con, and the container which holds your recalls ($item_con). There are alises built into scripts/basic_utilities.tin which establish those by using the finditem command.

These can fail, because sometimes your container name doesn't line up with the actual keyword for that object. You may need to set these manually. I made two aliases to try to set these variables:

varset
setvars

There's actually and alise to run both of those: varset   (it breaks a lot so I usually run the above two commands individually)
Run #var afterwards to see what vars got set and if they are correct. If they are not, set them manually: 
#var item_con CONTAINER
#var pot_con POTIONCONTAINER

Make sure you use a valid keyword for each container. 

IMPORTANT FLAW

Currently I realize I only have these container variables setup for my Dragonslayer characters, which is handled out of newtin/genres/dragonslayer.tin. If you 'score' command doesn't show you as in that organization, this won't be loaded, and even if it were, it wouldn't work cuz your heals and container names don't match.

You'll need to create another config which is loaded for everyone, or by organization, by modifying main.tin so that instead of trigger on 'Dragonslayer' Trigger on whatever organization is listed in your 'score' output. Then load a file for that, where you modify my dragonslayer.tin to work with those container names and recall names and whatnot.

Here's how it works. You'll need to revamp this based on 'a violet potion' and whatever your container names are.

The command 'findtem heal' is ran. For DS chars, our heals are called "Dragons' Lament". Replace with 'a violet potion' or whatever the regular one is named. That command will pull a heal from whatever container on your body that you have heals in, We then grab that container name and set it as $pot_con variable, and put the heal back away where we found it. Finally we examine the $pot_con, because there are ALSO now triggers setup (somewhere..where? basic_utilities maybe?) to try to track how many of those I'm carrying based on how many I see in my container. THis bit isn't really working yet, but it shouldn't harm anything really.

#ACTION {You find Dragons' lament in Dracocutis of the Isorla.} {#var pot_con draco; put heal my.${pot_con}; exa my.${pot_con}}
#ACTION {You find Dragons' lament in a %0.} {#var pot_con %0; put heal my.${pot_con}; exa my.${pot_con}}
#ACTION {You see no my.gnomish here.} {#VAR pot_con metal; put heal my.${pot_con}; exa my.${pot_con}}

This last one is basically a workaround to deal with the fact that one container "A gnomish metal potion container" doesn't work when called with "Gnomish"
So, if that error is encountered, reset the variable explicity to 'metal' which I know is a valid keyword for that container. 

This then sets your $item_con based on the output of 'finditem recall'. Replace 'calling of dragons' the name of the regular recall scroll.

#ACTION {You find the calling of dragons in a %0} {#var item_con %0;put recall my.${item_con}; exa my.${item_con}}
#ACTION {You find the calling of dragons in Dracocutis of the Isorla.} {#var item_con draco;put recall my.${item_con}; exa my.${item_con}}

Simarily, there may be problems with the DISARMS trigger setup in basic_utilities.tin as well. If the leading word of the weapon name isn't actually a key for that weapon, that's a problem. You'll want to disable the trigger or hard-code it or something to mitigate that. In newtin/scripts/basic_utilities:

#NOP DISARM & SET WEAPON VARIABLE
       #ACTION {DISARMS your %0 %1!} {
               #VAR weap_var %0;
               get $weap_var;
               wield $weap_var
               }

This hasn't failed me yet, but I'm sure there are some weapons out there which will cause it to fail because the first term of the weapon isn't a keyword for it.

Heal/Hit Triggers

Finally, also in basic_utilities.tin is the rudiment of my fight/heal triggers. These presume you use the same prompt as me:

*** Really all that matters is that the first portion is the same ((Dymrex) 1703/1703hp) after that can be your own custom prompt***
Non-fighting prompt: 
(Dymrex) 1703/1703hp 645/645mv $12,328,042 1000 HY

Setup in game with the in-game prompt command:
prompt &G(Dymrex) ^x&R%h/%Hhp &G%v/%Vmv &O$%g &g%a &c%A%f

When not fighting, the prompt is constantly used to set the $hp, $maxHP, and $damage variables.

If the alias 'fighton' is entered, it loads similar scripting (/newtin/scripts/fighton.tin) which fires on the fprompt

***again, only the first bit actually matters to trigger things after (Dymrex)F 1703/1703hp do what you want with your prompt.  
Fighting Prompt: 
(Dymrex)F 1703/1703hp 645/645mv $12,328,042 1000 HY

Setup in game with the in-game fprompt command:
fprompt &G(Dymrex)&rF ^x&R%h/%Hhp &G%v/%Vmv &g%a &R( &C%c &W.:&Y%L&W:.&R)

The only difference between the two is the "F" after my character name. That F however triggers the 'fighting' mode. 

If a fight begins, the prompt in-game goes to the fprompt. 
When that "F" appears after the charname, and IF the 'fighton' script has been loaded, then:
That "F" triggers a lot of stuff that basically tracks damage, heals, and watchs for 'hits' to the mob. and re-scans. 

It does this by the action setup in basic_utilities.tin for #ACTION {SMAUG 2.1}
This is the output of the 'version' command, which is a no-lag command. 
I also have the actual text "SMAUG 2.1" replaced with 'AUTOFIGHTING' so I know this is enabled and working. 

Upon printing the output of 'ver' (smaug version) to screen, that triggers a fight/heal check that basically says:

If damage is > 100, take a heal and rerun ver to check again. 
If damage is < 100, issue $hit to $target. 

The $target variable is setup by either typing "k mob" "kil mob" or typing "targ MOBNAME" or upon someone in the room saying "targ MOBNAME"
The $hit variable is contained in each CLASS config file.  

What the 'fighton' script really does is setup a trigger on all the attack messages "you stun" "you smash" "your circle" etc, which issues another 'ver'

This create a loop. ver -> heal -> ver -> (once healed) $hit $target -> (hit message) -> ver.... repeats forever. 
It's the hit message trigger that 'fighton' is enabling. Otherwise the hit messages triggers nothing, and the loop stops. 

Sometimes it gets wonky and starts issuing too many 'version' commands to the mud. If things start to run-away from you, spam 'fightoff' until it stops.

It's also IMPORTANT to note that the 'ver' trigger is ALWAYS ON.

That means that at ANY POINT if you run ver, your character is going to check it's HP and either heal or $hit $target. 
However, it will not LOOP and continue hitting/healing unless you run 'fighton' first. But so, it's always available as a 'one-off'.
(Make sure you've setup $hit, $target, $pot_con variable or this will just error a bunch and may runaway) 

To Multi characters, I have a 'boton' 'botoff' alias that you can enter on a character you want to become a bot. If you enter that, then they'll respond to someone ELSE saying 'fighton' and 'fightoff' to turn auto-fighting on and off. For example:

Char1: boton (enables botting on/off by 'say' of another char)
Char2: say 'fighton'
  (Char1 enables fighton.tin triggers, and starts auto healing/hitting)
Char2: say 'fightoff'
  (Char1 disables fight triggers, and stops healing/hitting)

Very Important Point

You MUST quit the game properly in order for your next connection to load up all the scripting. 
This is because it all gets loaded by triggers setup on the Welcome screen. 

Turns out, if you dump out of realms without actual 'quit'ing, then the next time you connect, you skip the Welcome screen. 
With no welcome screen, nothing triggers, nothing loads. 
So, MAKE SURE, you ALWAYS quit properly, or when you re-connect you will be without ANY of the things setup in this package.

Furthermore: Do not edit scripts manually in a text editor WHILE LOGGED INTO THE GAME.

This is because any changes you write are going to be overwritten when you quit, since quit writes out all live running configured stuff to those files.

ALWAYS make changes INSIDE THE GAME console, OR, while fully disconnected from the game.

If you screw up, and have manually written to a file outside the game, but realize you were logged in, and don't wanna overwrite stuff:

dump the game with ctrl+d to avoid overwriting what you've manually written to a file. 
Log back into the game. Nothing will load because you'll miss the Welcome screen
Quit
Relog

You'll have avoided overwriting your updated configs, and relogged so everything does get loaded by the Welcome screen trigger.

Speech Logging

Speech logging is already setup and everything someone says/tells/chats/asks/ordertalks (can be changed to guildtalks) is logged to newtin/speech_log.tin

To monitor that, is more linux-based than tintin-based:

% tail -f /path/to/tintin/newtin/speech_log.tin will basically do the job, but will lack colorization. 
  (Adjust path as necessary from wherever you run this)

I installed the 'colorex' program here: https://bitbucket.org/linibou/colorex/wiki/Home

I then run this in a terminal (shell is zsh)

tail -f speech_log.tin | colorex -y .\*ordertalks.\* --green .\*says.\* --green .\*exclaims.\* --cyan .\*tells.\* -r 'chats|asks|answers' -m .\*yells.\*

I have that aliased so I don't have to type it everytime. In ~HOME/.zshrc:

alias tinlog="tail -f speech_log.tin | colorex -y .\*ordertalks.\* --green .\*says.\* --green .\*exclaims.\* --cyan .\*tells.\* -r 'chats|asks|answers' -m .\*yells.\*"

So, open new terminal, run 'tinlog' and boom, speech-only secondary window.

Things you need to set for this to run properly

PASSWORD: set your password inside newtin/main.tin (you must use the same pword for ALL characters)

Variables: 
item_con
pot_con
  (new scripting needs written for non-dragonslayer containers/heals/recalls... or manually set)
   #var item_con CONTAINER
   #var pot_con CONTAINER
      (Obviously, you might use the same container for both things, that's fine)
hit
  (this is written into newtin/classes/CLASSNAME_classconfig.tin)
  (if you have any of the same classes as me, its probably already set there)
  (easy way to set/change your preferred 'hit' for a character is to use these commands in game)
     classwrite
     hitis HITNAME     (I setup an alias 'hitis' to reset the hit variable whatever you specify here, can be changed on the fly mid-fight too)
  (upon quitting that variable gets written to your class config and you shouldn't have to set it again. Can always reset/change it with the 'hitis X' alias. 
     charwrite    (re-open character specific class, my preferred default setup)

A good habit

Check your character's specific config file every once in awhile to see if you've accidentally saved anything in there that should actually be in some other config

If you find stuff in there that you think some other characters might want, this about where that should go instead.

Finding where stuff is set

Sorry this only makes sense to me. It's kinda a hydra and that's probably not the best 'design' so to speak.

Anyhow, if you want to find where something is setup, thank god for linux, just grep for it:

(cd into the tintin directory first, or modify the path so its the full path into the newtin directory)

To view ALL aliases:

grep -ir alias newtin/* 

To view ALL actions:

grep -ir action newtin/*

To view something specific:

grep -ir var_name newtin/*

etc, etc, I hope you know how to use grep cuz it'll be super useful for figuring out what is set where here.