Floating text appear then dissapear after a few seconds?

I'll try and describe my scenario.

A prim that you click on, then that sends a key word to 2 another linked prims.

If the other prims detects the right word then they run their own short piece of code and that's it.

Is there any Simple way of when the code in a prim does it's job (for ease of this question, I'll say it changes colour) to then have some floating text appear about the prim with a string of text in it.

which I know it easy enough

But (and this is the bit I'm asking about) after 3 or so seconds the floating text is blanked out (which as far as I know) means issuing another floating text command but just a blank one.

But (in my mind) you click the 1st prim, the code in the second prim runs and puts up the floating text, and that's the end of the code.

How then (say 3 seconds later) would you get the text to clear (be overwritten with a blank) as now there's nothing "running" is there?

Set a timer event with llSetTimerEvent (3.0) function when the code has done its stuff. Add the code to clear the text in the timer event handler AS WELL AS another call to llSetTimerEvent (0.0) with zero as the parameter to clear the timer setting, which would repeat every 3 seconds otherwise.

I think I "just about" understand that

Will Re-Triggering the code that displays the text clash with the timer event?

Say it's going to clear in 2 seconds and I click the prim twice more, will each click (and fresh text put up above the prim) wipe out the effect of the timer (if you see what I mean?)

If you call llSetTimerEvent again before the previous timer event occurs it will be reset to 3 seconds, so the new text will overwrite the existing text and will be cleared 3 seconds after that.

default
{
    state_entry()
    {
        llSay(0, "Hello, Avatar!");
    }

    touch_start(integer total_number)
    {
        llSetTimerEvent (0.0);//this line added as per Void's suggestion below
        llSetText ("Touched at " + llGetTimestamp (), <1.0, 1.0, 1.0>, 1.0);
        llSetTimerEvent (3.0);
    }
    
    timer ()
    {
        llSetTimerEvent (0.0);
        llSetText ("", <1.0, 1.0, 1.0>, 1.0);
        llSay (PUBLIC_CHANNEL, "Text cleared at " + llGetTimestamp ());
    }
}

Many thanks for that.

That code works perfect in a stand alone prim, or a prim with the (what I'd call) touch control on, but I'm getting errors I think with the "timer()" command, presumably as it's just in a script and not a touch activated prim/script.

This is the start of my script:
================================================

default
{
link_message(integer sender_num, integer num, string str, key id)
{

if( str=="press" )
{

================================================

Another prim sends the word "press" to this prim and if it detects the word, then it runs.

I guess there is a reason why this does not like the script example.

I don't think I understand the problem here. You cannot get a script to run at all unless it's in a prim. Do you mean you are getting error messages from the compiler when you combine the example with your own script and try to save it? Could you give a description of the error you are getting?

One point, though; you refer to the "timer()" command. This is not what it is at all. It is an "event", and the code asssociated with it is an "event handler" which is executed when the event occurs. The distinction is important, as it relates to the fundamental nature of LSL scripts: they are "event driven". They consist of chunks of code that are executed in response to various events (on_rez, state_entry, touch, timer, link_message and so on).

Thanks for the follow up. (was tired and getting a bit late last night)

Off to RL work now

Will try and explain more clearly later.

Just just to say now, yes it worked perfect in a stand alone prim, and I managed to make it also work in the prim I click on that triggers a message to ALL_LINKED_PRIMS.

The problem was that I could not get the code working (compiler errors) when it was put into the code of the linked prims.

I'm wondering if the idea itself it going to work (practicality wise) but as I say, can explain better later.

Again, I very much appreciate your help.

Thanks

If that is the actual text you are using in your code it will be the cause of a compiler error message: the constant name you want is LINK_SET.

No, it's ok...

I'd just sleepily crept out of bed when I posted that, rushing to get ready for work & eating my breakfast at the same time

At I say, there may be a problem with my "plan" as it were, as rethinking it, I think I'd want the text to be redirected into a prim other than the one the code is in.

In time I know I'm going to want to re-do this from scratch (well much of it) as in reality I should be using the blue "dialog box" system for picking my simple options.

I have 2 simple dialog box demo's but they are (for me) currently a bit confusing and not quite what I'm after in the structure they work.

Basically, I (in time) would like to click on a linked set, the blue dialog box comes up with a main menu, clicking on one of those would bring up a sub page, then clicking on of the sub page items would send one of more variables back to a specific prim in the link set.

But that's beyond me right now

That is often the case; while coding you suddenly see a much simpler and more logical way of doing things. That's when you know that the learning process is working.

Dialogs are nowhere near as scary as they look at first, though there are issues surrounding them, not least being that they require a "listener" to capture the result, and badly configured listeners can be heavy on processor resources.