Dora Gustafson

With danger to confuse the issue I like to point out that using Username over Userkey should take less room in most cases Converted to a string the Username takes max 63 chars but much less in most cases, the Userkey takes 32 characters, when dashes are removed, always The Username is unique for all agents in SL like the Userkey The Username is not as convenient as the Userkey if you have to address agents not in the same region The Username is just as suited as the key to identify agents in the same region Hashed keys has been discussed much Hashed keys can not be used to recreate neither the full key nor the Username It is hard to say how many unique Usernames can be stored in world in one script because of the dynamic size My guess is twice the number of unique Userkeys, say 1400 :smileysurprised::smileyvery-happy:

Use a newbie, an alt with no money and you are safe from being a victim for this ruthless trick Doing this also makes it easy to keep a lot of garbage out of you main alt's inventory :smileysurprised::smileyvery-happy:

It is a matter of view Any photographer can tell you that And you can see for yourself just by having a friend to help you Stand 2 meters from you friend and look him in the eyes and you can see his ears Look with one eye 0.25 meters from his nose and you can't No perspective mapping on a flat surface makes a distortion, only the wrong viewing distance does :smileysurprised::smileyvery-happy:

What you see is what you get when you put a small focal length camera lens up someones nose In SL increase the focal length, press Ctrl+0 a few times and step back a few steps :smileysurprised::smileyvery-happy: Spinell wrote: Oohh, I see. Yes, when I change views with number 5, it does look very strange, more similar to how it looks in SL. Now, can you explain to me why this happens and how I can have the mesh look the same in perspective as it does in ortho? It is all a matter of viewing distance. Ortho is what you get when viewing from infinity and zoom in to make the object fill the view

You can't set 'Buy' unless you set it for sale Could that be it? :smileysurprised::smileyvery-happy:

like:) Particularly the module's small size and simple interface that makes it useful in a lot of contexts :smileysurprised::smileyvery-happy:

It may be something accidentally attached to your hud Examine what is attached, eventually detach it all :smileysurprised::smileyvery-happy:

LepreKhaun wrote: Unsure what your point is. It doesn't matter if the same number is used each time for the same avatar. If the listen handler is being closed properly each time it's used (which it is in the script I gave), chance of collision is 0 for that avatar. Your assumption is not met The handler is not closed until you have a listen event on the channel (or a time out) One person can open several handlers before that happens More scripts using same communications channel pose a risk for cross talk :smileysurprised::smileyvery-happy:

LepreKhaun wrote: Dora Gustafson wrote: I am talking about two ways to compute a suited communications channel number (1) 0x80000000 | (integer)("0x"+(string)toucherKey)(2) (integer)llFrand( 8388608.0 ) | 0x80000000 In the example at hand (1) expose a risk immensely reduced by (2) Try to figure out why :smileysurprised::smileyvery-happy: In (1) there is a hexadecimal number of length 8 being used. When one reduces a number pool by a factor of 32 (which is what you're doing here) the risk increases by a factor of 32, not the other way around. Wrong: (1) returns the same number for the same key and for all keys having 8 identical first digits in it The probability that the same toucher generates the same number in any number of tries is 1 (2) returns a random number each time it is called The probability that the same toucher generates the same number two times in a row is 1/8388608 :smileysurprised::smileyvery-happy:

SL Viewers never had de-render, you can stop searching :smileysurprised::smileyvery-happy:

Are you saying it is no option? One can hope to be happily surprised :smileysurprised::smileyvery-happy:

Thank you to both, I didn't realize that the JIRA has this option :smileysurprised::smileyvery-happy:

Is this possible at all? All I can think of are these We have or had in-world office hours but I don't know where and whenThe buck tracker is for bugs and not wishes and what I have in mind is not really a bug although it is a wish for something to prevent a run time error situationI guess there is no need to elaborate my wishes in the forum as it will not be noticed by any LindenI don't think any of them will work Where do I turn to? Any suggestions are appreciated :smileysurprised::):smileyvery-happy:

