MLPV2 questions & bug reports

Winter, the simple reason from my point of view is that this is how it worked in old MLP, and I didn't see a compelling reason to change it, which would be a lot of work and most likely introduce new bugs, with no new features (but somewhat reduced lag due to fewer listens).

I wish I knew what the actual cost of a listen is. Unqualified listens (ones that listen on channel zero, for any string from any source) are clearly very evil, since the script's handler runs for each chatted message. What's less clear is the runtime cost for a listen on a channel that nobody chats on.

However, here's one issue. If you sit on a linked poseball, edit linked set, and move the poseball, your avatar doesn't move with the poseball. This means that rather than allowing people to use the normal editing interface, you'd have to build a new one into your scriptset (e.g., buttons to adjust things, like we have on no-mod, menu-modifiable products like hair). I find those menu-button interfaces clumsy and wouldn't want to put together or adjust a big pose set using something like that.

Hello, I have been learning to rez props with animations and so far it's been good. My question is...Can I make more than I item rez with the same animations at the same time?

No, other than having the rezzed object rez another object from its contents.

You *might* perhaps try it as a coalesced object, making sure that each item has in it the necessary scripts provided so they can die when required to -- but I'd want to experiment with that somewhere in the open at first in case it might go all over hell's half acre :}

Since I switched to MLPv2.4h yesterday, I'm having a problem adjusting positions. The chat and position dumps are reporting absolute positions rather than offsets. An example is:

{Sit 2f} <89.005,188.686,351.728> <-9.0,0.0,90.0>

Resetting and recompiling have not made a difference. Moving to a different sim and resetting has helped a couple of times, but after 2-3 poses are adjusted, this issue recurs. I changed back to 2.4d and the problem seems to be happening there too now.

I am having the same issue with both MLPv2.3k and MLPv2.4d. An example for me is:

[1:07] : {StretchOut} <161.995,130.333,22.841> <-2.1,-0.1,-87.5>

Help!

Would someone having this problem please try it with an old MLP as well?

I can't imagine why this would change suddenly, so I suspect a server issue.

Please post what server version you're using (Help -> About Second Life).

Thanks for the reports.

Well it seems that SL was just having a HUGE glitch last night as it seems to be working fine now.


~ Desi

(waves at Lear!)

I encountered many system issues last night on other non-MLP products I was working on -- scripts and notecards not saving, etc.

/me waves back!

I have mixed emotions. Happy I don't have a bug to fix, but sad that SL could screw up in such a way!

Glad it's over, in any case (if indeed it really is ... knock on wood!)

I have a question about animation packs. I know the readme notecard says that the scripts read the notecards in alpha order. If I were to name the notecards as A, B, and C would the buttons on the menu then be in that order as well? I'm picky--I like my buttons in a certain order.

~Desi

Yes.

Gotta love a simple answer!! Thanks Lear!

~ Desi

I'm trying to help someone who says to have crosstalk issues (using MLPV2.1c).

When browsing through the scripts I noticed that the chat channels where choosen mostly from a 16bit Numberspace ((integer)("0x"+llGetSubString((string)llGetKey(),-4,-1))).

Is there any problem to expect when I extend this to 32bit in the scripts?
((integer)("0x"+llGetSubString((string)llGetKey(),-8,-1)))?

I found something in the code that might cause this under unusual circumstances, and changed the code to avoid it. I posted it on MLPV2 group, or you can find it at jPose Villa Freebies section (see my picks for location). Please give this a try.

The problem is that the positions have numbers bigger than 10 in the first vector (stuff between the <>. They seem to be the actual location rather than the position relative to the MLP prim. If that's what you're seeing, try the latest.

The problem would be caused when there's significant LM lag but chat is fast. Normally, things work the opposite way, but who knows what evil lurks in the mind of a server? And the code shouldn't rely on who wins the race anyway.

Interesting: I never noticed that it's only 16 bits. (I never changed that from Miffy's original MLP code.) Yes, extending it to 32 bits would reduce the probability of an accidental collision, and shouldn't cause any problems.

Anyone remember their prob/stat well enough to calculate the number of people who have two MLPs within 10M to get an even chance of a collision with 16 bit numbers?

Let me know how it works out, and I can change the baseline code. Of course, the likelihood that this is causing a real problem is pretty low. To verify that's the problem,

