Second Life Wiki - User contributions [en]

State variables

2007-05-30T17:54:19Z

Eraz Rhode:

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 management 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 opening 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:
<pre>
// Both variables "x" and "y" refer to the same memory location
// while only one can be referenced when the given state is active
// Overloading of names in sense of C++ must not be implemented if
// this would cause too much problems with the actual given
// LSL compiler.

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

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

state ExampleState
{
integer y = 1; // with scope of "ExampleState" state

state_entry()
{
llOwnerSay( (string)x ); // produces compiler ERROR !!!
llOwnerSay( (string)y ); // produces output "1"
state default;
}
}
</pre>
--[[User:Eraz Rhode|Eraz Rhode]] 07:09, 29 May 2007 (PDT)

----

State functions (methods) would be interesting too. This sort of complication would require some language design (the exact implementation would end up being controversial). -- [[User:Strife Onizuka|Strife Onizuka]] 09:46, 29 May 2007 (PDT)

LlGetAgentPreferredLanguage

2007-05-29T14:10:55Z

Eraz Rhode:

{{LSL_Function|func_id|mode=request|func_sleep=1.0|func_energy=10.0|func=llGetAgentPrefedLanguage|sort=GetAgentPreferedlanguage|func_desc=Returns a string with the content of the profiles entry about languages.
|return_text|spec|caveats=Requires data from the Owners profile, which is atm not generic and this way difficult to parse.|examples|helpers|related|also|notes=This function would allow us to get information about prefered languages the agent is capable of and this way offer scripts to alternate dialogs texts, notecards etc. to the specific language prefered by the agent.}}

--[[User:Eraz Rhode|Eraz Rhode]] 07:10, 29 May 2007 (PDT)

State variables

2007-05-29T14:10:10Z

Eraz Rhode:

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;
}
}

--[[User:Eraz Rhode|Eraz Rhode]] 07:09, 29 May 2007 (PDT)

State variables

2007-05-29T14:09:42Z

Eraz Rhode:

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:

<nowiki>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;
}
}</nowiki>

--[[User:Eraz Rhode|Eraz Rhode]] 07:09, 29 May 2007 (PDT)

State variables

2007-05-29T14:07:51Z

Eraz Rhode:

Talk:LlGetMyAccountBalance

2007-05-29T14:01:44Z

Eraz Rhode: /* Security issues from scripts within vendor machines etc. */

== Name of Function ==
Maybe, to match the current nomenclature of LSL, this should be called "llGetOwnerAccountBalance" or "llGetOwnerMoney" [[User:Cron Stardust|Cron Stardust]] 14:25, 21 March 2007 (PDT)

== Possible security issues ==
I just noted that with this function it would be possible to detect when the owner paid money to another person/object or received funds by recording the current amount of money, then testing again after a period of time and comparing the values. This would allow a malicious script to siphon money away from the owner to another player slowly and at each transaction so as to hide traces of it's activity. [[User:Cron Stardust|Cron Stardust]] 14:25, 21 March 2007 (PDT)

== Security issues from scripts within vendor machines etc. ==

Such functionality will bring new security issues. Vendor software, which is often not editable by customers using them, might contain spyware functionality to spray account balance information around in SL and into the internet. This is a seriuos issue related to privacy!

State variables

2007-05-29T13:59:37Z

Eraz Rhode:

LSL Useful Function WishList

2007-05-29T13:34:27Z

Eraz Rhode: /* Other functionality */

__NOTOC__
{{LSL Header}}
==A==
[[llAddToEstateBanList]]
==C==
[[llChangeLandPassPrice]]

To allow the access price to enter a parcel of land to be changed via a script.

==E==
{{LSLG|llExecuteMenuCommand}}

==F==
{{LSLG|llFrandom}}

==G==
{{LSLG|llGetParcelBanList}}
{{LSLG|llGetEstateBanList}}
{{LSLG|llGetAvatarKeysOnParcel}}
{{LSLG|llGetAvatarKeysOnEstate}}
{{LSLG|llGetMyAccountBalance}}
{{LSLG|llGetGroup}}
<s>llGetScriptCreatorKey</s> - use [[llGetInventoryCreator]]([[llGetScriptName]]()) instead
{{LSLG|llGetRegionPopulation}}
{{LSLG|llGetParcelPopulation}}
{{LSLG|llGetWorldPopulation}}
{{LSLG|llGetPrice}}
{{LSLG|llGetAgentPreferedLanguage}}

