nyuuzyou/wikis huggingface dataset:
Reset from Child Plugin

* Back to MLPV2_Addons
Thanks to Gillian Uxlay for writing this script and allowing it in the wiki.
This script goes in the main prim with all the MLP scripts. It could also be used in any other object that you would like to reset scripts in without having to 'edit linked-> reset all scripts in selection'. It can probably be modded to just reset specific scripts as well. It is activated by the second script in any child prim that you want to use for a 'reset prim'.
//Written and donated by Gillian Uxlay
// just call this script using llMessageLinked( LINK_ROOT, RESET_ALL_SCRIPTS, "", "" );
integer RESET_ALL_SCRIPTS = -5102104;
resetAllScripts(){
 integer l = llGetInventoryNumber( INVENTORY_SCRIPT );
 integer i;
 for( i = 0; i < l; i++ ){
 string name = llGetInventoryName( INVENTORY_SCRIPT, i );
 if( name != llGetScriptName() ){
 llResetOtherScript( name );
 }
 }
 llResetScript();
}
default
{
 state_entry()
 {
 }
 link_message( integer sender_num, integer num, string message, key id ){
 if( num == RESET_ALL_SCRIPTS ){
 resetAllScripts();
 }
 }
} 
This is a basic dialog script by Alicia Stella that I modded to go in any child prim. It will give a menu to reset or not reset all the scripts in the main prim. It may work if MLP is not in the main prim, but that has yet to be tested. It will take up to 12 buttons if you wish to use them to save on ~menu memory. It can be accessed by all, unless the owner sets it to 'not running' or someone with more script skill than I wants to mod it to group or owner only access.
list MENU_MAIN = ["Reset", "No Reset"]; //up to 12 in list
integer menu_handler;
integer menu_channel;
integer RESET_ALL_SCRIPTS = -5102104;
menu(key user,string title,list buttons)
{
 llListenRemove(menu_handler); //BugFix 5/2008
 menu_channel = (integer)(llFrand(99999.0) * -1);
 menu_handler = llListen(menu_channel,"","","");
 llDialog(user,title,buttons,menu_channel);
 llSetTimerEvent(30.0); //how long to wait for user to press a button before giving up and closing listen
}
default
{
 state_entry()
 {
 //nada
 }
 touch_start(integer total_number)
 {
 menu(llDetectedKey(0), "\nRemote Reset Menu", MENU_MAIN);
 }
 
 listen(integer channel,string name,key id,string message)
 {
 if (channel == menu_channel) 
 {
 llListenRemove(menu_handler); //close listen
 llSetTimerEvent(0); //stop timeout timer
 if (message == "Reset")
 {
 llSay(0, "Reseting main scripts...");
 llMessageLinked( LINK_ROOT, RESET_ALL_SCRIPTS, "", "" );
 }
 else if (message == "No Reset")
 {
 llSay(0, "No Resets Done.");
 }
 //else if (message == "Button3")
 //{
 //do something
 //}
 }
 }
 
 timer() //VERY IMPORTANT menu timeout
 {
 llListenRemove(menu_handler); //close listen
 llSetTimerEvent(0); //stop timeout timer
 }
}
Category:MLPV2
Resetting Scripts in a Large Build

