MLPV2 questions & bug reports

Im sorry, I wasnt exactly sure what the issue I was having is.. I've figured out how to set up the sequences, so it shows up on the menu, and the menu Im using in the .menuitems notecard works fine, but the sequence just wont run.. Heres what I have setup in the .sequences notecard-

SEQUENCE | Romantic
MENU | Romance
POSE | standing
AVWAIT | 0 | Waiting for someone to sit on ball
WAIT | 10
POSE | Kiss
WAIT | 10
POSE | Enter
WAIT | 15...
...REPEAT

Like I said, it shows up in the menu selection, but no poseballs are rezzed when you select the sequence. Heres what I have in the .MENUITEMS notecard pertaining to the sequence-

MENU Romantic
LINKMSG Romantic | 0,-4,-12001,SEQUENCE Romantic
LINKMSG PAUSE | 0,-4,-12001,PAUSE
LINKMSG RESUME | 0,-4,-12001,RESUME
SWAP
STOP
BACK

Im not sure what Im doing wrong, I have gone through the readme, and all the instructions a million times, this is the only part Im having trouble with.. sorry for the lack of clarity in the last post.

In the sequence notecard:
Following SEQUENCE, put the name of the sequence.
Following MENU, put the name of the menu it uses.

Also, no two buttons in the whole menu system can have the same label.
You have a "Romantic" menu button, and a "Romantic" sequence button.
Only one of them would work.

Try this

SEQUENCE | Romance
MENU | Romantic
POSE | standing
AVWAIT | 0 | Waiting for someone to sit on ball
WAIT | 10
POSE | Kiss
WAIT | 10
POSE | Enter
WAIT | 15...
...REPEAT


MENU Romantic
LINKMSG Romance | 0,-4,-12001,SEQUENCE Romance
LINKMSG PAUSE | 0,-4,-12001,PAUSE
LINKMSG RESUME | 0,-4,-12001,RESUME
SWAP
STOP
BACK

BTW, if you use GOTO, it's a good idea to put an avwait after the label so that, if they hop off, it doesn't cycle endlessly, wasting sim resources.

Your problem is simple: you have two buttons with the same label, which isn't allowed. That's probably not mentioned anywhere in the wiki, so I'll try to remember to add that.

I assume "Romance" is a menu of poses, including "standing", "Kiss", and "Enter".

SEQUENCE | Romantic
MENU | Romance
POSE | standing
AVWAIT | 0 | Waiting for someone to sit on ball
WAIT | 10
POSE | Kiss
WAIT | 10
POSE | Enter
WAIT | 15...
...REPEAT

Like I said, it shows up in the menu selection, but no poseballs are rezzed when you select the sequence. Heres what I have in the .MENUITEMS notecard pertaining to the sequence-

MENU Romantic
LINKMSG RomanticMoments | 0,-4,-12001,SEQUENCE Romantic
LINKMSG PAUSE | 0,-4,-12001,PAUSE
LINKMSG RESUME | 0,-4,-12001,RESUME
SWAP
STOP
BACK

Hi,

I have begun a new project which will be making use of MLPV2. I want to thank you for continuing that project after Miffy moved on to XPOSE.

The product is in the works, far from complete. I cannot give details as it is, hopefully, something new to SL - at least parts of it are.

Anyway, I am writing about two issues I have run into, and am wondering if there is any chance of help on them.

-----

1. More then 10 entries in the main menu

Currently, all sub-menus will automatically get a "More" button if needed, but not the main menu. According to the docs, a "More" button must be added manually if needed. However, this is not very friendly to end users, when dealing with modular products, as ours will be.

Say the base product has one or two main menu entries, but then there are a dozen or more add-ons available for purchase, all stand-alone (ie, no one of them requires any other, aside from the base product of course). If a customer buys a lot, the main fills, and then we're faced with explaining (in the manul, which no one ever reads) how to extend the main menu.

Any chance of having "more" added automagically?

----

2. Memory

Yeah, this is a biggie! Even mono doesn't have unlimited memory, and the project we're working on if gonna grow BIG. I know that implementing memory expand scripts is NOT trivial, but is there any possibility of this being done?

Thanks in advance for your help.

-- Miro Collas

I love simple solutions, works perfectly now, Thank you SO much!!

