Post: #1

Actually the @Dye is fired only on the item, it works fine but it's not friendly to use because I must copy/paste the same @Dye on every itemdef.

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)

To make this, the current @Dye can be changed to @ColorChange and it will be fired only on the item, and add a new @Dye to be fired only on typedef t_dye_vat when it try to dye something

The execution order will be like this:
1) @Dye on dye tub
2) @ColorChange on item/char

Post: #2

You can set a [typedef t_dye] to be applied on EventsItem in the sphere.ini instead of adding the code to every itemdef.

Argo in this trigger is the source used (in case of t_dye_vat), so you can call your triggers from it.

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

Post: #4

nah, workarounds...
I wonder if EventsItem is safe to use on a live server with 1.000.000 items :/

but anyway, I'm already using @TargOn_Item on my furniture dye tub
basically this item is 100% custom with absolutely nothing inherited from an dye tub. The t_dye_vat is only to make the i_dyes works on the item to change the tub color

I just suggested this idea about @Dye / @ColorChange to make everything oficially supported and easy to set. These "furniture/runebook/etc dye tubs" are items originally added on UO, but I cant implement them on sphere script pack because the only way to create these items is using workarounds and more workarounds. And it's a bad idea use workarounds on the script pack

Post: #5

I don't know if it would be bad to use EventsItems, however ... there's a more precise way to do so:

This will override every item with this type, you may block actions in this re-definition, return 0 will allow default behaviour... so it seems fine for what you want?

Post: #6

(05-18-2014 12:55 PM)Coruja Wrote:  I wonder if EventsItem is safe to use on a live server with 1.000.000 items :/

As long as you know what you're doing, should not be a problem
most of the items are 'inactive' on player houses/banks and most of the triggers fire on a very specific event. I wouldn't be worried with that unless my event contains code that can potentially hung the server

I got coruja's point, he want something like @BeforeDye to be called on the tub. @TargOn_Item can not decide if the item can be dyed or not, only force it.
A @BeforeDye trigger called on the tub holding writable internal sphere decisions allowing scripts decide if an item can be dyed or not regardless of just checking can_i_dye flag

Post: #7

yea, the focus is the trigger to run on dye tub, not on the targeted item
the @ChangeColor I just said because compatibility with the current @Dye: the current @Dye changes to @ColorChange (fired on item) and a new @Dye is added on the dye tub

but maybe it can be done with @TargOn_Item
the idea is just make something more "official-like" (to later add it on script pack) instead a workaround

Post: #8

I really don't understand what would @Dye be able to do that @TargOn_Item can't do...

btw, it's not because something is not hardcoded that it's called a workaround. A workaround would be using a feature in a way that it wasn't meant to, to make something else do something it couldn't normally.