If you have a complex build, perhaps sim wide and you need to reset all of the scripts, there isn't an easy way to do this, say from from parcel properties or the region tools.
This presents a few startegies for providing this ability but it does require some forethought.
=Region Restart=
Detect region restart and restart script.
(or other event)
default
{
 changed(integer change)
 {
 if (change & CHANGED_REGION_START) 
 {
 llOwnerSay("The regions has just restarted, resetting the script.");
 llResetScript();
 }
 }
 state_entry()
 {
 // setup and do stuff
 }
}
=Listener - restart on command=
Listen for instruction and restart script.
// some random negative number
integer chatChannel = -1324628;
// could consider using a random string for the command to obscure the function
string chatCommand = "reset";
default
{
// this script sends the command to reset the other scripts to reset.
// change to use any trigger event that is suitable.
 touch(integer num_detected)
 {
 llRegionSay(chatChannel, chatCommand);// (3)
 }
}
// some random negative number
integer chatChannel = -1324628;
// could consider using a random string for the command to obscure the function
string chatCommand = "reset";
default
{
// insert the listen into your scripts that need to reset on command
 state_entry()
 {
 // setup and do stuff
 llListen(chatChannel, "", NULL_KEY, chatCommand);
 }
 listen(integer channel, string name, key id, string message)
 {
 if (message == chatCommand)
 llResetScript();
 }
}
=Random Staggered Reset=
Script load on the sim may be a concern, if so you could use a random timer in the target script to stagger the reset as follows:
// some random negative number
integer chatChannel = -1324628;
// could consider using a random string for the command to obscure the function
string chatCommand = "reset";
default
{
// insert the listen into your scripts that need to reset on command
 state_entry()
 {
 //setup and do stuff
 llListen(chatChannel, "", NULL_KEY, chatCommand);
 }
 listen(integer channel, string name, key id, string message)
 {
 if (message == chatCommand)
 {
 //random timer within [0.0, 60.0)
 llSetTimerEvent( llFrand(60.0) );
 }
 }
 timer()
 {
 llResetScript();
 }
}
If you need to stagger the resets, perhaps because the order the scripts start is important, use different commands with appropriate pauses between start commands, such as:
// some random negative number
integer chatChannel = -1324628;
// could consider using a random string for the command to obscure the function. "reset3" will trigger after 15 seconds.
string chatCommand = "reset3";
default
{
 state_entry()
 {
 // setup and do stuff
 llListen(chatChannel, "", NULL_KEY, chatCommand);
 }
 listen(integer channel, string name, key id, string message)
 {
 if (message == chatCommand) llResetScript();
 }
}
----
Return to Good_Building_Practices
Resident

A user in Second Life (SL) is typically called a Resident (abbreviated "Resi"). This term is used by Linden Lab and may be meant to give users a feeling of "belonging" and ownership of the virtual world. "Resident" is also used throughout most of SL's user interface in place of "user".
== Origin of the term "Resident" ==
Robin Linden stated in the official forums:
"Resident" is frequently capitalized because it's used as a title by habit. However, given a changing, growing world, the Doc Team is evaluating (as of 2009-02-01) whether this still makes sense.
== First use of "Resi" ==
Torley Linden (formerly Torley Torgeson) is the first known person to abbreviate "Resident" as "Resi", dating back to 2005-10-06. Over the years through repeated usage, this shorthand gained popularity both inside Linden Lab and publicly:
Category:Culture
Resident/ja

Second Life (SL) のユーザは通常、住人 (Resident, Resi) と呼ばれます。この呼び方は が使っているものです。その意図は、ユーザが仮想世界の一部であり、またそれを所有しているという実感をユーザ自身に持ってもらおうという事かもしれません。"住人" という言葉は SL のユーザ インターフェイスの殆どで "ユーザ" の替わりに使われています。 
== "住人" という語の起源 ==
Robin Linden は公式フォーラムで以下のように述べています:
"Resident" はよく語頭が大文字にされますが、それは習慣的に表題として使われるからです。しかし世界の成長に伴い、(2009-02-01 時点で) Doc Team はこれにまだ意義があるかどうか検討中です。 
== "Resi" の初出 ==
"Resident" を "Resi" と最初に略したのは dating back to 2005-10-06 における Torley Linden (かつての Torley Torgeson) です。何年も繰り返し使われるうち、この短縮形は Linden Lab 内外で一般的に使われるようになりました: 
Category:Culture/ja
Resident/ko

세컨드라이프(SL)의 사용자를 통상, 거주자(Resident, Resi)이라고 부릅니다. 이 호칭은 린든랩에서 사용하고 있는 것입니다. 그 의도는, 사용자가 가상 세계의 일부이며, 또 그것을 소유하고 있다라고 하는 실감을 사용자 자신에게 갖게 하려고 하는 의도일 지도 모르겠습니다. ”거주자” 라고 하는 말은 SL 의 사용자 인터페이스의 대부분으로 ”사용자”의 대신에 사용되고 있습니다.
== "거주자" 라고 하는 단어의 기원
Robin Linden 은 공식 포럼에서 아래와같이 진술하고 있습니다 :
”Resident”은 첫 글자가 대문자로 되는 것은 습관적인 표제로서 사용되기 때문입니다. 그러나 세계의 성장에 따르고, (2009-02-01시점으로) Doc Team 은 이것에 아직 의의가 있는 것인가 아닌가에 대하여 검토하고 있습니다.
== ”Resi”의 첫 출현 ==
”Resident”를 ”Resi”이라고 최초에 생략한 것은 dating back to 2005-10-06에서 톨리 린든 ( 이전의 닉은 Torley Torgeson)입니다. 몇년동안 되풀이하며 사용되는 동안, 이 단축형은 Linden Lab 내외에서 일반적으로 사용되게 되었습니다 :
Category:Culture/ko
Resident/pt

