Jump to content
Wolfe Blackburn

Teleporter Camera Override Problems

You are about to reply to a thread that has been inactive for 801 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I am in the process of creating a teleporter for local use on a sim. I have a 10 year old commercial product (the creator left the grid so I can't ask him) which works perfectly but does not have access control. So I decided to make one myself. Anyway, this is how the original product (and my current work) works:

Avatar touches a prim (can be linked with other object, like building). Script in prim checks if avatar is authorized and then rezzes a prim to sit on (the beamer). The beamer transports avatar to destination and then self destructs.

So far, so good. All this works nicely. I am using a modified version of "warppos" to do the actual teleporting. And here is my problem:

If I have a camera hud running, I must hit ESC before sitting on the teleporter. Otherwise the camera will simply not follow the avatar to the teleport destination. Without running a camera hud, everything works fine right away.

I did vehicle scripts in the past and never had a problem taking over the camera. My vehicles use llSetCameraParams to setup the camera. I did the same in my teleport script. And yet, for the teleporter I must hit ESC (release the camera to default) before using the teleporter (otherwise my camera settings in the teleporter script are not applied).

So the question is: what is the difference between a (non physical) teleporter and a (physical) vehicle? Does the physics allow me to take over the camera (even if user did not hit ESC)? The only difference I can see in my scripts is the fact that the teleporter is non physical and the vehicle is physical. I never thought about it in the past but how does a vehicle script enforce its own camera settings even if the current settings at the time of sitting on the vehicle (from lsl wiki: " Scripted camera parameters will not set for the agent if the last controls they used were their camera controls. Manual camera control will override set parameters too.") are not the defaults?

Thanks for any hints on this matter,

Wolfe.

Share this post


Link to post
Share on other sites

That's expected behavior. Essentially,  you have moved on and your cam is still focused on where you used to be, unless you force it to focus on you by hitting ESC.

Incidentally, do not use warppos or anything like it. That hack has been unnecessary since about 2010. Use llSetRegionPos instead.

Share this post


Link to post
Share on other sites
51 minutes ago, Rolig Loon said:

That's expected behavior. Essentially,  you have moved on and your cam is still focused on where you used to be, unless you force it to focus on you by hitting ESC.

Incidentally, do not use warppos or anything like it. That hack has been unnecessary since about 2010. Use llSetRegionPos instead.

OK ... if that is expected behavior, then I have 3 more questions to help me understand what is going on:

  1. Why do I not have to hit ESC when sitting on a (physical) vehicle? As soon as I sit, the camera goes in position behind and above the vehicle. This works no matter if I am wearing a camera hud or not (I tried 2 camera huds, my own and a commercial product, makes no difference).
  2. Why do I not have to hit ESC before sitting on the teleporter when I do NOT wear my camera hud?
  3. What might the scripter of my old 2008 teleporter have done to overcome the camera problem? If I use that old teleporter, the camera will follow me no matter if I am wearing a camera hud or not.

And yes, you are right of course regarding warppos. I actually started out using llSetRegionPos, then switched to a warppos implementation to match that old 2008 teleporter as close as I can imagine (see question #3). Just wanted to make sure that there is no difference in the camera following problem depending on using llSetRegionPos vs warppos.

Share this post


Link to post
Share on other sites

The difference is that the teleporter moves you instantly,  so your camera lags and can't keep focused on you. In a vehicle the cam has a much easier time following you. Many years ago, Dora Gustafson did some trials with a system for tricking the cam into staying with you through a teleport. I have used her code a few times, with limited success, but it's not perfect. It is still best to simply hit ESC becore you TP.

Share this post


Link to post
Share on other sites

Would be nice to have scripted camera reset capability.

Also, warppos is a linear process that cannot cross no entry parcels if you're not explicitly plotting a course around said parcels when building the position list.

Jumppos has a risk of objects going off world in a northeast region thousands of meters away.

llSetRegionPos() is the better candidate.

Share this post


Link to post
Share on other sites
3 hours ago, Rolig Loon said:

The difference is that the teleporter moves you instantly,  so your camera lags and can't keep focused on you. In a vehicle the cam has a much easier time following you. Many years ago, Dora Gustafson did some trials with a system for tricking the cam into staying with you through a teleport. I have used her code a few times, with limited success, but it's not perfect. It is still best to simply hit ESC becore you TP.

Yes I studied Dora Gustafson's scripts. Setting the camera to the target position only works when camera control has been released prior to the teleport - and then you don't have the problem in the first place.

3 hours ago, Lucia Nightfire said:

Would be nice to have scripted camera reset capability.

Also, warppos is a linear process that cannot cross no entry parcels if you're not explicitly plotting a course around said parcels when building the position list.

Jumppos has a risk of objects going off world in a northeast region thousands of meters away.

llSetRegionPos() is the better candidate.

Yeah I know, both warppos and jumppos are outdated. I used them temporarily to see if it would make any difference with the problem of the camera staying behind. llSetRegionPos (followed by a final llSetPos for a finishing touch) sure is the way to go.

---

I did some more testing with a vehicle - really making sure that I did use my camera control before sitting on it. Banked the camera to the left, hopped on the vehicle and the camera stayed on the left. Vehicle could not override. You are right, Rolig.

But here's the thing: using that stone old commercial (aka no mod) teleporter script from Klug Kuhn, I can do a 1000m TP over and over. It works. Every time. The camera follows like it is the most normal thing in the world. I can even manually adjust my camera to like, look at my left side and then TP. After the TP, I still look at my left side. That guy must have used some hack to make the camera follow no matter what. It's just sad that such precious knowledge can get lost.

If any of you scripters want to try that thing to see how wonderful it works, let me know.

Thanks.

Share this post


Link to post
Share on other sites

Lucia Nightfire was so nice to come over to my place yesterday evening to test that old teleporter which I have. To my surprise, she told me that her camera does stay behind when she uses my tp! She suggested that I try again using the LL viewer (I only use FS) to make sure that it's not one of the many switches FS has in its move/view preferences that make my camera follow the tp. I will do that.

So the mystery remains. Because the camera does not follow me when I use my own tp script. I'll keep y'all updated in this thread.

Share this post


Link to post
Share on other sites
18 hours ago, Wolfe Blackburn said:

(I tried 2 camera huds, my own and a commercial product, makes no difference).

There are lots of different things a "camera HUD" might do, and I'm having trouble coming up with an explanation for how any of those would behave differently with one teleporter versus another, which I guess is the main puzzle at the moment.

Some passing observations, probably irrelevant:

  • Returning the camera to the "default" (as opposed to alt-zoom focused on an object) doesn't require an explicit "ESC" keypress. Ordinarily, the avatar walking around will suffice (but I can't guess how a camera HUD might affect this). I mention this because I made an Experience-based walk-through "portal" teleporter, which for a time hid from me a cam-orientation-specific misbehavior of the "look-at" argument to llTeleportAgent[GlobalCoords]() -- which admittedly has nothing to do with the current topic. I'm just suggesting that if there's a difference in how the avatar gets to sit on the two different teleporters, it might alter how they affect the cam.
  • The cam behaves differently when it's tracking an object than when it's just pointed out in a particular direction. I can't come up with an explanation, though, for why this should matter when a camera HUD is already overriding the default cam, especially in a way dependent on which teleporter is involved.
  • The prim properties set by llSetCameraAtOffset and -EyeOffset only apply to the default cam, so I don't think they have any effect if a camera HUD has already moved the cam to a scripted position with llSetCameraParams -- but I'm not entirely sure that's (universally?) true. Anyway, I was hypothesizing that one teleporter had such prim properties and the other didn't, and that was somehow interacting with the camera HUD's function.

Share this post


Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 801 days.

Please take a moment to consider if this thread is worth bumping.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...