Finally, have them upgrade to the latest MLP. While I fixed the crosstalk problem early on, the fix got lost, and I don't remember which early versions had it and which didn't. The real cause for the problem is for a copiable object, with multiple copies using the same value due to not recalculating it when rezzed.

My earliest fix was to reset on rez, but later I realized that all I needed to do was recalculate the chat channel. This happens in several different scripts.

Rule # 1: if it's broke, upgrade to the latest version!

Hi Lear,

First of all thank you SOOO much for looking into this. As you know it's been driving me loopy. I notice in the new MLPV2.4i that there are two balls -- ~ball and ~ball-dbg. Which one should go in the MLPV2 prim? Also, the ~ball-debug script in the ~ball-dbg is no mod/no copy which I'm assuming should be full perms if we're to use it?

Thanks again!

~ Desi

As for the stats I'd say that depends more on the likelyhood that 2 prims are very close with their UUIDs on the last hexdigits, than on the pure math of how to pick n out of 65k. I'm not sure which generation algorithm LL uses for their UUIDs. For pure random pick the likelyhood to colide whould be pretty low.

I will test it to see if I encounter problems with that changes. The only annoyance I can think of right now might be hitting the debug channel, which could be ruled out by bitwise and-ing with 0xFFFFFFA0 (you should be guaranteed to stay at last 31 channelnumbers away from 0x7FFFFFFF by doing so).

I suggested the change to 2.3f already for my friend and will try my changes in that release. Even if the crosstalk chance is already very low between diff MLP instances, getting lower seems no bad thing and given that you might have other devices around whose channel choice you can neither controll nor configure, a bigger pools of channels to choose from seems favourable to me.

which turns out to be the same thing.

Look up UUID in wikipedia. I believe that SL uses the total random format.

or hitting zero, which would be even worse. Or hitting a number ust below debug channel or zero, since it uses the given channel and several channels (up to 22, IIRC) above it.

In any case, the first thing to try is to reset both items that are getting crosstalk. Most likely, it's the problem I mentioned above, and this will fix it without any script changes. If you test without doing this first, you won't have learned whether your changes fixed it or the reset fixed it.

In any case, I bet this is not your friend's problem: the problem is that the channel isn't being recalculated.

Finally, it's generally best to use the mainstream release, unless you're willing to keep making your changes to new versions as you upgrade.

Thanks for helping your friend, though, and for posting your thoughts here!

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.

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.

I located the error in the ~menu script:

The issue is located in this section:


else if (cmd == "LINKMSG" {
// menu button to send LM to a non-MLPV2 script
integer ix = llListFindList(LMButtons, [button]);
if (ix != -1) {
list lmparms = llCSV2List(llList2String(LMParms, ix));
llMessageLinked(
llList2Integer(lmparms, 1), // destination link#
llList2Integer(lmparms, 2), // 'num' arg
llList2String(lmparms, 3), // 'str' arg
user0); // key arg
if (llList2Integer(lmparms,0)) { // inhibit remenu?
return FALSE; // yes, bug out
}
}
}


More specificaly here :

if (llList2Integer(lmparms,0)) { // inhibit remenu?

the if statement is missing the item to compare to, the line just needs to be changed to:

if (llList2Integer(lmparms,0) == 0) { // inhibit remenu?

and this will solve the system ignoring the noregen option for a LINKMSG menu entry.

Sorry if this was posted already but I got tired of reading all 13 pages.

Kuma

I just bought the MLPV2.4i about two days ago and though I've looked through this thread and the Wiki I'm still having a lot of trouble figuring it out. Today I was finally able to get the first menu to come up, but for some reason when I click on the button to go to a submenu I get this same error: "llDialog: button labels must be 24 or fewer characters long" and I did not forget to put the | between the POSE name and the pose animation. Any ideas on why my submenus won't come up?

Oh, and on the menus where I am not using submenus I cannot get the poseballs to rezz...I mean not at all. Not below, not above, not in, and I have filled out the positions notcard. So could I get some help with that too?

(P.S. I only read the thread to this point, so if someone else asked about this, I'm terribly sorry, but please help. T.T)

That's usually caused by omitting a vertical bar in a .MENUITEMS* notecard. One of these days I'll look into scanning for that mistake on reset.

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.

Thanks; I'll look into that. Thanks for being clear about the version, especially since it's contradictory.

Please tell me what the Description on your MLP prim is. I suspect it's 10 or perhaps -10, due to your having used the Height menu.