Jump to content

Mesh Body Parts Standard (MBPS)

Felicia Silversmith

By Felicia Silversmith,
in Mesh

 Share
You are about to reply to a thread that has been inactive for 3643 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Felicia Silversmith

Felicia Silversmith

Posted
Posted

        ======================================
        MESH BODY PART APPLIER STANDARD (MBPS)
        ======================================

Currently most creators of mesh body parts using own texture applying technique, channels and message format for applying textures to their creations. As a result appliers wich work for parts from one creator doesn't work with others. Clothes and skins creators have to do a lot of work to make their creations compatible with different versions of body parts. Mesh body parts for sure is a future of SL and with time more creators will start to make mesh body parts. To avoid mess with appliers we introduce this standard wich allow make body parts and clothes compatible without  described common techinque for texture applying to be used in future versions of body parts and clothes for them.
This version of standard suppose that applyers using SL compatible UV mapping.


FOR MESH BODY PARTS CREATORS
============================

All you need to make your creation MBPS compatible is it put script and configuration note to your creation. In note you setup to wich face of object each body part related. Each line have following format:

    part name = face number
    
Supported body parts listed in clothes creators section. If body part have more then 1 primitives MBPS script and configuration note should be placed in each of them.

How script works:
Script using similar technique as most appliers. Numbers define wich face of mesh will be used for applying listed body part.

Example of configuration note:
    legs = 0 // skin layer
    underpants = 1
    pants = 2

Note:
• Texture offset, scale and rotation should be set manually (using Edit tool) by body part creator.
• Number of channel for listening based on mesh part owner avatar key. Technique of channel number calculating will not be published anywhere to avoid stealing of textures UUIDs.  

FOR CLOTHES & SKINS CREATORS
============================
To setup MBPS applyer you should edit note included in applyer.
Configuration note for applier have following format:
    
    option = value
    
Emtpy lines are ignored. Any characters following // are ignored until end of string.

Note can have have following parameters:

    part = <body part name>
    texture = <texture key>
    color = <RGB 0-255 vector>
    alpha = <float>

Body parts is only required parameter. Other parameters are optional.
Here is list of currently supported parts:

    Mesh heads:
    ===========
    • head
    • headtatoo
    • hairbase
    
    Mesh upper body:
    ===============
    • torso
    • torsotatoo
    • undershirt
    • shirt
    • jacket
    
    Breast implants:
    ==============
    • breast
    • breasttatoo
    • bra
    • top
    
    Mesh hands:
    ===========
    • hands
    • handstattoo
    • gloves
    
    Mesh lower body:
    ===============
    • legs
    • legstatoo
    • underpants
    • pants
    
    Mesh feet:
    =========
    • feet
    • feettatoo
    • socks
    
Example of applier configuration note:
    part = top
    texture = 89556747-24cb-43ed-920b-47caed15465f
    color = 224, 224, 224
    alpha = 1

Any suggestoions about standard are welcomed. You can recieve scripts inworld by contacting me. Later i going to place MBPS scripts at market and free vendor inworld.
    
With best regards, Felicia Silversmith

   

Link to comment
Share on other sites
Felicia Silversmith

Felicia Silversmith

Posted
  • Author
Posted

Scipts are available in COPY/TRANSFER versoin. They are NO MOD to hide listened channel number calculation algotythm.

2 Sassy: A lot of clothes and skins creators interested in existing some standard. Now they have to make a lot of appliers for each creator. After making this standard work amount of needed appliers will be decreased.

 

Link to comment
Share on other sites
Sassy Romano

Sassy Romano

Posted
Posted

Obfuscation of the channel was exactly my concern but playing devil's advocate, what is to prevent a script that cannot be inspected from farming the UUID of every texture four malicious intent?

 

The answer of course is "trust" and nothing else.

 

I understand the initiative but given that one of the most popular appliers and thus all its clones already send the UUID in clear text on an easy to find channel, plus that the UUID of every texture downloaded is already in local cache, the cat is rather out of the bag.

 

