MLPV2 questions & bug reports

Not sure. However, what from I've read that was posted by Blondin Linden in the forums and in the recording of the Brown Bag Lunch for Merchants on this topic it sounds like a store like mine would not be considered adult content. It sounds like it is more about what is the setting and overall theme in which case I don't know that such an option to MLPv2 would make a difference.

I wasn't meaning to turn this into a discussion about Adult Content but more about options...and in hearing what people say and thinking a bit more it seems like it may not be a feature that would be used.

Thanks for being willing to think it through with me.

~ Desi

I get this message when restarting....

[16:04] VK 2.4 whispers: Warning: can't find prop 'pillow' in inventory
[16:04] VK 2.4 whispers: Warning: prop 'pillow' is no-copy!
[16:04] VK 2.4 whispers: Warning: prop 'pillow' is no-copy for next owner


the pillow is full perm....and why can it tell it is no copy if it cant find it????

TY

An update....the pillow is now recognized in inventory (forgot the script doh!!!) but it still reads as no copy and no copy for next owner....
wtf is going on???..it wont rez.

Help!!! plz

What are the perms on the script in the prop?

~ Desi

Perms are all set to Full...triple checked....lol

still no luck...pillow wont rez...

How do you mean, forgot the script? Which script?

I had the same question as Chaz. I assume you mean the script that needs to be in "pillow", but that wouldn't have caused the warning message. If you omit the "~prop" script in the pillow, it'll rez and won't warn, but it won't save, and it won't delete when changing poses or on STOP.

Note well! Object inventory is often just plain wrong. Usually, it's out of date: what I see on my screen is what *used* to be there. I've even seen completely different results for "edit -> contents" and "open", and seen that persist for 10 minutes or more. Relog fixed it.

If you are looking at stuff inside the contents of a prim, and right-click over one of the items, you should only get like 4 choices... (Open, Properties, Rename, Delete)... If you get a whole long list of choices, then the content ain't refreshed and you ain't getting an accurate picture of what's in there... If so, try one of the following -- relog as Lear said (sure fire, works every time), or look at the contents of another prim, then come back to the one you are actually interested in (works *some* times.)

What Chaz said -- only, if you get just the 4 right-click menu items, it doesn't mean it's an accurate list of the contents. Just *usually*.

When you get the long right-click menu, an update is due and usually comes (I've never seen it get stuck in this state, anyway).

Object inventory is particularly bad and slow for objects with lots of items. But the problem I mentioned earlier was an object with just 10 or 12 items. Everything else seemed to be working: I could get profiles, I could rez objects, and I could even see the correct contents using right-click -> Open. At least, I THINK they were the correct contents!

You can always try this, to see what scripts think are in the inventory. I can't guarantee that every script sees the same inventory, though I can't remember a case where I was sure they weren't. (Hit QUOTE button to see this code with indentation.)

default {
    touch_start(integer count) {
        integer ix;
        for (ix = 0; ix < llGetInventoryNumber(INVENTORY_ALL); ++ix) {
            llSay(0, llGetInventoryName(INVENTORY_ALL, ix));
        }
    }
}

Note: untested, uncompiled, probably contains typos and bugs. Correctness left to the reader as an exercise!

This was a good question. Even more to the point would be "are all the contents of the prop copiable (by YOU)?" Of course, if you're going to distribute, it would need to be copiable by next owner as well. Mod and xfer permissions are not required for next owner.

I'll go Lear one better and say *quite possibly* it's an accurate list :}

I often do an extra trick, of dropping in an extra deliberate dupe item, then deleting it, so that I've "jiggied" the inventory list a few times to be sure enough that I trust what I see.

I've been meaning to ask about if there was a way to remove some of the unused ~poser scripts.

With script limits coming in I'm assuming that this will become more important. I've yet to find out enough information to be seriously scared yet, but I would assume that my shop packed full of mlp goodies is going to be crippled.

So does anyone have any info on the impact of the new limits on mlp and can anyone advise how i can remove the ~poser scripts without it getting upset.

TIA

Good question. It should work, and seems to work, as long as you don't configure poses that need the missing scripts. The only problem is that you'll get script errors on startup, restart, or menu reset. These are safely ignored.

