Keeping the Experience property on a script

[Cron Stardust]

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

[Lucia Nightfire]

Judging from the response to that feature request, you'll probably have to wait it out for experiences to be released grid-wide first before tpv's are allowed to pick up the same script compile procedure and UI as the project viewer. It is a little annoying as I deal with the same thing. I just  stay logged on the project viewer when I'm working on experience based script compiling then switch over to the tpv when I'm done. The priviledge to be able to work with experiences early is worth the gripes, especially dealing with the UI and lack of tpv goodies.

[Cron Stardust]

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.

[Lucia Nightfire]

Its not a hack, its simply an additional data point sent with the compile data that currently no other viewer sends. Server side checks still occur to see if the compiler has the right to attach the experience with the compile(expereince owner/contributor).

[Cron Stardust]

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.

[Dolphin Linden]

The real problem here is that there is no way for the sim to determine the scripter's intent if no experience is sent with a script when it is compiled. Do they mean remove the experience or do they want to keep it the same? Making one decision over the other will incovienience different people. It is also an intentional decision to fail to save a script if you try to use an experience you do not have rights to. With your suggestion, in this case the script could not be saved by someone not in the experience and there would be no way for them to fix it (i.e. they could not change or remove the experience even if they had modify rights on the script). 

I cannot speak to the schedules of the TPVs but the script signing is not terribly detailed (one call to get a list of ids and then you put one of those ids in the save request). 

 

[Cron Stardust]

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.