Innula Zenovka
-
Posts
10,793 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Innula Zenovka
-
-
I don't know if this is the answer to the question, but one common "gotcha" when making things that need to respond both to the owner and the owner's hud is saying
default{ state_entry() { llListen(99,"",llGetOwner(),""); } listen(integer channel, string name, key id, string message) { message = llToLower(message); if(message = "sheath"){ //do something } }}
That doesn't work when the hud says "sheath" because, of course, the hud's uuid isn't the same as yours.
Instead, you have to say something like
key owner;//declare it as a global, because you don't need to check it all the timedefault{ state_entry() { llListen(99,"","",""); owner = llGetOwner(); } changed(integer change) { if (change & CHANGED_OWNER){ owner = llGetOwner(); } } listen(integer channel, string name, key id, string message) { if(llGetOwnerKey(id)==owner){//is it a message from my owner or something belonging to my owner? Avatars own themselves in according to LSL message = llToLower(message); if(message = "sheath"){ //do something } } }}
That's going to work whether the command comes from the avatar or the avatar's hud.
-
Phil Deakins wrote:I haven't thought through the idea of restricting all transfers to indentifiable people, so I don't yet have an opinion about that.
NPIOF Resident: Hi, sorry to bother you, but I bought a low prim widget in your shop out of my earnings as a dancer in a club here, and it doesn't seem to work.
Merchant. That's OK, since it's transfer -- just send it back to me, and I'll send you a replacement.
NPIOF Resident: Ah... that may present a problem..
-
You really do need to think carefully about this one. You can discover what clients people purport to use (it can be spoofed) provided that they have their viewers set to receive parcel media, by using exactly the same method RedZone used before it and its creator were banned. The problem is that it exposes people's IP addresses and can be used to link them to avatars' uuids, thus outing people's alts and potentially revealing more information about you, too. So if you do make something that does this without actually asking people to cooperate, you risk a lot of complaints from GreenZone and others, and a flood of ARs.
OK, you're just using it to collect anonymous statistics about viewer use, but people using TPVs with the Parcel Media Filter turned on (a feature that's slowly working its way into the official viewer, I think) are just going to see an unexpected attempt to load a url that doesn't look like a music stream and are naturally going to assume the worst.
-
Yeah, in V2, Dialog menus don't stack any more -- https://jira.secondlife.com/browse/STORM-522 -- which breaks some older content.
I don't think you actually lose the menu; the ones that are overwritten seem to vanish down to the bottom right of the screen with all the IM notifications and so on, but if you're not expecting multiple menus (or even if you are) it's very easy to miss them.
-
Constance Flux wrote:It's amazing that Linden Lab allow NPIOF residents to build and sell at all. They are not accountable for their actions and some of them are thieves, copybotters and cause more trouble than they're worth
Almost everyone is NPIOF when they start, of course, and, while building and scripting were two of the main things that got me hooked on SL, I had no idea how to do either when I started, let alone that I'd enjoy doing them, and I'm not sure I like the idea of having to be PIOF in order to particpate in two core activities of SL. To sell stuff in the marketplace, yes, but not simply to be able to build stuff or pass it to friends.
-
I'm not sure that relogging on a Linden sim after manually deleting your cache is a good idea any more, or has been since almost all, if not all of, the Linden sims started running on one or the other release channels. Some of those certainly have had problems fetching inventory in the past, and the fact that a release channel server version is fetching inventory without problems this week is no particular guarantee that the version they roll out next week won't have issues.
I switch between viewers very frequently -- often several times a day -- because I make quite complicated scripted items, often involving RLV, and I need to make sure they work in all the viewers people are likely to be using with them. I keep separate cache locations for each viewer, and all I can say is that the new inventory fetching system introduced in V2.5 made a big difference, at least for me, in how fast and how completely my inventory loaded, and things got even better with 2.6 (I think the new Firestorm, expected in the next week or so, uses the 2.5 codebase, so it'll be interesting to see how that works out).
When I'm using V1-based viewers, I certainly do encounter problems still, and most definitely far more frequently with Phoenix than with Cool VL or Singularity, but nothing that manually deleting my cache and relogging on a quiet Island sim running on the main server channel doesn't fix, at least for a week or so.
As to why Jaffee is having all these problems, having tried everything, I just don't know. Why am I not experiencing them? Do LL maybe keep people's inventory on different server clusters, and I've just been lucky with the ones where my and my alts' inventory is based?
-
Arkady Arkright wrote:Regardless of the principle involved here, non-USA residents have a problem with the mechanism for PIOF.I was both Premium and PIOF until SL handed their payment collection over to a gambling house; subsequent events reported on these forums and others have persuaded me to revert to Basic and remove my payment info until SL demonstrates considerably more competence and trustworthiness in this area.I'd like SL to provide a non-USA payment system which actually works well for at least 6 months (without it refusing legitimate payments, causing the banning of innocent residents and deletion of their inventory, leaking personal data or being acknowledged by SL themselves as a Beta-test using live data) before I go back to PIOF.It's a simple matter of confidence. I don't currently trust SL with a payment system which, for non-USA users, is actually a gambling company located in a tiny British colony (Gibraltar)., which would appear to havea) (allegedly) already leakeduser's information to it's related companies for spam purposes, andb) required users to send them photocopies of both sides of their credit card before they'll take their money.
Since Dragonfishtech.com, the payment handlers, are subject to EU data protection law and EU gaming regulation,as are their owners, 888.com (who are a UK company), and many of their customers -- e.g. Littlewoods Pools, a name that will mean something to Brits, if to no one else -- they're subject to a much tighter compliance regime with their data handling than is LL or most other US companies, and have considerably more to lose if things go wrong. If something goes wrong, both Dragonfish and Littlewoods are subject to criminal prosecution in Gibraltar and the UK respectively, as are senior managers in both companies, and risk losing their business altogether because they'd be putting their gambling licenses at risk by breaking data protection law. I'm pretty certain, too, that Dragonfishtech have considerably more experience, because of the nature of their business, in dealing with online fraud attempts.
The fact that LL has chosen them doesn't really tell me much. However, the fact that, for example, Littlewoods and Racing Post use them gives me a great deal of confidence because I know they'll have had to do the necessary due diligence checks.
If I did the pools I would be far less worried about giving Littlewoods' appointed agent my credit card details than was I about giving my details to an unregulated American company like LL, because I know there are robust legal protections in place in the EU (which includes Gib) to protect me, and because I know Littlewoods have a great deal to lose if their agents foul up.
-
Qwalyphi Korpov wrote:It's unclear from the write up how the policy achieves it's objective via payment info.
It will serve to hamper the activities of people who use a succession of throwaway alts to put ripped content up for sale at firesale prices on the marketplace on a Friday and can normally expect to enjoy a couple of days' unjustified income before anything much happens. At least they won't be able to do it with mesh.
And it also provides a disincentive in that LL will have some RL names and addresses to give to Turbosquid's lawyers when they phone up asking whose life they should make difficult for a bit.
-
Domitan Redenblack wrote:Ah, yes, but suppose the separator is a Region name? With say 22 letters? "Sub-Antarctic SnowZone" etc
Could you give us an example of a typical string you would like spitting into three list entries? It may be possible to discern a pattern there you haven't noticed.
-
Randall Ahren wrote:Don't you get texture lag from particles?
Particle textures, like the textures on buildings, your clothes and stuff, take time to load. There's nothing special about textures in particles, except it's normally far more noticeable when a texture for a particle is loading than when it's a similar texture on one of the unscripted gems in my earrings. And it's only one texture, normally; a particle emitter can only emit one type of particle at a time, so even if it's switching between different textures on a timer it's not usually going to be loading more than two or three.
Having said that, people do often use unnecessarily high resolution textures in particles. But -- unless Void disagrees, in which case I'll defer to her because she knows considerably more about scripting than most of us, and certain more than do I -- I'd say that particles aren't a particular cause for concern.
-
Do you notice any difference between viewers? For example, as I understand it from TPV devs, V2's inventory fetching system changed dramatically in 2.5, and I certainly noticed a big difference then, too -- my inventory loads far faster now in 2.6 than it did a few months ago, and when I'm using Snowglobe-based TPVs, it's always loaded slower in Phoenix than in Cool VL or, more recently, Singularity.
Could there be something else running on your computer that's causing the issue? That might be the common factor between you and the other people, in different parts of the world, who've told you they have similar problems.
I take your point about how you've tried all these different things, but the fact remains is that here's me in the UK, with a decent computer and cable connection, but neither as good as yours, and I'm not having anything like the problems you describe. And neither, I think, are any of my friends, whether in Europe, the USA or Asia. If they are, I'm sure they'd have mentioned it by now. So, whatever's causing the problem, it's clearly not a general one.
What do you think it might be -- some people, including you, have had the misfortune to have their inventory permanently stored on a dud server (no idea if that's a conceivable reason) or what?
-
Medhue Simoni wrote:So, what happens when you are not using a version that has a Starlight set for it? I tend to use alot of project viewers.
Dunno. Worst that can happen is that it doesn't work and you have to reinstall the project viewer, I guess. If in doubt, I'd check over at http://www.sluniverse.com/php/vb/viewer-xml-skinning/ , which is where Hitomi usually posts.
-
Void Singer wrote:also may depend on what else the scripts do, or might be caught in the middle of doing....
Very good point. In this instance, all they do is sit and wait either for people to touch them or for other units to poll them, so in practice I don't think they're likely be caught doing much. They rez a teleporter disk once you've selected your destination and then wait for the next person to happen along.
-
I'm working on an in-sim tp system which works like this -- user touches a unit, unit polls all other units on the sim with the user's uuid, using llRegionSay(), other units check the uuid against their access lists and settings, and, if the user is able to access that particular unit, replies, using llRegionSayTo(), to the unit that's initiated the inquiry.
That unit then builds a list of destinations the user is allowed to access and presents him or her with a menu.
Obviously, I don't know in advance how many units there are or how many are likely to reply.
How long should I wait before I generate the menu of possible destinations? In testing, anything over 2 or 3 seconds seems a very long time, but I've no idea what's likely to happen -- and neither am I really in a position to find out by experiment -- on a laggy sim with a couple of dozen units.
-
I wouldn't normally suggest this sort of thing, but my business partner and I recently looked into setting up a web-based updater for our products. We rapidly came to the conclusion that, while it's the sort of thing I could do if I did a bit of research and asked here and in-world for help on anything I didn't understand, since we both trust Andy Enfield and Hippo enough to let them run our affiliate vendors, and since buying Andy's system (which he maintains) involves a one-off payment of a few hundred L$, it probably makes more sense from a business point of view to buy a solution rather than make our own.
Like I said, I wouldn't normally suggest buying something rather learning how to make it yourself, but, at least for me, it's the sort of specialist thing for which I'm only going to make time to learn when I've got a project about which I'm enthusiastic that really requires it.
-
Medhue Simoni wrote:Those are neat, but it really needs to be an option in the viewer. Or possibly, you drop the xml in the right folder and can put as many as you like, and they come up in a drop down window when you log in.
But that's pretty much what you do do. Dowload the skins from the link given at https://wiki.secondlife.com/wiki/Viewer_Skins/Starlight and unzip them, and then drop two folders into your V2 folder, and say "Yes" when it asks you if you want to overwrite existing files.
Then you get this at log in:
There are a couple more optional tweaks that involve copying other individual files to particular subfolders (if you want vertical tabs in the IM window, for example) but the basic process really is pretty straightforward.
ETA: If anyone's interested, the unofficial Starlight forum is http://www.sluniverse.com/php/vb/viewer-xml-skinning/ -- it's not just about Starlight, but it's a very good place to ask Hitomi questions.
-
Randall Ahren wrote:Penny Patton wrote:
AO sets with high numbers of animations lead to latency issues, too, since every new animation needs to be streamed to every avatar around you.What about dancing? Practically every club or hangout place has a dance ball. Doesn't streaming the dance animation to every surrounding avatar cause substantial lag? Couldn't clubs eliminate a lot of lag by getting rid of the dance balls?No, it doesn't. All the sim does is send a small file to your PC, and your graphics card and cpu make all the people dance. It actually puts a lot less strain on the sim resources to have people dancing (particuarly if they're using dance balls) because, as far as the sim is concerned, you're just standing or sitting there not doing anything. You're using a lot more resources by walking round.
If you think about a normal club, you might have a lot of people dancing, but most of them are doing the same few dances.. if they''re all walking round, probably most of them have got different anims in their different AOs to be sent to your PC.
-
Medhue Simoni wrote:Luc Starsider wrote:Oh, and I want different skins for the viewer, supported by LL.- Luc -
Yeah, I can't really understand this. How long does it take to make a new skin? They could even ask people to make them and add them as options. It's a minor thing but it makes many people feel more attached to their viewer.Don't we, in effect, have that with Hitomi Tipomi's Starlight Skins? I find they make the viewer far more usable.
-
How about disabling scripts in the region (or make a small parcel, 4x4, containing the object, and disabling scripts in that), and then trying to delete the thing? I've had that problem before with temp rezzers gone nuts, and that's how I fixed it in the end.
-
Best of luck. If you may have dropped it on a private sim, the sim owner (or anyone with estate manager rights) should be able to locate it for you using the estate tools and simply return it to you, if you tell them what it's called.
-
I'm not that familiar with the Dominatech Relay, except I know it's a very good one, but I know -- at least I think I do -- what the issue is.
The only reason you're seeing that is that you're not using RLV. It's the relay asking your viewer if you're sitting on anything and, if so, what the uuid of that object is, and telling it to reply on channel 1827504366.
If you were using RLV, you wouldn't see it, unless you had RLV debug messages turned on, because the viewer would intercept it and process it silently by sending the relay either the uuid of the item or NULL_KEY if you're not sitting on anything. But since you're not using an RLV viewer, you're seeing a message that's not meant for you.
Solutions -- either enable RLV (with debug messages turned off) or take off the relay, which can't be doing much if you don't have RLV turned on.
-
1
-
-
To ensure the owner change after transfer, you just need another event:
changed(integer change) { if (change & CHANGED_OWNER){ llResetScript(); } }
-
By coincidence, someone was asking a very similar question yesterday over in the Scripting Tips forum (different error messages but the basic issue's the same). Rather than repeat all that was said there, I'll direct you to the URL -- Rolig Loon explains how to look for the item: http://community.secondlife.com/t5/LSL-Scripting/Help-Please/m-p/914243#M2804
-
1
-
-
That's why I said I don't understand the sequence of events, and I do know a bit about scripting stuff to animate avatars.
Quite simply, you cannot have deleted the AO because, if you had, it wouldn't be able to complain about not having control permissions. Nor do I understand how one AO that's not working -- as the problematic AO cannot be, because it needs control permissions so to do -- can possibly affect another AO that is working. And there is no way that it can be doing anything at all to you if you're not on the same sim.
And deleting it from your inventory will have made no difference one way or the other -- you can only be getting error messages from it if it's rezzed somewhere in world, and from what you describe I very strongly suspect it's rezzed somewhere on the ground. That would explain an awful lot, other than why your other AOs aren't working on other sims.
That is a bit of a mystery, I agree, because there's no way for a scripted object to affect your viewer settings like that, unless you're using RLV, and nothing in RLV can tweak any settings that would affect your AOs. In fact, I'm not even sure what debug settings would -- I am sure there are some, but I have no idea what they are.
Is there anything else you did while trying to fix this problem? First, what viewer are you using? I ask because there's some settings in Phoenix that I think might disable all AOs if injudiciously applied.
Facebook
Instagram
Twitter
YouTube
Flickr
question: Touch Event
in LSL Scripting
Posted
Are you sure about that? According to the wiki, it's so that a prim containing a touch event doesn't pass the touch back to the root as well as doing whatever its own script has to do with the touch. The wiki has the caveat,
This has no effect (whether set TRUE or FALSE) from the root. Touches are always passed to the parent when there is no touch event script in the child, even if this is set (TRUE or FALSE) within another event in a child's script. If you want to block touches from a child , you must add a script with a touch event in the child. This creates a default no passes.
https://wiki.secondlife.com/wiki/LlPassTouches