Rather than trying to obfuscate the channel, it may be better to implement an encryption method such that the script and algorithm can be open to evaluation. The derivation of the required key would provide the security.

Link to comment
Share on other sites
Felicia Silversmith

Felicia Silversmith

Posted
  • Author
Posted

There is way to make implementation of channel calculating separately, but i guess it will be just headake with llMessageLinked processing. I am going publish MBPS sripts itself (except channel calculation part) so creators can deside themself to trust MBPS scripts or not. Here is script for mesh body parts:

 

list faces;
list params;
string note = "MBPS Body Part Setup";
integer line;
key query;
integer value;
string str;

integer getChannel()
{
    [ HIDDEN ]
}

load()
{
    faces = [];
    line = 0;
    if( llGetInventoryType( note ) != INVENTORY_NOTECARD ){
        llOwnerSay( "ERROR! Notecard \"" + note + "\" not found." );
        return;
    }
    query = llGetNotecardLine( note, line );
}


process( string data )
{
    value = llSubStringIndex( data, "//" );
    if( value != -1 ) data = llGetSubString( data, 0, value - 1 );
    data = llStringTrim( data, STRING_TRIM );
    if( data == "" ) return;
    params = llParseString2List( data, [ "=" ], []);
    if( llGetListLength( params ) != 2 ){
        llOwnerSay( "ERROR! Incorrect parameters count in config note: " + data );
        return;    
    }
    str = llStringTrim( llList2String( params, 1 ), STRING_TRIM );
    value = (integer) str;
    if(( string ) value != str ){
        llOwnerSay( "ERROR! Incorrect face number in config note: " + data );
        return;    
    }
    faces += llStringTrim( llToLower( llList2String( params, 0 )), STRING_TRIM );
    faces += value;
}

default
{
    state_entry()
    {
        load();
        llListen( getChannel(), "", NULL_KEY, "" );
    }
    
    attach( key id )
    {
        if( id != NULL_KEY ) llListen( getChannel(), "", NULL_KEY, "" );
    }
    
    on_rez( integer param )
    {
        llListen( getChannel(), "", NULL_KEY, "" );
    }

    changed( integer ch )
    {
        if( ch & CHANGED_INVENTORY ) load();
    }
    
    dataserver( key id, string data )
    {
        if( id != query ) return;
        if( data == EOF ){
            query = NULL_KEY;
            return;
        }
        process( " " + data );
        query = llGetNotecardLine( note, ++ line );
    }
    
    listen( integer ch, string name, key id, string msg )
    {
        if( query != NULL_KEY ) return;
        if( llGetOwner() != llGetOwnerKey( id )) return;
        params = llParseString2List( msg, [ "|" ], []);
        if( llList2String( params, 0 ) != "MBPS" ) return;
        value = llListFindList( faces, [ llList2String( params, 1 )]);
        if( value == -1 ) return;
        value = llList2Integer( faces, value + 1 );
        if( llList2String( params, 2 ) != "" )
            llSetTexture( llList2String( params, 2 ), value );
        if( llList2String( params, 3 ) != "" )
            llSetAlpha(( float ) llList2String( params, 3 ), value );        
        if( llList2String( params, 4 ) != "" )
            llSetColor(( vector ) llList2String( params, 4 ), value );        
    }
}

Appler source code will be publised after beta-testing. And yes, suggestion about message crypting is really good and will be implemented also.

Link to comment
Share on other sites
Sassy Romano

Sassy Romano

Posted
Posted

Felicia Silversmith wrote:

 

Appler source code will be publised after beta-testing. And yes, suggestion about message crypting is really good and will be implemented also.

The problem here is that the source can't be verified against a compiled no mod script.

Concentrate on the above key derivation to an established algorithm such that the whole script can be published, then the channel does not need to be obfuscated.

Link to comment
Share on other sites
Yabusaka Loon

Yabusaka Loon

Posted
Posted

As long as you use notecards for the configuration, your UUID will never be safe.

I'm not sure if the creator of Tango or other creator is realized it but reading no MOD notecards is very very easy thing.

