Lear Cale
-
Posts
438 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Lear Cale
-
-
You probably didn't turn off object entry, or it wouldn't have been able to get in.
You probably didn't turn off scripts, or it wouldn't have been able to follow.
You can use About Land and return all objects by anyone you don't know.
-
I assume you mean 3 hours to make the video.
Either that or you're a world speed record holder for building in SL.
-
Yes, you are allowed to make recommendations.
-
Kayaker Magic wrote:Well, I'm competing against the guy who has something like this in his code somewhere:
for (EVER){ vector pos=//some calculation llSetLinkPrimitiveParamsFast(1,[PRIM_POSITION,pos]); //there are 2 or more prims in the build sleep(0.02);}and MY customers are asking me "Why do YOUR critters move in such a jerky way? Cant you make them move smoother?"I'm trying to be a good netizen about it and find some way to increase my step rate while still using good event driven programming.I've gotten smother motion with physics, but it has its own problems. The physics engine is not lag free either. It runs away from me all the time. llMoveToTarget can't really do constant velocities and won't move larger builds. I've had to resort to using vehicle physics. Meanwhile, the guy with the ugly loop above is getting beautiful results. What is a scripter supposed to do?
Note the sleep(0.02); According to the documentation, this will actually be more like a sleep(0.05). I doubt there's a significant difference between using a timer and a sleep, other than the obvious: your event-driven code will be able to respond to an event, whereas this one can't (without odd gyrations like checking a prim parameter for a passed value from another script).
Without the sleep, the code would be criminal. ;-)
BTW, this is why we hate pets. Any script that does something EVERY FRAME is ... well ... a bit rude to those sharing the sim. Admittedly, overuse of physics isn't a good solution.
-
You won't see memory freed using llGetFreeMemory(). As mentioned above, it only reports a high water mark (unless they've changed that recently). So, forget about garbage collection; the results of llGetFreeMemory() have nothing to do with that.
Using multiple scripts is one solution. Might be the best way.
But first, make sure you're using the most efficient way to append to a list for Mono. When I originally tested mono memory usage, there was no apparent penalty for doing it the simple way, e.g.:
myList += item;
However, that was before they checked memory usage for every function call. Now that they do that, the code above takes twice the space for myList plus the space for item. I don't know the current best incantation for adding an item to a list in Mono, but it's on the wiki somewhere. If you're doing the simple thing, you'll benefit a lot by using the optimized but illegible version.
-
Thanks for the update, Void!
-
There's no way to detect a spy script.
Your best bet is to use a combination of beacons to show scripted objects and look for suspicious ones, and About Land to see the list. Also, check out anything that may have been given to you or edited by the person you suspect.
Hopefully you're just being overcautious. No spy script can spy on IMs, so until you're satisifed you can use IM rather than chat. Of course, a spy could also see who's in the area.
-
That script looks like it should work; it's doing what Void says: it's repeatedly restarting the open-mouth animation. That script does other things too; looks like it handles a gag; you may want to remove the unnecessary bits.
Specifically, remove the LinkedMessage handler, and set gInserted to TRUE in the state entry handler. (Better yet just remove all the tests on this variable assuming it's always true.)
Remove the llMessageLinked call, and starting the toothedsmile expression.
-
Lycia Undercroft wrote:Ok I have a question about using state changes to remove a listener... What happens if you get an event when you are in the second state?
It depends on the design of your state machine and the overall logic of what you're making.
UNFORTUNATELY (and I'd like to crucify whoever made this decision), all queued events are deleted on a state change. This means it's actually impossible to build a classical state machine using LSL states (lol).
As Void says, in most cases, our devices aren't too susceptible to loss of a single event. Most times, it's a click, and the users provide the fault tolerance by clicking again. The only time you need to worry about this side effect of state changes is when you design a fairly sophisticated system where multiple scripts are communicating, and losing one message would cause a failure. In this case, don't change states, or build fault-tolerance into the communications architecture (e.g., with acnowledgments and retries). (gak)
-
1
-
-
I agree with Void. While llListenControl or turning listens on and off specifically might reduce overhead a little, if you use listens reasonably following the advice above you should be OK.
When considering performance and the effect on a sim, the question to ask is HOW MANY. At the bottom, you want to get to how many times your listen handler is invoked and the code inside it runs and does something. The "innermost loop" as it's sometimes called, somewhat incorrectly.
The thing that many people forget to consider is that a big factor in answering this is a number of other "how many"s. For example:
1) how many of these scripts will be rezzed within "earshot"? (using llRegionSay, the region. Using llWisper, 10M.) In most cases, like the case here, there's just one. In many other cases, considerably more, so more caution is required, such as poseballs. For an extreme obsurd example, consider a horridly coded resizer script in a popular brand of 200-prim hair. (Not that I know of such a case, where resizers use listens in each prim, but you get the idea.) I did have a friend who was proud of his building skills but wondered why his sims always lagged, and the reason was he left the alignment scripts (skidz or whatever) in all his prims after he was done! Nearly every prim in the region ran a script with a listen!)
2) how many chats match the llListen filters. Void made a point of this above, and correctly so. The most important one here is usually the channel, picking a good unique channel filters out nearly all "crosstalk" -- objects hearing messages meant for other objects. Any other filters you can apply such as, for a HUD, the owner, also help and should be used.
3) how many chats matching the filters are actually intended -- again as Void pointed out, a few quick sanity checks can avoid "crosstalk" quickly. Ideally there should be nearly none of these.
The worst case is listen for any text from anyone on channel 0. This wil fire the scripts Listen event handler for everything anyone in hearing range says. If there's only one script like this nearby, even then it's usually not a problem. But we've been burned by sloppy coders of popular objects like poseballs, and so in a hangout spot we might have dozens of scripts processing everything said by anyone -- this is the total fail case that caused people to be concerned about this subject in the first place. It should be avoided in almost all cases, with the exceptions being either very important functions that can't operate any other way (translators), or novelties that we pull out for a laugh, use for a little while, then put away (possibly forever).
In LSL, anything that only happens say once per second in a region is insignificant in terms of the region's performance. But if we have thousands of scripts running, and a big chunk of them are doing something once a second, we start to see slow script performance ("script lag", where it takes a while to say, open a door, but the sim works fine otherwise).
Note that bad scripting with listens generally only causes script lag, and does not cause anyone's frame rate to go down, or rubber-banding when you try to move, etc. The exception to this is when too many scripts use too much memory causing the sim to thrash, which REALLY socks it. So, in most cases, "lag" isn't caused by bad scripts.
-
As everyone has said, this woman was being rude and presumptive, and you have no need to take notice.
Concerning your jiggling, that is set by THEIR settings, not yours. Let me make this clear, since several posters above seem to have it wrong.
The "physics" settings in your browser affect what YOU see. They affect how everyone you see looks on YOUR screen. They do not affect in any way how others see you on their screens.
So, anyone who comments on your jiggling is either joking or ignorant, because it is they who control what they see, not you.
-
Medhue Simoni wrote:Lear Cale, I appreciate the thoughtout reply. I've only read about DMCA take downs. I've not actually filed 1.Lear Cale wrote:There are a number of wrong things. First LL didn't simply remove the specific content that violated the DCMA (in the incident I mentioned) -- they deleted all content with a 'created by' matching a given avatar. That doesn't just delete products, it deletes anything people have made from the prims created by that avatar. Someone could lose any amount of hours of work that way.
Why would they delete everything from the creator? Why would they not just delete the product and items inside that were infringed?Good question. It's what they did, in the Eva Capalini incident (finally remembered the av name).
Normally, DCMA is more straightforward. Someone gets around copy protection to copy content, and the new content appears created by them. LL's reaction is simple: delete the offending copies by asset ID, which is different from the originals.
This wasn't a DCMA takedown -- at least, not a legitmate one. It wasn't a DCMA violation; it was a license agreement violation, which LL shouldn't even get involved in (perhaps, though that raises a number of debatable issues). EC bought full-perms animations from SS and others, with the agreement not to distribute full-perms. EC distributed full-perms, by selling a "business in a box". Someone bought the BIAB and distributed it for free. Result, a number of animators' wares being available full-perm. The creator of the OBJECT (not the anims) happened to be EC, so SS talks LL into deleting content created by EC. Unfortunately, that hit perfectly legit folks who happened to (foolishly, as I learned!) used EC's object in their own creations, while deleting the illegal content. That was me, using it to create MLPV2, used by a lot of perfectly legit furniture makers. Fortunately it was early in the MLPV2 life cycle, and I changed the object owner and also made it no-trans so that anyone using it would be forced to use their own object in their products.
It sounds like LL did something very similar in this case, but I don't know the details as well as the EC case (where my nose was rubbed in the details!)
In any case, there is a simple way for LL to avoid the vast majority of content theft, which is to require identification for all new avatars. Then anyone found violating the rules could be banned. As it is now, they simply ban the avatar, and the offender opens a new account. LL has their reasons for wanting to allow complete anonymity, and we all face the consequences of that. That's (second) life!
-
Innula Zenovka wrote:I may be mistaken (I often am) but I thought the success of the original sexgen product preceded the purchase of the mocap suit, rather than the other way round.
That's my understanding, too, based on rumor, unnuendo, and old forum posts (in decreasing order of reliability ;-). I think it was before I joined.
-
Medhue Simoni wrote:Personally, I don't quite understand why deleting all the original content is a problem. Any good merchant keeps records of sales. If all my customers lost all their purchases, I'd only need to get a list of all the purchasers from my records and send them all updated versions. So, I would not fault LL for a merchant failing to keep proper records. Being that he filed the DMCA, he should have known what would happen next and been ready to respond in a professional way, not bitching at LL for doing exactly what he knew they would do.
There are a number of wrong things. First LL didn't simply remove the specific content that violated the DCMA (in the incident I mentioned) -- they deleted all content with a 'created by' matching a given avatar. That doesn't just delete products, it deletes anything people have made from the prims created by that avatar. Someone could lose any amount of hours of work that way.
Second, you don't think it's a problem for thousands of residents to have to contact countless merchants to restore their land, due to no fault of theirs or their suppliers or merchants? You think it's perfectly OK for LL to make a habit of deleting content that's perfectly legal, just because it shares some arbitrary criteria with illegal content? I don't.
Third: The actual illegal content didn't get deleted! That's the really funny part. Anyone with those illegal anims who'd rezzed a copiable version of the freebie bed in question would still have it in their inventory, complete with all the illegally distributed animations.
Fourth: I try to keep records of all sales, but due to mishaps, there are gaps. That's not LL's fault -- unless LL goes and deletes my products regardless of the fact that they're 100% legal and 100% original content. Then I have a problem, due to my own mistakes, but made horrible due to LL's mistake.
Fifth: you may not mind redlivering your products. Others do.
I could go on. I'm surprised you don't see any problem with what LL did here. However, it's a mistake, and we all make mistakes, and in the first incident, I give LL credit for recognizing the mistake and doing their best to correct it ASAP. I do not think LL are evil or incompetent. As we all know, institutional memory is limited, and this kind of thing is bound to happen. It's just unfortunate, and a little bit humorous, though not so much to those it adversely affects.
-
There are some available as freebies at jPose Island:
jPose Sit is a sit poseball with a number of sit animations the user can select using shift-arrow. However, all the animations have to use the same sit target. (There might be an option to have different sit target offsets for different anims using the notecard config; it's been a while and I don't remember offhand.) The script and anims are full perms. This is easy to use but won't work with all combinations of arbitrary animations. Try it and see. With luck you can just drop the anims in and it works.
The Easy Sit Target Positioner allows you to do essentially the same thing as jPose Sit, but without poseballs. That requires setting the "sit target" for the prim being sat upon. With poseballs, it's easy to just adjust the poseball so the av fits the object. Without poseballs, you need to do this a trickier way, which the Easy Sit Target Positioner makes easier ... but it still takes some fussing. I'd start with poseballs and graduate to non-poseball projects. It also comes with all the freebie sit poses I could find at the time I made it long ago, and might be worth picking up for that reason.
MLPV2 is a script system that takes some notecard setup; it provides a menu that rezzes up to 6 poseballs with menu buttons to choose the poses. This is the most flexible but also the most time consuming to configure and understand. There's a wiki tutorial to help (find it in my inworld profile picks).
jPose Island is adult; if you're not adult-capable then ask on the MLPV2 group and someone should be able to help you. You can find jPose Island in my profile picks. There's a TP pad in the front entrance to the FREEBIES section.
~~~
If you want menus for poses but don't want poseballs, or poses for a vehicle, try nPose -- you'll have to ask for it since I don't know where to get it these days. You can ask in the MLPV2 group and you'll probably get help.
XPOSE is a system like MLPV2 with more features and supporting up to 15 poseballs, but not free.
-
Wow.
First, it boggles my mind that after raising so much cain about protecting his intellectual property rights (IPR), SS would just go and trash those of others. It paints a rather unflattering picture.
Second, it sounds like LL has yet again shot their foot by overreacting to SS. The last time, SS complained about someone who'd released his anims full-perms into the wild, so SS deleted all inworld content with creator as that person. The trouble was, I had originally gotten interested in MLP because of a freebie full-perm bed I found and started fiddling with. I quickly realized that the anims weren't intended to be free, so I set them aside, but kept fiddling with the scripts, and used them to create MLPV2. Um (blushing) ... without creating blank scripts created by me. So one morning everyone wakes up and their MLPV2-powered furniture has the scripts and notecards deleted! Fortunately LL quickly learned it was a mistake, and to SS's credit, he offered a Sexgen bed to anyone who claimed they'd lost a legitimate bed in the process.
And now they do it again ... heavy sigh!
BTW, changing perms on an item does not change its key. What you may have seen is that when you drag a copiable item out of inventory into world, it creates a new copy and that new copy gets a unique key. That's for objects. Things like animations, which can't exist by themselves inworld (but must be in the inventory of an object or an avatar) follow different rules: the copies all have the same key, and changing the permissions does not change the key.
Anyway, the good news here is that now there will be a free set of sex bed animations that fledgling furniture makers can use. It will impact the business of us animators, but there will still be a market for new, good anims. SexGen anims were good for their day but that was quite a while ago.
But it's shameful if SS did indeed release the property of others.
In any case, I bet SS's lawyers had a good laugh or two in the country club locker room, discussing the subject of the case!
-
1
-
-
I assume you want this for a worn object, and don't want to replace the AO in the wearer.
I'm more familiar with sitting animation scripts, but I do have freebie guitars I made long ago that have a similar problem. Given all the guns we see in SL, I'm sure there's an appropriate solution for this, though i don't know exactly what it is. I do know how AOs work, having mucked with ZHAO-II a bit. Hopefully this wouldn't need to poll as fast as a good AO needs.
I'll probably look into this some time this week, but hopefully someone will pop up with a simple answer before then. I'm confident there's a good solution. IIRC, there are public gun scripts somewhere, perhaps in the scripting library.
I believe that the only difference between your needs and say, a teddy bear script, would be that you're using an animation with priority 2.
-
leliel Mirihi wrote:It has nothing to do with OpenGL, it's a fundamental limitation of raster based graphics. Alpha blending is anorder dependentoperation. That means that to properly draw the frame you have to sort every alpha pixel into the correct order before composition the final image.The current best known algorithm, A-buffers, requires DirectX 11 class hardware and can potentially use several hundred megabytes of vram to draw the image. The average resident of SL simply does not have that kind of hardware. That's why LL hasn't bothered to do anything about it yet.
Thanks for this important clarification! The problem isn't the API (OpenGL), it's the underlying algorithms. Alpha sorting is a very difficult problem, and the best-looking solutions require a lot of horespower. Currently, the practical solution is to avoid the problem.
I was unaware of the "1-bit alpha" workaround, which would be very helpful if it works in SL.
-
Doesn't the dot move based on cam location, as your nametag does? That is, if 3 people are looking at you from different distances, they'd see the dot in 3 different places. If this is true, then what you want to do isn't possible -- though you might be able to get close enough, for your own cam and people nearby.
Of course, the point about the animation is also important: any attached prim will move with the animation, whereas the dot doesn't.
I suspect that unless you make the prim very large, what you're trying to do isn't possible.
-
Dogboat Taurog wrote:you are on my banned list now.
Now you're on mine ;-)
PS: A security device needs no more than one prim. Your 10 second orb is downright rude, unless it's set up where it would be impossible for anyone to enter its zone by accident. Zedd Zeddmore's orb is L$100 and has all the features anyone would want.
You blame the need for an orb on tresspassers, but your need is equally attributable to your own desires. You have the right to buy land you can set up ban lines on. You have the right to use a security orb. You have the right to put people on your ban list. But do you have the right to expect everyone to share your values? I say you do not, even though your values may be perfectly reasonable.
-
The "answers" section is for questions.
To find answers, look elsewhere.
;-)
Seriously, I don't see much use for the "answers" section. For one thing, it's not possible to read the whole question, or even enough of it to see whether I can answer it, with the current (awful) layout where subjects are truncated so short. Furthermore, it's not divided into general areas of expertise. As a result, it's rather tedious to wade through looking for posts where I can help.
It may be easy for those asking questions, but it doesn't support people who are interested in providing answers in specific areas -- or more to the point, *not* interested in questions in a number of different specific areas.
Hopefully, I'm wrong, and the Answers section turns out to be useful for general questions where the asker can't find more specific forums on which to ask.
-
Friends don't let friends use "drop" !!
It is sometimes useful, but I sure wish they'd put it on the second pie rather than the first one. It sure leads to a lot of litter in buildable public spaces. Sigh!
-
A typical sit script (e.g., poseball, or sit-target-positioner script that remains resident) doesn't provide a menu. When would the item be offered? Each time you sit?
I suspect that what you want for the non menu case is a click-to-give-item script. It would be different from the MLPV2 give-item script.
Note that the MLPV2 give-item script won't work with old MLP, but only with MLPV2. Let us know if you need to upgrade from MLP to MLPV2. It's easy.
-
Thanks, Ella. So, there IS a checkbox -- they just ignore it???
grrrrr
Facebook
Instagram
Twitter
YouTube
Flickr
Improvements to Second Life Random Ideas.
in General Discussion Forum
Posted
Most of the problems (griefing, copybotting, content theft) would be dramatically minimized by requiring identification (e.g., by requiring payment info) for all NEW accounts.
LL seems to be pretty committed against this idea, so there's little to be done about the problems. When actions are not attributable to individuals, there's no way to prevent repeated bad behavior. There is no technical solution to copybotting. Policing it properly would be too labor intensive.
Regarding adult status, LL does what it needs to do to cover its legal derriere. The current system evidently does that. Don't expect more: it would cause a lot of upset (as the Adult system did when it came into being), would cost LL more, and wouldn't really work anyway. The current system is a sham, but there's really no foolproof system in place, so we hide behind a sham.
Now, FEET, there's a place where improvement is feasible!