Welder1488303095

@ Nova Convair I doubt llsensor is the way too. I will probably use "re-activate everything on first click" and require a second click to get a menu etc @ Dora Gustafson Its number 5, having too many scripts, I am trying to avoid. I guess you are right, I worry too much.

I am looking at general ways to reduce the impact my scripts have on the sim and so I am considering: 1. llSetMemoryLimit; does this have any benefit for the server? It seems that it only effects the memory llGetObjectDetails reports, effectively making your scripts only seem nicer. 2. Using a controller script to set all the object scripts to "not running" and then turning them on again when someone is llSensored. Assuming that the scripts turned off are well behaved and are mostly idle expecting a click here and "message linked" there, would that be better? Presumably the server can swap non running scripts out, so that would be a benefit if the memory is tight for the sim.

In the end I used character 31 string SAFE_SEP = ""; //chr(31) and after a while I ended up using it everywhere, even in trivial situations In SL it prints as very distinct black triangle , which is good for visual inspection The only drawback I can see is that, as above, it will not show at all in notepad, and show as a space in wordpad and in lsl editor. Notepad++ shows it as a "US" (Unit Separator) on black background so that's ok. In all cases, copy and pasting it to-and-fro preserves it (as one would reasonably expect) , so you can copy it from above even though you can't see it. Thank you all for your replies.

Pipe symbol is not safe at all for my purposes. I was thinking something more exotic like ascii char 31 which is nicely named in ascii tables "unit separator", and prints as a small triangle symbol. string SEPARATOR = llBase64ToString(llDeleteSubString(llIntegerToBase64(31),0,3)); Any reason I should NOT use it?

Any recommendations for which character to use as a separator for storing, transporting and retrieving lists with llDumpList2String etc . I will be storing user input so an out of way character is needed, but it does not have to be foolproof; i.e.. the script crashing if someone purposely feeds that character is acceptable A control character perhaps? Any best practices on this subject?