LeafIllusion

Removed my post. See other posts with a simpler solution than mine. Sorry for the confusion.

Perfect! That fixed it. I figured there must be some setting that was messed up, just no idea where to begin looking. Thank you! How to: In the Main Menu top left of screen select Me > Preferences > Graphics tab > Uncheck the box labeled "Advance Lighting Model"

On the latest viewer I notice property lines now are not on surfaces, but float over objects. So I have property lines appearing on walls, ceilings, etc. Also when building the axis alignment lines no longer show a point of entry to the ground face, thus it is impossible to tell where the centerline of a prim is when positioning it. Best I can do is guess, place the prim, release it from edt, and hope it doesn't get taken if I accidentally got it placed over a property line. Is there a setting I can change to make the property lines paint onto the terrain face? Am I missing something? Thanks! Viewer 3.7.18 (295539) Here's an example of weird distorted property lines in red:

I hadn't checked on the 000 problem in a while, and was messing around yesterday and noticed I couldn't reproduce it. Tried in 3 different regions using a teleporter script that produced the problem in the past. Did a quick search of recent viewer and server release notes, but didn't see any references to llSetRegionPos (I admit I was lazy and didn't read each note.) Does anyone know if the 0,0,0 issue with llSetRegionPos has been fixed? Is anyone still having problems with 0,0,0 displaying when using llSetRegionPos? Oh, I should also say thanks to everyone who has helped me and provided input on this!

Well, at least now I feel a little less stupid! Thank you!

