Jump to content

PeterCanessa Oh

Resident
  • Posts

    4,476
  • Joined

  • Last visited

Posts posted by PeterCanessa Oh


  1. Valareos wrote:

    Seems there is a wee bit of confusion.

     

    the sploder is not mine, ive gotten it from marketplace (its a grid wide sploder,) The secodn cahnce drawing takes no lindon, nor does it give lindon, so it is not illegal.

     

    Yes, there is a bit of confusion - the sploder is yours, you got it form the marketplace.  If there is a fee to play it and there is a random factor in its payouts it is illegal to use because it is contrary to LL's gaming policy.  The second chance thing you're talking about takes a fee in the non-monetary form of an SL "thing of value" and, randomly, gives a similar prize.  As Qie said, LL almost certainly won't do anything about it but both machines are in breach of the rules (and possibly law although it's even less likely the RL police will do anything).

    http://wiki.secondlife.com/wiki/Linden_Lab_Official:Policy_Regarding_Wagering_in_Second_Life  Just about every possible lottery, raffle, sploder and non-competitive game is illegal under this policy if there is any sort of fee to pllay it and any sort of prize.

    I'm only really posting this to point out that you might be open to RL criminal charges and should get legal advice - LL have banned all sorts of things that didn't even have a random element while left other things completely wild.  Until someone takes them to court (!) I doubt they'll take any notice of their own policy (ie; it's there because the law says it has to be there but beyond that they ignore it).

     

  2. Sounds and textures referenced by UUID don't have to be in an object's contents, as you said.  They live in someone's inventorym possibly the (LL provided) 'library' part and are therefore in the database.  They have many, many neighbours but as far as I know there is no way to identify 'just' from a UUID which are sounds.

  3. I really am not sure what your objection is.  Having boiler-plate code is not unknown ^^.  Please see http://community.secondlife.com/t5/LSL-Scripting/Trying-to-sell-multiple-items-from-a-single-thread/m-p/2328881#U2328881 which asks about a multi-vendor.  A solution would be to track multiple people and which option they had selected, until the transaction was complete.  Such a list would eventually overflow though so you need a mechanism for timing-out and removing those who take too long.  Unlike closing a single listener this is a case where it is (fairly) important that people are removed at the correct time.  On the one hand you don't want to make things difficult for a potential customer, on the other you can't risk the script crashing.  Not only that but I'll probably have single script running the whole shop, not just one vendor - the overhead of using the same queue for a listener is much less than the alternatives.


  4. ChaosRaine wrote:

    ...it shows how new I am at scripting.

    We all were at some time, keep trying.

    There are several things to consider when scripting a multi-vendor.

    1. Someone may "touch" one option, change their mind and want to "touch" a different one - you don't want to force their second click to be a 'pay'.
    2. Someone may "touch" and not pay (or pay the incorrect amount and not re-pay the right amount) - you need to time-out waiting for them at some point to let someone else use the vendor.
    3. Between an original touch and final, successful, payment any number of other people may touch as well - they shouldn't go straight to 'pay' but neither should they change the original person's selection.  you need to decide what to do with them (either track multiple people at the same time or just tell them to try again later).
    4. The money() event is not raised for L$0 transactions - you need a different method for giving-away free items/demos.

    The simplest solution, if you have 4 or fewer options, is to make sure your prices for each are all clearly displayed and then just have click-pay,  Let the customer decide which price they want to pay, check it matches one of the options and give them the appropriate item.

    The drawback of this approach is that they have to select the correct pay option, but it means 1) they only have to click the vendor once, 2-3) your script handles everything in the money() event-handler, 4) if needed have a L$1 demo/freebie and immediately refund the money.

     


  5. LepreKhaun wrote:

    All your elaborate dance does is time out 30.1s after the last touch event is triggered, the same as mine. 
     Nothing more, nothing less.

    If you mean "close the listener" after the last touch event then you are correct.  The something more it does is remove earlier touchers at the appropriate time.  That makes it trivial to add additional functionality might it be required which, I am trying to point out, is what I use this skeleton for.  I know it's overblown for a simple listener, isn't that what I said when I agreed with you last time?

    Rarely, however, do I deploy scripts that are simple listeners; they usually have much more going on, making this skeleton a fully-functional, timed,  internal message queue.  I only posted that script to illustrate the approach I took - it's a toy^^ Just be glad I left out the rescheduling (which actually isn't much more than an llListSort() with the appropriate stride) and repeating parts.

    I'm talking about something like automatic door-closers, texture-changers, sim-mappers, etc. all at the same time and different speeds, amongst which a trivial multi-listener handling dialog conversations is 'just another entry' in the queue.

     

  6. Well there are several problems in that, although it isn't easy to read!  (Click the icon above the post message box that looks like a clipboard with a 'C' on it - that lets you post formatted code).

    The first thing that happens is the default state, state_entry() event-handler is run.  There you check llDetectedTouchFace(), which has no meaning there "For the touch category of events only.".  That is, you can't check which face has been touched until/unless a face has been touched!  Then again, you're storing the meaningless result (into integer Face) but not doing anything with it anyway.

    You then ask for debit permission and go into state cash.  Ok, but the script has no way to reach the other states.

    In state cash, state_entry() you "llSetPayPrice(price, [price ,PAY_HIDE, PAY_HIDE, PAY_HIDE]);" but price is 10, as defined in the first line of the script and never changed anywhere else.

    Then, when the object gets paid you ask for the payor's name but don't do anything with that and either refund the money or give them that one thing.

    Apart from the logic not working there is the problem that someone else might touch, or pay, the object while someone else is already carrying-out a transaction.

    Odd as it may seem I'd recommend that you set your different prices into the llSetPayPrice() and just give them whichever object matches the amount they pay you.  Much easier that way.

    • Like 1
  7. There are almost 30,000 sims in SL, sub-divided into millions (probably) of "places" so it isn't possible for us to give you an exhaustive list, or even be familiar with them all, especially as they change so frequently.

    In-world search for "electric chair" gives me 11 results, although I can't vouch for their usefulness:

    Restrained freedom island
    Builders depot
    Post mortum designs
    Grot family shop
    *The house on haunted hill ...
    **M&E Bondage**
    DEF! Clothing & Accessories
    Gadgets, Gimmicks, Gizmos & Invisibility Cloaks
    RBH Stores: Robeck Land
    Castelo Reseller Full Permissions Freebies
    Evaki and JSF Desgins: Your Christmas HQ

    Try a few.

  8. Duplicate of http://community.secondlife.com/t5/Everything-Else/what-places-are-there-in-second-life-that-have-a-electric-chair/qaq-p/2328737

    Please do not start multiple threads asking the same question.  You can edit your original question using Options > Edit on that post to add information.  You can also use 'permalink' under any respondant to type a reply directed at them (yes, we know 'permalink' doesn't mean anything and we don't like the interface here any more than anyone else does).

    • Like 1
×
×
  • Create New...