[#VWR-1405] llMapDestination does not work as designed for OS X/Intel viewers

1. Second Life Viewer - VWR

llMapDestination does not work as designed for OS X/Intel viewers

Created: 27/Jun/07 12:34 PM Updated: 24/Jul/08 03:13 PM

Component/s:

Scripting

Affects Version/s:

1.17.0.x, 1.18.4.3, 1.18.5.3

Fix Version/s:

1.20

Environment:

OS X 10.4.10 and earlier on Intel. Happens in all 1.17 and earlier, as well as all currenty First Look clients.

Issue Links:

Relates

This issue is related to by:

VWR-2060 llMapDestination (and possibly SLURLs) sometimes fail to use the target vector data

VWR-1577 Meta-Issue: Bugs or improvements suitable for open source programmers

Linden Lab Issue ID:	DEV-2071
Linden Lab Internal Branch:	maintenance-6

Description

« Hide

When using a script with llMapDestination that uses coordinates outside the originating sim with the OS X/Intel viewer, the destination presented on the map is not in the correct location. This is only evident with the Intel version of the client, OS X on PPC seems to work as designed.

Example LSL script:

default {

state_entry()
{
}
touch_start(integer num_detected)

{ llMapDestination("Boksik", <-1723.69,49534.9,25.99>, <0,0,0>); }

}

On Windows and OS X/PPC viewers, that llMapDestination takes you to <69,126,25> on Almaden sim, but on OS X/Intel it attempts to drop you six sims to the east. All llMapDestination targets on OS X/Intel take you several sims eastwards of where the destination should be.

Unkown if the Linux viewer has the same issue.

- - - - edit by Missy Malaprop ****
        the issue is that all negative vector positions are set to 0, positive numbers work fine, but any sized negative number is set to 0.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Missy Malaprop added a comment - 03/Jul/07 11:33 AM

I looked at this issue a lot and was about to report it when i foud it already has been reported.

When you use a negative number in a vector position on llMapDestination, it sets it to 0 instead of the actual negative number. positive numbers work fine, but all negatives are changed into 0. It seems to only happen on Intel Macs, nothing else... even PPC Macs are said to work ok.

[ Permlink | « Hide ]

Daedalus Young added a comment - 16/Jul/07 06:35 PM

Edit: Added "Scripting" Component.

[ Permlink | « Hide ]

Strife Onizuka added a comment - 05/Aug/07 11:31 PM

it sounds like they used the wrong variable types in llMapDestination or the underlying transport of the data. Sounds like they mixed signed and unsigned number types and when the conversion is done on any platform other than OS X/Intel, it just copies the memory but on OS X/Intel its actually performing the conversion. This wouldn't surprise me in the least I think it's why the great zero is at sim 1000x1000 (Da Boom).

[ Permlink | « Hide ]

Torley Linden added a comment - 21/Aug/07 10:36 AM

This sounds like part of the problems in VWR-2060 – please distinguish if it's actually a different and separate issue.

[ Permlink | « Hide ]

Rifkin Habsburg added a comment - 11/Oct/07 11:43 PM

This is a separate issue – it only affects the OSX/Intel viewer. VWR-2060 affects all viewers.

[ Permlink | « Hide ]

Rifkin Habsburg added a comment - 11/Oct/07 11:50 PM

This is not a duplicate of VWR-2060, it's a separate issue that only affects the Intel-OSX viewer.

[ Permlink | « Hide ]

Saskia McLaglen added a comment - 15/Oct/07 10:56 AM

This is a separate issue to VWR-2060. I am on an Intel Mac, OSX 10.4.10 using the Second Life 1.18.3 (5) client.

It can be reproduced everytime for me using the exact code from the wiki entry for llMapDestination found at

[url]http://rpgstats.com/wiki/index.php?title=LlMapDestination[/url]

as well as with my own code.

Please fix this asap!

[ Permlink | « Hide ]

Keiki Lemieux added a comment - 28/Nov/07 11:33 PM

I'm getting reports of this from people using my HUDs.

[ Permlink | « Hide ]

Raven Quine added a comment - 28/Nov/07 11:36 PM

Also is affecting version 1.18.4.3 regular landmarks are fine but anything in a landmark program sets it up all wrong.

[ Permlink | « Hide ]

Monica Balut added a comment - 13/Jun/08 05:23 PM

The same problem was recently reported to me by one of the Mac users of my teleporting HUD. He was using the 1.19 viewer. Needs to be fixed.

[ Permlink | « Hide ]

Haruki Watanabe added a comment - 13/Jun/08 05:54 PM - edited

It's not only negative vectors - it seems the whole function is borked on intel macs at all.

Using llMapDestination doesn't bring up the map nor does it add the vectors to it.

(iMac 2.16 GHz, Intel Core 2 Duo, 2GB RAM, OS-X Leopard 10.5.3)

[ Permlink | « Hide ]

Bridie Linden added a comment - 17/Jul/08 03:03 PM

Fixed in 1.20!

[ Permlink | « Hide ]

Bridie Linden added a comment - 17/Jul/08 03:04 PM

Fixed in 1.20 RC0