MLPV2 questions & bug reports

OK, thanks

I'm surprised I didn't bump into that myself yet. I usually make every possible mistake!

BTW, if anyone wants a good laugh:



See the discussions. Thanks to Chaz (I think it was Chaz) who pointed this out to me, when the guy was selling "MLPV3.0" for L$750. He removed that listing after I got a copy but before I posted my discussion.

OK, I'll go back to my pathetic little life now.

I bought the xstreetsl version have it the same poses of the in world version? it only have 6 and is for sit lol

I thought I'd use the same command line in the notecard as you can use (or at least used to) to give items.

It doesn't work

I assume it's because the code is only set to give objects. I had a look in some of the scripts to see if I could find the code to hack it but the closest I found was in ~menu and didn't really look right at all.

so, can anyone tell me how I jig this thing to give a notecard?

This is what I had for the linked message



I tried setting it up as both a button on the menu and as a separate menu and neither worked so I'm thinking that it is because it's only set to give objects

thanks

A bit more on the memory issues.
I found this in the LSL Wiki. It does help to explain a lot of what I am seeing.
http://www.lslwiki.net/lslwiki/wakka.php?wakka=MemoryUsage
A string in a list uses 12 bytes + 1 per character per string

The current way is to store the name of the pose in one list, and divide the rest up into four lists in a round robin manner.
So there is 24 bytes of overhead with each pose. Not much choice here unless we parse the data everytime we search for a pose, which would take too long and add to the lag involved.

I am working on a modification to the way MLP handles the storage of the position information. I am using the method everyone else seems to be using. That is having a master ~memory script with four sub scripts that hold the lists.

I have most of this working now. The position information now loads, stores, updates, and dumps the position information using 4 sub scripts. This is transparent to the rest of the engine, the only changes are to the ~memory script, and the addtion of the four new ~memory1..~memory4 scripts.

I am now working on handling the adjustment and Reorient tasks. Once those are implemented this should be a simple update to the engine.

btw my bed now holds 187 positions with out even breaking a sweat.

More to come,
Lizzy

I think i need more positions... lol can someone send somes poses to me? lol

Motorola,

You may be able to find some free animations at some of the reputable freebie stores. Be careful though because if you want to sell items with animations in them you will want to make sure you are using animations intended for that purpose.

Other options are to learn how to make animations using a program like QAvimator or Poser (there are other programs as well) or to purchase animations from animators here in SL. If you visit www.xstreetsl.com and go to the marketplace you can look at animation options there. You can of course also use inworld Search to find animation stores.

~ Desi

Ok thanks

Giving items isn't a built-in feature of MLPV2.

The LINKMSG line creates a button that sends a link-message to another script (which you would write, or get someone to write). That script can do whatever it wants based on the message. What's missing in your case is this extra script. It's possible that someone posted one on the twiki -- if so, try using that one.

Make sure you know what the giver script needs as its linked message, and pass the correct text. In your example above, it looks like it'll give "Notecard 1" and chat "You're in trouble now", but that's just a wild guess. That's if you can find the script that went along with this notecard line you're quoting.

Hi There,

I'm using the latest MLPV2 version and its simply amazing. I'm finally able to bring my design creations to life... THANKS Lear!

Now onto my question....


Upon clicking the prim to start the menu or to turn on, I don't actually have any pose balls show up until I click within the menu and select a option. Is there a way to program the MLPV to show a default pose ball and set upon start up?

I've referred to the http://wiki.secondlife.com/wiki/MLPV2_Reference_Manual#TIP.21_Default_Pose Default pose section in the wiki but still upon start up no pose balls rez until I click the menu.

Have I missed something or is there something else?

Thanks!

I'm new to MLP and I'm having a problem that I can't seem to figure out. I'm using the latest MLPV2 scripts from the XStreet link at the beginning of this thread, and I haven't edited any of the scripts. The only things I've changed are the .MENUITEMS notecard, and I replaced the default ball with my own (after copying the script out of the default one).

The issue I have is that poseballs report (and the system stores) their positions as absolute world coordinates, but the controller interprets them as being relative to its own position... So for instance this is an example of the positions being reported with a controller located at 30.0, 225.0, 3000.0:



