Jump to content

Lavanya Hartnell

Resident
  • Posts

    15
  • Joined

  • Last visited

Everything posted by Lavanya Hartnell

  1. Sim was sold at asking price. Thank you to all who inquired. Good luck in your searches!
  2. No offers at my asking price yet. Lowering to L$ 30,000 (~US $120). First one to offer this price gets it. Also considering other serious offers.
  3. No asking-price (L$ 50k) offer received yet. Lowering price to L$ 40,000 (US $160). First one to offer this price gets it. Also considering other serious offers.
  4. See it here: http://maps.secondlife.com/secondlife/Lavars/203/114/40 L$50k (~US $200) plus transfer fee or best offer. Tier due December 7th. Targeting sale by December 1st. This is a standard full island region with 20k prim available. Tier is US $229 per month. Transfer fee is US $100. Grandfathered sims usually have lower tier, but transfer fee is US $300. This is the current incarnation of Lovers Nation on the Lavars (Hindi for "lovers") sim. 100% custom build with an Alpine valley theme. I will leave all the ground assets for you to either keep or selectively delete. The build currently occupies about 4,500 LI out of the 20,000 LI available. (Note that there is currently a 1k LI skybox that will be removed before sale.) The Lovers Nation branding will also be removed. This sim is a labor of love and entailed a massive investment in some of SL's best landscaping and PG furniture assets. This is a ready-made public park or private retreat. Be sure to take some time to explore it before you buy. Whoever is first to meet my asking price will get Lavars. Otherwise I'll choose among the various lower offers with consideration of your use case. Please online or offline IM me with offers or inquiries. - Lavanya Hartnell Info about transferring regions: https://community.secondlife.com/knowledgebase/english/managing-private-regions-r50/#Section_5
  5. Definitely frustrating. I've learned not to show a dialog while waiting for the user to grant permissions because of that overlap. But even the inventory window, mini map, and other HUDs can obscure it. It doesn't help that it's dull in color to the point of blending in with always-there windows like the chat history or inventory box. At least dialogs stand out enough to draw the eye to them. I've recently discovered that a lot of people are not aware of the floating icon indicating waiting system notices and requests that hide after a while. The system is polite but cryptic, especially for new users.
  6. I have to agree. The way LSL permissions work, overall, makes good sense, IMO. I don't think I'd want objects teleporting me without my permission, even if they are attachments. It would be nice if one could grant a permission to an entire product line, which I was hoping was what experiences were for. They only kinda are. I'm being optimistic in hoping that users will soon be used to getting hundreds of my dynamic landmarks from places they visit, so I have an incentive to try to reduce this somewhat confusing barrier. Quite a few people who have tried out the HUDs don't actually see the permission request at first. I think more than a few have even just given up on it because they never noticed that permission box or payed attention to the plain-English messages the HUD repeatedly gives the user to explain the need. But this is a classic problem in user interface design, too. I'll continue working on a better answer.
  7. Okay, cool. That now perfectly meshes with what I've found. My users only have to grant teleport permission once (per HUD). It is retained across sessions of wearing, thankfully. This isn't awful, of course. I was just hoping to make it so they would grant a permission (i.e., an entire experience) for the entire line of HUDs people may get in the future with this same script set. But it's clear to me, now, that experiences must be enabled at the parcel or region level. I'm disappointed that LL introduced yet another feature that had the potential to be more than it is. I shouldn't complain, though, because it's still a neat feature for a lot of game-like applications. Incidentally, I'm not the first person to think of this. There is an "AVsitter" experience created for use with all the furniture that relies on the AVsitter kit. I guess I had been assuming it actually works grid-wide like what I want for my HUDs, but the evidence is that it doesn't. Again, each region or parcel would have to enable that experience, which requires parcel owners to even be aware of it in the first place. Thank you all for your insights.
  8. My software already demonstrates this, though. The HUD is worn. Upon the first rezing (when worn), the script detects that it does not yet have permission to teleport the owner, so it requests permission. This causes the usual permission dialog to show, as seen in the included image. Note how it visibly asks for permission to both attach and to teleport. I thought maybe there was a difference between permissions during the on_rez() event and the attach() event that could account for this behavior, but I don't think it's that. If the user chooses "No", the script again asks the user for permission. This is, of course, long after the attach() event has fired. If there was going to be a silent, automatic granting of permission, it would happen here, at least. I think this confirms what the wiki shows: Teleport permission is not automatically granted. I suspect that if the only permission I was asking for was attachment, it would silently grant the permission without showing a dialog. Otherwise, all those HUDs I've seen that have close buttons would be showing the permission request, too. I think it's just including it on the permission dialog because the two permissions are requested at the same time.
  9. Thank you for the follow-up. I checked the documentation for llRequestPermissions(). Sadly, PERMISSION_TELEPORT is not automatically granted to the wearer of an attachment the way, say, PERMISSION_TRACK_CAMERA is. However, you do explain well why I still have to request PERMISSION_ATTACH to detach the HUD, even if the user would not normally see a visible request. I hadn't realized this aspect of permissioning prior. In any case, the basic answer is: no, you can't design an experience to work grid-wide. Noted. Thank you all for your replies. Too bad, though.
  10. I should clarify. This is a HUD that is given out. It could be that you gave a copy to your friend. So there is no telling what sim someone will be on when they wear the HUD. Now, I don't need attach permission for them to manually attach it, but I do seem to need the permission to detach it for them if they hit a "close" button or once they complete a teleport. That's really annoying and I don't know why it's required, but I haven't figured a way around it. As for the teleport permission, again, the HUD could be worn at any point in time and on any sim. Okay, so if this was just one HUD, this would be no problem, but it's not. This is a free service where anyone can create their own "dynamic landmarks". Each DLM comes with its own branded HUD, so if one person has 20 DLMs to different clubs, shops, etc., they have to grant the same permissions at least 20 times. Here's the product: https://marketplace.secondlife.com/p/My-dynamic-landmarks/11534763 That's where it currently stands. First time you wear one of these HUDs, you have to grant permissions to teleport and attach (detach) before continuing. See why granting an experience to all of these HUDs one time would be valuable? They all use the same scripts from me, so they all have the same security considerations. But I don't think it's practical to engage in a campaign to convince all region owners to add my experience just for this minor product. Thoughts?
  11. Is it possible to create an experience that works grid-wide? Or will these only work on regions or parcels that allow the experience? For example, a system of grid-wide teleporter HUDs, where user interaction with each HUD triggers llTeleportAgent(). My current design requires the user to grant TP (and attach) permissions once for each HUD they get. It would be nice for them to grant the experience once and have it apply to every HUD using the same software.
  12. A friend created a group ("~Polyamory~"). She left it at some point and ownership got transfered to me somehow. I am listed as the only owner. When I look at the available roles to give her -- or any other user in-group, for that matter -- the "Owner" option is grayed out so I can't check it. This is also happening with another group I created. I also tried inviting someone not in-group in with the "Owner" role, but it is not in the drop-down lists of first roles to assign to a new member. Is there some master setting that's designed to stopp accidental oopsies that I need to change in my client or something?
×
×
  • Create New...