Not too likely. I don't like this limitation, and at one time looked into fixing it, but it got ugly pretty fast.Actually, I'm more likely to look into making MLPV2 use LESS memory. You see, per-parcel script memory limits are coming. If your project takes more memory than MLPV2 allows, you'd probably be better off using XPOSE, where the scripts don't read the config (and thus take memory) until the menu is actually used. (I don't know whether XPOSE allows add-ons the way MLPV2 does, though.)

I may need to make MLPV2 work more like XPOSE due to the per-parcel limits that are coming. I like the fact that with MLPV2, you don't have to wait after selecting a menu. But the "just in time" configuration reading might be required in the future. I sure hope not!

Hmmm... sorry to hear about the main menu entries thing. One more thing on that though: would there at least be a way to have the top level "More" do nothing if there *is* nothing more? Right now, it seems to go to some other 2nd or 3rd level menu. Having it be ignored would at least be easier to explain to customers than explaining how to go edit the notecard.

[Sorry, I've had too many customers who wear boxes and then complain that a product doesn't work, so I always try to find solutions that make it easy, even for the box-wearing crowd.]

As for XPOSE, I just went to test my copy, as well as one or two items I bought which use XPOSE, and they all seem to load menus on start-up, like MLPV2 does. At least based on what appears in hover text (and man is that annoying!) Plus they respond way too fast to be loading menus and poses on the fly.

Also, XPOSE does not appear to be modular, but I could be wrong about that.

Otoh, DevPose by Riann Maltese loads menus on the fly. But I don't think that exists as a developer kit.

Anyway, that aside, I see the issue, and yes, that would be a good solution all round. And possibly simpler than memory expansion scripts too (aside from possible future limits SL might care to impose).

Thanks for the response.

-- Miro

NO doubt I was confusing DevPose and XPOSE. I don't have either myself.

I have 2 little problems with the balls rezzed by mlp2,
First....some of my items the balls do not go to the positions that i saved them at...and yes i have saved to the positions notecard..
The second is the sit offset i edited in the ball script does not work.....I put the sit offset to -3.0 so the balls wouldn't end up in the gadget...When i 1st rez a saved item...it all works as it should...but if i leave the item inworld and come back to it a day or so later...the problems occur.

Is it something i am missing??

Liann, first I suggest you try an unmodified ~ball script and find out whether it's working that way or not.

Second, get the latest version. There are two "latest", one on XStreetSL, which is the latest in the 2.3 line, and one at jPose Villa (see my picks), which is the latest in the 2.4 line. The main new feature in 2.4 is configurable swaps. Take your pick.

Third, after you do "save pos" (or if you're using Adjust Pos mode in more recent versions, that do the auto save), as soon as it saves, you should be able to use the pose menu button and get the new position. If that doesn't work, saving to notecard won't help.

When you save a position, it chats the new position. The first set of numbers between angle brackes should all be less than 10. If they're not, this is a problem people have been reporting, but I'm not sure what version or what circumstances cause it. If you see the big position numbers, make sure it's one of the latest versions as mentioned above. If it is, please let me know so I can look into it.

Finally, -3 is a huge offset. That's 3 meters, taller than any non-giant avatar. 1 meter (-1) is a more typical adjustment for that purpose. But don't fiddle with that at all until you have the rest of it working.

Be sure to use the ~ball script with the version of MLPV2 you're using. Sometimes they mix and match between versions; other times they don't.

BTW, folks, these days I'm reluctant to add new features, and prefer to concentrate on making it as robust as possible. I'm sure I introduced some bugs by adding so many features in rapid succession, and I'd like a cooling period to work out those bugs!

For expandability, I recommend each .MENUITEMS* file contain one unanchored menu, with any submenus in the notecard hanging off of that unanchored one. This allows 10 independent modules and only memory limitations on the total number of menus.

I don't understand what you're getting at here. By 'saved item' do you mean a saved pose? When "problems occur", exactly what goes wrong?

One problem I have seen is that on very laggy sims, balls or props can disappear. Balls won't reappear until after you hit STOP, because MLP still thinks they're there. (Props re-rez every time you choose a pose with a prop, so STOP isn't necessary in this case -- the prop is simply missing.)

Thanks for the reply....i'm sorry i made a typo with the offset...i meant to put -0.3....
and when i said saved item....I meant Item with the poses saved to the .POSITIONS notecard..But i think i found the problem.......When i edited the ball script i forgot to check the box marked mono when saving changes...also i possibly wasn't using the ball script from the current version...anyway....thanks for replying....

Was very pleased to see what you said about backing off on new features and working on de-bugging efforts. The work you are doing has been so great, I can understand the need to track down things that creep in.

What version do you recommend currently as stable for production use?

Lear, I second or third (or whatever it's on now) the motion to work on a stable "gold" release.

Part of that would be letting everyone know (as you know) that features are frozen, and any feature requests now coming in go on a wishlist for the fall, or whenever, and sticking to your guns, no matter how much they plead. That would also have the benefit, perhaps, of giving you a mental health break.

And when the gold release is issued, that would be a good occasion for us all to pass by your tip box again :} (Though I know this isn't about the Lindens for you, it prolly does take away from your main biz which pays your tiers, etc.)

I've used various versions of the MLP for quite some time, so I'm familiar with the system. The chair I'm currently working on was working just fine for awhile. I dumped the menu system in, the animations, and set all the positions which I then saved into the .positions card. I hard restarted from Tools>Reset scripts and tested it. I then noticed that I had a menu item I wanted to remove (part of the menu config* was copied from a different piece of furniture). So I updated the .menuitems notecard then checked to make sure that there was a corresponding menuitem line, animation, and position setting for each pose. Hard restarted again. This time around the poseball shows for only a second and then disappears. It does this for every single pose in the entire menu.

I tried changing to a transparent texture to make sure the poseball wasn't just hiding in one of the prims. The animations have all been used with no difficulty in other pieces of furniture. I tried replacing all of the scripts and other menu items. I checked the .menuitems and .positions cards repeatedly to make sure they were configured correctly. I tried copying the relevant menu sections again from another peice of furniture that I know it works in. I tried adjusting position to see if I could get the adjust bar at least. I tried all the reset options from within the menu. I took it into inventory and re-rezzed it. I went through numerous hard restarts in my various troubleshooting attempts. Finally I went online and upgraded from MLPv2.1c to MLPV2.3l and replaced all the system components again. Nothing I've tried has fixed it so that the poseball doesn't die after one second. I'm at a loss on this one.


*The copied part only included the relevant TOMENU lines and menu sections, none of the rest.

The best are the latest, which seem to be pretty stable if a lack of problem reports is any clue.

You can choose between MLPV2.3 (latest on XStreet) and MLPV2.4 (latest at jPose Villa). MLPV2.4 has configurable SWAP; see the MLPV2.4 .readme for detailed differences. When I find bugs that affect both versions, I've been fixing both versions.

Right now, as far as I know, the only unresolved problems are:

1) impending script memory limits and what to do about them

2) deeding to group

We'll postpone (1) until we know what the limits will be.

For (2), if you deed an MLPV2 bed, you lose the OPTIONS menu unless you remember to change all the OWNER menus to GROUP menus, and even then you won't be able to use full shutdown.

I'm surprised that nobody has raised this issue before; it just occurred to me recently as a possible cause of a problem (which it wasn't -- as it turns out they were using old MLP and not even the latest version of that). That would lead me to think it's not very important ... but I suspect it's just slipped between the cracks.

Hi Lear,

I took a bed I've recently been working on that has a pretty jam packed menu and tested it in the Scheduler Test 2 sim on the beta grid and it worked fine. Are you anticipated that MLPV2 will become borked by the new "fix" to the memory limits?

~ Desi

I am however getting a stack heap collision and script run time error on a different bed that has an even bigger menu. Is this ALWAYS a memory issue? Is my only recourse to make the menu smaller?

First, I'm relieved to hear that a 'tight' one doesn't crash. But, there are different kinds of 'tight', and I do fear that some which work now will exceed the new limitations.

More importantly, ones that push memory limits will push per-parcel limits.

Furniture makers are going to need to make products more streamlined for different kinds of customers, or give them ways to do it themselves. I suggest dividing menus & positions into separate notecards making it easy for customers to delete the ones they won't use. If the limitations are severe, I'll look into finding a way for MLPV2 to only load one menu notecard at a time, or something like that.

I believe there will also be pressure on furniture makers to (a) state the memory usage, and (b) focus on a smaller number of quality poses rather than cramming a product with every pose they can find regardless of quality.

Note that I am NOT implying that Des's products have low quality poses! I'm a big fan of her products, which I use for my living room and bedroom.

I strongly recommend that people test their big menus on the beta grid. I plan to do so myself.

It depends on which script is crashing. If it's ~memory, you can reduce memory usage by optimizing your .POSITIONS* notecards. Remove any lines for poses that aren't in use.

Also, these notecards often waste lots of space with trailing zeros. The latest MLPV2.4 version now deletes trailing zeros on "save pos" and "save prop" (and if you convert notecards using 2.4, you can use them with 2.3). The quickest way to re-save ALL your poses is:

1) drop .MENUITEMS.reorient (from MLP Tools box) in.
2) Menu Reset.
3) Use the Reorient menu to move all the poses by 1 cm. This will save all the poses, with only a small change. If you don't want the 1cm change, then just move it back 1cm after it finishes. Wait for both props and pose adjustment to complete! (Be patient!)
4) dump pos, dump props, and save to appropriate notecards.
5) Delete MENUITEMS.reorient, and restart.

I will be offering a .MENUITEMS.optimize notecard soon that will add only one button (so it'll be less likely to crash a working menu), that won't actually move any poses but will cause them all to be saved (it'll move them by zero amount).

Good info. Thanks!




Hehe...thanks for clarifying and for the plug




As always--you rock!

~ Desi

Are the two .POSITIONS the same? I'd like to upgrade the menus I used in my furniture items from MLP to MLPV2, but the thought of having to reset all those positions is a bit discouraging. I've scanned through the forums, and read the tutorial, but didn't see this question asked/answered.

Thanks,
Kermi

I would encourage all those upgrading from MLP to MLPv2 to examine the animations they use, and to discard (or legalize) the pirated ones they are using. A list of pirated animations is here: http://slfreebieslist.xonat-qayos.com/

It would be nice if MLPV2 stayed clear of the bad rep that MLP acquired owing to people's use of pirated animations with it. Again, the list is here: http://slfreebieslist.xonat-qayos.com/

There are many quality animators in SL now, and the price of getting current animations is very reasonable considering the profit that can be made on animated products.

Actually, I DID purchase or make the animations in my furniture, and you really didn't answer my question.