Jump to content

LLSetPayPrice Issue


UbiquitousStudio
 Share

You are about to reply to a thread that has been inactive for 2899 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hello, I have a script and my goal is to get the player to pay into it and it captures the amount, if the amount does not equal the specified numbers just don't go the state and return funds. Here is my script here for you to try to understand better.

default
{
    state_entry()
    {
        
    }

    touch_start(integer total_number)
    {
        llRequestPermissions(llDetectedKey(0), PERMISSION_DEBIT);   
    } 
    
    run_time_permissions(integer perm)
    {
        if (perm & PERMISSION_DEBIT)
        {
            state idle;
        }
    }
}

state idle
{
    state_entry()
    {
        llSetPayPrice(10, [10 , 25, 50, 100]); 
    }
    
    money(key id, integer amount)
    {
        // THIS IS WHERE MY ISSUE IS //
        // If money is not right amount
        if(amount != 10)
        {
            // Send their money back
            llGiveMoney(id, amount);
            llOwnerSay("You paid the wrong amount, here is your money back and please try again!");
        }
        else if(amount != 25)
        {
            // Send their money back
            llGiveMoney(id, amount);
            llOwnerSay("You paid the wrong amount, here is your money back and please try again!");
        }
        // If money is the right amount.
        else
        {   
           state funds; 
        }
    }       
}

state funds
{
    state_entry()
    {
        llOwnerSay("State Funds");
    }

    touch_start(integer total_number)
    {
        
    }      
}

The 10L works fine, but when I added 25 it doesn't work. I tried to do || with it and no luck. I am probably just not thinking of something cause I do this but any help will be appreciated!

Thanks

Link to comment
Share on other sites

Think through the logic of what you wrote in the money event. Suppose that the person clicks the L$25 option.  The first task asks "Is L$25 NOT equal to L$10?".  The answer is TRUE, it's not.  Therefore, there's no point in asking the second question: "OK, if the first answer was NO, is L$25 NOT equal to L$25?".  The answer to that second question would be FALSE, but you never got to ask it because the first answer was TRUE.

else if always means exactly what it says: "Ask this question only if the answer to the one before it was FALSE.

You have a more serious logical question to ask yourself, though.  If you are always going to refund money to anyone who pays L$10 or L$25, why are you even giving them the option to pay it in the first place?  The llSetPayPrice function lets you offer only the specific choice (or choices) that you want. Don't make an option available if you don't want people to use it.

In fact, I'll go farther than that. It's hard to imagine many situations where it's really necessary to refund L$ at all.  Unless you find yourself with one of those rare situations, it's probably smart to avoid ever allowing PERMISSION_DEBIT.  Doing that can increase your risk of having someone find a way to drain your account.  Until you are very confident that you know how to anticipate the sorts of tricks a bandit can use against a poorly written script, I suggest avoiding refunds.

  • Like 2
Link to comment
Share on other sites

Read through that response 10 times now and still can't figure it out. I get what you are saying about it asking if the 25L is not equal to 10 cause the amount is 25L when they click 25L I just don't get how to go around it, do I write different money events?

Nevermind I read through that edited part and now I am rething even doing refunds. The reason refunds were even a thing was because it was all connected to mysql and I wanted to make sure what was being paid is paid, but I can do it a easier way where I just grab the amount paid and just add that. I am just complicating things way to much.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2899 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...