Cool VL Viewer forum
http://sldev.free.fr/forum/

Lua scripting related requests
http://sldev.free.fr/forum/viewtopic.php?f=9&t=1737		 Page 7 of 10
Author:  ZaneZimer [ 2017-05-04 12:54:03 ]
Post subject:  Re: Lua scripting related requests
Henri Beauchamp wrote:
Please note that viewer-side Lua scripting is not meant to replace server-side LSL scripting (especially since you can have LSL scripts invoking Lua commands, bringing a whole new lot of possibilities for your scripts).
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'. :-)
Author:  ZaneZimer [ 2017-05-06 19:14:56 ]
Post subject:  Re: Lua scripting related requests
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. :-)
Author:  ZaneZimer [ 2017-06-08 03:02:46 ]
Post subject:  Re: Lua scripting related requests
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.
Author:  Henri Beauchamp [ 2017-06-08 11:47:26 ]
Post subject:  Re: Lua scripting related requests
ZaneZimer wrote:
When using the OnRadar() callback is it possible to get the (un)marked status of the agent?
Added for next release.

Quote:
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)?
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.

Quote:
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. .../...
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").

Quote:
OnRadar() callbacks don't come in until it has been opened. They will continue if the panel is closed thereafter. .../... The OnRadar() callback will continue to get events until the panel is opened and then obviously closed, if my second question above is true.
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.
Author:  ZaneZimer [ 2017-06-08 12:40:47 ]
Post subject:  Re: Lua scripting related requests
Henri Beauchamp wrote:
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.
Author:  ZaneZimer [ 2017-06-08 13:33:03 ]
Post subject:  Re: Lua scripting related requests
Henri Beauchamp wrote:
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.
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:
Code:
C.debugSetting = {
  FN    = "FirstName", -- read only
  LN    = "LastName", -- read only
  CFV   = "CameraFrontView",
  RNHS  = "RenderNameHideSelf",
  RN    = "RenderName",
  RFC   = "RenderFarClip",
  SRFC  = "SavedRenderFarClip", -- read only
  AOZ   = "AvatarOffsetZ",
  SR    = "SpeedRez", -- read only
  SRI   = "SpeedRezInterval", -- read only
  RAMC  = "RenderAvatarMaxComplexity",
  RAMSA = "RenderAutoMuteSurfaceAreaLimit",
  RAMM  = "RenderAutoMuteMemoryLimit"
}
I would hate to lose the usage of those.
Author:  Henri Beauchamp [ 2017-06-08 14:56:35 ]
Post subject:  Re: Lua scripting related requests
ZaneZimer wrote:
Henri Beauchamp wrote:
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.
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:
Code:
C.debugSetting = {
  FN    = "FirstName", -- read only
  LN    = "LastName", -- read only
  CFV   = "CameraFrontView",
  RNHS  = "RenderNameHideSelf",
  RN    = "RenderName",
  RFC   = "RenderFarClip",
  SRFC  = "SavedRenderFarClip", -- read only
  AOZ   = "AvatarOffsetZ",
  SR    = "SpeedRez", -- read only
  SRI   = "SpeedRezInterval", -- read only
  RAMC  = "RenderAvatarMaxComplexity",
  RAMSA = "RenderAutoMuteSurfaceAreaLimit",
  RAMM  = "RenderAutoMuteMemoryLimit"
}
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.
Author:  ZaneZimer [ 2017-06-08 15:41:21 ]
Post subject:  Re: Lua scripting related requests
Henri Beauchamp wrote:
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.
Author:  ZaneZimer [ 2017-06-11 02:34:57 ]
Post subject:  Re: Lua scripting related requests
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]'.
Author:  Henri Beauchamp [ 2017-06-11 08:26:13 ]
Post subject:  Re: Lua scripting related requests
ZaneZimer wrote:
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...
Page 7 of 10 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/