Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2024-04-16 05:28:31



Reply to topic  [ 22 posts ]  Go to page 1, 2, 3  Next
Lua and SetAvatarMinimapColor 
Author Message

Joined: 2011-09-17 11:12:19
Posts: 361
Reply with quote
I've been playing around with the SetAvatarMinimapColor function and I have a few questions.

I can't seem to get the color to "stick" and be remembered between logins. Is that how it is, or is it me that is doing something wrong?

To circumvent it I made a script that called the function with that avatar keys I wanted to color, however from what I can see it only works with avatars currently "visible" to me, either in minimap or radar? I can't set an key and then expect them to be colored when they enter the region or tp in, can I?


2020-07-04 23:41:58
Profile

Joined: 2016-06-19 21:33:37
Posts: 342
Location: Columbus area, OH, USA
Reply with quote
I use a combination of OnAvatarRezzing() with IsAgentFriend() to color the minimap and name tags. Given this simple scenario, I don't need to have anything preserved across sessions but you can always store such data with SetPerAccountData(). This is my simple function:
Code:
--[[ Handle avatar rezzing

params:
  #string id - the UUID of the avatar rezzed
]]
function OnAvatarRezzing(id)
    if IsAgentFriend(id) and userConfig.friendColor ~= nil then
        SetAvatarMinimapColor(id, userConfig.friendColor)
        SetAvatarNameTagColor(id, userConfig.friendColor)
    else
        SetAvatarMinimapColor(id)
        SetAvatarNameTagColor(id)
    end
end


2020-07-05 04:15:48
Profile

Joined: 2009-03-17 18:42:51
Posts: 5545
Reply with quote
Catten wrote:
I can't seem to get the color to "stick" and be remembered between logins. Is that how it is, or is it me that is doing something wrong?
This is perfectly normal. Nothing that you can set via Lua is remembered over sessions, with the exception of debug settings values (just like for any other parameter in the viewer: "sticking" parameters are backed by a "debug" (bad term, really) setting, including floater sizes and positions).
If you want your colors to "stick", you must script the saving and restoring of the color table (use the avatar Id for the key and the color for the value), with Set/GetGlobalData() or Set/GetPerAccountData().

Quote:
from what I can see it only works with avatars currently "visible" to me, either in minimap or radar? I can't set an key and then expect them to be colored when they enter the region or tp in, can I?
You need to set the color (from your table) when the avatar "rezzes" (i.e. becomes known to the viewer), using OnAvatarRezzing(). An example is given on how to use SetAvatarMinimapColor() and SetAvatarNameTagColor() in an OnAvatarRezzing() callback.


2020-07-05 07:00:26
Profile WWW

Joined: 2011-09-17 11:12:19
Posts: 361
Reply with quote
I got it working. Thank you both for your help :D


2020-07-05 13:06:39
Profile

Joined: 2011-09-17 11:12:19
Posts: 361
Reply with quote
I spoke too soon. It works, but It's not exactly what I'm looking for. I fight in roleplay, and most of the others use firestorm. That viewer allows them to see enemies marked as red on the minimap and with red hitboxes. It is a huge advantage and while I do not like the feature as it takes immersion, I also don't like losing always due to my principles :)

The current Lua coloring where I colour people in the OnAvatarRezzing(id) event, only works if I look in the direction of the people. So I can't tell if an enemy gets near me from another direction. The screenshot below shows the dilemma.

https://imgur.com/a/0BMrfXz

Is there something else I can do to even the odds? Friends are rendered yellow regardless of where I look.


2020-07-05 15:32:21
Profile

Joined: 2009-03-17 18:42:51
Posts: 5545
Reply with quote
The OnAvatarRezzing() callback is called as soon as the avatar object is created in the viewer: it is not possible to call it sooner !

I also doubt very much Firestorm can colour avatars sooner (since they would need knowing that the avatar is there even before the server tells them !)...


2020-07-05 16:13:55
Profile WWW

Joined: 2011-09-17 11:12:19
Posts: 361
Reply with quote
I just checked, firestorm doesn't change the colours back to green on the minimap if I look in the other direction. If I colour the avatars, they stay coloured no matter where I look and move. I'm guessing they must use the same method to colour the minimap as is used to colour friends yellow. For instance in Cool Viewer, friends don't change colour between green and yellow if you change your view. They are the correct colour always.


2020-07-05 16:27:03
Profile

Joined: 2009-03-17 18:42:51
Posts: 5545
Reply with quote
Catten wrote:
I just checked, firestorm doesn't change the colours back to green on the minimap if I look in the other direction. If I colour the avatars, they stay coloured no matter where I look and move. I'm guessing they must use the same method to colour the minimap as is used to colour friends yellow. For instance in Cool Viewer, friends don't change colour between green and yellow if you change your view. They are the correct colour always.
The viewer does NOT modify the colour by itself (the tag/dot colours are initialized at LLVOAavatar object creation, and can only be changed by the corresponding Lua functions).

However, avatars beyond the draw distance won't be coloured with your custom colour, because the avatar got derendered (i.e. the LLVOAvatar object got destroyed, and with it the associated colour which is contained in a member variable); the (mini-)map info is separate from the objects list, and works with UUIDs, thus why your friends (which are known by their Ids by the viewer) can be coloured and not a random avatar.

The workaround is to increase your draw distance (anyway, what's the point of spotting your enemies on the mini-map if you can't see them to target them ?...). As long as the avatar stays within the draw distance, you do not need to face it (have it in your camera FOV) to see it coloured on the mini-map.

Firestorm deals differently with avatar colouring, by associating each "tagged" avatar Id with a colour in a std::map. This (searching for the UUID in the std::map at each frame) is however much slower than using a pointer to a member variable in LLVOAvatar to get the colour... So I don't feel like using the same method in my viewer...

Finally, note that there are better ways to track avatars than the mini-map: the radar offers a marking feature, alerts, and allows to track (with the tracker beacon) any single avatar (including beyond draw distance, since it also uses the maps data).


2020-07-05 16:51:08
Profile WWW

Joined: 2011-09-17 11:12:19
Posts: 361
Reply with quote
The benefit from marking them on radar is that you can see them approaching, however you are right that can be done with tracking and having the radar notifying if they are close. That will be fine enough for my use.

Question though. Isn't that feature in the radar just as "expensive"?


2020-07-05 17:57:11
Profile

Joined: 2011-09-17 11:12:19
Posts: 361
Reply with quote
Another question. If I enable moderation and alert. It looks like it enable it globally for everyone in the radar and not the individual person, unlike the other features of the radar?


2020-07-05 18:01:23
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 22 posts ]  Go to page 1, 2, 3  Next

Who is online

Users browsing this forum: No registered users and 17 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.