MLPV2 questions & bug reports

Inworld, you can always look near the bottom of the .readme notecard in the latest distribution. But the web page is super handy.

If they contradict, well, that would be my fault.

Hello there,
I have a question to the older version of MLP. The channels, used for the balls are defind (0,1), so if I have two or more menus in the furniture (for example I have a bed, a lounge and a rug with different menus for different poses, based on MLP) standing near each other, I should change the channels and make them different for different menus. As I understood from the scripts, the channels can be changed in "~pose1" and "~pose2" scripts and will be used by other scripts as well. After I have changed the chennels for example to "11,12", "21,22", etc. for different menus I dont have a problem of overtalking anymore, but the poseballs will be not animated. They change the positions and so on, but no animations. Have I forgotten something to change in scripts? I have a lot of furniture and dont want to change all of them to MLPv2 because of this problem. Please, help me! Thanks

Please start with the problem and then we'll work out the solution.

Are you having a problem that using the menu on one item is affecting the others?

This shouldn't happen with MLP 1.2. (If for some reason you have an older version, you should at least upgrade to 1.2) It can happen with that version (or early MLPV2.0 versions) if you rez multiple copies of the same item from inventory, but not otherwise.

This problem is called "crosstalk". It can cause the menu for one object to move the balls for a different object. It can also cause a menu from the other object to pop up.

The simplest solution is to reset each copy as you rez it. Also, original MLP always resets on owner change, so unless you sell copiable items, it shouldn't ever be a problem for your customers.

But you're getting this on different objects, it seems. Did you start with the same MLP prim and copy it to make each of them, without ever resetting the scripts? (Usually, the scripts get set after adjusting the notecards.)

BTW, upgrading to MLPV2 is as simple as replacing the scripts and the ball. No notecard changes are required.

In any event, there's no need to "change the channels". The only thing that's required is for the base channel, which is a function of the object's key, to get recalculated when appropriate. This always happens on a reset.

Yes. I have several objects, using MLP engine standing in one room and as soon as I click one of them to call up the menu, I get several menus from near standing objects and the balls are moving from object to object. I would like to have them for each object separate and of cause see only this menu, which object I click on.

I have MLP 1.2 and, of cause, if the balls are everytime have the channels 0 and 1 it should happen, that they "crosstalk", even if you restart each of them. I would like to try first to fix this version, because my try to upgrade all of my furniture shows me, that I should adjust all of the positions again for each object. The reason is, that even with the same ".POSITIONS" notecard the newer version still make it different, because of different rotation. Any way, would mean a lot of work for me.

I restart it every time and I do no copy an existing prim with menu, usually I use new prim for different objects and put all scripts inside from my inventory.
As I said, I have changed the channels to a different one for different objects, restarted each of them, but it seems to work only with channels 0 and 1 or 1 and 2. As soos as I put some other number, I dont get any "crosstalk", but also no animations in balls. The pop-up questions to animate my avatar doesnt appear.

This is incorrect. This is not the channels the balls listen on, and is not the channels the ~menu script listens on for

Clearly, you must have modified scripts and not the standard ones.

This is NOT because of different scripts; it's because of using a differently-oriented prim containing the scripts.

Then the scripts you're using are messed up, because what you describe is not how MLP 1.2 works.

Please post the original and modified code you're using, because your facts are simply incorrect. None of the scripts listens on channels 0, 1, or 2. (Don't post whole scripts, just a few lines around the ones you're modifying, and tell us which script it's in.)

The balls don't listen to the menu. They listen to the ~menu script. So, for now, forget the balls.

The script listens on a channel that's based on the object's key. The variable is called "ch" in most or all cases.

I suspect you have scripts that were modified by someone for a special purpose. Either that, or there's something else going on here that's leading you astray.

Actually, the last time I had the timer script in there, it popped us off the balls after it timed out. We had not changed poses in that amount of time, so not sure if that is part of what caused it or not. My experience with that might not have been with the latest version, so I'll check that when I log in.

