• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-8485
Type: New Feature New Feature
Status: Open Open
Priority: Normal Normal
Assignee: Unassigned
Reporter: Elwe Ewing
Votes: 2
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

llMapDestination little behaviour modification

Created: 02/Aug/08 09:24 AM   Updated: 06/Jun/09 04:30 AM
Return to search
Component/s: Scripting
Affects Version/s: None
Fix Version/s: None

Issue Links:
Relates
 


 Description  « Hide
I recently used the llMapDestination function to build a "navigation system aid" which copes to the main Map limitation that not permits to set a number of locations as "waypoints" prevent making a "route" to follow.
This tool can be useful to anybody who wants to start from point "A" and reach point "Z" passing through points "B", "C", and so on even if "A" and "Z" are really far away (the limitation in the number of waypoints is actually only in the way the script stores the SLURLS that defines them: I tested my tool up to 90 waypoints at the moment, which is a long route to follow).

The "annoying" problem is due to the fact that there is no way to use llMapDestination without open the Map (and no way to close a "window" from a script, like llCloseWindow(WND_MAP)): the better way to work, for my point of view, is to set a destination (which makes the "red pole" visible) without popping up the Map.
I know that this is NOT the original use for llMapDestination was designed for, but I think there should be no problem to add an optional "boolean" flag to the existing instruction to permit/inhibits the Map pop-up at each call, leaving the original behaviour as the default one to avoid breaking existing scripts and keeping the original use of the instruction (but permitting this "new" one).

llMapDestination(string simname, vector position, vector lookat, integer nomap)

the nomap flag, optional to the instruction, defaults to FALSE: if set to TRUE prevents the Map to pop-up and sets the new location only.

I read the wiki documentation and the JIRA issues and comments, and didn't found a reason, even security one, to not implement this little improvement.
More: this behaviour can help preventing the problems described into SVC-1038 in two ways:
(1) if directly programmed using the new flag, the Maps never pop-up setting the red-pole only (this way is for non-griefers programming),
(2) if the flag is set for any internal call, not related/due to an event, the Map pops-up the first time only (the event-related one): any subseguent "loop" call only sets a new location but never pops-up the map untill a new (touch) event. So one simply close the map and perhaps watch the red pole to change position but is never spammed by map popups.

I suggest to leave all Teleport issue to a (most wanted) llTeleport that will be implemented: with llMapDestination one can intend to "see/set a location on a map" not to "teleport there" which is a totally different kind of work to do.

 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Elwe Ewing made changes - 02/Aug/08 09:52 AM
Field Original Value New Value
Description  I recently used the llMapDestination function to build a "navigation system aid" which copes to the main Map limitation that not permits to set a number of locations as "waypoints" prevent making a "route" to follow.
 This tool can be useful to anybody who wants to start from point "A" and reach point "Z" passing through points "B", "C", and so on even if "A" and "Z" are really far away (the limitationin the number of waypoints is actually only in the way the script stores the SLURLS that defines them).

 The "annoying" problem is due to the fact that there is no way to use llMapDestination without open the Map: the better way to work, for my point of view, is to set a destination (which makes the "red pole" visible) without popping up the Map.
I know that this is NOT the original use for llMapDestination was designed but I think there should be no problem to add an _optional_ "boolean" flag to the existing instruction to permit/inhibits the Map pop-up at each call, leaving the original behaviour as the default one to avoid breaking existing scripts and keeping the original use of the instruction (but permitting this "new" one).

 llMapDestination(string simname, vector position, vector lookat, integer nomap)

 the nomap flag, optional to the instruction, defaults to FALSE: if set to TRUE prevents the Map to pop-up and sets the new location only.

 I read the wiki documentation and the JIRA issues and comments, and didn't found a reason, even security one, to not implement this little improvement.
 More: this behaviour can help preventing the problems described into SVC-1038 in two ways:
 (1) if directly programmed using the new flag, the Maps never pop-up setting the red-pole only (this way is for non-griefers programming),
 (2) if the flag is set for any _internal_ call, not related/due to an event, the Map pops-up the first time only (the event-related one): any subseguent "loop" call only sets a new location but never pops-up the map untill a new (touch) event. So one simply close the map and perhaps watch the red pole to change position but is never spammed by map popups.

 I suggest to leave all Teleport issue to a (most wanted) llTeleport that will be implemented: with llMapDestination one can intend to "see/set a location on a map" not to "teleport there" which is a totally different kind of work to do. 		 I recently used the llMapDestination function to build a "navigation system aid" which copes to the main Map limitation that not permits to set a number of locations as "waypoints" prevent making a "route" to follow.
 This tool can be useful to anybody who wants to start from point "A" and reach point "Z" passing through points "B", "C", and so on even if "A" and "Z" are really far away (the limitation in the number of waypoints is actually only in the way the script stores the SLURLS that defines them: I tested my tool up to 90 waypoints at the moment, which is a long route to follow).

 The "annoying" problem is due to the fact that there is no way to use llMapDestination without open the Map (and no way to close a "window" from a script, like llCloseWindow(WND_MAP)): the better way to work, for my point of view, is to set a destination (which makes the "red pole" visible) without popping up the Map.
