Problems after the last SL update

Working with my scripts I've discovered that llXorBase64Strings is actually still buggy. When the length of s2 is less than the length of s1 then the result appears to be random. In 1000 permutations, 200-400 unique results are created when s1 is 4 characters in length and s2 is 2 characters in length. I see no readily visible pattern but then I haven't looked that hard.

If the behavior of llXor64BaseStrings could be stabilized then I might be able to adapt to the new implementation. This is because some of my scripts using this function are in my customer's copies of products they have purchased from me and I cannot modify them.

I agree that any radically new implementation should be under a new name. To suddenly change the output of a function like this knowing so many users depend on the old behavior seems really irresponsible to me. If there are flaws that can be fatal to the system, fine, make exceptions in the code for them but don't change the output. We need stability.

- Flyte

Phoenix this is not good at least for me and many of my customers. I develop a the THiNC Printing Press and THiNC Book. Basically the press allows you to make a copy of a the thinc book by copying texture keys encrypted pasted into notecards using XOR which is placed in a publication that reads the notecard & displays the textures as books in SL. I have sold hundreds of these Thinc Printing Presses which are capable of producing unlimited quantities of books. By not fixing the XOR output you will potentially be breaking thousands of books out there that other people give out or sell to rely on income. Please reconsider the problems that are occuring.

Hi everyone,

I'm not a scripter, so I don't understand much of the technical discussion above. I sell hair, so I work with prims and textures but pretty much avoid doing very much to script.

I do use JEVN vendors though, because they are basically user-friendly for a person with my level of skills. Since the 1.9 update, my vendors won't update properly to the servers, and if they do, in some cases, they are not giving out product as they should. Whatever the problem is, it needs to be addressed soon, and in a way that those of us who aren't scripters can adapt before it disrupts too much of our income. Whatever was done on 3/30 has not resolved the problem, and as some have said above, the behavior may be different but things are still not working properly. (ie. JEVN servers not finding vendors, not updating properly, not distributing product when it should, etc.).

Thanks much for your attention.

There are currently no plans to change the new implementation. This is for a few reasons:

* The new version is easier to integrate with external interfaces, which will matter a lot as the world grows. The old version was only tested at LL to work when the process was completely in-world. This is the first release which has tested with external libraries, which is how the bug was originally revealed.
* The new version actually conforms to the documentation.
* The new version addresses crash bugs.

We have, will be again, occasionally be forced to change output of the viewer, servers, emails, and script functions. The larger problem of handling simultaneous integration of the world with updated output will be addressed in a forthcoming release.

As for this,



I have run literally 1000's of tests on the new base 64 functions, and I know that there are permutations I have not yet tried, but most of the xor tests are of the form where s1 is longer than s2, and I just tried some tests with lengths 4, 2. In all of those tests, the original string comes back. For a trivially easy example to copy and try yourself, look at the lsl wiki entry.

Can you provide an lsl script which you believe generates incorrect output?

I thought the publicity and press releases touted 2nd life as a world created by users for the users.

No where did I see a world created for users by the users and ignored by the suppliers ?

Has Linden Lab never heard of backward compatibility or introducing major rewrites in the quise of new functions that can be phased in over time allowing those users who actually create content time to adjust to the new functions and phase out existing get arounds?

It must go without saying that if the original function was broken , but was still being used then people had found a way around the problem and were dealing with it - to rewrite the function to perform "properly" would therefore and obviously break all of the fixes that users had come up with.

Sorry if I sound harsh, but this sort of reckless rewriting without informing anyone who actually uses the functions is absurd and is just going to force people to see a problem and instead of coming up with ingenious ways to get around it are going to say "nopes - not touching that - no point - in 3 months my fix will be useless".

I think Adriana has very valid points. This could have been implemented in a much better way. At least with the publications created with my THiNC Printing Press anything published before March 29th update is broken.

I know there are literally 1000's of these publications in world. I am getting a ton of IMs because of this "improvement" about broken publications and customers losing business. Though the blame should be entirely on Linden Labs, it is definitely not helping my name or any my customers selling these publications.

I have been bit twice just with this product alone about sudden "improvements" in game. The llGiveInventory function was crippled some months ago and took a giant scripters uproar to change it back. If you want scripters to continue to be productive PLEASE keep them in mind and the "improvements" you implement. For every time this has happen I've always questioned myself that: "Is this really all worth it?". I believe Linden Lab didn't not think this out before implementing this and at very least expect an apology to my customers.

I've asked the development team to look into another solution. I'll keep you posted here.

I have about 100 THiNC books in circulation that are broken because of this.

I'm very sorry that the Base64Xor fix broke content by changing the results of the XOR. What I have done:
1) Restored llXorBase64Strings to the original, pre-1.9 functionality
2) Created a new function, llXorBase64StringsCorrect, that implements the post-1.9 functionality

This should go into tomorrow's release. Testing right now.

I believe this is obvious but anything that relies on encryption using llXorBase64Strings data since Wed March 29th will not work, correct? I know I can't have my cake and eat it too on this one.

That's correct. The thought process was that far more existing content relies on the old behavior, so we're restoring that as quickly as possible.

Hi!

Toneless, is it okay if I hijack your account in our testing grid? I need the name of an object you have in your inventory (from about 2 weeks ago) so I can test a real-world (erm... real-inworld?) object with the new changes.

Can you provide an lsl script which you believe generates incorrect output?

I already dropped it on your profile on 4/1/2006 and sent you an IM. Yeah, April 1st. 3 days ago.

- Flyte

We're sorry about the delay, Flyte. Our development team is not in over the weekends. We escalated it yesterday to "must-fix" status and it was fixed for tomorrow's rolling update.

The behavior of llXorBase64Strings matches that of pre 1.9.0.18 now. Cory also added a new function, llXorBase64StringsCorrect, which behaves the "correct" way (ie, Phoenix's fix).

Please let me know if this new version doesn't work for you after the rolling update is complete.