In the process of trying to create a repo test case, I also observed inconsistient behaviour int he triggering of the money() event. Again, exact duplicate copies of a simple object with 2 prims and two scripts results in one object that would only trigger the money() event in sometimes when paid and the other always.
(I may open another bug for that issue - but mention it hear in case it is related).

I'll also test in other locations in case there is something wrong with the state of Sandbox Goguen.

In the original non-working vendor, a recompilation of the scripts (back) to LSL cause it to start working. Them, recompilation again into Mono and it also worked.

So - not sure where the problem is/was. How does the 'payable' object state based on if a money() event is present get maintained? Could there be a problem with re-compilation and maintenance of that state that persists through resetting all scripts?

Without even being able to reproduce it with the original device now - not much use leaving this bug marked as a showstopper. I'll downgrade it.

I observed this:

1. Created two prims and linked them
2. Created a new script in the root that called llSetPayPrice(-1,[1,-1,-1...])
3. Created a new script in the child prim with a money event that just chatted 'payed'
4. Reset all scripts in selection (without 'Edit linked parts' checked)
5. Right-click payed the object - Fast pay dialog showed, but when I clicked the "1", nothing happened (assume money() event not triggered). Repeated payments yielded no result.
6. Unlinked and relinked the object without unselecting in between
7. Right-clicked, payed again, still no result.
8. Unlinked and observed that root has no Pay.. menu option on pie menu (as expected - no money() event) and former child-prim has usual Pay dialog (without L$1 fastpay setting) - again, as expected.
9. Payed the former child prim - saw "payed" chat output
10. Relinked in same configuration
11. Right-clicked and Payed the L$1 fastpay option and observed 'payed' in chat.

So - it is inconsistent but somehow related to relinking. None of the scripts were edited/recompiled/reset during that sequence.

I'll mark it related to VWR-8744 just-in-case.

I have reports of it happening in Caledon Penzance, Caledon II, and Caledon Primverness so far.

If this is a viewer issue, then I'm not sure which client version I was using when reported - whatever client was the download for the beta grid at that time. I've been using 1.21.0 RC (95157) on a main-grid sim with 1.24 after the Mono rollout and been using and working on scripts in the same device without observing any problems even once.

Can someone with server/viewer code knowledge enlighten me as to how the flag for showing/not-showing the Pay.. option gets computed and propagates to aid in diagnosing it?

• When does the viewer get notified about if the Pay.. should be available for an object - when the user right-clicks, or is the flag attached to every object in view when it is streamed to the viewer?

• When the flag is sent to the viewer by the region, is it computed dynamically at that time, or is the flag stored by the region as an object property and just updated in response to relevant changes (re-linking, addition/removal of scripts, changes in running state)?

As I mentioned, the money() event is in a script that is in a child prim in this case. However, although the vendors are 'new versions' the scripts and code for the money() event etc. is basically unchanged. All the vendors had a 'reset all scripts in selection' performed before being taken into inventory for 'packaging'.
The script with the money() event only has one state - so it isn't an issue with reset/init states or state change timing.

One other piece of information that may be relevant: the scripts in the vendors were all install using llRemoteLoadScriptPin() buy our 'build' device.

More info if/when I have it. I'm waiting on one customer to try both our old LSL vendors and the non-RC viewer.

So, it is definitely a problem with the RC viewer.

I am going to experiment with child-prim link ordering next (as it doesn't matter with our devices and hence they're probably not linked consistently with respect to which numbered child prim contains the money event).

Using the RC viewer (1.21.0 95157), create 2 cubes and add this script them:
default
{
state_entry()
{
}

touch_start(integer total_number)
{ llSay(0, (string)llGetLinkNumber()); }


money(key agent, integer amount)
{ llSay(0,"payed "+(string)llGetLinkNumber()); }

}


Then create a 3rd and put this script in it (same but without money event):
default
{
state_entry()
{
}

touch_start(integer total_number)
{ llSay(0, (string)llGetLinkNumber()); } }
}

Link all three together so that the root prim is the one without the money event.

• Right-click the object and notice that Pay.. is available. Pay the object L$1 and notice that there is no chat output (assuming neither of the money() events were triggered).
• Right-click either of the child prims and Pay.. them and you'll see the expected chat output

Repeat in the release viewer (1.10.15):

• Right-click the object and notice that Pay.. is greyed-out (I assume that is correct as the root prim has no money() event, but I'm not 100% on the spec'd behaviour)
• Right-click on either child prims and Pay.. them and you'll also see the expected chat output.

My setup:

Create two prims and link them together. In the root prim place this script:

default
{
state_entry()

link_message(integer prim, integer num, string str, key id)
{
if (num == 201) { llMessageLinked(LINK_ALL_OTHERS, 101, "", NULL_KEY); state pay; }
}
}

state pay
{
state_entry()

link_message(integer prim, integer num, string str, key id)
{
if (num == 200) { llMessageLinked(LINK_ALL_OTHERS, 100, "", NULL_KEY); state default; }
}
}

In the child prim place this script:

default
{
state_entry()

link_message(integer prim, integer num, string str, key id)
{
if (num == 101) { state pay; }
}

touch_start(integer count) { llMessageLinked(LINK_ALL_OTHERS, 201, "", NULL_KEY); }
}

state pay
{
state_entry()

link_message(integer prim, integer num, string str, key id)
{
if (num == 100) { state default; }
}

money(key giver, integer amount)

touch_start(integer count) { llMessageLinked(LINK_ALL_OTHERS, 200, "", NULL_KEY); }
}

Reset the scripts so they are in no pay mode, there is currently no pay option on either prim.

Touch the child prim to put the scripts into pay mode.

Note that the pay option is available on the root and child prims.

The release client only shows the pay option on the child prim.

Additionally, my firing ranges refuse to show the pay option at all, even though they are using a variation of the above procedure. They work fine under the release client.

Have a script with two states (my example above is valid for this test) one with a money event handler, one without. Start in the no-money event state and no pay option is displayed in the pie menu. Switch to the money event state and the pay option becomes available. Switch back to the no-money event state and the pay option is still available. (In a MONO script, the pay option becomes disabled again).

Example object available on request.

After 1.25 server, my script started showing this. I have a game that accepts payment and after that, changes to another state that has no money event but the Pay pie menu is still there and you cna pay the machine. I am trying to reproduce the problem but it does not happen. Only in my game. I reset it, no change. I recompile; no change. I am stuck.

Please help.

Mitralone Yalin