After a restart it then merrily tries to rez the balls up at 6000m (not to mention with a Y value that also isn't possible).

So what am I missing here?

Give tool is here:

http://wiki.secondlife.com/wiki/MLPV2_Give_Item_Add-on

I don't know quite what my problem was, but I fixed it by rezzing a new (empty) sphere prim and moving the contents of the old controller across to it... That was only intended to be the first step in my attempt to narrow down the cause, but everything worked perfectly afterward.

I'm not sure it matters, but the original controller was a single-prim sculpted mushroom. Since MLP worked with the plain sphere I just made that invisible and linked the mushroom to it (sphere as root) so that the mushroom could still operate as my control mechanism... And since it all works now I've decided not to mess around with it for the sake of a single prim.

This can happen and seems to be an SL glitch. Sometimes waiting it out and trying later, rerezzing an MLP prim or starting a new one, or changing sims will do the trick. I've really found that it is an SL issue as opposed to an MLPV2 issue.

You're missing a great marketing opportunity! Double the price of your stuff, and say, "For sex so heavenly you'll feel transported!"

STOP turns off scripts, including sequencer, etc, as it should, in order that scripts aren't running when they aren't in use.

Normally, just clicking MLP and choose a POSE seems to start the scripts again.

However, picture a scenario (which I just stumbled across in a product of mine) where you don't have standalone poses, just, say, 3 sequences, so three sequence buttons. So there is no POSE button to press. If you press STOP, the scripts get turned off, and you can't use any of the sequences anymore until you restart the whole product.

Caveat: I may be doing something wrong.

Edit. Ignore. Doesn't work. Problem is that when ~sequencer is turned off, it appears to essentially be just frozen (in the middle of what it's doing.) When it's turned back on, it's all confused. Timing doesn't work, etc.

Only solution is to make sure there's a POSE that users can use to start things up again after a start, before going into a sequence. Then, the sequence script starts timing things normally again. Can't find in the scripts what the POSE cmd is doing special cause brain is fried after 12 solid days of MLP.

Oh, version: 2.4N2

____________________
Lear will likely think of a more logical way; here's what I'm doing in the meantime. Slight mod to my ~menu script:

in integer handle_cmd() function, added the 3 lines with the >> in front of them, as shown below. This will turn the sequence script back on.


} else if (cmd == "LINKMSG" {
// menu button to send LM to a non-MLPV2 script
integer ix = llListFindList(LMButtons, [button]);
if (ix != -1) {
//LINKMSG Romance| 0,-4,-12001,SEQUENCE Romance-seq
list lmparms = llCSV2List(llList2String(LMParms, ix));
>> if ( llList2Integer(lmparms, 2) == -12001) {
>> turnScriptsOnOff(TRUE);
>> }

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
}
}
}

I'm new to using MLP and am creating my own animations. The problem is this. The poseballs appear and avvie #1 gets on a ball and it's animation starts. Then avvie #2 gets on the second ball and it's animation starts...since the animations are starting immediately when someone sits, they're out of sync. Any ideas on how to handle this? Thanks!

Thanks Desi.

This is a problem that I keep hearing about, but have never seen myself. In any case, I recommend what Desiree says, or trying "Tools -> Reset scripts in selection", and crossing one's fingers. Maybe someday we'll find an MLPV2 bug that causes it, but it never seems to persist long enough to track down.

Check the phase of the moon.

There are a few problems with STOP turning off scripts (to minimise lag). For example, sometimes a ~poser script is stopped before it releases permissions, after which it loses its input queue and thus keeps the permissions. This causes the reanimation bug to reappear.

My plan is to change the way it works, so that the scripts all turn themselves off rather than having ~menu do it.

Hopefully that will fix Chaz's last problem. I'll have to give more thought to automatic startup, though. Chaz, please keep bugging me about this!

