LepreKhaun

The reason you were getting a 30 cm offset with a cube is because of how bounding boxes work. The raised head rest at the end of the table places the bounding box upper surface higher than the rest of the bed. So, when you tried to use a cube for the physics model, it was being resized to account for that. For your purposes, you probably just require a plane at the height of the bed surface, making your physics model simply 2 triangles. This should be flat plane, at a tangent to (paralleling) the bed surface, which is perpendicular to the Z axis.. When you have it at angle as you've done, it then obtains a bounding box and will scale wierdly (besides having a slanted surface to stand/sit/lay on!). Your poses/animations would then account for the inclined head rest. For your soft linkage issue, simply make the bed the root and the towel a child. That way the plane you have for physics will scale with the bed in its entirety. And it gives you the option of having two towel models, one on the table and the other "draped" over the rubbee, and bringing one or the other into view as needed.

anselm Hexicola wrote: Thankyou for your replies. They gave me much to mull over. (I should maybe say that my uploaded objects are just for my own amusement; ie. not to be distributed inworld/sold. They just get put on my own rented parcel. So they will not impinge on the general SL users' graphic experience. That said, I do try, if only for my own sake, to get it as right as I can.) ... @LepreKhaun - yes, I do tweak the UV mapping as best I can; it takes me ages, but I kinda like it! Generally my cheap and cheerful style of texturing is to do an AO then add other layers (colour, text..) Because of that, "stacking" isn't an option. Also I tend to keep my islands (perhaps too ) widely spaced - got snookered once when they were very close. ... (...I now reckon I can keep the texture down to x512 with a bit of fiddling about with the UV map; but that means all my LOD's will need changing!) Thank you for the screen shots, it gives us something we can make concrete suggestions on. For instance, if you're never going to have stencilling on the inside of that door, you can probably drastically decrease the size of its UV island. Here I've made it 1/4 1/16th the size of what it was, rearranged the islands and tightened it all up just a bit. This cut the UV mapping required for this door in half. If I found that arrangement caused too great of detail loss on the inner door surface, I'd consider shortening the two right hand islands, enlarging the inner door island (from its reduced size) 150% in height and doubling width then turning it on its side, where it would snug into the bottom right corner. And, yes, this "fiddling around" is time consuming, no argument there. But once you get the mind set of big islands for detail areas, squish everything else as small as they'll go, it'll go quicker. And you'll have the satisfaction of having crafted your model the best possible way. {EDIT to correct scaling error- 1/4x1/4 = 1/16th. LOL] [and AGAIN to show a larger interior door as described.]

Have an idea for a mainland harbor, seaside airport or a large, luxury island and tired of looking at tiny 512m lots at outrageous prices? This is a rare offer of not one, but two, adjacent parcels with a full 64 meter protected waterfront that are each 128 meters deep. That's right, a whopping 1/8th region (8,192 sm) with a 1,875 prim allowance each, AND both bordering on Linden Seas! The price is less than half of neighboring, much smaller waterfront parcels are going for, your choice for only L$40,000. So, don't think about this too long. And if you'd want something even larger at a better deal, pick up one of the 64x64 parcels next to each of these going at a mere L$1/sm!!!

You can have one 1024x1024 replace four 512x512 textures on your mesh with a savings since each texture to be downloaded entails an overhead in its "fetch and get". It's just a matter of using offsets and sizing for which quarter of the large texture you wish to apply where. However, you do lose the option of repeats using this optimization and your entire mesh will be "blurry" until the entire texture is downloaded. But, if if that isn't a concern, you can even take the idea further by having one quarter of your texture further subdivided into four 1/16ths (or 256x256 textures) for the smallish areas of your mesh. And, of course, if you're doing UV mapping, there are ways of manipulating the relative sizes and placement of your islands to acheive the same result. In other words, make unimportant or smallish areas that don't require too much detail occupy less space on your UV map and arrange things to have as little wasted space as possible. Even "stacking" islands that could well have the same texture pattern showing can free up precious map space to allow enlarging the "important" islands that require finer detail. As Ciaran Laval said, it depends. It is good to know all of the options one has to be able to pick and choose what may work best on your particular model.

Try contacting the creator of any that "almost" suits you. If they see a possible profit to be made from adding the scene to their MP inventory you may get a really great deal. If, however, you are looking for a one-of-a-kind custom build, be prepared for a bit of a shock when you hear the estimate.

As you can see, seeking legal advice in a public forum can cause something of a stir, especially on a thorny a topic as copyrights*. Much more important than whether it is illegal, is whether it is against LL's ToS, and that is much easier to find out, simply read it and, if you need clarification of the fine points, go to https://secondlife.aditi.lindenlab.com/my/account/ip/tutorial.php? and take what is known as the "mesh test" (which, I'll point out, has on its starting page "If you need advice on intellectual property rights, we suggest you contact an attorney.") I say the ToS is more important because the likelihood of being sued or having a DMCA take down notice filed against you by Disney may be slight but the Linden's do take ToS violations seriously, for the most part. But, there's still another consideration that may be more important that- SL is a (very real) society with an established social code. And you may be both (barely) legal and (just) within the ToS but run afoul of that. As you can see, opinions on this subject can run hot (and rightly so!) when one considers what creators contend with along the lines of content thieves, copybot programs and blatant disregard for their licensing agreements. Having creators turn against you may prove to be the undoing of any commercial venture as well as taking all the fun out of the SL experience you might otherwise have had. And, finally, there's the most important of all considerations- how one feels about their own actions. If one does doubtful things it will tend to harm your self image over time. It's good that you have asked the questions you did because the responses you received here may influence you towards a more "livable" course of action. It's a good thing to go to bed each night with a clear conscious. * Ever notice, in mainstream movies when they have a birthday party scene you'll rarely hear anyone sing "Happy Birthday"? There's a reason for that- the song is actually under copyright protection (see Copyright status at http://en.wikipedia.org/wiki/Happy_Birthday_to_You if you didn't realize this)! Now, let me ask the reader- How many times have you, your family and your friends sung this song w/o permission??? {Edited for readability}

