Jump to content

Haravikk Mistral

Resident
  • Posts

    123
  • Joined

  • Last visited

Reputation

2 Neutral

Recent Profile Visitors

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

  1. Qie Niangao wrote: Haravikk Mistral wrote: my wiki editing privileges have been revoked. This may not apply here, but just in case: the wiki has been closed to resident edits for months, with only special exemptions. Maybe this is something different -- perhaps you were among the annointed few who could edit -- but otherwise not being able to edit the wiki is just how it's been, ever since some spamming a while back. (I know there was also promise of some new fix to defeat the spam and restore normal wiki function, but I never heard it was complete.) If only that were the case; I had already requested to get the privilege back. Whichever Linden has been harassing me revoked it again, falsely claiming that I in some way "misused" editing permissions (despite only making something like half a dozen edits in the past two months and only to my own pages); I tried to point this out to support staff, and instead of doing something about it they suspended my in-world account for "consistent misuse" of the wiki, which is simply impossible; and even if it were it is an irrational response for something that at most might justify a warning! The Linden support staff are entirely unwilling to even consider that one of their own might be abusing their powers to treat me this way; it's like the whole thing is us against them, that being paying customers, content creators and residents vs. despotic Lindens on power trips.
  2. So the latest update to this entire debacle; I noticed today that my wiki editing privileges have been revoked. So naturally I filed a support ticket asking why only to be told I've had them revoked for some kind of infraction. After asking to be told what that would be I have now had my in-world Second Life account banned as well (like I can edit the Wiki with that?) It is clear that I am being targeted for harassment by Lindens, which is apparently their response to any and all criticism. I don't expect I'll be able to post to the forums for much longer.
  3. Innula Zenovka wrote: You are, I think, mistaken when you say, "Premium Members Only: Only premium members can create content using this feature, but why?" Only premium members can own experiences, but once an experience has been created, the owner can set it to a group, and the group owner can assign the abiltiy "Experience Contributor" (as I think it's called) to particular group roles. Then anyone with that group role can create content for that experience, whether or not they are premium members. That doesn't really help though; that's even more complexity for what should be a simple feature. It also doesn't change the fact that you still need to be in a group with which an experience is shared in that way, that's still a lot more than just being able to type the letters "llSit()" into a script and being half way to finished.
  4. Qie Niangao wrote: A variant of that use case appears a couple places here (including "switching seats on a vehicle"), but it's quite tangential to the function's real utility. With PRIM_SIT_TARGET (now, or since 2011, llLinkSitTarget) and llAvatarOnLinkSitTarget, it's (relatively) trivial for a non-Experience-based script to move seated avatars around among those target locations, regardless of which sit-targets they happen to occupy. ("Relatively" because it would still be necessary to back-out the ancient sit target offset mess, if sit targets are really how the script is retaining avatar target locations -- which is almost never the case anyway.) The point isn't that it can't be done by other means, but that it isn't possible to do cleanly with llSitOnLink() which should be the obvious choice; I've used llSetLinkPrimitiveParams() to do this for years, I'm not looking for ways to do it, I'm looking for a feature that's actually fit for purpose after a decade of needing this feature (llSit(), not llSitOnLink()). Qie Niangao wrote: Presumably it's intended to be sure permissions are associated with products intuitively for the end-user: the thing on which they end up seated is the thing that had permissions. If that's the case then in four or more weeks a single Linden hasn't once said it; Oz Linden has implied there are technical reasons why permissions are difficult to implement, but utterly failed to give a single one. I have pointed out that, though the permissions bitfield is finite, there are still around 17 slots available for new permissions, and like I say in terms of functionality the requested behaviour is identical to PERMISSION_TRIGGER_ANIMATION, so implementing it that way cannot possible be difficult, so once again this is a Linden using the "you don't know what we know" line as a cheap foil, when chances are I know a lot more about software development than all of them combined. If the issue is on granting the permissions in an intuitive way then it isn't relevant; under the llSitOnLink() proposal it will already be possible for scripted objects to haul you around faster thatn you can possibly track down the device at fault, but in fact standing up will not be sufficient to stop it. Instead you must delve into the experience system window (which you may not fully know about) and block the correct experience. The proposed permission implementation is actually better in terms of safety as it would only auto-grant on objects you are sat upon (easily revoked, and easy to know the culprit, since it's something you chose to sit on), likewise with auto-grant on attach, again easily solved, as how many potentially malicious objects is an avatar actually going to attach? Besides which, when attaching a trustworthy HUD, it can implement far richer and more detailed "permissions" than LL can; just take a look at even simple RLVa relays, which tell you what has requested permissions and (depending upon the mode its in) can allow you to individually revoke them. Otherwise the permission is per-object and only so long as you are in the region, so teleporting away is always a solution in the worst case scenario; if a problem persists, it's definitely an attachment. Besides which, with a permission it is possible for the viewer to block permission requests or identify them; this is not possible at all with the experience system. You could for example have an option to block sit permission requests from some or all sources, which some viewers have for animations. Qie Niangao wrote: One other note: Even though all the baggage that comes with Experiences may not be necessary or even valuable for this functionality, I can pretty much guarantee that the functionality would never have even been considered at all if we hadn't fussed about how much we needed this in order to make Experiences useful. This is probably likely, but the thing is experiences are useful; I like the feature for what it is good at, I like persistent permissions, and persistent key/value storage etc. It already does what it is good at, shoe-horning features into it for no reason is not valuable. However, my objection to llSit() being usurped for that purpose does not extend to the other feature enabling objects to prevent unsit; this absolutely should be experience limited, as handling that with a permission would be difficult. But there is simply no reason for llSit() to be butchered into a useless function to window dress the experience system with something it doesn't need. Qie Niangao wrote: I wouldn't raise it, myself, if I hoped to get results from Lindens (as opposed to merely rousing the rabble, I guess). "merely rousing the rabble" seems to be the only option left; I've tried the JIRA, I've tried user groups, I've tried talking directly to a Linden (reminder: it took four weeks to get something approaching an actual conversation from someone who ultimately can't even be bothered pretending to care), and I've been treated like **bleep** the entire time.
  5. You're probably right; I've been sick of the way SL is run for some time now too. I mean, it's ridiculous that they're still charging $195/month for a mainland simulator (or 50% extra for private); for that kind of money I can buy 10-20 cloud compute instances, each just as powerful as the hardware LL allocate per sim, and run an entire mini-grid of open simulators, so what are we even paying for anymore except the sallaries of people who hate us? 10 years ago that might have been close to what a dedicated server or good VPS would cost, but it seems the ridiculous cost is nothing more than an attempt to delay the inevitable. No-one I know has land anymore, nor wants it, as hoovering up half a region for L$10,000 isn't worth it if you have to pay through the nose to keep it. The increased prim allowance is likewise a bad joke; it's the kind of increase we should have had 5 or 10 years ago, now it just feels like a slap in the face, or sprinkles on a turd salad.
  6. I'm not sure how many of you aware of it, but there is a new function in RC right now llSitOnLink(), and while it might sound nice to finally have a scripted sit feature, it is unfortunately a very sad tale of just how much contempt the Lindens view us with, as the reality is that this feature is deeply flawed, yet the Lindens are refusing to do anything about it while there is still time. Problems With the Feature To give you some idea of why this annoys me so much, I suggested the very same feature almost a decade ago (in fact probably longer, as I originally proposed it on the pre-JIRA issue tracker), which you can view under SCR-3. You may note right away that the design of the actual function is different; instead of taking an agent key and a link number, it takes two keys. This is important because it not only means the function can do everything llSitOnLink() can (using llGetLinkKey()), but it can do so without scripts having to actually reside in the target object; it could for example (and crucially) be used from a HUD or other attachment, or could teleport you from one object another. The other problem however is the fact that the Lindens are refusing to the use permissions system to implement this feature; they are essentially trying to use the experience system as a lazy shortcut. While the experience system has its advantages, it simply isn't suited as a replacement to a permission in this case for a huge number of reasons (I'll limit myself to four): No Auto-Grant: It is not possible for the experience system to automatically grant permission on sit (or attach for llSit), and this is a huge oversight, as it means that the most basic use-case of llSitOnLink(), moving an avatar between sit-targets, cannot be achieved without the additional boilerplate of the experience system. The only way this could be achieved would be with a workaround, at which point… why not use a permission which can do this?Experiences Can Be Blocked: In permission based objects, the experience system is a convenient way to grant the permissions persistently, however, if the experience is blocked, the permission can still be granted and the device can continue to work normally. This is not possible for a feature limited solely to the experience system; this means that switching seats on a vehicle can (will) simply stop working, and in a very unintuitive way for end users, so if this feature can't even handle that simple use case, what is it actually good for?Premium Members Only: Only premium members can create content using this feature, but why? It's a very basic feature so why shouldn't a regular member be able to create a vehicle with seat-switching? The whole reason I liked Second Life was the openness of content creation; while there are some cases where experiences are the right place for a feature, this is not one of them, not even close, and I am deeply concerned that it is the start of a trend of restricting new features to premium members only.Permissions Do It All: Not only are permissions finer grained, more compatible and easier (and free) to implement effectively, they also provide all the protection that this feature needs. Sat on something that maliciously used the auto-grant on sit behaviour? Stand up! Attached something that is forcing you to sit? Detach it! The experience system offers nothing that permissions alone can't do, except for persistence, but then the experience system can just as easily do that by granting the permission, there is no reason for this ludicrous and entirely arbitrary restriction. Implementing a permission for this would be as simple as copy/pasting PERMISSION_TRIGGER_ANIMATION; it has the exact same auto-grant behaviour, making this a few minutes of work at most. Response by the Lindens I have been trying for weeks now to raise all of these concerns (and more) with the Lindens, and their response? Many don't seem to even understand the issue in the first place, while others seem bewildered by the idea that they are being questioned at all. Most have ignored me, my JIRA issues attempting to raise specific issues and propose solutions have been closed without comment (or comments proving a Linden didn't even read it) and when I asked that someone actually talk to me about it? Banned from the JIRA! User group meetings have been little better, as it is almost impossible to get an issue properly discussed when many people have issues to raise and the subject changes too quickly, while the Lindens largely result to the bad parenting 101 default response of "because I said so". After all that time however I finally got Oz Linden to actually consent to speaking to me via e-mail, but this again has been an entirely pointless endeavour. Despite raising all of the issues with the feature clearly, Oz has yet to address a single one of them; all I've gotten is vague hand waving "woe is me" crap about limitations, without not a single scrap of detail to any of it; I even responded refuting every possible objection and Oz didn't address any of that either. I even tried to compromise; if the experience system is non-negotiable, then at the very least llSit() with two keys would still be infinitely more flexible, as we could put it in a HUD and implement permissions ourselves. But no, nothing. I don't know what the point of his contacting me really was, as right now it feels like just another insulting display of contempt, giving me false hope and then yanking it away, as I received no sign that at any point he was considering changes; I didn't even receive so much as an apology for my treatment up until that point! Getting the two key variation of the function would take perhaps two minutes of work for a Linden with access to the simulator source code (hell, if they gave me access I could probably have it done in a day or two with no prior familiarity with the code), but it's the same old line I've been hearing for 11 years as a paying customer; "we're too busy", like they're the real victims here despite being paid money to deliver sub-par work that any self-respecting developer should be ashamed with (I personally would commit sepuku or ask to be taken outside and shot). They certainly weren't too busy to squeeze out a function that is vastly inferior to what I proposed 10 years ago, and upon release will continue to be overshadowed by RLVa, a free, open-source feature added by a third party viewer developer, which has been delivering precisely the two-key format with fine-grained permissions that I've wanted for a decade. For years now I have had to rely on a third-party viewer feature; anyone in a similar situation will know what it's like trying to tell customers they need to install a third party viewer, and enabled a feature called "Restrained Love" just to gain access to a basic feature. What can be done? What can be done about it is a question I'm not sure I know the answer to; for now I am just hoping to document this sorry saga of my attempt to get a single half-assed feature fixed before it is inflicted upon the main grid. But if people are interested by it, please make yourself known here; better yet, please attend the next Server/Sim/Scripting User Group meeting. Perhaps if there are enough of us there to voice our disatisfaction we might be able to convince the Lindens that half a feature is not good enough; I for one am tired after 11 years of broken promises, half-implemented and/or poorly designed features delivered at a glacial pace, and Lindens with entirely undeserverd superiority complexes telling us we are wrong to be unhappy with their amateur-hour mediocrity. Sorry, I take that back as it's unfair; amateurs at least try their best and learn from mistakes. What I do know is that I have spend thousands of USD in Second Life, and I have been treated with what can only be described as institutionalised contempt just for trying to see a basic feature implemented to a reasonable standard, and I am sick of it. I've created a petition for those that wish to add their names: Implement llSit() as Originally Proposed in SCR-3 Ten Years Ago
  7. Does HTTP in support the sending of custom HTTP headers? I've been trying to send any kind of data at all via HTTP headers to a script in-world and it doesn't seem to receive any of them, however the only restriction mentioned on headers is that requests to llGetHTTPHeader() need to be in lowercase, there is no mention of headers being removed. Is anyone aware of any other restrictions on which headers can and cannot be sent to an LSL script, and whether any of them can be used to pass custom details? I had thought that passing some simple data via a custom header would avoid the need to perform additional processing on the message body in http_request(), however I cannot get it to work at all.
  8. I think the biggest problem with the up-front private sim cost is that it hasn't been justified for a very long time. It might, might, just have made sense back when SL was small and machines had to be provisioned especially to meet demand for new private sims, and it wasn't clear if SL would take off long-term (i.e- it was more of a risk to buy a machine, so the up-front cost helped to cover that). However, as SL grew the machines became used for a long time, especially with LL making better use of them through load-balancing, so even if someone got a private island and gave it up after a month, there would still have been a good chance of someone else wanting it, so the hardware wasn't wasted, i.e- no up front cost was needed to offset the risk as it was pretty much guaranteed to be utilised by someone. The cost is justified even less now if demand is dropping, because it means that there is a bunch of machines that are going to be wasted otherwise; in terms of maintenance it makes more sense to have as many private island owners on those machines as is possible, as their monthly fees will then pay for any hardware fixes, power consumption, data charges etc. In other words, if a private sims close and leave a machine with no sims on it, then that machine isn't making any money at allto offset its original cost, or the cost to keep/maintain it. At the very least the private sim setup costs should have adjusted to reflect the land market or something, but really the up-front fee has been a total rip-off for a long time now IMO, especially with a private sim costing so much more to own anyway, just to get more control of terrain height and appearance, and a fairly basic set of estate tools.
  9. Geez, I hope it doesn't come to that. IMO it would make more sense to cut the tier prices in half (or double their allowances) and run sims two per (virtual?) core; the vast majority of sims are lightly loaded anyway, so as long as high traffic sims aren't sharing the same CPU resources that would allow costs to be slashed without having to reclaim land. With people able to have more land at the same monthly tier cost that should encourage sales again without downsizing. I mean, downsizing sims would be a pretty tricky proposition anyway given that a sim could be half empty but still populated with beloved virtual homes etc. I've been trying to read up on the Project Sansar thing and I wonder if LL will be using more of a cloud computing model to manage it, as systems like OpenStack would allow simulators to share resources a lot more efficiently and fluidly. If they are then it would make a lot of sense to move the current SL sims over to the same platform (may not actually be that hard). Either it would mean they can repurpose existing SL hardware as hardware to start their own cloud, or they can transition sims away from the hardware and discontinue it/sell it off so they no longer have to manage hardware of their own (if they end up using an cloud computing platform like Netflix has done).
  10. I think my last land purchase and sale was over six years ago Shame, I've seen outfit and avatar combos that sell for more, seems strange that land has such a low value when you still need it to actually keep things rezzed. Is everyone renting now or something? I missed the deadline to sell and tier down anyway (I got the date wrong, yay!) so I guess I'll just keep dropping the price till it goes, or abandon it if I'm at risk of paying the higher tier for another month, as it doesn't sound like there's much to gain by holding onto it. I guess it's just lucky the prices weren't this low six years ago, or I'd probably have even more land I need to get rid of.
  11. Their rate as far I am aware of is 0.3 per meter. way less than 0.5 which is a "decent" price for someone who wants to get rid of their parcel. Wow, that low? If I remember right the last land I bought was nearly L$20 per square metre, I guess the land prices aren't doing so well these days?
  12. Apologies if this is covered somewhere already, but I can't find it (I'm not too happy with the search on these forums). It's been a long time since I last sold land, but back then all I had to do to sell quickly was find out the current L$ per square metre target of bots and price my land just under that to have a bot show up and buy it within minutes. Looking at land sales however I'm seeing a huge range of prices for similarly sized plots, so I'm not sure whether that sweet spot exists anymore, or have the bot-based monopolies fizzled out? The land is in a nice quiet sim, 3,536 square metres of plain grassland. I'd appreciate any advice on the current market for selling land like this, should I set my expectations low? I'm mostly doing it to tier down rather than make tons of L$, but anything I can make on the sale can be used to pay that lower monthly tier for a while so… it's always nice to get something if I can.
  13. All good suggestions, but the major one for me is eliminating this fixed tier pricing. I know the Lindens want to encourage larger sales, but personally I find people forced to cut corners rather than tier up or, in my own case, I'm in the difficult position of having to make tough decisions in order to tier down, as I don't believe I'm getting enough out of my current land for what I'm paying and need to scale back. Personally I'd like to see them just take the price per square metre of the current tiers and simply charge for what you own. For example, if you want 6,000 square metres you'd pay $25 for the first 4,096 square metres, then an extra ~$7 for the remaining 1,904 square metres at the 8,192 tier price of ~$0.003 per square metre, i.e- the square metre price gets cheaper for each power of two square metres you already own. In effect the pricing would be the same as it is now for anyone that is right on their tier limit. In the short term this means a reduction in cost for most people, who probably have the odd awkward amount of land use they can't use, but I think in the long run it'd be better as users will be encouraged to buy up small amounts of extra land above their tier. In fact, for most casual land owners 2,048 or 4,096 square metres is a good amount of land, but it's easy to outgrow these, however 8,192 is a more significant commitment if you don't really need that many prims or that much space, which is why the current system really doesn't work IMO.
  14. Does anyone know if Poser Debut is any good for making animations in SL? It's currently available as part of the MacHeist Bundle along with a heap of other useful apps for the next two days. I'm tempted to get it anyway as it's good value, and supports charity to boot, but I'm curious whether anyone has used Poser Debut to make SL animations? It seems like a stripped down version of Poser, which may be all I need for SL animating since I don't need fancy character models or such, just the right skeleton and BVH output, especially since QAvimator doesn't seem to be working too well on Mac on anymore (either that or I'm a seasoned pro at making it crash with every second click).
  15. That would certainly explain why it doesn't work then! Okay, do any third party viewers available for Mac work? I'm using Intel integrated graphics so I don't think I can set a system-wide frame-rate limit under OS X, unless it can be set under Windows and sticks (e.g - if it's a hardware setting)?
×
×
  • Create New...