Second Life Forums Archive - MLPV2 questions & bug reports

Amiz Munro

Registered User

Join date: 8 Jul 2008

Posts: 54

03-05-2009 10:51

From: Lear Cale

I see a problem where everything is fine and all of a sudden, I'm one meter higher.

I know this isn't an MLP bug, because there are no MLP messages to the balls -- the ball location didn't change, the animations didn't change by MLP. I suspect it's due to an anim being run (either by an AO, or by my selecting something which causes SL to run the "edit" arm-pointing "anim", or wearing an object that runs an anim -- I've seen all 3 cases). For some reason, sometimes the hip location changes. Hop off and back on and you're good. Change poses and you're good.

I really think it's a viewer bug. I can't say this for sure, but I'm pretty sure that I've seen it when running two clients (avatars), and one sees the goofup but the other doesn't. That kind of problem can never be caused by a scripting bug. With exceptions for particle effects and rotating nonphysical objects, differences in what two clients see are SL bugs, not scripting bugs.

See if your sudden drops correlate to any of the things I've mentioned above: anything that would normally cause your av to animate if you weren't sitting on the MLPV2, and let me know. (BTW, the goofup isn't instantaneous, and I think it can happen when SL stops the anim as well as starts it. I clearly saw this when sipping champaigne while seated, and it happened with poseballs as well as MLP -- completely different scripts.)

I think I caught the problem, just don’t know how to solve it.

First off Lear I have to say thank you, thank you ,thank you…and I don't know how you do it!

Now my deal with the AVs flying about 3 meters away. I was on my couch the other night with a friend and she had her evil titler running on channel 7. Every time it shouted to be changed we zoomed across the room into the floor, I asked her if she saw us like that as well, she did: now I don’t feel so crazy anymore.
I would just chose another pose it brought us right back to the couch and all is fine until it shouted again.
So, I figured out what it might be but other than asking her to remove her title device I don’t know how to cure it. I just thought you might like a report on this... just so you would know Lol

Anyways thanks again!

Amiz Munro

Registered User

Join date: 8 Jul 2008

Posts: 54

03-05-2009 10:52

From: Lear Cale

I see a problem where everything is fine and all of a sudden, I'm one meter higher.

I know this isn't an MLP bug, because there are no MLP messages to the balls -- the ball location didn't change, the animations didn't change by MLP. I suspect it's due to an anim being run (either by an AO, or by my selecting something which causes SL to run the "edit" arm-pointing "anim", or wearing an object that runs an anim -- I've seen all 3 cases). For some reason, sometimes the hip location changes. Hop off and back on and you're good. Change poses and you're good.

I really think it's a viewer bug. I can't say this for sure, but I'm pretty sure that I've seen it when running two clients (avatars), and one sees the goofup but the other doesn't. That kind of problem can never be caused by a scripting bug. With exceptions for particle effects and rotating nonphysical objects, differences in what two clients see are SL bugs, not scripting bugs.

See if your sudden drops correlate to any of the things I've mentioned above: anything that would normally cause your av to animate if you weren't sitting on the MLPV2, and let me know. (BTW, the goofup isn't instantaneous, and I think it can happen when SL stops the anim as well as starts it. I clearly saw this when sipping champaigne while seated, and it happened with poseballs as well as MLP -- completely different scripts.)

I think I caught the problem, just don’t know how to solve it. Version(d)

First off Lear I have to say thank you, thank you ,thank you…and I don't know how you do it!

Now my deal with the AVs flying about 3 meters away. I was on my couch the other night with a friend and she had her evil titler running on channel 7. Every time it shouted to be changed we zoomed across the room into the floor, I asked her if she saw us like that as well, she did: now I don’t feel so crazy anymore.
I would just chose another pose it brought us right back to the couch and all is fine until it shouted again.
So, I figured out what it might be but other than asking her to remove her title device I don’t know how to cure it. I just thought you might like a report on this... just so you would know Lol

Anyways thanks again!

Chaz Longstaff

Registered User

Join date: 11 Oct 2006

Posts: 685

03-05-2009 11:19

From: Kuma Starsider

There is another bug I located and squashed. This bug related to the LINKMSG feature of the .MENUITEMS. Though this is a minor annoyance at best, it still annoyed me when I was creating a custom sub-menu for a piece of furniture, causing menus to stack when I didn't want them to.

The dialog system was ignoring the NOREGEN option when a LINKMSG selection was added to the .MENUITEMS note card.

From: Lear Cale

Your suggesttion merely inverts the logic. If the logic disagrees with the documentation, I'll update the documentation to avoid breaking existing configurations.

The expression in the 'if' statement is not "missing the item to compare to". The expression is true if the value is nonzero, and false if it is zero.

Just wanna make sure I'm following this: are NOREGEN options being ignored when a LINKMSG command is added to the .MENUITEMS note card?

_____________________

Thread attempting to compile a list of which animations are freebies, and which are not:

http://forums.secondlife.com/showthread.php?t=265609

Lear Cale

wordy bugger

Join date: 22 Aug 2007

Posts: 3,569

03-06-2009 15:46

Ah, that's probably it, Chaz -- thanks; I missed that bit. The suggested changes wouldn't fix that. I assume NOREGEN is the thing that inhibits posting the menu again after making a selection, a feature I never use myself. If so, that should be easy to fix.

[edit: I think you mean REDO rather than NOREGEN.]

Lear Cale

wordy bugger

Join date: 22 Aug 2007

Posts: 3,569

03-09-2009 10:04

Found the problem where balls would move due to ">" in chat. In specific cases, this bug could also cause "menu crosstalk", where using the menu on one object affects another one nearby.

Fixed version is available at jPose Villa FREEBIES section (see my profile picks).

Lear Cale

wordy bugger

Join date: 22 Aug 2007

Posts: 3,569

03-12-2009 14:00

The example LINKMSG in the standard MENUITEMS had a mistake:

From: someone

// link-message button. LINKMSG buttonname | parms
// where parms is a comma-separated list: menu,primnum,lm-num-arg,lm-str-arg
// menu is 1 if the LM will cause a menu, or 0 if not (to avoid menu stacking if remenu is on).
// primnum is the primitive number (see llMessageLinked() docs)
// lm-num-arg is the 'num' arg in the LM. If sending to same prim as MLPV2, avoid -100 to 100 range.
// lm-str-arg is the 'str' arg in the LM
// The menu user's key is passed as the LM 'key' arg.
//
// Example (commented out):
// LINKMSG Show/Hide | 0,-4,-100,show-hide
// -- inhibits remenu and calls llMessageLinked(-4, 100, "textures", toucherKey)

This line:

From: someone

// LINKMSG Show/Hide | 0,-4,-100,show-hide

should have been:

From: someone

// LINKMSG Show/Hide | 1,-4,-100,show-hide

(Or, "inhibits" should have been "allows".)

Lear Cale

wordy bugger

Join date: 22 Aug 2007

Posts: 3,569

03-12-2009 14:07

From: DrJohn Lane

MLPv2.4i (labelled as 2.4h when running) has resolved the problems with saving positions, but there seems to be a problem with saving props (unless this behavior is expected). If you save a prop more than once when adjusting it, the offset position changes each time, even if the prop position has not changed. For example, if you move the prop upward by .1, the z-value increases by .1 each time the save prop button is clicked.

Thanks for the bug report. I think this was a ramification of a recent fix (somewhere in the 2.4 version train). Yup, just as described, if I move a prop by some amount and save it 3 times in a row, it moves it 3 times as far. This has nothing to do with the "Height" menu as I surmised earlier.

DrJohn Lane

Registered User

Join date: 3 Aug 2007

Posts: 4

Simple temp solution

03-12-2009 14:13

From: Lear Cale

Thanks for the bug report. I think this was a ramification of a recent fix (somewhere in the 2.4 version train). Yup, just as described, if I move a prop by some amount and save it 3 times in a row, it moves it 3 times as far. This has nothing to do with the "Height" menu as I surmised earlier.

A simple temporary solution is to avoid OCD tendencies and just save the prop position once.... That has been working.

Chaz Longstaff

Registered User

Join date: 11 Oct 2006

Posts: 685

03-12-2009 14:18

From: DrJohn Lane

A simple temporary solution is to avoid OCD tendencies and just save the prop position once.... That has been working.

Had to look up OCD, grin. Anyway, easier said than done I suppose when someone keeps chatting in your ear and you forget whether you saved or not ;}

_____________________

Thread attempting to compile a list of which animations are freebies, and which are not:

http://forums.secondlife.com/showthread.php?t=265609

Lear Cale

wordy bugger

Join date: 22 Aug 2007

Posts: 3,569

03-12-2009 18:47

From: DrJohn Lane

A simple temporary solution is to avoid OCD tendencies and just save the prop position once.... That has been working.

Grins. But, it's broken and needs to be fixed. Like Chaz, I often don't remember which step I'd just done when I return to what I was doing (or after crashing ...)

I'm sure crashes while scripting has led to more than a couple MLPV2 bugs.

Lear Cale

wordy bugger

Join date: 22 Aug 2007

Posts: 3,569

03-17-2009 08:16

OK, found why saving object position multiple times causes it to move. The fix is easy, in the ~prop script (the one in the prop object). I'll be posting it to the group soon.

Thanks again for the clear bug report!

Callie Hearn

Registered User

Join date: 10 Sep 2006

Posts: 3

Name above pose balls

03-18-2009 05:49

Hi.
The floating tag above the balls when rezzed reads- "Multi-Love Pose". I was wondering in where in what script I need to go to change this. In the script inside the ball itself lines 73-76 read " on_rez(integer channel) {
Name = llGetObjectDesc();
if (Name == "" || Name == "

No Description)"

{
Name = "LOVE";"
... so I need help on where i need to change that elsewhere. Thank you.

Lear Cale

wordy bugger

Join date: 22 Aug 2007

Posts: 3,569

03-18-2009 06:41

Set the description of the ~ball object (in the MLPV2 prim's inventory) to a space or two, to make the ball text blank. No script changes needed.

Callie Hearn

Registered User

Join date: 10 Sep 2006

Posts: 3

03-18-2009 07:02

Where?

Callie Hearn

Registered User

Join date: 10 Sep 2006

Posts: 3

03-18-2009 07:07

I got it

. Thank you so much .

Desiree Bisiani

Furniture Designer

Join date: 25 Nov 2006

Posts: 189

03-20-2009 18:41

Sigh...

I have a bed with a fairly large menu that I have been working on. All was working fine with all the animations and poses added, positions set etc. That is until I added the XCITE Partner Script and got about half way down my list of poses to add the xcite specifications to the .XCITE notecard. Now it is giving me Script run-time error and Stack-Heap Collision. It had been working ok even with the xcite scripts included when my .XCITE notecard was not as long...but now seems to be giving me issues.

memory:

**Xcite! Partner v2.0.3 initialized : 7054 bytes free.
0 xcite anims and 67 poses configured (~MLPT-Xcite-adaptor4 v0g: 25966 bytes free)
11 poses with props (~props: 35006 bytes free)
181 poses loaded (~pose: 22558 bytes free)
313 menuitems loaded (~menucfg: 24954 bytes free)
(~menu: 14224 bytes free)

Any ideas?

_____________________

**************************************

http://slurl.com/secondlife/Lux%20Prometheus/139/47/307/
www.ambianceinteractive.wordpress.com/

Lear Cale

wordy bugger

Join date: 22 Aug 2007

Posts: 3,569

03-21-2009 07:28

Make sure the MLPV2 xcite partner script is MONO-compiled. Open it from object inventory and look at the MONO checkbox at the bottom. If it's clear, check it and Save. Then drag that into inventory for distributing to any other beds.

It should be Mono-compiled in the distribution, but perhaps it's not. I'll double check. You have to have the script in an object to tell.

Desiree Bisiani

Furniture Designer

Join date: 25 Nov 2006

Posts: 189

03-21-2009 10:41

From: Lear Cale

Make sure the MLPV2 xcite partner script is MONO-compiled. Open it from object inventory and look at the MONO checkbox at the bottom. If it's clear, check it and Save. Then drag that into inventory for distributing to any other beds.

It should be Mono-compiled in the distribution, but perhaps it's not. I'll double check. You have to have the script in an object to tell.

Hi Lear,

Thanks for the response.

I did double check and the xcite partner script had already been mono compiled. Am I correct in what I am getting from your comment is that this is an xcite script issue as opposed to an MLPV2 issue?

~ Desi

_____________________

**************************************

http://slurl.com/secondlife/Lux%20Prometheus/139/47/307/
www.ambianceinteractive.wordpress.com/

Lear Cale

wordy bugger

Join date: 22 Aug 2007

Posts: 3,569

03-21-2009 12:37

The Xcite partner script reports only 7K of free memory. I suspect it's not Mono-compiled.

MLPV2 sends a big "link message" with the menu configuration, and that is probably killing the Xcite partner script.

Please contact Xcite and see if they can provide a version of their script compiled in Mono.

Meanwhile, I'll see if I can rearchitect the way MLPV2 passes the config from ~menucfg to ~menu. I did that pre-Mono, and it could now be optimized for Mono, avoiding the big LM.

BTW, it's the size of the menu config (.MENUITEMS notecards) that governs this, not the number of .XCITE entries.

Lear Cale

wordy bugger

Join date: 22 Aug 2007

Posts: 3,569

03-21-2009 12:50

Are there any non-MLPV2 scripts in the MLP prim, other than the xcite partner script?

MLPV2 sends a big "linked message" (LM). If there's a script that listens to LMs and is not Mono-compiled, that could cause a stack-heap error in that script.

It's also possible that the big LM is killing the xcite partner script. Try reducing the number of poses in .MENUITEMS notecards and see if it goes away.

Desiree Bisiani

Furniture Designer

Join date: 25 Nov 2006

Posts: 189

03-21-2009 19:00

Update:

Ok...well I decided to remove the xcite partner script and .xcite card and check it to see if it still got a script error and it did (even though it hadn't previously). So, I went back and removed a few animations and their positions and now it seems to be working fine. I'm a bit puzzled as to why it worked before and then it wasn't...*shrugs*. I'm glad its now working though!

Thanks for your patience in thinking it through with me Lear.

~ Desi

_____________________

**************************************

http://slurl.com/secondlife/Lux%20Prometheus/139/47/307/
www.ambianceinteractive.wordpress.com/

Lear Cale

wordy bugger

Join date: 22 Aug 2007

Posts: 3,569

03-22-2009 13:08

As I said above:

From: someone

BTW, it's the size of the menu config (.MENUITEMS notecards) that governs this, not the number of .XCITE entries.

You must be right on the edge with number of poses. Since the Xcite partner script is Mono (as you told me by IM -- damn that's a big script for not needing any config) the big MLPV2 LM must be killing it, so one of these days I'll look into reducing the size of that LM by breaking it into smaller ones.

Oh, also try with lots of avatars nearby. I heard someone say the Xcite script does a scan, and more avatars might make it take more memory.

You also might get different results due to reset order. When testing, use "tools -> reset scripts in selection", and then touch the MLPV2 to get it to start up, so you get the same reset order each time. Once you have something that works, try running it, using xcite-based poses, and then restart MLPV2 via OPTIONS -> Shutdown menu. There wouldn't be a difference between the "Restart" button and "Shutdown!" followed by touching it.

Desiree Bisiani

Furniture Designer

Join date: 25 Nov 2006

Posts: 189

03-22-2009 16:34

From: Lear Cale

As I said above: You must be right on the edge with number of poses. Since the Xcite partner script is Mono (as you told me by IM -- damn that's a big script for not needing any config) the big MLPV2 LM must be killing it, so one of these days I'll look into reducing the size of that LM by breaking it into smaller ones.

Oh, also try with lots of avatars nearby. I heard someone say the Xcite script does a scan, and more avatars might make it take more memory.

You also might get different results due to reset order. When testing, use "tools -> reset scripts in selection", and then touch the MLPV2 to get it to start up, so you get the same reset order each time. Once you have something that works, try running it, using xcite-based poses, and then restart MLPV2 via OPTIONS -> Shutdown menu. There wouldn't be a difference between the "Restart" button and "Shutdown!" followed by touching it.

Yeah...you mentioning the .MENUITEMS doing it is what made me decide to decrease the poses by a few (eliminated a few that weren't that necessary). That did seem to do the trick. As always...you rock!

~ Desi

_____________________

**************************************

http://slurl.com/secondlife/Lux%20Prometheus/139/47/307/
www.ambianceinteractive.wordpress.com/

Resa Oberlander

Registered User

Join date: 1 May 2008

Posts: 3

Sequence question

03-24-2009 20:29

I'm not sure if this is a silly question, but after going through the sequences notecards, I'm a little wary about how to set it up. I'm pretty sure I grasp how to set up the actual sequences in the .sequences notecard, but the actual poses, do those come from a preset menu on the .menuitems notecard? Like if I already set up all the menus on the .menuitems notecard, after SEQUENCE | NameofSequence, it MENU | (Do I put the name of a preset menu here, and thats where it gets the previously set poses?)

Lear Cale

wordy bugger

Join date: 22 Aug 2007

Posts: 3,569

03-26-2009 13:18

From: Resa Oberlander

I'm not sure if this is a silly question, but after going through the sequences notecards, I'm a little wary about how to set it up. I'm pretty sure I grasp how to set up the actual sequences in the .sequences notecard, but the actual poses, do those come from a preset menu on the .menuitems notecard? Like if I already set up all the menus on the .menuitems notecard, after SEQUENCE | NameofSequence, it MENU | (Do I put the name of a preset menu here, and thats where it gets the previously set poses?)

NOt exactly sure what you're asking; next time please post a more complete example of what you think.

In a sequences notecard, after the "MENU" keyword, put the name of the menu as it appears in your .MENUITEMS.* notecard. This tells MLP how many and which color balls to use.

In a .MENUITEMS* notecard, if you have a menu with poses that you use only for sequences and you don't want them visible to the user on the MLP menu, use "HIDDEN" instead of the "ALL" keyword.

MLPV2 questions & bug reports
Amiz Munro Registered User Join date: 8 Jul 2008 Posts: 54	03-05-2009 10:51 From: Lear Cale I see a problem where everything is fine and all of a sudden, I'm one meter higher. I know this isn't an MLP bug, because there are no MLP messages to the balls -- the ball location didn't change, the animations didn't change by MLP. I suspect it's due to an anim being run (either by an AO, or by my selecting something which causes SL to run the "edit" arm-pointing "anim", or wearing an object that runs an anim -- I've seen all 3 cases). For some reason, sometimes the hip location changes. Hop off and back on and you're good. Change poses and you're good. I really think it's a viewer bug. I can't say this for sure, but I'm pretty sure that I've seen it when running two clients (avatars), and one sees the goofup but the other doesn't. That kind of problem can never be caused by a scripting bug. With exceptions for particle effects and rotating nonphysical objects, differences in what two clients see are SL bugs, not scripting bugs. See if your sudden drops correlate to any of the things I've mentioned above: anything that would normally cause your av to animate if you weren't sitting on the MLPV2, and let me know. (BTW, the goofup isn't instantaneous, and I think it can happen when SL stops the anim as well as starts it. I clearly saw this when sipping champaigne while seated, and it happened with poseballs as well as MLP -- completely different scripts.) I think I caught the problem, just don’t know how to solve it. First off Lear I have to say thank you, thank you ,thank you…and I don't know how you do it! Now my deal with the AVs flying about 3 meters away. I was on my couch the other night with a friend and she had her evil titler running on channel 7. Every time it shouted to be changed we zoomed across the room into the floor, I asked her if she saw us like that as well, she did: now I don’t feel so crazy anymore. I would just chose another pose it brought us right back to the couch and all is fine until it shouted again. So, I figured out what it might be but other than asking her to remove her title device I don’t know how to cure it. I just thought you might like a report on this... just so you would know Lol Anyways thanks again!
Amiz Munro Registered User Join date: 8 Jul 2008 Posts: 54	03-05-2009 10:52 From: Lear Cale I see a problem where everything is fine and all of a sudden, I'm one meter higher. I know this isn't an MLP bug, because there are no MLP messages to the balls -- the ball location didn't change, the animations didn't change by MLP. I suspect it's due to an anim being run (either by an AO, or by my selecting something which causes SL to run the "edit" arm-pointing "anim", or wearing an object that runs an anim -- I've seen all 3 cases). For some reason, sometimes the hip location changes. Hop off and back on and you're good. Change poses and you're good. I really think it's a viewer bug. I can't say this for sure, but I'm pretty sure that I've seen it when running two clients (avatars), and one sees the goofup but the other doesn't. That kind of problem can never be caused by a scripting bug. With exceptions for particle effects and rotating nonphysical objects, differences in what two clients see are SL bugs, not scripting bugs. See if your sudden drops correlate to any of the things I've mentioned above: anything that would normally cause your av to animate if you weren't sitting on the MLPV2, and let me know. (BTW, the goofup isn't instantaneous, and I think it can happen when SL stops the anim as well as starts it. I clearly saw this when sipping champaigne while seated, and it happened with poseballs as well as MLP -- completely different scripts.) I think I caught the problem, just don’t know how to solve it. Version(d) First off Lear I have to say thank you, thank you ,thank you…and I don't know how you do it! Now my deal with the AVs flying about 3 meters away. I was on my couch the other night with a friend and she had her evil titler running on channel 7. Every time it shouted to be changed we zoomed across the room into the floor, I asked her if she saw us like that as well, she did: now I don’t feel so crazy anymore. I would just chose another pose it brought us right back to the couch and all is fine until it shouted again. So, I figured out what it might be but other than asking her to remove her title device I don’t know how to cure it. I just thought you might like a report on this... just so you would know Lol Anyways thanks again!
Chaz Longstaff Registered User Join date: 11 Oct 2006 Posts: 685	03-05-2009 11:19 From: Kuma Starsider There is another bug I located and squashed. This bug related to the LINKMSG feature of the .MENUITEMS. Though this is a minor annoyance at best, it still annoyed me when I was creating a custom sub-menu for a piece of furniture, causing menus to stack when I didn't want them to. The dialog system was ignoring the NOREGEN option when a LINKMSG selection was added to the .MENUITEMS note card. From: Lear Cale Your suggesttion merely inverts the logic. If the logic disagrees with the documentation, I'll update the documentation to avoid breaking existing configurations. The expression in the 'if' statement is not "missing the item to compare to". The expression is true if the value is nonzero, and false if it is zero. Just wanna make sure I'm following this: are NOREGEN options being ignored when a LINKMSG command is added to the .MENUITEMS note card? _____________________ Thread attempting to compile a list of which animations are freebies, and which are not: http://forums.secondlife.com/showthread.php?t=265609
Lear Cale wordy bugger Join date: 22 Aug 2007 Posts: 3,569	03-06-2009 15:46 Ah, that's probably it, Chaz -- thanks; I missed that bit. The suggested changes wouldn't fix that. I assume NOREGEN is the thing that inhibits posting the menu again after making a selection, a feature I never use myself. If so, that should be easy to fix. [edit: I think you mean REDO rather than NOREGEN.]
Lear Cale wordy bugger Join date: 22 Aug 2007 Posts: 3,569	03-09-2009 10:04 Found the problem where balls would move due to ">" in chat. In specific cases, this bug could also cause "menu crosstalk", where using the menu on one object affects another one nearby. Fixed version is available at jPose Villa FREEBIES section (see my profile picks).
Lear Cale wordy bugger Join date: 22 Aug 2007 Posts: 3,569	03-12-2009 14:00 The example LINKMSG in the standard MENUITEMS had a mistake: From: someone // link-message button. LINKMSG buttonname \| parms // where parms is a comma-separated list: menu,primnum,lm-num-arg,lm-str-arg // menu is 1 if the LM will cause a menu, or 0 if not (to avoid menu stacking if remenu is on). // primnum is the primitive number (see llMessageLinked() docs) // lm-num-arg is the 'num' arg in the LM. If sending to same prim as MLPV2, avoid -100 to 100 range. // lm-str-arg is the 'str' arg in the LM // The menu user's key is passed as the LM 'key' arg. // // Example (commented out): // LINKMSG Show/Hide \| 0,-4,-100,show-hide // -- inhibits remenu and calls llMessageLinked(-4, 100, "textures", toucherKey) This line: From: someone // LINKMSG Show/Hide \| 0,-4,-100,show-hide should have been: From: someone // LINKMSG Show/Hide \| 1,-4,-100,show-hide (Or, "inhibits" should have been "allows".)
Lear Cale wordy bugger Join date: 22 Aug 2007 Posts: 3,569	03-12-2009 14:07 From: DrJohn Lane MLPv2.4i (labelled as 2.4h when running) has resolved the problems with saving positions, but there seems to be a problem with saving props (unless this behavior is expected). If you save a prop more than once when adjusting it, the offset position changes each time, even if the prop position has not changed. For example, if you move the prop upward by .1, the z-value increases by .1 each time the save prop button is clicked. Thanks for the bug report. I think this was a ramification of a recent fix (somewhere in the 2.4 version train). Yup, just as described, if I move a prop by some amount and save it 3 times in a row, it moves it 3 times as far. This has nothing to do with the "Height" menu as I surmised earlier.
DrJohn Lane Registered User Join date: 3 Aug 2007 Posts: 4	Simple temp solution 03-12-2009 14:13 From: Lear Cale Thanks for the bug report. I think this was a ramification of a recent fix (somewhere in the 2.4 version train). Yup, just as described, if I move a prop by some amount and save it 3 times in a row, it moves it 3 times as far. This has nothing to do with the "Height" menu as I surmised earlier. A simple temporary solution is to avoid OCD tendencies and just save the prop position once.... That has been working.
Chaz Longstaff Registered User Join date: 11 Oct 2006 Posts: 685	03-12-2009 14:18 From: DrJohn Lane A simple temporary solution is to avoid OCD tendencies and just save the prop position once.... That has been working. Had to look up OCD, grin. Anyway, easier said than done I suppose when someone keeps chatting in your ear and you forget whether you saved or not ;} _____________________ Thread attempting to compile a list of which animations are freebies, and which are not: http://forums.secondlife.com/showthread.php?t=265609
Lear Cale wordy bugger Join date: 22 Aug 2007 Posts: 3,569	03-12-2009 18:47 From: DrJohn Lane A simple temporary solution is to avoid OCD tendencies and just save the prop position once.... That has been working. Grins. But, it's broken and needs to be fixed. Like Chaz, I often don't remember which step I'd just done when I return to what I was doing (or after crashing ...) I'm sure crashes while scripting has led to more than a couple MLPV2 bugs.
Lear Cale wordy bugger Join date: 22 Aug 2007 Posts: 3,569	03-17-2009 08:16 OK, found why saving object position multiple times causes it to move. The fix is easy, in the ~prop script (the one in the prop object). I'll be posting it to the group soon. Thanks again for the clear bug report!
Callie Hearn Registered User Join date: 10 Sep 2006 Posts: 3	Name above pose balls 03-18-2009 05:49 Hi. The floating tag above the balls when rezzed reads- "Multi-Love Pose". I was wondering in where in what script I need to go to change this. In the script inside the ball itself lines 73-76 read " on_rez(integer channel) { Name = llGetObjectDesc(); if (Name == "" \|\| Name == "No Description)" { Name = "LOVE";" ... so I need help on where i need to change that elsewhere. Thank you.
Lear Cale wordy bugger Join date: 22 Aug 2007 Posts: 3,569	03-18-2009 06:41 Set the description of the ~ball object (in the MLPV2 prim's inventory) to a space or two, to make the ball text blank. No script changes needed.
Callie Hearn Registered User Join date: 10 Sep 2006 Posts: 3	03-18-2009 07:02 Where?
Callie Hearn Registered User Join date: 10 Sep 2006 Posts: 3	03-18-2009 07:07 I got it . Thank you so much .
Desiree Bisiani Furniture Designer Join date: 25 Nov 2006 Posts: 189	03-20-2009 18:41 Sigh... I have a bed with a fairly large menu that I have been working on. All was working fine with all the animations and poses added, positions set etc. That is until I added the XCITE Partner Script and got about half way down my list of poses to add the xcite specifications to the .XCITE notecard. Now it is giving me Script run-time error and Stack-Heap Collision. It had been working ok even with the xcite scripts included when my .XCITE notecard was not as long...but now seems to be giving me issues. memory: Xcite! Partner v2.0.3 initialized : 7054 bytes free. 0 xcite anims and 67 poses configured (~MLPT-Xcite-adaptor4 v0g: 25966 bytes free) 11 poses with props (~props: 35006 bytes free) 181 poses loaded (~pose: 22558 bytes free) 313 menuitems loaded (~menucfg: 24954 bytes free) (~menu: 14224 bytes free) Any ideas? _____________________ ************************************ http://slurl.com/secondlife/Lux%20Prometheus/139/47/307/ www.ambianceinteractive.wordpress.com/
Lear Cale wordy bugger Join date: 22 Aug 2007 Posts: 3,569	03-21-2009 07:28 Make sure the MLPV2 xcite partner script is MONO-compiled. Open it from object inventory and look at the MONO checkbox at the bottom. If it's clear, check it and Save. Then drag that into inventory for distributing to any other beds. It should be Mono-compiled in the distribution, but perhaps it's not. I'll double check. You have to have the script in an object to tell.
Desiree Bisiani Furniture Designer Join date: 25 Nov 2006 Posts: 189	03-21-2009 10:41 From: Lear Cale Make sure the MLPV2 xcite partner script is MONO-compiled. Open it from object inventory and look at the MONO checkbox at the bottom. If it's clear, check it and Save. Then drag that into inventory for distributing to any other beds. It should be Mono-compiled in the distribution, but perhaps it's not. I'll double check. You have to have the script in an object to tell. Hi Lear, Thanks for the response. I did double check and the xcite partner script had already been mono compiled. Am I correct in what I am getting from your comment is that this is an xcite script issue as opposed to an MLPV2 issue? ~ Desi _____________________ ************************************** http://slurl.com/secondlife/Lux%20Prometheus/139/47/307/ www.ambianceinteractive.wordpress.com/
Lear Cale wordy bugger Join date: 22 Aug 2007 Posts: 3,569	03-21-2009 12:37 The Xcite partner script reports only 7K of free memory. I suspect it's not Mono-compiled. MLPV2 sends a big "link message" with the menu configuration, and that is probably killing the Xcite partner script. Please contact Xcite and see if they can provide a version of their script compiled in Mono. Meanwhile, I'll see if I can rearchitect the way MLPV2 passes the config from ~menucfg to ~menu. I did that pre-Mono, and it could now be optimized for Mono, avoiding the big LM. BTW, it's the size of the menu config (.MENUITEMS notecards) that governs this, not the number of .XCITE entries.
Lear Cale wordy bugger Join date: 22 Aug 2007 Posts: 3,569	03-21-2009 12:50 Are there any non-MLPV2 scripts in the MLP prim, other than the xcite partner script? MLPV2 sends a big "linked message" (LM). If there's a script that listens to LMs and is not Mono-compiled, that could cause a stack-heap error in that script. It's also possible that the big LM is killing the xcite partner script. Try reducing the number of poses in .MENUITEMS notecards and see if it goes away.
Desiree Bisiani Furniture Designer Join date: 25 Nov 2006 Posts: 189	03-21-2009 19:00 Update: Ok...well I decided to remove the xcite partner script and .xcite card and check it to see if it still got a script error and it did (even though it hadn't previously). So, I went back and removed a few animations and their positions and now it seems to be working fine. I'm a bit puzzled as to why it worked before and then it wasn't...shrugs. I'm glad its now working though! Thanks for your patience in thinking it through with me Lear. ~ Desi _____________________ ************************************** http://slurl.com/secondlife/Lux%20Prometheus/139/47/307/ www.ambianceinteractive.wordpress.com/
Lear Cale wordy bugger Join date: 22 Aug 2007 Posts: 3,569	03-22-2009 13:08 As I said above: From: someone BTW, it's the size of the menu config (.MENUITEMS notecards) that governs this, not the number of .XCITE entries. You must be right on the edge with number of poses. Since the Xcite partner script is Mono (as you told me by IM -- damn that's a big script for not needing any config) the big MLPV2 LM must be killing it, so one of these days I'll look into reducing the size of that LM by breaking it into smaller ones. Oh, also try with lots of avatars nearby. I heard someone say the Xcite script does a scan, and more avatars might make it take more memory. You also might get different results due to reset order. When testing, use "tools -> reset scripts in selection", and then touch the MLPV2 to get it to start up, so you get the same reset order each time. Once you have something that works, try running it, using xcite-based poses, and then restart MLPV2 via OPTIONS -> Shutdown menu. There wouldn't be a difference between the "Restart" button and "Shutdown!" followed by touching it.
Desiree Bisiani Furniture Designer Join date: 25 Nov 2006 Posts: 189	03-22-2009 16:34 From: Lear Cale As I said above: You must be right on the edge with number of poses. Since the Xcite partner script is Mono (as you told me by IM -- damn that's a big script for not needing any config) the big MLPV2 LM must be killing it, so one of these days I'll look into reducing the size of that LM by breaking it into smaller ones. Oh, also try with lots of avatars nearby. I heard someone say the Xcite script does a scan, and more avatars might make it take more memory. You also might get different results due to reset order. When testing, use "tools -> reset scripts in selection", and then touch the MLPV2 to get it to start up, so you get the same reset order each time. Once you have something that works, try running it, using xcite-based poses, and then restart MLPV2 via OPTIONS -> Shutdown menu. There wouldn't be a difference between the "Restart" button and "Shutdown!" followed by touching it. Yeah...you mentioning the .MENUITEMS doing it is what made me decide to decrease the poses by a few (eliminated a few that weren't that necessary). That did seem to do the trick. As always...you rock! ~ Desi _____________________ ************************************** http://slurl.com/secondlife/Lux%20Prometheus/139/47/307/ www.ambianceinteractive.wordpress.com/
Resa Oberlander Registered User Join date: 1 May 2008 Posts: 3	Sequence question 03-24-2009 20:29 I'm not sure if this is a silly question, but after going through the sequences notecards, I'm a little wary about how to set it up. I'm pretty sure I grasp how to set up the actual sequences in the .sequences notecard, but the actual poses, do those come from a preset menu on the .menuitems notecard? Like if I already set up all the menus on the .menuitems notecard, after SEQUENCE \| NameofSequence, it MENU \| (Do I put the name of a preset menu here, and thats where it gets the previously set poses?)
Lear Cale wordy bugger Join date: 22 Aug 2007 Posts: 3,569	03-26-2009 13:18 From: Resa Oberlander I'm not sure if this is a silly question, but after going through the sequences notecards, I'm a little wary about how to set it up. I'm pretty sure I grasp how to set up the actual sequences in the .sequences notecard, but the actual poses, do those come from a preset menu on the .menuitems notecard? Like if I already set up all the menus on the .menuitems notecard, after SEQUENCE \| NameofSequence, it MENU \| (Do I put the name of a preset menu here, and thats where it gets the previously set poses?) NOt exactly sure what you're asking; next time please post a more complete example of what you think. In a sequences notecard, after the "MENU" keyword, put the name of the menu as it appears in your .MENUITEMS.* notecard. This tells MLP how many and which color balls to use. In a .MENUITEMS* notecard, if you have a menu with poses that you use only for sequences and you don't want them visible to the user on the MLP menu, use "HIDDEN" instead of the "ALL" keyword.

Welcome to the Second Life Forums Archive

MLPV2 questions & bug reports