LepreKhaun

irihapeti wrote: look at the pattern. is 7 * 1/32768 and 2 * 1/256 I don't see it. default{ touch_end(integer num) { integer i; for (i = 28; i >= 0; i -= 4) { llOwnerSay((string)i); } }} Outputs: [06:18] Object: 28 [06:18] Object: 24 [06:18] Object: 20 [06:18] Object: 16 [06:18] Object: 12 [06:18] Object: 8 [06:18] Object: 4 [06:18] Object: 0 which is 8 iterations, not 7. And how you came to arrive at two 1/256's is beyond me because there is only one (which happens when the variable b is finally processed). What am I missing here?

irihapeti wrote: LepreKhaun wrote: And, on reflection, I see it was completely unneeded since the odds of ever matching anything NOT on a key boundary is vanishly small (it works out to be (number_of_keys_added - 2)*(number_of_keys_added - 1)/2*8 * 1.329228e-36 * 1/256 = approximately 0.000,000,000,000,000,000,000,008,748 - figuring 3,300 eight 15 bit possibilities with a ninth of 8 bits, all having to match) and one just needs llSubStringIndex(). I've changed my original code to reflect this much better solution since the chance of a false positive is so incredibly small the complication I had originally added is unnecessary. [Edited to more correctly show that the first two additions to the data string will, of course, never result in a false match and to cite my source as to how that extremely small figure is to be obtained. you might want to check your arithmetic 2 encoded keys: ABCDEFGHa XJKYMNOPb compare a 3rd key QRSTUVWXc where lowercase in the set [0..255] and uppercase in the set [0..32767] the potential cross-boundary collisions are: BCDEFGHax CDEFGHaXj DEFGHaXJk EFGHaXJKy FGHaXJKYm GHaXJKYMn HaXJKYMNo aXJKYMNOp + also need to factor in that the set of all keys is an arrangement using 2bits by example: k = [00,01] c = [0,0] compare [10]. 0 collision k = [00,01,10] c = [0,0][1,1] compare [11]. 1 collision --- k = [00,01] c = [0,0] compare [11]. 0 collision k = [00,01,11] c = [0,0][1,1] compare [10]. 0 collision --- k = [00,10] c = [0,1] compare [01] 1 collision k = [00,10,01] c = [0,1][0,0] compare [11] 0 collision --- k = [00,10] c = [0,1] compare [11]. 0 collision k = [00,10,11] c = [0,1][0,1] compare [01]. 1 collision. as the 2nd collision will never happen etc Well, you started off right. First possible mismatch is when the 3rd key is added and, yes, there are only 8 possible places for it to mismatch. But you skipped figuring out what is the possibility of each of those mismatches at that point. See, each of those 8 possible mismatches must each exactly match 9 characters. The first character has 2^15 possible states, so its chance of mismatching is 1 out of 32,768 or 0.000030517578125. The chance of the first character AND THEN the second character mismatching is 1/32768 * 1/32768 (since the first and second characters are independent of each, as per my cited source for how this math works). The chance of the 3rd character then mismatching after the first two is given as 1/32768 * 1/32768 * 1/32768 and so on until the final character, which has 2^8 states. So, the possibility of any 1 of those mismatches is: 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/32768 * 1/256 ~ 1.329228e-36 * 1/256 And, since we have 8 possible mismatches when we add the third key, its possible mismatch chance is: 8 * 1.329228e-36 * 1/256 Now, when we add the 4th key it has 16 places to mismatch, the fifth key has 24, the sixth key 32 etc (since if(character_place%9==0) we actually have a good match). And, yes, we do have to "factor in that the set of all keys is an arrangement", let me show you how my original formula does exactly that. Since the keys are added into the arrangement one at a time, we have to add the previous chances of mismatches as we go. In other words, though the 4th key has 16 possible mismatches, we can't disregard the 8 possibilities the third had. And when the fifth key is added, the running total is 8 + 16 + 24; 6th is 8 + 16 + 24 + 32; and so on to the 3,300th key added, which would be 8 + 16 + 24 + 32 + 40 + 48 + ... + 26,384; where "..." is a fairly long string of numbers, the last if which is (3,300 - 3) * 8. That final string of numbers can be simplified using a high school formula. First we factor out the 8, giving us 8 * (1 + 2 + 3 + 4 + ... + 3,298) and we see we're just doing the sum of consecutive integers (N(N+1)/2) so we simply plug in 3300 -2 for N, multiply by factor of 8 and then again by the chance of each mismatch and we have: (3300 - 2)*(3300 - 1)/2 * 8 * 1.329228e-36 * 1/256 or approximately 0.000,000,000,000,000,000,000,008,748 Hope that clears it up for you.

