Jump to content

Soto Hax

Resident
  • Content Count

    52
  • Joined

  • Last visited

Community Reputation

4 Neutral

About Soto Hax

  • Rank
    Advanced Member
  1. To clarify, by "time of day" I mean Sunrise, Midday, Sunset and Midnight.
  2. So I'm having the same issue on the latest, non-pre-release default LL viewer in Blake Sea (mainland). Here's what I've found. Advanced Lighting Model (ALM) on/off makes no difference at all. If I go to [TOP MENU]> World > Sun > [PICK A TIME OF DAY], everything is as it should be. If I then go to that same menu and pick Region Default, the resulting bad lighting is dependent on but different from the time of day chosen in the previous step. I'm assuming this is because the server-side EEP changes have been implemented, and the non-EEP viewer release doesn't know what to do with it. -------------------- Second Life Release 6.1.0.524670 (64bit) Release Notes You are at 142.5, 206.7, 22.7 in Blake Sea - Turnbuckle located at sim9734.agni.lindenlab.com (216.82.45.68:13007) SLURL: http://maps.secondlife.com/secondlife/Blake%20Sea%20-%20Turnbuckle/142/207/23 (global coordinates 290,190.0, 268,751.0, 22.7) Second Life Server 19.03.07.525089 Release Notes CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (3392.28 MHz) Memory: 8147 MB OS Version: Microsoft Windows 10 64-bit (Build 17134) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce GTX 960/PCIe/SSE2 Windows Graphics Driver Version: 23.21.13.8813 OpenGL Version: 4.6.0 NVIDIA 388.13 Window size: 1920x1017 Font Size Adjustment: 96pt UI Scaling: 1 Draw distance: 64m Bandwidth: 10000kbit/s LOD factor: 1.125 Render quality: 5 Advanced Lighting Model: Enabled Texture memory: 512MB VFS (cache) creation time: January 15 2019 17:01:07 J2C Decoder Version: KDU v7.10.4 Audio Driver Version: FMOD Ex 4.44.64 Dullahan: 1.1.1080 / CEF: 3.3325.1750.gaabe4c4 / Chromium: 65.0.3325.146 LibVLC Version: 2.2.8 Voice Server Version: Not Connected Packets Lost: 4,968/529,942 (0.9%) March 24 2019 11:56:44
  3. Two months later. I have in fact experienced the occasional failure of this method. Pretty rare though.
  4. Question for the experts: What is a reasonable amount of total script time for each type of region? Like an amount beyond which you'd start to see noticeable region performance degradation (sim lag) if we assumed each region on a processor is the same region type with the same total script time?
  5. Hokay. I've been using it for five days now and haven't had a single failure. I think the extra one second delay did the trick. =)
  6. I'm finding it fails on rare occasion. I've added a one second delay to see if that fixes it. RunWait, SecondLifeViewer.exe, C:\Program Files (x86)\SecondLifeViewer Run, flux.exe, C:\Users\user\AppData\Local\FluxSoftware\Flux WinWait, f.lux Sleep, 1000 WinHide Exit
  7. tl;dr: Launch SL using this AHK script below from now on to fix that stupid f.lux black/rainbow screen bug. Modify paths as needed. So there's this weird bug where every single time you exit Second Life while running f.lux, the screen goes black or goes all crazy rainbow colours. The mouse pointer remains visible. For some reason, right clicking on the f.lux system tray icon and then clicking somewhere else on the screen fixes it. Now before you start chiming in with all sorts of ideas about how to fix this problem, let me just point out that I've seen this bug consistently on multiple machines, multiple video cards of both nVidia and ATI make, and multiple video drivers. No, f.lux safe mode doesn't fix it. Please. Spare me. =p I've gotten quite good at knowing precisely where on my screen the f.lux icon is, so I can click it blind to fix the screen most of the time. This is a real pain in the ass though. What's worse, there's a focus-stealing yes/no dialog box that pops up when the default viewer wants to do an automatic update installation, so you have to press the correct arrow key to highlight the yes button and hit enter, THEN find the damn f.lux icon. You could of course just uninstall f.lux, but I for one am unwilling to do that. f.lux is a wonderful program that reduces eye strain and (allegedly) improves sleep patterns, so I'm not going to give that up. There's a better solution: AutoHotKey. AutoHotKey (AHK) is a very powerful operating system automation script engine. You can write scripts to automate all sorts of complicated tasks in Windows, Mac and Linux with a variety of triggers and conditions. I've written an AHK script that does the following: 1.) Launch Second Life. 2.) Wait until the Second Life process has terminated. 3.) Launch f.lux. 4.) Wait until a window titled "f.lux" exists. 5.) Hide the f.lux window. 6.) Exit script. Here is the code: RunWait, SecondLifeViewer.exe, C:\Program Files (x86)\SecondLifeViewer Run, flux.exe, C:\Users\user\AppData\Local\FluxSoftware\Flux WinWait, f.lux WinHide Exit This has the exact same effect as the manual solution, but is infinitely more convenient and error proof. So install AHK and run this script instead of launching Second Life directly from now on. Just make sure you edit the paths in the script to match your particular setup/environment first. I also made a desktop shortcut to the script and changed the shortcut icon to the Second Life logo, just so it doesn't feel weird. I haven't tested this script in other environments or during a default viewer automatic update, so let me know if you find any bugs. Again, make sure you change the file paths in the script to match your own setup.
  8. ....oh! Damn! How did I not see something that basic? That makes perfect sense. Its getting to around 130m and then not detecting anything. Thanks. =p
  9. I'm writing a script that performs an llSensor() call, processes the results, moves the script container up 30m, then calls llSensor() again as long as pos.z < 4096m. Trouble is, the thing always seems to stop around 130m to 140m up without any errors or output from the pos.z > 4096m block. This also happens with llSetPos() and llSetPrimitiveParams(), and llSleep(16.0) doesn't seem to help at all either. Another curious fact is that if I reduce the step to 10m instead of 30m, it still stalls around the same height and takes more steps up to get there. It doesn't happen if I remove all the sensor stuff. Is there some limitation I'm hitting here of which I'm unaware? Code is as follows: float NORTH = 168; float SOUTH = 135; float EAST = 160; float WEST = 135; list objKeys = []; vector startPos = ZERO_VECTOR; default { touch_start(integer total_number) { startPos = llGetPos(); llSensor("",NULL_KEY,SCRIPTED,96.0,PI); } sensor(integer num_detected) { integer i = 0; for(i; i < num_detected; i++){ key objKey = llDetectedKey(i); integer already_scanned = llListFindList(objKeys,[objKey]); if(!already_scanned){ vector pos = llDetectedPos(i); integer within_parcel = pos.x > EAST && pos.x < WEST && pos.y > SOUTH && pos.y < NORTH; if(within_parcel){ objKeys += objKey; } } } vector up = llGetPos() + <0,0,30>; if(up.z < 4096){ llSetRegionPos(up); llSensor("",NULL_KEY,SCRIPTED,96.0,PI); } else{ llSetRegionPos(startPos); llOwnerSay((string)llGetListLength(objKeys)); } } }
  10. Steps to Reproduce: 1.) Open edit shape panel. 2.) Increase hover slider by 5 (starting point seems to be irrelevant). 3.) Click save button. 4.) Close panel. 5.) Walk forward. Result - Previously saved hover value suddenly plunges down to 13. Avatar ends up in the ground. Subsequently increasing the hover value up from 13 seems to fix it.
  11. What the hell do you want, a "We're sorry" coupon?
×
×
  • Create New...