= Residente =
Um usuário do Second Life (SL) é normalmente chamado de Residente (abreviadamente "Resi" em inglês). Este termo é sempre utilizado pela Linden Lab e pode ser entendido como uma denominação para dar ao usuário, um sentimento de que ele "pertence" e está imerso no mundo virtual. "Residente" também é um termo utilizado na maior parte das configurações da Interface do Usuário (UI em inglês) do SL, no lugar do termo "usuário".
== Origem do termo "Residente" ==
Robin Linden escreveu no fórum oficial:
Tradução livre
O termo "Residente" é frequentemente capitalizado, porque é usado como um título, como um cargo, pelo hábito de utilizá-lo. No entanto, em um mundo onde ocorrem mudanças, a equipe de documentação do SL está avaliando (a partir de 01/02/2009), se isso ainda faz sentido.
== Primeiro a fazer o uso do termo "Resi" ==
O usuário Torley Linden (conhecido anteriormente como Torley Torgeson) foi a primeira pessoa que abreviou o termo "Resident" para "Resi", segundo esta postagem feita em seis de outubro de 2005. Ao longo dos anos através do uso repetido, esta denominação ganhou popularidade tanto dentro Linden Lab, como dentro e fora do Second Life:
Tradução livre
Category:Culture
Resident Experience

Linden Lab Resident Experience Team
Resident Experience Team - or Rx
The Resident Experience (aka User Experience) team works to make Second Life easier to use by integrating user-centered design methodologies into the product development cycle. The Rx team includes Visual Designers, User Experience Designers and Usability Specialists.
== SL-UX Email Discussion List ==
The SL-UX Email Discussion List is the ongoing conversation about the Second Life UI and Resident Experience. Residents and Lindens join together to discuss, brain storm and refine the Second Life UI.
Join 
== Rx Office Hours ==
The Resident Experience team no longer holds in-world office hours. Transcripts of past office hours can be found here: Resident_Experience_Team_Office_Hours_Transcripts.
See also the User Experience Interest Group
== Rx Team Projects ==
==== Landmarks and Navigation Project ====
A project to improve access to and management of Landmarks (see also the Landmarks component in the Second Life Issue Tracker).
==== Dazzle ====
Dazzle is meant to modernize the visual appearance of the viewer UI, using the viewer's existing skinning hooks wherever possible, documenting and addressing technical blockers as required.
==== User Interface Improvements ====
This page describes a proposed project to design and implement an improved User Interface for the Second Life Viewer.
Resident Help Network Portal

== Welcome to the Resident Help Network Portal! ==
		 	
