Jump to content

Qie Niangao

  • Posts

  • Joined

  • Last visited

Everything posted by Qie Niangao

  1. Interesting example, as it shows that your state scope variables are static. Until I read the example I assumed they'd reinitialize each time the state is entered, which changes their usage quite a bit. If static, they seem "syntactic sugar" for global memory, permitting the same variable names to be overloaded but otherwise behaving as uniquely named global variables. In contrast, if they reinitialize they'd be like locally scoped variables in functions or event handlers, and the memory could be re-used in other states. But as long as we're dreaming, I occasionally long for static local variables in functions and event handlers, too.
  2. If it's really all about picking up the gifts to know which stores to visit, I'm not sure why it would matter if the gift-availability event started a week after the non-gift event. Wouldn't it be better for collecting those gifts if the place weren't packed with so many early-access non-gift event shoppers? Trying to wrap my head around that, I came up with a couple possible explanations: Perhaps there's appeal to being among that initial crowd of event-goers, even if going exclusively for the gifts. (Maybe it's related to the appeal of waiting in line for the next big Apple product, if people still do that.) It's true that "Gifty Event Day" might not be quite so crowded, which I'd seen as an advantage, but maybe it's not. Perhaps it's not all about the gifts and there's also something else of interest that's unveiled at the initial event, before a hypothetical "Gifty Event Day." I'm not sure what that is, but it might be important to merchants as well as shoppers. or maybe it's something else that I've missed altogether. In case there's confusion, I'm not proposing making gifts be transferable. I mean, some creators might do that for some gifts (at events or otherwise) as pure advertising, but gifts are also used as incentives to join a store group, or to visit the store/event to get the gift, or etc. (I may have created confusion when I mentioned gifting demos, which I only meant as a fallback for increasing demo distribution even if the creator can't bring themselves to grant the demo transfer permission.)
  3. Yes. I appreciate being able to get a demo at the creator's store (assuming they have a store, and assuming the event doesn't have a rule against it which would be crazy). It does mean a trip to the store, but the creator could be helpful and provide at the event an "objectim" URI to the store demo item itself and make it handy for the event shopper to share it with an alt or friend. In some perfect world I'd prefer the event offer delivery of demos accessed through a web "gallery" (either their own or one of the "event blogs" like Seraphim). It's a little more technically challenging than it sounds because, unlike Marketplace, the gallery won't have authentication of recipient and we don't want innocent Moles getting spammed with a bunch of illicit talpidae pr0n. So that means recreating much of the private predecessors of Marketplace (in-world sign up, etc) but with only advertising as revenue. Or events could allow/encourage creators to offer the demos on Marketplace and link to them from galleries while the actual products are still event exclusive, but that probably sounds threatening to somebody's business model, either that of events or of Marketplace. Whether the demo links are from gallery or Marketplace we wouldn't need transferable demos for event-exclusive (or any other) items. I could just send my alts the demo's URL and they could fend for themselves.
  4. I'm among those who crowd into events. (It's a dirty job but somebody's gotta do it.) No doubt sometimes I only can get in because of my Premium subscription. Whether that's a good thing or not is beside the point here, it's really about whether merchants (and "event planners") are adapting to current conditions which include early access favoring Premium members. Thing is, I have these impoverished, Basic account alts who are real clothes horses. In fact, they get way more new outfits than my main account. But they often miss out on new items because they can't get into the events, I can't test their clothes for them because they all have different mesh avatars, and I can't send them demos. That's because demos are almost universally no-transfer, and nearly never in a gift-giving vendor. Why? How do either of these settings benefit anybody? Without being able to test stuff on an alt, there's no way I'm going to gift them a full price fatpack. How isn't it an obvious win to change this? (Much the same logic would apply even if there weren't special access for Premiums: Let one shopper hand out demos to alts and friends and anybody else who might come to buy. It's the best, most cost-effective "advertising" those products will ever get and makes better use of the time spent by shoppers using peak-time slots. ------------------------------- Then there are the other kind of "GIFTS", the kind Events have Creators offer to "celebrate" an anniversary or something. Now, I'm sure the Event organizers are ever so excited about turning "this many years old" but most folks who are drawn to the gifts are at most only briefly and vaguely aware of the thing being celebrated. Then they're like kids ripping off gift wrap under the Christmas tree: it's all about what's inside. Commercially, the point must be to use that, uh, "enthusiasm" to draw business to the event. Thing is, though, events are already at full capacity to start, with or without gifts. It's only later that there's even headroom for gifts to have any benefit at all. In fact, at first, they're worse than nothing: they cause shoppers to spend extra time collecting gifts that don't generate revenue while crowding out shoppers who'd otherwise be throwing L$s at non-gift products. So why not wait a week before offering any gifts? Let the event's natural appeal draw the crowds into the venue, full of "Special Gifty-Day Celebration starts September 1st!" decorations, and stretch out the event frenzy with returning customers when the gifts are available. Creators may not want to come back and set out their gifts later, so maybe they use a special vendor that shows the upcoming gift, whetting appetites until the event organizers flip the switch to activate all those vendors on Gifty-Day.
  5. I was thinking that, too. I hesitated because at least some creators are tight-lipped about who works for them, for fear of losing whatever competitive advantage they suppose they're getting from their own magic dream scripter. (Still, can't hurt to ask.) About "the web part is done", that may make an LSL scripter a bit cautious. Depends on the application and the design, but there are potential pitfalls in having one part of anything "complete" while another has yet to be designed, especially dealing with SL functionalities that are so often constrained by bugs and artificial limitations imposed to conserve sim resources or protect from griefing. But I'm sure it'll all be fine. <———(famous last words)
  6. I think that's right. If you don't want B to always contain the script that chats back to A, it's possible to push that script from A to B when needed using llRemoteLoadScriptPin but B must have that PIN set in advance. That's also one of several possible complications with llGiveInventory*-List: if scripts are being copied, they won't arrive in a running state using those llGiveInventory* functions. (Much more intricate complications if the recipient object happens to be a worn attachment.)
  7. I assume the post is mostly in jest, but why would there be any difference between Zindra and Adult private estates? Originally "age verification" applied identically to both (as well as other SL Adult rated content including web profiles, Marketplace, etc). Of course age verification proved quite impractical and was soon enough abandoned, but maybe the surveillance state has become more effective in the intervening decade.
  8. I don't expect any significant change to pricing of existing Land products, but I'm not sure that was ever really in the cards. Rather, I expect some new products to emerge that take better advantage of AWS's capacity-on-demand. It's kinda wacked that a full region for an individual's occasional use is the same price as the same full region constantly filled with event shoppers. Before AWS those two regions cost the same for LL to operate, but now that unserved "region on demand" market is a business opportunity: a whole lotta folks won't spring for the current full region product but, rather than always-on access to a little parcel or a crippled homestead, would spend more to have their own full region only on their and friends' schedules. That obviously requires significant server-side changes, though, so I hope they've got enough developers working on it. (FWIW the move to AWS must change LL's accounting dramatically. Rather than depreciating a massive pile of capital, it's shifted to massively increased operating expense. To the bottom line, though, the change is probably minimal, steady state, but with AWS they have much more flexibility to scale and shift product offerings.)
  9. Does anybody remember Aristotle Integrity? That was the outfit the Lab had doing "age verification" as part of the Adult content migration of which Zindra was a part. For a lot of us, they could verify age based on RL identity supplied with payment info. Some had to go further (IIRC, especially those not using US banks but others too) and supply copies of actual government ID. So I think experiences varied. It was pretty much a disaster. I mean, they probably did fine with 99% of identities or something, but whatever it was it wasn't good enough and they eventually abandoned the whole thing in favor of provisionally accepting self-stated age, same as nearly every other online experience was doing already. Frankly, I suspect Aristotle sold the Lab a bill of goods, which was pretty easy to do back then (remember 80/20 Studio and Viewer 2?). Let's hope the new guys are smarter.
  10. If the objective is to get this particular script working, just ignore what I'm about to suggest. Assuming I understand correctly that the "COLOR_PRIM/_FACE" is simply a uniformly colored screen that fades in and out of transparency (so the image on the TEXTURE_PRIM/_FACE can change while the screen is opaque), a more efficient way to get the same effect is by sliding pixel-wide slices of an alpha gradient texture across the face of that color prim, a la: key ALPHA_GRADIENT = "f222f5ff-4a5a-6c02-004c-9bec19511f20"; // quick and dirty integer GRAD_X_RES = 128; // Your assembly will differ integer TEXTURE_PRIM = LINK_ROOT; integer COLOR_PRIM = 2; integer TEXTURE_FACE; // 0 in my assembly integer COLOR_FACE; list textures; // however you get 'em integer textureIdx; integer textureCount; default { state_entry() { float celWidth = 1.0/GRAD_X_RES; // one pixel of gradient per cel of animation textureCount = llGetInventoryNumber(INVENTORY_TEXTURE); integer textureIdx = textureCount; while (0 <= --textureIdx) textures += llGetInventoryName(INVENTORY_TEXTURE, textureIdx); llSetLinkPrimitiveParams(COLOR_PRIM, [ PRIM_TEXTURE, COLOR_FACE, ALPHA_GRADIENT, <celWidth, 0, 0.0>, <celWidth-0.5, 0.0, 0.0>, 0.0 , PRIM_LINK_TARGET, TEXTURE_PRIM , PRIM_TEXTURE, TEXTURE_FACE, llList2String(textures, textureIdx), <1,1,0>, <0,0,0>, 0.0 ]); } changed(integer change) { if (CHANGED_INVENTORY & change) llResetScript(); } touch_end(integer i) { float REVEALING_TIME = 1.0; float SHOWING_TIME = 2.0; float HIDING_TIME = 1.0; float cels = (float)GRAD_X_RES - 1.0; llOwnerSay("Revealing…"); llSetLinkTextureAnim(COLOR_PRIM, ANIM_ON, COLOR_FACE, GRAD_X_RES, 1, 0.0, cels, cels/REVEALING_TIME); llSleep(REVEALING_TIME); llOwnerSay("Showing "+llList2String(textures, textureIdx)+"…"); llSleep(SHOWING_TIME); llOwnerSay("Hiding…"); llSetLinkTextureAnim(COLOR_PRIM, ANIM_ON | REVERSE, COLOR_FACE, GRAD_X_RES, 1, 1.0, cels, cels/HIDING_TIME); llSleep(HIDING_TIME); llSetLinkTextureAnim(COLOR_PRIM, FALSE, COLOR_FACE, 0, 0, 0.0, 0.0, 0.0); llOwnerSay("Hidden."); textureIdx = ++textureIdx % textureCount; llSetLinkPrimitiveParams(TEXTURE_PRIM, [ PRIM_TEXTURE, TEXTURE_FACE, llList2String(textures, textureIdx), <1,1,0>, <0,0,0>, 0.0 ]); // wait for touch (or could delay here for HIDDEN_TIME interval) } } I include the above advisedly, recognizing it may only cause confusion and doesn't help with the original script at all. I only mean it as an illustration of how this can be done without a tight timer loop, instead moving the time-critical "smoothness" processing from the script to the viewer.
  11. Yeah, this land setting (disallowing Object Entry) means that only sat-upon objects can traverse the path, which for my interests renders railway throughout Bellisseria ornamental at best. Among the problems are multi-unit trains, as you mention, which can't really be "fixed" in any practical way, inasmuch as all the units would need to be linked in a single assembly, requiring a whole lot of geometry calculations, especially complicated for curves at or near region borders. That's assuming that such a complex assembly of links can make it across the border at all. Anyone who's looked at the VRC train scripts knows they could be much simplified, in part because they antedate many "efficient script" functions for manipulating link properties. I've sometimes been tempted to tidy-up, but I always worry they may unwittingly depend on accidents of timing.
  12. For finest grain control and flexibility, don't use the body's "alpha cuts" HUD at all and instead use alpha masks as outfit components, the simple reliable solution we regained when mesh bodies all adopted Bakes On Mesh. (Well, all except Jake, for which proper BOM would require a trivial update which hasn't been forthcoming from Belleza in all these many years, so alpha masks don't even work on Jake's lame BOM applier skin.) Slink indeed abandoned the old alpha cuts kludge altogether which is a big reason that body is so easy to render and uses such light script resources (but it also scared off some folks who'd forgotten how to use and make alpha masks).
  13. Well, kinda. Remember, the Lab banned gambling only under extreme duress, not as a decision to placate investors or to tidy up the brand image. That was due to real regulatory restrictions in a bunch of places from which SL allowed users and wanted to continue to allow logins to the main grid from those jurisdictions. Hence, they segregated-off a bunch of content and required it to conform to some whitewash restrictions to placate some other regulators. That all happened very near the peak of SL's popularity. The gambling ban had some effect on the SL economy—more than I think it could survive now in its diminished state—mitigated by transmogrifying SL gambling into "skill gaming" (and hey, even now, who is that new VP of Engineering?). So it's very possible "we'll be fine" if they do the same with Adult regions, imposing some bogus regulations to placate those objecting to sexual content. But the real reason I think "we'll be fine" is that this time it doesn't seem to be a problem of direct governmental regulation, but rather it's Mastercard and the banks trying not to get caught openly processing payments for child pr0n and underage prostitution. I can imagine the Lab being (even?) more visible in enforcing existing bans against anything like such content, incurring literally zero effect on revenue and very minimal expense. Maybe they'll have to go further, but even worst case, the Lab has been pretty adept at creating loopholes for near-gambling and more recently, near-gacha.
  14. I'll be disappointed if they don't already have a business proposal for using Tilia to shield Only Fans' successor. Opportunity is what you make of it.
  15. If long enough it won't work: llGetNotecardLine() silently truncates at 255 characters.
  16. Is there record* of scripts seeing this return value? If so, do we know the timing relative to shutdown warning to avatars? ______________ *a record presumably stored outside the region
  17. A regular LSL script can grab many of the EEP settings, but not all. Quite reasonably, llGetEnvironment() can't grab the UUID of textures (as EEP uses for clouds, moon, sun, etc, although it can tell if the defaults are being used), and it also lacks a few settings that would be extremely useful. One thing I very much want but have had no luck even approximating is a way of determining the keyframes in the currently used day cycle.
  18. If you want to write this script, you came to the right place for help, just show your current script, tell us what's wrong, and we'll help you fix whatever isn't working. If you want somebody to write a script for you or find one to purchase, you came to the wrong place. Try the help wanted or stuff wanted forums instead. If you're really seeking drama, there are many role-play communities in-world in deep abiding need of feigned misery, so don't waste your talent on a mere forums thread.
  19. Can't help there, but if you're ever looking for more macroeconomics charts and graphs (well, tables of numbers), there are new ones in the back of The Economist every week. And every six months, their not-entirely-joking "Big Mac Index".
  20. Yeah, that's pretty horrible. Also, I noticed using an in-world gifting system (most likely Caspervend) that it was smart enough to keep me from gifting something the recipient had already purchased for themselves (or maybe somebody else already gave it to them, dunno). That's a pretty important feature, too, which I doubt the Marketplace has yet. It seems kind of restrictive, though, to assume that the current Marketplace is the thing through which all purchases would be routed, if such a thing ever happened. So then it would become a requirements-gathering exercise to determine what features would need to be developed (in addition to the massive increase in throughput to which it would need to scale). And while we're at it, we could just "require" that routed-through-Marketplace in-world purchases not incur the same merchant commissions as direct Marketplace sales, which is only fair given that dues are already being paid in the form of Land fees. But I think it's all moot. I'd build it that way if I started from scratch, but I'm not seeing how it could be introduced in SL as it exists today.
  21. Maybe they spent too much chasing the gacha dragon and need a place to crash until it's time for their next fix.
  22. I don't think such a script would actually hurt anybody because it would only illustrate what everybody who has paid attention has known about gacha since forever (they're often rigged, sometimes egregiously, and there's simply no way to know), and that's had little effect on their popularity. And that means such a script also wouldn't help anybody either: Those of a mind to learn from it, already know. Just to restate a point I tried to make earlier, it's not only that the gacha (and now conveyor) merchants exploit customers—really, if the customers want* to pay for the thrill of the hunt for a less valuable catch, well, let 'em. A bigger problem is that those merchants' game-of-chance marketing technique steals honest business from more talented, less cynical creators. ______________ *Where "want" is euphemistic. This thread is ample evidence of buyers in deep denial about what truly motivates them to press that gacha lever.
  23. Because it's a new effect, it might be something with a new viewer version, and Firestorm's recent release finally includes the "Custom Key Mappings" feature that was in a Linden viewer since April. It shouldn't teleport you anywhere weird, but it's all new enough there could be bugs, maybe?
  24. The part I bolded may have been obvious all along, but stated so concisely, it's a revelation to me: The relevant price is not that of the item being purchased at the moment, which is fixed, but the unknowable cost of the item one actually wants. With gacha, you don't even know which item you're purchasing until you've paid; with the conveyor you know what you're getting with the immediate purchase but can't necessarily know how much it will cost to even bring the desired item into view and eventually buy it. Consider what would happen if the rules changed such that the entire set of available items were required to be displayed in the conveyor, in the order they'll need to be purchased, so the buyer could see exactly how much it would cost to get to the one they want. Now, if the conveyor system were such a good deal, that should be uniformly appealing to both seller and buyer, right? But it would be a commercial flop because fair pricing isn't what any of this is about.
  • Create New...