I'm having trouble getting messages created using llInstantMessage to go to my email. The messages are showing up in my email inbox, however the message text is empty. Ie; I get an email that says: The object 'Object' has sent you a message from Second Life: = Object is owned by LeafIllusion Resident The expected text from the llInstantMessage function in the script is not delivered in the email. If I run the script while I am logged in, the message does display as expected in my viewer. If another user IMs me when I am logged off I do get their complete messages through my email. I'm sure this is some simple, dumb thing I am doing wrong, but I am stumped as to what! Here's the simple script I'm using: key OWNER_KEY; default { state_entry() { OWNER_KEY = llGetOwner(); //get owner's key llSetTimerEvent(240.0); //to allow time to log off } timer() { llInstantMessage(OWNER_KEY,": this message was sent at "+ (string)llGetTimestamp() + "."); llSetTimerEvent(0.0); } }I could probably just use llemail to send the messages, but this has me annoyed and I would like to try to figure it out. Thanks for your help!

That would totally explain it. I knew it must be something stupidly simple! But I couldn't find a single article that explains degrees in relation to compass directions. Only took you 10 words! Thank you!

I am stumped by a behavior that doesn't seem logical to me, but I can't find anything that helps me figure it out after an hour or so of searching. I would think if what I was seeing was normal, something would be written someplace on it, so assume I'm doing something wrong... OK, humbly I submit my problem: I've made a simple script to make the avatar sit on an object facing north. My assumption is that using ZERO_ROTATION would achieve this. I realize that there is an issue with local vs. global rotation, so to assure that isn't an issue I'm also rotating the prim to ZERO_ROTATION (I assume that means it would face north?) What I am doing is setting the sit rotation to ZERO_ROTATION using llSitTarget. To align the prim, on touch it rotates to ZERO_ROTATION using llSetRot. So it seems like I should be able to touch the prim and it would align to north (it does), then when the avatar sits on the prim the avatar should also face to the north. Yet in all my tests the avatar sits facing east. I can obviously correct for this by rotating the avatar -90 degrees from ZERO_ROTATION, but what has me stumped is why this behavior occurs. So I guess I know how I can fix it, but I want to make sure there isn't something I'm missing here, because my goal is to become a good scripter rather than just slopping code together. Here's the test script I'm using: // Sit facing north default { state_entry() { llSitTarget(<0.0, 0.0, 0.6>, ZERO_ROTATION); } touch (integer num_detected) { llSetRot(ZERO_ROTATION); } } I feel like I'm missing something really obvious here, it's just too simple. But what? Unless normal behavior is for the avatar to sit rotated 90 degrees from the prim? Thanks for helping!!! PS. Am I misunderstanding that a rotation angle of 0 degrees on a compass would be north in SL? I've not really seen anything that actually says that, although I've seen some articles that imply it.

Fantastic script! Especially the v1.07. It eliminates the 0,0,0 issue and is fast. I did notice in my tests that to get the maximum speed the teleporter users need to have Disabled Camera Constraints on their viewers. That makes sense as it would need to move the camera beyond the 50m default viewer constraint for the distances I was testing. Nice work!!!

Just an update to my comment on draw distance. In testing on an open full-region premium sandbox the draw distance seemed to have a major impact as I previously noted. However, when testing using the same script in a complex private region with lots of buildings with custom textures, I noticed very little performance improvement from changing the draw distance. Apparently the complexity of the surroundings has a great deal to do with this...

Dora Gustafson wrote: I would like to know the result if someone does test it:) I tested it as written at Sandbox Verenda (entering destination coordinates that I know have created the 0,0,0 issue), and on 4 tests it worked beautifully each time... quick and smooth, no "0,0,0" issue. But it doesn't unseat the user from the prim or return the prim. The last section under "touch_end(integer num)" does not appear to execute. (Maybe it isn't supposed too? Am I expecting it to do something you didn't intend? I confess to just having my nose above water on this and most of your code completely loses me!) When I modified it to unseat the user and return the prim, it went the 0,0,0 route like the others. Now again, I must confess that I can't even follow your scripting, it is so far beyond my beginner abilities! I have never looked at camera controls and the like. So my effort to hack that last section to add "llUnSit(sitter)" and get it to execute is probably what is messing it up.

I did a rather crude test this morning with a teleporter installed in a substantial private sim build that creates the 0,0,0 problem/issue. Using my main computer for my avatar and putting a alt on my laptop, I was able to watch the process as viewed by both the teleporting avatar and others not involved in the process. As the avatar sat on the teleporter at the origination, the alt saw the avatar attach to and sit on the teleporter. (This teleporter is part of a store directory sign, so the avatar appeared to be imbedded in the sign.) There was no consistencey at this point. Sometimes the avatar would sit imbedded in the sign for a few seconds, sometimes it would just be just a flash and it was gone. Watcing both screens, the 0,0,0 effect never occured while the avatar was imbedded in the sign, it occured after the avatar had left the original location. When viewed from the destination the alt saw the avatar begin to materialize at the destination at the same time the avatar started seeing the 0,0,0 effect. So when the avatar being teleported is seeing the 0,0,0 location on their screen, everyone else is seeing the avatar already materializing at the destination. Hope that information helps.

Another possible issue with llSetRegionPos: After the teleporter prim returns to it's original location it sometimes becomes invisible to the avatar who just used it to teleport. In other words, if you teleport then walk back to the original teleporter location the teleporter prim is not longer visisble. Sometimes it is just "alpha" and can be sat on although not visible. Other times it is not even clickable. It is visible and useable to other avatars, it is just the one that used it that can't see it. I have only been able to duplicate this in the Second Life Viewer 3.3.4 and not in the current Firestorm. Possibly a viewer issue? I've not been able to find any other mentions of this in the forums. Thought I would mention it since it showed up numerous times during my llSetRegionPos teleporter tests. Anyone else noticed this one?

As with Qwalyphi, I've found inserting a 5 second delay averts the going to 0,0,0 problem, but of course, the cure is about as bad as the problem. In response to some of the other comments, the going to 0,0,0 issue almost never happens when making a vertical teleport. I can also easily go 1000m as long as it is vertical. With a few very specific exceptions, it only happens when moving horizontally across the sim for longer distances. For example I have 4 of these teleporters using this script in my SL home and all work well and extremely fast for the short hopes between rooms. I did try hopping across a sim diagonally using primarily vertical hops. I did this by jumping from one corner up to the 4090m level then back down to the opposite corner of the sim at ground level. When I tried that the 0,0,0 issue occured on the way down. I have tried inserting various length delays into my script in multiple combinations of places with no success unless the delays exceeded a length of 5 seconds. But having the avatar implanted on the teleporter in a store directory sign for 5 seconds looks rather silly, so not a good option! I even tried hopping in 50m jumps across the sim, but also still had the 0,0,0 issue. It is possible I could create a 2 hop teleport that places the avatar into a hidden room in the sim for the 5 second duration... if all else fails that is my plan B at this point. I am starting to wonder if this is this an intentional feature of llSetRegionPos? So far the only reasonably reliable cure that does not need a delay that I have found is to increase my avatar's draw distance to 300m. But that isn't helpful for a teleporter that will be used by others as part of a public sim. It seems to me that this going to 0,0,0 may be a method that the function creators are using to address the time needed by the viewer to load the terrain and texture data for the new destination location. So perhaps the function is designed to devert the prim to 0,0,0 during this process. In most cases that would be an oout of the way location for it to sit and wait for the data to load. Going to 0,0,0 wouldn't seem to be such a bad thing if it were possible to blank the user's screen or something during the process. But it is a bit unnerving for an unsuspecting avatar who expects to be teleported to a specific location to find themselves suddenly underwater or underground. It will give the feeling of an error having happened and they may log out asuming a crash. I should also not that there is not an issue with llSetRegionPos failing. Of the 80 or so test teleports I've conducted over the last 3 days, only twice has the teleport failed to complete. The avatar does make it to a lcoation within a few meters of the destination. It is just a visually unpleasant process. Here is the basic code segment I have been using. Very basic and simple. The llSleep command has been moved to various location and values in my tests so it can be ignored, this is just where it was on my last test. Changing it to a 5 second delay at the current position often (not always) does work to stop the 0,0,0 problem. { vector init_pos = llGetPos(); llSetRegionPos(destination); // use llSetRegionPos function llSleep(0.2); llUnSit(user); llSetRegionPos(init_pos); // use llSetRegionPos function} I really appreciate all the responses an suggestions and comments. Thank you all! Keep brainstorming and making suggestions if you will, I will continue to test whatever pops into my feeble brain!

Further testing indicates there is a strong relation to the draw distance set in the viewer's graphics options. With draw distance set at 300m the successful completion of a 200m teleport without stopping at 0,0,0 was over 80% of the attempts. So does this indicate the viewer is waiting for information to draw the new location? Is there any cure for this, or just a price to pay for a long teleport? Other odd things I noted in the 20 test runs using a simpler script than my earlier tests used. With the draw distance set at 100m, on about 1/3 of the teleports the avatar went to 0,0,0 before eventually going to the destination. On another 1/3 the teleporter worked quickly and reasonably accurately. On the last 1/3 my avatar started walking briefly before teleporting and walked a short distance after arriving at the destination. One time after sucessfully completing the teleport to the destination, the avatar turned and walked by itself all the way across the sim back to the teleporter!