Curious Hazelnut

That sounds somewhat like a fun game to play. I see two ways to make it happen (and I think you hinted at them in your post). Have scripts in each of the collectable parts that will link the objects together when you have all of them, or Have a old-for-new delivery system, so the player puts all the collectable objects together, something verifies all the collected objects are there and trades the collected bits for the prize. Either way, it sounds like the collected objects need to be trans, no-copy, no-mod. I suspect option 2 is easier. It also seams like quite a challenging task to complete. I wish you luck.

There probably isn't really a "best" place. But there are lots of good choices, like... If any of you have a "home" in SL, use that. being informal and only 5, look for a quiet region and TP there. don't go anywhere, just start a multi-avatar IM session or voice session (depening on your preference) There are a number usually empty Linden built islands and places (especially in the old continent) that offer a nice view and a place to chat. There are a series of linden built regions starting with Bertrada and heading east that are usually pretty empty. If you need to rez/build. Go to a quiet sandbox. If you are all premium, the premium sandboxes are very quiet.

Orca Flotta wrote: What kind of community/RP do you have in mind? Happy mindless suburban families on zombie hunt I love it. Let's do it. ... Do you think anyone would notice if I dropped a zombie rezzer in a Linden Home region?

I know, but I keep hoping. Amethyst Jetaime wrote: Linden homes don't lend themselves to forming communities or roleplay simply because the owners are from all over the world and live in different time zones. Many people only use their Linden home to rez into, change clothes and open boxes etc. They don't hang out there much. And finally Linden homes appeal to premium members that pay annually and have extended absences in SL due to RL. They can be gone for a long time and their home is still theirs when they come back, These are some of the reasons that you are alone on the sim a lot of times and I am sure there are others. I am also pretty sure that all the Linden Home islands are like this too. When I look at them on the map I rarely see more than a few green dots on them, if there is anyone there at all.

Thanks 16, looks like I've got some reading to do. I know XOR alone is not crypto secure. That's more or less why I started this thread. To see if there were any creative solutions out there. 16 wrote: [...] on a 160bit cipher then i probably use a feistel network mixer with say 4 or more rounds. a feistel mixer algo output is provably indistinguishable from "random" after 4 rounds. here is a ref: http://en.wikipedia.org/wiki/Feistel_cipher or even easier bc is small and can easy fit in memory then a knuth (fisher-yates) shuffle http://en.wikipedia.org/wiki/Knuth_shuffle [...] this works bc XOR is a bijection like i say above. is not crypto-secure all by itself tho

Hello forum people, I have once again got myself a Linden Home. Most of the time when I pop over to my cute little house in Aetios, I'm the only avatar on the region. So, I was wondering if there are any attempts to make communities or role play within the Linden Home regions? If you've got a community going, or just thought you wanted to, please let me know how it's going and what your idea/community is about? Thanks.

You can also submit a support ticket to Linden Lab asking for the specific part of the abandoned land you want. You need to be very specific in your request and include grid coordinates (region and x,y,z) inside the property you want along with the size and dimentions of the half you would like. (4 points to make the square/rectangle you want). I've done this twice now. It took a day the first time and about a week the second time. I found it helpful to submit the ticket (get the ticket number) wait a day, then contact support and ask them about the status of the ticket.

