Jump to content

is it possible to have 2 timer in a script


NawaliaTrea
 Share

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

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

Recommended Posts

Hi again,

I have another question since i think it never been mentioned in the wiki about this in the timer()section. Is it possible to have 2 timer() in 1 script? i want to put timer for 2 different animation. i am gutting a draw/sling script i found in the wiki adding stuff and modifying some stuff in it. i put 1 animation in the draw command with a llSetTimerEvent timer() to sequence with another anim pose.

 and then i add another animation into the sling command and trying to add timer to sequence it with another pose but i am stuck so far cos the second timer just won't  firing.

so i am wondering if it is even possible to add second timer in 1 script.if not then is there a way for me to do what i meant to do.

Thank you all ;D

 

Link to comment
Share on other sites

Nope. Only one timer per script.

Several possible workarounds, though.

I think for what you want, a global integer flag that you set or reset when you start your animations would do to let you know what's supposed to happen in the timer event.

Also there's the evil cheat of using llSensorRepeat with settings for something that'll never be sensed, and reacting in the no_sensor event.

There are also a few scripts floating around that implement multiple timers, but I think they'd mostly be overkill for what you want.

  • Like 1
Link to comment
Share on other sites

For things like draw and holster animation sequences, I use an integer I can toggle to an on or off state.

Then if the script knows the item is drawn, it slings it, and if it knows it's slung, it draws it.

Also, a way to sequence animations so that they play properly one after the other is to determine how long the first animation is, then use llSleep() to make the script wait that long before doing the next thing, which would be running the second anim.

llSleep puts everything on hold for the specified amount of time, then turns it all back on, but things like sounds, animations, and particle effects still play while the script is sleeping, if they were begun before the llSleep() was used.

This is why you can use it like a timer, provided it isn't crucial for the rest of the script to be doing anything super-important for that 3 seconds or so.

 

So you'd end up with something like this...

llPlayAnimation("reachback");

llSleep(3.5);

llPlayAnimation("drawsword");

Edited by Berksey
We must capitalize the first person singular when typing formally...
  • Like 1
Link to comment
Share on other sites

3 minutes ago, Berksey said:

This is why you can use it like a timer, provided it isn't crucial for the rest of the script to be doing anything super-important for that 3 seconds or so.

"Anything super important" includes sending and receiving messages, handling dataserver requests, sensing touch*/collision*/sensor triggers ....  In effect, llSleep does exactly what it says.  It puts the entire script to sleep for the designated time.  Animations will continue to play because they are client-side functions. Once triggered, they no longer need the script to keep them going.  As a rule, it is wise to avoid using llSleep for more than a second or two unless you are sure that your script will not miss something "super important".  Use a timer instead.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

I agree with Rolig (as I usually do!).    To my mind, people should be very careful about using llSleep unless they are sure they want to shut things down -- e.g. to ensure other things have a chance to happen after the object containing the script has been rezzed.   My general rule of thumb is if I find myself wanting to sleep the script for much more than 0.75 seconds, I should probably use a timer instead.

Anyway, @NawaliaTrea, here's an outline of one way to handle your problem -- multiple animations with different durations.    It's not quite how I would do it in practice but I wrote it this way to make logic clearer (I hope) than otherwise it might be:

float fAnim1Duration = 5.0;//length of time to play strAnim1
float fAnim2Duration = 7.5;//length of time to play strAnim2
float fAnim3Duration = 10.0;//length of time to play strAnim3
float fThisAnimDuration;

integer iCounter;
integer iMax;

list lAnimsAndTimes;

string strAnim1 ="Ready";//name of first anim
string strAnim2 ="Aim";//name of second anim
string strAnim3 ="Fire";//name of third anim

string strThisAnim;
string strOldAnim;
default
{
	state_entry()
	{
		lAnimsAndTimes =
			[
			strAnim1, fAnim1Duration,//Strieded list of animation name and how long animation lasts
			strAnim2, fAnim2Duration,
			strAnim3, fAnim3Duration
			];
		iMax = llGetListLength(lAnimsAndTimes);
	}
	touch_start(integer total_number)
	{
		//start the sequence
		iCounter = 0;//0 the counter
		llSetTimerEvent(0.0);
		llRequestPermissions(llDetectedKey(0),PERMISSION_TRIGGER_ANIMATION);//always request perms in the first instance
	}

	run_time_permissions(integer permissions)
	{
		if(permissions & PERMISSION_TRIGGER_ANIMATION){
			strThisAnim = llList2String(lAnimsAndTimes,iCounter);//get the name of the first animation
			fThisAnimDuration = llList2Float(lAnimsAndTimes,++iCounter);//advance the counter, and get the next item, which is the corresponding time
			llStartAnimation(strThisAnim);
			llOwnerSay("starting to play "+strThisAnim);
			strOldAnim = strThisAnim;
			llSetTimerEvent(fThisAnimDuration);
		}
	}

	timer()
	{
		if(++iCounter < iMax){//advance the counter.  If it's still less than iMax
			strThisAnim = llList2String(lAnimsAndTimes,iCounter);//get the name of the next animation
			fThisAnimDuration = llList2Float(lAnimsAndTimes,++iCounter);//advance the counter, and get the corresponding time
			llStartAnimation(strThisAnim);
			llOwnerSay("starting to play "+strThisAnim);
			llStopAnimation(strOldAnim);//stop the old animtion
			strOldAnim = strThisAnim;
			llSetTimerEvent(fThisAnimDuration);			
		}
		else{
			llOwnerSay("Finished");
			llStopAnimation(strOldAnim);
			llSetTimerEvent(0.0);
			iCounter = 0;
		}
	}
}

Not tested in world,. but it looks right to me.

Edited by Innula Zenovka
  • Like 4
Link to comment
Share on other sites

I was tired. Sorry.

llSleep between two animations in a draw/sling script is just what usually works for me instead of having to refer to a separate timer event when only one timer event can run. I never use timers for the pause between two animations when it's drawing or slinging an attachment, it makes no sense to use up a timer for that, when llSleep was made for it.

And as for "anything super-important", I probably would have done better to say, "anything else at the moment". Sorry.

Edited by Berksey
  • Like 2
Link to comment
Share on other sites

i used llSleep in this script after a suggestion in my previous question. using like 4 llSleep command in 2 different command set ;D so far it worked just fine for me everythn=ing working in order the way i want to ( since i use them to delay sound, and objects alpha to fire to match the movement of the animation)

For the current problem the only thing i know that can do what i want to do is a timer() but as you all said there'sonly 1 timer possible in 1 script. @Rolig Loon said about the no sensor thing with llSensorRepeat , i'm going to try that. and also going to try what @Innula Zenovka suggest since it looked like it can solve the problem i have right now eventho the whole script looks a little too advance for my current scripting skill ;D. also trying what @Berksey suggest about the llsleep betwen 2 animation.so the command like hibernate the 2nd animation when the first 1 fires. hopefully i can get it right...;D will let you all know how it goes since i will have alot more question about this ;D

Link to comment
Share on other sites

44 minutes ago, NawaliaTrea said:

hmmmmmm...okay....i tried the llSensorRepeat like @Rolig Loon suggest, and it worked.. but somehow the 2nd animation just wont stop even i already put a llStopAnimation for it.what do i do wrong ;(

okay...solved with a llSensorRemove ;D but now another problem...after the last anim pose  stopped by the sensorRemove the av went back to the first anim and freeze there lol....eventho i already put a stopanimation for that anim. ;D

Link to comment
Share on other sites

16 hours ago, Rolig Loon said:

"Anything super important" includes sending and receiving messages, handling dataserver requests, sensing touch*/collision*/sensor triggers ....  In effect, llSleep does exactly what it says.  It puts the entire script to sleep for the designated time.  Animations will continue to play because they are client-side functions. Once triggered, they no longer need the script to keep them going.  As a rule, it is wise to avoid using llSleep for more than a second or two unless you are sure that your script will not miss something "super important".  Use a timer instead.

While a script is sleeping, any events that would happen are put into a queue. You don't actually "miss out" on anything, you just won't react immediately anf that's where you should ask "is this super important?"

  • Like 1
Link to comment
Share on other sites

38 minutes ago, Wulfie Reanimator said:

While a script is sleeping, any events that would happen are put into a queue. You don't actually "miss out" on anything, you just won't react immediately anf that's where you should ask "is this super important?"

"Missing" something doesn't necessarily mean missing it forever, true, but delaying it can be just as bad. Signals that are received out of order can set up race conditions that create false or misleading results.  For example, you set a sensor to detect when an avatar is within range, but you add a 5 second llSleep immediately after the sensor is triggered, hoping that it gives you 5 seconds to escape detection.  If the sensor detects you during the sleep period, the response will simply be delayed, not ignored, so your hopes are dashed. The script has failed to do what you wanted.

  • Like 2
Link to comment
Share on other sites

10 hours ago, Berksey said:

I never use timers for the pause between two animations when it's drawing or slinging an attachment, it makes no sense to use up a timer for that, when llSleep was made for it.

Using llSleep to set a pause between two animations might make sense in the particular applications you have written but that does not prevent it from coming back to bite you in other circumstances (e.g. if you find yourself making a HUD that animates the wearer but does a lot of other things too).   Using llSleep as an alternative for a timer is a dangerous habit to get into  -- people quite often contact me for advice because they can't get a script to work properly and I've lost count of the times it's turned out to be because of injudicious use of llSleep.   

1 hour ago, Wulfie Reanimator said:

While a script is sleeping, any events that would happen are put into a queue. You don't actually "miss out" on anything, you just won't react immediately anf that's where you should ask "is this super important?"

No.  I'm sorry, but you're mistaken.   Drop this in a prim, say something on channel 5 to put the script to sleep and then touch the prim several times.   When it wakes up again, you will see it's registered the first touch event but lost the subsequent ones.    As I understand it (though I've not tested it recently) other events behave similarly -- that is,  while the script is sleeping it registers the first event of a particular kind (touch, listen, link message and so on) and ignores the rest.

integer counter;
default
{
    state_entry()
    {
        llListen(5,"",llGetOwner(),"");
    }
    
    listen(integer channel, string name, key id, string mesage){
        llOwnerSay("Going to sleep now");
        counter = 0;
        llSleep(5.0);
        llOwnerSay("Woken up again");   
    }

    touch_start(integer total_number)
    {
        llOwnerSay("touch "+(string)(++counter));
    }
}

This is an example of why llSleep can be dangerous -- it looks so simple but even very experienced scripters are often unaware of the various traps and pitfalls it hides.

Edited by Innula Zenovka
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

Improper use of anything through the misunderstanding of it can be dangerous. And yeah, people have misused things before and others have been less than delighted with the results.

I think I shall now and in the future simply warn people away from even trying to learn any of this, as some mistake might potentially creep in, and somewhere down the road, it could lead to disaster.

The future is scary now that I consider all of this; I mean, some person could read about the legitimate use of a function, and being too new to scripting, completely misunderstand the function, and what the person describing the function is trying to say, and the potential damage caused by imperfect information in the hands of the unlearned is simply too awful to countenance.

I see the awful truth now. New people must be prevented from having any of this knowledge, as they may not be expert in its use, and then any number of awful things could happen.

I will do my part to prevent this miserable future by immediately implementing the only solution I can even consider at this point. I leave it all to the experts, and the safety of the future I shall simply have to trust to them.

@NawaliaTrea will probably want to discard anything I gave her inworld that she's incorrectly assumed (as an unlearned newbie) to be helping her with learning this stuff, as every once in a while the scripts tend to be told to sleep for half a second or so. We all know that using that function is just bad coding practice now, so throw those things away, and learn to use extra code, if it's what these guys recommend.

See, this is what happens when you let someone with only twelve years experience speak on a scripting forum. I propose anyone who isn't at least retired from IT work after 30 years be disallowed from even asking about this stuff, let alone be encouraged to USE any of it.

I'm done overthinking LSL, I'm going to go make fun things now.

Edited by Berksey
Wasn't Perfect Enough for This Forum and the People In It
  • Confused 1
  • Sad 1
Link to comment
Share on other sites

15 minutes ago, Berksey said:

Improper use of anything through the misunderstanding of it can be dangerous. And yeah, people have misused things before and others have been less than delighted with the results.

I think I shall now and in the future simply warn people away from even trying to learn any of this, as some mistake might potentially creep in, and somewhere down the road, it could lead to disaster.

The future is scary now that I consider all of this; I mean, some person could read about the legitimate use of a function, and being too new to scripting, completely misunderstand the function, and what the person describing the function is trying to say, and the potential damage caused by imperfect information in the hands of the unlearned is simply too awful to countenance.

I see the awful truth now. New people must be prevented from having any of this knowledge, as they may not be expert in its use, and then any number of awful things could happen.

I will do my part to prevent this miserable future by immediately implementing the only solution I can even consider at this point. I leave it all to the experts, and the safety of the future I shall simply have to trust to them.

I'm done overthinking LSL, I'm going to go make fun things now.

Awww.... don't back off too fast, Berksey. You have made valuable contributions in this forum. There are few "experts" in this business.  We all learn by bumping our noses into things that don't work the way we expected, and by sharing with each other.  Some of us have just made more mistakes than others, so we've learned more ways to screw up and how to avoid them. 

Innula and I were guided by Void Singer when we started here.  Take a look at her scripts sometime.  They are masterpieces of tight scripting, hard to follow because of her personal notation style but loaded with ways to avoid logical traps.  I was intimidated for quite a while.  It took me a very long time to understand all of the nuances she was explaining to me, especially her advice about watching for race conditions -- still one of my issues. 

The best thing for you -- and any other scripter -- to do is to get out there and make mistakes.  Don't play it safe.  Try things that have a high probability of failure, beat them, and tell the rest of us how you did it. 

  • Like 3
Link to comment
Share on other sites

4 hours ago, Innula Zenovka said:

Using llSleep to set a pause between two animations might make sense in the particular applications you have written but that does not prevent it from coming back to bite you in other circumstances (e.g. if you find yourself making a HUD that animates the wearer but does a lot of other things too).   Using llSleep as an alternative for a timer is a dangerous habit to get into  -- people quite often contact me for advice because they can't get a script to work properly and I've lost count of the times it's turned out to be because of injudicious use of llSleep.   

I think you hurt their feelings!

Link to comment
Share on other sites

1 hour ago, Berksey said:

I think I shall now and in the future simply warn people away from even trying to learn any of this, as some mistake might potentially creep in, and somewhere down the road, it could lead to disaster.

The future is scary now that I consider all of this; I mean, some person could read about the legitimate use of a function, and being too new to scripting, completely misunderstand the function, and what the person describing the function is trying to say, and the potential damage caused by imperfect information in the hands of the unlearned is simply too awful to countenance.

I see the awful truth now. New people must be prevented from having any of this knowledge, as they may not be expert in its use, and then any number of awful things could happen.

Sorry, Berksey, but I think you're missing an important point here.   

I would say that we don't want to get new people into bad habits.   You and I both both know enough about scripting to know when it's safe to use llSleep as a simple alternative to llSleep and when it might it be dangerous.   Beginner scripters don't know that, and if they start using llSleep when they should use a timer, then they'll very rapidly discover their scripts stop working without any obvious reason.    I know that because that's what mine did when I was learning, until someone explained to me where I was going wrong.

That's why I make such a big thing about llSleep() -- because I know that beginner scripters often don't fully understand the implications of using it, and I think it's best to encourage people to develop good scripting habits right from the start.    Yes, we could tell people "You can use llSleep here, but you need to be aware that you shouldn't use it if any of the following circumstances are likely to apply" but to my mind, that's overcomplicating it and I'd rather simply try to help people learn how to do things the safe way.

It's a bit like braces -- yes, experienced scripers know when you need to put them after a condition and when you don't, but rather than complicate life for new scripters by asking them to remember this, I try to encourage them always to use them, even when they're not strictly necessary (as I do myself, so I don't have to remember when it's safe not to use them).

55 minutes ago, Love Zhaoying said:

I think you hurt their feelings!

I had no intention of so doing, and if I have, I hope Berksey will accept my apologies for having caused offence, and also accept my assurances that any offence caused was completely unintentional.   Like Rolig, I very much hope Berksey will reconsider, and will continue to be a valued contributor to the forum.

  • Like 1
Link to comment
Share on other sites

If stating a function's caveats is an over-complication, but using hacks and workarounds instead of that function are not, then it's no wonder people think all of this is beyond them when they're new.

Perhaps that and the way people here can't even be courteous without it revealing itself to be condescension is why some people decide to stop trying to help.

I don't post on any of the forums here because of this. Condescending experts who can't even admit another person is also right without insisting they're wrong, well, that's just the last little bit it takes for me to never want to post here.

I would contribute to this forum, but the popularity contest aspect repels me, and people needing to be right no matter what just makes me want to take up a different hobby or something.

Our feelings are the only things in here that are real. Good thing nobody's feelings matter but the ones with the highest popularity points; having alts is good for more than one thing, I suppose.

Link to comment
Share on other sites

8 minutes ago, PheebyKatz said:

If stating a function's caveats is an over-complication, but using hacks and workarounds instead of that function are not, then it's no wonder people think all of this is beyond them when they're new.

A timer event is hardly a hack or a workaround.  It's the standard workhorse for making things happen when you want them to, basically like the alarm in your smartphone.  Using a llSleep command as a substitute is the workaround -- useful if you only need to stop things for a very short time and don't want to jump out of the current event to do it.  The caveat that Innula and I raised is that the llSleep workaround has many non-obvious disadvantages. 

We've all been beginners.  Most of us have been beginners in many fields.  Part of stepping into a new field is learning the language -- in this case, LSL -- and part is grasping its logical underpinnings.  Language  is actually the easier part of it.  You can always consult dictionaries or wikis to find the right word or the syntax for a command.  The logic is harder to assimilate.  You can learn a lot by experimenting -- I strongly recommend practicing on increasingly difficult tasks -- but you can shortcut some of the experiments by seeing what more experienced people have done before you, learning from their mistakes.  That's what this forum is for.  We rarely provide finished examples, because it makes more sense to identify specific places where logic needs tuning and then let the OP take it from there.  We try to identify places where we know we and other scripters have had problems, and to offer possible ways out of them.

It's often hard to tell how much advice to offer, and it's rarely easy to tell how it will be received.  Unlike many of the SL forums, this one has historically had very few condescending participants, but any of our posts might be interpreted that way by someone.  The best I can say, personally, is that I have tried very hard not to respond in a snippy or condescending way, even when I have been tempted to.  I can almost guarantee that some of the thousands of students I have known in my career probably felt hurt by something I said, but it wasn't intentional. If I've come across that way here, I apologize. 

  • Like 2
  • Confused 1
Link to comment
Share on other sites

well...i am new in all this just start to learn by gutting and modifying existing script for just not even a month..and i have almost zero knowledge in scripting at any language except writing some simple basic HTML script at school computer class years ago..i truly think everyone here are correct, sometimes a simple thing can do just the way we want to and sometime they don't and have to use something more elaborates to go around it. so i think it is depending on the circumstances. just can't think a simple solution will solve everything but can't also think an elaborate ones needed to solve everything..well..it just my thought ;D specially for someone who is totally blind in any of this like me starting with something simple is the best way for me to understand things, and gradually develop into thing that are more complicated when i facing problems that can't be solved with simple commands . and tbh the learning script i am working right now consist little bit of everything i got from all of you in here that already help me tremendously. i truly thank you all very very much.. and please expect alot more questions from me cos sure i'll have a bunch of them along the way ;D @

Edited by NawaliaTrea
  • Like 2
Link to comment
Share on other sites

12 hours ago, Rolig Loon said:

Unlike many of the SL forums, this one has historically had very few condescending participants

I can fix that for you! B|

I figure it's a public service to discourage people from writing LSL.

default
{
    state_entry()
    {
        if ([TRUE] == [FALSE])
            llOwnerSay("Everything can be proven!");
    }
}

Who would encourage fresh, innocent minds to follow this path to madness?

  • Haha 5
Link to comment
Share on other sites

I'm having difficulty understanding something. A timer event is not a hack or a workaround, true, yet this thread is asking a question that can only be answered with a workaround, or hack, enabling one to bypass the one-timer-event limit. When I mentioned hacks and workarounds, I was referencing this thread, the one we're posting in, and I do not recall ever stating that a timer was a hack or a workaround.

I believe this failure to see the obvious when one is trying to make a point of being right is what a certain someone was talking about when you guys got all over her for mentioning a function you guys didn't like as much as doing this stuff, the stuff in this thread.

Failure to see how our scripting practices will potentially blossom out over time and affect the scripting practices of others is certainly something to overcome, but it seems to me that it isn't restricted to scripting practices. Seeing how treatment of other members of the forum affects them, the forum, and others on the forum, I think that's possibly just as important.

Link to comment
Share on other sites

On 6/23/2018 at 11:11 AM, Qie Niangao said:

I can fix that for you! B|

I figure it's a public service to discourage people from writing LSL.


default
{
    state_entry()
    {
        if ([TRUE] == [FALSE])
            llOwnerSay("Everything can be proven!");
    }
}

Who would encourage fresh, innocent minds to follow this path to madness?

But, but, but - would it not be a true statement in some quantum possibility condition... xD

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2161 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

×
×
  • Create New...