Wolfe Blackburn

Thank y'all for your suggestions. Things I've tried so far which did not have an impact at all: Setting folder (Firestorm's local and roaming AppData) and process exlusions in Windows Defender Turning off all the bells and whistles in /System Properties/Advanced/Performance Texture memory setting in Firestorm is maxed out at 512 MByte Further differences I observed: Under Windows 10 I have an average of about 40% CPU load on all 4 cores - under Windows 7 only 2 cores are under load (40-50%). GPU load runs about 50-60% under both OS (no real difference to observe). I do have visible (in statistics) network packet loss under Windows 10, anything up to 1.5% - under Windows 7 this number is stuck at zero. I appreciate all further suggestions. Will try to let AMD's Adrenaline to auto-tune the viewer app. Right now I do not want to disable all kinds of graphics settings in the viewer since my goal is to figure out why the very same computer performes so much worse under Windows 10. Turning off things like advanced lighting under Windows 10 would result in a comparison of apples and oranges (since it is enabled under Windows 7).

I am in the process of finally migrating from Windows 7 to Windows 10. I have a dual boot installation. So I can directly compare performance under Windows 7 and Windows 10 on one and the same machine. The problem is: under Windows 10 the fps is about 30-40% of what I get under Windows 7. My system is a AMD FX-4350 with 16 GByte of ram and an AMD HD-7750 graphics board. Both Windows 7 and Windows 10 have the current graphics drivers from AMD installed. The problem is not viewer dependent; it happenes with the LL viewer as well as Firestorm. Graphics settings in the viewers are identical under Windows 7 and Windows 10. I run the same power profile settings under Windows 7 and Windows 10. I tested OpenGL performance using GFXBench and the results are slightly better! in Windows 10 than Windows 7. I am on a 100 MBit synchronous internet connection (wired). What I have noticed: ping times are greatly fluctuating under Windows 10. This is not a problem of the network connection; we all know meanwhile that when the viewer reports 100ms of ping time it simply means that it pings the server every 100ms because that's the time it takes to complete a frame. Ping time is basically the inverse of the fps value. It simply looks like Windows 10 is dragging its heels. Thanks for any advice! Wolfe.

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.

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. 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.

OK ... if that is expected behavior, then I have 3 more questions to help me understand what is going on: 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). Why do I not have to hit ESC before sitting on the teleporter when I do NOT wear my camera hud? 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.

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.