Logo

Innula Zenovka · 07-24-2012, 07:03 AM

What I usually do in circumstances where it's likely to be an issue is

key k = (key)llList2String(default_params,n);
if(k){
//do stuff
}

Is that terribly expensive?

Chalice Yao · 07-24-2012, 07:36 AM

Nah, not overly. I use that at times and haven't noticed anything. I might do some synthetic loop timing to see just how much overhead there might be from the additional casting.

Darien Caldwell · 07-24-2012, 01:05 PM

Quote:

Originally Posted by Innula Zenovka

What I usually do in circumstances where it's likely to be an issue is

key k = (key)llList2String(default_params,n);
if(k){
//do stuff
}

Is that terribly expensive?

you don't even need to explicitly set the cast, strings will assign to key variables just fine.

If you think about it, that's exactly what you're doing when you do

key k = "b1d453b2-5c70-421e-9621-98f26fe4713e";

Assigning a string to a key. Keys and strings are *nearly* interchangeable, except in the case of comparisons.

**NeoBokrug Elytis** · 07-24-2012, 01:22 PM

There was a little bit of conversation earlier as to how there should be an option to reset a script for the end user.

As a guy who's made quite a few successful games, I think that's a terrible idea. Allowing anyone to reset a script would break a lot of content.

I however am not opposed to a scripted flag such as llAllowScriptReset(). That way it's up to the creator of the script whether or not the end user can reset it.

Penny Patton · 07-24-2012, 07:08 PM

Quote:

Originally Posted by NeoBokrug Elytis

There was a little bit of conversation earlier as to how there should be an option to reset a script for the end user.

As a guy who's made quite a few successful games, I think that's a terrible idea. Allowing anyone to reset a script would break a lot of content.

I however am not opposed to a scripted flag such as llAllowScriptReset(). That way it's up to the creator of the script whether or not the end user can reset it.

This actually brings up a very good point regarding a distinction that LL (and even many people here on SLU) tend to forget.

People often make demands, request changes, or bring up suggestions based on limited perceptions of how a certain goal can be achieved.

An SL user will make a suggestion that they think leads to an end goal, and a good company would recognize that it is the end goal, not the stated suggestion/demand that is the critically important part.

I know I agreed with the comment earlier about wanting the ability to reset scripts in no-mod content. The thing is, the ability to reset scripts wasn't the end goal that caused me to agree with the suggestion. The end goal is being able to fix no-mod scripted content when it breaks.

In fact, I'd argue this distinction between a suggestion/request is present in the majority of posts where someone is presenting an idea. It's certainly been a point of contention for a number of suggestions made in this very thread.

I suspect there'd be a lot fewer back and forth arguments if people, before disagreeing with a suggestion, asked themselves, "why was this suggestion made? What is the end goal they hope to achieve?"

**Void** · 07-24-2012, 09:35 PM

I think, though, that without knowing the end goal you really can't do much other than to agree with useful ideas, and point out the flaws in bad ones. if there's an end goal you can suggest alternatives, or even improvements.

Melissa Yeuxdoux · 07-24-2012, 09:45 PM

Quote:

Originally Posted by Marine Kelley

Another silly quirk is that in LSO (not in Mono), the length of the identifiers (variables and functions names) does count. The less characters you use to name a function, the more memory you spare. Because the bytecode stores the names as strings in clear.

I sincerely hope that's not the case. Have we learned nothing since the days of old tokenized MS BASIC?

Marine Kelley · 07-25-2012, 01:30 AM

Quote:

Originally Posted by Melissa Yeuxdoux

I sincerely hope that's not the case. Have we learned nothing since the days of old tokenized MS BASIC?

Well as Strife pointed out, although it was true back then, it is apparently not the case anymore, thankfully.

Chloe · 07-25-2012, 08:59 AM

Quote:

Originally Posted by Chalice Yao

list default_params=[(key)"blah",(key)"blah"];

If the params are intended to be keys, that should work. Altho now that you mention it, I don't remember testing casting inside lists like that.

I ran into difficulty casting strings to keys in LSO and asked about it on the slScripters list and someone even created a jira. Apparently it was well known (which is all I was asking) that in LSO you cannot cast strings to keys in that way whereas in MONO you can.

I'm pretty sure that in either LSO or MONO you *can* do llList2Key even though the element in the list is a string and it works out the way you want!

Marine Kelley · 07-25-2012, 09:17 AM

