Re: Arcadia's Scripts
Posted: Wed Dec 30, 2020 5:59 pm
EDIT: Snoots completely removed this answer because of learning something new from John (see below), and coming to the realization that LsL structure is totally insane. ;D
Documentation, discussion and support for Kitely users
https://www.kitely.com/forums/
Of Course! I can pass you the ones that I have scripted directly but all of them unscripted can be found at:Snoots Dwagon wrote: ↑Wed Dec 30, 2020 5:59 pmIf there is time maybe we could work on this project together. My price: I get one to put at the Wellspring Tiny Playground. ;D
Sure thing Kosahri. You can just drop stuff in a box and IM them to me, along with a notecard if you like telling me what you need done and what you've succeeded at so far. We'll try to figure it out. : )Koshari Mahana wrote: Of Course! I can pass you the ones that I have scripted directly
Great, I'll box them up tomorrow for you.Snoots Dwagon wrote: ↑Thu Dec 31, 2020 4:10 amSure thing Kosahri. You can just drop stuff in a box and IM them to me, along with a notecard if you like telling me what you need done and what you've succeeded at so far. We'll try to figure it out. : )
This isn't quite true, Snoots - it's a lot simpler than that[1]. Consider this code:
Code: Select all
integer b = FALSE;
if (b = TRUE) llOwnerSay("huh?");
Code: Select all
integer x = 123;
if (x = 234) llOwnerSay((string)x);
Code: Select all
string PrimName() {
return llGetObjectName();
}
default {
state_entry() {
string name = PrimName();
if (name == "Object") llOwnerSay("This is " + name);
}
}
Code: Select all
string PrimName() {
return llGetObjectName();
}
default {
state_entry() {
string name = "";
if ((name = PrimName()) == "Object") llOwnerSay("This is " + name);
}
}
Code: Select all
x = y = z = GetValue(); // set x, y and z to output of GetValue()
Code: Select all
x = GetValue(); // set x to output of GetValue()
y = x;
z = x;
I couldn't agree more. I think all the terse code mania is a holdback from the days when coders were trying to work within a limit of 4k RAM. Such is no longer necessary. In current days it's often a result of coder ego and "look how leet I wrote this"... which can be chucked out the window as well.John wrote:As a personal aside, I'm not in favour of terseness for its own sake. Some programmers love to come up with code that will do in one line what would normally take six lines, but at the cost of easy readability. Many years of working in teams in real-world software companies knocked that habit out of me pretty quickly, and unless absolute efficiency is required (and the code is very well commented), it's much better to have things plainly laid out. So I use the above techniques quite sparingly in production code.
Absolutely! I only wrote that as a bare-bones snippet to demonstrate the behaviour of = in an if statement. Something like that should never be coded in an actual working script.is in my mind an ultimate example of really bad coding structure
Where is that stated? I've not seen that, but I could easily have missed it. This page seems pretty clear and correct.The fact that LsL documentation itself has stated that = within a decision structure is a boolean operator makes things that much worse.
if (b) is fine, or you could use if (b == TRUE]. No need to use bitwise operators such as & for something this simple.I suppose a more proper way to write the above would be: if ( b & TRUE) ? Or of course, just: if (b) ...
Really, LSL isn't particularly to blame for anything here. Sometimes the language makes me beat my head on a hard surface, but in this case its behaviour isn't all that different from other C-like languages. If Linden Lab messed up with LSL, we could come up with plenty of other things to complain about. In particular, it's a language that was designed to be usable by beginners, yet it uses C syntax (which I personally love, but is not for beginners), yet fails to provide so many things that an experienced programmer would expect to see. It's an unhappy alliance between ease of use and power that maybe would have been better achieved by splitting it into two separate languages, as Unity and other platforms have done.Poor language design.
It's also due to the pride that programmers take in doing the most they can with the least. It's like people who produce intricate carvings in the lead of a pencil, or create an image of Marilyn Monroe using only tiny seashells of various colours - we can appreciate the skill that goes into it for its own sake, but ultimately and practically, it serves no material purpose and was never intended to do so.I think all the terse code mania is a holdback from the days when coders were trying to work within a limit of 4k RAM
Ha, yes! The core script in RezMela (bear in mind this is a script which can be reduced in size and complexity no further by splitting without increasing size and complexity with an interface) has TEN completely different timer usages. So the timer duration has to be set at the LCD of all those usages, with integer counts for the frequency of further calls - and, of course, we want the timer to stop completely when not in use by any of them. I could write a lengthy article on timer event sharing alone - but in C# (upon which LSL is based), you just create a new dynamic event for each use.ONE timer event?
The way to get a predictable link order, is to select the parts one by one but not link anything until you've selected them all. If you do it that way, the first object you selected will have the highest link number, the second one you selected will have the second highest link number etc.Koshari Mahana wrote: ↑Wed Dec 30, 2020 12:49 amTess, lol I did have trouble with this. I naturally thought since there were 12 prims that if I linked it second to last (with the root prim being last) that it would turn out to be link 11. But that wasn't the way it turned out, sometimes it came out to be link 2 and sometimes it came out to be link 12. I ended up linking it 3rd to last which made it link 11. It took a lot of trial and error though, I'm lucky it was only 12 prims!
Well to be fair, I got into LsL just shortly after SL was set up. (My group was the very first to purchase a non-business private sim.) So a lot of information I read regarding SL was from early days before major parts of the WIKI were updated. Early Wiki contained numerous errors (as would be expected). Stating that = within an IF statement was a boolean operator could have been an early error that had long-standing repercussions. Or I could be mistaken and it was something I read repeatedly on the SL scripting forums. That was a while back. At that time I was still a Ruther dressed in pajamas. : )John wrote:"Where is that stated? I've not seen that, but I could easily have missed it."
Code: Select all
integer b;
default{
touch_start(integer a){
b = FALSE;
if (b = TRUE) { llOwnerSay("TRUE!"); }
b=TRUE;
if(b = FALSE) { llOwnerSay("FALSE!"); }
}
}