First want to say thanks for the help! Other people I asked just said I should take the MLP2 and forget the old one. I really appreciate it!



Yes, I ment it too, the ~menu script should control the menu itself and the balls. As I said I am not a scripter, but it was necessary for me to try to understand the scripts, because nobody could help me. The first I have seen was the line in ~pose1 and ~pose2:

integer ch = 1; //pose1: ch=0 //pose2: ch=1

I thought it was the channel and I have changed it to some different. In other scripts I didn´t find such definitions. As I said, it helps to avoid the crosstalking, but was wrong anyway.

Now it seems I found the way. I let the variables "ch" for both scripts as they should be (0 and 1) and changed follow line in all scripts, where I have found it:

ch += (integer)("0x"+llGetSubString((string)llGetKey(),-4,-1)); //fixed channel for prim

I have changed "-4" to different numbers for different objects and it works! Hope it was not wrong and I will not get any other problem, which I can´t see now.


The prim I have used for a new version was THE SAME prim with THE SAME orientation and position like it was with an older one. I just delete the scripts there and put the new ones inside. In this case I can´t explaine different orientation of the poses by using the positions in .POSITIONS notecard. But it doesnt metter at the moment. I use the new MLP anyway for my new creations, just wanted to save a bit time for my old creations and dont update them to new scripts.

Thanks a lot! And maybe, if I am wrong with my changings described before, you can tell me this. Anyway in all of the scripts I used stands:

//MLP MULTI-LOVE-POSE V1.2 - Copyright (c) 2006, by Miffy Fluffy (BSD License)

so I cant say if it was modified or it was just a mistake of a scripting-newbie like me

I have no idea why you're seeing what you're seeing.

llGetKey() returns a different string for every object. You should NOT change -4 to another number. This text simply returns the integer number corresponding to the last 4 hex digits of the object's key.

Every object has a different key. The chance of two objects having the same last for characters is 1 in 65535. (You can improve those odds to 1 in 4 billion, by changing the -4 to -8 -- but using the same code for all objects.)

To see what is happening, put the original code back, and put an llSay() call to tell you the calculated channel number:

llSay(0, "Key: " + (string) llGetKey() + ", Channel: " + (string) ch);

See what that reports.

You should NOT need to change the code to keep two objects from interfering.

Right, that's the old script, called "~timeout". It has annoyed me once or twice, and that and a post above got me to thinking that there was a better way. The new one, "~~MLPT-timeout", shouldn't kick anyone off, ever. Assuming I didn't goof!

The new timout script is compatible with older MLPV2. How old, I'm not sure -- maybe even original MLP but I wouldn't put money on it.

Awesome, I'll nab the new stuff

I have tried to find if anyone is usin rlv as part of the mlvp. such as the capture and strip portion of the rlv....if anyone knows how to impliment it I would appreciate some help. Bare with me i am very new to all this.

Try searching MLPV2 (not MLVP), or MLP2 (which some folks use, but I always put the V in there). Unfortunately, these forums won't let you search on RLV since search terms have to be at least 4 letters. (grr!)

It's been discussed a bit, but I don't remember who's involved.

I keep recommending someone to start a thread on "RLV and MLPV2", but if anyone has, I haven't seen it.

I don't know much about RLV myself, but I believe that MLPV2 should already have all the features needed to make RLV adaptor scripts, similar to how xcite adaptor scripts work.

There are some products on xstreet for adding rlv functions to things such as the MLPV2, which might be another place to do some searches. I did beta testing for one of them, so that's the only one I know much about, but it was fairly configurable and worked really well with the MLPV2.

RLV with MLPV2 was also discussed a few weeks ago in the MLPV2 group inworld, so that might be another place to gets some ideas and/or help.

I've a question about re-syncronize the animations mostly when avatars jump on the first balls in different moments. I'm using MLP 2.4r
How MLP do this, if does, and when? Manually, automatically or not at all?

Thank you

