Beginner question - why dosen't this work?

I know how to do this with a couple of states but I tried to compact it into one perpetual state. What is wrong with my thinking?

integer lightstate = TRUE; 
vector  Color=<1,1,1>; 
float Intensity=8.9;
float Radius=14;
float Falloff=0;

default
{
    state_entry()
    {
        llSetPrimitiveParams([PRIM_POINT_LIGHT,lightstate,Color,Intensity,Radius,Falloff]);
        touch_start(integer total_number)
        {
            lightstate=!lightstate;
        }
    }
}

state entry is run once whe script first run only or reset
-LW

Touch start is an event.. it nees to be outside of State Entry.

 integer lightstate = TRUE;
vector  Color=<1,1,1>;
float Intensity=8.9;
float Radius=14;
float Falloff=0;

default
{
    state_entry()
    {
        llSetPrimitiveParams([PRIM_POINT_LIGHT,lightstate,Color,Intensity,Radius  ,Falloff]);

    }

   touch_start(integer total_number)
   {
       lightstate=!lightstate;

       // also note here.. that you never send the command again
       // to change the prim params... you've only changed the integer.
   }
} 

I also have a little bit of an uneasy feeling about the expression: "lightstate=!lightstate;" that feels a tad truncated to me. As a beginner, I can't tell if that's gonna work or not. I know what you're TRYING to do there.. but I'm not sure if that toggle will work. I would write it out longhand, just to know what I was doing was working.

touch_start(integer total_number)
     {
            
     if (lightstate == TRUE)
          {
               lightstate = FALSE;
          }
     else
         {
              lightstate = TRUE;
         }

     // then I'd reissue the Prim Params command here... just to be safe.

     llSetPrimitiveParams([PRIM_POINT_LIGHT,lightstate,Color,Intensity,Radius  ,Falloff]);

     }

That should help iron things out a tad at least?

lightstate = !lightstate is fine.
You do have to send all the parameters again.

integer lightstate = TRUE; 
vector  Color=<1,1,1>; 
float Intensity=8.9; 
float Radius=14; 
float Falloff=0; 
Light()
{
        llSetPrimitiveParams([PRIM_POINT_LIGHT,lightstate,Color,Intensity,Radius    ,Falloff]); 
}

default 
{ 
    state_entry() 
    { 
        Light();
    } 

   touch_start(integer total_number) 
   { 
       lightstate=!lightstate; 
        Light();
   } 
} 

Thanks everyone - by the time I got back here this morning I had figured it out.
And I was able to make it work with just one perpetual state which was my goal and to cut it down to more compact code.

integer lightstate = TRUE; 
vector  Color=<1,1,1>; 
float Intensity=8.9;
float Radius=14;
float Falloff=0;

default
{ 
   touch_start(integer total_number) 
   {
       lightstate=!lightstate; 
       llSetPrimitiveParams([PRIM_POINT_LIGHT,lightstate,Color,Intensity,Radius  ,Falloff]); 
    }
} 

I fear you are confusing states and events.
All of the examples have been single state scripts.
default is a state,
state_entry and touch_start are events.

But even if you're confusing the terms... you DID also manage to make it into a single event script. (and it IS a single state too, but it was before). Nice and compact looking too.

(I always assumed you needed the "State entry()" event... even if it was blank.)

to almost any "prop script" though.. I would state that the following elements should be considered carefully.

Use state entry to define your script the way it should be "at the start".. it's "ready" state. For example.. with a lightsaber... the sounds would be off, the beam would be invisible, and the lightsource would be off. Then use "on rez" to reset the script. by triggering llResetScript on rez.. you can force the script back to the beginning. it will re-read all the variable callouts at the top, and then execute "state entry". This is darned useful with things like a lightsaber... because that way, every time you "wear" it (also triggers the on rez event) it will be reset to your preferred default mode.

I've used this a few times where there have been active listens using variables defined with llGetOwner. a llResetScript on rez will clear out the old owner when a new owner wears it. (and I can use state entry to also state.. that the attachment should be invisible on wear... and then we let the new owner command it to become visible.

states are a bit more complex.. think of it as if you had several scripts inside one large text file. By using an event like touch or listen or whatever.. (money's a good one too).. you can change the item from a notecard giver that unsits you every time you try to sit.. into a car. a menu (dialog?) event could thenchange modes again and turn your car into an aircraft.. or a jetpack, or what have you.

every state has a state entry. (things that are done on entering this state). since most scripts only have the default state.. "state entry" doubles as "on save or reset".

I'm sure someone else can explain the difference better. I'm actually a bit afraid of states still.

I ended up with this compact script with one perpetual state and no function call. Is this acceptable or breaking any rules???

Also this local lighting effect is only functional if the viewer has
Edit/Preferences/Graphics Detail/Lighting Detail:/Nearby local lights turned ON but this defaults to OFF. Is there any way to offer to turn it on if they grant permission?

integer lightstate = TRUE; 
vector  Color=<1,1,1>; 
float Intensity=8.9; 
float Radius=14; 
float Falloff=0; 

default 
{ 
   touch_start(integer total_number) 
   { 
       lightstate=!lightstate; 
       llSetPrimitiveParams [PRIM_POINT_LIGHT,lightstate,Color,Intensity,Radius,Falloff]); 
    } 
} 

Annmarie,
With regards to my previous post I apologise if it seemed I was belittling you.
My comment was not itended as such.

Here is a Two state version of your code, just for show really:

vector  Color=<1,1,1>; 
float Intensity=8.9; 
float Radius=14; 
float Falloff=0; 

default 
{ 
   state_entry() 
   { 
       // original script was On ByDefault
       llSetPrimitiveParams [PRIM_POINT_LIGHT,TRUE,Color,Intensity,Radius  ,Falloff]); 
    } 

    touch_start(integer total_number) 
   { 
       state OFF;
   }
} 

state OFF
{ 
   state_entry() 
   { 
       llSetPrimitiveParams [PRIM_POINT_LIGHT,FALSE,Color,Intensity,Radius  ,Falloff]); 
    } 

    touch_start(integer total_number) 
   { 
       state default;
   }
 } 

Your code is fine.
For more complex scripts you will find you do need a state_entry and probably an on_rez and a changed but that is for the future.

I'm not aware of any LSL capability to manipulate the client settings, would be nice but I think could be too easily used for greifing. Having permissions would offset that a little.
Certainly i know numerous people would like the ability to override the sun/TOD settings and this would fall into that category of request. Who knows may be now we have the open client it may happen.

Thanks all for devoting your time. I do realize I should use a default state entry under normal situations - I was just testing the limitations as a learning experience.

I've been an assembly language programmer for over 45 years with a bit of C++ & VB and quite a bit of JavaScript so I think I'll catch on pretty quickly.

My biggest problem is apparently not uncommon and that is a reverse lookup of llfunctions based on the result I need to achieve. Any suggestions of a reference book with reverse cross-reference or do I just use the search index on line.

try the wiki at
http://rpgstats.com/wiki/index.php?title=Main_Page