Introduction
Many players are familiar with the concept that each item in UO has a unique number that separates that item from all other items in the game. For instance, two piles of gold will have unique numbers, so that the game can tell “Hey, this is pile of gold 1 here and that other gold pile over there is pile 2”. These numbers are referred to in UO’s code as “objectID” (most of the time).
However, items have more numerical codes associated with them than objectID. In the EC, there are dedicated tools (functions) for obtaining an item’s graphic number (typeID tool) and an item’s color number (hueID tool), but there are not specific tools for obtaining objectID or other ID codes. There are many ways to obtain these codes in the EC, just not functions in the Actions list for doing so.
--A caveat here, “typeID” is a less than ideal reference to the graphic number, as “type” is also associated with a different numerical ID.Different Methods of Targeting via objectID
So, why would you want to know an item’s objectID? The most likely answer is to target and interact with a specific object and no others. Within the EC there are two general paths to target and manipulate an item via objectID:
1. Calling a cursor and then using a stored cursor target.
2. Targeting a stored item and using that stored item.
These paths may seem similar, but the coding is different. The two methods can also accomplish separate tasks. Additionally, the second method uses simpler functionality, making it slightly faster. Let’s look at some examples to understand the differences.
Cursor
Target Stored (Stored Object won’t work):
Let’s say you to want to repair an item. You can write a macro to hit the repair
button, wait for the targeting cursor to appear, and then target a Cursor
Target Stored object. This would work and the object would be repaired.
However, if you wrote the macro to hit the repair button, then target a Stored Object, when you ran the macro the cursor would appear, the object would be
targeted, and nothing else would happen. That is because the macro isn’t being
told to execute on Stored Object, just to target it. If you’re calling a
cursor, you need to use Cursor Target Stored to execute the task.
Stored
Object (Cursor Target Stored won’t work):
Let’s say you want to use your pet summoning ball. In this case you might drag
Store Pet Summoning Ball 1 into a hotbar slot, click on the that slot, and
target Pet Summoning Ball 1, thereby storing Pet Summoning Ball 1 via objectID.
You could then write a macro to Target Pet Summoning Ball 1 and Use Targeted
Object. This would work and you would interact with Pet Summoning Ball 1.
However, since there is no action in the macro that requires a cursor, and no cursor would appear, using Cursor Target Stored would have no effect and the macro would not work.
Cursor
Target Stored and Stored Object both work:
Let’s say you write a macro to cast Heal on a pet. You can write the macro as:
Cast Spell (Heal), wait for Target Cursor, Cursor Target Stored (Pet). This
will cast and execute Heal on Pet, but not on anything else, because you have cursor
targeted Pet by Pet’s objectID. In idealized code, this macro would look
something like this:
Cast Spell (Heal)
Open Target Cursor
Wait for Target Cursor to Finalize
Target(objectID)
Close Target Cursor
You could
write this same macro as Cast Spell (Heal), right click> Target Stored
(Pet). This macro will also cast and execute Heal on Pet, but not on anything
else, because this time you have Stored Object (Pet) via Pet’s objectID, directly
on Cast Spell (Heal). In idealized code, this macro would look something like
this:
spell(Heal(target(objectID)))
The result of these different paths is that if you wish to target via objectID:
1. When a targeting cursor is required, Cursor Target Stored or a similar function (the default cannon actions are all Cursor Target Stored) must be used.
2. When no targeting cursor is required, Stored Object (Default Objects, Pets, Pet Summoning Balls, Bard Super Slayers, and Bard Slayers are all Stored Object) must be used.
If both Cursor Target Stored and Stored Object are available, it may be slight faster to use Stored Object.Creating a generic “Stored Object”
Stored Object actions are incredibly useful, but in the default client there are a limited number of those actions and many of them are additionally restricted in the types of objects that can be stored. For instance, Pet Stored Objects must be pets, Bard Slayers Stored Objects must be in your backpack, etc. The only widely usable Stored Object actions are Default Stored Objects, but there are only five of those in the default client. One of the major targeting flaws in the default EC is that while many Stored Object actions exist, all with their own uniquely identifiable icons, no Generic Stored Object action exists. Such an action would work as a counterpart to the generic Cursor Target Stored and vastly improve Stored Object targeting. Below is an image displaying the relationship among Actions regarding the creation of a basic macro for target Stored Object, Use Targeted Object. While the icons are pretty, a generic Stored Object would be far more functional.
Luckily, the EC is mod-able, you can create a bazillion Default Stored Objects if you’d like, all with their own icons. However, a more accessible solution would be preferable. As the EC also provides the tools to create functions in-game with Actions>Command, such a solution exists. Allow yourself to be introduced to the most generic of targeting commands and one of the simplest and most useful bits in the EC:
script HandleSingleLeftClkTarget(objectID)This simple function, accessible via Action>Command, will allow you to Store/Target Object for anything in the game, but without the need for a cursor.