I have been playing a little with an RLV adaptor script. It uses an adaptor script and a modified ~ball script to make the poseball RLV aware. I will post what I have when I get the chance.

Also if anyone has any links to detailed info on making RLV furniture that would be helpful. Most of the links I have found seem to be aimed at making relays.

Hmmmm? Not letting me post the scripts. Anyone who wants a copy please IM me and I will send them to you.

Not lettimg me post

I am using MLPv2.4t2 and have been having problems with sequences freezing during the running of the 4th or 5th sequence. When the notecards load, there is 3K of sequence memory left. Eventually, though, a stack-heap collision error occurs. Deleting animations and./or text from the sequence delays the onset of the error, but it still seems to always happen. Is there something that can be done in the sequences to prevent this?

Thanks for the report.

Which script gets the stack-heap error? IIRC, it's printed in the error message.

I'll try this myself. It would help to know roughly how many steps the sequences have, and if you run each to completion, and whether they loop. (You could just drop the sequence notecard on me, full perms please.)

You're probably using one of the forbidden SQL keyword sequences; see Void's helpful sticky post for more info:

/327/5d/330018/1.html

Also, please post this on a new thread: it's worth discussing, and it would be best if it weren't interrupted by MLPV2 bug reports an unrelated feature requests.

People are definitely interested. If the changes to ~ball are suitable, I can incorporate them into the standard. But I'm wondering what it needs that isn't already provided by the LMs sent by the ~poser* scripts.

The only mod I made in the ~ball script was to coopt the GREEN2 color to tell the ball to capture and force a sit if it detected an RLV relay within a certain distance. I am sure that there is a more elegant solution but I was more interested in a proof of concept than in worrying about a full solution at this time. When I get a chance I will try again to post what I have been playing with in a new thread.

I checked it out, and didn't see a memory leak. However, the amount of memory does go up as different situations are encountered, before stabilizing. I suspect you're at the edge of the memory limit for sequences.

In all cases, I saw memory consumption increase as I started sequences the first few times, after which it remained stable.

After resetting sequences (e.g., saving the notecard, or resetting ~sequencer), start the longest sequence. Do this again a couple times -- no need to let it run all the way through or stop it.

Do the submenu items go in the menuitem or the menuitem.xxx I have been searching all night for this information and the link on the wiki for submenu is not there. Please help, and thanks for an amazing product. Also on the props that many are having issues with. The scripts have to be in the item to be rezzed. I found two different ones in my inventory ~prop and ~props. The prop save would not work with just one, but when I placed both inside, it worked. Hope this helps

Submenu items go into whatever menuitems notecard their parent is in.



huh? Oh, I just had a glance. I think you might be meaning that that topic is not explicitly covered in a dedicated section....



The item to be rezzed doesn't technically need a script in it to be rezzed; you can rez a lump of rock with no script in it -- however, the item does for all intents and purposes need a script anyway for it to be able to do as it's told after being rezzed.



Only one script should go into an item to be rezzed, the one called "prop." This is the script that enables to rezzed item to do as it's told after being rezzed. The one called "props" with an s stays in the main body of your MLP product, with all the other scripts and animations, etc.

Hope this helps.

They can be in either, but it's a good idea to put all custom menus for your product on .MENUITEM.xxx notecards. That way, if you want to update to a new version that has new features in the OPTIONS menu, you don't have to do any cut/paste editing: just use the new .MENUITEMS notecard with your product's .MENUITEMS.XXX card.

All .MENUITEMS.* notecards are read in order and MLPV2 doesn't care which particular notecard something is in. It essentially just concatenates all the lines and treats it as one big config.

However, in the future, due to script memory limits that should appear in 2010, MLPV2 may save mmory by not reading in all the data for all notecards at once, so it might be a good idea to have a notecard per related set of submenus.

Thanks very much for the assistance, you rock. I now have submenu items and a much easier to work on bed. Taking it a stage at at a time..next sequences..wish me luck.