Soto Hax

Resident
  • Content count

    50
  • Joined

  • Last visited

Community Reputation

4 Neutral

About Soto Hax

  • Rank
    Advanced Member
  1. Reasonable region script time?

    Makes sense. Thank you.
  2. I made a solution to the f.lux bug. =3

    Two months later. I have in fact experienced the occasional failure of this method. Pretty rare though.
  3. 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?
  4. I made a solution to the f.lux bug. =3

    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. =)
  5. I made a solution to the f.lux bug. =3

    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
  6. 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.
  7. Sensor Loop + SetRegionPos = Height ceiling?

    ....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
  8. Sensor Loop + SetRegionPos = Height ceiling?

    Code added to original post.
  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. Unscheduled Maintenance [COMPLETED]

    Fine, fine, I'm sorry for the language.
  12. Unscheduled Maintenance [COMPLETED]

    Really? I didn't know that. o_0
  13. Unscheduled Maintenance [COMPLETED]

    What the hell do you want, a "We're sorry" coupon?
  14. Unscheduled Maintenance [COMPLETED]

    * Bandwidth - They're still paying for that. They would purchase network bandwidth in bulk at a flat rate, not pay for it by the gigabyte like you seem to be suggesting. * Support - They still have to pay their support people. They're not gonna come in to work only to be told, "Oop, sorry, network's down, go home we're not paying you! ^.^ " * Us paying - Networks have down time. Get over it.
  15. Unscheduled Maintenance [COMPLETED]

    Because the explanation as to what broke is probably too technical for most people to even understand.