irihapeti wrote: LepreKhaun wrote: Good luck with all that... ty always a pleasure...

Many times while programming a simple and elegant solution can be had by redefining the problem. Instead of trying to communicate just with the closest object, I saw you were actually just wanting the HUD to chat with one object at a time. This is what you need in each object, along with whatever HUD interaction code in the listen() you might have. Note the use of the global listen_handle to capture the listener so you can close it in the timer(): integer chan = -12345; // communication channel to chat with HUDinteger listen_handle; // holder of the open channel, used to close it when donedefault{ touch_end(integer num) { if(llDetectedKey(0) == llGetOwner()) // if the owner touched it, then { listen_handle = llListen(chan, "", "", ""); // open a listener and store its handle llSetTimerEvent(60.0); // keep the listener alive for one minute } } listen( integer channel, string name, key id, string message ) { llSetTimerEvent(60.0); // keep the listener alive by resetting the timer // ... other code to interact with HUD here ... } timer() { // we haven't heard anything so, llListenRemove(listen_handle); // stop listening and llSetTimerEvent(0.0); // clear the timer }} You could also toggle the listener within the touch event, this snippet (and an understanding of the functions being used) using the timer should get you started in that direction as well.

You could have the listener default to off in the object and only turn on for (say) 60 seconds when touched by it's owner. With just one listener ever active when the HUD started chatting, you'd never have a problem.

And, of course, if you're wanting to speak only to a specific object, you can look into llRegionSayTo to see if that might better work for you,.

