Jump to content

Zagnut Avedon

  • Posts

  • Joined

  • Last visited


1 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I can't help being curious as to why you "decided you didn't like it" (premium membership) after only 10 minutes... what, exactly, where you expecting from it?
  2. I'm not sure there's enough information here to answer the question... Is this an edit-able object that you're trying to apply a different texture to? If so, [CTRL] [ALT] [T] activates "highlight transparency"; faces with transparency will acquire a red tint to them. From there, it depends on why the face is transparent; it might either have a texture that's fully transparent to begin with, or it might have its transparency (alpha) set to 100%. (You can tell by looking at the texture panel in the edit window.) Either apply a different texture, or change the alpha back to 0%. If this is a scripted object, and you want it to turn transparent (or not) in response to some conditions, then it depends on whether you can edit the script or not.
  3. Ah, fair enough then -- I haven't yet come across a v4-based OpenCollar, so I hadn't realised they'd changed it that drastically. (And honestly, it rather sounds as if they've over-complicated the issue if it's that dependent upon specific prim link numbers...)
  4. Dora's got the right idea. If I recall correctly, the OpenCollar scripts only work right if they're in the root prim. When you link multiple objects, the last prim clicked becomes the root. Try this: (1) Rezz the collar on the ground. Edit it, and take note of which prim is surrounded by the yellow halo -- that's the prim you want to keep as the root. (Many OpenCollars have the "root" as a transparent sphere near the front, I've found, so you might need to use the "view transparent objects" trick to keep track of it.) (2) Rezz the other objects you want to link to it, and position them as needed. (3) Now -- do the "select multiple objects" thing by shift-clicking each add-on object in turn first, and then shift-click the collar. Do not click the "LINK" button yet! (4) Set the "edit linked objects" checkbox in the edit panel, so you can select and unselect individual prims in the linked object (i.e. the collar, in this case.) (5) Now -- shift-click the collar's root prim, and only the root prim, from step (1), to de-select it. Then, shift-click it again to re-select it. (6) Now hit the "LINK" button in the edit panel. If everything has gone according to plan, the prim that was the yellow-haloed root in step (1) should now be the yellow-haloed root of your newly-linked collar again. (7) Reset the scripts in the collar. It should now function properly.
  5. I should think that any proper combat sim should have some kind of information kiosk or vendor at the entrance point where you can obtain whichever tools or HUDs are required for use within the sim. (Well, unless it's a "closed" environment where they aren't accepting new players, or only accepting them by direct invitation, perhaps.) When someone just pops into the forums here and randomly asks "where can I find one of those cool toys that lets you throw other people into the air", most are going to immediately assume that they're asking about an "orbiter", or some other griefing-tool toy that would let them run around SL throwing people into the air at random. Unfortunately, that sort of thing is far more common than combat sims. If it is a combat-sim-specific HUD or weapon you're looking for, and the sim in question hasn't got an obvious information kiosk at the entrance point, then Sasy's advice is sound; you'll most likely need to ask the participants in that particular sim as to which tool(s) are being used and where to get them. There is, unfortunately, no "universal" kit that works (or is allowed) on every such sim; different sims use different systems.
  6. No, love, you really don't want one. They're called "griefing tools", and using them is an abuse-reportable offence that can get you banned from SL.
  7. The inventory servers are having trouble right now; LL has been "performing unscheduled maintenance" since about 9AM (SL time) this morning, and it looks like they're still at it. You won't be able to do much of anything (at least not reliably) until they get it sorted, I'm afraid.
  8. They're "performing unscheduled maintenance", which in plain English means something (most likely the asset servers) are buggered up again. http://status.secondlifegrid.net/
  9. The answer is, "it depends." If I understand your example correctly, you have the region carved up into four sections -- three "residences", each with 1000 prims allocated to it, and then a fourth "public commons" area that has the remaining 750 prims available to it. Correct? If so, then it depends on where the boats are arriving. Once a region is carved into parcels, each parcel's prim allocations apply only to objects within that parcel space. (Or, more specifically, objects whose root prim is within that space. Technically, an object such as a large waterfall or other landscaping object can span multiple parcels, but only count against one parcel's prim count.) So, if the boats arrive in the public-commons area, then they count against the 750 prims in the common space, not against any of the residence spaces. If they arrive in one of the residence spaces, then they count against the available prims for the particular parcel they're in. If they cross from one parcel to another, then they also count against the prims for the parcel they've moved into. That being said, vehicles can be a bit dodgy when it comes to the prim rules. If the vehicle is being worn as an attachment, then obviously it doesn't count at all -- and if memory serves, as long as the vehicle is being sat upon and driven by an avatar, then the sim considers it a "temporary" object, and it comes out the sim's pool of "reserve prims" rather than out of the actual parcel prims. (In which case, you should only get the "region full" message if the region has used up all of the temp-prim capacity as well.) I do recall there was a bug about this a while back, where vehicles were being erroneously counted against the parcel limits even when being sat-upon, though I think it's been fixed by now... However, if the AV dismounts the vehicle, then (again, if memory serves) it becomes a "real" object and its prims count against the capacity of whichever parcel it happens to be in at the time. (And if the owner of the parcel has it set to not allow anyone other than themselves to build on that land, or if the build rights are set to "group only" and the owner of the vehicle isn't a member of the group, then the vehicle will be immediately derezzed and returned to the vehicle owner's "Lost and Found" folder with the usual "cannot rezz object on this parcel because the owner does not allow it" message.)
  10. Unfortunately, no, this is not possible. A script can only detect whether another object or avatar belong to the same group as the object containing the script -- and in the case of avatars, it can only detect this if the avatar in question has that group active at the time. There is no means for a script to acquire a list of what groups an avatar belongs to, or to test if an avatar belongs to a specific group other than the one the avatar currently has active. There's definitely no provision for a script to determine exactly which group role or title the AV is wearing. In other words, if you have a group called "MyGroup", with roles of "Overlord", "Underling", and "Minion", then an object which belongs to "MyGroup" (either because it was rezzed on land belonging to "MyGroup", or it has been set to "MyGroup" via the edit window, or it's being worn by an avatar who currently has one of "MyGroup"'s tags active) can only determine whether an avatar that tries to interact with it (by touching it, colliding with it, etc.) is currently wearing a "MyGroup" tag -- it can't determine which tag they're wearing (i.e. it can't tell if they're an "Overlord", an "Underling", or a "Minion"), and it can't determine if they're a member of "MyGroup" if they're currently wearing a tag from a different group, or no group tag at all. If they're not wearing a "MyGroup" tag, the script will behave as though the avatar in question is not a member of the group.
  11. Unfortunately, animation priorities are not something which you can change. The priority level is "baked" into the animation at the time it's uploaded into SL, so if your "walk" animation has a higher priority than the "handcuff" animation, it will always override the handcuff animation. (Same goes for "stands", "sits", etc.) There's no setting or script function which will allow you to change an animation's priority. The only fix is to either find a walk animation with a lower priority, or replace the cuff animations with ones of higher priority. (Or turn off your AO whilst wearing the cuffs, but that's probably not an ideal solution.) Or, use a better set of cuffs. Basically, the OpenCollar ones "fail" in this way partly because of the priority levels (I'm pretty sure most of those free anims are not priority-4), and partly because they don't re-assert the cuffed animations; they just fire a single llStartAnimation() when you engage the pose. The issue here is that even if the two different animations are of equal priority level, the most-recently-played one "wins" -- so, if your "handcuff" pose is priority 4 (the highest officially supported, though supposedly it's possible to "hack" a priority 5 with certain 3rd-party animation-creation tools), and your "walk" is also priority 4, then as soon as you start to walk, the "walk" animation wins and overrides "handcuff" because it was played more recently... but the cuff script doesn't know this, so when you stop walking, the "handcuff" pose is not reasserted; as far as the script is concerned, you're still in the "handcuff" animation. Better cuffs, such as the Mesmerize Dungeon models, not only have their animations all baked at P4, but the script frequently reasserts the selected animations to insure that its own animations are always the "most-recently-played" ones and that any walks, sits, etc. from other AOs or furniture are continuously overridden. They're a bit costly (although let's be honest, L$800 is only a bit over 3 US dollars ... or £2, or not quite 3 euros, or a bit over 4 dollars Australian or Canadian, so in "real" money, they're still fairly cheap; a takeaway coffee and donuts will cost you more than that!), but they work a treat in keeping your arms from flailing about when you're supposed to be cuffed. If you're really on a tight budget, then Bondage Witch Project has a set of free (non-Opencollar) ones that work fairly well, although I hesitate to recommend them because they've not been updated in ages and are script-heavy as hell.
  12. A forum post is about as far from "contacting them directly" as you can get. What makes you think Rodvick even looks at these forums, much less takes them seriously? You want his attention, Amethyst's suggestion is the only way to go. Registered letter, via physical mail, return receipt requested. Anything else will just be ignored.
  13. I don't think that's quite what the original poster had in mind, though.
  14. As far as I know, unless it's been changed very recently, a vehicle cannot have more than 32 prims, total. (That's actual linked prims, not the so-called 'prim equivalency', in case you're dealing with mesh stuff.) And, again as far as I know, each avatar sitting on it counts as one 'prim' -- so, for example, a 2-person jetski can only have 30 actual linked prims at most, since you need to keep two aside for the seated avatars. It's been a long time since I've tangled with vehicle scripts, though.
  • Create New...