I know that this is NOT the original use for llMapDestination was designed but I think there should be no problem to add an _optional_ "boolean" flag to the existing instruction to permit/inhibits the Map pop-up at each call, leaving the original behaviour as the default one to avoid breaking existing scripts and keeping the original use of the instruction (but permitting this "new" one).

 llMapDestination(string simname, vector position, vector lookat, integer nomap)

 the nomap flag, optional to the instruction, defaults to FALSE: if set to TRUE prevents the Map to pop-up and sets the new location only.

 I read the wiki documentation and the JIRA issues and comments, and didn't found a reason, even security one, to not implement this little improvement.
 More: this behaviour can help preventing the problems described into SVC-1038 in two ways:
 (1) if directly programmed using the new flag, the Maps never pop-up setting the red-pole only (this way is for non-griefers programming),
 (2) if the flag is set for any _internal_ call, not related/due to an event, the Map pops-up the first time only (the event-related one): any subseguent "loop" call only sets a new location but never pops-up the map untill a new (touch) event. So one simply close the map and perhaps watch the red pole to change position but is never spammed by map popups.

 I suggest to leave all Teleport issue to a (most wanted) llTeleport that will be implemented: with llMapDestination one can intend to "see/set a location on a map" not to "teleport there" which is a totally different kind of work to do.
Elwe Ewing made changes - 02/Aug/08 09:54 AM
Description  I recently used the llMapDestination function to build a "navigation system aid" which copes to the main Map limitation that not permits to set a number of locations as "waypoints" prevent making a "route" to follow.
 This tool can be useful to anybody who wants to start from point "A" and reach point "Z" passing through points "B", "C", and so on even if "A" and "Z" are really far away (the limitation in the number of waypoints is actually only in the way the script stores the SLURLS that defines them: I tested my tool up to 90 waypoints at the moment, which is a long route to follow).

 The "annoying" problem is due to the fact that there is no way to use llMapDestination without open the Map (and no way to close a "window" from a script, like llCloseWindow(WND_MAP)): the better way to work, for my point of view, is to set a destination (which makes the "red pole" visible) without popping up the Map.
I know that this is NOT the original use for llMapDestination was designed but I think there should be no problem to add an _optional_ "boolean" flag to the existing instruction to permit/inhibits the Map pop-up at each call, leaving the original behaviour as the default one to avoid breaking existing scripts and keeping the original use of the instruction (but permitting this "new" one).

 llMapDestination(string simname, vector position, vector lookat, integer nomap)

 the nomap flag, optional to the instruction, defaults to FALSE: if set to TRUE prevents the Map to pop-up and sets the new location only.

 I read the wiki documentation and the JIRA issues and comments, and didn't found a reason, even security one, to not implement this little improvement.
 More: this behaviour can help preventing the problems described into SVC-1038 in two ways:
 (1) if directly programmed using the new flag, the Maps never pop-up setting the red-pole only (this way is for non-griefers programming),
 (2) if the flag is set for any _internal_ call, not related/due to an event, the Map pops-up the first time only (the event-related one): any subseguent "loop" call only sets a new location but never pops-up the map untill a new (touch) event. So one simply close the map and perhaps watch the red pole to change position but is never spammed by map popups.

 I suggest to leave all Teleport issue to a (most wanted) llTeleport that will be implemented: with llMapDestination one can intend to "see/set a location on a map" not to "teleport there" which is a totally different kind of work to do. 		 I recently used the llMapDestination function to build a "navigation system aid" which copes to the main Map limitation that not permits to set a number of locations as "waypoints" prevent making a "route" to follow.
 This tool can be useful to anybody who wants to start from point "A" and reach point "Z" passing through points "B", "C", and so on even if "A" and "Z" are really far away (the limitation in the number of waypoints is actually only in the way the script stores the SLURLS that defines them: I tested my tool up to 90 waypoints at the moment, which is a long route to follow).

 The "annoying" problem is due to the fact that there is no way to use llMapDestination without open the Map (and no way to close a "window" from a script, like llCloseWindow(WND_MAP)): the better way to work, for my point of view, is to set a destination (which makes the "red pole" visible) without popping up the Map.
