Sara Nova

I can only imagine it's always listening. If it wasn't, the HUD couldn't work, could it? The user could click a button at any time. I guess it could communicate via an external server or something, but that would be overkill for something like a color/texture HUD.

1. But I already have a lot of hair I bought from that creator back when I didn't care about modify perms quite as much as I do now. Besides, they had a lot of designs I really liked (and still do) and it's not like I can just buy the same product from a different creator. A different seller perhaps, if someone illegally copied it, but I imagine that's not what you're talking about. 2. I don't see why not. This isn't the official forum for that commercial product or its creator. This is the official forum for Second Life, and not everyone here has a problem with using products in ways the creator didn't intend. You're welcome to state your opinion on the matter, but so long as my "reverse engineering" stays within the Terms of Service, I think this forum is a fine place to discuss it. Besides, how do you know the creator would have an issue with it? It's possible the idea of sharing the channel number simply never occurred to them. 3. Okay...that's a shame, but I don't see why that should stop me.

I've actually done that before (there's something you can turn on in Advanced->Consoles->Debug Tags that makes it output to the console IIRC) but this HUD doesn't use a dialog. Good idea though. I looked that up on the wiki earlier today, and yes.

I have a whole bunch of hair I bought from a store called Rezology that I really like. It comes with a HUD to select from a few textures and change the tint color, but unfortunately the hair is no-modify, meaning unless I can emulate it, I have to use the HUD and can't trigger it from my own scripts. And this is a problem for me, because while this wasn't as important to me when I bought from them, now I use a complex set of scripts to automatically edit all of my attachments, for purposes like color coordination. (These scripts are almost entirely implemented in client-side Lua, so there's no need to worry about them causing lag.) I'm already using my own custom-compiled fork of Cool VL Viewer, so I suppose I could add in some code to programmatically simulate clicks on the HUD. But since this is theoretically something I can do without all that extra complexity, the ideal solution would be to do it that way. If the texture buttons on the HUD send a full UUID, I might even be able to use my own textures for it that way. I just don't know what channel it uses. I'm pretty sure all of the products I bought use the same channel, as I was able to change the color of one of them using the HUD that came with another. And yes, normally what I'd do is contact the creator, but the store has since closed down, so that might be difficult. And I seem to remember trying to contact them about something else back when the store was open and never even getting a response then. So does anyone happen to know what channel it uses, or have any suggestions for what it might use?

Thank you for the suggestion! I'm still looking for something more similar, but I did end up buying that cause it was pretty cheap. Unfortunately, it looks like the creator accidentally made the body no modify, even though the permissions on the rest of the parts are correct. I sent the creator a notecard, but their bio says they're unavailable for a couple months. (With no date listed, so a lot of that time might have already passed as far as I can tell.) I hope this doesn't turn out like the last time, where the creator never ended up replying to me. I got the listing taken down that time, but that didn't really help me get the permissions I paid for. I wish LL was willing to take matters into their own hands and grant the advertised permissions when the creator is insolvent. (So as not to derail the conversation in case someone mentions their supposed lack of legal ability to do so, it actually would be legal for LL to do that, incidentally thanks to the same clause which makes the SL ToS incompatible with DAZ's license.) Yes, I have already; many times.

That says it was made before mesh existed; I said I'm looking for a mesh body. Also it doesn't have that same "slim" style as the one I posted. That one reminds me a lot of Winx Club, and I'm looking for a similar aesthetic to that. Thanks anyway though

Bumping since it's been more than half a year with no reply. By the way, I'm still interested in something you find even if it doesn't have Bento hands, but I can't do without mod permissions. Oh, and I contacted DAZ 3D since I had no luck reaching the creator, and they said I actually wouldn't be allowed to upload it to SL with either license, as it's not compatible with SL's Terms of Service. If anyone knows of a good way to reach this creator, please do let me know. Alternatively, is there anywhere you recommend I can commission the creation of something in this style? And how much should I expect to pay for it if so? (I'm fine with the creator selling it to other people as well, in case that'll make it cost less.)

I can't help but wonder, did you think I was a traffic bot before you triggered my bumper?

Hopefully that will keep them occupied so they aren't griefing 😁

Yes, there's reviews, but you can't post a review unless you've bought the product via the Marketplace listing (as opposed to in-world.) And even if you did, sometimes you might just want to post a comment without affecting the rating, though that's less of an issue. You can at least post comments on reviews that others have already posted, but that seems weird if you want to say something that isn't related to that specific review. Why can't there just be a regular comments section for the item as well as the reviews section? What if I want to ask a question about the product before I buy? I could IM the creator, but it would be nice to have it publicly posted on the listing for other customers, as well as letting other people answer. (An Amazon-like Q&A feature that notifies people who've bought the product would be cool.) Is there some reason Linden Lab might have intentionally left this feature out, or have they simply not gotten around to adding it?

Something in the same vein as this: https://www.daz3d.com/star-original-figure Bento hands and mod permissions are a must. Side question: if I were to buy that model from DAZ and upload it to Second Life (anyone know how easy that would be?) do you think I'd need to buy the interactive license even if I don't transfer it to other users? Or would the mere fact that the data is transmitted to other viewers be enough to necessitate the interactive license, even if those users couldn't rip it without jumping through hoops and violating the SL ToS?

I know you said you looked at everything on Marketplace, but this isn't actually labeled using any of the terms you described, so maybe you didn't see it: https://marketplace.secondlife.com/p/Happy-Paw-Dragon-wings-bentoanimesh/17417223

Okay, well if attachments are unaffected, then doing it the way Firestorm does it would work for my needs. I'm just not sure what that is that it's doing.

I use a custom build of Cool VL Viewer to which I've added additional Lua scripting functionality for manipulating prims. I have it set up to perform automatic modifications to my attachments, to do things like color coordination, and automatic positioning/scaling to fit an avatar that swaps parts frequently. When I add an attachment to this system, my code stores some data about the prims, like their original position (in case any of my filters end up moving them around, e.g. for changing the length of flexi hair) and which labels ("targets") I've assigned to each face for purposes of applying colors and the like. This data is associated with each prim via its link number, determined by its position in the list returned by calling LLViewerObject::getChildren() on its root prim. (Don't worry; this is nowhere near enough data to recreate the object from scratch. I could do the same with LSL; it would just be laggy and harder to maintain.) This has remained stable and accurate for some time, but yesterday I started running into a problem where it was no longer giving me the accurate link order, seemingly being randomized each time I reattach something. This was not caused by any change in the viewer, nor in my Lua code, so I can only conclude that there was some kind of change in the server related to the order in which it sends prim updates. (I have verified that the actual link order as reported by LSL has not changed.) This has caused all of the prims to become jumbled up as it thinks they're in the wrong location and tries to "fix" it, often resulting in an ugly mass of prims that looks nothing like it's supposed to. I know that it's possible to determine the accurate link order from viewer-side code, as Firestorm's previous/next prim buttons show the accurate order. (Cool VL Viewer's previous/next buttons, by contrast, show the jumbled order.) I looked at how Firestorm does it, and it just uses the same getChildren() method I'm using, so clearly there's some difference elsewhere in the code that makes that always return the right order. But I don't know where to look. Does anyone have any advice?

I already bought it a while ago but my support expired. Is there a way I can renew my support for less than the cost of buying a new copy?

How what part would work specifically?

I'm just wondering why this functionality wasn't implemented. It seems like such a simple thing to support, and this is me speaking as a programmer. Just have the viewer transform the vertices of the mesh either before or after applying the skeletal deform, as an extra step when rendering a rigged mesh attachment. Am I missing something and this wouldn't work? Why isn't it a feature? I'm hoping LL decides to add this. To prevent breaking existing attachments, they could have it be enabled by a setting on the object, which is off by default for older objects, but on by default in newly-uploaded ones. (This could also be where you select whether to apply the transformation before or after the skeletal deform.) Just like positioning and rotation, this could be editable even on no-modify objects, to avoid the side effect of preventing users of older no-modify objects from benefiting from this new way of adjusting fit, in case they're lucky enough that the scale wasn't inadvertently changed by the creator. (In other words, it would keep this backward-compatibility feature from breaking backward-compatibility somewhere else.) Besides the obvious benefits for adjusting the fit of mesh attachments, this would have other uses as well, such as: Making it easier to create rigged items for use with mesh bodies you didn't create, without annoying trial-and-error uploads. (Tip from OptimoMaximo: you can do this trial-and-error testing on the beta grid and you won't waste L$. Thanks again!) Rigged attachments that can change size through scripting. Is this something LL might add in the future? Is it worth submitting as a suggestion?

I think $40 is awfully steep but it was still worth it to me. Weird that they require Premium as well as the $40 though.

Would be funny if they forgot to forbid "Linden" as a choice.

Finally, I don't have to explain to everyone that my account isn't an alt anymore, despite my username saying it is. $40 is awfully steep, but eh, I can live with it, plus now I have a name I really like. Surprised it was still available when I took it!

That's another thing that should have been disclosed. If an item is advertised as having a certain permission enabled—such as modify—the assumption is that I'll be able to do everything allowed by that permission—including deleting a script—without meeting any kind of resistance. Unintended glitches, sure; there's always a risk of that when doing that kind of edit. Same if the updater had instead been inseparately built into the main script. But deliberate "anti-tampering checks" have no place in an object sold as modifiable, unless it was made clear what is deliberately excluded from modifiability. I know scripts are often set as "no modify" in spite of said permission being advertised for (and present on) the object itself, but that's a common thing that's pretty much expected. (Though it wouldn't necessarily be obvious to a newbie, I guess.) Deleting scripts only requires modify permissions on the object itself though, not the scripts. What if you had bought something advertised as modifiable and found that, while the permissions technically are as advertised, the object deliberately breaks if you change the color or texture, and there's no way to disable this without also disabling the core advertised functionality? Or what if an object is advertised as having transfer permissions, but it has a script that disables some or all of the functionality after changing owners, without this having been disclosed? I've seen modifiable objects before that have some kind of animation with alpha (like blinking eyes) likely using llSetPrimitiveParams, and it ends up resetting the color I've selected as an unintentional side effect. And a transferrable object can easily have a bug where it doesn't work after changing owner, if the creator forgets to do llResetScript (or at least replacing things like llListen) on owner change. Things like this are unfortunate, but they happen. (Though in the latter case, I think it's reasonable to expect the creator to fix the bug.) Even if it is something deliberate, they're technically telling the truth about the permissions. But it still seems dishonest, like false advertising, to not disclose it, if they're deliberately limiting what can be done with the object besides what's normally allowed by the stated permissions.

Sorry to hear you're involved in a pyramid scheme. Edit: Or is it an inverted funnel?

Oh, whoops, didn't know that. I've removed the creator's name. Should I remove the website link as well? How come? All Pastebin hosts is plain text. Even if the code I linked to was malicious, merely clicking the link couldn't execute it, only display it. I never said I expected that. It's also perfectly understandable for already-released updates to eventually cease being available to those who don't already have them. But if I don't get the latest update in time, I should still be able to make do with the outdated version I have. And generally, I expect to be able to, at least to whatever extent is technically possible. What if the existence of that exploit, or knowledge/hope that one could potentially surface, was a factor that motivated the purchase? If no exploit ends up being found, or the person ends up buying it too late to get the version they want, then it wouldn't be reasonable for them to complain. Even a product that disables itself isn't a valid cause for complaint as long as it were stated somewhere prior to purchase that it would. But if not, then that expectation of having a product continue to work, at least for local functionality, would be reasonable, and likely would have been a factor in the decision to purchase. It's like keeping a game console on an outdated firmware version so you can mod it. They're under no obligation to provide you with that version if you don't already have it, nor to allow you to connect to online services with it. But the product you purchased comes with the expectation that the software on it will continue to work perpetually, at least for local functionality. I don't think this is actually the case for the consoles on the market today, but if not, then that's only because they stipulated it somewhere in the fine print. If this was the case for the HUD I purchased, I wouldn't be complaining. And of course, it goes without saying that an exploit that affects the creator's server, or other users of the product, can be patched on the server, or in an update that other users can get to protect themselves. I'm only talking about when functionality is deliberately disabled, not just stops working because of the failure of an external dependency. If that's something you're worried about, then that's absolutely fine. Just make sure you're upfront about that functionality prior to purchase, and there's no problem.

I recently attached my Empower Magic HUD for the first time in years, and it told me it was an out-of-date version. Not a surprise considering how long it had been. What was a surprise was that it said it was disabling the version I had—what if I don't want to update? I don't see any warning of forced updates on the empowermagick.com website. Even worse, the landmark it gave me to get the update led to something completely different now, and when I asked in the group about it, they said it's "dead"; the creator is gone and it's no longer available for sale. (Yes, and for some reason the website is still up.) Since the HUD came with modify permissions, I decided to try rezzing a backup (it seemed to have deleted all the scripts) and deleting the updater script. As I hoped, it didn't trigger when rezzed, only when attached, so I was able to delete the script. But then when I attached the HUD, it said this: This time, all of the scripts were still intact, but it still refused to work. Now it's especially clear they were trying to force me to update, and on top of that, it seemed to be programmed so that an "Empower Adept" could prevent you from using what you purchased. Again, it was never disclosed that I was purchasing a product that could be taken away from me. When you pay for something, isn't the expectation that it'll be yours forever? That no one (except perhaps a Linden) can take it away from you no matter what, not even the creator? The exception is if it relies on some external server not operated by LL, but there was no reason to think this would in order to function. I tried tinkering with it some more, adding scripts to discover what I could about the black-box scripts it came with, and to try and break the lock mechanism. I was able to have it show up as unlocked and make some of the HUD functionality appear to work again, but the main functionality still didn't work. Here's my script though, in case anyone else has this problem and wants to try. Rez a backup copy of the HUD, delete the updater script, and add my script. My main question though is, is this type of behavior allowed? I feel like it could be considered a type of bait-and-switch if it's not clearly disclosed. I paid for the product based on what I knew about it, so failing to disclose something like this feels like a type of false advertising. Is this a common thing? I do remember seeing this kind of thing on at least one other product, but that was ages ago.

Okay, well maybe I was mistaken.