I took a quick look at making them work more like the "optional" scripts (~props, and one other I can't recall offhand, but look in ~run to see the list). Unfortunately, I can't just move them to the optional script list, because they need to be reset before ~menu. So, it would take a bit more dinkin with the reset logic.

However, I am thinking of a different option: having ~menu set these scripts to not-running whenever their respective ball isn't rezzed. That would be a better solution, since it would be automatic, and it would shut down all those scripts whenever MLP is STOPped.

*that* sounds like a great plan

have you had a chance to look at the script limit thingy yet? if everything is shared memory then i wonder just what is going to happen. I must have 20 or more separate mlp items in my shop, let alone what's in my workshop so I'm assuming that there's going to be trouble when they implement the changes. although I haven't got my head around just how it is going to work. I assume if the memory is blown then any inactive script wouldn't work on reactivation.. ok it's late and I am losing my grasp of the english language, but i hope you can see where I'm coming from.

Just the nudge I needed!

Turning off the poser scripts is working fine; I've upgraded my shop to this and it improved total script time measurably (well, 12 microseconds per MLPV2).

There are other scripts I can shut down when stopped, so I'll try that next and see how it works.

Concerning overall memory, I'm going to wait for measurement tools and to see what LL plans to use as limits to help guide the effort. I suspect suspending scripts will help, though, so this is worth doing from both standpoints.

Couldbe, I suspect that unless you have a fairly large plot, you'll need to make revisions.

I have an 8K plot, 1/8 of a sim. I have 9 or 10 MLPV2s running in addition to a few score poseball scripts, and I'm pretty close to my 1 millisecond "share" of sim script time for background usage. I won't be too surprised if it winds up being more than my fair share of memory. My MLPV2's have 50 to 100 or so poses. I shudder to think of the memory footprint for folks who are configuring 250-pose giants.

If you're on an 8K, I suspect you'll need to trim back. If you're on 32K, I hope you're fine (assuming you don't have a gob of other hoggy scripts). At 16K, I suspect you'll be borderline. But, we'll see.

I suppose I could change the memory announcing to give the memory used (rather than just available), so we could add it up and make some rough calculations. For now, though, if you want the numbers, just subtract the free memory from 64K and add them up, and that's most of it. There are a number of smaller scripts that don't report memory, of course.

However, if all your objects shut down scripts they're not using, there's more likely to be room for those who need it on activation.

Shutting down scripts that hold data might be a good strategy. It allows the server to store that information on disk rather than in RAM. This would work well for objects that are usually not in use. It might not work so well for things that frequently change from dormant to in-use.

BTW, I put a timeout script in all my display models that STOP it after 60 minutes of no menu activity. It deletes itself on owner change. I believe that's in the standard distribution, but if I forgot to turn it off, it'll delete itself on sale (oops!) I'll make a point to put that in ~MPL Tools, and store owners should make a point to include it in display models. I suspect I could reduce the timeout interval quite a bit, too!

Someone remind me to put this in the wiki someday! :-/

How did you do it Lear, like this? "However, I am thinking of a different option: having ~menu set these scripts to not-running whenever their respective ball isn't rezzed. That would be a better solution, since it would be automatic, and it would shut down all those scripts whenever MLP is STOPped."

I'm definitely interested in hearing more about this as well. The majority of my MLPV2 items have only 2 balls needed at most...so would be worth not having the others ~poser scripts running.

~ Desi

Stopped scripts also get reset on sim restarts, so experiment gently

On the topic of stopped scripts, I just thought I would post an observation...

I have a few purchased items at home, some use MLP2, some use XPOSE. I keep all "shutdown" unless in use. Interestingly, using estate tools, all XPOSE items show as running quite high on scripts even when shutdown - while MLP2 items drop low when not running. Two numbers to compare: XPOSE at 0.044 vs jPose at 0.026 or another MLP2 item at 0.023.

Hum, XPOSE went to 0.097. MLP2 figures holds pretty steady however.

Anyway, Lear, improvement is always good, but at least you can have satisfaction knowing that MLP2 is already WAY better on script time than XPOSE is.

Correction: The product I was looking at for MLP2 numbers turned out to be an XPOSE too. :-| I double-checked the figures and got better results...
I have one XPOSE item that oddly peaked at 0.365. MLP2 holds steady at 0.007.

And PerfectSitter? OMG the script usage time is through the roof.

thinking about this, is there a way that there can a modifiable variable in the notecard or in the run script (or where ever it is) where you can specify just how many of the poser scripts you want to run. that would stop the error message and would only require a couple of extra lines of code (yeah I know, famous last words and all that lol)

Ouch -- good point. I *knew* that, but forgot to consider it. This might not be a big issue, fortunately. It may take some scripts off the list of ones to disable.

The answer is that I'm doing it automatically, based on the number of balls rezzed, so when STOPed, all poser scripts are off, and I've turned off 4 others as well.

Maybe I could add a simple sim restart detector (since I'm disabling scripts anyway, any one of them could announce a reset, which could be interpreted as that in certain cases ...) and in that case, advice a Reset (but giving you the option of dumping and saving positions and props first).

I'm currently turning ~props off, but I'll have to take that one off the list, because someone might have adjusted a prop and not saved yet, and it wouldn't survive a reset.

As mentioned above, we won't need any lines for how many poser scripts will be running: just load them all in, and only the ones needed will run. (All will run at startup, but then get shut down as soon as the menu is ready.)

Rather than making a solution that requires fiddling on the part of every maker to take advantage of it, I'm focusing on the biggest gain with least effort.

Keep in mind that products usually contain a number of scripts in addition to the pose menu scripts.

The 'top scripts' tool is of limited usefulness, since it's a single sample. I've been meaning to write a JIRA entry requesting low-pass filtered values as well. These would show average usages, which would be more informative than single samples. And it only adds a single number per object to be kept by the sim.

In any case, when shutdown, MLPV2.4 shuts down all scripts but these:

~run
~swap
~timeout, if you are using that it

It doesn't shut down any XCite-related scripts, if you're using them. It only shuts down scripts that are part of the standard distribution. It does not shut down any scripts from MLP Tools.

The following scripts are optional and can be safely deleted, without error messages, as long as the respective features aren't used:

~props
~sequencer
~timeout (which generally shouldn't show up for the end user)

So, if my memory of left-on scripts is correct above, MLPV2 should take .006 ms when Shutdown. It takes considerably more when STOPped, though that is now less in my latest prototype.

.002 per script that's doing nothing. Most MLPV2 scripts do nothing most of the time, except for the periodic keepalive messages (once a minute).

My prototype now shuts down all but 6 scripts, thus taking .012 ms. Another way to look at it is it shuts off 10 scripts, saving .020 ms.

Any MLPV2 using more than a minimum of .032 has additional scripts in it.

I added a piece to my ~run script which does an inventory of all the scripts, MLP standard or custom, and then toggles them all (except ~run & timer if found) off / on as required.

But I suppose you'd have enough people who would want various other custom scripts never to be turned off, as to make such an approach impracticable.