Also, using random channel doesn't really help, since there is a script called "multi channel listner" which allows one to listen hundreds of channels at a time.

 

 

 

Link to comment
Share on other sites
Pussycat Catnap

Pussycat Catnap

Posted
Posted

Everyone already has the UUID of every single texture they encounter in SL anyway...

Going to great lengths to hide it in a script is pointless.

Anyone who can understand the code if you were to reveal it, and see what channel, reasonably already knows where the UUIDs are already available for everything.

 

Link to comment
Share on other sites
Felicia Silversmith

Felicia Silversmith

Posted
  • Author
Posted

May be i got you wrong. But crypting code is not going be published. Of course there are another ways to get texture UUIDs without scripts (i dont think its good idea to publish detailed info about it here). Without knowing of channel number calculating and UUID crypting algorithms its not easy at all to get real UUID by scripted hacking tools. That is a main reason why MBPS scripts are NO MOD - to hide these algorythms and avoid hacking. And besides goal of standard is not only to secure texture UUIDs. First of all standard was created as common technique wich allow to create appliers for body parts from different creators. And wich allow any body part creator to make their products MBPS compatible.

 

MBPS LAST UPDATES:

1. Some body parts added to standard:

  • handnails
  • feetnails
  • nipples

2. Specifications changes: Textures for breast implants supposed to use Lolas compatible UV mapping ( left upper 1/4 of standard SL upper body texture). If body part have different UV mapping that defined in MBPS standard it is reccomended to use custom body parts names to avoid mess with UV mapping.

3. For better compatibility with existing appliers 3 parameters added:

  • texture repeats
  • texture offset
  • texture rotation

4. It possible now to create custom MBPS compatible appliers. Code for communication between applers and mesh body parts moved to separate script. Scipt processing now linked message with code 0x40000, encoding textire UUID if message have some and sending message to mesh body part. Message format to be sended to script:

   part name | alpha value | color vector | repeats | offset | rotation

Part name is only required parameter, others are optional. For example operator

   llMessageLinked(
       LINK_SET,
      0x40000,
      "underpants||<1,1,1>",
      "89556747-24cb-43ed-920b-47caed15465f" );

will set underpants texture and color without changing alpha, texture repeats, offset and rotation. Texture UUID will be crypted before sending it to body part.

 5. Existing formats support added
A lot of clothes creators have tonns of appliers already. So support of existing popular applier configuration formats was added:

  • Lolas Tango, Lolas Mirage, Lush, Boop breast implants
  • Lucky Inc. Phat Azz mesh bottom
  • Sking Mesh bottom

 

 

 

 

Link to comment
Share on other sites
Yabusaka Loon

Yabusaka Loon

Posted
Posted

I couldn't really get no.4 but I assume you quited using notecard for setting UUID and decided to use llMessageLinked script instead?

llMessageLinked is another thing which is easy to listen-in... but I guess it doesn't really matter since most of current appliers also have security hole anyways?

 

Link to comment
Share on other sites
Felicia Silversmith

Felicia Silversmith

Posted
  • Author
Posted

Notecards still going to be main engine of textures applying. Developer Kit contains ready to use MBPS compatible applyer temaplate wich clothes and skins creators have to just configure to use with their creations. llMessageLinked was added as extention to make possible creation of custom MBPS compatible appliers. It is optional functionality. In common way creators will just configure ready applier with notecard as they doing now with other appliers.

About security holes...

IMPORTANT INFO FOR SKIN & CLOTHES CREATORS

Default MBPS applier have 2 prims. Scripts and notecard located in child prim. By default MBPS applier template is full perm to let you setup parameters in notecard. But before sharing applyer creator should make applier NO MOD for next owner. In this case notecard can not be readed somehow by scripted hacking tools and texture UUID can not be stolen. Applier shows warning when you configure it in case you did not made it no mod. So make sure you dont get warning message before selling your appliers.

 

Link to comment
Share on other sites
You are about to reply to a thread that has been inactive for 3643 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share
Go to topic listing
×
×
  • Create New...