16 wrote: Curious Hazelnut wrote: Base 64 encoding was created to convert binary data into printable characters (to get around transmission issues with some early protocols). In simple terms, it converts 3 bytes into 4 bytes but guarantees that those 4 bytes are all printable characters. So, if the size of your data is not divisble by 3, then there are 1 or 2 "extra" characters needed as filler. To note this, Base 64 encoding uses the equal sign (=) as a marker. You will see two equal signs at the end of the Base 64 encoded integer because a 32 bit integer is 4 bytes (hence add two useless bytes to get the multiple of 3). What does all this mean for encryption? Well, if we take our 160 bit HEX encoded number, we need to break it into 5 equal parts, each of which can be represeted as a single integer and encoded. BUT we can't simply concatenate them because each of them have 2 equal signs indicating the unused bytes. i just pick up on this part one way is can fill your data before encrypting so length is divisible by 3 (or whichever length) say length = 3 then fill 2 random bytes length = 5 length = 2 then fill 0 random bytes length = 2 length = 1 then fill 1 random bytes length = 2 can then use/append "random" number modulus 3 as a last byte to know how many to strip after decrypt or can fill them to front. or even use password as seed for prng to make some "random" position insertions into data for the fillers when use "random" fillers then can always make length(data) = length(pad) If you notice the original statement, I need to convert one 160 bit integer represented in HEX. The only way I can see to convert it to something usable by llIntegerToBase64() is to break it into 5 32-bit integers. So the question becomes how to re-combine them for use in a subsequent call to llXorBase64.... Good idea except where the dummy data can't be allowed to be predictable (like when used as an encryption key or part of a one-time-pad).

RE: HTTPS I did actually consider HTTPS communications as an option. When reading the wiki page about it, I noticed that the server URL for the receiving prim changes periodically (like for region reboots). RE: my reasons My discussion here was mostly academic because the idea of secure communications fascinates me (I've read quite a bit on the subject). It did come about as the result of an actual project. I'm fiddling with a sort of role play HUD for SL. Something to compliment the combat huds I've seen. My thought (and I've seen other systems that do this too) is to add farming/mining/gathering and production/selling as elements that can be used within an RP environment. Or, if you prefer, add the "grinding" elements of traditional MMOs as an optional add-on to SL role play. The challenge is that any sort of system that would support this would be very open to cheating by replaying information being passed from object to hud. So, encrypt the communications. But that means quick encryption and low-lag communications (which pretty much limits me to llSay() and friends).

That is working :matte-motes-big-grin:. It seams to offset the roll and pitch by 90 degrees to the prim rotation in testing. BUT I do understand enough about rotations to fix that for the display. Thanks! Dora Gustafson wrote: I gave the problem a little more thought and believe the complete solution is: float roll = llAcos( < 0.0, 0.0, 1.0 >*llRot2Left( llGetRot())); if ( < 0.0, 0.0, 1.0 >*llRot2Up( llGetRot()) < 0.0 ) roll = TWO_PI - roll; float pitch = llAcos( < 0.0, 0.0, 1.0 >*llRot2Fwd( llGetRot())); if ( < 0.0, 0.0, 1.0 >*llRot2Up( llGetRot()) < 0.0 ) pitch = TWO_PI - pitch; The same thing in other words: vector F = llRot2Fwd( llGetRot());vector L = llRot2Left( llGetRot());vector U = llRot2Up( llGetRot());float roll = llAcos( L.z );if ( U.z < 0.0 ) roll = TWO_PI - roll;float pitch = llAcos( F.z );if ( U.z < 0.0 ) pitch = TWO_PI - pitch;

It took me about a half hour to make OSX read public chat to me using the built in tools and getting it to read the chat log. No need for overhead of a HTTP server in the middle. interesting idea you have, but easy enough to do.

Thanks, when upright, those do appear to be functioning correctly. Adjusting roll and pitch at the same time do appear to be affecting eachother. BUT the roll and pitch never seam to go negative with those calculations and they when flying upside down. For testing, I'm sitting a prim facing along the X axis and editing the prim manually to change position and see what effect it has on the roll,pitch, and compass directions. The premium gift airplane appears to be unrotated but thanks for reminding me. If I want this to be generic I'll need to add a menu to let people deal with rotated vehicles.

