MLPV2 Modularity issues -- bed makers

MLPV2 is a set of scripts that provide menu-based poses for furniture.

One MLPV2 feature is that it's modular. Sets of poses can be added to existing MLPV2 objects simply by dragging config files and animations into the object. The method is very simple: it reads all .MENUITEMS* and .POSITIONS* files, in the same order as in inventory, and treats them all the same. (Of course, .MENUITEMS has to come first as it has the main menu, but otherwise order isn't critical.)

The only other trick is that the main menu is populated with placeholders, and any MENU configs that don't belong to TOMENU statements from other menus replace the main-menu placeholders.

So, if the original maker of the object doesn't use all the main menu slots, the user can easily add more poses by dropping in more .MENUITEMS* and .POSITIONS* files. Ideally, an add-on would have one un-anchored MENU to go on the main menu, and all subsequent menus in the config would chain off of that.

For compatibility, though, there's an issue: the orientation and shape of the MLP prim.

For beds, most people put the scripts and animations in the mattress, though there's a good argument for putting them in a leg.

When it's the mattress, the orientation of the mattress is critical. For square or sculpty mattresses, the prim's local Z axis usually points up. However, many mattresses are cylinders, rotated 90 degrees and squashed, to imitate the curvature of the top of a mattress. This rotation causes a problem: pose sets that are made for one type will be rotated 90 degrees off when used in a mattress of the other type.

The advantage to using one of the front legs of a bed is that it defines two edges of the bed regardless of mattress size, allowing poses to be positioned along these edges with minimal end-user adjustment required. Of course, poses that belong in the middle of the bed won't be precisely in the middle, since mattress sizes vary.

Vertical position isn't a big issue, because of the Z-offset feature from MLP. However, the height of the mattress, knee height vs. thigh height, affects what kinds of poses work.

I'm interested in addressing these issues so that furniture makers can make items with the widest compatibility with animators pose sets, and vice versa.

One approach would be to have a set of standards for the common types, e.g.:
- type A: center of mattress, Z axis points up
- type B: center mattress, Z axis points to head of bed
- type C: front right leg

Sofas could follow the same convention for center cushion or right-front leg. One or more standard cushion depths might be necessary. For beds, we might want an additional option: mattress height (low or high).

But this leads to a lot of different options, making it hard for a maker to decide which formats to offer.

Another approach would be to provide a scripted solution. The ideal would be a button on the bed for the user to re-orient for prim rotations, but it ain't gonna happen ... at least, not before Mono rolls out. Memory is already too limited.

However, it is possible to write scripts to convert between the different mattress rotations (A and B, including other 90-degree rotations). It would spit out a new set of POSITIONS file entries. Most likely, it would be a bit tricky to expect the typical end user to use, but it would allow pose-set makers the ability to more easily stock sets for multiple styles.

Comments and suggestions please! I'm especially interested to hear from furniture makers regarding any issues I've neglected, and how practical it might be to try to standardize on prim orientation.

Thanks!

Lear, I see where you are going with this and it is an infinitely groovy idea to be able simply add pose packs and expansion onto existing pieces. However, as a furniture maker, I just don't see a way to accommodate every single type of prim that a MLP could end up in or rotations thereof. I've got stuff made with sculpty, torus, cylinder, cube, sphere....

The second challenge is that it takes a bit for people to get up to speed with some of the finer details of building - like the orientation of your prims, especially root prims. This leaves a newer builder up a creek when they orient something wrong in building, they add in an MLP system, and then it's all wonky -- and you have a customer service IM resulting since your name is on the scripts. Or let's say the builder adjusted all their pose orientations (not knowing any better that the prim orientation was the fault) and put their product out telling customers they could add in pose packs later. Customer does so, poses are all oriented off, builder gets angry IM that their product sucks.

The only way I could see to solve all that would be to make the MLP always have to live in a specific type of prim within the furniture link set - which adds another prim to the build if the builder hadn't already planned on using..say..a cube prim in the their piece. Really, the only way this works for aftermarket expansion packs is if the MLP scripts are always in a specific type of prim across the board and that becomes a "rule" for everyone who will ever build something, stick an MLP script in it, and call it furniture.

As many different prim types as exist, someone is bound to use odd stuff in their designs and that will end up throwing the whole "expansion pack" idea off. I know as a builder I'd rather not be restricted by what I can and can't turn into a piece of furniture -- that's part of the fun of SL.


(PS, I was never able to change the menu button or the hover text on the balls from "Love" to "Sit" -- it would be really handy to have that as a configuration setting just like it is on a regular poseball....)

I'm with Isablan on this one. Once you go down the path of trying to anticipate and accommodate some subset of the myriad ways people will try to use MLP, you'll find yourself in an impossible position. Heck, I consider myself a decent builder/scripter/animator and I invariably plop the MLP into its own invisible prim laid over the top of the piece of furniture in question. It's only 1 prim.

Of course I don't actually sell furniture so feel free to ignore me