{| border="0" cellspacing="0" cellpadding="0" width="100%"	
{| style="width="30%"; font-size:95%; text-align:center; padding:-2px; background:none" cellpadding="0" cellspacing="0"	RHN	RHN
		 	
{| border="0" cellspacing="0" cellpadding="0" width="100%"	
{| style="width="30%"; font-size:95%; text-align:center; padding:-2px; background:none" cellpadding="0" cellspacing="0"	Category: New Resident Help	Category: New Resident Help
Category:Portals
Resource Impact Calculator

====Resource Impact Calculator caused by Avatars====
Use to control the lag caused by avatars, maximizing sim's performance.
Takes into account how many avatars are in the sim, for proper load balancing,
which means that if the sim is empty, all RAM/CPU is allowed for use for a single avatar, since it wont cause an impact on performance.
/*
 Sim resource impact calculator 
 Call impactCPU(uuid) or/and impactRAM(uuid) to get the percentage of allowed resources the avatar is using.
 Data returned is integer type [0-100].
*/
integer maxRAM=209715200; //bytes- 200MB server RAM is usually what simulators use for scripting
float maxload=0.040;//seconds- Maximum allowed latency in miliseconds due scripting load on the simulator, 40-80ms is normal.
integer impactCPU(key id){
return (integer)(llList2Float(llGetObjectDetails(id, [OBJECT_SCRIPT_TIME]), 0)/(maxload/llGetRegionAgentCount())*100);
}
integer impactRAM(key id){
return (integer)(llList2Float(llGetObjectDetails(id, [OBJECT_SCRIPT_MEMORY]), 0)/(maxRAM/llGetRegionAgentCount())*100);
}
default
{
 
 touch_start(integer num_detected) {
 key id=llDetectedKey(0);
 llInstantMessage(id,"CPU usage: "+(string)(impactCPU(id))+"%");
 llInstantMessage(id,"RAM usage: "+(string)(impactRAM(id))+"%");//example of informational message
 if(impactRAM(id)>100)llInstantMessage(id,"You've hit the memory usage limit."); //example of warning message
 if(impactCPU(id)>100)llInstantMessage(id,"You've hit the CPU usage limit."); 
 
 }
}
Category:LSL Examples
Responder

* A Responder is a simple abstraction for handling callbacks that have data associated with them.
* The responder has two essential properties:
** It is ref counted so that it gets destroyed when both the responder and the respondee are finished with it
** It has a virtual 'completed' function that is called by the responder and implemented by the respondee
* Simple example:
class LLResponder : public LLThreadSafeRefCount
{
public:
	virtual ~LLResponder();
	virtual void completed(bool success) = 0;
};
class MyResponder : public LLResponder; // contains private data and overrides completed()
make_a_request("foo", new MyResponder(mydata)}; // when the request completes, MyResponder::completed() will get called
Reticolo/Informazioni di riferimento su come caricare un modello IU

Usare la finestra Carica modello per caricare i file COLLADA (.dae) su Second Life. Questa finestra include tre schede e una sezione di anteprima che è sempre visibile.
== Anteprima ==
La sezione Anteprima mostra il modello selezionato in anteprima a vari livelli di dettaglio. Usare i per la panoramica e per zoomare la visualizzazione del modello.
=== Pesi e tariffe ===
Mostra il costo calcolato per il download, la fisica e il server per il modello, il costo dei prim equivalenti e la tariffa di caricamento relativa.
== Livello di dettaglio ==
== Fisica ==
== Modificatori ==
RetrieveInstantMessages

==Message Layout==
{
	RetrieveInstantMessages Low NotTrusted Unencoded
	{
		AgentData 		Single
		{ AgentID LLUUID }
		{	SessionID	LLUUID	}
	}
}
==Usage and Notes==
Used by client to get instant messages that were persisted out to the database while the user was offline.
==Related Messages==
ImprovedInstantMessage
Category:Messages
Reverse HTTP

Reverse HTTP is an experimental protocol which takes advantage of the HTTP/1.1 Upgrade: header to turn one HTTP socket around. When a client makes a request to a server with the Upgrade: PTTH/0.9 header, the server may respond with an Upgrade: PTTH/1.0 header, after which point the server starts using the socket as a client, and the client starts using the socket as a server. There is also a COMET-style protocol which will work with HTTP/0.9 or 1.1 clients that do not know how to perform this upgrade.
March 2009: Zero and Donovan submitted an Internet-Draft formally describing this.
----
Below is an example transcript using Reverse HTTP. Lines on the left are traffic from the client to the server. Lines on the right are traffic from the server to client. Lines with a red background are HTTP requests. Lines with a green background are HTTP responses.
The transcript was created by sniffing the traffic from running this script .
Request
Response
client -> server 	server -> client
POST / HTTP/1.1 	
Host: localhost:9999 	
Accept-Encoding: identity 	
Upgrade: PTTH/0.9 	
 	
 	HTTP/1.1 101 Switching Protocols
 	Content-type: text/plain
 	Upgrade: PTTH/0.9
 	Date: Tue, 13 May 2008 20:14:45 GMT
 	Content-Length: 0
 	
 	GET / HTTP/1.1
 	Host: 127.0.0.1:65331
 	Accept-Encoding: identity
 	accept: text/plain;q=1,*/*;q=0
 	
HTTP/1.1 200 OK 	
Content-type: text/plain 	
Date: Tue, 13 May 2008 20:14:45 GMT	
Content-Length: 15 	
 	
!dlrow ,olleH 	
 	
==COMET Fallback==
If the client or server is incapable of upgrading from HTTP, a COMET-style protocol can be used instead. The server can maintain an event queue and require that the client repeatedly POST to the queue's resource to receive events. Below is a protocol trace using JSON as the protocol encoding.
POST / HTTP/1.1 	
Host: localhost:9999 	
Accept-Encoding: identity 	
 	
 	HTTP/1.1 200 OK
 	Content-type: application/json
 	Date: Tue, 13 May 2008 20:14:45 GMT
 	Content-Length: 210
 	
 	{'message-id': 'xxx', 'method': 'GET', 'request-uri': '/', 'http-version': 'PTTH/0.9', 'headers': [['Host', '127.0.0.1:65331'], ['Accept-Encoding', 'identity'], ['Accept','text/plain;q=1,*/*;q=0']], 'body': }
POST / HTTP/1.1 	
Host: localhost:9999 	
Accept-Encoding: identity 	
Content-type: application/json 	
Content-length: 193 	
 	
{'message-id': 'xxx', 'http-version': 'PTTH/0.9', 'status': 200, 'reason': 'OK', 'headers': [['Content-type', 'text/plain'], ['Date', 'Tue, 13 May 2008 20:14:45 GMT']], 'body': '!dlrow ,olleH'}	
 	HTTP/1.1 200 OK
 	Content-type: application/json
 	Date: Tue, 13 May 2008 20:14:45 GMT
 	Content-Length: 2
 	
 	{}
A response of {} from the server means no server-side event occurred within some timeout, and that the client should poll again if it wants to keep receiving events.
Another idea is to use text/plain encoding instead of JSON, and just have the actual text of the HTTP request in the response, and the text of the response in the next request. In this case, the message-id would be relayed in a header instead of in the body. Perhaps the message id should always be relayed in a header and never in the body?
RevokeModification

==Message Layout==
{
	RevokeModification Low NotTrusted Unencoded
	{
		AgentData			Single
		{	AgentID			LLUUID	}
		{	SessionID		LLUUID	}
		{	GranterName		Variable	1	}
	}
	{
		RevokedBlock		Variable
		{	RevokedID		LLUUID	}
	}
}
==Usage and Notes==
Category:Messages
RevokePermissions

==Message Layout==
{
	RevokePermissions Low NotTrusted Unencoded
	{
		AgentData		Single
		{	AgentID		LLUUID	}
		{	SessionID	LLUUID	}
	}
	{
		Data	Single
		{ ObjectID				LLUUID }
		{ ObjectPermissions		U32 }
	}
}
==Usage and Notes==
Can be used by a client to revoke script Run_time_permissions. The permissions indicated by the ObjectPermissions mask (the high bits) are revoked
Category:Messages
RezMultipleAttachmentsFromInv

==Message Layout==
{
	RezMultipleAttachmentsFromInv Low NotTrusted Zerocoded
	{
		AgentData			Single
		{	AgentID			LLUUID	}
		{	SessionID		LLUUID	}
	}	
	{
		HeaderData			Single
		{	CompoundMsgID			LLUUID }	
		{	TotalObjects			U8	}
		{	FirstDetachAll			BOOL	}
	}
	{
		ObjectData			Variable		
		{	ItemID					LLUUID	}
		{	OwnerID					LLUUID	}
		{	AttachmentPt			U8	}	
		{	ItemFlags				U32 }
		{	GroupMask				U32 }
		{	EveryoneMask			U32 }
		{	NextOwnerMask			U32	}
		{	Name					Variable	1	}
		{	Description				Variable	1	}
	}
}
==Usage and Notes==
Category:Messages
RezObject

==Message Layout==
{
	RezObject Low NotTrusted Zerocoded
	{
		AgentData		Single
		{	AgentID		LLUUID }
		{	SessionID	LLUUID }
		{	GroupID		LLUUID	}
	}
	{
		RezData			Single
		{	FromTaskID				LLUUID	}
		{	BypassRaycast			U8	}
		{	RayStart				LLVector3	}
		{	RayEnd					LLVector3	}
		{	RayTargetID				LLUUID	}
		{	RayEndIsIntersection	BOOL }
		{ RezSelected				BOOL }
		{	RemoveItem				BOOL }
		{	ItemFlags				U32 }
		{	GroupMask				U32 }
		{	EveryoneMask			U32 }
		{	NextOwnerMask			U32	}
	}
	{
		InventoryData			Single
		{	ItemID				LLUUID	}
		{	FolderID			LLUUID	}
		{	CreatorID			LLUUID	}	
		{	OwnerID				LLUUID	}	
		{	GroupID				LLUUID	}	
		{	BaseMask			U32	}	
		{	OwnerMask			U32	}	
		{	GroupMask			U32	}	
		{	EveryoneMask		U32	}	
		{	NextOwnerMask		U32	}	
		{	GroupOwned			BOOL	}	
		{	TransactionID		LLUUID	}
		{	Type				S8	}
		{	InvType				S8	}
		{	Flags				U32	}
		{	SaleType			U8	}
		{	SalePrice			S32	}
		{	Name				Variable	1	}
		{	Description			Variable	1	}
		{	CreationDate		S32	}
		{	CRC				U32	}
	}
}
==Usage and Notes==
Category:Messages
RezObjectFromNotecard

==Message Layout==
{
	RezObjectFromNotecard Low NotTrusted Zerocoded
	{
		AgentData		Single
		{	AgentID		LLUUID }
		{	SessionID	LLUUID }
		{	GroupID		LLUUID	}
	}
	{
		RezData			Single
		{	FromTaskID				LLUUID	}
		{	BypassRaycast			U8	}
		{	RayStart				LLVector3	}
		{	RayEnd					LLVector3	}
		{	RayTargetID				LLUUID	}
		{	RayEndIsIntersection	BOOL }
		{ RezSelected				BOOL }
		{	RemoveItem				BOOL }
		{	ItemFlags				U32 }
		{	GroupMask				U32 }
		{	EveryoneMask			U32 }
		{	NextOwnerMask			U32	}
	}
	{
		NotecardData		Single
		{	NotecardItemID	LLUUID	}
		{	ObjectID		LLUUID	}
	}
	{
		InventoryData		Variable
		{	ItemID			LLUUID	}
	}
}
==Usage and Notes==
Category:Messages
RezScript

==Message Layout==
{
	RezScript Low NotTrusted Zerocoded
	{
		AgentData		Single
		{ AgentID		LLUUID	}
		{ SessionID		LLUUID	}
		{ GroupID			LLUUID	}
	}
	{
		UpdateBlock			Single
		{ ObjectLocalID	U32	} 
		{ Enabled			BOOL	}	
	}
	{
		InventoryBlock		Single
		{	ItemID			LLUUID	}
		{	FolderID		LLUUID	}
		{	CreatorID		LLUUID	}	
		{	OwnerID			LLUUID	}	
		{	GroupID			LLUUID	}	
		{	BaseMask		U32	}	
		{	OwnerMask		U32	}	
		{	GroupMask		U32	}	
		{	EveryoneMask	U32	}	
		{	NextOwnerMask	U32	}	
		{	GroupOwned		BOOL	}	
		{	TransactionID	LLUUID	}
		{	Type			S8	}
		{	InvType			S8	}
		{	Flags			U32	}
		{	SaleType		U8	}
		{	SalePrice		S32	}
		{	Name			Variable	1	}
		{	Description		Variable	1	}
		{	CreationDate	S32	}
		{	CRC				U32	}
	}
}
==Usage and Notes==
Category:Messages
RezSingleAttachmentFromInv

==Message Layout==
{
	RezSingleAttachmentFromInv Low NotTrusted Zerocoded
	{
		AgentData			Single
		{	AgentID			LLUUID	}
		{	SessionID		LLUUID	}
	}
	{
		ObjectData			Single
		{	ItemID			LLUUID	}
		{	OwnerID			LLUUID	}
		{	AttachmentPt	U8		}	
		{	ItemFlags		U32		}
		{	GroupMask		U32		}
		{	EveryoneMask	U32		}
		{	NextOwnerMask	U32		}
		{	Name			Variable	1	}
		{	Description		Variable	1	}
	}
}
==Usage and Notes==
Category:Messages
Rico Warilla

==Rico Warilla==
President of [Amsltech] and a virtual persona of Dr. Mario bka [Doc Reo] aka [Mareo-Ahmir Lawson]. Originally Rico Warilla was written to be Rico Dawson. Dawson was a character in a script called "Starving Artists". This was a film/ television concept in 2003. The concept was originally written by William Folger of Industree Entertainment. Although Rico Warilla, is an entirely different character.
As a resident of Secondlife in 2006, Rico grew to learn about SIM security, terraforming, building, scripting and the community. As a part of the entry level security team for Bart Heart Estates (BHE), Warilla quickly learned land management techniques. After successfully purchasing land from BHE, Brautigan & Tuck Holdings(BnT), [Governor Linden] and a few other companies, By 2007 Warilla had been building, scripting and developing products with the SL AirCavalry.
As the Operations Officer to Major General Hermans (ret), later replaced by Major General Snook (ret) Colonel Warilla worked closely with SL AirCavalry Division Command. During that time he serve as a security liaison to BnT, and BHE. Rico joined Mark Locks team of NG Security specialists at BnT. Then he moved on to becoming a BnT Security Manger. While continuing to act as the security manager, Warilla was later promoted to VP of Marketing at BnT, before finally taking Amsltech into use for real world applications.
He also worked closely with Colonel McKay, Strategic Air Command, Major Kokobide XO, HR and Medical Command. Rico Warilla is still currently the Major General of AirCav division command. 
Category: History