I know that this is NOT the original use for llMapDestination was designed for, but I think there should be no problem to add an _optional_ "boolean" flag to the existing instruction to permit/inhibits the Map pop-up at each call, leaving the original behaviour as the default one to avoid breaking existing scripts and keeping the original use of the instruction (but permitting this "new" one).

 llMapDestination(string simname, vector position, vector lookat, integer nomap)

 the nomap flag, optional to the instruction, defaults to FALSE: if set to TRUE prevents the Map to pop-up and sets the new location only.

 I read the wiki documentation and the JIRA issues and comments, and didn't found a reason, even security one, to not implement this little improvement.
 More: this behaviour can help preventing the problems described into SVC-1038 in two ways:
 (1) if directly programmed using the new flag, the Maps never pop-up setting the red-pole only (this way is for non-griefers programming),
 (2) if the flag is set for any _internal_ call, not related/due to an event, the Map pops-up the first time only (the event-related one): any subseguent "loop" call only sets a new location but never pops-up the map untill a new (touch) event. So one simply close the map and perhaps watch the red pole to change position but is never spammed by map popups.

 I suggest to leave all Teleport issue to a (most wanted) llTeleport that will be implemented: with llMapDestination one can intend to "see/set a location on a map" not to "teleport there" which is a totally different kind of work to do.
[ Permlink | « Hide ]
Strife Onizuka added a comment - 02/Aug/08 02:43 PM - edited
The way LSL is written it is incapable of supporting overloaded functions or optional parameters. This would require significant changes to the compiler.

McCabe Maxsted made changes - 04/Aug/08 09:47 AM
Project 4. Second Life Misc Issues - MISC [ 10000 ] 1. Second Life Viewer - VWR [ 10003 ]
Key MISC-1433 VWR-8485
McCabe Maxsted made changes - 04/Aug/08 09:47 AM
Component/s Scripting [ 10030 ]
[ Permlink | « Hide ]
Elwe Ewing added a comment - 04/Aug/08 11:22 AM - edited
It seems awful to me to request a new instruction's implementation (such as llSetMapDestination()) but if there is no way to modify llMapDestination they can clone nearly all of its code, leaving behind the one which opens the Map :-D, and create the new statement with the little requested add-on, thus the original one suffers of no modifications at all... and we have the means to make things like "gps".
In this case I request that we can pass a SLURL also to "mark" (which holds all the needed infos), instead of a name and a vector:

llSetMapDestination(integer mode, string simname, vector position, vector lookat)

mode: 0 = as llMapDestination (default), 1 = with SLURLS

if mode = 0
simname: name of the SIM
position: vector of the position to set, in region coordinates
lookat: vector of the AV orientation, in region coordinates (currently unused)

if mode = 1
simname: SLURL of the marked point
position: unused
lookat: unused

This new behaviour can be implemented into the existing Map also, but it seems to me that requesting such a little modification to llMapDestination was lighter than working on the Map (even if they decide to implement llSetMapDestination): it may be a problem, working on the Map, to load/register lists of SLURLS like a script can do (mine filters the clobbered "SLURLs" which come from the chat also ).
At last we've no way to create a Notecard from a script yet.

(thanks to McCabe also for the adjustments done on this proposal)


[ Permlink | « Hide ]
Strife Onizuka added a comment - 05/Aug/08 01:16 PM - edited
It would be a new function internally either way it was implemented (as a new function or an optional parameter/overload). It would be less work to make a new function (the changes to the wiki templates would not be fun).

I would go with the separate function and loose the look_at parameter:
llSetBeacon( string simname, vector pos );


[ Permlink | « Hide ]
Graven Gothly added a comment - 30/Sep/08 10:29 AM
An Improvement To The Current Functionality Would Be To have The "Teleport" Button Focused When llMapDestination Is Called. This Way The User Only Needs To Hit The Enter Key To Keep Going. Looks Now Like The Focus Shifts Between "Teleport" and "Search Results" And Pressing Enter Ends Up Clearing The SLURL .

darling brody made changes - 30/Sep/08 09:57 PM
Link This issue Relates to VWR-2060 [ VWR-2060 ]
[ Permlink | « Hide ]
darling brody added a comment - 30/Sep/08 09:57 PM
The focus issue may be related to the comments and problem described in VWR-2060.

Also a llTeleportAgent(key avatar, vector position, vector lookat, string region) is long overdue and would resolve most of these issues.

Darling Brody


[ Permlink | « Hide ]
Jahar Aabye added a comment - 07/Oct/08 12:57 PM
Graven, the problem with having the teleport button focused when the llMapDestination() is called is that it can result in a user being teleported immediately if they unintentionally click on an object scripted with this function. This is why, in general, computer functions with a default input for Enter are almost never given automatic focus in any (well made) program. There is simply too much room for error, for unintentional entry. Besides, the issue here is that the ticket reporter wishes to avoid opening the map at all.

