llSetScale/PRIM_SIZE... A soda can full of fail

Okay.. I really need help. I'm at my wits end here.

I made a soda-can... and the idea is, the wearer sips it a few times, then crushes it and drops the can. The mechanism I use is as follows: if the can is worn.. it becomes the animated "new" can. it has a clean sculpt, and the wearer holds it. it gets animation permissions and all that, and then goes through it's cycle. When it reaches the last sip, it rezzes a copy of the can.

If the can was rezzed (spawned) it gets a startparam (999).. So, when a new can is rezzed, with 999 it changes itself to the crushed sculpt, and behaves differently (setting itself temp and physical and all that.

Thing is.. it works. it works great. BUT... the SCULPTS are slightly different sizes. <.15,.15,.16> and <.096,.09,.16> But for WHAT EVER REASON, the llSetScale isn't working. Now, I've tried ganging it into the llSetPrimitiveParams, and was even (needlessly) using llSetLinkPrimitiveParams on prim 1.. and regardless of whether it's llSetScale or PRIM_SIZE.. the can just isn't scaling.

Now, either the can is in it's crushed size, or in it's new size.. and it seems relatively random which one it's going to choose.

I seriously need an answer to this. I've torn the concept script apart 3 times now, and written it 3 different ways, always with the same results.

key soundOpen = "";
key soundSip = "";
key soundBurp = "";
key soundCrush = "";
key soundDrop = "";

key newCanSculpt = "";
key oldCanSculpt = "";

integer sips;

list canNew = [     PRIM_PHYSICS
                ,   FALSE
                ,   PRIM_TEMP_ON_REZ
                ,   FALSE
                ,   PRIM_TYPE
                ,   PRIM_TYPE_SCULPT  
                ,   newCanSculpt
                ,   PRIM_SCULPT_TYPE_SPHERE
                ];
                
list canOld = [     PRIM_PHYSICS
                ,   TRUE
                ,   PRIM_TEMP_ON_REZ
                ,   TRUE
                ,   PRIM_TYPE
                ,   PRIM_TYPE_SCULPT  
                ,   oldCanSculpt
                ,   PRIM_SCULPT_TYPE_SPHERE
                ];

worn()
{
    llSetScale(<0.150, 0.150, 0.160>);
    llSetPrimitiveParams(canNew);
    llSetLinkAlpha(LINK_SET, 1, ALL_SIDES);
    sips = 0;
    llSetTimerEvent(2);
}

discarded()
{
    llSetScale(<0.096, 0.090, 0.160>);
    llSetPrimitiveParams(canOld);
    llSetLinkAlpha(LINK_SET, 1, ALL_SIDES);
}

onground()
{
    llSetTimerEvent(0);
    llSetLinkAlpha(LINK_SET, 1, ALL_SIDES);
}

sip()
{
    llSetTimerEvent(7 + llFrand(10));
    sips += 1;
    if (sips == 6)
    {
        llSetTimerEvent(0);
        llRezObject("Pepsi Can", llGetPos() + <0.5,0.0,0.5>, ZERO_VECTOR, llGetRot(), 999);
        llSetLinkAlpha(LINK_SET, 0, ALL_SIDES);
    }
}

default
{
    state_entry()
    {
        onground();
    }
    
    attach(key attached)
    {
        if(attached != NULL_KEY) // worn
        {
            llRequestPermissions(attached, PERMISSION_TRIGGER_ANIMATION | PERMISSION_ATTACH);
        }
        else // dropped
        {
            onground();
        }
    }
    
    on_rez(integer startparam)
    {
        if (startparam == 0) // rezzed on ground
        {
            onground();
        }
        else // dropped
        {
            discarded();
        }
    }
    
    run_time_permissions(integer permissions)
    {
        if (permissions & PERMISSION_TRIGGER_ANIMATION)
        {
            worn();
        }
    }
    
    timer()
    {
        sip();
    }
    
    object_rez(key child)
    {
        llGiveInventory(child,llKey2Name(child));
        llDetachFromAvatar();
    }
}

NOw, let me be clear.. it seems to work the first go round.. at least in my test here.. but then watch this. Take the discarded can, and wear that, and you'll see the problem

I think you may be running into the limitation that scaling functions fail silently on calls asking for dimensions smaller than 0.1m.

Why is the second can rezzed?

WHY WOULD THAT HAPPEN? since the minimum dimensions are 0.01m?

I will blame my stupidity on a lack of sleep, and proceed to go cry now.

Well, I think I know why it's not resizing... but all I've come up with is another problem.

You can't resize a physical object.



"Physical prims cannot change their scale, as that would change their mass as well."

So... I tried this:

worn()
{
llSetPrimitiveParams(canNew);
llSetScale(<0.150, 0.150, 0.160>;
llSetLinkAlpha(LINK_SET, 1, ALL_SIDES);
sips = 0;
llSetTimerEvent(2);
}

...doesn't work

This:

worn()
{
llSetPrimitiveParams(canNew);
llSetstatus(STATUS_PHYSICS, FALSE);
llSetScale(<0.150, 0.150, 0.160>;
llSetLinkAlpha(LINK_SET, 1, ALL_SIDES);
sips = 0;
llSetTimerEvent(2);
}

...doesn't work.

Debugging the physics status shows that it never becomes false.

So I think the problem isn't with the llSetScale but with turning the physics off.

That's as far as I got and I'm left with the question: can the physics of an attached object be changed?

Well according to..



So it would SEEM to be possible to turn physical status ON on an attachment. I dunno about OFF.

This line of thinking has me considering a slightly different approach to the project now. I'll see what I come up with in a bit here.

why not start with no physical, and chnage the discarded version to physical after changing it's shape and being detactched? I know that changes to a scupltmap will unseat an av, perhaps it's related to that.

Once again, the problem asserts itself when you "take a copy" of the discarded can.

so don't take a copy... ?

A little test script:

integer Toggle;

default
{
state_entry()
{
llSetStatus(STATUS_PHYSICS, FALSE);
llOwnerSay("Toggle:" + (string)Toggle + " Status:" + (string)llGetStatus(STATUS_PHYSICS));
}

on_rez(integer start_parm)
{
llOwnerSay("Toggle:" + (string)Toggle + " Status:" + (string)llGetStatus(STATUS_PHYSICS));
}

touch_start(integer total_number)
{
llSetStatus(STATUS_PHYSICS, Toggle = !Toggle);
llOwnerSay("Toggle:" + (string)Toggle + " Status:" + (string)llGetStatus(STATUS_PHYSICS));
}
}

This is what I observe:

The Physics status of an attached object is always TRUE (inherited from the Avatar?).
Changing the physics of an attached object is ignored.

However, the attached object retains its Physics status from when it was attached to when it is detached. If an object is physical when attached, it's physical when detached and visa-versa.

That's not appropriate to the task at hand.

I think the sad and frustrating fact, is that I am going to have to "time out" the dropped can, and make it set itself to non-phys after the drop is complete. Or else I will have to simply rez the dropped can nonphys, at ground level.. or worst of all, generate a "droppable" can that when touched will somehow have a full can (with a dropcan also) to pass to the clicker. Unfortunately self-replication requires the child to be rezzed inworld.

hehehe soda can full of fail....I LOL'd!

got nothing usefull to contribute, but thanks for making me giggle