Lots of the beds I make, don't have legs. And lots of the sofas I make, morph into beds.
I also tried making a default sculpt mattress, to make things easier for myself, but found myself using different ones anyway, for different beds.
And in almost every case, the positions need to be set for the particular bed.
If it has a frame or not that protrudes past the mattress... a headboard and footboard change how you can use positions too... height of pillows... retractable cover or no...
the variables are endless.
eventually we just started making our own animations. because other ppls ones fit poorly.

then you go on to jaccuzzi, hammocks, rugs, tables, kitchen counters... the list is endless. there are so many places ppl want their nookie that i think it will be impossible to standardise anything

the idea though, is brilliant..being able to add any creator's animations to any MLPV2 piece

im not technical so bear with me:

all my beds now are 3x4x0.75h. my engine prim [while im working its textured with an arrow that points towards the pillows] sits slap bang central to that. the engine is .5x.5x0.85 so it sticks out a tiny bit on top. positioning is therefore relative to the bed.

while i will not be doing add-on packs as my engine is already full to capacity, if memory ever gets increased i would do the following:

i would pre position add on packs to my bed dimensions so when client drops pack into their engine and if the gods of sl are kind, after a reset everything should work.
u could always do options for 3.5, 4, etc width beds if u have animations that u position at the edge of the bed say for sitting or standing by the bed. i also inform clients that boy/boy beds are prepositioned for 7ft avis, girls for 6.5 and str8 for one of each. customers find it easier to adjust their size than faff around with tweaking the positions.

the same could be done for a sofa, chair, shower etc if you pick the middle of it as placement.

the only disadvantage i can see to the abv method would be if someone buys an add on pack from another creator.

***while here may i ask, is anyone having issues with saving the .positions and .menuitems and then finding the positions are all skewy in spite of this?
and is anyone having issues with some animations that often forget to stay where they are positioned. im finding this is the case with one particular animator's work.

I agree, Isablan, Anti, and Eku -- there's no way to accommodate every possibility.

However, I'm confident that there *is* a way to accommodate those who (a) want compatibility and (b) are willing to follow a few simple conventions. Feel free to be incompatible. Many kinds of furniture can't possibly be, and that's fine. I won't put anything in MLPV2 to keep it from being as flexible as possible. The vast majority of furniture items I see conform to one of the 3 models above. (BTW, it doesn't matter what kind of prim it is, just the orientation: center of bed or other, and where the prim's local Z axis points.)

Beds without legs can have an invisible prim in the front right corner (or front left, if you prefer).

I forgot about round beds. IMHO, when making pose sets for arbitrary beds with poses using the bed edges, stick to the middle of the edge so poses work with round beds as well as square ones.

Toothfairy, there should be no difference between using an "engine" prim and plopping the MLP in the mattress, assuming the prim orientation is the same, except that the engine either needs to be the root prim, or else you need to put ~touch_passer in the root prim. The nice thing about an engine prim is that you can move it to align the poses with the edges of the bed (or whatever). This kind of thing is a prime candidate for compatibility.

I make an MLP bed cover that you can float over any bed and then click to make it invisible. No need to link it in (though you can if you want, and doesn't need to be root prim; just click it). It's a torus, so you can flatten it or leave it curved a bit as desired.

Currently, memory is a limitation. But when Mono hits the grid, it won't be. With 16K of memory, we have room for a pretty comprehensive set of poses (50 to 70, depending on how many have more than 2 avs). With Mono, we'll have more than 4 times as much capacity. Given that, I think it behooves us to do something that's beneficial to the customer: make it easy for them to collect their favorite pose sets and put them in their favorite furniture.

Please post this at

/54/48/270890/1.html

Lear, using the engine prim method works for me also for round beds - basically the slame method as your bed cover to float over any bed. its better for me because different bed styles that i make require different style mattresses.

on another note, today im up to 75 paired anims [including defaults] now with no crashes and still 1526 bytes memory spare. i have renamed all modifiable anims with a short coded name ie, if u created a 'rub hands together' anim i would rename it LJCRH1 - i understand that saves bytes. will post here at what point engine explodes )

Just right click on ~ball in MLP prim's inventory, set its description to "sit".

With MLPV2.1, you can set it to "none" and there will be no hovertext at all.

If this doesn't work for you, please post in the MLPV2 questions thread in scripting tips forum, link above.

My point is that for compatibility, an engine in the middle of the mattress is no different than using the mattress itself, other than the Z offset. The prim size or type doesn't matter, only its position and orientation.

Of course, the z offset is another complication. However, that's a pretty simple adjustment the user can do for each pose, or they can live with a bit of discrepancy.

I make animations, but not furniture and my building knowledge is sketchy.

However, if I ever do sell my animations, I would like to make animations that are as compatible with anyone's furniture as possible. Something that an end-user can easily drop into their favorite furniture, wherever they bought it.

