Jump to content

Kyrah Abattoir

  • Content Count

  • Joined

  • Last visited

Community Reputation

865 Excellent

About Kyrah Abattoir

  • Rank
    Advanced Member

Recent Profile Visitors

818 profile views
  1. It's not just that it's just that voice + motion control caters to a completely different demographic: those who use VR as a direct extension of their real self. You basically have to be an "actor" to play a role in these conditions.
  2. Biggest issue of VR: typing. Voice and motion controllers also shifts the potential userbase completely away from those who wanted more immersion with the same "out of body" experience that we've always had.
  3. Those are not fees their are throttling measures. The real costs of running all this is expressed in the region and land fees.
  4. I'm mainly trying to avoid messing with other people's items if possible. I already use some animation checking code (which i really need to rewrite) but a real solution would be so much better.
  5. You've got to be *****ing kidding... REALLY? My theory was that it was related to ease-out on some animations preventing that animation from finishing in time, causing the system to freak out, killing all reunning animations. Why is there even a "kill all running anims" behavior to begin with anyway?
  6. This is an oldie but a goodie. I still can't understand how to prevent it reliably. We have all encountered it I'm sure. Your scripted attachment is playing some animation loop. You detach it. Your detach code executes just fine and stops the animation... All the animations currently affecting the avatar are stopped. Attachment animation scripts are supposed to be simple right? pretty much scripting 101? Something like: string anim = "someanimname"; integer has_perms; default { attach(key attached) { if(attached) { llRequestPermissions(id,PERMISSION_TRIGGER_ANIMATION); } else if(has_perms) { has_perms = FALSE; llStopAnimation(anim); } } run_time_permissions(integer perms) { if(perms & PERMISSION_TRIGGER_ANIMATION) { has_perms = TRUE; llStartAnimation(anim); } } } But no, it doesn't work (at least not with all animations). And when it does, it's not in 100% of the time. The docs state that animations will be purged anytime you detach an object and do not stop animations attached to it, but it will still happen regardless, depending of the animation. Also I only care about standard permission behaviors, so I'm ignoring the weird Firestorm permission options. So my questions to you fellow seasoned scripters are: How do you prevent this? How do you prevent this RELIABLY? How do you prevent this regardless of the animation? WARNING: If you think this is a simple noob problem, think again. I've either been completely stupid for my 15 years of LSL scripting, or there is a real issue with the SL animation system.
  7. If you only need the "impression" of a light and no change in light emission you can use a two step texture animation and consume no script time.
  8. Well I don't know if i'm a major creator, but I simply don't "lock things" down, almost always copy & mod objects unless there is a good reason to (gameplay?).
  9. It also limited the copyright issues of the grid too since content in SL could only be made in SL (excluding sound/tex/anims obviously)
  10. I'mho just put a hard limit and you get a helpful little progress bar that tells you how far from the limit you are. Done. If ARC hadn't been completely defanged...
  11. Pretty much. Anything that sits in a computer's ram is under the complete control of their owner.
  • Create New...