My trigonometry skills are somewhat weak and I want to make a HUD to use with the new premium gift (an airplane). My problem is I can't figure out how to properly get the roll (rotation around local X axis) and pitch (rotation around local Y axis). From what I've read, I'm pretty sure that the compass direction (called yaw if I've read the pages on rotations and quaternians correctly) is the Z component of the rotation. So... can anyone explain to me the mathematics I need to perform to get proper pitch and roll values for my artificial horizon? In the end I need a float that is the appropriate angle (preferably in radians).

Awesome idea. The only way I can think is to make the ball bigger but I'm assuming it is a rendering problem. Also, if it is a rendering problem, make sure your draw distance is more than 64m (it probably is).

I've recently been playing with the LSL functions that were clearly added for the purpose of building encrypted communications. As I went through them I found what I think are significant flaws in the design of the functions we are provided with. I'm wondering if there are others who have played with trying to implement practical encryption solutions in LSL? I am aware of alternatives using trusted back-channels for communications (sending through a web server, using llemail) but my goal is more of an intellectual exercise. So, first, the LSL functions we are provided for encryption, what are they for, and why are they wrong? llModPow() is a somewhat odd function that is really only useful when implementing a public key cryptographic algorythm. The problem is that public key cryptosystems (such as RSA) are really only "secure" when they use a key size of 1024 bits or greater and ModPow() works with 32bit integers. Thus I have yet to find a use for this function. llSHA1String() seams to be here for two purposes. First, as a message authentication tool and secondly as a key generation tool. These are both why SHA1 was created in the first place. The problem with this tool is that its output is in HEX. This is fine for message authentication but not practical if you are using it to generate one time pads (more on this later). llXorBase64StringsCorrect() also really only serves one useful purpose and that is to implement one time pads. The problem with it is that it repeats the 2nd string passed to it if the 1st string is longer than the second string. As a chaining algroythim this is a bad idea (especially when using one time pads). Why is the repeating so bad? Because, a one time pad can only be used one time if it is to remain secure. Reuse of the same pad dramatically reduces the effectiveness of it to the point where even the LSL Wiki talks about how insecure it is. llStringToBase64() and llIntegerToBase64() are here so that we can convert our strings and integers into Base 64 encoding, presumably for input into the above mentioned llXorBase64StringsCorrect(). What am I getting at with the above? Well simply put the obvious way to "encrypt" a string using the available LSL tools is with one time pads as follows: string base_64_data = llStringToBase64(data); string base_64_pad = llStringToBase64(pad); string encrypted_data = llXorBase64StringsCorrect(base_64_data, base_64_pad); and, that would actually be incredibly secure if pad and data are exactly the same size (or pad is bigger). This just leaves the problem of generating a PAD. And this is where SHA comes in. We share a secret (password) in advance and add to it some always changing value to generate the PAD with SHA1String. I've seen this implemented in commercial software that was vetted as "secure" by a standards organization. Of course, those get broken quite regularly but at least it's a starting point. We can think about generating our pad as: string pad = SHA1String(password + salt); but that has pad encoded in HEX when it is really a 160bit (20 byte) integer. We do have llIntegerToBase64(), maybe we can add that ... string hex_pad = SHA1String(password + salt); string pad = "0x" + llIntegerToBase64(hex_pad); Had to add the "0x" in front to let the LSL interpreter know the integer is encoded in HEX, not decimal. Otherwise it would truncate at the first letter it ran into. Unfortunately, this doesn't actually work. Our hex_pad is 160 bits but the size of an integer in LSL is 32 bits. So the pad is pretty much always going to be -1 (I tested this) because when a string is converted to an integer, if the resulting number exceeds the maximum size a 32-bit integer can be, it is set to -1. So ... now we have to break our 16 bit hex encoded integer into 5 parts. I won't bother with the code at this point because it has yet another problem to overcome. Base 64 encoding was created to convert binary data into printable characters (to get around transmission issues with some early protocols). In simple terms, it converts 3 bytes into 4 bytes but guarantees that those 4 bytes are all printable characters. So, if the size of your data is not divisble by 3, then there are 1 or 2 "extra" characters needed as filler. To note this, Base 64 encoding uses the equal sign (=) as a marker. You will see two equal signs at the end of the Base 64 encoded integer because a 32 bit integer is 4 bytes (hence add two useless bytes to get the multiple of 3). What does all this mean for encryption? Well, if we take our 160 bit HEX encoded number, we need to break it into 5 equal parts, each of which can be represeted as a single integer and encoded. BUT we can't simply concatenate them because each of them have 2 equal signs indicating the unused bytes. On top of that we haven't solved the "salt" issue to actually generate our pad. If you've actually made it through my rant and understood it, have you got any thought comments or observation on encryption using LSL?

