Jaymes Capalini

Hmm... interesting. It didn't allow me to right click to pay. So it seems that the issue is related to the pay on left click function. So that seems to solve it for now.

But wouldn't that only suppress the "left click to pay" option? I would think that you could still right click to pay the object. I'll have to go back and test it.

Nope. That was actually the reason that I tested it out on an object with your script. I knew I didn't have any payment scripts in my object, but wanted to be sure. Next step is to try a different viewer.

OK... new information here. I went and checked out your split script that you linked to earlier. Guess what. Same thing happens. Steps I'm taking: Edit the script, and change the split percent (gSplitPct), and key (gSplitKey). Save the script. Test the script by Allowing Debit Permissions. Result: Left clicking allows me to pay 1,000 lindens. This is split 75/25 as specified, with my alt (who is getting rich from all this). Now, reset the scripts in the object. This time choose "deny" on the Debit Permissions. The object still shows a payment option when i hover it. When I left click, it still allows me to pay 1,000. However, now the money does not split.

Rolig: Thank you for helping on this. I really appreciate it. Unfortuantely that doesn't really address the core problem. Setting all of the pay options to PAY_HIDE, and the way I had it (with one being "0") both did the same thing. I have now changed it so that the default state returns the llSetPayPrice to it's default llSetPayPrice(PAY_DEFAULT, [PAY_DEFAULT, PAY_DEFAULT, PAY_DEFAULT, PAY_DEFAULT]); This does reset all the values back to what they should be. However, it doesn't address the problem that the object is accepting money when there is no money section in the state it is in. It still does that.

The llSetPayPrice line that you removed from default is actually my bandaid. It keeps the unit from accepting money even after the weird state reset. The llSetTimerEvent was left over from an earlier attempt to fix. The script works great for me too, when have just edited the script and saved it. No problems at all. But when I reset all scripts in the item, from the build menu (Firestorm 4.3.1), it goes into the wonky semi default state that still allows payment.

Yep, that is basically the approach I have taken. There is nothing in the default state except a check for debit permissions. It only moves to state Money if those permissions are granted. I know it seems like it is still in state Money, but it isn't. it is executing commands (like setting the llSetPayPrice to zero) that are only in the default state. Also it is firing the request for debit permissions, which also only exists in the default state. Here is the script itself: integer intCorrectAmt = 10;integer intShareAmt = 1;default //not accepting payment{ state_entry() { llSetPayPrice(PAY_HIDE, [0, PAY_HIDE, PAY_HIDE, PAY_HIDE]); llRequestPermissions(llGetOwner(),PERMISSION_DEBIT); } run_time_permissions(integer perm) { if (PERMISSION_DEBIT & perm) { state Money; } }}state Money{ state_entry() { llSay(0,"Now accepting money!"); llSetPayPrice(PAY_HIDE, [10, PAY_HIDE, PAY_HIDE, PAY_HIDE]); llSetTimerEvent(10); } money(key id, integer amount) { if (amount == intCorrectAmt) { llGiveMoney("44b47a0a-90d2-444c-b30e-775f27e03e86",intShareAmt); //Here I fire a llMessageLinked function that allows other scripts in the objet to take over. llSay(0,"Thank you!"); } else { llGiveMoney(id, amount); } }} NOTE: As you said, it shouldn't really require the check to ensure that the money paid was the correct amount. I threw that in as a just in case.

That sort of addresses the issue. Yes, I do have the object set to pay when left-clicked, and I did wonder about whether that could be changed. So thanks for that tip! :matte-motes-big-grin-wink: I do limit what the customer is allowed to pay so that they can only pay the actual price of the item. So, I don't really need PERMISSION_DEBIT for that. However, I do use PERMISSION_DEBIT to split money between the creator (i.e. me) and the owner of the object (whoever wants to put one out). The purpose of my script is to only take money and distribute product if the owner of the object has agreed to split the proceeds. What is not making sense to me is that the script is acting like there is a money handler in the default state, when there clearly is not. What I have done for now is similar to what you suggest but goes one step further. I have set "llSetPayPrice(PAY_HIDE, [0, PAY_HIDE, PAY_HIDE, PAY_HIDE]);" in the state_entry of the default state, so that even if someone does attempt to pay, it doesn't allow them to as all the amounts are hidden and no manual payment can be done. changing the click action would only prevent them from paying with a left click, not at all. This isn't really a solution, but it is an effective bandaid I suppose. At least I'm not taking money from people and giving them nothing in return. But it's not the solution i'm looking for. The object shouldn't be trying to take money at all. This seems to be a bug in the money handling of SL. It is acting sort of like an object property setting (i.e. llSetText) where once the setting is made, you have to issue a new command to take it off. That's ok, but what command would take it off?

I have an item that I would like to distribute to others on a free or discounted basis, so they can put it out to sell items from. Essentially an affiliate vendor (though it is, in fact, a soda machine). I have two states in my script. One state is default, the other is "Money". The default state has a llRequestPermissions(llGetOwner(),PERMISSION_DEBIT) command in state_entry(). It also has a run_time_permissions(integer perm) section that checks the value of perm & PERMISSION_DEBIT. If TRUE, it changes the state to "Money". The Money state has a money section in it to allow the item to accept payment, which puts a product delivery script into motion. All this works fine, the first time I run it after saving changes to my script. It comes up in the default state, requests debit permission, won't accept money if the user doesn't allow PERMISSION_DEBIT, changes to the Money state if they do. Everything is fine. HOWEVER... I noticed that if I then go and edit the item, and reset scripts, it then reissues the request for debit permissions, but regardless of whether the owner grants debit permissions, it still allows money to be paid to the object. This is very odd, because they object only has a "money()" section in the "Money" state. So, I don't know why it is accepting money at all. And it can't be in the "Money" state itself, because it doesn't execute any of the statements in the money() section. To further confuse it, there is a llSetPayPrice() function in the "Money" state that limits the input to 10L. This also seems to be working in this quasi state, because the unit will still only accept 10L. But again, it does nothing when paid. Anyone have any ideas as to what to do about this?

I've taken the quiz and have payment method on file. My account shows that I'm good to go on both. But, on the one mesh item I have on the marketplace, it still won't allow me to select the radio buttons for partial mesh and 100% mesh. Any idea why?

OK yep.. i'm so used to having my head stuck in a script that I forgot that.

OK then Out of curiosity. If the prim pole was replaced with another mesh object, would it still act the same way? In other words, is this because of linking mesh with non mesh items, or is it just the way mesh is?

I've got an item that is a Christmas tree made with strands of Christmas lights that are meshes, attached to a root prim that is a cylinder (pole). There are 8 strands of lights, so eight mesh items, arrayed around the pole. The cylinder is definitely the root prim, but I noticed an odd thing when I attempt to rotate the object. It does not rotate around the root prim. Instead, it picks what appears to be a middle point of all the objects in the set, and rotates around that. Is that normal for a link set with mesh objects in it?