irihapeti wrote: jejejejje (: can still remember that convo + when you going to start the ethics debate in GD ?? Kant and Rawls and Locke and all that Thank you for clarifying your motivations.

Perrie Juran wrote: LepreKhaun wrote: Perrie Juran wrote: You should be honored. Where irihapeti is from, the Warriors only ate Opponents who fought valiantly. Where I live, those that pick fights with others are called bullies and can't expect the other to accept their rules. Where I live it's only those who pick on the weak. (I will confess to being very fond of her. I know of no one else who can go 'vroooom vrooooom' the way she does). Picking on someone stronger only makes them a foolish bully.

irihapeti wrote: ty. my copypasta skills sux (: ok. i leave you alone now. i take my oranges and play in another post ty for the debugs as well (: ps. i still do like your 700+ version. is ideal for a library script i think Leaving me alone sounds like an excellent idea. Unsure about "playing" in the forums though. Good luck with all that...

Perrie Juran wrote: You should be honored. Where irihapeti is from, the Warriors only ate Opponents who fought valiantly. Where I live, those that pick fights with others are called bullies and can't expect the other to accept their rules.

irihapeti wrote: you got 1 unnecessary addition in the end encoding as well as reintroduce collision + also if move the encoding to the harness side then more oranges. 3424 about You're correct, my approach is extremely flawed and anything based on it would be defective. Let's hope that no ignorant, clueless NOOBs* have made the mistake of relying on my work. * ETA: the phrase is used affectionately btw. We all love the beginners in our forums, it's just that they can be so exasperating until they realize how little they know.

irihapeti wrote: your understanding of the publishing rules for crediting sources is on the same level as your understanding of the ToS And don't you forget it.

irihapeti wrote: if anyone do use the above algo then replace this code: b = (b & 0xFF); e += llBase64ToString(llIntegerToBase64( 0xE0808000 | (((b + 0x800) << 12) & 0xF000000) | (((b + 0x0800) << 10) & 0x3F0000) | ((b << 8) & 0x3F00))); with this b = (b & 0xFF) | 0x8800; e += llBase64ToString(llIntegerToBase64( 0xE0808000 | ((b << 12) & 0xF000000) | ((b << 10) & 0x3F0000) | ((b << 8) & 0x3F00))); + means that the chance of cross-boundary collision is 0. 0 like in never dunno why LepreKhaun is now regressing his own design. It dont make any sense at all to do this. The coding cost of zero collision guaranteed is zero + the cost of non-zero isnt mathematical when it happens. The cost is a really unhappy customer a once in a zillion year storm ? once in a zillion zillion ? a zillion zillion zillion even. Only needs to happen once and unhappy. The coder who sold you the non-zero app in these situations will just go: gosh !!! wow !! really ??? like relly really !!??!!? woooo !!! how unlucky can you be ??? oh! well Well, if you want to go that way, fine. Your choice. But I think my design change suggestion is much better...

And here I am still trying to get this lazy cow to jump over the moon...

irihapeti wrote: see what happens when concentrate on the codes and not fuss so much about what people write in their texts is pretty good this mod you made. clean, fast and no fuss. I like it (: And, on reflection, I see it was completely unneeded since the odds of ever matching anything NOT on a key boundary is vanishly small (it works out to be (number_of_keys_added - 2)*(number_of_keys_added - 1)/2*8 * 1.329228e-36 * 1/256 = approximately 0.000,000,000,000,000,000,000,008,748 - figuring 3,300 eight 15 bit possibilities with a ninth of 8 bits, all having to match) and one just needs llSubStringIndex(). I've changed my original code to reflect this much better solution since the chance of a false positive is so incredibly small the complication I had originally added is unnecessary. [Edited to more correctly show that the first two additions to the data string will, of course, never result in a false match and to cite my source as to how that extremely small figure is to be obtained.

irihapeti wrote: LepreKhaun wrote: irihapeti wrote: LepreKhaun wrote: We've already shown that I "invented" nothing that you're making use of in your code. the last example in the test codes clearly shows how your invention is used Where you're relying on return r + enU((enB & 0xFF) + 0x8800); Which is YOUR OWN, original code. I had suggested an entirely different approach, for an entirely different program you'd written and my suggestion was merely what any intermediate programmer that was familiar with the subject and the literature of those that had worked within it would see as obvious. As Nexii Malthus did FIVE YEARS AGO. "My invention", sheesh! Next you'll be crediting me with inventing the Marketplace. I can't help you get your facts straight but that credit you give IS inappropriate, and I have no idea why you can't see it. that I changed the map location dont negate the design. No more than me changing the codes I get of Strife from << & to & << does. [ETA} and removing Becky's code from deU and changing it to a >> & mod to show symmetry seems to me that your main objection is to the test code examples. From which you seem to be extrapolating everything else. I made a mod to these to better show your design contribution for which you been properly credited When the other has spoken plainly, "extrapolating" means you have chosen not to hear what is being said. Too bad...

irihapeti wrote: LepreKhaun wrote: We've already shown that I "invented" nothing that you're making use of in your code. the last example in the test codes clearly shows how your invention is used Where you're relying on return r + enU((enB & 0xFF) + 0x8800); Which is YOUR OWN, original code. I had suggested an entirely different approach, for an entirely different program you'd written and my suggestion was merely what any intermediate programmer that was familiar with the subject and the literature of those that had worked within it would see as obvious. As Nexii Malthus did FIVE YEARS AGO. "My invention", sheesh! Next you'll be crediting me with inventing the Marketplace. I can't help you get your facts straight but that credit you give IS inappropriate, and I have no idea why you can't see it.

irihapeti wrote: if I am being stubborn (and I am actual not) is bc of the credit/citation publishing rules + in all the previous LSL literature and works on encoding LSL keys to UTF-16 compatible chars is no mention anywhere to map the end buffer character to a different BMP section to enable llSubStringIndex to find UTF-16 compatible encoded keys in a string table without cross-boundary conflict/collision. Maybe someone somewhere else maybe did already think of it, but is not in the literature. You put it into the public domain literature [ETA] in a convo we were having about it elsewhere. So you get cited in this LSL published works for this invention LepreKhaun you either invented this or you didnt. Is nothing in the prior literature or in what you have said to suggest that you didnt. So you get cited as the design inventor of the end buffer character mapping if you (or anyone reading) can show somebody else who prior publish a LSL work with this end coding design invention or prior made such a suggestion in any LSL forums then I will change the citation/credit to them as is proper. I am not going to change the citation without this. bc is a code submission to the LL LSL library. Is not just some codes I pasted to some random forum chat + aww gosh imma not that great !!! is not grounds for a non-citation in a published work. bc credit/citation publishing rules. Nobody gets to choose which of these rules applies to them just bc of how they feel if I did remove the citation then I would have to remove the script bc of the rules. I am not going to remove the script just bc awww! gosh so either come up with another person as the design inventor to get yourself off the credit/citation list or your name stays as it must by the rules We've already shown that I "invented" nothing that you're making use of in your code. You seem to have taken the view that you get to decide what is the appropriate use of someone else's name, even when they beg you to reconsider. Well, that's your problem and all I can do is politely ask one last time to please remove the inappropriate use of my name in your code.

You're working on key compression using what is known as a "Base 32768 Scheme". Basically this means splitting the 128 bits of a UUID key into 8 groups of 16 bits each and then encoding 9 UTF16 characters within the Unicode BMP (Basic Multilingual Plane) from them. This work apparently was started from a (somewhat off-topic) discussion in March of 2009 found here starting with "Stephen Psaltery 2009-03-27 13:40:06-04" that includes Kelly Linden's response (which compressed a key to 22 characters) through Doran Zemlja's first compression to 9 UTF16 characters. Doran's implementation was later tweaked by their coding partner, Adam Wozniak, and Haravikk Mistral then included that version in a collection of compression schemes they had assembled (many of which were their own). At the same time, Becky Pippen was also working on compression schemes that also (early on) used llUnescapeURL() to form UTC code points. Their work (here, here and primarily here) gives the best definition of the problem and (more importantly) gives the links to the reference material to properly understand both the problem as well as the offered solutions. What is of note is that these early solutions all relied on llUnescapeURL() to obtain the final result and it was Strife Onizuka who made the radical suggestion in Jan of 2010 to use llBase64ToString(llIntegerToBase64()), which was based upon their work of the Combined Library, dating from 2008. This approach was proven to be superior in both time and memory usage (a rare combination, it's usually one or the other). And that's about the sum of it- some great coders figured out this algorithm after untold hours of study and experimentations, published their results for the rest of us to use and Strife directed these early studies in the direction which you finally chose to modify. You might notice the lack of my name in this list and for good reason: I not only had not yet joined Second Life at that point, I'll always be several ranks below the coding ability of any of those mentioned. In other words, I'm not only not in the same league as these coders, I wasn't even playing when they took to the field and worked all this out. I have never knowingly nor willingly made any contribution towards any of your efforts that you could use my name without permission after the fact. Including my name with such as these coding greats is not flattering, nor is it appropriate. In fact, it is an embarrassment that I humbly beg you to forgo your stubborn, contrary arguments and simply remove the inappropriate credit from your code. PLEASE!

Yes, the SMOOTH transformation at first may not appear to be what you want until one realizes what happens when it is constrained to just one frame. The benefit of using this approach is not having to do the x-y offset calculations to show the frame you want, which can be a pain. Just keep in mind that frame numbering begins at 0.0, so your last frame in a 4x8 tile set is 31.0.

irihapeti wrote: changing the end character encoding doesnt mean that the pipeset is only now redundant. It was always redundant bc fixed length of 9 chars for (i == 0; i < lenset; i += 9) k = UTF2Key(llGetSubString(set, i, i + 8)); is the same code that would be used for both old and new end encodings + it maybe that you had a impression that the first iteration was returning variable length codes. It wasnt, they were always 9 char lengths for all + Pipe sets was a use case raised in the first convo. Why the user chose to do that may simply have been so that when copypasta they got a visual cue that they did have the number of keys intended. At some loss of storage space copypasta can have visual side effects depending on OS and fonts installed which can be visually confusing sometimes. Inserting an extra delimiter like | or ~ or , etc can be a aid to helping with this (at some loss of storage space) i just coded this into the test to show how pipe/delimited sets may be encoded and decoded for that particular use case raised in the convo + is also true for old and new that with pipesets then this works also for (i == 0; i < lenset; i += 10) k = UTF2Key(llGetSubString(set, i, i + 8)); + if you wish to rewrite the test codes or even mod the whole thing as a help to intending users/readers then you are free to do this And now you've argued full circle back to my original contention that I have made no significant contribution to your code. So, crediting me alongside those whose work you did build upon is inappropriate. The only required change to be made is removal of my name from it. Thank you.

See the last example before Notes at http://wiki.secondlife.com/wiki/LlSetTextureAnim for what you need.

irihapeti wrote: they examples of how it can be used the string table example shows how to read and write native sets the pipeset example shows how to format for that use case But the point is, the suggestion you're crediting me for makes a pipe delimited table completely unnecesary and doubly wasteful of memory ("doubly wasteful" in that 2 bytes are required for each pipe used and you are pulling out a list from the string table). Your third example of a "stringtable" is spot on but the first two, with the pipes, miss the mark because they imply that the pipes are somehow needed (which was the case in your original SLUniverse code). Why incorporate a suggestion if you're not going to use it?

If you were using my suggestion (encoding the 9th character differently than the previous 8) correctly, you'd not have need for the pipe-delimited string. As it is, it appears my suggestion added nothing to the original algorithm as you wrote it in SLUniverse. In other words, my suggestion has nothing to do with this code unless it is actually using a string for storage that doesn't depend on a pipe ("|") to separate the coded keys. Lacking that, it simply complicates the original algorithm unnecessarily. Your usage examples should reflect the change (ie 'string utfs = "蟿蟿蟿蟿蟿蟿蟿蟿裿|⨢䱄⨢䱄旝䎻旝䎻裰|旝䎻旝䎻⨢䱄⨢䱄蠏|⨢䱄⨢䱄⨢䱄⨢䱄蠀|旝䎻旝䎻旝䎻旝䎻裿|橀⪳䡈㯄僑䲀奙࢑裝|ᒄ䌪㚦蝮筻䳕奙࢑裰|菿左㼮翿㋳癝菿左袚|幉彦壠蘐掼➔劎沀蠳|ࠀࠀࠀࠀࠀࠀࠀࠀ蠀";' should read 'string utfs = "蟿蟿蟿蟿蟿蟿蟿蟿裿⨢䱄⨢䱄旝䎻旝䎻裰旝䎻旝䎻⨢䱄⨢䱄蠏⨢䱄⨢䱄⨢䱄⨢䱄蠀旝䎻旝䎻旝䎻旝䎻裿橀⪳䡈㯄僑䲀奙࢑裝ᒄ䌪㚦蝮筻䳕奙࢑裰菿左㼮翿㋳癝菿左袚幉彦壠蘐掼➔劎沀蠳ࠀࠀࠀࠀࠀࠀࠀࠀ蠀";') which eliminates breaking the string out into a list (just step through it 9 characters at a time).

Adana Ember wrote: The email didn't work, because I only get IM emails when I'm offline. What I wanted was a way to capture the text from an IM without having to copy and paste it from chat when i was actually in SL. I resolved this myself by finding the chat log, copying it to my server, then parsing out the data with .NET... "Look, Ma, no LSL needed!" ... this wont work for anybody but me, so it isn't marketable, but it's good to know. Thanks for your help. To obtain consistent behavior, I'd have just simply changed it to e-mailing me the info all the time. But if what you're doing works for you, great.