Sassy Romano

Insert a keyframe. You can do it for each IK handle.

"Generally CAN'T put another texture on them" Amethyst meant to say can't, it was a typo.

They can give someone some money in RL for no particular reason. Someone can give someone else L$ for no particular reason. If they're still struggling with this then person A can rez a cube, set it for sale and person B can purchase the cube, thus creating a transaction of a product, completely in line with the tools provided and compliant with the TOS.

Garvin Twine wrote: I also wonder why my review can be removed without asking or even telling me about it. LL: "We're going going to remove your review because it's deemed to be unfair" You: "I object!" LL: "Tough!" *deleted* That's why they don't bother asking. Being informed that a review is removed I can agree with. Depending on the exact wording, your review sounds like it was objective and thus should have remained. Just undertsand that the LL staff who attend to review don't really seem to pay much attention at all and just remove upon request. By the way Gavin, a "costumer" in English has its own meaning, it means someone who makes, rents or sells costumes. You wanted "customer". I offer this as help because i'm trying to learn a couple of languages and welcome the corrections to my terrible attempts so I hope you accept this in the nature in which it is offered

Yes they just have to be weighed to suit. However, if you're using a mesh body, then you also need the items to suit that body and not all mesh body creators do a good job of enabling other creators to make items because they don't give out their mesh body creator kits. This immediately limits your suppliers, in some cases to a very few creators.

Customer: "Hi, i've just bought your [product name] in SL and i'd like to use it in Sansar, can I have a free delivery there too please?" Merchant: "Sansar and SL are different platforms...yes I know the currency is the same... I understand your frustration but you'll need to purchase it again." Customer: "Wait, i've just looked and you're charging 30% more in Sansar in SL, you're a money grubbing thieving merchant, i'm never buying from you again!" I can honestly say that i'm glad I won't be selling anything in Sansar