Quote:

Originally Posted by Chloe

I'm pretty sure that in either LSO or MONO you *can* do llList2Key even though the element in the list is a string and it works out the way you want!

In my experience I have been stumped a couple times by this issue. If you store a key as a string inside a list (for example after parsing a chat message) and you retrieve it with llList2Key(), it won't give you the key you want (maybe NULL_KEY instead, I don't remember), and it was in both LSO and Mono.

ETA : You CAN cast a random string to a key and back to a string just fine, regardless of its size. I do that all the time in my linked messages, that's the main way I use to pass information between my scripts. However I don't know how it looks while it is a key, but that's not my concern. All I know is that no information is lost, and also that casting a string that looks like a key, to a key, will give you a valid key. That's also something I do all the time, both in LSO and in Mono.

Marine Kelley · 07-25-2012, 09:42 AM

Quote:

Originally Posted by Penny Patton

I suspect there'd be a lot fewer back and forth arguments if people, before disagreeing with a suggestion, asked themselves, "why was this suggestion made? What is the end goal they hope to achieve?"

I couldn't agree more. But it so sounds awfully like the typical problem of every contractor :

- Client : "I want feature X."
- Contractor : "Oh I see, but then it means you want to achieve goal Y ?"
- Client : "Come to think of it, yes, exactly."
- Contractor : "Ok then we'll do feature Y."
- Client : ".. for the price of X."

And that's when things go well. Usually it is more like :

- Client : "I want feature X."
- Contractor : "Oh I see, but then it means you want to achieve goal Y ?"
- Client : "You're not listening."

Aribeth Zelin · 07-25-2012, 10:15 AM

I had someone interested in a custom project a little while back...and before I quoted the price, i had the darndest time trying to get what was actually wanted...

**Void** · 07-25-2012, 10:31 AM

Quote:

Originally Posted by Chloe

I ran into difficulty casting strings to keys in LSO and asked about it on the slScripters list and someone even created a jira. Apparently it was well known (which is all I was asking) that in LSO you cannot cast strings to keys in that way whereas in MONO you can.

I'm pretty sure that in either LSO or MONO you *can* do llList2Key even though the element in the list is a string and it works out the way you want!

I've found that the real problem there is searching a list for a key... for which there was (is?) a nasty bug.

it's almost saner to have a general policy of storing everything as strings and retrieving them that way then casting to key.... it's also a bit wasteful since you'll have extra casts all over the place.

Darien Caldwell · 07-25-2012, 02:43 PM

Quote:

Originally Posted by Void

I've found that the real problem there is searching a list for a key... for which there was (is?) a nasty bug.

it's almost saner to have a general policy of storing everything as strings and retrieving them that way then casting to key.... it's also a bit wasteful since you'll have extra casts all over the place.

I agree, but I have to wonder, just how much does a cast really cost in terms of script space? I've never seen any data on that.

Jack Abraham · 07-25-2012, 03:53 PM

Quote:

Originally Posted by Marine Kelley

I couldn't agree more. But it so sounds awfully like the typical problem of every contractor :

- Client : "I want feature X."
- Contractor : "Oh I see, but then it means you want to achieve goal Y ?"
- Client : "Come to think of it, yes, exactly."
- Contractor : "Ok then we'll do feature Y."
- Client : ".. for the price of X."

And that's when things go well. Usually it is more like :

- Client : "I want feature X."
- Contractor : "Oh I see, but then it means you want to achieve goal Y ?"
- Client : "You're not listening."

Or the Linden Lab version.

- Resident: "I want feature X."
- Lab: "Oh, I see. We're not going to do that."
(Two years later)
- Lab: "You said you wanted feature X, so we put a hedgehog in your pants. Aren't you happy?"

Aribeth Zelin · 07-25-2012, 04:13 PM

I want a hedgehog....just not in my pants.

Argent Stonecutter · 07-26-2012, 06:14 AM

Quote:

Originally Posted by Jack Abraham

Or the Linden Lab version.

- Resident: "I want feature X."
- Lab: "Oh, I see. We're not going to do that."
(Two years later)
- Lab: "You said you wanted feature X, so we put a hedgehog in your pants. Aren't you happy?"

Display Names

llTeleportAgent

Chloe · 07-26-2012, 03:17 PM

Quote:

Originally Posted by Void

I've found that the real problem there is searching a list for a key... for which there was (is?) a nasty bug.