Funny you should say that. My friend and I were just talking about how SL has felt more empty than usual. Someone else posted a thread a few weeks back (can't find it now) observing that concurrent users is way down from what it used to be.

Loki, I haven't used llSetCameraParams() before but after reading the Wiki I noticed a couple of things that might be causing some trouble for you... CAMERA_FOCUS_OFFSET, <-0.0, 1.0,1.5> // <-10,-10,-10> to <10,10,10> meters offset 1m from center on the Y coordinate (you mentioned it's not directly behind). and combine that with: //CAMERA_FOCUS, <0,0,5>, // region relative position would have your camera looking at the center of the raft from a bit off to the right. That does look like what's happening in your picture. What happens when you change CAMERA_FOCUS_OFFSET to <0.0, 0.0, 1.5> ?

After clearing your cache, I find it helps to always do the following after logging in: 1) Open your inventory and search for "a" in your inventory. This forces your entire inventory to be re-downloaded and re-cached (makes inventory a lot easier to work with). Wait for it to finish counting/finding (this takes several minutes, go make tea or something) 2) Completely change avatar, cloths attachments, skin, body, hair, EVERYTHING. One easy was to do this is to choose one of the default avatars or use the "tests" as suggested by another post. This forces a re-cache of your body/shape/avatar and usually takes care of the cloud and missing attachments issues. Once changed, you can change back. 3) Stand in home and face each of the compas directions for about 30 seconds each (really more like 10 seconds, but if I said that, you would just spin in a circle). This loads the image and object cache around your home envirionment which makes it show up faster. You might want to repeat this for areas you freqent often. Your viewer cache doesn't cause lag, it reduces lag because your viewer doesn't need to fetch objects/prims/textures/avatars/etc. Using more than one viewer that share a cache directory (but not the contents) could cause lag when there are conflicts in names of cached items but this doesn't really happen very often.

I hope you are still reading this, since it appears nobody has acutally answered your question. Why does Linden Lab charge a $1000 set-up fee for a new private island and $300 tier per month (or $200 per month for mainland)? They charge the $1000 to cover their capital costs of purchasing, configuring, and racking (mounting in the data center) a server (actually about 1/4 to 1/8th of a server). If you look at commercial grade fully-managed server rental, you will find that the price Linden Lab charges is pretty reasonable. Linden Lab is not Amazon. They don't run their own data centers, they rent space in data centers (2 last time I checked). Are they making money on the $1000 set-up fee? Almost certainly they are, but it's probably not huge. As to the $300 a month private island teir, this is also in-line with a fully managed top rated server. Linden Lab needs to cover the hosting costs, network bandwidth usage (and we use a LOT), operating system maintenance, Second Life server (and viewer) development costs, call center support, etc. This also covers the asset servers. As with above, they are not Amazon, they can't get the economies of scale that Amazon does. And in any case Amazon does not provide fully managed servers. Amazon provides VMs that you have to manage yourself. So, even if Linden Lab could afford to match Amazon's hosting costs, Second Life would still cost more because of the software development and added overhead of system administration. If you think that Linden Lab isn't using a top-rated hosting facility, you might want to try some of the opensimulator systems running on Amazon. Region crossings in Second Life are incredibly smooth compared to the last time I tried one of the alternatives. And those alternatives don't have the software development overhead that Linden Lab did. While I am not willing to pay the tier for a full region, I don't think their pricing is completely unrealistic based on my estimates of their costs. I'm sure more than $100 a month of the $300 private island cost is profit, but there is a reason why mainland is $200 a month for a full region (to encourage use of mainland). I doubt the private island profit is much over $100.

