blink Blink ON and OFF as Listen Event

[Mistral Shieldmaiden]

Hello,

I am struggling with a script for days now and hope to find some help here. I am working on a HUD for my FX and Light Screen, almost everything works but I can´t figure out what I am missing in the blinking script. The prim where this receiver script is in only blink once when BlinkON is activated in stead of over and over again. Any help is much appreciated 😊

Thanks, Mistral Shieldmaiden

------

vector color = <1,1,1>; 
float intensity = 1.000; 
float radius = 10.000;  
float falloff = 0.750; 

default
{
    state_entry()
    {
    llSetTimerEvent(2);
     }      
     timer()
    { 
    llListen(737, "", NULL_KEY, "" );
    }
     listen(integer number, string name, key id, string message)   
    {
         if(message=="BlinkON")
     { llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_POINT_LIGHT, TRUE, color, intensity, radius, falloff, PRIM_FULLBRIGHT, ALL_SIDES, TRUE, PRIM_GLOW, ALL_SIDES,0.2]);
     llSleep(0.5);
     llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_POINT_LIGHT, FALSE, color, intensity, radius, falloff, PRIM_FULLBRIGHT, ALL_SIDES, FALSE, PRIM_GLOW, ALL_SIDES,0]); 
    }
         if(message=="BlinkOFF")
     { llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_POINT_LIGHT, FALSE, color, intensity, radius, falloff, PRIM_FULLBRIGHT, ALL_SIDES, FALSE, PRIM_GLOW, ALL_SIDES,0]); 
    }
  }
}
 

Edited April 15, 2019 by Mistral Shieldmaiden

[Rolig Loon]

Well, you have almost all the right pieces, but they are in the wrong places.  You want to turn the timer ON or OFF when you hear the message "BlinkON" or "BlinkOFF", so the place to put llSetTimerEvent() is in the listen event. And you want the actual blinking to take place every time that the timer is triggered, so you want to put all of the SLPPF function calls in the timer event instead of in the listen event.  The only piece that's actually missing is the toggle switch to turn the blink ON or OFF each time that the timer event triggers.  That's easy to add. 

A basic toggle switch looks like this
 

timer()
{
    iSwitch = !iSwitch;
    {
        if (iSwitch)
        {
            // Do the ON stuff
        }
    }
    else
    {
        //Do the OFF stuff
    }
}

where the variable iSwitch is a global integer.   So, each time the timer event triggers, iSwitch flips from TRUE to FALSE (OFF to ON, whatever), and operates the right SLPPF function calls.

[steph Arnott]

36 minutes ago, Mistral Shieldmaiden said:

    llListen(737, "", NULL_KEY, "" );
 

You can not use NULL_KEY in the llListen function. It has a value of "00000000-0000-0000-0000-000000000000". You are locking your script to a value it will never recieve. Set it to llListen(737, "",  "", "" );

Edited April 15, 2019 by steph Arnott

[Fenix Eldritch]

49 minutes ago, steph Arnott said:

You can not use NULL_KEY in the llListen function. It has a value of "00000000-0000-0000-0000-000000000000". You are locking your script to a value it will never recieve. Set it to llListen(737, "",  "", "" );

That is not true. The key parameter for llListen can be either an empty string ("") or the NULL_KEY constant and the result will be the same: i.e. it won't be used for filtering. This is explicitely stated on the wiki page for llListen, and can also be seen in the hover tip when moving the cursor over the function in the viewer's script editor.

Just now, I set up two scripts to talk and listen and can confirm that the following variants are functionally identical:

llListen(737, "", "00000000-0000-0000-0000-000000000000", "" );
llListen(737, "", NULL_KEY, "" );
llListen(737, "", "", "" );

 

Edited April 15, 2019 by Fenix Eldritch
typos

[steph Arnott]

1 minute ago, Fenix Eldritch said:

That is not true. The key parameter for llListen can be either an empty string ("") or the NULL_KEY constant and the result will be the same: i.e. it won't be used for filtering. This is explicitely stated on the wiki page for llListen, and can also be seen in the hover tip when moving the cursor over the function in the viewer's script editor.

Just now, I set up two scripts to talk and listen and can confirm that the following variants are functionally identical:

llListen(737, "", "00000000-0000-0000-0000-000000000000", "" );
llListen(737, "", NULL_KEY, "" );
llListen(737, "", "", "" );

 

Two are filters. That is using the old LSO.

[steph Arnott]

vector color = <1,1,1>;
float intensity = 1.000;
float radius = 10.000;
float falloff = 0.750;
integer iSwitch;

default
{
	state_entry()
	{
		llListen(737, "", "", "");
	}
	listen(integer number, string name, key id, string message)
	{
		if(message=="BlinkON")
			llSetTimerEvent(2.0);
		else if(message=="BlinkOFF")
		{
			llSetTimerEvent(0.0);
			iSwitch = 0;
			llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_POINT_LIGHT, FALSE, color, intensity, radius, falloff, PRIM_FULLBRIGHT, ALL_SIDES, FALSE, PRIM_GLOW, ALL_SIDES,0]);
		}
	}
	timer()
	{
		iSwitch = !iSwitch;
		if (iSwitch)
		{
			llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_POINT_LIGHT, TRUE, color, intensity, radius, falloff, PRIM_FULLBRIGHT, ALL_SIDES, TRUE, PRIM_GLOW, ALL_SIDES,0.2]);
			llSleep(0.5);
		}
		else
			llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_POINT_LIGHT, FALSE, color, intensity, radius, falloff, PRIM_FULLBRIGHT, ALL_SIDES, FALSE, PRIM_GLOW, ALL_SIDES,0]);
	}
}

 

[Mistral Shieldmaiden]

Thank you Rolig and Steph for your fast response, I already was trying to implement what Rolig had said but ended in some Errors so I knew I still did not find the right places for the different events ....  but the script Steph just posted is working, jayyyy , you have no idea how happy I am now after so many headbreaking days, thank you so much😘

Mistral

[Fenix Eldritch]

Glad you got your issue sorted out Minstral.

And Steph, I  have no idea what you're talking about. I stand by my original statement. All other things being equal, using "" or NULL_KEY for the speaker's id parameter in llListen the end result will be the same.

[steph Arnott]

5 minutes ago, Fenix Eldritch said:

Glad you got your issue sorted out Minstral.

And Steph, I  have no idea what you're talking about. I stand by my original statement. All other things being equal, using "" or NULL_KEY for the speaker's id parameter in llListen the end result will be the same.

You use it, then when it glitches you will be scratching your head wondering what is going on. I have been in SL to long and know what will happen. And FYI you should not even be valuating a NULL_KEY even in a conditional. It is a bad practice.

Edited April 16, 2019 by steph Arnott

[Fenix Eldritch]

Then in the interest of gaining a better understanding, can you elaborate on the scenario where this would cause a problem?

And to be clear, I'm not talking about the best practice of making one's listener filters as specific as possible to eliminate unnecessary chat. Specifically, under what circumstance would using llListen(737, "", NULL_KEY, "" );  fail where llListen(737, "", "", "" );  would not?

 

Edited April 16, 2019 by Fenix Eldritch
correction

[steph Arnott]

Just now, Fenix Eldritch said:

Then in the interest of gaining a better understanding, can you elaborate on the scenario where this would cause a problem?

And to be clear, I'm not talking about the best practice of making one's listener filters as specific as possible to eliminate unnecessary chat. Specifically, under what circumstance would using llListen(737, "", NULL_KEY, "" );  fail where llListen(737, "", NULL_KEY, "" );  would not?

 

LSO was as loose as a clowns pocket. Mono tightened up those things we got away with. If you use a NULL_KEY it will glitch. Maybe not today, not next week and then wollop it refuses to work.

[Fenix Eldritch]

That's extremely vague and doesn't answer my question. Have there been documented instances of this? JIRAs? Anything that concretely identifies the source of the supposed "glitch" being traced back to the use of NULL_KEY in place of "" ?

If not, then I think I'll take my chances, thank you.

[steph Arnott]

12 minutes ago, Fenix Eldritch said:

That's extremely vague and doesn't answer my question. Have there been documented instances of this? JIRAs? Anything that concretely identifies the source of the supposed "glitch" being traced back to the use of NULL_KEY in place of "" ?

If not, then I think I'll take my chances, thank you.

I give up. It is just wasting my time.

[Wandering Soulstar]

10 hours ago, steph Arnott said:

You use it, then when it glitches you will be scratching your head wondering what is going on. I have been in SL to long and know what will happen. And FYI you should not even be valuating a NULL_KEY even in a conditional. It is a bad practice.

Once again .. providing baseless claims that you cannot demonstrate, and incorrect direction. In all the years of my coding in SL, and scripts that have been running for years, I have never had an issue with Listens that have NULL_KEY in them. And, if I have explicitly set a variable to equal NULL_KEY, then later test to see if it has changed in a conditional, why in the world would that not work .. and where have any guides stated that it is 'a bad practice' .. other than you stating it?

9 hours ago, steph Arnott said:

I give up. It is just wasting my time.

Actually I am sure it is myself, or anyone else that challenges your claims that is wasting their time .. and so to take a page from multiple threads you have posted to .. Good Day.

Edited April 16, 2019 by Wandering Soulstar

[steph Arnott]

2 hours ago, Wandering Soulstar said:

 

My claims? Even LL's own code writters state NOT to use NULL_KEY in MONO. They state to only  test for a valid key or in the case of listen filters to leave it  "" or a valid key..

[Wandering Soulstar]

Just now, steph Arnott said:

Even LL's own code writters state NOT to use NULL_KEY in MONO

Where is this stated .. can you please provide a link?

[Nova Convair]

I'm not quite sure why a thing is debated that can be proofed so easily.

Besides of that - I'm using NULL_KEY in listen events for years now - and I am still laughing. 😜

[steph Arnott]

4 minutes ago, Nova Convair said:

I'm not quite sure why a thing is debated that can be proofed so easily.

Besides of that - I'm using NULL_KEY in listen events for years now - and I am still laughing. 😜