it's almost saner to have a general policy of storing everything as strings and retrieving them that way then casting to key.... it's also a bit wasteful since you'll have extra casts all over the place.

Agreed, if I remember the sequence correctly, if you have

Code:

key k1 = "valid key";
key k2 = "valid key";
list l1 = [k1, k2];

and later do a search such as

Code:

llListFindList(l1, [llGetOwner()])

the search will fail in LSO even if llGetOwner returns a key that is either k1 or k2 but in MONO, the search would correctly return the index.

The safe response is, of course, to define k1 and k2 as strings and then cast the result of llGetOwner to string

**Void** · 07-26-2012, 03:20 PM

Quote:

Originally Posted by Darien Caldwell

I agree, but I have to wonder, just how much does a cast really cost in terms of script space? I've never seen any data on that.

in LSO its a 2byte op code, per instance, and I forget the speed difference but it was negligable... it's more an issue of code clarity than size or speed unless you do something stupid like define explicit vectors or rotations within a loop using integers. that's still ~33% increase in a numerical data size, generally less for string/key... honestly with they'd made keys store as numericals but

Alison Alena · 07-27-2012, 09:45 AM

Quote:

Originally Posted by Chalice Yao

Random protip on silly memory savings:

Don't use NULL_KEY. Silly LSL compiler handles each use of NULL_KEY as a seperate string of "00000...", each with its own memory allocation. Thanks LL.

Store "" manually in a single variable and use it instead. Or replace NULL_KEY everywhere with "".

This is only with true with LSO. Replacing NULL_KEY with "" does not save you anything when using Mono.

Darien Caldwell · 07-27-2012, 12:12 PM

Quote:

Originally Posted by Alison Alena

This is only with true with LSO. Replacing NULL_KEY with "" does not save you anything when using Mono.

The bigger savings comes from storing it in a variable and then re-using the variable. And that's Universal to LSO and Mono.

Innula Zenovka · 07-27-2012, 12:38 PM

Quote:

Originally Posted by Darien Caldwell

The bigger savings comes from storing it in a variable and then re-using the variable. And that's Universal to LSO and Mono.

I'm getting confused.

It's my normal practice, in both LSO and Mono, to avoid checking if a key is NULL_KEY if at all possible. That is, I will normally test

Code:

if (id){
   // do something
   }
else{
  // do something different
 }

rather than if (llAvatarOnSitTarget()!=NULL_KEY).

But in circumstances when I might otherwise use NULL_KEY, I use "" instead, so llListen(5,"","","") or llMessageLinked(LINK_SET,0,"","").

Are there circumstances in which I would do better to declare a global variable, key null = NULL_KEY, and use nul instead of "" ?

Chalice Yao · 07-27-2012, 12:48 PM

Quote:

Originally Posted by Alison Alena

This is only with true with LSO. Replacing NULL_KEY with "" does not save you anything when using Mono.

It's true that it is more apparent with LSO, but it still exists in MONO.

I just tested it with a script that I slapped a large pile of NULL_KEYs into. 55004 free with "", 54492 with NULL_KEY (512byte difference). Remember that Mono only allocates in 512byte steps, so granted, you won't notice the difference when measuring with only a few usages of NULL_KEY due to that, but under the hood it still has an overhead per NULL_KEY.

Under LSL you will notice an immediate difference even with a few instances, as LSL shows even small memory changes.

**Void** · 07-27-2012, 02:59 PM

Quote:

Originally Posted by Innula Zenovka

I'm getting confused.

It's my normal practice, in both LSO and Mono, to avoid checking if a key is NULL_KEY if at all possible. That is, I will normally test

Code:

if (id){
   // do something
   }
else{
  // do something different
 }

rather than if (llAvatarOnSitTarget()!=NULL_KEY).

But in circumstances when I might otherwise use NULL_KEY, I use "" instead, so llListen(5,"","","") or llMessageLinked(LINK_SET,0,"","").

Are there circumstances in which I would do better to declare a global variable, key null = NULL_KEY, and use nul instead of "" ?

that's all as it should be, there are a few instances where a function might return (key)NULL_KEY (because they defined the constant as a string ::shakes head:: ), or you might want to distinguish between a properly formated NULL_KEY, and either garbage or an empty string...

the real reason is that redefining it means you can use the friendly name in your code so that the intent is better understood. so your listen would still be effectively the same, but it's clear that you are using a key and that it's non-op one.

