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.
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.
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.
Finally, also in basic_utilities.tin is the rudiment of my fight/heal triggers. These presume you use the same prompt as me:
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
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 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 trying "targ MOBNAME" or upon someone in the room saying "targ MOBNAME" The $hit variable is contaned in each CLASS config file.
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.
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)
Finally, a 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, 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.