llSay(-50, "5"); llListen(-50, "", "", ""); Ok, you have a common problem but you're going to fall into a couple of traps here. Your basic issue is that above, you're using a static channel, in your case -50. Anything else listening on that within 20m range, the range of an llSay, will hear that. Whether the message sent will be of any interest will depend on the listening script. You have options. You can either listen on a more unique channel, you can target only known avatar or you can construct a message that is broadcast on a static channel but where the message itself contains more identifying information. I'd be inclined to do two of these which is to use a more specific channel and send to only the expected avatar. First, how to get a more unique channel? Well one thing that avatars have which is unique is their UUID. There's a good tutorial in the LSL wiki on dialog menus (here: it teaches a lot of important things along the route http://wiki.secondlife.com/wiki/Dialog_Menus ) and to just pull the example from there:- integer channelDialog; default{ state_entry() { channelDialog = -1 - (integer)("0x" + llGetSubString( (string)llGetKey(), -7, -1) ); }} So what this snippet does is assigns a variable at the top, then uses llGetSubstring to grab a bit of the avatars unique UUID and then ensures it's a negative channel. Just be aware that others may use the same snippet of code so you could still end up sending messages to other items belonging to this avatar. Another option would be to use llFrand to generate a random number for the channel. Having done these, lets now look at llRegionSayTo. http://wiki.secondlife.com/wiki/LlRegionSayTo Function: llRegionSayTo( key target, integer channel, string msg ); This then is "where is it going to? on what channel? what am I sending?" Looking in the Caveats in the wiki, the one of interest is:- Text sent to an avatar's ID on non-zero channels can be heard by any attachment on the avatar Wel this is handy because you know how to get a unique non zero channel, that's above. You can find out the key of the destination avatar, well it's the owner of the garment, probably the same as the one using the HUD, so the target is llGetOwner() and now if you send the message to the target of llGetOwner() on a non zero channel, all attachments (your clothing item) will hear it. Yay! But wait there's a problem. If you use the exact same script for multiple items of clothing, how would your texture change account for changing texture of a jacket vs pants as both will hear it? You could hope for the best that a random channel (llFrand) wouldn't collide, or you could be more intelligent with your message. By that I mean instead of just broadcasting on a channel "set texture 1", you would broadcast "pants, set texture 1" or "jacket, set texture 1". If you do this, then your receiving script needs to do a tiny bit more work first because it needs to parse the message and split out the parts. llCSV2List can do this and what you'd end up with in my example would be list entry 0 (lists start at 0) would be a string called "pants" or "jacket" and list entry 1 would be a string of the texture UUID. Now you would have an outer IF loop that first tested for this message. Alternatively, you could make your HUD no modify and give it a name that you tested for in your listen because the name of the sending object will be in listen event as the name (second parameter). There is one final gotcha. You have your listen defined in the state_entry. Unless this script is reset on transfer to a new owner, the listen will be listening to the previous owner. This is described as the second caveat in the wiki page for the listen event When an object changes owner any listen registered with llGetOwner will not automatically update itself until the script is reset. The scripter can catch this scenario per the example below. changed(integer mask) { //Triggered when the object containing this script changes owner. if(mask & CHANGED_OWNER) { llResetScript(); // This will ensure the script listens to the new owner, and doesn't continue listening to the creator. } } There's plenty that you will gain with experience, it's all part of the journey and I hope the above gets you a little further forward. I would strongly recommend that you go through the dialog tutorial though as it starts simple and builds upon the problem, tackling issues very similar to the ones you're going to come across here. The only difference really is that you're sending messages upon hud button press vs blue menu buttons, they're almost identical otherwise.

If they're what I'm thinking of, you can already get those on marketplace.

If you read the many pages of the search beta thread, you'll see examples of how to properly get rid of demos which LL refuse to address. They believe it's better to return all the straw in the haystack but allow you to adjust the location of where the needle might be. Demos for all products isn't feasible. Not all items lend themselves to methods of demoware nor is any investment in time worth it.

That's not going to work for a start because you're resetting variables each time you enter the function. There's more to the problem, whole script please.

This is not new and has been reported multiple times in the correct format. When it was found that the purchaser could leave a review, LL fixed this by preventing the purchaser from doing do:- https://jira.secondlife.com/browse/WEB-2660 However, they forgot that it is completely sensible to allow the person who is actually in the position to reivew the item to be able to do that and that one is "deferred" while they play with more interesting toys:- https://jira.secondlife.com/browse/WEB-4420 Discussion about demos being irrelevant in search is not considered an issue. Although LL is in the process of twiddling with search yet again, they are struggling to grasp the concept that returning irrelevant results when trying to address relevance is counterproductive. Thus they have no present intention to deal with removing demos from the search results. It's a bit like when trying to find a needle in a haystack, just moving the position of the needle nearer to the top. Thread for discussion:- https://community.secondlife.com/t5/Merchants/Marketplace-Beta-Search-New-Information/td-p/2981178

Because if there's a funds transfer or the TOS changes, you're not around to support it and haven't agreed to the terms of service. Why should someone be participating in the platform if they're not in acceptance of the current terms? They are disconnects as far as I'm concerned.

tish Celt wrote: no other games you can't convert the ingame money to RL$ and its harder to move it from 1 account to another all some one needs to do is get your password log into your account buy a **bleep** load of L$ transfers the L$ to another Avatar then sell it to a buyer for RL $ Other scams exist, e.g. http://forum.worldoftanks.com/index.php?/topic/314161-beware-when-you-accept-a-gift/ Also, the part about "all someone needs to do is get your password"... and they're doing that how? (The follow up posts have told you)

What he said but he beat me to it. I've said the some of it already in the thread. Expecting the review system to warn people is like waiting for the obligatory three children to be killed crossing the road before the authorities acknowledge a black spot and install safety features. Look at Apple, they police their appstore very carefully, how about if they ran a "10 bad reviews and you're out" system? Can't see it somehow. Again, there are NO negative issues that surround each listing showing the last logged in merchant date and requiring merchants to accept the TOS in order to continue selling (and to ideally reset a TTL before auto de-list. Also, there IS a criteria for this:- "There is no metric for how long someone has to be "away" from SL to 'lose the rights to their account'. Example, if someone is a premium avatar and their account falls into arrears, then after a period (90 days?), the account is suspended and inventory deleted. Yep deleted. Happened to a friend of mine. So, you say "well that's their problem!" and I don't disagree but i'm curious now that VMM is integrated with inventory as to just how much "integration" this amounts to. What happens to a account that is in arrears, that has Marketplace listings that are VMM sourced when inventory is subsequently deleted by LL? One for the very active Linden input in this forum...I wonder if they accounted for this scenario?

Darrius Gothly wrote: Linden Lab: YOU are the only party capable of doing the right thing. And yet, you continually condone (through both inaction and direct avoidance) illegal acts. You want to avoid lawsuits and criminal entanglements? DO THE HONEST THING! Not just inaction and avoidance but take a 5% cut of the action. I can partly understand when they're not aware but once made aware, the result is usually "TOS says caveat emptor so tough!" even when they actively remove the product, eventually. What I can't understand is the apparent refusal to implement very simple measures that give the potential customer information such as last logon date of merchant which is ridiculously simple and has no negative reasons to NOT do so. *baffled*

ChinRey wrote: Sassy Romano wrote: That'll be the upgrade price to v2 - "Rigged Sphere" Oh, I see. Better not take that idea too far though. Possible DMCA risk down the lane: http://dilbert.com/strip/2014-12-29 Mine will have rounded corners, i've already got the design patent in

That'll be the upgrade price to v2 - "Rigged Sphere"

In any given month, 80% of listings have no sales. Like I said, the old stuff has been largely superceded, I have no problem with it being there as long as it requires a merchant who has complied with current TOS and who is prepared to reset a TTL on a listing. If they're neither of those, dump it. Your edit 1 demonstrates that its removal would reduce the out of date dross Edit 2, yes it happens but comes back to the issue of support, there is none so show us the date of last login and let the customer decide or just remove it. It's very much an edge case.

Well I hope you're not going to feel that my mesh for mesh sake is appropriate here? There are just some things that you can't do properly with prims:- https://marketplace.secondlife.com/p/Sassys-Rigged-Cube/5366291

Chic Aeon wrote: Can't creators who are no longer logging in just take their money out via the website? I DO know that when the new TOS comes out it shows up on both the website and the login screen -- you can accept either place. Yes to both and showing a "last logged in" date on the listings would show this to be the case. However to circumvent both the new TOS for the merchant avatar and to hide logins, they could also have a "thief prim" inworld which allows an alt to transfer funds but that's only going to be relevant for wilful actions described. Genuine dormant accounts do not help anyone. Animations do age though, just like content. Feel free to compare a keyframed animation done in the likes of Qavimator against a recently imported high quality MOCAP. I know what you're getting at but for most content, there's a high chance that there's a better one that's newer.

I don't care. If the seller has LEFT for good then where are the L$ going, nowhere, just sitting in an account, nobody is disadvantaged by this content disappearing. As I said, it will likely be old, stale content, long since surpassed. I'm not after a mathematical outcome, just a common sense one that says "if this merchant isn't here and hasn't accepted the current TOS, then content should not be onsale as it could be in breach of TOS" It's that simple! I've long asked for a "last logged in date" to be shown against listings, a VERY simple method to show the likelihood of a merchant being around to offer support, clearly this is also deeply buried in the "too difficult" bin.

Freya Mokusei wrote: Sure, maybe. I don't think it's quite as reasonable as you seem to, but I can't say it is likely to affect me either way. LL already have the content in their hands, why should they chase up the merchant? Reckon it'd be insurmountable to change this policy so late in the game, and that no-one's really motivated to produce a Marketplace solution that doesn't have everything. Looking historically and with regard to maintaining SL as it is, there's no downside (to users, LL, merchants) to their current strategy. Service quality across SL does not suffer. This kind of change would have to be done at the beginning of a service, before reasonable limits to behaviour by service operators is set in stone and while the userbase is in a position to be well-informed about the change. Why change it? Because it would go some way towards chaning the perception that SL is rife with dishonest merchants, lack of customer service, thieves, fraudsters and similar perspectives. I disagree that it can't be put in place now. We periodically have to accept a change to the TOS, why should it be the case that content should continue to be on sale by people who have not accepted the current terms of the platform. That's a disconnect for starters. If someone isn't a current and active participant then i'd challenge them to justify why their content should remain on sale, if they're not active, what impact would it have on removing it? It's likely to be old and stale. Simply put, if someone cannot login periodically to reset a TLL on their listings, the listings don't belong here!

Or that they don't accept that is the problem that it is. They're not customers of this issue therefore it doesn't exist as a problem.

You gave up a job for *that* job in *that* timezone. It is NOT a universal thing, there are jobs for all timezones. When I had staff, I especially wanted them to cover the times when I was not online.

Crystal clear to me.