MLPV2 questions & bug reports

left & right with no trapping?
kinda curious why you didn't use shift+ for all those controls.

What i am trying too acheive is Props off.

Then all poses still rezz at position.

I do not need "prop on" too rezz the prop instantly, just to enable props again for next pose change that is propped!!

Is anyone getting a math error (script error) when they rez an item with MLPV v2.4l or m2 onwards?
I seem to get that with slower sims. Works fine on fast sims. I've gone back to using 2.4d which seems like a stable release, as I don't want to take up any sim script time with potential script errors. The math error seems intermittent (like every 3rd attempt when I rez a bed). Is there any way to make it more lag tolerant?

Trapping?

As stated above, it doesn't use left and right arrow, leaving that for camera control. It does use up and down arrow, which I don't like stealing from camera controls, but there's no other option if we want adjustment on 3 axes.

See my post above, which lists the only keys we can respond to in scripts.

Please try punctuation. It's hard to tell what you're trying to say here. I *think* you're saying that all you need is a global "enable/disable" for props, but there are other ways of interpreting it, and I hate guessing.

Please go to Preferences and enable sending script errors to chat, and post the full chat for when it fails. Not just the error message, but any chat from the bed before and after it. That might give me a clue what's going on when we get this error. I haven't ever seen it.

I'm thinking of fixing MLPV2 to work properly when deeded to group.

Currently, it has a bug in that it uses llOwnerSay(), which goes nowhere when deeded to group. That's easily enough fixed, so it will whisper in this case.

After being deeded to group, the original owner still has access to OWNER menus. This is ideal for public spaces, but not for rentals.

I'd like to provide sane behavior for rentals, though. Here are some possibilities:

1) "RENTAL" button that gives group-tagged avs access to OWNER menus (e.g., OPTIONS). It would be a toggle, and only the original owner could use the button. Of course, this would only be available if you use the new MENUITEMS notecard.

2) Add an optional access script, allowing the owner the ability to configure, by notecard, names of avatars who can use the OWNER menus. This would probably require another script, which I don't like, but it's a much more correct solution to the rental case.

Comments, suggestions?

After I rez the bed, this is what I get:
[8:33] Bed V7: 0 sequences (~sequencer: 35606 bytes free)
[8:33] Bed V7: 0 poses with swaps (~swap: 51398 bytes free)
[8:33] Bed V7 whispers: relax1
[8:33] Bed V7 [script:~swap]: Script run-time error
[8:33] Bed V7 [script:~swap]: Math Error

The pose balls actually appear in the centre of the bed, but when I click on any action, they will no longer move into position. Only action that works is then Stop, which will make the balls disappear. Selecting an action after this will only rez the ball in the middle of the bed again. The only way to fix this is then to delete and rerez the bed.

I have an idea for both your renter issue, and your take controls dilemma.

renter issue:
essentially, leave verification of owner level privs to an outside object, so it can easily be centralized, so that adding a renter doesn't mean tweaking all the stuff on that parcel. most rental systems have a method of providing a list of who's renting what.

 //-- at the end of the activation event code
 //-- only triggers if the triggering agent wasn't authorized
else if (renter_flag) {
  llRegionSay( check_up_channel, (string)id + ":" + llGetPos() );
}

 //-- in the listen event
if (speakerOwner == owner){
  if (llSubStringIndex( heard, parcel_name )){
    //-- add trailing key to the list of people to test for owner privs
  }
}

control issue:
only take controls when asked (or release them when asked) until them monitor nonsensical combo's of key presses (accept = true) but don't trap them (pass_on = true also).

integer ControlsActive;

//-- monitor only controls
llTakeControls( CONTROL_UP | CONTROL_DOWN, TRUE, TRUE );


if ((CONTROL_UP | CONTROL_DOWN) & level){
if (ControlsActive = !ControlsActive){ //-- yes this is an assignment!!!
//-- take extended controls
}else{
//-- release extended controls with
llTakeControls( CONTROL_UP | CONTROL_DOWN, TRUE, TRUE );
}
}else{
//-- your extended controls detection routine
}

I originally suggested monitoring rot_[left|right] because they wouldn't trigger your positioning code, but I'm unsure without testing that you can overlap controls in the same script with different pass_on settings. instead you may be able to avoid some accidental triggering with active keys by only checking level, and dropping small sleeps into the control event.