==I==
{{LSLG|llInstantMessageGroup}}
{{LSLG|llInviteToGroup}}
==L==
{{LSLG|llLBETMB}}
==N==
{{LSLG|llName2Key}}
==P==
{{LSLG|llPizza}}
{{LSLG|position_change}}

==R==
{{LSLG|llRaiseError}}
{{LSLG|llRemoveFromEstateBanList}}
{{LSLG|llReturnObject}}
{{LSLG|llReturnOwnersObjects}}
{{LSLG|llRotateAgent}}

==S==
{{LSLG|llSoundex}}
{{LSLG|llSpeakText}}
{{LSLG|llSpeech2Text}}
{{LSLG|llSpeech2TextRemove}}
{{LSLG|llSayWithinRange}}

==T==
{{LSLG|llTeleportAgent}}
{{LSLG|llTriggerLandmark}}
{{LSLG|llTrackTouches}}

==Other functionality==
{{LSLG|Block comments}}
{{LSLG|True tab-stops}}
{{LSLG|Code Folding}}
{{LSLG|Windowed Scripting}}
{{LSLG|Switch Statement}}
{{LSLG|Array}}
{{LSLG|on_unrez|Event: Unrez / Delete}}
{{LSLG|Conditionals}}
{{LSLG|State variables}}

LlGetAgentPreferredLanguage

2007-05-22T22:42:52Z

Eraz Rhode:

LlGetAgentPreferredLanguage

2007-05-22T22:41:49Z

Eraz Rhode:

{{LSL_Function|func_id|mode=request|func_sleep=1.0|func_energy=10.0|func=llGetAgentPrefedLanguage|sort=GetAgentPreferedlanguage|func_desc=Returns a string with the content of the profiles entry about languages.
|return_text|spec|caveats=Requires data from the Owners profile,which is atm not formatted and dificult to parse|examples|helpers|related|also|notes=This function would allow us to get information about prefered languages the agent is capable of and this way offer scripts to alternate dialogs texts, notecards etc. to the specific language prefered by the agent.}}

Talk:LlGetMyAccountBalance

2007-05-22T22:31:18Z

Eraz Rhode: /* Security issues from scripts within vendor machines etc. */

== Name of Function ==
Maybe, to match the current nomenclature of LSL, this should be called "llGetOwnerAccountBalance" or "llGetOwnerMoney" [[User:Cron Stardust|Cron Stardust]] 14:25, 21 March 2007 (PDT)

== Possible security issues ==
I just noted that with this function it would be possible to detect when the owner paid money to another person/object or received funds by recording the current amount of money, then testing again after a period of time and comparing the values. This would allow a malicious script to siphon money away from the owner to another player slowly and at each transaction so as to hide traces of it's activity. [[User:Cron Stardust|Cron Stardust]] 14:25, 21 March 2007 (PDT)

== Security issues from scripts within vendor machines etc. ==

Such functionality will bring new security issues. Vendor software, which is often not editable by customers using them, might contain spyware funtionality to spray account balance information around in SL and into the internet. This is a seriuos issue related to privacy!

Talk:LlGetMyAccountBalance

2007-05-22T22:29:23Z

Eraz Rhode: Security issues from scripts within vendor machines etc.

== Name of Function ==
Maybe, to match the current nomenclature of LSL, this should be called "llGetOwnerAccountBalance" or "llGetOwnerMoney" [[User:Cron Stardust|Cron Stardust]] 14:25, 21 March 2007 (PDT)

== Possible security issues ==
I just noted that with this function it would be possible to detect when the owner paid money to another person/object or received funds by recording the current amount of money, then testing again after a period of time and comparing the values. This would allow a malicious script to siphon money away from the owner to another player slowly and at each transaction so as to hide traces of it's activity. [[User:Cron Stardust|Cron Stardust]] 14:25, 21 March 2007 (PDT)

== Security issues from scripts within vendor machines etc. ==

Such functionality will bring new security issues.
Vendor software, which is often not editable by customers using them, might contain spyware funtionality with such functionality to spray account balance information around in SL and into the internet.

LlGetMyAccountBalance

2007-05-22T22:20:52Z

Eraz Rhode:

LlGetMyAccountBalance

2007-05-22T22:00:21Z

Eraz Rhode:

{{LSL_Function|func_id|mode=request|func_sleep=0.1|func_energy=10.0|func=llGetMyAccountBalance|sort=GetMyAccountBalance|func_desc=Returns an integer representing the script owner's Linden Dollar account balance.
|return_text|spec|caveats=Requires Permission|examples|helpers|related|also|notes=This function would allow us to get the current status of our Linden dollar account balance, and open the door for accounting after Money() events. Remark from Eraz Rhode: It also might bring new security issues, when sold scripts may look after the owners balance, but sends such sensible data to third parties without the knownledge of the owner, which is not typically the script creator.}}

LlGetMyAccountBalance

2007-05-22T21:59:02Z

Eraz Rhode:

{{LSL_Function|func_id|mode=request|func_sleep=0.1|func_energy=10.0|func=llGetMyAccountBalance|sort=GetMyAccountBalance|func_desc=Returns an integer representing the script owner's Linden Dollar account balance.
|return_text|spec|caveats=Requires Permission|examples|helpers|related|also|notes=This function would allow us to get the current status of our Linden dollar account balance, and open the door for accounting after Money() events. Remark from Eraz Rhode: It also allow security issues, when sold items may look after the owners balance, but sends such sensible data to third parties without the knownledge of the account owner, which is not typically the script creator.}}

LSL Useful Function WishList

2007-05-22T17:46:23Z

Eraz Rhode: /* G */

LSL Useful Function WishList

2007-05-22T17:26:34Z

Eraz Rhode: /* G */

__NOTOC__
{{LSL Header}}
==A==
[[llAddToEstateBanList]]
==C==
[[llChangeLandPassPrice]]

To allow the access price to enter a parcel of land to be changed via a script.

==E==
{{LSLG|llExecuteMenuCommand}}

==F==
{{LSLG|llFrandom}}

==G==
{{LSLG|llGetParcelBanList}}
{{LSLG|llGetEstateBanList}}
{{LSLG|llGetAvatarKeysOnParcel}}
{{LSLG|llGetAvatarKeysOnEstate}}
{{LSLG|llGetMyAccountBalance}}
{{LSLG|llGetGroup}}
<s>llGetScriptCreatorKey</s> - use [[llGetInventoryCreator]]([[llGetScriptName]]()) instead
{{LSLG|llGetRegionPopulation}}
{{LSLG|llGetParcelPopulation}}
{{LSLG|llGetWorldPopulation}}
{{LSLG|llGetPrice}}
{{LSLG|llGetAvatarPreferedLanguage}}

==I==
{{LSLG|llInstantMessageGroup}}
{{LSLG|llInviteToGroup}}
==L==
{{LSLG|llLBETMB}}
==N==
{{LSLG|llName2Key}}
==P==
{{LSLG|llPizza}}
{{LSLG|position_change}}

==R==
{{LSLG|llRaiseError}}
{{LSLG|llRemoveFromEstateBanList}}
{{LSLG|llReturnObject}}
{{LSLG|llReturnOwnersObjects}}
{{LSLG|llRotateAgent}}

==S==
{{LSLG|llSoundex}}
{{LSLG|llSpeakText}}
{{LSLG|llSpeech2Text}}
{{LSLG|llSpeech2TextRemove}}
{{LSLG|llSayWithinRange}}

==T==
{{LSLG|llTeleportAgent}}
{{LSLG|llTriggerLandmark}}
{{LSLG|llTrackTouches}}

==Other functionality==
{{LSLG|Block comments}}
{{LSLG|True tab-stops}}
{{LSLG|Code Folding}}
{{LSLG|Windowed Scripting}}
{{LSLG|Switch Statement}}
{{LSLG|Array}}
{{LSLG|on_unrez|Event: Unrez / Delete}}
{{LSLG|Conditionals}}