Jump to content

Cron Stardust

Resident
  • Posts

    11
  • Joined

  • Last visited

Everything posted by Cron Stardust

  1. Correct - my solution was for all other cases than a rogue contributor - a rogue contributor can be solved by making sure you only add people you know you will be able to implicitly trust for the lifetime of the Experience. But that's not a technological solution, only an interpersonal one. A tech fix for a rogue contrib would require facilities for being able to blacklist Experience scripts created by a specific account. To prevent accidents and further abuse, the given account would have to have been removed from the Experience. However, the workaround for the rogue would be to have other, not as script savvy, members of the Experience copy & paste code into new scripts. So the tech fix still requires an interpersonal fix.
  2. A work-around for all cases other than a rogue contributor is to add a blacklist version check in the KV store: if the script finds its version number in the value of the blacklist it either shuts off, removes itself from inventory, deletes the object, or tries to update - whatever the application demands.
  3. That's about it AFAIK. However, you might run across issues with avvies of non-humanoid shape: these typically use animation just to keep the shape correct, and may mess with the origin. The Seawolf Ancient dragon comes to mind... Of course, having not tried to do this myself, I may be all wet and my fears be ungrounded!
  4. I would expect that, given the way it's set up: no Experience id = remove or keep same; with Experience id = either add, update, or keep same. Note the conflation. My suggestion is to make the experience operations (add, remove, keep) dependent on explicit operations, with a implicit removal for a special circumstance. The explicit operations would be: Add Experience to script, Remove Experience from script. These would be explicitly set via the client UI. When a script is uploaded without an Experience ID, it means simply to keep same - with the exception of if the uploader does not have permission to put scripts in an Experience: say they bought the script or object with full perms, the Experience association will be lost. This circumstance should display a warning to the user upon opening the script that saving the script will cause it to be removed from the Experience. So in short: Connect Experience ID with script: UI control. Remove Experience ID from script: UI control, lack of permissions at upload (checked serverside). Maintain current ID or lack: basic script upload. Note that this means that no Experience ID is expected to be sent with a script upload. Again, I don't know the feasability: if there's no ability to differentiate between an upload that is an update for an existing script and an upload that is a completely new script, then my entire concept would likely take too much of an overhaul of the code and potentially break some assumptions in the system.
  5. No solid answers, but as far as I understand it there should be a different Experience name, and consequenctly a different Experience Key, for each "experience" produced. This implies that selling an Experience that is then abused would only go against that specific key - unless there was a pattern of keys gettign abused that all are traceable back to the same account. Then that implies that the user of that account is unable to, or does not wish to, create Experiences that aren't abuse resistent. Which brings up the question as to whether LL wants to keep allowing that user to create such things. So from my perspective: 1. It depends. 2. No, different experiences should be different Experiences. (note the capitals ) 3. I don't have the understanding yet of that detail to attempt an answer.
  6. Correct. The reason I still consider it a hack is that the serverside should be able to keep that property on the script across recompiles. To me there's no reason the client should be re-attaching the experience data every upload. Yes, serverside checks would be in place. But that doesn't bypass what appears to me to be a design-by-fastest-implementation hack. Then again, there could be valid reasons for doing it this route. It just makes using the system annoying - and there's going to be lots more complaining once this goes live: I have no stats, but I'd say that most advanced scripters don't use LL's viewer unless they have to - and even then thye only use it for that have-to situation and then continue in their favorite TPV. And many of those TPVs take a while to process the large changsets that get dropped by LL. This results in a fairly long overlap period whith annoyed users. Not the first time, but should be preventable by making the server responsible for keeping that attribute assigned to the script unless explicitly removed by the user, or due to the user not having permissions to maintain scripts in that experience.
  7. Agreed. However, this seems to indicate that there's a hack in the code where the client is responsible for keeping the experience property applied to an updated script. That sounds like a problem to me, and a potential route for exploits: anything the client maintains is such a potential route. If the property was being managed serverside, as it should be, and only added/changed via explicit requests from the client, then we wouldn't have this issue: you could connect the script to the experience in a viewer that supports it (explicit add operation), relog into another client, and change script code without issues.
  8. Conversion in my case. But I have many things that could do with Exp enhancements - tip of the iceberg and all.
  9. As posted in BUG-6711 scripts don't keep their Experience property when edited by the same user on a viewer that does not support the Experience system - which is every other viewer available ATM. I use a handful of viewers, and specifically I use Firestorm exclusively for editing scripts, and having the code lose the information that it is connected with an Experience is frustrating. Any thoughts on a workaround or some way to be able to use power tools like "edit in an external window", a preprocessor, &c.?
  10. Is there a JIRA entry for this? As a OS developer myself, I might consider creating a patch to change to new defaults (should be trivial) but a JIRA for that specific feature would be needed first. :matte-motes-smile:
×
×
  • Create New...