So yeah, I just fired off five emails to them.
What'd I say? Here's the text:
Ok.
From what I recall, the last two LSL changes since 1.5's release were later reversed in the patch that immediately followed them. Why? Mostly because the coders who use LSL complained about a lack of warning, about breaking scripts, and unforseen side effects of such changes.
[insert personalized paragraph here of why I'm writing to them in specific]
I'm also writing several other people in LL about this same topic.
LSL is not like most other things in SL. One change to LSL can have wide reaching consequences across the entire world, and effect every user you have. Making a change to LSL would be similar to, say, changing every sphere in the game into a dodecahedron. You CAN do it, and it might even be something that NEEDS to be done for some reason, but it changes large portions of the world of SL in ways that it's users have to deal with, both in having something that's "always" worked suddenly not any more, and in those users having to fix what was working "fine" in the first place.
In addition to it affecting your user base, the last two LSL changes have resulted in what is, in essence, money flushed down the toilet for LL. You see, I'm not sure if you know this or not, but coders cost money AND they can't do everything at once. Every second they spend working on project A is time they're not spending on project B. So when they recode LSL and impliment changes into it, that's time they could have been spending on something else. Now, I'm not saying that changes to LSL aren't appreciated. Bug fixes and the like are alright, but when you have a horde of torch wielding users carrying the broken remains of their scripts as rusty knives to cut off your fingers with and have to have to spend MORE (though I'm sure not much more) time reversing the changes, you've essentially wasted time and effort.
So what's my point? Any and all changes should follow a strict procedure. First, the change should be announced and the old way of doing things should be depreciated. Not -removed-. Depreciated. You've done it before. It should still work fine, but coders should have ample warning about it being changed in the future.
Second, the change should be introduced in a TEMPORARY function. This should occur at the same time as the annoucement. I honestly don't care if you call them ttParseString2List, or llTempFunction1. (This idea just came to me as I was writing this email, so I haven't thought it out yet and it may be flawed.) This will give coders time to test out patches and such, and make sure the new function works. Sort of like a beta test period. This will also allow coders to make suggestions so that other tweaks might be done to help make the function even more friendly.
Third, after a SIGNIFICANT amount of time (say, at LEAST two weeks, if not a month, since you never know who's taking a break from SL), the change is implimented, replacing the old function with the new one. No one has to learn a new function name every time a change is made to LSL this way. The new ttParseString2List replaces llParseString2List. Or whatever the function is. If the ttParseString2List temporary functions (or whatever they're called) can actually be changed to the real function name within the database and script itself, so that when you open it up to edit it, what was once the name of the temporary function is now the name of the real function, all the better. It'll allow coders to release patches using the temporary function and have them transition smoothly over to the new code once the permanent one is done, and it'll allow the name of the temporary function to be reused in the future if future changes are needed. The temporary function should cease to function entirely. If someone types in the temporary function's name after the real change has been made, it shouldn't be recognized as a valid function. However, if the temporary function can't be replaced with the real one, coders should be warned of this fact, so they can have patches READY using the real function name, but not released until the change is official.
I don't see this creating much more work for LL than the present way of doing things, and LSL changes will actually STICK with this method. All coders ask for is warnings, and time to get ready for the changes. That's all. We're not asking for you to put changes up to a vote, just a decent heads-up.
All that said... Can something PLEASE be done about that damn edit camera? For a good year+ now people have been asking for the camera to NOT be moved by Edit mode. It can't be THAT hard to comment out the camera-change lines of code, or put it in as an option. Please?
--Moleculor Satyr
From what I recall, the last two LSL changes since 1.5's release were later reversed in the patch that immediately followed them. Why? Mostly because the coders who use LSL complained about a lack of warning, about breaking scripts, and unforseen side effects of such changes.
[insert personalized paragraph here of why I'm writing to them in specific]
I'm also writing several other people in LL about this same topic.
LSL is not like most other things in SL. One change to LSL can have wide reaching consequences across the entire world, and effect every user you have. Making a change to LSL would be similar to, say, changing every sphere in the game into a dodecahedron. You CAN do it, and it might even be something that NEEDS to be done for some reason, but it changes large portions of the world of SL in ways that it's users have to deal with, both in having something that's "always" worked suddenly not any more, and in those users having to fix what was working "fine" in the first place.
In addition to it affecting your user base, the last two LSL changes have resulted in what is, in essence, money flushed down the toilet for LL. You see, I'm not sure if you know this or not, but coders cost money AND they can't do everything at once. Every second they spend working on project A is time they're not spending on project B. So when they recode LSL and impliment changes into it, that's time they could have been spending on something else. Now, I'm not saying that changes to LSL aren't appreciated. Bug fixes and the like are alright, but when you have a horde of torch wielding users carrying the broken remains of their scripts as rusty knives to cut off your fingers with and have to have to spend MORE (though I'm sure not much more) time reversing the changes, you've essentially wasted time and effort.
So what's my point? Any and all changes should follow a strict procedure. First, the change should be announced and the old way of doing things should be depreciated. Not -removed-. Depreciated. You've done it before. It should still work fine, but coders should have ample warning about it being changed in the future.
Second, the change should be introduced in a TEMPORARY function. This should occur at the same time as the annoucement. I honestly don't care if you call them ttParseString2List, or llTempFunction1. (This idea just came to me as I was writing this email, so I haven't thought it out yet and it may be flawed.) This will give coders time to test out patches and such, and make sure the new function works. Sort of like a beta test period. This will also allow coders to make suggestions so that other tweaks might be done to help make the function even more friendly.
Third, after a SIGNIFICANT amount of time (say, at LEAST two weeks, if not a month, since you never know who's taking a break from SL), the change is implimented, replacing the old function with the new one. No one has to learn a new function name every time a change is made to LSL this way. The new ttParseString2List replaces llParseString2List. Or whatever the function is. If the ttParseString2List temporary functions (or whatever they're called) can actually be changed to the real function name within the database and script itself, so that when you open it up to edit it, what was once the name of the temporary function is now the name of the real function, all the better. It'll allow coders to release patches using the temporary function and have them transition smoothly over to the new code once the permanent one is done, and it'll allow the name of the temporary function to be reused in the future if future changes are needed. The temporary function should cease to function entirely. If someone types in the temporary function's name after the real change has been made, it shouldn't be recognized as a valid function. However, if the temporary function can't be replaced with the real one, coders should be warned of this fact, so they can have patches READY using the real function name, but not released until the change is official.
I don't see this creating much more work for LL than the present way of doing things, and LSL changes will actually STICK with this method. All coders ask for is warnings, and time to get ready for the changes. That's all. We're not asking for you to put changes up to a vote, just a decent heads-up.
All that said... Can something PLEASE be done about that damn edit camera? For a good year+ now people have been asking for the camera to NOT be moved by Edit mode. It can't be THAT hard to comment out the camera-change lines of code, or put it in as an option. Please?
--Moleculor Satyr
Emails are already away, but go ahead and tell me what you think anywho. I know you want to.
