Post: #3

@dye is intended to call on the item, so you can change the behavior of this item when someone dyes it. You don't have to track the item id on the dye tub for every dyed item with specific behavior
eg: You don't want this specific item to be dyed when some X property is set or during an event

You can use something like this to change the dye tub behavior

[typedef t_dye_vat]
ON=@Targon_Item
Serv.b <src.name> used a dye tub on a <argo.name> !

The call order is:
@TargOn_Item on t_dye_vat(global) or on itemdef(specific tubs) (return 1 prevents @Dye to be called)
@Dye on the itemdef

If you want @Dye to be called on every item to...for example update your sql database, just do what Xun said

Quote:The idea is improve it, making it fire some trigger on the dye tub too (SRC=dye tub, ARGO=targ item/char). With this single trigger we can control everything or even create custom dye tubs to dye only certain items (furniture dye tub, runebook dye tub, etc)

On RunUO, C# (C++ and others too) provides a way to create new classes based on a base class (derived/inherited classes)
eg: Every sword in the game is based on the BaseSword class, which is based on BaseWeapon class, which is based on Item class. Every visible object inside the game is either Item or Mobile. The same goes for mobiles (eg: Vendor<-BaseVendor<-BaseCreature<-Mobile)

On Sphere we could have something like this, inherit types from a base type

[typedef t_furniture_dyetub t_dye_vat]
ON=@TargOn_Item
if (!<Argo Is forniture>)
message You can only dye furnitures!
return 1
endif

t_furniture_dyetub is based on t_dye_vat. It will behave exactly like a t_dye_vat unless when some script modify its functions

With the actual scripting you can create the furniture dye tub and override its functions with triggers on the itemdef. inherited item types would just be a shortcut or a clever way to separate items based on its functions (type) and not by itemdef.
Even that it sounds redundant to have derived types, I'd vote for it. When talking about dye tubs it has no big reason to used derived types, but if you want to have practice weapons, you could create a t_practice_weap based on the t_weapon; no needs to define same triggers on every practice weapon. Just imagine this with spawners..or everything else
Changing the new typedef would change the behavior of every item with this type quickly