The background

As some of you, at least those who have paid some attention to news updates group, may already know, I recently made several enhancements to the 'eqset' command. This command, while useful, had various minor usability flaws, such as that it required you to have all the equipment belonging to the set in your inventory to actually see what belongs to the set. Not very logical, and sometimes inconvenient.

Also, when performing 'eqset validate', you didn't actually get to see what equipment was removed from the defined set, just the number of items that were dropped.

These issues all derive from the fact of how 'eqset' stores the data about equipment. The old version (and the improved one) basically store an unique identifier .. every item in BatMUD has such an identifier, which is basically a large number. Every player has such identifier as well, though it differs a bit from unique ids of items.

The old version of eqset simply stored this unique identifier and no other information. Unfortunately the identifier can't be used to directly access any information about the item objects themselves, unless they have been loaded. It is also a practical requirement, for performance reasons, that we have the item "at hand", aka in a known container or the inventory of the player.

A wicked problem (or a few) this way come ...

This brings us to the first problem .. if we only have the identifier, we can not dig up the other information such as the item's description(s), handles, etc. This is why, while refactoring the 'eqset' code, I decided to save some of that information in the new eqsets along with the unique identifier.

Now that we have the shortdesc, handles, etc saved, we can easily show the player all this information even when he or she is not in possession of the said items. This is also the reason why when the old eqset data was converted, some descriptions of items in the 'eqset view' listing temporarily became "--" or so .. if the item was not loaded (and in the player's inventory) at the time of the conversion, there was no possible way to get the required data .. However, the data will be fetched by the eqset code as soon as you use the eqset command with the item(s) in your possession.

And this all would be rather fine, unless we wanted a bit more out of the command .. and who wouldn't? Convenience is the king.

Solutions in search of problems -- or vice versa

Many players have whin.. compl.. *ahem* .. expressed their wishes that it would be nice if there was some kind of 'eqset get' and 'eqset put' or similar functionality. Yes, I do agree that it would be nice. And I did try .. but I prefer a somewhat more generic solution .. thus enter 'eqset foreach' and 'eqset command'.

The 'eqset foreach' is something that existed before my changes, but I added the enhancement of the <item> tag. It has been pointed out to me, that it was possible to do the same before with clever aliases, but now it is bit easier. The 'eqset command' .. uh .. command, is similar to foreach, but instead of performing the specified command separately for each item in eqset, it combines the items to a list and feeds that to the command. For example:

> eqset command setname say <item> are in the set.
You say 'a leather backpack 1,elshara darkeye's ring 1,mithril ring 1,holy paw of The Bunny labeled as (Ggr) (holy) are in the set.'

And yes, this all kind of works .. some of the time. It is easy to hit various problems, though, and some of the problems are not easily circumvented. This all comes from the following facts:

1. The 'eqset foreach' and 'eqset command' do NOT have any special knowledge about containers or such. They simply just run a specified command, with item descs generated from the eqset data as the command parameters.
   
2. Because we do not have any special code for handling containers and only access items by (one) of their possible handles, we can hit various problems with multiple items with same desc, or copies of the same item.
   
3. Also, there is the unfortunate fact that some items actually have same handle(s) that a completely different item has (see: Eckma and Beholder mithril ring)

All of the above combined we can hit a multitude of snags. As we do not have knowledge of where the items reside (player's inventory? we can check that, but perhaps it's NOT what the player actually wants .. containers? nope, would require special code -- more about that later) and the clashing handles and item indexing (aka 'ruby ring 1' and 'ruby ring 2' etc.) -- Well, to put it short: it's a mess.

A good practical example would be: You want to put the eqset items into your chest. This is kind of easy .. 'eqset command setname put <item> in chest'. And it usually works, as we can, to some extent, access the items in player's inventory and index them properly so that 'mithril ring 3' actually matches the correct ring.

But when you want to _get_ those items from a container, we have absolutely no idea (from the command's point of view) what the chest or rig might have inside. Are there perhaps items that are similar, but do NOT belong to the eqset that is being operated on? With this method, it is possible that you end up with wrong items being handled.

Solutions, solutions, solutions ... ?

So, you may be wondering; considering the numerous problems with the current functionality, is there anything that could be done?

Yes .. and no .. and kind of. The way I personally think, there are basically two possible solutions, each of them with their respective pros and cons.

Perhaps the easiest and most universal solution would be to use the items' unique identifiers. While almost always hidden from the world of mortals, the identifiers actually work as hidden handles for the items. Unfortunately this would "reveal" the ugly inner workings of the command in many cases -- such as if the item in question does not happen to be where the command expected it to be:

There is no 1234567-1 in the a gargantuan dukonium vault (open)!

That might be a bit confusing, to say the least.


The second solution I've come up with would be to ditch the idea of generalized 'eqset foreach' and 'eqset command' functionality and create special purpose 'eqset get', 'eqset put' etc. commands that would be able to access containers.

Unfortunately this presents certain problems as well. Much of the code for handling such containers currently resides in the 'put' and 'get' commands themselves. It would require quite a bit of work to refactor that code into something useful and move it into the MudLib as general purpose functionality. I personally do not feel that I have the time and patience to do that, at least for the moment.

In conclusion

Hopefully this rather long and complex post answered some of the questions and cleared up a bit of confusion on the topic why certain things are the way they are.

In general it also applies to many other things .. sometimes making things work is not as easy as it might seem from the mortal point of view. And sometimes even a seemingly simple feature may cost us wizards many a sleepless night to implement ..

-- Ggr, the Bunny Wizard