Over the past week I've spent a substantial amount of time learning TF a bit better. I've learned quite a bit, this tracking script is the product of that work. I'll list the features first, then the code. I don't think the code will be extremely useful to anyone "out of the box" without my other scripts. This script takes advantage of an "array.tf" file I found online that adds array variables to TF, also includes macros for accessing, altering, and examining them.

I'm going to add a separate topic to the Mechanic's section with a link so you can download all of my TF script files. That set of files will be much more helpful to you. Im posting this file separatly because it does some interesting things, and I figure some people might learn a few things from it (worst case scenario it's a nice code example to learn from).

I designed this script in a way that allows others to easily customize it for their own needs. All of the real complicated and difficult work is done in a few macros (/def's), whose purpose is commented well with the syntax needed to use them. These macros are intended for use in aliases you create to do what you need to get done. The macros are tools for you to use, more or less. You shouldn't really need to mess with the macros at all. This method hides all of the complicated details, giving you the power to create some real nifty things with simple code. It makes it easier to update and maintain your aliases too, because they're simple. Reading through the comments in the code, and the aliases I created for myself, will give you a better idea of what I mean.

player highlighting and stack management
This script revolves around a set of stacks (implemented by a variable of space separated words - stack-q.tf). Each stack is related to a type of players I wish to track. There are two type of stacks, dynamic and static. Dynamic stacks are always changing. These stacks have associated /def's that automatically populate them with values, and are executed every so many minutes. One defines my citymates, one my guildmates, and the other my cityenemies. Static stacks are ones that are not updated automatically in this way. I have one for official enemies, allies, suppliers, and marks.

The player highlighting is on a priority system. You can have one person in multiple lists. For example, I might have one person in my citymates, guildmates, and marked lists. When his name is seen in TF he will appear as a mark, because I gave it a higher priority than citymates and guildmates. If he wasn't marked, he'd be colored as a guildmate because I gave it a higher priority than citymates. And so on.

All of the highlighting is logged nicely by the colored logger I wrote (check my next post for the file of all my scripts).

- Ability to save/load stacks to files (2 macros do the work, aliases were created for each stack type).
- Macros for use in CONNECT/DISCONNECT hooks to automatically load/save stacks for you when you start/close TF.
- Macros to add, remove, and list highlighted players. Aliases were created for each stack type to facilitate adding/removing players (enemy/unenemy, citymate/uncitymate, mark/unmark, etc).
- Macros to populate dynamic stacks (citymates, guildmates, cityenemies), and a macro to have them automatically repopulated every x number of seconds.

player locating
Thirdeye is a great skill, this section of the script gives you many commands to really take advantage of it.

- Macro to locate one or more players (space separated list of names as argument)
- Macro to list all players at a location (partial or full name as argument)
- Macro to list location of a specified player, and all those at his/her location (single name as argument)
- There are then a slew of aliases to take advantage of these three macros. Since they accept lists of names as arguments, it's very easy to just throw them the player highlighting stacks to locate a group of people. Examples: "loce" locates all enemies, "locc" locates all citymates, etc.

This probably isn't as much detail as you'd like as far as features go, but I don't feel like writing about it anymore! I've got other code/ideas I'm working on, and Daevos and Ixion are going to be pissed if I don't start playing more often. The code is commented pretty well, and I use long macro/variable names to make the code very readable...well...as readable as TF code can be. If you're looking to use this script as-is, I'd STRONGLY recommend checking out my next post to obtain all of the files and start with that. Taking this file on it's own without the others is like remove the engine and tires from your car...not very smart and a pain in the ass.

Here's the code, you can see a syntax highlighted copy of it on my website at http://www.bwbettin.com/files/tracking.tf.html

People like you scare me...

Thank you for the compliment

I certainly can't scare you in the realms yet, at least I can do it IRL

druth i think you overlapped your enemy and ally command with the builtin commands. I dont think thats such a good idea have to change that alias name or work around the limitations of the enemy and ally lists

Well, yes, I have aliases named "enemy, unenemy, ally, and unally". Yes, these overlap with the Lusternian built-in commands of the same name. However, that's the point. I wanted to expand on what the Lusternian built-in commands did. As I enemy people, I also want them highlighted a certain way. My version of the Lusternian built-in commands do the highlighting, then call the Lusternian built-in commands to adjust the player's enemy/ally status in game.

I use my "enemy" alias as an example (the others are almost identical):


The user of this alias can type "enemy player1 player2 player3..." or "enemy". Just typing "enemy" by itself will print the list of players you have enemied to your screen. Giving the enemy command a list of players will enemy all of those players, then add highlights for them so that their names are colored in TF.

The key line here that addresses your concern is "/mapcar /sendl_enemy %{*} %; \\". What "/mapcar" does is apply the command on the right (/sendl_enemy) to every name you passed to the enemy alias. So if you typed "enemy player1 player2 player3", that /mapcar command will execute

/sendl_enemy player1
/sendl_enemy player2
/sendl_enemy player3

The sendl_enemy code is also included in the tracking script:


It seems rather pointless at first, why have one 1-line command simply call another 1-line command? The answer is that /mapcar only allows you to use a single-word command. The command I wanted to run on each name sent to the "enemy" alias had more than one word. The code for "/sendl" is not included in the tracking script posted here, it's in my logging script (which is why I posted all of those files in another post right after this one).

Here is the "/sendl" code:


The way my logging script logs sent commands is through SEND hooks. Normally if you typed enemy/ally it would get sent to the mud, and logged. However, because I wanted my aliases to replace those commands, I had to use a /send command to send "enemy" and "ally" to lusternia. /send commands DO NOT trigger SEND hooks, and thus the commands wouldn't be logged in my colored log. /sendl is my work-around for that. It sends the enemy/ally command to Lusternia, and then writes the entry to my logs itself (since the all-encompassing SEND hook won't catch it).

In the end, my "enemy" and "ally" aliases don't really overlap with the Lusternian built-ins, it's more like they wrap around the built-ins...adding functionality to them. When you type enemy/ally in with my script, you're still executing the same commands you always did, but the highlighting now comes along with it.

I'll end up doing this same thing to other commands, such as DEF. I add more functionality to the commands that exist. This way of doing things makes it easier for myself and others to use my system, because the built-in commands they've always used are still there...just better.

What are the limitations of my alias/stack replacements for the built-in commands? I don't really use them all that much, so I'm certainly not an expert on the built-ins. The built-ins let you enemy one person at a time, unenemy one person at a time, or unenemy everyone at once. Mine does the same, but also lets you enemy a list of people at once.

After messing with it a bit I do notice one slight performance hit in the unenemy alias. If you do "unenemy all" it unenemies each player one at a time. It would make more sense to just send "unenemy all" to lusternia and do them all at once. I think I'll probably leave it as-is; I like to see who I'm unenemying and not just a generic "You feel forgiving and unenemy everyone" message. Are there any other problems with the aliases I missed?