I am talking about two ways to compute a suited communications channel number (1) 0x80000000 | (integer)("0x"+(string)toucherKey)(2) (integer)llFrand( 8388608.0 ) | 0x80000000 In the example at hand (1) expose a risk immensely reduced by (2) Try to figure out why :smileysurprised::smileyvery-happy:

You are partly right but It is not closed until the menu is actually used, so it is possible for one person to open more menus using the same channel at the same time In everyday use it probably is not a big problem :smileysurprised::smileyvery-happy:

I like:) We have a general problem with skins Up til now a skin is nothing but a diffuse UV map and the highlights and shades are mostly those painted on the skin Painted highlights and shades do not change when light sources change In this case the light I see falling on the models face is not coming from the sun or the sky I am not blaming you, nobody can do it much better given only the diffuse skin UV texture The day glossiness and normals come to skins it will be another story :smileysurprised::smileyvery-happy:

When I come to think of it, a random channel would be better: dlgChannel = (integer)llFrand( 8388608.0 ) | 0x80000000; Because by the other approach the number is always the same for the same person clicking So if one person clicks more prims with the script you end up in the same situation as with a constant number :smileysurprised::smileyvery-happy:

If you take a close look at the script mr. Khaun has been kind enough to post, you will see how you assign a channel number to 'dlgChannel' in a proper way: dlgChannel = 0x80000000 | (integer)("0x"+(string)toucherKey); and not the way it is in the copy you found: integer dlgChannel = -468; drewbrown wrote: i've never seen this before so does this mean i have to change that value on each one i rezz now? There is no need for that, the script can do it for you the way it is done by Mr. Khaun :smileysurprised::smileyvery-happy:

You may be right about that but what you suggest is far more complicated than it need to be I suggest that you assign a big negative random number to dlgChannel in order to give every instance a unique channel number This is a very common way to assign "unique" communication channels to a script Tell me, your pads are not linked together?? If they are we may be looking at something different :smileysurprised::smileyvery-happy:

When all instances listen on the same channel (dlgChannel) they will all act on what you choose in one dialog I don't think you are having dialog boxes from all of them :smileysurprised::smileyvery-happy:

When you edit you see a "C" tool icon called:"Insert Code" Use that and you can publish formatted code :smileysurprised::smileyvery-happy:

Wandering Soulstar wrote: hmmm .. when you say collisions could occur ... I am trying to keep the data transfer among prims to a minimum and was hoping that a prim with this in it would have a unique channel. I could easily have 100's of prims with this code running in them. This is for a building tool and so I want to be sure that a prim other than the one that calls the HUD does not hear a response. so ... any suggestions for how to get a unique channel id? In that case you can use the same channel number for all when you call with llRegionSayTo() (You know the prim id the moment you get a request from it) :smileysurprised::smileyvery-happy:

Wandering Soulstar wrote: am I correct in assuming that if I were to substitute llHetKey() for llGetOwner(), I'd get a channel unquie to the prim the script is running in, always? You are right that the channel number will be based on the prim key Take notice that the prim key isn't very stable, it is new each time a new instance of the prim is rezzed Wandering Soulstar wrote: I have the followng snippet of code that I saw one day that gets me a unique chat channel: CHAN = 0x80000000 | (integer)("0x"+(string)llGetOwner()); The generated number is not unique, it is one in 2147483648 and anybody is allowed to use anyone of these channel numbers at any time The integer generated from the string uses no more than the first 8 digits from the key Two different keys that share the first 8 digits will generate the same channel number Otherwise it is not a bad way to obtain an almost unique channel number :smileysurprised::smileyvery-happy:

avatar in llLoadURL( key avatar, string message, string url); must be a key You can typecast string type to key type like this: string s = "01234567-89ab-cdef-0123-456789abcdef";key avatar = (key)s; The url in llLoadURL( key avatar, string message, string url); must be a string :smileysurprised::smileyvery-happy:

Well done and good luck I am so excited to see how far this project has advanced tomorrow :smileysurprised::smileyvery-happy: