Heartbeat Scripting Issues (Sculpty Version)

After failing to meet Valentine's Day deadlines last year, I am inspired to finish again this year with a revised sculpty version of my anime heart eyes (I almost forgot!). However, I'm having some trouble again.

I had a parent-child script set for my old hearts, but I realised that it's possible to use two nearly identical independent scripts (one for each heart). However, I've yet to determine a way to use the independent script method to synchronise the sculpt maps changes with the resizing.

My objectives:

* To allow a user to activate and deactivate a pair of hearts on command without much lag.
* To synchronise sculpt map changes with resizing.

My current problems with the parent-child script method:

* A sphere appears (balling effect?) prior to the heart sculpt maps.
* Resizing starts unsynchronous with the sculpt map but they synchronise after a few seconds (and stay synchronised).

I will post my scripts in successive replies.

//Establish the global variables
integer frameset = 1;
integer beating = 0;
integer visible = 1;
Resize(float scale)
{
integer num_prims = llGetNumberOfPrims();
integer i;

for (i = 1; i <= num_prims; i++)
{
llMessageLinked(i, 0, (string)scale, NULL_KEY);
}
}
initialise()
{
llInstantMessage(llGetOwner(), "Love at First Sight script by Peach loaded. Type '/9

pulsate' to animate, '/9 rest' to pause animation, and '/9 vanish' to turn off.";
llListen(9, "", llGetOwner(), "";
}
default
{
state_entry()
{
initialise();
}
attach(key love)
{
if (love)
{
initialise();
}
}
timer()
{
float scale;
if (frameset == 1)
{
frameset = 2;
scale = 1.25;
Resize(scale);
}
else if (frameset == 2)
{
frameset = 1;
scale = 0.8;
Resize(scale);
}
}
listen(integer channel, string name, key id, string message) {
float scale;
if (message == "pulsate"
{
if (beating)
{
llInstantMessage(llGetOwner(),"Already beating.";
}
else
{
llSetTimerEvent(0.5);
llSetLinkAlpha(LINK_SET,1,ALL_SIDES);
beating = 1;
visible = 1;
llInstantMessage(llGetOwner(),"Doki doki...";
}
}
else if (message == "rest"
{
if (!beating && visible)
{
llInstantMessage(llGetOwner(), "Already resting.";
}
else if (!beating && !visible)
{
llSetLinkAlpha(LINK_SET,1,ALL_SIDES);
visible = 1;
llInstantMessage(llGetOwner(), "Ai mode initiated.";
}
else
{
llSetTimerEvent(0);
if (frameset == 2)
{
scale = 0.8;
Resize(scale);
frameset = 1;
}
beating = 0;
llInstantMessage(llGetOwner(),"Stabilized.";
}
}
else if (message == "vanish"
{
if (!visible)
{
llInstantMessage(llGetOwner(), "Already invisible.";
}
else
{
llSetTimerEvent(0);
if (frameset == 2)
{
scale = 0.8;
Resize(scale);
frameset = 1;
}
llSetLinkAlpha(LINK_SET,0,ALL_SIDES);
visible = 0;
beating = 0;
llInstantMessage(llGetOwner(),"Ai mode terminated.";
}
}
}
}

default {
link_message(integer sender_num, integer num, string str, key id) {
float scale; // size factor
list primparams;

scale = (float)str;

primparams = [];

primparams += [PRIM_SIZE, llGetScale() * scale]; // resize

// if (llGetLinkNumber() > 1) { // only move if we're not the root object
// primparams += [PRIM_POSITION, llGetLocalPos() * scale]; // reposition
// }

llSetPrimitiveParams(primparams);
}
}

default {
link_message(integer sender_num, integer num, string str, key id) {
float scale; // size factor

scale = (float)str;

if (scale == 0. { // heart is shrinking
llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_SCULPT, "UUID ASSET TRANSITIONAL HEART CENSORED", PRIM_SCULPT_TYPE_SPHERE]);
llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_SCULPT, "UUID ASSET DEFLATED HEART CENSORED", PRIM_SCULPT_TYPE_SPHERE]); // deflate
}
else if (scale == 1.25) { // heart is growing
llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_SCULPT, "UUID ASSET TRANSITIONAL HEART CENSORED", PRIM_SCULPT_TYPE_SPHERE]);
llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_SCULPT, "UUID ASSET INFLATED HEART CENSORED, PRIM_SCULPT_TYPE_SPHERE]); // inflate
}
}
}

By the way, I am very willing to show a demonstration of my anime heart eyes inworld (preferably Beta Havoc) to show the problems that occur and provide a better picture of how I want the accessory to function. Thank you in advance.

What you describe isn't a scripting issue per se. Sculpt maps are textures, so the balling and unsyncronzied behavior is what one routinely sees in SL with rezzing of textures. You need to find a way to pre-rez the texture. One way would be to have an alphaed prim with the sculpt maps set as their texture (not their sculpt map), perhaps as an additional child prim. This is so that clients start downloading the sculpt map before it's ever used. It's not 100% foolproof, but should certainly help.

Ah, that's a good idea to eliminate the balling effect. Thank you. However, the lack of synchronousity happens every time I activate the accessory, even when all textures are rezzed. Synchronization takes approximately ten cycles, consistently.

Also, there exists a significant lag time (2-3 seconds) for activation from a rested state. However, returning to a rested state with a user command takes only half a second. (I suppose this is because the number of lines the script must navigate through just to initiate activity is fairly higher than to disable by shutting off the timer....)

I really would love to show you how this is reacting.

Oh I see a possible reason. You are sending a linked message to each child prim individually. So there will be sync problems. Instead just send one link message to ALL prims, and have each child prim look for that message. That way they should all receive the message nearly simultaneously.

Change Resize function to:

Resize(float scale)
{
llMessageLinked(LINK_SET, 0, (string)scale, NULL_KEY);

}

Unfortunately, that is actually less synchronous, but in a different way. This time, the hearts are not in synch with each other; they're off by about 0.2 seconds. The initial ten cycles still lack synchronousity between the sculpt map changes and resizing. T.T

Well, good news. I fixed the script! The problem was that llInstantMessage needed to be placed BEFORE the llSetTimerEvent code in the following excerpt:

else
{
llSetTimerEvent(0.5);
llSetLinkAlpha(LINK_SET,1,ALL_SIDES);
beating = 1;
visible = 1;
llInstantMessage(llGetOwner(),"Doki doki...";
}

Now I just need to see if I can cut down on code or "relays" to reduce lag....

Interesting. I guess the 2 second built in delay in llInstantMessage had an effect. I wouldn't have guessed that. Glad you got it going.

Thanks... Although, the main grid seems to be flipping out today. I tested yesterday on the main grid and my script seemed fine. Now it's going crazy and the effects are even worse when the hearts are attached to an avatar. In the beta grid, there is no problem, and attachment is a nonfactor. I'm told this may be in part due to how the beta grid is on Havok4, while the main grid is still on Havok1. Correct me if I'm wrong....

There are a few private estate sims in the Main Grid that are running Havok 4. I believe the number of sims in the Beta Grid that are on Havok 4 is also limited, though it may be a larger number. The Mono sandboxes I have been to in the Beta Grid are not on Havok 4 (in fact they are still on 1.18 code). You can see if your current sim is running Havok 4 by going to Help -> About Second Life.... I believe the fourth line down (the one with the server version in it anyway) will have Havok 4 in it if so.

Ah, thank you! Well, I slowed down the timer event from 0.5 to 1.0 and there's more stability now. I suppose lag and/or server congestion is a major factor in this situation. Naturally, beta is empty. However, after testing in a Havok4 area on the main grid, I noticed the server version does matter. I will have to make sacrifices for the old server, for now....

Yeah. I'm hoping the use of llSetLinkPrimitiveParams() on avatars remains as it currently is in Havok 4, so my teleporter, conference table, and sport animation systems continue working and gradually get phased into working all over the grid....

/54/20/239110/1.html

You have a cool script there, Hewee-san. Have you considered alternative code for Havok1?

I'm considering adding a rate variable to my code to allow users to choose "heart rate." This way, the anime heart eyes would not become so easily outdated by server upgrades across the main grid. The default rate, of course, would be a lowest because of the very abundant Havok1.