note Genesis wrote: Where have you seen that "JSON actually has brought true, indexed arrays as well as associated arrays AND nesting to LSL" It s wrong . With an indexed array , get operations or set operations are O(1) time .Time is independant of the size of your datas. With map arrays , get operations or set operations are O(k) time . Time is proportionnal to the size of the index of your datas. Time is independant of the size of the values of your datas With a true list from an another language ( not LSL list ), get operations or set operations are too proportinnal to the sum of the size of node pointers or references . Time is independant of the size of the values of your datas With JSON string inside LSL , get operations or set operations are O(n) time . Time is proportionnal to the size of your FULL datas ( keys and values ) , because it s as simple silly string. It s the worst case who can happen . I dont consider JSON as a solution to replace indexed arrays and associated arrays , and nested arrays . The goal to use indexed arrays , associated arrays , nested arrays is to have a better data structure more efficient for some kind of algorithms , not a better syntax . And binary searchs can t be implemented efficiently , by instance , because there is no string operators to compare s1 < s2 or s1 >s2 . The "keys" of the JSON string are only strings . JSON strings in LSL are the worst efficient to use algorithms You have talked too about nested data structures : same problem . a real data structure cfrom an another language could implement AVL , or binary trees and to be able to do search in O(ln(n)) time . With JSON String, as it s implmented , it will be never possible No denying the shortcomings of LSL that all of us have to struggle with. However, the definition of indexed and associative arrays does not include the stricture of amortized time of operations as you give it* except at the lowest level of optimized implementation. In other words, you are citing "best case" implementations, which is rarely seen in high level languages, even those with native support built in for these structures (which, as I've already pointed out, LSL lacks). And I am in complete agreement with "I dont consider JSON as a solution to replace indexed arrays and associated arrays , and nested arrays ." since LSL has none of that to replace in the first place, it is what JSON brings to LSL. But when you claim "there is no string operators to compare s1 < s2 or s1 >s2" you are apparently unaware of the numerous user functions that have been written to do exactly that. Just Google "LSL string compare" and pick the one you feel is most memory or time efficient as you wish. And I'll grant that " a real data structure cfrom an another language could implement AVL , or binary trees and to be able to do search in O(ln(n)) time . With JSON String, as it s implmented , it will be never possible". However that is far from saying that we can't now implement AVL or binary trees if we so choose. In fact, with a bit of thought, one can now do true objects with encapsulated data that can only be manipulated with methods. A bit more thought, and one can even implement classes, complete with inheritance, albeit somewhat clumsily since LSL has no pointers and can't pass by reference. I'm of the opinion that a coder shouldn't avoid complex data structures simply because "it may take a bit more time" to do something and, as a consequence, miss out on such powerful tools as reusable code modules. For instance, say one wished to now make a Schedule application for SL, a way to store alarms that would not only go off when as the user has set them, but would also give them a message with the particulars of the alarm- say, "Builder's Brewery class in Advanced Bulding in 5 minutes. Don't miss this!" Wouldn't that be neat? First you'd design an Alarm object, possibly like this: jsonAlarm { "kID": string, // Unique Identifier "kTIME": string, // Time Stamp Format - "YYYY-MM-DDThh:mm:ss.ff..fZ" "kTYPE": string, // Descriptive classification of the alarm, optional "kPURPOSE": string, // Reason for the alarm being set, optional "kSLURL": string // "Region Name/x/y/z" SLURL, optional} Then, you'd design your Schedule object along these lines: jsonSchedule{ "kCURRENT_ALARMS: { "kTHIS_DAY": [jsonAlarm, ... ], "kTHIS_WEEK": [jsonAlarm, ... ], "kTHIS_MONTH": [jsonAlarm, ... ], "kTHIS_YEAR": [jsonAlarm, ... ] } "kONE_TIME_ALARMS": [jsonAlarm, ... ], "kRECURRING_ALARMS": { "kDAILY_ALARMS": [jsonAlarm, ... ], "kWEEKLY_ALARMS": [jsonAlarm, ... ], "kMONTHLY_ALARMS": { "kMONTHLY_ALARMS_BY_DATE": [jsonAlarm, ... ], "kMONTHLY_ALARMS_BY_DAY_OF_WEEK" : [jsonAlarm, ... ] }, "kYEARLY_ALARMS": [jsonAlarm, ... ] }} The next step would be deciding on the functionality you'll present to the user, the "methods" of the Schedule object. And these might be along the lines of: VIEW one or more Alarms // VIEW Modifiers ALL- returns a formatted listing of all "specified" alarms in Schedule NEXT- returns next scheduled alarm TODAY- returns all alarms for today DATE- returns all alarms for the specified date FIND a specific AlarmADD an AlarmDELETE an AlarmMODIFY an Alarm Then it's simply a matter of writing the code bits to do the methods you've decided on, and having a (say) 10 minute timer event that would continuously update your Schedule object (copying recurring alarms into THIS_DAY as needed, for instance) and setting the timer for the next scheduled alarm. The beauty of this approach is that later you may decide to add a field/key to the jsonAlarm object named "HOW_TO_NOTIFY" and have choices such as having a prim flashing its color, a sound played, an IM or e-mail sent, llOwnerSay, whatever. And, get this, you won't need to change anything you've written up to that point but simply add the coding to handle that field! But wait, there's more! Once you've finished your Schedule object, you can now reuse it! For instance, you could make a completely menu-based front end, or a HUD with some buttons, a clock and perpetual calendar used to access the object's methods (along with the needed llTextBoxes at times) or a wall-mounted display the same along the lines of the HUD. These would be three entirely different applications to offer the end user, but they would all have the majority of code exactly the same! And, once they're written, if you decide at some point to change the data structure of either your Schedule object or the Alarms (such as shortening the names of all your keys to have a smaller memory footprint of the JSON object), you only need to change the coding within the object itself, not in any of the front ends as long as you leave the method signatures themselves untouched. woot woot! * FYI, the best case for map (associated or random access) arrays' "get" and "set" is not 0(k) as you stated but is 0(log k) 0(1). Since the indexed arrays are dynamic (as opposed to static) the big 0 values are 0(n) for anything but indexing, which is 0(1). [EDIT TO CORRECT SELF] Sorry, big 0 notation can be somewhat confusing if one mixes best case and worse case considerations in together. [ETA: source citation for best case implementations: http://en.wikipedia.org/wiki/Array_data_structure table under Efficiency comparison with other data structures.

np, all good in the neighborhood.

Suspiria Finucane wrote: LepreKhaun wrote: Madeline Blackbart wrote: LepreKhaun wrote: Madeline Blackbart wrote: Candii9 wrote: -1 I'm sorry you feel the facts deserve a minus point. -2 for now claiming your opinion is a "fact". So your saying that copyright laws are not fact? So they don't exist? Pretty sure they are infact fact. And that taking someone else work without permission is in fact against the law. Unless you would like to prove to me that this "opinion" is some how NOT a fact? I'd also like to give YOU a -50 for not know about copyright laws. Of course copyright laws are a fact. However, our individual interpretations of them are our opinions about that fact. -3 for missing the point entirely. Oh, I get the point of these kinds of threads entirely, having seen a good number of them over the years. I just feel playing King/Queen of the Ethical Hill is somewhat childish and immature is all. My observation of human behavior makes me believe that no amount of ranting and raving, hair pulling and chest pounding, and general posturing is going to change anyone's ethics. And, with a number of years on debate teams behind me, I regard the argument of "if you don't agree with my opinion then you must be denying the facts under discussion" or "my opinion is going to be the fact of discussion" as erroneous. The truth of it is, no matter how passionately one believes, no matter how emphatically they state their position, no matter how "good" the position may be within some ethical context- an opinion is merely an opinion. No more no less. Now, I gave my opinion (I would pay particular attention to the last line of that link, "If there is any doubt, it is advisable to consult an attorney.") very early in this thread, way back in the 4th message down, after stating a fact. But, participants in these kinds of free-for-all ethical pile-ups are rarely concerned with facts. No, their opinions and the drama based bickering is all-important. Fine, have at it. Some get a lot of amusement value out of it, usually the starter of the fray if no one else. And if it gives you a warm, cuddly feeling for having fought the good fight afterwards, by all means, carry on. Just don't try to disparage those that choose not to roll around in the dirt with you or are willing to point out fallacies.

Gistya Eusebio wrote: LepreKhaun wrote: [snip] But our main problem with Json usage is that LSL lacks native support for both associated array and nested data structure manipulation and we have to "roll our own" using the llList* functions. Klutzy, but doable. A bit of study of Computer Science doesn't hurt either, very little math involved even! :smileyhappy: [ETA] On a side note, FORTRAN got nested arrays in 1954. Such is progress... Is there some technical reason why they continue to leave arrays and nesting out of LSL? And for that matter, data storage? They could easily charge a nominal fee for database usage and pad profits with that. As it is we have to rely on outside data stores when most of the time, it's over-kill. Maybe they're working on enhancing LSL in these ways, but we just haven't seen it yet. Ahhhh, but that's just thing- JSON actually has brought true, indexed arrays as well as associated arrays AND nesting to LSL! The only thing lacking is the methods to work on them naturally. So, we'll have to "roll our own". Fortunately, using just the newly supplied JSON methods of llJsonGetValue, llJsonSetValue, llList2Json, llJson2List and LlJsonValueType along with the llList* functions we do have, we can not only construct complex data objects but craft the methods to handle them as well. OOP has come to LSL! woot woot!!!

This may be a problem with their Maturity Ratings conflicting with the region or parcel they are on, http://community.secondlife.com/t5/English-Knowledge-Base/Maturity-ratings/ta-p/700119 : Have her try adjusting her maturity ratings setting in her prefrences to see if that clears up the problem.

Syle Devin wrote: ... ... collision_start(integer num) { name = llDetectedName(0); if ( name == "ball") //Checks if Bowling Ball has hit prim. { trigger = TRUE; } else { trigger = FALSE; } }... ... I wish to draw your attention to this part of your code. Consider what happens when the bowling ball hits 10 pins in RL: A LOT of collisions in a very short time. Pins will be hitting other pins, the ball might be banging into any given pin a number of times, everything bouncing off the alleyway and walls; that's the "CRASSSHHH!" you hear at the moment I bowl a strike.* Now, when more than one collision with a task takes place in less than 1/45th of a second, ALL of them together become available to the collision_start event handler. That's the purpose of having "integer num", so you can determine how many you need to process during that event trigger. And "llDetectedName(0)" is going to address only the first in the list of all the collisions. So, I don't know what you intend to do with the "trigger" boolean but you may want to rethink this a bit more. *The "thud" you hear following that is from the rest of my team collectively passing out in disbelief

The 2 member groups may be as Lindal describes but they are also formed by two individuals to do collabrative works. For instance, one may be a bulder and the other a scripter or texture artist. To work together effectively, they would form the group, deed land to it and the builds would have their permissions set where anyone in the group could modify it.

The avi who appeared in your home was simply inviting you to engage in (most likely) mild role playing. Next time something like that happens you might consider the offer. The way I'd handle such a situation would be first to say "just a sec." Then I would take a moment to right-click on them and pull up their profile. You can do this without the other ever knowing, there isn't an alert given when it's done. A lot can be determined by a quick scan of a stranger's self-description, groups they participate in and picks/favorites (keeping in mind that a few bad apples are deceptive, just as in RL!). And if the person's profile seems like a person I might like to get to know, I'd then say something along the lines of "Well, how expensive are you? And do you do windows?" In other words, I'd play along with them. Who knows where it might go?!? SL can be a very rich and rewarding experience and it really is all about our interactions with each other. If you have never role played, finding someone willing to introduce you to it can be a wonderful, enlightening experience. Or, at worst, you'll have wasted a little time to find out you're really not into it after all. So, speaking just for myself, did she perhaps leave a card with you?

You were in a public place wearing bedroom attire and holding a bedroom accessory. Obviously the sim owner (or their agent) objected to that and a discussion ensued. Next time that happens, simply leave after finding out what might be acceptable there and don't go back unless you're willing to wear it. Getting argumentative with a sim owner is never advised since it's a battle you will never win.

The "host not found" error is an issue with your connection to the internet that may be caused by a number of things. To cure it try, in order of complexity (in other words, let's try the simple cures first!) : Reboot your computer Restart your modem (unplug it off for at least a minute or so and restart it) Download another viewer and attempt to log in. Reconfigure your firewall (see http://wiki.secondlife.com/wiki/Configure_your_software_firewall for instructions on that if needed) If you still can't connect, you may have to get technical and follow the instructions at http://neilrobinson.wordpress.com/2008/05/19/a-fix-for-dns-errors/

Madeline Blackbart wrote: LepreKhaun wrote: Madeline Blackbart wrote: Candii9 wrote: -1 I'm sorry you feel the facts deserve a minus point. -2 for now claiming your opinion is a "fact". So your saying that copyright laws are not fact? So they don't exist? Pretty sure they are infact fact. And that taking someone else work without permission is in fact against the law. Unless you would like to prove to me that this "opinion" is some how NOT a fact? I'd also like to give YOU a -50 for not know about copyright laws. Of course copyright laws are a fact. However, our individual interpretations of them are our opinions about that fact.

Madeline Blackbart wrote: Candii9 wrote: -1 I'm sorry you feel the facts deserve a minus point. -2 for now claiming your opinion is a "fact".

Syle Devin wrote: That all helped a lot. I actually hadn't actually started the script just yet but that was exactly what I needed to know to at least get the collision detection down and such. Now I just have to get the rotation to be compared. Below is what I have. It worked until I added rot = llGetLocalRot(); and got a mismatch error and not sure what is wrong. Also I might later add a timer, or something, instead of waiting until the pin stops moving so that a turn doesn't last too long but we'll see. I need to test more to see if that is ever a problem. string name;string rot;integer trigger;default{ state_entry() { rot = llGetLocalRot(); } collision_start(integer num) { name = llDetectedName(0); if ( name == "ball") //Checks if Bowling Ball has hit prim. { trigger = TRUE; } else { trigger = FALSE; } } moving_end() { if (trigger) //If Bowling Ball has hit prim then run script. { llOwnerSay("Frozen at" + rot); } }} I am really excited to actually be making progress as I was feeling like it was slightly out of my reach. Thanks for the help both of you! rot = llGetLocalRot(); // rot must be typed as a rotation, not a string

Yes, we're both on the same page here. My approach might require a call to a (not supplied by LSL!) function "isKey", that would return a boolean after testing to see if the supplied KEY is, in fact, within a specific JSON_OBJECT. However, a run time removal of any element, either a KEY:VALUE pair or a VALUE within an indexed list, implies some logic thread leading up to it that one would hope is correctly written. But our main problem with Json usage is that LSL lacks native support for both associated array and nested data structure manipulation and we have to "roll our own" using the llList* functions. Klutzy, but doable. A bit of study of Computer Science doesn't hurt either, very little math involved even! :smileyhappy: [ETA] On a side note, FORTRAN got nested arrays in 1954. Such is progress...

Tim Flynn wrote: ... I also looked on the Marketplace and saw there were more than a few options for fading lights. But there are few places to see the item in world and almost no demos. I've learned from experience things are not as they seem in the picture or description and am hesitant to try a few of them and waste the Lindens unless I know it works. I'd try contacting the creators of those lights you find interesting on the MP. I'm certain you'd find at least one who would be more than willing to work up exactly what you envision. And if you ever have a problem when writing your own code, this would be the correct forum to post in.

Being California based, SL falls under the Copyright Act of 1976,17 U.S.C. § 107 and has a provision within it that defines what constitutes "fair use". http://www.copyright.gov/fls/fl102.html . I would pay particular attention to the last line of that link, "If there is any doubt, it is advisable to consult an attorney."

The problem arises because inventory permission changes are not applied until the item is rezzed, which you're failing to do before transferring. This is brought to your attention with a Firestorm viewer, with an asterisk that appears next to the field when you make the change. As Brent Linden advised, "Don't change the permissions of containers in your Inventory." http://forums-archive.secondlife.com/120/1a/58241/1.html. Unexpected results happen apparently.

Innula Zenovka wrote: ... sensor(integer total_number) { integer i; detected=[];//clear the detected list for( i = 0; i < number_detected; i++ ) { key k = llDetectedKey(i); string s = llGetUsername(k);//llDetectedName is deprecated nowadays if (!~llListFindList(visitor_list,[s])){ if (showOwner == TRUE || k != owner){ if (overMyLand == FALSE || llOverMyLand(k) == TRUE){ visitor_list +=[s]; } } } } //finished processing the avatar list } Careful, number_detected should read total_number.

OK, say you had an application that was designed to handle messages and you wanted to handle them in the order they came in but at times they might pile up on you, such as when you're offline. To do this, you would be implementing what is known as a queue (http://en.wikipedia.org/wiki/Queue_(data_structure) ), where you are adding messages to the end of a list and handling them from the beginning, the same way a check out line works- the person at the head of the line is next, new arrivals join the end of it. Since the order of arrival is important, you would naturally use an indexed array, the JSON_ARRAY for this, adding incoming messages to the end of it and removing from the first of the array as you answer each as you get to it. The key word in the action is removing, because if you are just setting the value to null, your list will grow [EDITed here for correctness] indefinitely until a stack heap collision occurs instead of simply expanding and contracting.