nyuuzyou/wikis huggingface dataset:
Arabian Microcontinent

Arabian Microcontinent, also known with its transitory name A232, is a Microcontinent located at Coordinates 665-667/1087-1089, Grid Sector F10, Far West Ocean. This map structure appeared on maps from 2013 or probably even before, but because of its small size, it was not noticed by Geographic surveys. 
== Structure ==
Arabian Microcontinent is made of 6 sims: S Haras, Jeddah City, Jeddah, Jeddah Sea, Arab World and Isles Marquises. Majority of them are desert.
S Haras is an oasis, surrounded by mountains, with a horse ranch in its center.
Jeddah City hosts center of a luxurious modern Arab city, with steel and glass sky-scrappers, shining in the desert sun. Race cars can be seen on roads and palm trees are around the coasts.
Jeddah is another sim, part of the city, but with a bit more historical buildings, also well maintained.
Arab World sim hosts a huge palace, with its gorgeous gardens. With all its vegetation, it is like an oasis in the desert.
Jeddah Sea is part of a sea, with an island and a peninsula. It makes you think of a luxury station in Dubai.
Isles Marquises are a mixture of parcels, part of them with unfinished constructions.
== Geography ==
This microcontinent is, with little exceptions, an extreme rich model of Tropical Beach Paradise. All, except S Haras, is covered with sand. Altitude is low (except again for the mountains found in S Haras) and ground texture resembles that of sand. Water covers nearly half of the surface and is sailable. Vegetation is tropical.
A high network of roads (and paths in S Haras) give access to all parcels in the microcontinent.
Of great interest are the buildings found here. They compose a City spread on 3 sims.
== Land status ==
Except for parcels in Isles Marquises, access restrictions are rare. Protected land is present, along roads and waterways. 
Land is owned by the same estate.
== See also ==
List Of Microcontinents And Sim Clusters
Second Life Geography
Oceans
City & Town
Arbor Project

The Arbor Project is a Second Life group that is working to recover and rejoin mainland microparcels (land cuts) with bigger plots so they can be useful again.
While seeking neighboring parcels that can rejoin those microparcels, Arbor works to protect and beautify small plots of land by planting trees.
The group has a long history, leading efforts to ban the practices of adfarming and land-cutting, and to work with Linden Lab and LDPW on projects to heal the damages those practices caused to the Mainland.
To understand the history of Arbor, one must know some history of this practices and their ravages to the Mainland.
... good stuff goes here. In the meantime: User:Qie Niangao/A Tour of Route 1
Arcadia Asylum

If you've ever gone freebie shopping and seen interestingly decorated boxes with unusual things inside like hobo boots, hobo bicycle, hobo blimp, hobo backpack, etc., you've found some of the work of Arcadia Asylum. More obscure, but equally free is her avie, clothing, architecture, vehicles, indoor and outdoor decor and a myriad of other doo-dads she made to strike her fancy. Much of her work is old, distressed, rusted, slummy, or otherwise intended for the SL hobo community.
During her very brief stay in SL, she was incredibly prolific, producing hundreds of objects of great detail and complexity in many cases, other things with single prim simplicity using delightful textures to captivate, enthrall, beguile and draw her admirers into her fantasy world. A group, the Arcadia Asylum Recovery group, was formed to pull all her work together and make it available to everyone. An Arcadia Asylum Library was later developed to facilitate that. Free vendors are available for land / store owners at SLX and you can take anything you want from the same vendors that are all displayed at the library. It is hoped you will contribute items we don't already have. Submit your transferable items to , An Arcadia Asylum Library librarian. We have some scripters in group who may be able to trade out a no-copy script for a full perms one so the object is no longer no-copy.
Reasons for her departure from SL are unconfirmed but suspected to be, at least, two fold. There are unscrupulous SL marketers who are selling her work despite the fact that each item comes packaged with her strongly worded notecard demanding that her creations remain FREE to anyone and everyone. It is also rumored that she lost at least a major portion of her inventory in an SL event. 
Those interested in learning about building in general, about the brilliant possibilities of textures, about the clever use of scripts, about whimsy, or just about exploring the clever & creative side of one human being's spirit, you're encouraged to visit An Arcadia Asylum Library. Scrutinize her work, take some stuff home, tear it apart, study it, rebuild it and learn some things about how one person approached it.
Architecture Working Group

== About ==
AWG's mission is to develop the protocols that will open up the Second Life Grid from something operated solely by Linden Lab to where others can run parts of the grid. Learn more about scope, timeframe, getting started, process and best practices in About AWG.
== Meetings ==
=== AWG Meetings ===
Formal meetings will likely be held 3-4 times/year and located in Second Life to facilitate broad participation. Meetings will be coordinated on SLDev.
* AWG Meeting 2 held 18 March 2008: Follow link for chat log, audio recording and other resources.
* AWG Meeting 1: Agenda, transcript, work items, participant responses and other resources.
=== Weekly In-world Discussions ===
* In-world office hours and discussions related to AWG issues
** Transcripts of meetings
== Documents and Resources ==
=== Specifications ===
The current, and first, draft of the proposed "Open Grid Protocol" can be found here:
* Open Grid Protocol Drafts
Please Note: 
* The draft page is locked because we want a stable reference for discussion and to base the next draft on. Each section in the draft has a link on the right to a discussion for that particular section. Discuss!
* Previously, we referred to this document as "Second Life Grid Open Grid Protocol" or "SLGOGP." This has now been shortened to "Open Grid Protocol," but you may see the old terms on some documents and links.
=== Design Documents ===
The current state of the group's design:
* Second Life Grid: Description, motivation and goals.
** Architectural Principles
* Structural Design: Overview of structure, description of agent and region domains, etc.
** Agent Domain
** Region Domain
* Second Life Grid Protocols: Description of current Second Life Grid architecture
** Foundation Protocols
** Login Protocol
** Teleport Protocol
*** Teleport Strawman
* Second Life Grid Glossary
=== Resources ===
* Open Grid Public Beta: Beta testing for login and teleport between Second Life and participating OpenSim simulators
* AWG Test Harness Python-based client library and test harness to test implementation and documentation of the Open Grid Protocols
* AWG Use Cases contributed by work group members.
Related efforts, groups and work:
* AWG Implementations: Projects working to achieve interoperability with the project
* The Incubator: A place for new ideas and concepts
* AW Groupies: Informal discussions by the people that make up the AWG
* Viewpoint Advocacy Groups: A set of groups developing ideas around particular issues
*
Architecture Working Group/Meeting 1 2007-9-13/Agenda

Second Life Grid Architecture Working Group 1
==I. Opening (30 min.)==
* Why we're here
* How we'd like to see participation
* Legal Issues
* What LL is thinking
* History of how this came about
* Why this is important
** the big scary numbers
==II. Introductions All Around (60 min.)==
* about 3 min. each
==III. The architecture (90 min.)==
# Region & Agent Domains
#* Agent Domain
#** agent services
#** agent hosts
#** agent stores
#** login
#* Region Domain
#** region services
#** region hosts (simulators)
#** region stores
#** login, part 2
#* Multiple Domains
#** Multiple Region Domains
#** Multiple Agent Domains
#** cross-linking
#** trust brokering
# Scaling
#* within a domain
#* multiple domains
# Central Utilities
#* Identity
#* Presence
#* L$
#* Search
# Modes of Deployment
#* Second Life
#* Land companies
#* Agent / Identity providers
#* Self-Hosted regions
#* Running Disconnected
# Technologies
#* Capabilities
#* cHTTP
#* REST & LLSD
==IV. Discussion (120 min.)==
#Process and participation
#Architecture
#* Major Architectural Form
#* Identity & Agents
#* Regions
#* Assets & Permissions
==V. Work To Be Done (60 min.)==
* Written Perspectives
** Thoughts on the design
** Will this work for you
** Where your work would interact
* Messages & Functions
** descriptive contract
** message flow
** parameters
** required trust
** The 500 messages
==VI. Closing (30 min.)==
Mop up.
Category:Architecture Working Group
Arizona/Tombstone Microcontinent

