State variables

While all variables that might be used within more than a single state must be global right now, poluting memory statically, there also some problematic situation to purely event driven state scripts, where there is switched between a number of states with only little number of calls to self defined functions. In such case, where there are only very little number of self defined functions that might be called with arguments, data managament is, within one and the same state, only solved through static global memory(heap) / variable allocation. A possible solution might be to allow state variables that are declared after the openening brace from a state declaration and which is/are allocated on stack only when the state is active, but removed from memory when a state becomes inactive from switching to another state. If a stack based solution is not conform to compiler design, another solution might be to have a memory layout of heap based state variables, where there is a fixed allocation of the static part of state variables in size of the largest possible set form state variables, that is reused when switching from one state to another. Such a solution of state local variables might help to provide a significant lower memory footprint in event driven multi state scripts.

Example:

state default {

   integer x = 0; // with scope of default state

   state_entry()
   {
       llOwnerSay( (string)x ); // produces output "0"
       state ExampleState;
   }

}

state ExampleState {

   integer x = 1;  // with scope of "ExampleState" state

   state_entry()
   {
       llOwnerSay( (string)x ); // produces output "1"
       state default;
   }

}

--Eraz Rhode 07:09, 29 May 2007 (PDT)