I have an idea for both your renter issue, and your take controls dilemma.

renter issue:
essentially, leave verification of owner level privs to an outside object, so it can easily be centralized, so that adding a renter doesn't mean tweaking all the stuff on that parcel. most rental systems have a method of providing a list of who's renting what.

 //-- at the end of the activation event code
 //-- only triggers if the triggering agent wasn't authorized
else if (renter_flag) {
  llRegionSay( check_up_channel, (string)id + ":" + llGetPos() );
}

 //-- in the listen event
if (speakerOwner == owner){
  if (llSubStringIndex( heard, parcel_name )){
    //-- add trailing key to the list of people to test for owner privs
  }
}

control issue:
only take controls when asked (or release them when asked) until them monitor nonsensical combo's of key presses (accept = true) but don't trap them (pass_on = true also).

integer ControlsActive;

//-- monitor only controls
llTakeControls( CONTROL_UP | CONTROL_DOWN, TRUE, TRUE );


if ((CONTROL_UP | CONTROL_DOWN) & level){
  if (ControlsActive = !ControlsActive){ //-- yes this is an assignment!!!
    //-- take extended controls
  }else{
    //-- release extended controls with
    llTakeControls( CONTROL_UP | CONTROL_DOWN, TRUE, TRUE );
  }
}else{
  //-- your extended controls detection routine
}

I originally suggested monitoring rot_[left|right] because they wouldn't trigger your positioning code, but I'm unsure without testing that you can overlap controls in the same script with different pass_on settings. instead you may be able to avoid some accidental triggering with active keys by only checking level, and dropping small sleeps into the control event.

Hmmm. Do you have a .SWAP notecard? If not, create one, and put at least one line in it, say a comment (beginning with a slash). If that fixes it, it gets you going, and the bug fix should be fairly straightforward.

I assume you're choosing a pose, not just rezzing the bed.

Thanks for the bug report: big help!

Good suggestions, Void.

If there's an open interface standard for centralized access control, I'll be happy to follow it. Otherwise, it doesn't make much sense.

Of course, I've posted a free access control script using LMs, which could easily be modified to use chat and serve as a central access control object. But, that's another project.

Concerning MLPV2 adjustment, I did consider ignoring up/down and shift-left/right until the user uses page up or down, using that to enable (and thereafter as the z axis control). But I think it's too complicated to explain in a one-line chat when the user sits. And it doesn't allow disabling and returning to uncontrolled mode, without something funky like "press-and-hold page-down".

I won't use left/right arrow keys (unshifted) because it's just too commonly used to change view. Unfortunately, that only leaves me with 6 other keys.

It's already complicated enough since so many people don't realize they need to escape from any text boxes or popups before using these keys anyway. They do this without thinking to walk, but when sitting they wonder why the keys don't work. Just human nature.

Well, I could use a listen (ack, adding a listen per poseball), and have a chat command for the purpose. If I went that route, I could probably even make expressions enable/disable per customer.

The last thing I want to do, though, is to turn a bed into a rocket ship! No user manual or training should be required!

"press PgUp & PgDn together to toggle position adjustment"
?

as for the left right issue.. if you can take those controls with pass_on, I don't see it being an interference if they are only monitored for toggling control modes, because no one is going to be using left AND right together to rotate their view

as for the other thing... I'm not really up on the renter appliances, but I suspect hippo has a authorization protocol for renters in mainland situations... estate only needs check against the parcel owner.

pressing page up&down together: that's a great idea, thanks. You did mention "combination" but I didn't quite get it first time through.

Evidently, for
you meant

er yeah... that (sorry)... I think (CONTROL_UP & level && CONTROL_DOWN & level) would work too (1 less data point floating about, though the integer version of yours would be smallest)

ETA:
dunno if I would have came up with it myself, I just remembered the trick being used by a friend. but hey, if they're gonna register like bits, might as well treat them like it, and make useful numbers with them =)