Modularity is a great feature that really helps consumers (who don't need to buy animations they don't need) and merchants (who don't have to worry about making "complete" products). To me personally, the modularity feature is the single best upgrade between MLP 1.2 and MLPV2.

However, to really get the benefits of modularity, there do need to be some standards for animating and building that increases the possibility of compatibility along different products.

Figuring out the best way to orient my animations is a problem because I have trouble anticipating how they will work with specific furniture. (And actually, the original post to this thread at least educates me a little about how the orientations work. That helps.)

My understanding of the standards that Lear is suggesting is not that they would be something enforced in the code, or even made a code "default." It would just be a set of voluntary standards that builders and animators could follow to assure the best chances of compatibility.

At a minimum, with standards, we could at least anticipate what kinds of products with which our products would be useful.

So, if I sell my animations, I can put in the product description that they work best in a certain kind of furniture. Product descriptions for furniture could state that they take additional animations that work with a particular kind of orientation.

I would like to see those standards developed. They don't have to be perfect or cover every situation; they just have to make compatibility between products an easier task.

My main concern is how do I make animations that have the best chances of compatibility with the broadest range of others' furniture.

I'm not sure that my building and LSL knowledge allow me to meaninfully suggest what the standards would be. However, if there just were a set of standards that a group of content creators were using, I could adjust my animations accordingly.

Also, developing standards does not have to be exclusive of developing a script-based way to change animation orientation. There can be both. Changing animation orientation is one of those features that I continually wish existed. I have a lot of uses for that, beyond compatibility concerns.

Scripting in a way to easily change animation orientation would get my vote as the single best next feature to add. But waiting for that does not mean that we can't, in the meantime, also develop some compatibility standards. I think standards would continue to be useful even after scripting in animation-orientation change.

Thanks Amity, I see you get the picture

For MLP and other menu-driven furniture, you really don't have to do anything special when making animations, other than to make sure the hip height is low enough, so that when it's used with a poseball with the minimal sit-target offset, the ball isn't below the surface of the furniture (mattress or cushion). That way, people can select the pose and find the poseballs. (When they do go below the surface, most folks know you can simply select a different pose, sit, and then change poses. But best to avoid the need.)

Generally, this is easy to do, just reduce the hip height from the standard. I use Qavimator, where the default height is about 41 (41 what, I'm not sure). Cutting that in half works well for menu-based animations. Other than that, the animator doesn't need to do anything special.

However, the animator might want to create the MLP configuration files (.MENUITEMS* and .POSITIONS* files) that orient the animations into "poses". (Note: the word "pose" is also used to mean "static animation", but here I essentially mean a "scene" -- what you get when you click a pose button in menu-based furniture.) The animator can then sell pose sets for use in the furniture of others. (They can also easily sell an "engine" prim containing the poses, that people can add to their own beds. For example, I sell an invisible bed cover that can be used to turn most any bed into a sex bed. Modules are better for people who want to combine pose sets from different makers.)

The animator can only go so far with this, because if the poses are generic, they can't take advantage of any details of the furniture. Still, I feel there is a market for relatively generic pose sets. Of course, there will always still be a market for pose sets that are carefully tailored to a specific piece of furniture.

BTW, for sit animations, you want the height to match the built-in sit animation. I'm not sure what that is, but if you do, your sits will be usable in AOs, as well as in more furniture without mods than otherwise. That's beside the point for MLP-like menu furniture, where the poseball gets moved by the scripts.

I don't think anyone has replied to you yet about this one.. Open your MLP object and drag ~ball onto the floor. Edit as a normal object, editing 'love' to your desired text. 'Take' it back into your inventory, then re-drag into your MLP object =) Other features can be added as well. I haven't found any issues yet by editing the ball.

.. As for the original topic, I've also considered making a more 'standard' MLP object.. So far it's worked wonderfully! I've made it a very small flat 'box' and placed it near the top of my objects. Positions hardly need to be adjusted now and it's wonderful! I don't have any 'on the edge' animations though so I'm not too sure about all that.

I may be thinking of something else, but I'm not overly sure what a 'pose pack' is? I've seen it in the instructions and such, but not too sure how that would work out since you still need to edit in the .positions and .menuitems.. Is it just pasting a bunch of poses/animations into the object? Pardon if I've missed something.. I do tend to skip things sometimes =x It annoys me, lol.

For a pose pack you don't edit .positions or .menuitems. Your create new files and add a suffix to the end of them for example .postions.myposes and .menuitems.myposes and you put the menus/positions information in them.

The user will then just have to drag and drop your animations and the .postions.xxx and .menuitems.xxx files into their MLP2 object and they will be set up for them. This is where making some standards comes in so it will work with most/all MPL2 powered objects

I tried to make the menu in Japanese.. and i get an error.
does anyone know a way to make the menu work with japanese buttons?
thanks muchly in advance.

Please post generic MLPV2 questions & bug reports on this thread:

/54/48/270890/1.html

and tell us on that thread exactly what error you get, and whether the error shows a script error popup (a picture of a page hovering over the object).