Cool VL Viewer forum

In general, I agree that Lua should not duplicate what LSL can provide. I appreciate you evaluating and including changes that may be valuable to others though.

My suggestion for teleporting only stemmed from the fact that I couldn't control the way I was facing when I landed and I always seemed to be facing the wrong way. I had noticed that the LSL method was almost identical to the Lua function, except for that one parameter of the 'cardinal direction' to arrive facing. I have a small table of favorite destinations that I trigger with a 'chat command' and I always end up facing away from the <crowd, feature, etc> which is to the <some direction> when I arrive. Basically, I use GetGridSimAndPos() to capture global coordinates, store them for later playback with TeleportAgentToPos(). Obviously, if a region has a landing point defined...this becomes less useful and as the land owner dictates place and direction of landing.

As for the AgentInfo(), that will come in handy when used in conjunction with the AgentStand(), AgentSit() or making scripted decisions about how to interact with others.

Again, thanks for 'hearing me out'.

Thanks for the recent Lua additions, Henri. I find that before trying to sit or stand in my automation, GetAgentInfo() is great. For the TeleportAgentToPos() 'look at', I think I may have misunderstood what was possible. I now understand your comment now about a 'random direction'. I thought the parameter would allow specifying the landing direction upon teleport, such as teleport and face northeast, west, etc. or even specify a numeric value indicating the vector or something.

Anyway, I appreciate all the work you do for the Cool VL Viewer. After being away from SL for a long time, you have given me a reason to come back and tinker around.

When using the OnRadar() callback is it possible to get the (un)marked status of the agent?

Is it true that the OnRadar() callback will only be triggered while the panel is open (and no other settings are in effect-see below)?

I also noticed (but haven't exhaustively tested), if the 'Announce incoming avatars even when closed' is checked (i.e. RadarKeepOpen == true) it won't take effect until the radar panel is opened once. OnRadar() callbacks don't come in until it has been opened. They will continue if the panel is closed thereafter. The same thing (sort of in reverse) seems to hold true if one sets the debug value of RadarKeepOpen to false while the radar is closed. The OnRadar() callback will continue to get events until the panel is opened and then obviously closed, if my second question above is true.

Added for next release.

The OnRadar() callback is only triggered while the radar is active (with the floater showing or hidden). By default, and to avoid any overhead in the frame main loop, the radar is inactive (floater not constructed) on login, unless the radar floater was open and showing on last logout.

The "RadarKeepOpen" debug setting is for internal use only: it is not meant to be manipulated (manually or by other code) outside the radar floater code. I should probably make some cleanup and set all such debug variables (there are quite a few in this case) as "hidden" to the debug settings floater. I will also forbid changing "hidden" variables via Lua, since it would only allow to break things... FYI, "RadarKeepOpen" simply turns the "close floater" action into a "hide floater" action, allowing the radar code to keep running in the background even when "closed" (actually, "hidden").

Which is the expected behaviour...

I added a CloseFloater() Lua function for next release, so that you can use OpenFloater("radar");CloseFloater("radar") on login to switch radar tracking on when in need for OnRadar() to always be active.

Thanks for the explanation on the radar floater's behavior and additional functionality. I figured the radar floater function was something along those lines, based on observation.

I'm not sure how 'sweeping' of a change you were thinking of in limiting the use of debug settings. I use a few other debug settings in my automation.lua. They are:I would hate to lose the usage of those.

They are not the targets of the code change. Only "hidden" debug settings (those you can't change from the debug settings floater) will be made read-only to Lua scripts.

Cool. Thanks again.

Is the documentation for GetAvatarName(avatar_id[, name_type]) correct for type 2? I am currently only using type 1, but the detail for type 2 seems to imply it is reversed to that of the preference radio button selection of 'display name [legacy name]'.

Both the documentation and the function are correct (no mistake in the doc, no bug)... I don't see why you would want the type number to follow the layout of a random UI element in some floater...