User talk:Omei Qunhua
An appeal:
When submitting sample scripts (or editing existing samples) PLEASE ensure you've tested the resulting script. There can be no excuse for blindly editing and not testing, and certainly no excuse for submitting scripts that won't even compile! Omei Qunhua 09:02, 9 December 2012 (PST)
- I wholeheartedly agree. I have been guilty of the sin but I agree. lslint and lsleditor are our friends. I noticed you mentioned that some edits have been breaking examples. If that happens, please make a note of it somewhere, we need to keep track of this so we can halt any negative trends. -- Strife (talk|contribs) 08:34, 14 December 2012 (PST)
- Well if you want to observe a negative trend, the following Wiki pages / examples were all corrupted by the same person :)
Wiki Page Date Corrupted Nature of Error Gun Script 18-Oct-12 Compile error llGetAgentList 8-Dec-12 Compile error llGetAgentList 9-Dec-12 Run-time bad results llDialog 24-Sept-12 Compile error 11SetLinkAlpha 30-Sept-12 Compile error llGetLinkInventoryPermMask 25-Nov-12 Compile error llResetOtherScript 24-Sept-12 Run-time error llGetSimStats 8-Dec-12 Compile error llRequestURL 24-Sep-12 Compile error llSetKeyframedMotion 24-Sep-12 Run-time error llEvade 4-Dec-12 Compile error llGetClosestNavPoint 4-Dec-12 Compile error llGetNotecardLine 23-Sept-12 Run-time bad results StringIsNum 7-Oct-12 Compile error Sensor 28-Oct-12 Compile error and Run time wrong results
(I've also corrected 4 other non-compilable or faulty example scripts by other editors, where the errors have existed since July 2012, March 2008, and Sept 2007)
Omei Qunhua 15:26, 18 December 2012 (PST)
- I have take a look at all his changeings in the example scripts and do not agree with the most, Everywhere he remove inside the sub-if's the clamps and resort the events. The most of the experienced scripters do not realy read it, but for beginners i think its bad when they not see where are the clamps necessary and where not. Daemonika Nightfire 10:19, 20 December 2012 (PST)
- I disagree with the way you say a script is "faulty" You do not clearly state your reasoning which is debatable because it's based on your own personal preference. --Ackley Bing 10:12, 14 February 2013 (PST)
- It's not a matter of "personal preference". If a script doesn't compile, or gives wrong results at run-time, then it's faulty. Omei Qunhua 03:22, 15 February 2013 (PST)
More size constructs
I've confirmed your results and made a few more tests of size optimization constructs.
x=-~x; 6 bytes (equivalent to ++x) x=~-x; 6 bytes (equivalent to --x) y=-~x; 6 bytes (equivalent to y=x+1) if(~x); 7 bytes (equivalent to if(x!=-1)) x*2; 8 bytes (equivalent to x<<1) x=-~-~x; 8 bytes (equivalent to x+=2) x=~-~-x; 8 bytes (equivalent to x-=2) y=x+1; 10 bytes x=x*2; 10 bytes (equivalent to x=x<<1) x*=2; 10 bytes if (!~x); 10 bytes (equivalent to if(x==-1)) if(x&0x80000000) 12 bytes (equivalent to if(x<0) for integers) if(x<0); 13 bytes x=x<<1; 14 bytes if(x!=-1); 17 bytes
For float x:
x=0; 9 bytes x=0.0; 12 bytes
For vector x:
x=<0, 0, 0>; 27 bytes x=<0.0, 0.0, 0.0>; 36 bytes x=ZERO_VECTOR; 36 bytes
for list x:
llGetListLength(x); 40 bytes x!=[]; 13 bytes (note: only list LENGTH is compared - actually subtracted. That returns 0 for empty list.) x==[]; 13 bytes if(x==[]); 17 bytes if(x!=[]); 17 bytes x!=[""]; 23 bytes (note: only list LENGTH is compared - actually subtracted. That returns -1 for empty list.) x==[""]; 23 bytes (true if x has 1 element) x!=[[]]; 23 bytes (list may not contain lists but this is allowed?!?!) x==[[]]; 23 bytes if(x==[""]); 27 bytes x!=[1]; 28 bytes (true if x has 1 element) if(x==["","",""]); 47 bytes if(x!=["","",""]); 47 bytes if(llGetListLengt(x)==1); 53 bytes if(llGetListLengt(x)!=1); 56 bytes if(x==["","","",""]); 57 bytes
Some of those may be worth being included in LSL Hacks, which I'd say is the place for code size optimization. Your list results are run time size related and thus worth being included as an update to LSL Script Memory. --Pedro Oval 09:35, 29 December 2012 (PST)
- Wow some of those are really interesting. I would venture the reason float zero is so expensive is how it's being encoded (there are several ways to encode floats in IL). They haven't optimized the zero case. I'm very surprised that x * 2 is less than x << 2. -- Strife (talk|contribs) 13:28, 29 December 2012 (PST)
- Well try these for size ... x+x; 4 bytes, x=x+x; 6 bytes, x=x^x; 6 bytes. Food for thought! Omei Qunhua 06:05, 30 December 2012 (PST)
- VERY interesting, thank you!!! --Pedro Oval 12:11, 30 December 2012 (PST)
- Well try these for size ... x+x; 4 bytes, x=x+x; 6 bytes, x=x^x; 6 bytes. Food for thought! Omei Qunhua 06:05, 30 December 2012 (PST)
Some more interesting results (all for LOCAL variables) [WITHDRAWN - SEE BELOW]
integer a; 49 bytes integer a=0; 53 bytes string a=""; 53? 55? bytes (I'm unsure if there's a preexisting instance of "" or not - my measuring method can't tell) string a; 53? 55? bytes string a="a"; 53 bytes plus 2*(num characters+1) per each different string (equal strings are referenced just once) float a=0; 54 bytes list a; 55 bytes list a=[]; 55 bytes float a; 57 bytes float a=0.0; 57 bytes key a=""; 60? 61? 62? bytes (same problem as string) key a="string"; 60? bytes + 2*(num_characters+1) per each different string
Braces don't seem to add anything: {integer a;} occupies the same size as integer a; and so on. Since the string case is complex, let me put an example. string a="aaa"; string b="aaa"; will use 53+53+2*(3+1)=114 bytes, because the string is the same in both cases and it's reused, but string a="aaa"; string b="bbb"; will use 53+53+2*(3+1)+2*(3+1)=122 bytes because the strings are different.
I'm getting inconsistent results with the keys. Something else seems to be going on. I get 61 bytes sometimes and 60 others. Wonder if there's a byte alignment problem. If so, that could make some of the previous measurements incorrect, even if they looked consistent. --Pedro Oval 13:40, 29 December 2012 (PST)
- Using the measurement method you suggested (or perhaps a variation), I have determined that an empty string uses 6 bytes always, while a 1 or 2 character string uses 10 bytes for the first appearance and 6 for the rest, and a 3 or 4 character string uses 14 bytes for the first appearance and 6 for the rest. Further testing suggests that string constants in code are allocated 4 bytes at a time.
- The previous results for local variable declarations can't be considered reliable. With this measurement method I get many variations for keys and strings: 132 bytes for the first appearance of
key x="", 56 for the second, 66 for the third... and also crazy for strings. I just withdraw the results. With integer I also got inconsistencies.: 43 bytes when measured with this method. What seems clear is that there's one implicit assumption wrong and I don't know which one or why. I guess a better understanding of CIL would help me interpret those results. Not sure if I'm willing to dive into that though. --Pedro Oval 14:44, 1 January 2013 (PST)
llGetSubString
I obviously did not review that edit! wtf were they thinking? Thank you. -- Strife (talk|contribs) 23:08, 3 January 2013 (PST)
UTF-8
UTF-8 characters can be more than 2 bytes, by the original standard, used by LSO, they can by 5 bytes. UTF-8 supported by Mono supports up to 4 bytes per character. -- Strife (talk|contribs) 20:31, 14 January 2013 (PST)
- Yes I know. That's why I quoted an example of a 2-byte UTF-8 when giving 512 as a UTF-8 limit. I didn't want to go into a full explanation on every page. Just wanted to give some clue that 1024 bytes doesn't necessarily give 1024 characters (and an opportunity to correct the 1023 to 1024). Maybe a link to a page on UTF-8 would be appropriate. But I think the current UTF-8 page needs overhauling. It starts by saying "SL uses UTF-8 for storing and transmitting strings" which I think is no longer always true (i.e. storage in Mono) then the UTF-8 page gets hijacked with complex code examples concerning Unicode which maybe appeal to 0.1% of Wiki's users. We need to sort the basics out on SO MANY Wiki pages, before leaping into hyperspace. And that's been the impetus behind my sudden burst of editing activity over 5 weeks. (IMHO, LOL) Omei Qunhua 00:26, 15 January 2013 (PST)
Wiki editing
I'm not sure why you feel the need to insult other editors with every other edit summary but I wish you all the best and merry christmas. Hopefully you can find some time to loosen up during the holidays. Best regards -- Kireji Haiku 14:29, 19 December 2013 (PST)
- I just stated a fact. If you find that insulting, well ....
- I don't understand why you are intent on driving the Wiki further and further from reality. You're just making it an academic non-practical source of your own personal preferences, at odds with what 99.9% of coders do and I'm sure will continue to do. Omei Qunhua 16:00, 21 December 2013 (PST)
I personally don't care either way with PUBLIC_CHANNEL and I didn't view the edit comments as insulting (the field encourages brevity, which can be mistaken as insult). I don't use it myself and I doubt many people do but many people don't use ~llSubStringIndex(), they use llSubStringIndex() != -1 or the new fangled llSubStringIndex() != ERR_GENERIC. Just because it's "ugly" doesn't make it wrong. So that we don't fight over these trivialities we should take the viewpoint that if they are already existing in articles we should not change them unless we are replacing the entire line. I'm ok with grammar and punctuation getting corrected but do keep in mind that grammar and punctuation are artificial rules created by man, and these rules can be redefined at anytime as well. What is grammatically incorrect today may be grammatically correct tomorrow, so grammatical correctness isn't the most important thing. There are however about 600 unloved articles in Needs Example (I'm amazed it's only 600 btw). So if you get bored and feel the desire to correct something minor, consider writing an example and spread a little joy to the unloved. -- Strife (talk|contribs) 15:15, 19 December 2013 (PST)
- I feel passionately that PUBLIC_CHANNEL should NOT be promoted in the Wiki - and this is NOT because that is my own personal preference, but it is the established preference of thousands of scripters as demonstrated in millions of scripts in-world and on script libraries. Kireji I am sure feels passionately that PUBLIC_CHANNEL should be promoted - but I venture to suggest that that IS due to his own individual and personal preference. I've noticed ERR_GENERIC creeping in, and that again is at odds with practically all actual scripts, although I'm less unhappy about it, in some situations. Sure I love mnemonics like CHANGED_REGION_START as most scripters would. As I say, the Wiki is in danger of becoming an academic tome, divorced from reality. :( Also, as pointed out before, we tend to have to explain that PUBLIC_CHANNEL means 0, whereas for example one would need to explain that 0x400 means CHANGED_REGION_START. That difference highlights the problem in a nutshell. Oh, and following on from your comments, Strife, the same logic dictates that where llSay(0, .... etc. exist in Wiki articles, they shouldn't be routinely changed to PUBLIC_CHANNEL. Omei Qunhua 16:04, 19 December 2013 (PST)
- Yes, the logic does, my condemnation is not aimed at any one party. But we have bigger problems. Dryness is one of those problems. The small number of editors is another. I'd say that Examples should be a top priority but I've never been able to make it one of mine. I don't have solutions to these problems. At some point we should have a meeting. My current projects include: parameter/subtype categories and haiku. -- Strife (talk|contribs) 21:04, 19 December 2013 (PST)
- "unless we are replacing the whole line" - and please, only replace that line if it's faulty, not just to propagate a personal style. Unfortunately that propagation has been going on for 15 months without anyone commenting until I started squirming a bit and seemed to become the target for criticism (the current condemnatory remarks appear in my own talk page). You say you have no preference, Strife, but your consistent use of llSay(0, in your own examples does suggest a preference. There are so many other unnecessary edits that have taken place over the same period, where there has been no corrective aspect. (float) FALSE is horrid, as are inserted lines of // { or // } ... or just adding the //. Awful. By all means, let's use our favoured styles on our own pages, or in examples that we originate ourselves. Enough. I'll go look at your list of the 600 unloved ... LOL. (But perhaps all those corrupted examples should be returned to their pristine states ^^). Omei Qunhua 09:19, 20 December 2013 (PST)
- Yeah the (float)FALSE thing... I have trouble seeing a good reason to use it. Oh I can understand that it might uses less bytecode but for the love of monkeys put it in the optimization article. That said, I am guilty of using (integer)"" in the past in code that was highly optimized (for LSO, yes I really did need every byte). Not really keen on whitespace changes either but I don't have a strong feeling. I wonder if we should considering protecting the diversity of programming styles in the articles. This way it gives the wiki a feel that real people actually wrote the examples and that they weren't extruded from some hideous creature's bum. It will be dangerous as it will be hard to define what is good diversity and what is bad content but it should be interesting. -- Strife (talk|contribs) 11:30, 20 December 2013 (PST)
- "What is grammatically incorrect today may be grammatically correct tomorrow" - LOL. So that's an excuse to write appallingly? No thanks! But I do think there could be a lot of merit in preserving the programming styles exhibited by example originators, as you suggest. Omei Qunhua 16:00, 21 December 2013 (PST)
- Fixed a bug in Constants, fewer articles should be showing up now in Needs Example. FixMe if you are wondering is where all the broken articles go. Most are constants in need of descriptions (others are constants in need of syntax examples like you would see on the like PRIM_NAME). -- Strife (talk|contribs) 20:28, 23 December 2013 (PST)
- P.S. Yeah it's a slippery slope and I don't buy it entirely either.
Further to suggesting that editors try to stick with the coding style used by an article originator, I was going to say that first of all the original writers should abide by an overall style guide agreed for the Wiki, such as [StyleGuide]. Unfortunately I see that that page has been 'hijacked' to promote one person's eccentric views. Proposed changes to the main style guide should FIRST be discussed in the corresponding discussion page. We can't have one person unilaterally declaring a style without discussion. So ... first we seriously need a 'committee' approach to defining an overall style guide. It's been said elsewhere that contributors are not going to want to rewrite their programs to comply with a Wiki style different to their usual practice. Personally I don't find that onerous, and I favour a more rigorous insistence on a unified style throughout. Omei Qunhua 04:04, 24 December 2013 (PST)
- I do not know how I overlooked this but It appears I forgot to codify any syntax guidelines into the LSL Portal Guidelines. For now I'll just shove something onto LSL_Style_Guide#LSL_Portal_Style. Thoughts? -- Strife (talk|contribs) 02:19, 25 December 2013 (PST)
I started tackling some of the "need examples" pages, but quickly felt that adding an example for each individual mnemonic constant was not necessary. Indeed having a separate page for each seems seriously OTT. Omei Qunhua 06:01, 27 December 2013 (PST)
- Do what you think is best, if it doesn't really need an example, skip it. I will not deny it was OCD to mandate that every constant have an article, nor that it might be a tiny bit excessive but I will argue with it being Over The Top.
- For some constants there is no benefit to having individual articles. If we were to deny all constant articles, we would end up with all function articles being at best llParticleSystem and at worst double what llSetPrimitiveParams (because llSetPrimitiveParams would become even worse). In the beginning I pushed for articles for constants because on the LSL Wiki it was hard to find information about constants. Not only was the information buried in function articles (which had no unifying layout so it could by literally be anywhere in the article), if the constant was used by multiple overlapping functions the information might be out of sync. It made maintaining the content very annoying. Personally I'd rather fill the wiki with stubs and let people flesh them out into articles if they want, than leave them digging and wishing for more. While we could come up with rules o how to decide which constants get articles and which don't, I don't think we gain anything by doing so (llParticleSystem is not one of my articles and I view it as grandfathered).
- Trying to shoe horn information about constants into articles has always been hard and it was especially hard on the LSL Wiki. You might want to add a single sentence of information but to do so might require refactoring a significant amount of the article. Here you can just post the sentence to the dedicated article and not have to worry so much about squeezing it in. -- Strife (talk|contribs) 22:08, 27 December 2013 (PST)
- Again, not sure why you feel the need to undo wiki contributions. Replacing channel 0 with PUBLIC_CHANNEL does not change the code style. If you strongly believe such edits shouldn't be done by others, same would go for your edits ... which go the other way around. The reason using constants is to enhance readability, making it easier for beginners. It's a lot easier to do a find and replace to get rid of PUBLIC_CHANNEL and to save byte-code than to look up what channel 0 is. Just my two cents. -- Kireji Haiku 06:54, 31 December 2013 (PST)
- Kireji, YOU are the one undoing Wiki contributions. I am merely agreeing that the original style (I use the word loosely) chosen by contributors should be preserved unless there is a very good reason (basically an error) that needs correction. Your use of PUBLIC_CHANNEL is nothing more than a personal fad, and the Wiki is not the place for such indulgences. Omei Qunhua 07:28, 31 December 2013 (PST)
- I understand the point that in certain usage cases where using values instead of constant would have an advantage like when there's an integer Bit_field. However constants were created for reasons. And if you'd know nothing about LSL (but you've experienced Second Life and how scripts work) and had
llSay(PUBLIC_CHANNEL, "Hello!");versusllSay(0, "Hello!");, I guess we can both agree that the first is easier to understand effect-wise. Now is there any non-personal arguement you'd want to bring up against this? Or can we move on and keep the use of PUBLIC_CHANNEL for the simpler example scripts? -- Kireji Haiku (talk|contribs) 09:53, 2 May 2014 (PDT)
- I understand the point that in certain usage cases where using values instead of constant would have an advantage like when there's an integer Bit_field. However constants were created for reasons. And if you'd know nothing about LSL (but you've experienced Second Life and how scripts work) and had
PUBLIC_CHANNEL vs Zero
Seeing as this topic hasn't settled down, it's time for the larger community to choose. I view their decision (even if it's Pie) as binding. http://www.sluniverse.com/php/vb/scripting/91061-wiki-public_channel-vs-zero.html -- Strife (talk|contribs) 00:15, 1 January 2014 (PST)
- It isn't just about PUBLIC_CHANNEL. It is about one individual tampering with hundreds of perfectly valid existing scripts, purely to impose exceptional ideas they originated, regardless of the demonstrated preferences of hundreds of contributors, many of whom are probably no longer here to defend themselves. I thought you and I had agreed, Strife, that edits should not unnecessarily change script examples unless to correct definite errors. So, if I vote in your survey, it will be for zero, but the survey misses the important point. The survey should be "Should one individual be allowed to edit script examples purely to impose personal preferences, and not in order to fix problems?" A Wiki is supposed to be a collaborative project. When one person rampages through it, insisting on their own views on every conceivable page, it ceases to be collaborative. Omei Qunhua 02:19, 1 January 2014 (PST)
llRezAtRoot
I think you missed the context, which is "offline building rights", you can't be offline and on the land at the same time. -- Strife (talk|contribs) 01:42, 4 January 2014 (PST)
- hummm. Well then, what is the correct wording for the note that effectively says "To have offline building rights, you need to allow everyone to build" ? And "Be" doesn't necessarily have to apply to an avatar, it can apply to the script doing the rezzing. No? Omei Qunhua 03:46, 4 January 2014 (PST)
- That does look better. But i still don't fully understand (excuse me for being a bit thick). Why do I need OFFLINE building rights to run a script with llRezAtRoot? Only if I'm actually offline surely. Not while I'm scripting and testing while online? Omei Qunhua 08:27, 5 January 2014 (PST)
- Oh dear :( Then what is the significance of calling it "offline"? I had started to think this related to the observed situation where a script of mine can't rezz a prim unless I'm online. If there's no difference between online and offline building rights, then just call it building rights, as it is usually known. No? Omei Qunhua 11:54, 5 January 2014 (PST)
Thank you. Yes, English is not my native language. I know about my ortographic problems, but I don't know how to activate a corrector or something similar. How do I make errors to be highlighted? Please tell me, that will be a great help.
--Rays of green light. Bright and proud to be a Circassian 10:44, 3 February 2014 (PST)
Memory Module
I'm afraid your characterization of sim and viewer events as 'rare' is inaccurate. It happens to thousands on a daily basis. Not to mention, the statement "such an event is likely to be more catastrophic than just the loss of variables would imply, it may not be worth trying guard against it." is extremely misleading, bad practice, and really amounts to nothing more than an opinion. Script state rollbacks are not catastrophic. They only result in a lack of data. Data which could be safeguarded against with the techniques described on the page. They certainly aren't the *only* way such safeguards can be implemented, but they are a valid way. If you think you know a better way, it would be more constructive to make a page about that, instead of vandalizing someone else's page.
I had many problems with your original statements, but I had enough respect for you that I did not change any of your wording. I only added on balance. I expect the same respect from you. But if you touch it again, Gloves off.
—The preceding unsigned comment was added on 2014-02-05 13:30:31 SLT by Darien Caldwell
- Please yourself. Care to sign your remarks here? And I certainly have problems with your wild assertions. You cannot possibly say categorically that "Script state rollbacks are not catastrophic." That's just ridiculous. "vandalizing someone else's page." A trifle over emotive? If you look at the page before I added the "tip" you'll see that seriously wrong impressions were given, i.e. that globals would always get reset on rezzing / logout-in. That needed addressing. "It happens to thousands on a daily basis. " That again sounds rather wild. Care to substantiate that? Fortunately never to me, nor to my clients that they have queried with me. Omei Qunhua 15:54, 5 February 2014 (PST)
re my script you corrected
I use scripts in that user space for teaching purposes. Thank you for posting the answers to what I expect the students to do to it in my user space, however I am taking that down so when I teach next week the page is waiting for them to fix it. Sorry if you misunderstood the use of teaching scripts in personal user space. Toady Nakamura 14:14, 11 March 2014 (PDT)
- Could you point me to what you mean by "that user space", Toady? I would be most most surprised if I've edited any example within personal user space, as I've always taken great care not to do that on the Wiki. Your recent edits don't seem to be involved in undoing any edit of mine. Thanks. Omei Qunhua 08:30, 12 March 2014 (PDT)
Checking that a Notecard exists in object inventory
What if the notecard isn't full perms, will llGetInventoryKey return a non-null value? -- Strife (talk|contribs) 20:19, 1 May 2014 (PDT)
- Hummm, no, a no-mod NC returns a null key. So what is the best way of guarding against a never-saved nc? Omei Qunhua 02:29, 2 May 2014 (PDT)
- An asset is not created until a notecard is saved. -- Kireji Haiku (talk|contribs) 09:53, 2 May 2014 (PDT)