Currently, the only workaround is to choose another pose (making sure it's one with different anims) and then go back.

In theory it's possible to have the notecards designate poses that need to be periodically resynchronized. To do this, MLP would probably play the default pose's animations (but not positions) for a very short time. I've heard reports that when done properly, it works reliably without even being visible in most cases.

But I haven't given this too much serious thought. We'd need a way to configure it (per pose, most likely) in the notecards. We'd need a way to communicate the status to the poser scripts. And we'd need the code in the poser scripts to do the resynch, but that would be the easiest part.

The best but hardest part would be to automatically resynch whenever someone hops on a synchronized pose.

In any case, a pose would always be unsynchronized when you select it the first time, because it takes different amounts of time for each anim to download to your client, and the client starts each anim when its download completes.

What about for instance, dance poses, where the first animation doesn't start until the 2nd avvie is on their ball...how does that work?

Those poseballs work like this:

When you jump on, you get a static pose animation.
A script waits to get confirmation that someone has hopped onto the other, linked poseball.
When it does, the real animation kicks in for both poseballs.
This is to make sure that the real animation starts at the exact same micro-second in time.

Sylva, for instance, names her anims sort of like this:
kiss-f
kiss-f-standby
kiss-m
kiss-m-standby

Gianluca Munro does this:
kiss-f
xkiss-f
kiss-m
xkiss-m

Anyway, you soon figure out what the naming scheme is for the standby animations for a given animator. Sadly, there are no naming conventions for animations (not even by the same animator! argh.)

Anyway, so when popping the anims into MLP, you discard the standby animations. Not used. Just pop in the main ones.

Set up the pose.

When placing the pose on the menu, if it's absolutely critical that the animations for both balls begin at the same nano-second, then place the pose in a spot on the menu where people won't be likely to click on it as the first pose.

So ideally what will happen is: they'll click on a pose where exact micro-second synchronization is not mission critical. And they get on the balls, etc. Then, when they do choose the pose for which precise synchronization *is* mission critical, no worries -- no waiting needed, cause they are both already on the balls and ready to go for that pose, so both animations can start at once (as they do, anyway) with no issues.

I need to add here that the above is how I approach it. Others may have different, better ways.

version 2.4n2

Re NOCHAT in sequences card turning off ALL chat.

Have discovered this occurs only if the last sequence to be read had NOCHAT in it.

If you have 3 sequences set up, the first two can be NOCHAT, the last one can't.

If you have 2 or fewer sequences set up, you can't use NOCHAT on them unless you really want all chat to be turned off everywhere.

In case anyone ever has a need here are some easy mods I did to make it so that if you clicked on a rezzed MLP prop, that click would "transfer the click" as it were to the main MLP prim and bring up the menu for the user.

Don't try this unless you're a confident scripter as this is offered without support -- and if you rely on it, you'd have to make the changes with each MLP release that you upgraded to, anyway. And this is not supported by Lear, so you'd be on your own.

Step 1: Replace the contents of the ~prop script (not ~props, but ~prop -- the one that you put inside the rezzables) completely with the following:

// MLPV2 by Learjeff Innis.

// Put this script inside any MLPV2 prop.
// Supports saving the prop's position
// Dies on timeout if MLPV2 object is removed.

integer ChatChan;
vector OrigPos;

//chaz addition for pool floaty to talk to menu
integer menuchannel;
//chaz addition for pool floaty to talk to menu


default {
on_rez(integer rez_arg) {
ChatChan = rez_arg;
OrigPos = llGetPos();
if (ChatChan != 0) {
llListen(ChatChan, "", NULL_KEY, "";
llSetTimerEvent(180.0);
}
}

listen(integer chan, string name, key id, string msg) {
list TempList = llParseStringKeepNulls(msg,["##"],[]);
string cmd = llList2String(TempList, 0);
string tmp01 = llList2String(TempList, 1);
if (msg == "SAVE" {
// report change in location since rezzed
llSay(ChatChan, (string)(llGetPos() - OrigPos) + "/" + (string)llGetRot());
OrigPos = llGetPos();
} else if (msg == "DIE" {
llDie();
} else if (msg == "LIVE" {
llSetTimerEvent(180.0);
}
//chaz addition for pool floaty to talk to menu
else if (cmd == "Menu Channel"
//llSay(0, "heard menu channel";
menuchannel = (integer)tmp01;
menuchannel = menuchannel - 1;
//chaz addition for pool floaty to talk to menu
}

timer() { // Haven't heard "LIVE" from menu for a while
llDie();
}

touch_start(integer total_number){
// llSay(0, "Menu Please##" + (string)llDetectedKey(0));
llSay(menuchannel, "Menu Please" + "##" + (string)llDetectedKey(0) + "##" + (string)llSameGroup(llDetectedKey(0)));
}

}

2. In the ~props script (that's the ~props script that gets put in the main MLP prim) under state On, under the link message event, make the following mod:

if (str == "POSEB" {
rez_prop((string)dkey);
//chaz addition start
//sending menu channel to pool floaty
llSleep(2);
llSay(ChatChan, "Menu Channel##" + "0x"+llGetSubString((string)llGetKey(),-4,-1));
//chaz addition end
return;
}


3. In the ~menu script, under state on, change the listen event to be as follows:


listen(integer channel, string name, key id, string button) {
//chaz addition for pool floaty to talk to menu
list TempList = llParseStringKeepNulls(button,["##"],[]);
string cmd = llList2String(TempList, 0);
string tmpwho = llList2String(TempList, 1);
string tmpgroup = llList2String(TempList, 2);
group = (integer)tmpgroup;
if (cmd == "Menu Please" {
id = (key)tmpwho;
}
//chaz addition for pool floaty to talk to menu
if (id != user) {
if (button == "Yes" {
user = id;
group = llSameGroup(user0);
mainMenu();
} else if (button != "Cancel" {
continMenu(id, "Selection cancelled because ";
}
return;
}
if (handle_cmd(button, FALSE) && redo) doMenu(FALSE);
}

Note: in the above, I'm a bit murky on how the samegroup stuff fits into a touched() function at the top of the script