Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2024-03-28 15:12:30



Reply to topic  [ 95 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9, 10  Next
Lua scripting related requests 
Author Message

Joined: 2016-06-19 21:33:37
Posts: 337
Location: Columbus area, OH, USA
Reply with quote
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'. :-)


2017-05-04 12:54:03
Profile

Joined: 2016-06-19 21:33:37
Posts: 337
Location: Columbus area, OH, USA
Reply with quote
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. :-)


2017-05-06 19:14:56
Profile

Joined: 2016-06-19 21:33:37
Posts: 337
Location: Columbus area, OH, USA
Reply with quote
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.


2017-06-08 03:02:46
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
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.


2017-06-08 11:47:26
Profile WWW

Joined: 2016-06-19 21:33:37
Posts: 337
Location: Columbus area, OH, USA
Reply with quote
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.


2017-06-08 12:40:47
Profile

Joined: 2016-06-19 21:33:37
Posts: 337
Location: Columbus area, OH, USA
Reply with quote
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.


2017-06-08 13:33:03
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
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.


2017-06-08 14:56:35
Profile WWW

Joined: 2016-06-19 21:33:37
Posts: 337
Location: Columbus area, OH, USA
Reply with quote
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.


2017-06-08 15:41:21
Profile

Joined: 2016-06-19 21:33:37
Posts: 337
Location: Columbus area, OH, USA
Reply with quote
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]'.


2017-06-11 02:34:57
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
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...


2017-06-11 08:26:13
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 95 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9, 10  Next

Who is online

Users browsing this forum: No registered users and 30 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:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.