Innula Zenovka

Try setting a new cache location for Firestorm, separate from the Phoenix one. It's going to take a while to load the first time, certainly, as it does any time you set a new cache and it has to fetch everything from the server, but after that it should be dramatically easier to load your inventory than with older viewers. I'm surprised that you say V2 doesn't work on your computer. I'm open to correction but as far as I know, anything that can run Phoenix can also run Firestorm or the official viewer, unless, maybe, it's a very old computer indeed.

You might want to have a look at this thread over in the server forum. Short version -- try the current V2 or the latest beta version of Firestorm. These incorporate a new method of dealing with inventory loading that's far faster and far more efficient than that in Phoenix or any other Snowglobe-based viewer.

In that case, I'd start by looking at the user function at http://wiki.secondlife.com/wiki/LlGetGMTclock That turns the time into strings, but it shows you how to do the calculations to turn the GMT clock time into hours and minutes, allowing for local time zones, so you can adapt that reasonably simply, I think. I would then have it calculate how long it is until the next top of the hour, and set a timer event to fire then. In the timer event, I would check what o'clock it was, use that to set the initial value of integer oClock and then use that to look up in a list what sound to play, and play it. Then I'd move to state running, where I'd set a timer event for an hour hence in state entry. Then just advance oClock by one every hour and play the right sound, resetting to 0 after midnight.

Great -- I'm so glad it worked for you. It certainly looks a lot better. The bracelets you won't be able to resize if they're no mod, I'm afraid (which is one reason I take a lot of persuading to buy no-mod clothes). But I'm so glad you've got the editing to work.

Your friends are either ingenious hoaxers or labouring under a massive misapprehension. LL is certainly not banning Singularity, or any other legitimate TPV. What they are doing, and this may have lead to your friends' confusion, is developing the SL server code with V2-based viewers in mind, and if this breaks functionality in V1-based viewers, like Phoenix or Singularity, then it's up to the the developers of the TPV to patch their viewers to accommodate the new code.

Depends where you and your ex are located in RL. In the UK it would be simple enough -- take the matter to the police, and charges under (at the very least) the Protection From Harasment Act would almost certainly follow.

Jump onto a pose stand (not vital, but it helps a lot since it immobilises you), select the item and bring up the right click context menu. Even if "Edit" seems to be greyed out, click it anyway -- sometimes the option is greyed out because you can't modify the object (e.g. resize it or change the texture), but you should always be able to reposition it. If that's a problem, bring up the Edit menu by clicking CTRL 3 before you try to select it -- that opens the edit window. Other useful shortcuts to know are CTRL 0 ( zero, not the the letter O) to zoom your camera in on the item once you've selected it, and then CTRL 9 to restore the normal view when you've finished. ETA -- I'm assuming you're logged in using "Advanced" mode.

Another major difference is that LL is unlikely to hire jcool (AKA Fractured Crystal) to work on their official viewer.

I agree with bee -- it looks to me, at first sight, more like a problem with positioning than anything else. Minor tweaks to the object's rotation can often make a great difference (for better or worse). I normally expect to spend quite a bit of time adjusting necklaces. But very rarely, and only as a last resort, do I try to modify the necklace itself, as opposed to its position and rotation, simply because that is pretty tricky even if you are used to working with SL jewelry. And it's rarely necessary with things like necklaces, I find. When adjusting stuff with V2, remember that CTRL-Z (undo) is your friend!

Ceera's is at http://forums-archive.secondlife.com/54/3a/234842/1.html I know this only because I was recently very pleasantly surprised to learn that Mssrs Google finally seem to be able to find their way round the old archives.

Trial and error mostly, in my case. I found it helpful to start by seeing what the various free full perms Phoenix ones did, then, starting with one I liked as a base, tweaking the various parameters to see what works and what doesn't. In my experience, at least, you really do need to experiment quite a bit -- what looks OK when you're walking about can look really odd when going up some stairs, for example.

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