ETA:
never replace explicit integers or floats with constants... in lsl, the pointer for them is the same byte size as the variable itself. (ok it can make code more readable, but the literal cost is the byte size of the constant you've declared. vectors, rotations, and strings >6 characters are fine though.

Darien Caldwell · 07-27-2012, 07:57 PM

Quote:

Originally Posted by Innula Zenovka

I'm getting confused.

It's my normal practice, in both LSO and Mono, to avoid checking if a key is NULL_KEY if at all possible. That is, I will normally test

Code:

if (id){
   // do something
   }
else{
  // do something different
 }

rather than if (llAvatarOnSitTarget()!=NULL_KEY).

But in circumstances when I might otherwise use NULL_KEY, I use "" instead, so llListen(5,"","","") or llMessageLinked(LINK_SET,0,"","").

Are there circumstances in which I would do better to declare a global variable, key null = NULL_KEY, and use nul instead of "" ?

Void summed up most of the points, though I wouldn't say readability is the main reason. It's for memory savings. NULL_KEY takes up around 70 bytes every instance it's used.

It's not uncommon in a typical script (at least my typical scripts

) to need to compare to NULL_KEY 20 or 30 times, so using a variable defined once is much more efficient than putting NULL_KEY at every comparison. You can't compare NULL_KEY to "" as you rightly pointed out.

using "" for llListen() and such is perfectly fine.

It may just be a style thing, but I never use raw comparisons for anything but Integers. (where you did a check with id without comparing it to anything). I don't trust it will always eval true when you infer it should.

07-24-2012, 07:03 AM	#276 (permalink)
Innula Zenovka Nasty Brit Wants things Join Date: May 2009 Posts: 6,970 SL Join Date: 17 June 2007 Business: Something Spunky	What I usually do in circumstances where it's likely to be an issue is key k = (key)llList2String(default_params,n); if(k){ //do stuff } Is that terribly expensive? __________________

07-24-2012, 07:36 AM	#277 (permalink)
Chalice Yao The Purple HEYOO! Join Date: Dec 2007 Location: Somewhere purple, Germany Posts: 7,672 My Mood: SL Join Date: 20. January 2007 Client: NaCl	Nah, not overly. I use that at times and haven't noticed anything. I might do some synthetic loop timing to see just how much overhead there might be from the additional casting. __________________ "Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac?" - George Carlin Last edited by Chalice Yao; 07-24-2012 at 08:21 AM.

07-24-2012, 01:22 PM	#279 (permalink)
NeoBokrug Elytis Senior Member *SLU Supporter* post_count++; Join Date: Sep 2007 Location: Austin, TX Posts: 1,031 My Mood: SL Join Date: 11/01/2005 Business: The Wastelands Client: Official Newest	There was a little bit of conversation earlier as to how there should be an option to reset a script for the end user. As a guy who's made quite a few successful games, I think that's a terrible idea. Allowing anyone to reset a script would break a lot of content. I however am not opposed to a scripted flag such as llAllowScriptReset(). That way it's up to the creator of the script whether or not the end user can reset it. __________________ Tin Man Rant - Blog Alright, I've been thinking. When life gives you lemons, don't make lemonade - make life take the lemons back! Get mad! I don't want your damn lemons, what am I supposed to do with these? Demand to see life's manager. Make life rue the day it thought it could give Cave Johnson lemons. Do you know who I am? I'm the man who's gonna burn your house down! With the lemons. I'm going to to get my engineers to invent a combustible lemon that burns your house down! -- Cave Johnson

07-25-2012, 10:15 AM	#287 (permalink)
Aribeth Zelin Just call me Beth Singing along with old music Join Date: Mar 2011 Location: Out in the mists Posts: 5,733 My Mood: SL Join Date: Oct 4 2009 Business: Faerycat Designs Client: Firestorm	I had someone interested in a custom project a little while back...and before I quoted the price, i had the darndest time trying to get what was actually wanted... __________________ Faerycat Designs In World -Marketplace 1- Marketplace 2

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

07-25-2012, 04:13 PM	#291 (permalink)
Aribeth Zelin Just call me Beth Singing along with old music Join Date: Mar 2011 Location: Out in the mists Posts: 5,733 My Mood: SL Join Date: Oct 4 2009 Business: Faerycat Designs Client: Firestorm	I want a hedgehog....just not in my pants.

Logo

Site Navigation