You probably are because you are stuck in LSO mode. LSL has advanced since those kludge days and when SL goes to 'cloud' you will have to be even more specific in code.

[Wandering Soulstar]

44 minutes ago, steph Arnott said:

You probably are because you are stuck in LSO mode. LSL has advanced since those kludge days and when SL goes to 'cloud' you will have to be even more specific in code.

Still waiting for that link .....

[steph Arnott]

Just now, Wandering Soulstar said:

Still waiting for that link .....

Read the official LSL wiki for starters then. It gives plenty of information.

[Rolig Loon]

4 minutes ago, steph Arnott said:

Read the official LSL wiki for starters then. It gives plenty of information.

Steph --  here's what the wiki has to say at the entry for llListen:

If msg, name or id are blank (i.e. "") they are not used to filter incoming messages. If id is an invalid key or assigned the value NULL_KEY, it is considered blank as well.

There's nothing in the Discussion notes or the revision history to suggest that it's changed.

 

[steph Arnott]

8 minutes ago, Rolig Loon said:

Steph --  here's what the wiki has to say at the entry for llListen:

If msg, name or id are blank (i.e. "") they are not used to filter incoming messages. If id is an invalid key or assigned the value NULL_KEY, it is considered blank as well.

There's nothing in the Discussion notes or the revision history to suggest that it's changed.

 

Firstly 'In many applications keys are checked against NULL_KEY to determine if they are valid; this is bad practice.' that means it will glitch.

Secondly, why on Earth would you test for a NULL_KEY for coms when everything in SL sends its UUID? Nothing sends a transmission with a NULL_KEY.

LL state that valid keys should be tested and not an invalid NULL_KEY.

Edited April 16, 2019 by steph Arnott

[Rolig Loon]

Hehe... I didn't say that it was good practice or that I would do it myself. Steph.  I'm too lazy for that.  I always use "" ,  According to the wiki and my own years of experience, though, it's perfectly acceptable to use NULL_KEY.  It's not interpreted as a filter in that function.  Sometimes "not good practice" doesn't mean that it won't work.

[steph Arnott]

Just now, Rolig Loon said:

Hehe... I didn't say that it was good practice or that I would do it myself. Steph.  I'm too lazy for that.  I always use "" ,  According to the wiki and my own years of experience, though, it's perfectly acceptable to use NULL_KEY.  It's not interpreted as a filter in that function.  Sometimes "not good practice" doesn't mean that it won't work.

It will and at times will not. It is another miss-use that gives intermitant glitching. Also i know you use "". I tend to use which ever filter suits my needs.

[Wandering Soulstar]

20 minutes ago, steph Arnott said:

Read the official LSL wiki for starters then. It gives plenty of information.

I was expecting that you'd say something like that. In the Wiki for the function llListen (link) the first mention of a null key:

Quote

Specification

For the listen event to be triggered it must first match the criteria set forth by the filters; only when all the criteria have been met is a listen event generated. First the message must have been transmitted on channel. If id is both a valid key and not a null key then the speaker's key must be equivalent^[2] to id. If name is set then the speaker's legacy name must match name exactly (case sensitive). If msg is set then the spoken message must match msg exactly (case sensitive).

Then later in the code example 'Two Listen Handles' they show when setting a listen for anyone the call to the finction with NULL_KEY. The only other mention of NULL_KEY in this entry is on the notes:

Quote

Avoid channel zero (PUBLIC_CHANNEL) and set name or id where possible to avoid lag. llListen(0, "", NULL_KEY,"") can be laggy as it listens to all chat from everyone in chat range and so should be avoided.

.. and obviously here the mention is in regards to opening listens on the Public Channel for everyone as it could be laggy. As I could not find anything here, I went to the definition og th NULL_KEY constant itself (link). Here the closest thing to any warning or advice in regards to not using NULL_KEY comes about half way into the notes:

Quote

...In many applications keys are checked against NULL_KEY to determine if they are valid; this is bad practice

LSL makes it easy to check if a key is valid. Simply use the key as the parameter for a conditional.

That is, instead of if(uuid != NULL_KEY), use if(uuid). if(uuid) will only return TRUE if it is a valid key that is also not a null key.

So simply a statement about how to determine if a variable holds a valid key ...

So instead of :

18 hours ago, steph Arnott said:

You can not use NULL_KEY in the llListen function. It has a value of "00000000-0000-0000-0000-000000000000". You are locking your script to a value it will never recieve. Set it to llListen(737, "",  "", "" ); 

The wiki specifically shows the use of NULL_KEY in an llListen call. Furthermore in no place did I find any warnings that using NULL_KEY in llListen (or any other function that takes a key as a parameter) would:

17 hours ago, steph Arnott said:

You use it, then when it glitches you will be scratching your head wondering what is going on.

And I definitely could find nowhere the following:

3 hours ago, steph Arnott said:

My claims? Even LL's own code writters state NOT to use NULL_KEY in MONO. They state to only  test for a valid key or in the case of listen filters to leave it  "" or a valid key..

So .. if it is on the Wiki and you have found this important piece of knowledge, could you please share that with the fourm?