Target vitals

[Galuhad]

I was just wondering if anyone has worked out a way to get information on the selected target? The Turbine.UI.Lotro.LotroUIElemen t enumeration has a 'Target' value so you can disable the default target vitals, but I really can't work out how to get the target information. I am trying to get the name of the target more so than anything else.

[Tangaar]

I was just wondering if anyone has worked out a way to get information on the selected target? The Turbine.UI.Lotro.LotroUIElemen t enumeration has a 'Target' value so you can disable the default target vitals, but I really can't work out how to get the target information. I am trying to get the name of the target more so than anything else.

I would like to ask something about vitals too

is there any way to check all vital bars fromm all around you?not only your selection targets vitals?

I have 5 npcs on me for example and i would love so see all healthbars from all these five without having to target tthem

[Garan]

I would like to ask something about vitals too

is there any way to check all vital bars fromm all around you?not only your selection targets vitals?

I have 5 npcs on me for example and i would love so see all healthbars from all these five without having to target tthem

Currently, no. The only way to access a non-party actor is if that actor is the current target of a party member. Once your or your party member switches targets, the actor for the prior target becomes invalid, all of its methods return nil and it will no longer fire events. This may not be working as intended since the method that gets the target in the first place, actor:GetTarget() is not yet documented and only available on Bullroarer. We will find out what is intended once Turbine officially documents the GetTarget() method. I would like to see Turbine expand upon this functionality to allow us to find "closest target" and "next target/previous target" the same way the client does but only time will tell...

Another side note about the current GetTarget() method, EVERY call to GetTarget gets a new unique actor instance whether the player changed targets or not so there is no way to tell whether the target returned by GetTarget is the same target as previously returned, either for this actor or another actor. This significantly limits the usefulness of the GetTarget() mechanism for displaying a list of multiple targets since there's no way to know if the target being returned already exists in the list (the closest thing is the actor's name, but that is far from unique). This issue would cease to be a problem if we could get some kind of ID from actors that is more unique than the name. The client obviously has such an ID internally, it would be great if we could get that ID via an actor:GetID() method.

[Tangaar]

Currently, no. The only way to access a non-party actor is if that actor is the current target of a party member. Once your or your party member switches targets, the actor for the prior target becomes invalid, all of its methods return nil and it will no longer fire events. This may not be working as intended since the method that gets the target in the first place, actor:GetTarget() is not yet documented and only available on Bullroarer. We will find out what is intended once Turbine officially documents the GetTarget() method. I would like to see Turbine expand upon this functionality to allow us to find "closest target" and "next target/previous target" the same way the client does but only time will tell...

Another side note about the current GetTarget() method, EVERY call to GetTarget gets a new unique actor instance whether the player changed targets or not so there is no way to tell whether the target returned by GetTarget is the same target as previously returned, either for this actor or another actor. This significantly limits the usefulness of the GetTarget() mechanism for displaying a list of multiple targets since there's no way to know if the target being returned already exists in the list (the closest thing is the actor's name, but that is far from unique). This issue would cease to be a problem if we could get some kind of ID from actors that is more unique than the name. The client obviously has such an ID internally, it would be great if we could get that ID via an actor:GetID() method.

Ahhh so its a code problem then. :/ it would be really helpfull if such thing could happen even with a plugin
Thanks fro clearing this out for me!

+1 rep