Innula Zenovka

jjccc Coronet wrote: on the latest firestorm viewer you can drag your AO into the menu bar at the bottom In rather more detail:

What the others said. And, if you're building the dialog button list on the fly, as I often do, with something like list buttons = llList2ListStrided(my_list,0,-1,stride_length); use llOwnerSay to check that list buttons is what you think it's going to be -- most usually when I see that error message it's because I've messed up building the list somehow.

A bit of poking round in the archives took me to this thread, where I found Void's solution and adapted it to give me this: default{ touch_start(integer num){ float baseNumChairs = 8; //-- for example, float because we'll need fractional angles vector baseOffset = <1, 0, 0.5>; //-- distance chair is rezzed from center of table rotation baseInterval = llEuler2Rot( <0, 0, TWO_PI / baseNumChairs> );// inteval in degrees for the next chair integer counter = (integer)baseNumChairs; rotation currentRot = llEuler2Rot(<0.0,15.0,0.0>*DEG_TO_RAD)*llGetRot(); vector currentOffset = baseOffset * currentRot; do{ llRezAtRoot( "Object",llGetPos()+ currentOffset, ZERO_VECTOR, currentRot, counter ); currentOffset *= baseInterval; currentRot *= baseInterval; }while (--counter); }} With a bit of tweaking it should do what you want, I think

I wasn't saying that you should use V2 if you don't want to. My point was, rather, that we've now proved that LL's servers and your computer can talk to each other and load your inventory perfectly well in V2.6 and Firestorm. That doesn't explain, I agree, why you're having much greater problems loading your inventory with Phoenix, Imprudence and so on than are many people using those viewers (my inventory loads ok most of the time with Phoenix), but it seems to me to suggest that, whatever's causing things to hang and stop, it's something at your end, because clearly the issue isn't there when you use something with the new inventory api. So that's where you need to look, I think.

Georg Stonewall wrote: The previous speaker are right, it's easy to destroy a prim attachment when modifying it, but that is not really a big deal. We sell transfer/no copy for over 4 years now and if someone has messed up with a prim then they sent it back to us and we replaced it. I know most merchants will happily replace transferrable items if I mess them up while editing them, but I still feel a lot happier working on copyable ones, if only because I know that if I wreck it -- and I still worry about wrecking stuff even though I know I'm pretty competent and careful builder by now, and don't normally mind making minute adjustments to complex items -- that I just junk it and start over, rather than have to drop a line to the creator and maybe not get a reply for a couple of days, because obviously I don't expect makers of clothes to be available 24/7 to customers any more than are scripters.

Try llInstantMessage(llGetOwner(), "TP TO: secondlife:///app/teleport/"+(llEscapeURL(llGetRegionName()) + "/" +"/" +(string)initPos.x + "/" + (string)initPos.y + "/" + (string)initPos.z + "/") ); I can't in to test it, but I think that's how I solved an almost identical issue that was driving me nuts recently.

I'm really not sure what you're trying to do. I though you meant you wanted to rez several prims, one at a time, increasing the rotation on the local z axis each time you rez one. If that's what you're doing, you just have the script alter the z component of vector_rot each time you rez one. But it looks like I misundertood.

LoveAngeL Lyre wrote: As already mentioned when you "destroy" 1-2 no copy outfits trying to fit them or by another reason, you will understand why most brands have copy but no transfer products. On the other side several famous brands (this moment i have "Avid" in my mind) offer transfer but no copy products. Yeah, and they can get away with it because they make such gorgeous clothes -- nevertheless, I buy far less from Avid than otherwise I might, precisely because I know they'll need a lot of adjusting and, even though I'm pretty good by now at making small adjustments to prim clothing, I'm still scared I'm going to trash my lovely new dress or coat. I still wince at how much I blew on Avid stuff when I was less experienced with the editing tools and wrecked while trying to fit it, so I never got to wear it.

Finrod Ghennyn wrote: It is not possible to change item properties, but with a little work you can make the vendor sell individual versions. Copy only version, mod only version etc.. Yeah, it's simple enough to make that. I would think most of any extra work involved would come from dealing with customers who find they've bought the wrong version and want a replacement -- simple enough if it's transfer/no copy, less so if they tell you they wanted a transfer one but bought a copy/no transfer one by mistake.

koto Nizna wrote: what if a well designed script that will changed the permission of the object from copy to trans and then the script will automatically delete all the copied item of the said product? I think it's possible. I wish i'm a scriptor genius lol I'm not a "scriptor genius" but I am reasonably competent scriptor and I know it's not possible in LSL, I'm sorry to say. Scripts can't change asset permissions (unless, maybe, you're a Linden in god mode).

If I have properly understood you -- and I am not sure that I have, but I'm taking you to mean you want the stiff edge of the flexy at the bottom, with face 0 (if it's a box) uppermost and at a 15 degree angle, then I would start with something like this: integer start_param = 9;rotation rot;string object;vector offset = <1.0,0.0,1.0>; //1 metre in front of the rezzer and 1 abovevector vector_rot=<15.0,0.0,0.0>; default{ state_entry() { rot = llEuler2Rot(vector_rot*DEG_TO_RAD); object = llGetInventoryName(INVENTORY_OBJECT,0); } touch_start(integer total_number) { llRezAtRoot(object,llGetPos()+offset*llGetRot(),ZERO_VECTOR, rot * llGetRot(),start_param); }} and then adjust the z component of vector_rot to alter the rezzed object's rotation round its local z axis.

Jaffee Gaffer wrote: FYI, I installed LL V2.6 viewer yesterday. It did manage to load all the inventory, although very slowly. I tried Firestorm, just for kicks, as well and it failed. It loaded around 43,000 items out of about 68,000 total. That suggests to me, then, that it's to do with the viewer. Your inventory is there, and can be retrieved by 2.6. Try reloging with 2.6 and see how long it takes to load now it's had a chance to be cached locally. Also, you might want to try the new Firestorm Beta, released yesterday. It's based on 2.5, so it includes the new method of fetching cache.

It might be worth, nevertheless, trying V2 or a TPV based on V2.5.1 or higher (Dolphin, KirstenLee's or Marine's, but not the current Firestorm, then, but the new version when its released as a binary) and seeing if the new Inventory API makes a difference: https://wiki.secondlife.com/wiki/Linden_Lab_Official:Inventory_API Certainly I noticed a big difference in how fast and reliably my inventory loads after it was introduced. ETA -- looks like the Firestorm Beta will be released later today. That's based on newer code and I'm assured by people who've test-driven self-compiled versions that the new Inventory API works well in that, too.

Hector Greenspan wrote: Also, there just happens to be a function called llPassTouches() If you set this to FALSE, touches do not propagate through the object in question. Can often save adding more scripts to an object! 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

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 have a) (allegedly) already leaked user's information to it's related companies for spam purposes, and b) 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?