Arizona/Tombstone is a Microcontinent with temporary name A061, located at Coordinates 966-968/1044-1047, Grid Sector I10, Little Pacific Ocean. 
== Structure ==
It is composed of 9 sims. This is a Western-themed roleplay and combat area.
== Geography ==
Land is dry, desert. Ground texture is white-to-red. It looks like the Western deserts. There are a few rivers, but all land sround them is dry. Mountains and hills are persent, with maximum Altitude of 50 meters. Interesting is that in this microcontinent there is a mine somewhere in South. Another mine is in Wastelands, also a Microcontinent (for more info, see Caves & Mines. Vegetation is reduced to a few trees, small parcels with grass for your horses and desert plants. Horses are present here.
Transportation is possible by horse or by walking, not by flying. There is even an alternative way, Tombstone Railway.
== Land Status ==
Only a few sims allow access for everyone. The other sims have restricted acces. You need to wear Western clothes to enter and a special combat meter. This is a wild place and there is a risk to get shot.
== See Also ==
Second Life Geography
List Of Microcontinents And Sim Clusters
Oceans
Caves & Mines
Array

An array is a data structure consisting of a group of elements having a single name that are accessed by indexing.
These elements can be of all other types like float, string or vector.
Example for a standard array :
array FRUITS = ["apple" , "banana", "strawberry"];
here FRUITS[1] = "banana"
Example for an associative array :
array EXAMPLE;
EXAMPLE["fruit"] = "apple";
EXAMPLE["beverage"] = "coffee";
EXAMPLE["meat"] = "chicken";
Functions:
llForeach
These functions have been created and contributed by LSL users to perform operations not covered by built-in LSL functions :
Simple LSL Array (Associative)
----
Reasons not to implement this suggestion as it is currently formulated:
#Associative Arrays would be double the memory footprint of ordinary lists. Memory limitations are a major concern.
#It would require major changes to LSL in bytecode, functions and syntax.
#*There are no LSO bytecodes currently implemented that can perform these tasks. This is not a trivial change.
#*Obviously the LSL compiler would need to be changed to support this new syntax. This is not a trivial change.
#*Since the array type is new, there are no functions that can deal with it.
#The difference between list and array syntax could be confusing to both the compiler and user, excluding associative arrays there is no meaningful reason why array style syntax can't be implemented with lists.
Articles utiles nouveaux propriétaires terrains (KB)

__NOTOC__
==Articles utiles pour les nouveaux propriétaires de terrains==
Voici quelques liens qui vous seront très utiles si vous envisagez d'acheter du terrain dans le monde virtuel de Second Life® :
Questions fréquemment posées par les nouveaux propriétaires de terrains 
Comment acheter un terrain dans la Boutique ?
Types de régions privées
Aspetto fisico

"Aspetto fisico" è una finestra mobile che permette di effettuare delle modifiche al corpo del proprio avatar. Si attiva dal menu in alto Modifica> Aspetto fisico... e poi scegliendo la voce relativa alla parte del corpo che si desidera modificare. E'possibile entrare nella stessa modalità puntando il mouse sul proprio avatar cliccando col tasto destro, apparirà il menu contestuale dal quale è possibile scegliere la voce Aspetto fisico. Quando si apre questa finestra il tuo avatar andrà in "Modalità aspetto fisico" e rimarrà con le braccia e le gambe divaricate per darti maggiore visibilità durante le modifiche. Durante questa fase la fotocamera effettuerà automaticamente lo zoom sulla parte del corpo che hai scelto di modificare. È comunque possibile spostare la fotocamera durante questa modalità per consentire la visualizzazione del tuo avatar anche da altre prospettive.
AssetType

/// <summary>
 /// The different types of grid assets
 /// </summary>
 public enum AssetType : sbyte
 {
 /// <summary>Unknown asset type</summary>
 Unknown = -1,
 /// <summary>Texture asset, stores in JPEG2000 J2C stream format</summary>
 Texture = 0,
 /// <summary>Sound asset</summary>
 Sound = 1,
 /// <summary>Calling card for another avatar</summary>
 CallingCard = 2,
 /// <summary>Link to a location in world</summary>
 Landmark = 3,
 /// <summary>Legacy script asset, you should never see one of these</summary>
 //[Obsolete]
 //Script = 4,
 /// <summary>Collection of textures and parameters that can be 
 /// worn by an avatar</summary>
 Clothing = 5,
 /// <summary>Primitive that can contain textures, sounds, 
 /// scripts and more</summary>
 Object = 6,
 /// <summary>Notecard asset</summary>
 Notecard = 7,
 /// <summary>Holds a collection of inventory items</summary>
 Folder = 8,
 /// <summary>Root inventory folder</summary>
 RootFolder = 9,
 /// <summary>Linden scripting language script</summary>
 LSLText = 10,
 /// <summary>LSO bytecode for a script</summary>
 LSLBytecode = 11,
 /// <summary>Uncompressed TGA texture</summary>
 TextureTGA = 12,
 /// <summary>Collection of textures and shape parameters that can
 /// be worn</summary>
 Bodypart = 13,
 /// <summary>Trash folder</summary>
 TrashFolder = 14,
 /// <summary>Snapshot folder</summary>
 SnapshotFolder = 15,
 /// <summary>Lost and found folder</summary>
 LostAndFoundFolder = 16,
 /// <summary>Uncompressed sound</summary>
 SoundWAV = 17,
 /// <summary>Uncompressed TGA non-square image, not to be used as a
 /// texture</summary>
 ImageTGA = 18,
 /// <summary>Compressed JPEG non-square image, not to be used as a
 /// texture</summary>
 ImageJPEG = 19,
 /// <summary>Animation</summary>
 Animation = 20,
 /// <summary>Sequence of animations, sounds, chat, and pauses</summary>
 Gesture = 21,
 /// <summary>Simstate file</summary>
 Simstate = 22,
 }
Category:Assets
AssetUploadRequest

==Message Layout==
{
	AssetUploadRequest Low NotTrusted Unencoded
	{
		AssetBlock		Single
		{	TransactionID LLUUID	}
		{	Type		S8	}
		{	Tempfile	BOOL	}
		{	StoreLocal	BOOL	}
		{	AssetData	Variable	2	} 
	}
}
==Usage and Notes==
Used for Xfer Manager transfers
*ID - Randomly generated LLUUID. The AssetID of the upload is computed by taking the MD5 hash of this ID and the SecureSessionID, so both the client and the server know what the uploaded asset's AssetID will be before the transfer finishes
*Type - AssetType of the asset being uploaded
*Tempfile - Deprecated
*StoreLocal - Used for temporary files like baked textures. These files are stored on the simulator's local file system rather than the asset server cluster. On the server side, this asset is referenced by simhost:port/asset/texture.id and fetched through HTTP before being served to the client
*AssetData - If the entire asset can fit in this packet (without going over the maximum packet size, MTUBYTES is currently defined as 1200 bytes) this is the raw asset data. If multiple packets need to be sent to upload this asset, AssetData is empty
Category:Messages
Asset Wrapper

Reference	extension	id	mime type	LSL
= Requirements =
A simple container format has been invented to wrap assets in a somewhat flexible and concise manner. Specifically we needed a format which:
* provides features for attribution.
* the meta-data needs to be in the first network packet. (specifically a requirement of texture attribution)
* supports arbitrary meta-data.
* introduces minimal byte overhead and does not require increased payload size.
Other container formats were considered but rejected for one of:
* too much overhead
* poor cross-language and cross-platform support
* geared for streaming content rather than fixed assets.
= Specification =
The asset type is an LLSD array of arrays. Each sub-array will contain a LLSD map of meta-data followed by the data segment. Asset files are serialized in binary LLSD unless a header in asset file indicates otherwise. 
The asset file:
* must be an array of arrays.
* should be binary
* may not have a header to indicate binary serialization
* must indicate if they are not serialized in the binary format in the first line of the file.
* should not contain more than one segment of a particular content-type.
The meta-data segment:
* must contain the 'content-type' of the data.
* should contain a 'creation-date' of the data. 
* should not contain a 'content-length'.
= examples =
This is a notation based mock-up of what an asset will actually look like:
[[{'content-type':'image/x-j2c', 
 'creation-date':'2007-01-01T00:01:00Z', 
 'creator-id':u3c115e51-04f4-523c-9fa6-98aff1034730}, 
 <BINARY IMAGE DATA>]] 
This example shows two different wrapped assets. Note that the first binary blob is serialized as raw data and the curly braces are inside the 160 bytes of content. The vnd.ll.lslbyte presented here is a (somewhat truncated) base64 encoding of the byte code generated by compiling the related vnd.ll.lsltext.
[
 [
 {
 'content-type':'application/vnd.ll.lsltext', 
 'creation-date':'2007-03-15T18:30:00Z', 
 'creator-id':u3c115e51-04f4-523c-9fa6-98aff1034730
 },
 b(160)"default
{
 state_entry()
 {
 llSay(0, "Hello, Avatar!");
 }
 touch_start(integer total_number)
 {
 llSay(0, "Touched.");
 }
}"
 ],
 [
 {
 'content-type':'application/vnd.ll.lslbyte', 
 'creation-date':'2007-03-15T18:30:18Z', 
 'creator-id':u3c115e51-04f4-523c-9fa6-98aff1034730
 },
 b64"AABAAAAAAAAAAAIAAAA//wAAP/8AAADgAAAA5wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABkAAAAZAAAAAAAAAAAAAAAZAAAAAAAAAABAAAAAAAAAAAAAAAAAAAABQAAAAEAAAAQAAAAAAAA
AAUAAAAFAAAAABAAAAAAAAAAPgAAAAQAAAAFAGNbXgAAAABgSGVsbG8sIEF2YXRhciEAZgAAAABc
XgAAAAhwEQjRABeVAAAABQBjW14AAAAAYFRvdWNoZWQuAGYAAAAAXF4AAAAIcBEI0QAXAZUAAEAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" 
 ]
]
Category:Assets
Astrin Few's Guide to Second Life Music

Ever wanted to get into the live music scene as a musician? Here are some words of wisdom from Astrin Few, one of Second Life's accomplished live performers:
On the technical side, there are several layers. First is good audio. Nothing to do with SL or the Internet (well, nothing about audio streaming really has much to do with SL). I recommend an external USB or Firewire mixer, like the Alesis Multimix 8USB, 12USB, however many channels you need. The reason for an externalUSB/Firewire mixer: Windows sound card drivers can be hard to work with. If you move your audio to an external mixer, your life becomes very simple, since you bypass a sound card and all its quirky driver behavior. But in any case, good audio quality into your computer is paramount; if you don't have clean sound with good levels, you won't sound good. Since every sound card driver and audio setup is different, it's very hard to provide general tips on getting audio into your computer.
Secondly, you need a stream client. The Winamp DSP plugin is ok, I've been using the Oddcast v3 client, which also requires that you install the LAME MPEG encoder, which is an extra step which may throw a few people off. But the Oddcast v3 client supports both shoutcast and icecast servers, and seems a bit more stable than the Winamp DSP plugin. I can't say anything about streaming on a Mac, as I haven't done it. In the stream client you'll select your audio source, which in my case is "USB Audio".
Thirdly, you need a server to connect your client to. This is a host, port and password that you enter into your stream client. Since most of the venues in Second Life now provide stream servers, this is no longer an issue for live performance. In the good ol' days, we all provided our own streams. I still provide my own stream, but that's just my choice.
After that, it's just hooking up with venue owners and managers and getting gigs. A perusal of the Live Music event listings is a good way to see which clubs are active.
Category:Media, music, and sound
AttachedSound

==Message Layout==
{
	AttachedSound Medium Trusted Unencoded
	{
		DataBlock			Single
		{	SoundID			LLUUID	}
		{	ObjectID		LLUUID	}
		{	OwnerID			LLUUID	}
		{	Gain			F32	}
		{	Flags			U8	}
	}
}
==Usage and Notes==
Category:Messages
Attachment

An attachment is an object (clothing, weapons, jewelry, shoes, etc) that can be attached to an avatar at a specific location. Usually location is set by the creator of the object. The default location otherwise is the right hand.
Attachments are linked to bones. When a bone is animated, all attachment locations linked to that bone will move identically to the bone they are linked to.
The following is a list of attachments and the bones they are attached to.
* Bone: Head
** Skull
** Nose
** Left Ear
** Right Ear
** Mouth
** Chin
* Bone: EyeLeft
** Left Eyeball
* Bone: EyeRight
** Right Eyeball
* Bone: FaceJaw
** Jaw
* Bone: FaceEarLeft
** Alt Left Ear
* Bone: FaceEarRight
** Alt Right Ear
* Bone: FaceEyeAltLeft
** Alt Left EyeThe alternative eye bones do not have saccades like the default eyes. They remain still unless animated.
* Bone: FaceEyeAltRight
** Alt Right Eye
* Bone: FaceTongueTip
** Tongue
* Bone: Neck
** Neck
* Bone: Chest
** Spine
** Chest
* Bone: Torso
** Left PecThe "pec" attachment slots are unfortunately named, as they attach to the central bone of the avatar's torso, and the pectoral muscles are associated with the upper or chest bone.
** Right Pec
* Bone: Pelvis
** Pelvis
** Stomach
* Bone: Groin
** Groin
* Bone: CollarLeft
** Left Shoulder
* Bone: ShoulderLeft
** L Upper Arm
* Bone: ElbowLeft
** L Forearm
* Bone: WristLeft
** Left Hand
* Bone: HandRing1Left
** Left Ring FingerAdded with the Bento Skeleton, December 2015
* Bone: CollarRight
** Right Shoulder
* Bone: ShoulderRight
** R Upper Arm
* Bone: ElbowRight
** R Forearm
* Bone: WristRight
** Right Hand
* Bone: HandRing1Right
** Right Ring Finger
* Bone: HipLeft
** Left Hip
** L Upper Leg
* Bone: KneeLeft
** L Lower Leg
* Bone: AnkleLeft
** Left FootNote: The leg bone hierarchy is Hip -> Knee -> Ankle -> Foot -> Toe. Foot and toe are not rigged in the default avatar, as the mesh foot is rigged to the ankle bone. Custom rigged mesh that use the foot bone may cause unexpected issues with unrigged attachments.
* Bone: HipRight
** Right Hip
** R Upper Leg
* Bone: KneeRight
** R Lower Leg
* Bone: AnkleRight
** Right Foot
* Bone: Tail1
** Tail Base
* Bone: Tail6
** Tail Tip
* Bone: Wing4Left
** Left Wing
* Bone: Wing4Right
** Right Wing
* Bone: HindLimb4Left
** Left Hind Foot
* Bone: HindLimb4Right
** Right Hind Foot
== Footnotes ==
== See also ==
* Video Tutorial/Wearing attachments
* Video Tutorial/Editing attachments
* Video Tutorial/Retrieving lost attachments
* What are HUD attachments
* Video Tutorial/Advanced attachment adjustment
Attachment (OS)

=== Feature Design Document ===
An attachment is an object or a prim, which is attached to an avatar. Attachment can be attached to several points of the body.
=== Functional Spec ===
(none)
=== Test scripts ===
Smoke Test 
Newbie Test
Shared Drawables Test 
=== Discussion for future improvements ===
(none)
=== Relationship to other features ===
 List of features that need to be tested when this feature changes, and why. 
Avatar FPS test - make sure we don't render avatars with attachments slower.
=== User Guides ===
(none)