Ok, the .SWAP notecard with //comment definitely helps. It's no longer giving a math error. But now when you rez it, the first time you click on an action, the pose ball just rezzes in the middle. You have to click on the action again, and it will go into position.
On rez:
[3:22] Bed V9: 0 sequences (~sequencer: 35606 bytes free)
Click relax1:
[3:22] Bed V9 whispers: relax1
[3:22] Bed V9: Reading .SWAP
[3:22] Bed V9: 0 poses with swaps (~swap: 51388 bytes free)
At this point, ball is just sitting in the middle of the bed, so we click relax1 again:
[3:22] Bed V9 whispers: relax1
Now the ball is in position.
Any ideas why? Thanks.

Was the .SWAP notecard missing or was it empty?

If your bed is copiable, rez it, restart it, and take it back into inventory.

If it's not copiable, I don't know why it's re-reading swaps and props each time you rez it; please let me know if this is the case.

Meanwhile, I'll do some testing after owner change to see if that's part of the problem here.

The .SWAP notecard was missing, probably because I copied from earlier versions. I've tried restarting it, taking it back into inventory and rerezzing it. It still re-reads the swaps and props when I click an action for the first time. Subsequent clicks do not cause it to re-read. However, after timeout, and clicking on an action, it will re-read.

By "click an action", do you mean select a pose, or click *any* menu button? Please always stick to the literal facts, being as specific as possible.

Please try resetting it, then selecting a pose, STOP, and then take into inventory. I suspect this'll fix it, in which case it's probably an issue with the stopping of unused scripts.

I really hate to bother you but I bought one of the couch covers about a week ago and I have yet to be able to get it to work. It keeps telling me script error and that there are no balls I have read everything I can that you offer and find no info why it is doing this all I did was put it out and try to use it. Thanks for your help

Sorry here is the errors that I get:

Object [script:.controller]: Script run-time error
Object [script:.controller]: Math Error
Object [script:.controller]: Script run-time error
Object [script:.controller]: Math Error
Object [script:.controller]: Script run-time error
Object [script:.controller]: Math Error
Object [script:.controller]: Script run-time error
Object [script:.controller]: Math Error
Object [script:.controller]: Script run-time error
Object [script:.controller]: Math Error
Object [script:.controller]: Script run-time error
Object [script:.controller]: Math Error
Object [script:.controller]: Script run-time error
Object [script:.controller]: Math Error
Object [script:.controller]: Script run-time error
Object [script:.controller]: Math Error
Object [script:.controller]: Script run-time error
Object [script:.controller]: Math Error
jPose Sofa Cover v1w7: Could not find object '~ball'.
jPose Sofa Cover v1w7: Could not find object '~ball'.

I also get

jPose Sofa Cover v1w7: Could not find object '~ball'.
jPose Sofa Cover v1w7: Could not find object '~ball'.

Kaylee, I have no idea where the "Object" error messages are coming from, and MLPV2 has no ".controller" script in it. These messages are from something else.

Concerning the sofa cover, for a short time the copy in my store was missing "~ball" due to an upgrade error on my part. You have two options: wait for me to log in and drop you a fixed copy, or get the latest MLPV2 from jPose Villa FEEBIES section (see my picks for location), pull ~ball from that and drop it in your sofa cover. Sorry for the inconvenience!

yes, 'click and action' means selecting a pose. sorry should have been more clear. I've tried what you suggested. Reset, select a pose, stop and take into inventory. Didn't help. When I rez, I have to select the pose twice again to get the balls into position. You can try this yourself if you want. Grab the jpose cover (I had jPose Bed Cover v1w2a), replace all the files with ~, with what was in mlpv 2.4m2, and you'll get the same issue.

I'm sure there are no issues using MLP at various heights. I just want to confirm.

Was helping a customer just now who lives at 2000 metres adjust poses.

We saved all the work to notecards. The positions were a bit odd, but I figured, whatever......

[18:40] {Drink} <169.663,-210.636,-2032.769> <178.2,0.9,-26.0> <0.000,0.000,0.000> <180.0,0.0,0.0>
[18:40] {Drinking} <169.659,-210.528,-2032.689> <178.2,0.9,-26.0> <0.000,0.000,0.000> <180.0,0.0,0.0>

(notice the minus 2032 bit)

Save notecard with adjusted positions. Reboot MLP object.

Call up menu, call up a poseball, and wham poseball goes about 50 metres beneath you.

There's another problem at play, right? Nothing to do with the height of all this? Just want to make totally sure I'm correct in assuming that is *not* a factor.

I worked at 3500m without problems.