As Darling points out, the subject of focus and map issues is discussed in VWR-2060, but the consensus there appears to be that it would be better to simply not shift the focus to the map at all, thus preventing both accidental clearing of the destination AND the possibility of being teleported immediately and unintentionally.

With regards to this specific feature request, I agree that the new function sounds like the best way to go, and it sounds like a useful idea. I could see it coming in handy when flying in SL, for instance, where we would often use the map beacon as a general header. Using this function, one could wear an attachment (since llMapDestination() can be called from attachments) and the wing leader could have a device that they speak the coordinates into on a backchannel, and it then llRegionSay()s the coordinates to the attachments of the other pilots, and immediately their map beacons all are set to the destination that can be used as a rendezvous.

I could also see it being useful for orientation in a sim, so when users teleport in to the hub, they're told "Welcome, once you've read through the rules, click the big button to see a red beacon, walk over there to find your free gear and get started...."


Sue Linden made changes - 13/Nov/08 11:06 AM
Workflow jira-2007-12-22a [ 57934 ] jira-2008-11-14 [ 63992 ]
Sue Linden made changes - 13/Nov/08 11:26 AM
Workflow jira-2007-12-22a [ 63992 ] jira-2008-11-14 [ 71218 ]
Sue Linden made changes - 13/Nov/08 04:51 PM
Workflow jira-2008-11-14 [ 71218 ] jira-2008-11-14a [ 93798 ]
Sue Linden made changes - 13/Nov/08 05:08 PM
Workflow jira-2008-11-14 [ 93798 ] jira-2008-11-14a [ 100007 ]
Sue Linden made changes - 13/Nov/08 05:16 PM
Workflow jira-2008-11-14 [ 100007 ] jira-2008-11-14a [ 103086 ]
Sue Linden made changes - 13/Nov/08 05:28 PM
Workflow jira-2008-11-14 [ 103086 ] jira-2008-11-14a [ 107863 ]
Sue Linden made changes - 13/Nov/08 05:56 PM
Workflow jira-2008-11-14 [ 107863 ] jira-2008-11-14a [ 117276 ]
Sue Linden made changes - 13/Nov/08 06:19 PM
Workflow jira-2008-11-14 [ 117276 ] jira-2008-11-14a [ 126079 ]
Sue Linden made changes - 13/Nov/08 06:38 PM
Workflow jira-2008-11-14 [ 126079 ] jira-2008-11-14a [ 133129 ]
Sue Linden made changes - 13/Nov/08 07:01 PM
Workflow jira-2008-11-14 [ 133129 ] jira-2008-11-14a [ 142234 ]
[ Permlink | « Hide ]
darling brody added a comment - 06/Jun/09 12:43 AM - edited

llTeleportAgent - ...and the nice version that lets you teleport a prim if your sitting on it too. so vehicles can teleport when desired.

We really need to lobby for this. It would solve all the issues in many different jira's. llMapDestination does just what it says, it shows a map of the destination. And people like myself are trying to use it as a seamless teleport to detination, which is just plain ugly.

What we need is a dialog box that says "Teleport to : <destination from script string>", with whatever security people think it needs.

llTeleport(key avatar, vector position, rotation rot, string region, string message, integer take_prim_flag)

The take_prim_flag tells the region to treat the teleport like a vehicle crossing a region border and take the prim your sitting on with you. This will let a teleporter take the particle poofer with you to complete the teleport effect, and also for vehicles to do cool stuff like fly though a stargate, or go into warp drive etc.

If I had this I woudl be able to make a space ship that can teleport. When teleport is desired I would expand a large prim around the spaceship that looks like some kind of space warp drive effect and then call the llTeleport function. Once the space ship arrived I could hide the effect prim again. (this all assumes that the black screen we normally see on teleport it not shown when we do a teleport with the take_prim_flag set true)

this stuff was lifted from another jira which i just cant seem to find right now.... but it was one i listed years ago....

Darling Brody.


[ Permlink | « Hide ]
Elwe Ewing added a comment - 06/Jun/09 04:30 AM
@darling brody: I think is better to create a new issue/feature request yourself, about llTeleportAgent: this issue is "limited" on llMapDestination (and/or llSetMapDestination).

Optionally, implementing the new statement, we can insert one more parameter:

llSetMapDestination(integer mode, string simname, vector position, vector lookat, integer teleport)

integer teleport:
TRUE = set the new destination AND teleport there instantly,
FALSE = set the new destination only without teleport (default to FALSE).
Powered by Atlassian JIRA the Professional Issue Tracker. (Enterprise Edition, Version: 3.13.2-#335) - Bug/feature request - Atlassian news - Contact Administrators