I'm really only guessing but... A number of largeish communities have moved to various opensimulator projects and probably taken a significant portion of their membership with them. Since the Opensimulator server code is about as stable and robust as SL was 3 or 4 years ago, it's become a vialble option for many seeking less expensive tier costs. In the last few years, costs have become a very significant issue for most people. While $10 a month for a premium account is (to me) quite reasonable, $200 or $300 for a full region is a significant outlay that many can no longer afford. Also, Second Life is now over 6 years old. This shows in the graphics and I'm sure many people who were more gamers than emersive world types have probably moved on to the next cool thing. Linden Lab is clearly trying to fix this but they might be at the point where it would be faster to make a full re-write than to update existing code. I have to say that I'm really impressed with the improvements and stability that Linden Lab has achived for Second Life (other's can disagree, but I've worked in software development and what they've done is not at all easy). Second Life isn't making the news like it was when we saw 80,000 concurrent users. I'm sure this is one of the reasons for the Steam integration. If you think new people aren't important, you really didn't watch the concurrency and new-user graphs back when SL was hitting 80,000 concurrent users. There was easily 25% concurrency spikes after each news article and even more when it hit mainstream (not just tech) news. I'm sure there are other reasons and the reality the drop in concurrent users you are seeing is not one (or even 3) factors but a whole lot of different reasons that all add up.

Thanks!

Why not do it the same way they did in Linden Realms? Create an object that uses llVolumeDetect() at the region landing point. Every time an avatar enters, it gives them a HUD. (turn on view transparency and go to Linden Realm. You'll see the object you pass through when you get TPed there from the portal).

I'm fiddling with a temp attach hud and I'm experiencing some strange behavior with it that might be system bugs. My problem is, since the pjira is no longer used, I can't tell if this is a known bug or or not. Or even if it's just my bad scripting. So, here's the situation.... I have an "avatar detector" that is an invisible box using llVolumeDetect() to identify when an avatar enters my landing point (same idea as Linden Realms). When an avatar enters the detector, the collision_start() event Rezzes a "hud" at it's origin passing a randomly generated integer as the start_param. Then it waits a fraction of a second and says the UUID of the avatar that was detected on the channel defined by the start_param. The HUD listens on the channel indicated by "start_param" and calls llGetPermissions() to get permission to attach to the avatar sent over that channel. If the avatar accepts the attach request, the hud attaches to the ATTACH_HUD_BOTTOM position and (should) move itself to <0.0, 0.0, 0.04> (this is just above the bottom button-bar on v3 viewers). When the person wearing the HUD touches it, the HUD sends a dialog box showing the HUDs position. this is really just a test activity so I could figure out where to put the HUD to avoid the viewer clutter that v3 has. If the HUD wearer changes regions, the HUD detaches itself with llDetachFromAvatar() after a 6 second delay (due to a bug I already know about). So, the problem I'm having is: when the avatar teleports, instead of detaching, it spits out the error message, "Script trying to detach from agent but PERMISSION_ATTACH permission not set!". BUT, the script requested PERMISSION_ATTACH as part of the attachment process.

You could add the UUID of the avatars that you've already sent a message to a list and check the list before sending messages. BUT this will eventually crash your script when the list gets too big.

Thanks for saving me the time. I was going help merge the scripts, too. Rolig Loon wrote: ... There's no reason for having two scripts either, and one of them is way longer than it needs to be. Here's Void Singer's simple door script, modfied (but not tested in world) by the addition of a timer that should close it automatically. ...