Problem with a countdown timer

Not sure how to approach this, but i scripted a countdown timer and then found out that the llSetTimerEvent isnt the most accurate thing in the world! Im getting quite a bit of time loss with this script especially through sim crossings, and was wondering if there wasnt a better way!

this is what i have now:

You need to put a space after the leading "<" of any "< vectors or rotations >" in your code.

It's some dumb-ass exploit protection code.

ahhh ok


/////Display Variables/////
string display;

/////Timer Variables/////
integer startlineTime;
float startTime;


default
{
state_entry()
{
llListenRemove(startlineTime);
startlineTime = llListen(-8001, "", NULL_KEY, "";
channel0 = llListen(0, "", NULL_KEY, "";
llSetTimerEvent(1.0);
}

listen( integer channel, string name, key id, string message )
{
if (channel == -8001)
{
integer getTime = llGetUnixTime();
string subString = llGetSubString(message, 6, -1);
startlineTime = (integer)subString;
startTime = ((integer)getTime - (integer)startlineTime);
}
}

timer()
{
/////Starting Line Timer/////
float x = 1.0;
startTime = (startTime + x++);
if (startTime > 0)
{
startTime = 0;
}

/////Update HUD Display/////
display = "Start Timer: " + llGetSubString((string)startTime, 0, - + " \n";
llSetText(display, < 1,0,0>, 1);
}
}

Solved

Wait! Hell no! You can not dangle the prospect of us helping you to solve a problem and then yank it out of our grasp! Especially on a Friday night when it is usually slim pickings here in the Scripting Forum. Please, please hurry up and break something else or come up with another unsolvable problem and drop us a crumb or two

Welcome to Scripting Tips Tim. Hope to see more from you here.

Oh? So THAT's how you use llListenRemove. Dang. Why have I always missed ASSIGNING listens to a variable? Furthermore "Why does llListen work without being assigned?"

Handles are returned and given integer values in the order in which llListens are opened, starting with 1. If you don't give them names, though, you get odd results. Can anyone explain why the following script .....

default
{
    state_entry()
    {
        integer handle = llListen(0,"","","");
        integer handle2 = llListen(1,"","","");
        llSay(0, (string)handle);
        llSay(0, (string)handle2);
        llListenRemove(handle);
        llListenRemove(handle2);
    }

    touch_start(integer total_number)
    {
        llSay(0, "You touched me! " +(string)llListen(0,"","","") + " " + (string)llListen(1,"","",""));
    }
}

..... produces the following results?

[7:40] Object: 1
[7:40] Object: 2
[7:40] Object: You touched me! 4 3

Why doesn't touching the object report handle 3 first? And why aren't they 1 and 2? I removed the handles in start_entry already. Or does it still remember dead handles?

Because the order of evaluation of expressions is not what you think it is, and no, it doesn't re-use dead handles.

To expand on the first part:

Originally LSL did not specify the order of evaluation, but Strife performed experiments and determined that the order of evaluation was right to left. He created some hacks that depended on this, and many people copied them. When I was reading the viewer code I noticed that the Mono compiler (which was then included in the viewer) evaluated code from left to right (as expected). For code without side effects the results are the same, but this would break code that depended on the order of evaluation of side effects.

I let LL know and they modified the Mono compiler to change the order of evaluation (and generate slightly more code as a result... the natural order of evaluation for the mono virtual machine meant they had to throw in some extra "swap" operations).

So now that's effectively part of the spec.

I think I would have preferred they reverted to forward order on the mono change-up... seeeing as how at that point they could have saved grief since there was no extra overhead for scripts already in the system as mono... now we're pretty much stuck with it. (and the inconsistent forward ordered function variable execution)

I think they should have simply said "order of evaluation is undefined" in the original spec. And anyone using Strife's hack would have had demons flying out of their nose.

I was just thinking of it from the perspective of it not breaking existing scripts... adding code and time to the execution to mimic a behavior that was counter-intuitive to begin with just seems wrong to me (not that it's a first)

OK, so now I understand about the order of things. I still don't understand why that little test script I posted (#7) returns 3 and 4 for the handles that are opened in the touch_start event. I removed the ones in start_entry (1 and 2), so why doesn't the numbering start over again instead of continuing with 3? When a handle is removed, why isn't the pointer to it also removed?

Heap?
If you reset the script then it reports 1 & 2 in state_entry again.

Because the guy who implemented llListen chose not to re-use IDs. There's good arguments both ways.

Oh. OK. So there's yet another good argument for assigning names to llListen handles instead of trying to keep track of their integer values. That was Zed's question originally. Thanks, Argent.