Jump to content

Innula Zenovka

Advisor
  • Content Count

    9,437
  • Joined

  • Last visited

Community Reputation

2,858 Excellent

4 Followers

About Innula Zenovka

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. Though if someone wants to ruin the experience of going round the spooky haunted house with their local lighting set to midday. then isn't that their problem rather than yours? I can see it being an issue in combat RP, where participants can gain an unfair advantage by tinkering with their settings and thus seeing far better than they should during a night attack, but is it such a big deal otherwise?
  2. Yes, but we're not talking about creating software here. We're talking about people using software to create things. One of the great reasons -- at least to my mind, and it's a view that's clearly shared by many -- that Bellissaria is so much more popular than the old Linden homes is precisely that it's an artisanal product, as it were, with each region built by hand, rather than a modular, mass produced, one like Horizons, which is built from modular and easily repeatable units. What you suggest would completely change the nature of the build, or so it seems to me, and risk losing, or at least compromising, one of the elements that makes Bellissaria so special and attractive for many people
  3. I would say that you and I are in exactly the same position, in that we both enjoy the same benefits and level of service -- we can both have a Linden Home if we want one and there's one available. The only difference is that you want one and I don't, at least not at the moment, but if I did, we'd be competing for one on a level playing field. Do you feel similarly aggrieved that that you can't find an affordable and vacant property in Bay City on which you could use your tier? Seems to me a comparable situation. Anyway, regardless of what you or I may think, the fact of the matter is that people who think that, after the price increases, premium membership is no longer worthwhile always have the option to revert to free membership. LL and the Moles are working as fast as they can to make more Linden Homes available, and doubtless they will in the no too far distant future. If you choose to (and if you're in a position to, of course) you could always lock into today's rates for up to a year if you extend your membership within the next few days -- whatever the deadline is -- during which time you'll be enjoying exactly the same facilities you have enjoyed previously as a premium member at exactly the same cost you have hitherto considered worth paying, and you'll have a whole year to try to bag a Linden Home. I guess I'm seeing the cup as half full and you're seeing it as half empty, but I don't think LL is likely to change its decision. If you don't think it's worth paying the extra or extending your membership, then you don't need to. If you decide to stick with it, then I wish you good luck with Bellissaria, and hope you soon find what you want there.
  4. I'm not quite sure I understand the example you're describing here -- I would need to see the door and the script to comment, and I must stress that while I do know something about doors and rotations, I don't know a great deal about making mesh. However, the basic scripting is quite simple, as are the constraints. By default, LSL rotations pivot round the centre of the object being rotated. The simplest workaround for when you need to pivot something on its edge -- a door, for example -- is to change the design of the object, by shifting its visual centre away from its actual centre, whether by path-cutting a prim or by manipulating a mesh door by adding a small hidden point offset from the edge of the door mesh, so it appears the centre of the resulting mesh object is, in fact, one edge of the visible area. If that's not possible (you didn't make the mesh) it's certainly possible, though rather fiddly, to offset the rotation by script, using a combination of llSetRot and llSetPos. That works for anything server-side, but not for llTargetOmega, since all its effects are client side. There's nothing you can do to fool llTargetOmega about where the centre of the object is. There's an added problem with llTargetOmega doors that, because that function is client-side, you also need to change the door's actual rotation, so the simulator knows what it is. Otherwise the door will seem open but you won't be able to pass through it because, while your CPU and GPU think the door should be drawn as open, the simulator thinks it's closed until the actual rotation is changed with llSetRot or similar. That can cause problems with scripted doors that use TargetOmega -- sometimes the way such doors are scripted mean that the door doesn't actually unblock or block the doorway until llTargetOmega has finished, which can be confusing. Typically I'll call llSetRot or llSetLocalRot several times on a timer while llTargetOmega is running, so the door's actual and represented rotations are always within 10° or 20° of each other, but not everyone bothers to do that, which can confuse users a lot. (I'm not saying that's the problem here.. just taking the opportunity to note it for future readers).
  5. While I understand your frustration, I think you misstate the position, I'm afraid. To my mind, all premium members continue to enjoy the same level of service as we did before, including the right to a new Linden Home should there be one available. I use my and my alts' premium membership to maintain existing mainland commercial properties, and I live on a private region, so Linden Homes aren't much use to me. However, should I decide I want one -- as I may do at some point -- then I can apply for one on the same basis as any other premium member. But for the meantime I'm not going to be using any of the extra benefits we've recently gained. That doesn't matter to me because I have become accustomed to the fact that companies have to raise their prices now and again, be it LL or my local supermarket or hairdresser or coffee shop, so I accept this as part of life in a free-market economy (I'm not yet so old that I spend my time complaining about much things cost nowadays compared with when I was a girl -- that was for my grandmother when she was alive) and I still consider the benefits of premium membership as good value for what I want, regardless of the price increase. Furthermore, having spent several years in SL listening to people grumble that "the tier is too damn high" and having long been concerned that LL's business model of relying so heavily on income from land was unsustainable, I can't really complain that LL, now Ebbe is running things, are taking the necessary steps to reduce the price of land (as they have done, dramatically, over the last year or so, and increased the LI limits) and raise their income from alternative sources, including premium membership.
  6. I'm not so sure. This is the description of the function's return value 1: That simply tells me that the instruction has been successfully sent (and that it didn't fail for one of four possible reasons, like script wasn't set to the experience, or the list of settings was malformed). It doesn't tell me if it was actually received and, if it was, what happened next. I will have to do some tests (or possibly bug someone who can give us a definitive answer) but it seems to me that if I go to World>Environment and uncheck the option "Used Shared Environment" in the EEP viewer, then it would not be unreasonable to expect my viewer to ignore all external attempts to change my personal settings, whether those of the region's own windlight settings or those of scripted objects. Possibly that's what -2, "The agent has not granted permission" (ENV_NO_EXPERIENCE_PERMISSION) means. ETA 1: This is informed speculation, but I suspect the fact that this function returns an integer value rather than triggering an experience_permissions event implies that while the function may the experience tools technology at the server level to communicate with the viewer, it doesn't rely on experience permissions, so the usual expectations based on our experience of experience tools may not be particularly applicable. But I don't know about that. I will try, by one means or another, to find out. ETA 2: Furthermore, when an experience_permissions call fails, that triggers an experience_permissions_denied() event, with a far longer list of possible reasons, including 4, XP_ERROR_NOT_PERMITTED ("Experience permissions were denied by the user") . That really strengthens my feeling that this function shouldn't be expected to behave in the same way as anything called in the experience_permissions() event as a result of an llRequestExperiencePermissions() call.
  7. Ah.. that makes a bit more sense. Thanks. Now I start to understand. I was thrown by the reference in the title to "un-analyzed meshes with "Prim Physics," which I took to mean PRIM_PHYSICS, but it presumably means PRIM_PHYSICS_SHAPE_TYPE, PHYSICS_SHAPE_TYPE_something. I'm not sure what the "something" is, though -- PRIM_PHYSICS_SHAPE_TYPE_PRIM presumably, since that's all that's left if it's neither convex hull or none. Now that I've read the repro more closely, the issue seems to be not with the door but with the root object. What happens if I make the root prim not the unanalysed mesh I've uploaded but, instead, a regular prim? How does the mesh object behave then after region restarts? Maybe it's just the mesh modellers I've worked with but my impression was that they tend to make things like houses with regular collision prims for the floors and walls and so on, link the house mesh to it and adjust things so that the collision prims are inside the floors and walls, set them to invisible, and then set the house mesh to PRIM_PHYSICS_SHAPE_TYPE_NONE. That seems to avoid most problems and also generally keeps the LI down. And if the whole thing is avoided simply by remembering to have the viewer's uploader analyse the mesh before you upload it, that's not much of a problem, I would have thought.
  8. Thanks, @Whirly Fizzle. I'm not particularly familiar with the details of mesh modelling, and I'd not seen that bug report before. This is probably a very stupid question, but I note the title stresses that the bug affects "un-analysed meshes with 'Prim Physics'," and the fact that the mesh must be "un-analysed" is several times stressed in the description. Does this mean the problem is confined to meshes that have been uploaded with first having the viewer's uploader analyse them, and only then if they are physics enabled (that is, if you raise it off the ground with the edit tools and release it, it will fall to the ground or other solid surface rather than remain suspended in mid air) and is there any good reason for not analysing the mesh before uploading it? On the face of it, I can't see any reason why you'd want a house door to be physics enabled, since that's unnecessary and is simply asking for trouble, and even if you did, could you not remedy the problem by re-uploading the mesh only this time remembering first to ask the uploader to analyse it? All I can say is that I've worked with plenty of mesh houses and doors, and so have plenty of other experienced scripters, and never had this sort of problem -- though admittedly I've never thought to set a door to physics enabled, and I didn't make the meshes myself but I have every confidence in the skills of the mesh makers who did, so maybe they realised the importance of analysing the mesh before uploading it -- and I know for a fact (since the Mole who scripted them is a friend of mine) that many, if not all, of the houses and houseboats on Bellissaria have mesh doors that use llTargetOmega and llSetRot, and people seem to be able to use them without much difficulty, so it would appear that the issue is easily avoided.
  9. Sorry but I have to disagree with you there. There's nothing wrong with using llTargetOmega in doors in mesh builds -- I do it all the time, as do many other regulars here. the issues described in that post are to do with the specific build and the way the meshes are set. llTargetOmega, unless it's called in something which has been set as physics-enabled (so a car wheel rather than a house door) is entirely client side. Whether it's called in a prim or a mesh, the object doesn't actually move at all as far as the simulator is concerned. So you need to to call both llTargetOmega to make the door open and close smoothly and also call llSetRot actually to open and close it so people can or can't walk through the doorway. The only real issue with using llTargetOmega in doors is that you can't offset the centre of rotation, which is why you need either to pathcut regular prims or to offset it in a mesh door using the method described early in the thread, because you can't pathcut the mesh door.
  10. More info needed, I think -- in particular, are the animations looping, how long are they, and what priority are they? While I'm not sure the priority is a big issue here, when I have this issue it's normally to do with a looping, or at least a lengthy, anim. As I understand it, the problem is that llStopAnimation stops the animation but it doesn't (rather counter-intuitively) cause anything else to happen, so if the animation loops your GPU will keep on looping it until given further instructions -- either you move, and your AO or the default animations kick in, or you explicitly tell it to start a new animation. A non-looping animation should, at least in my experience, either continue until its end after you remove the attachment (so possibly up to 20 or 30 seconds, which is a long time in this context) and then leave you in the final frame until something else happens to start a new animation, or you move, which should over-write the old animation immediately So I when I run into this, my first response is very like Mollymews' above. Until you move, neither your AO nor the viewer realise your animation state has changed. They think they you're just standing, and for the simulator and your GPU and CPU know, the animations they've been told to start and stop control your facial expression or something. They don't know it's been making you dance or jump around. I think, in fact, the llStartAnimation("stand"); call is all you need because the second call, llStopAnimation() probably won't have time to fire before the attachment returns to your inventory. That doesn't matter, because the documentation is correct is saying the object is going to lose permissions to be unable to do anything once its inside your inventory (though it will retain animation permissions unless you cancel them by resetting the script or overwriting them with a new set of perms). The important thing is to tell the simulator what you want to happen after the attachment is gone, which has to be a positive instruction, so not "stop playing this" but "start playing something else". That would be my initial approach. Best of luck! I agree it's not at all intuitive -- it took me years to find the solution and only then because Dari Cauldwell, one of my many kind mentors in LSL, explained the nature of the problem to me, and told me it took her ages to work it out, too. (ETA: For newer scripters -- take it from me, if it's a scripting issue that both Kyrah and Dari think is tricky then you can be assured it really is a stinker of a problem!).
  11. Mine was from a classic British 1960s TV series, The Prisoner. Here's the opening titles, without text (very unusual for the time). I remember this when I was a kid, but it looks surprisingly contemporary in many ways: https://en.wikipedia.org/wiki/The_Prisoner I think Portmeirion, where it was shot, would be a lovely theme for Linden Homes, though I'm not sure how you'd script the bouncy ball that emerges from the sea to capture Patrick McGoohan's character when he tries to escape (it's called "Rover" in the series, as I recall). Probably need a special mesh avatar, with a hideable bubble component plus a bubble with several different faces, appearing and vanishing as Rover envelops its target.
  12. As I understand it, when in the past a premium member has become a former premium member, they've kept the same number of groups they had as a premium member, but if it's more than the lower number to which they're entitled as a free member they have to bring their membership down to the lower number less one before they can join a new group. Obviously you'd need to check as a basic member, but I'd be amazed if you find you've suddenly lost membership of 7 of your groups. As to Linden Homes, you're a bit behind the times, I'm afraid. LL have recently released the new continent of Bellissaria, with entirely new Linden Homes in two themes -- traditional American-styled houses and Houseboats. This has been a huge success, and a strong and active community has appeared overnight. LL are now out of new homes and are working very hard to create more regions to try to keep up with the demand and also are planning to release new themes of Linden Home quite soon. So while you might still not want one, you can be assured Linden Homes have recently changed for the better by orders of magnitude and are now hugely popular. As to the financial side of things, if you take into account the weekly stipend you receive as an annual member, that pretty much reduces the cost to only a couple of dollars a month (around the price of a cup of decent coffee, if not less) and you can pick up a 1024 Mainland parcel for a one-off cost of pennies per LI, and live there rent free in a house of your own choice. It might not be for you, but premium membership does have benefits that make it attractive in different ways to different people.
  13. That you can do already by having the environment hazards fling invisible damage-enabled prims at agents who come too close or who collide with the hazard, can't you? It's a lot more convoluted than your proposal but you can fake the effect quite well, I think.
  14. I want llDoWhatIMeantNotWhatIWroteDamnIt();
×
×
  • Create New...