The Astria Porta Open Stargate Network is a free fault tolerant open source networked Stargate teleportation system for the online game Second Life.
The code and reference implementation are FREE. If you paid for them you got ripped off.
Second Life® and SL™ are a trademarks of Linden Research, Inc., and they have lots of funny rules that require this piece of text appear at the beginning of this document.
And while we're thinking about it, we should also mention that The Astria Porta Open Stargate Network is a non profit project developed by fans of the Stargate Universe & Franchise, of which all Major Rights, Trademarks and Intellectual Properties belong to MGM, Sony Entertainment and their associated respective rights holders.
Resident "CB Radek" has done an excellent open source implementation of the Goa'uld transporter rings. Contact him in world for your free copy, or join the "openrings" group.
To get your own free Open Stargate, go to http://slurl.com/secondlife/Sentry/136/119/119
This file is part of the Astria Porta Open Stargate Distribution available at http://ma8p.com/~opengate/open7.tar.gz
News and current events can be found in
world by joining the "opengate" group.
http://world.secondlife.com/group/e949df2f-ff8c-f0d3-bb17-d882466b0ddf
A complete list of Stargates can be found at http://ma8p.com/~opengate/list.cgi
A map view of all Stargates is at http://ma8p.com/~opengate/map.cgi
If you're an XML freak, you might also want to look at http://ma8p.com/~opengate/xml.cgi
Questions / problems / miseries / pizza / beer can be sent to adam-opengate@ma8p.com
There are two ways to use an Astria Porta Open Network Stargate; voice command or DHD.
To dial a destination by voice, stand near the Stargate and say
/dial <alias>
Where <alias> is an alias for the destination Stargate. As an alternative to "/dial <alias>", the Stargates will also respond to a number of other dial commands. This was done as a compatability convenience for travelers who may be familiar with other Stargate networks.
An <alias> may be the region name of the Stargate (i.e. "laserlight"), the region name followed by the owner name (i.e. "laserlight doran zemlja"), a special alias (i.e. "my alias"), or a special seven symbol address.
See "Stargate Aliases" below for a more detailed explanation of Stargate aliases.
The special alias "random" will select a random Stargate.
Stargates listen to both channel 0 (the public channel) and channel 123 (for compatability with other Stargate networks).
A complete list of Stargates can be found at http://ma8p.com/~opengate/list.cgi
As an alternative to voice commands, Stargates will also respond to commands from the symbol based DHDs. Stargate addresses can be entered via DHD. A one prim sculpted symbol based reference DHD is part of the standard distribution, and can be found near many Stargates.
Once the Stargate dials, the Event Horizon (blue swirly thing) will appear. Click it and a map will appear. Click the "teleport" button on the map, and you will teleport to your chosen destination.
Touch the Stargate and select the "Automap". The Stargate will vend you an automap object. If you wear the automap object, the map will appear automatically when you collide with (walk through) the event horizon. This saves you a click, and makes the action a bit more realistic. You still need to click the "teleport" button on the map.
Several people have asked why the automap is necessary, and why we can't just have "walk-through" teleports. This is an SL limitation. See http://jira.secondlife.com/browse/SVC-212 for a full history on this subject. Many people have pointed out that the Quantum Gate stargates have walk through teleport. Strictly speaking, this is not true. To activate a quantum portal stargate, you need to touch the Stargate. The touch handler delays until a collision is detected by a second script. Only the person who originally touched the Stargate gets the "walk through teleport". Others in the area must still touch the event horizon. This solution is clunky, and causes new users quite a bit of confusion. Rather than implement a broken and confusing solution like this, the Astria Porta Open Stargate Network encourages you to use the automap object, and vote for SVC-212.
@tpto support; Some viewers (Restrained Life, Cool, and possibly others) have a feature which DOES allow forced teleports. As of v210, the automap object will detect this feature and use it if it is available.
Push feature; Inspired by scenes in the show where characters appear to be "pushed" out of the wormhole on arrival, one resident suggested we add this feature. This feature is OFF by default. To enable it, detach your automap, right click it in your inventory, select "properties" and add "{push}" to the description. Now wear it again. Push enabled automaps will give you a gentle push out the wormhole when you arrive, if you arrive close to the Stargate and if the land you arrive on allows it.
Radio feature; As of v209, the automap object also acts as a radio. If you have an older automap, you will need to get a new one from a v209 or later Stargate for this feature to work. The default radio channel is 7, and can be changed via the {radio:} setting in the automap object description. If you speak on the radio channel (i.e. type /7 hello in the chat bar), all others with automap objects set to the same channel will hear you. This will even work through open wormholes on v209 and later Stargates.
The symbol addresses use unicode characters in the range U+263C through U+2653. Some users may have trouble with these characters. If your SL Viewer displays these as question marks or small boxes, there is a problem with the fonts. Note that this is a Viewer problem, and NOT an LSL problem.
If you have problem seeing fonts, try the following:
In all likelyhood, you are missing one or more of these fonts, or have old versions of these fonts. There are four possible ways to fix this problem.
Like the viewer, some web browsers may have problems with the characters used for symbols in the http://ma8p.com/~opengate/list.cgi . Solutions for this will vary by browser and are out of scope for this document, but in general:
Go to secondlife://Sentry/136/119/119 to get your free mod/ copy/ transfer reference Stargate. You can also get one from slexchange.com ( http://www.slexchange.com/modules.php?name=Marketplace&SearchKeyword=opengate ). This is a minimalist single prim Stargate. It's intended for you to take apart and examine and base your own Stargate design on, or to use as-is if you want an ultra low prim count Stargate.
Your Open Stargate will be one small part of a network of Stargates. Modifications to your Stargate which cause problems with the network and other users' enjoyment of the system will result in your gate being deleted without warning.
Aliases are set by adding them to the name field of the object, in square brackets.
A complete list of Stargates and Stargate aliases can be found at http://ma8p.com/~opengate/list.cgi
When dialing, a case insensitive match is done on the following:
Matches are done in the order shown. i.e. if there is a Stargate in the region named "Gamma" and there is also a Stargate with an alias of "Gamma", dialing Gamma will ALWAYS get you the Stargate in the region named Gamma.
If there are multiple matches at the same level then one of them is chosen at random. i.e. if there are two Stargates in the region Gamma, dialing Gamma will give you one or the other at random. However, to speed lookups, once a Stargate gets a match, it will remember that match until some other Stargate is dialed. i.e. the first dial to Gamma will be a random gate in Gamma, but subsequent dials from that same gate will go to the same destination in Gamma, until some other address is dialed.
Stargates may have multiple aliases. An alias appears in square brackets in the Stargate object name. i.e. If you name your object "OpenGate [prime] [my alias]" it's aliases will be "prime" and "my alias".
The special symbols used for Stargate addresses can also be used as part of an alias. Since SL does not allow special symbols in object names, escape sequences are required. The sequences \A through \Z, \0 through \9, and \. and \- are used to substitute for the special symbols.
As a shorthand, an alias beginning with a ~ is assumed to be all symbols, so the alias [\A\B\C] is the same as [~ABC].
Aliases with unicode characters can also be created by using u+XXXX to represent a unicode code point. For example, [u+661fu+9580] would be the Chinese Traditional alias for "Star Gate".
Note that while it is possible to set an alias with repeating symbols, the DHD cannot dial it. Also note that normal Stargate addresses are searched first, so an alias cannot be used to hijack another Stargate's address.
Please do not copy a gate, or rez multiple copies of gates, for the sole purpose of getting a specific gate address. The odds of getting a specific gate address by copying gates is about 1 in 20 million. It is futile. The best way to get your gate to respond to an old address is to use a special symbol alias, as described above.
The name random is special, and selects a random Stargate.
The names prev, next, and redial are also special. The first two dial the previous and next Stargates in the chord network, respectively. The third redials the last successful regular dial.
A Stargate will never dial itself.
Flags are set by adding them to the description field of the object. All flags are case sensitive (must be lower case) and must include the opening and closing curly braces.
If you absolutely must place your Stargate in an area not open to everyone, please add the string "{norandom}" to the Stargate description. This flag will prevent your Stargate from being used when travelers "/dial random".
Please note that unless you add the {norandom} flag to your Stargate, travelers may arrive at your Stargate randomly and uninvited. Please do not be angry with them. If you do not want random visitors, set the {norandom} flag on your Stargate.
Ditto for the various "security orbs" available. If you're using a security orb to eject random visitors, please also set the {norandom} flag on your Stargate.
Double ditto for the various role play combat systems out there. Random travelers will have no clue they've wandered into a role play sim, and are fairly unlikely to have ever heard of whatever combat system you're into. If your estate/region/parcel has strict roleplay or combat system requirements, please save potential visitors the hassle and set the {norandom} flag on your Stargate.
Note the {norandom} flag ONLY affects travellers who use "/dial random". The Astria Porta Open Stargate Network does not implement any access restrictions for travellers dialing by name, address, or alias.
This flag acts identically to the {norandom} flag.
The Stargate will set this flag automatically if your parcel has restricted access (i.e. "ban lines"). This is done so that gate travellers dialing randomly will not be sent to restricted parcels.
Setting this flag manually does NOT alter the access restrictions on your parcel. Use the "About Land" / "Access" tab to alter your parcel's access settings.
If there are multiple gates in a region, {default} gates are given priority when dialing that region.
Specifies the facing rotation for the gate. May be one of "north", "south", "east", "west" "northeast", "northwest", "southeast", "southwest", or their abbreviations ("n", "s", "e", "w", "ne", "nw", "se", "sw"), or an integer number of degrees (0=east, 90=north, 180=west, 270=south). This is used to keep the rotation correct when switching PHYS.
The chevrons are implemented as temp-on-rez objects. If you're very sensitive to server lag, you may opt to disable them. To disable the temp-on-rez chevrons, add the string "{nochevrons}" to the Stargate description. After setting or removing this flag, it may take up to 1 minute for the chevrons to disappear or reappear.
If you can spare the prims, you may wish to transform your Stargate to one of the higher prim models. See "Stargate Physical Model" below for more details. When using the multiprim models, the chevrons are real (not temp-on-rez) objects, and the {nochevrons} flag has no effect.
This flag produces slightly more verbose output during dialing.
FOR DEBUGGING USE ONLY. DO NOT SET THIS FLAG ON YOUR STARGATE.
Enables debugging output. This is probably only useful if you are debugging a serious problem.
Specifies the physical model being used. (See below.)
Specifies the theme being used. (See below.)
Specifies the channel settings used for compatability with some Alteran Stargate Network products. Valid values are "milkyway", "pegasus", "opengate", or a base channel number. The Stargate will listen on the base channel number, and reply on base - 1000. The base numbers used for milkyway, pegasus, and opengate are -904000, -804000, and -704000, respectively.
To use a channel other than base - 1000 for reply, use two numbers seperated by a comma. For example, compatability with old arcturus milkyway DHDs can be acheived with {altcompat:-8765,-87654}
If altcompat is not set, the theme setting is used to derive the base channel number. If the theme is not "milkyway" or "pegasus", then the "opengate" base channel of -704000 is used.
These flags are set automatically by the Stargate when an error condition is encountered.
THE CANCREATE FLAG HAS BEEN DEPRECATED.
The OpenGate object must have object create permission on the parcel where it is located. If it does not have object create permissions, temp-on-rez chevrons will not appear, and more importantly, it will not be able to rez incoming or outgoing wormholes. Lack of object create permission also interferes with the automatic updates and script error recovery functions.
The Stargate will attempt to determine if it has such permission, and notify you if there is a problem. You can confirm the problem by going to the Stargate and attempting to dial out. If you get the "Opening to" message, but no event horizon appears, then the Stargate does not have object create permission.
In many cases, the problem can be fixed by changing the group of the Stargate to match the group of the parcel. Deeding the Stargate to the group is NOT recommended.
Stargates support multiple physical models, also known as "PHYS". This allows you to change the look of your Stargate.
From the "Admin" menu, select "core/ops" and "PHYS". Multiple physical models are available. Note transforming between models may take several minutes, and may be error prone if the parcel does not have enough prims to support the model.
Some models (oneprim, eleven) may also have their own dialog menus for model specific settings (i.e. theme). Be sure to check the Admin menu again after changing PHYS.
Some models (supergate) use megaprims. Linden Labs discourages the use of megaprims. Use this model at your own risk.
The oneprim PHYS uses temp-on-rez chevrons and dialing ring. This is good for very small plots, or where prim count is a concern.
The eleven PHYS does not use temp-on-rez for chevrons or dialing ring. This is good where lag is a concern.
All PHYS still use a temp-on-rez Event Horizon.
Resident Marcus Gray maintains an image gallery of the various PHYS/theme combinations at http://picasaweb.google.com/Marcus.Himmel/OpenGate
The two classic PHYS (oneprim and eleven) support a number of themes (texture sets, sounds, and associated objects) that allow you to change the look of the Stargate. To change the theme, touch your stargate, select "Admin","phys/" from the menu, and select the theme you want.
When changing themes, it may take up to two minutes for the chevrons to change.
Themes are contained in notecards inside the Stargate named "@theme:whatever" or ".theme:whatever".
When you select a theme, the textures/sounds/etc referenced by the theme notecard are used to change the appearance of your Stargate. If subsequent software updates change the contents of the notecard, your Stargate will change appearance to match the new updates.
Themes named "@theme:whatever" will be removed during the automatic update process. Changes to these notecards will be lost during an update.
Themes named ".theme:whatever" will NOT be removed during the automatic update process. You can use this to set the theme of your Stargate and prevent it from being overwritten by future updates.
A theme notecard consists of a list of setting value pairs, one per line.
Since reading notecards is relatively slow, and the settings are generally self explanatory, there is no provision for comments in the theme notecards.
The following settings are recognized by the theme reader. Settings in the theme notecard may appear in any order. Unrecognized settings are ignored.
| name | type | description |
|---|---|---|
| back | key | texture used on back of Stargate |
| bigchevron_lit | key | texture for lit top chevron |
| bigchevron_unlit | key | texture for unlit top chevron |
| bumpshiny | string | bump shiny setting (comma seperated) (see below) |
| chevron_lit | key | texture for lit non-top chevron |
| chevron_ring | string | sculpted or flat |
| chevron_rot | vector | euler degree rotation of topmost chevron when ring is in <0,0,0> rotation |
| chevron_sculpt | key | sculpt map used for chevrons |
| chevron_size | vector | size of chevron prims |
| chevron_unlit | key | texture for unlit non-top chevrons |
| collapse_texture | key | particle texture for collapsing wormhole |
| coloralpha | rotation | <red, green, blue, alpha> setting |
| dhd | key | texture used for dhd |
| edge_inner | key | texture used on inner edge of Stargate |
| edge_outer | key | texture used on outer edge of Stargate |
| event_horizon | string | hollowsphere or 36frame |
| fail_sound | key | sound used for failed dials |
| front | key | texture used on front face of Stargate |
| fullbright | integer | 1 for fullbright on or 0 for off |
| glow | float | glow setting |
| horizon | key | texture used for event horizon |
| horizon_animation | string | parameters passed to llSetTextureAnim |
| hsoow_sound | key | sound used for collapsing wormhole |
| lock_sound | key | sound used for chevron locking |
| loop_sound | key | sound used while wormhole is open |
| material | string | stone, metal, glass, wood, flesh, plastic, or rubber |
| params | string | settings passed to llSetPrimitiveParams (deprecated) |
| ring | key | texture used on dialing ring |
| ring_static | key | texture used on multiprim dialing ring when not moving |
| splash | key | sound used for avatar colliding with wormhole |
| texgen | string | default or planar |
| woosh | key | particle texture for opening kawoosh |
| woosh_sound | key | sound used for wormhole opening |
Allowed bump settings: none bright dark wood bark bricks checker concrete tile stone disks gravel blobs siding largetile stucco suction weave
Allowed shiny settings: none low medium high
It's always annoying to walk through a Stargate and come out somewhere random, far away from any visible Stargate. Sort of breaks the mood, you know?
Please, as a courtesy to other Stargate travelers, do not place your Stargates on land with restricted access ("about land" / "access" should not have any check boxes selected), or with a teleport routing away from the Stargate ("about land" / "options" / "teleport routing" should say "anywhere"). Alternately, you can set "teleport routing" to "landing point", and place the Stargate at the landing point. If you wish to have a seperate landing point from the Stargate, you might consider splitting off the 4x4 m^2 section containing the Stargate ("edit terrain", "subdivide").
Also, if placing your Stargate in a private region, make sure region permissions are set to allow people to teleport to the region.
Whenever possible, prefer using the metaupdater object to update existing Stargates instead of rezzing a new Stargate and deleting the old one. Every time a Stargate joins or leaves the chord network, a ripple of increased activity spreads across the network. Using the metaupdater object for existing Stargates is MUCH more efficient.
The Stargate MUST have permission to create objects. Generally this means the Stargate owner or Stargate's group must have create permission. You can see these permissions in "About Land" on the "Options" tab. Without object create permission, the Stargate cannot rez the event horizon or temp chevrons. (see also {cancrate} flag)
Please do NOT deed the Stargate object to a group. Deeding an object to a group changes the owner of the object to the group. This is a much more complex change than simply setting the object's group, and introduces several problems. If there is an issue with the Stargate, we won't know who to contact to resolve the issue. Usually when someone does this they are trying to resolve an object create permission problem on group owned land. These sorts of problems can be overcome simply by setting the group of the Stargate and allowing group create on the land. Alternately, group settings can be used to allow specific users to override normal object create permissions on the group owned land. Deeding to a group is almost never necessary.
Please do NOT set the "Locked" checkbox on your Stargate. Setting the "Locked" checkbox interferes with the automatic update process. It also interferes with the automatic script error recovery process. In the "Edit" window, on the "Object" tab, make sure the "Locked" checkbox is NOT checked. Since they cannot be updated, Stagates that are "Locked" may be deleted without notice if they cause problems in the network.
Please do not put objects inside, over, or around the Stargate, even transparent ones. Many users have tried to place transparent visitor counters or other semitransparent scenery objects inside, over, or around the Stargate for various reasons. Such objects interfere with Stargate traveler's ability to touch the Event Horizon when it appears, even when those objects are transparent. When they attempt to touch the Event Horizon, they will touch your object instead. They will not see a map and will not be able to teleport. This is normal SL behavior, and NOT a bug in the Astria Porta Open Stargate code.
Please do not use "temp-on-rezzer" or other "zero prim" or "prim expander" objects with your Stargate. Your Stargate will not work with these objects. You won't be able to dial out reliably, and no one will be able to dial in.
Due to SL server bugs, travelers will currently always arrive facing East. If at all possible, place your Stargate facing east to minimize confusion to travelers. The code DOES properly set the look_at parameter to llMapDestination(), but current SL servers ignore it.
Stargates on highly loaded regions do not respond to messages from the
chord network in a timely manner, and will negatively impact ALL Stargates
in the network. Rather than let the entire network become unusable,
the Stargate on a highly loaded region will partially disconnect from
the network temporarily. Stargates may still dial out, and receive
incoming wormholes when partially connected, but will not participate
in normal network maintainance messaging. It will reconnect to
the network once server load has returned to acceptable levels.
Most users will not notice that a Stargate is partially disconnected.
Stargates on loaded regions with partial connections will exhibit
increased delays between dialing command, address resolution, and
wormhole creation. If you have this problem consistently, please see
https://secondlife.com/community/support.php?questionID=4780
as well as
https://secondlife.com/community/support.php?questionID=4235
The seven symbol Stargate address is based on a hash of the Stargate object's key. Since the key changes when rezzing an object, if you take a Stargate into your inventory and then rez the Stargate somewhere else, the seven symbol address will change. Most owners will likely not care about the Stargate address changing during a move. If for some reason you want to maintain the Stargate address, it is necessary to maintain the Stargate object key. You can do this by attaching the Stargate to your avatar, moving to a new location, and then dropping the Stargate. (see also "Gate Aliases")
The Stargate object's name must start with "OpenGate", and must contain only that string followed by any user defined alias in square brackets.
The description may contain only flags and theme settings in curly brackets.
These restrictions are enforced by the software. Any attempts to override them by changing the software will result in your gate being deleted without notice.
The Stargate uses http_in for communication (technical details appear at the end of this document). This method allots a certain number of URLs per parcel, the same as the prim limit. If you see this error, some other object on your parcel is consuming URLs and not releasing them. We know it is NOT the Stargate, because we have several dozen gates on 4m^2 parcels (3 prim/URL limit!) that do NOT exhibit this problem. If you see this error, your best bet is to locate the offending object and delete it. Another possible solution is to restart the region.
Updates are distributed via group notices to the "opengate" group. Updates are released frequently, occasionally multiple times per day.
All updates or cumulative. If you fall behind and want to catch up, just apply the highest numbered update and things should be fine.
Because people (understandably) may not want to keep their Stargates completely up to date, we have developed a ranking system for updates. Update ranking can help you decide whether or not you want to apply an update. There are four update ranks, as described below.
DO NOT apply old updates to "downgrade" your gate. Doing this may cause problems with the network. If you discover some problem that is "fixed" by downgrading, please report the problem immediately so it can be fixed in future releases. If we don't know about the problem, we can't fix it, and while downgrading may seem to fix the problem now, eventually your gate will become incompatable with the current code. Occasionally we will update gates to fix network problems. Users who repeatedly downgrade their gates will find them deleted without warning.
Some people have asked if it is possible to set up a prvate network of Stargates seperate from the main gate network. A private network cannot dial into the main network, nor can the main network dial into the private network.
When a Stargate is rezzed in world, it immediately tries to connect to other gates by UUID as listed in the $core/SEEDS or .core/SEEDS notecards. To create a private network, we need to make sure that the gates in that private network only ever try to connect to other private network gates. This is a little tricky, because if a private gate ever contacts a gate in the main network, the two networks will merge together, which is not what we want. Here's how it's done.
From the Open Stargate Network distribution box, rez an OpenGate Blank object. Now right click and "Edit" the object. Go to the "Contents" tab and create a "New Script". Right click and open the script, replace the code with that shown below, and "Save".
default {
state_entry() {
llSay(0, (string)llGetKey());
}
}
The Blank will say it's UUID. You'll need this in a minute, so copy and paste it somewhere safe.
In an inventory window, create a New Note, and name it ".core/SEEDS". Inside that note, place the UUID of the Blank. Save the note, then drag it into the contents of the Blank.
Now stand nearby and wear the metaupdater. It should update the Blank object. Your new gate will use the contents of .core/SEEDS instead of $core/SEEDS when acquiring the network. This is the "first gate" in your network. Take a copy of it and use it to rez new gates in your network.
Do not delete the first gate. If you ever do, then new private gates will not be able to join your private network. You can make things more robust by adding all of your private gate UUIDs to the .core/SEEDS file.
A "bug" is any situation where a Stargate, DHD, automap, or address display fails to operate in the manner described in this manual. Anything that does not fit this description (like that cool new idea you just had) is a "feature request".
To report a "bug", create a notecard named "Stargate Bug Report" and give it to Doran Zemlja. Whenever possible, bug reports should include a complete list of "steps to reproduce" as well as "expected results" and "actual results" for those steps. This will greatly speed up the debugging process.
To file a "feature request", create a notecard named "Stargate Feature Request" and give it to Doran Zemlja. Like bug reports, please inclue "steps", "actual results", and "desired results".
Properly named notecards will receive priority over all other requests.
The code (LSL and perl scripts) is licensed under the GPL. Please read and understand the license agreement. The GPL is designed to make sure that the code remains free for everyone to use.
When I first logged in to Second Life, one of the first things I stumbled across was a Stargate. I thought they were the neatest things. When it came time for me to learn LSL, I decided I wanted to script one, as a learning exercise.
It only took me a few days, and I came up with something which, while not artistically accurate, worked just as well as the Stargates I had stumbled across my first day in Second Life.
I was excited. I wanted to show off what I'd done. I hunted down Wes Keynes. I hunted down Reyo Neutra. I was such a newb.
I learned several things. There was not just one, or two, or three, but four separate and noninteroperating Stargate networks. While two of the networks were working on interconnecting, mine was a fifth, and nobody wanted to see that.
I also learned that Second Life was not an "Open Source" community. It seemed as if many people were infected with the "greed meme", and thought they could sell their objects for fun and profit.
Not only did nobody want to look at my code, nobody wanted to show me theirs.
This bothered me.
Over time, I also learned that each of the different networks was tied its own central server, coordinating that network's stargates. If that server goes down, all the Stargates on that network stop functioning.
This also bothered me.
As I write this, it seems some of the networks have disappeared altogether, and with them some fairly stunningly beautiful Stargates. I particularly miss the Elven Moor Stargate, and I've had a rough time finding another like it.
This also bothers me.
It seems that, as long as a single server controls the network, there is a tendency towards instability. That server may go down, or the person operating it may lose interest in maintaining it.
Of course, there's only one thing for it. A decentralized open source Stargate network. As long as there is not any single point of failure, and the code is freely available, the Stargate network should remain stable and usable by all.
Note that this is a "clean room" implementation; I've never actually seen any code for any other stargate network. Please see the note in automap.lsl regarding "clean room" development.
These web pages are interviews and news articles posted by folks outside of the development team.
http://blog.iliveisl.com/stargates-sculpties-isl/
These web pages may help shed light on the history behind having multiple Stargate systems. It is my fond wish and hope that the availability of an open source alternative will eventually cause these competing systems to freely interoperate.
Alteran [Zachary Carter]
Cleary [Wes Keynes, Lobos Cranes]
Ancient Stargate Alliance (formerly Open Source Stargate Server) [Joran Yoshikawa, cyber Ahn, Paul Gazov]
Arcturus [Zachary Carter, Peter Lameth, Kegan Loon]
Prometheus [Mintopia Ambassador]
Quantum Gate Stargate [Darling Brody]
Stargate Network Teleporter [Chianna Nozaki]
Iconian Gateway [Peter Lameth]
These web pages are about the stargate device in the Stargate Movie and TV shows: http://www.rdanderson.com/stargate/glyphs/glyphs.htm http://en.wikipedia.org/wiki/Stargate_%28device%29 http://www.joysgate.com/stargate_sg1/sg1_graphic_art.htm
MUST HAVE:
NICE TO HAVE:
When first starting up, the Stargate uses llRequestURL to get a URL for incoming http connections.
It then uses the contents of the $core/SEEDS or .core/SEEDS notecard to get a random UUID of another Stargate.
It then uses llEmail to contact the other Stargate and advertise its URL.
From then on out, all communication from Stargate to Stargate is through llHTTPRequest(), http_request, and http_response.
The Stargate network uses a variation of a distributed hash table algorithm known as "chord" to perform the function of resolving Stargate addresses to object UUID (see http://pdos.csail.mit.edu/papers/chord:sigcomm01/ ). This algorithm is designed to distribute information amoung a set of connected peers.
To join the network, a new Stargate uses a static list of Stargates contained in the "seeds" note card. If a Stargate drops out of the chord network for any reason, a random entry in the seeds list is chosen to reinitiate contact with the chord network. If this contact fails, another random entry is chosen.
On startup and every three minutes thereafter, register.lsl generates a series of hash values for the various names it wants to register (i.e. "region", "region ownerfirst ownerlast", "alias", etc..) It then sends these to a connected peer as specified in the chord algorithm.
Registered names are dropped from the hash table after a specific period of time (currently about half an hour).
A typical dialing sequence proceeds as follows:
The web interface is updated using HTTP.
This is handled by "web.lsl" in the Stargate objects. On startup and periodically thereafter, this script notifies the Web Server (via ping.cgi) of it's existence via HTTP.
The failure of a Web Server will not at all impact the in world function of the Stargates in the network.
This is accomplished via a number of perl CGI scripts which can be hosted by any number of web server architectures. We currently use Apache.
Web.lsl periodically contacts ping.cgi to update the Web Server with its current status.
Logger.lsl periodically contacts log.cgi with loggable events.
User interface is through list.cgi and xml.cgi
Every Stargate has an "address" which consists of seven astrological symbols. This is simply a hash of the Stargate object's key.
The parser.lsl also listens on channels 123 and 34353 for commands. dhd.lsl simply says a dial command on this channel to begin the dialing process.
I haven't bothered with it yet. I'm not convinced this sort of feature would actually see much use.
A Grid is an entity used to seperate sets of Stargates. Stargate dialing from one Grid (including dialing "random") will only return results within the same Grid.
Web Servers recognize the difference between the Teen Grid and the Main Grid. The code should work equally well on both. The list available in the web interface will show Stargates on both Grids, but with different icons.
The Astria Porta Open Stargate Project is currently looking for someone with a valid Teen Grid account to evangelize the project on the Teen Grid, maintain Stargates, establish vendors, etc...
Additionally, external Stargate networks may be given their own virtual Grid. It is possible to dial from the Astria Porta Open Stargate Network to these other grids, but a return trip might not be possible (depending on the Grid). Currently only the Alteran network will allow dials back to the Astria Porta Open Stargate Network.
The following virtual grids are currently active: alteran, cleary
The following Stargate networks do not make their Stargate database public, and are therefore not supported: arcturus, iconian, quantum portal. If anyone involved with these networks knows how to get a list of Stargates with locations, please contact Doran Zemlja.
To dial out of Grid, say "/dial >gridname alias". For example, "/dial >cleary aslan" will open a wormhole to a Stargate in the Aslan region on the Cleary Stargate Network.
It is NOT possible to dial from the main grid to the teen grid. This is a purposeful limitation imposed by Linden Labs and there is no way around it.
The various open source simulator efforts are not currently supported; They do not have sufficient LSL support to run the Astria Porta Open Stargate Network code. (See "OpenSim, OpenLife, OGP, and HyperGrid", below)
Icons (32x32 .PNG files) distributed with the server are part of the Tango Icon Library ( http://tango.freedesktop.org/Tango_Icon_Library ) and are licensed under the Creative Commons Attribution-ShareAlike license ( http://creativecommons.org/licenses/by-sa/2.5/ ).
The stargate graphics ( Stargate.gif and blackring.gif / bmp ) are from the Wikimedia Commons ( http://commons.wikimedia.org/wiki/Image:Milky_way_stargate_with_very_detailed_glyphs2.svg ) and are licensed under the GNU Free Documentation License ( http://en.wikipedia.org/wiki/GNU_Free_Documentation_License ).
The various in world textures were donated to the project by Micheil Merlin, Doran Zemlja, and Dargo Fetid, Crysti Thor.
People who've looked at the source code in-world have noticed that is pretty much unreadable. The first question I'm asked is "why the obfuscated code?"
I'm trying to kill several birds with one stone here.
During development of the first Stargate network, I would often succumb to the temptation of modifying the code in world to fix bugs. The result was that the online tarball would become out of sync with what was actually in use, and I lost much time scratching my head over which version was correct.
Obfuscating the in world code forces me to do development out of world.
There is a fair amount of shared code between the different scripts. On several occasions I found that I had different versions of key algorithms in different scripts, and this caused many headaches. To avoid this, I wanted to use C/C++ style #includes and #define macros, and that necessitated moving to a development platform with real development tools.
To some degree, obfuscated code is a natural result of using #include and #define macros.
Often people would make changes on their objects and submit them back to me for inclusion in the project. Such code had often gone through several iterations of copying and pasting in different tools, and it was often difficult to get a clean diff to figure out what had changed.
Obfuscating the in world code should help reduce this problem. I will no longer accept contributions that do not diff cleanly against the code in the distribution.
Many well meaning people who used the objects in world took them apart, picked a single script, and found their favorite nit to pick in the name of readability, efficiency, reduced memory, or reduced lag, and "fixed" them. They often did this without understanding the complete design, especially without understanding how the different scripts interoperated with each other, how the different objects interacted within a single Stargate, or how the individual Stargates interacted with each other in the Stargate network as a whole. On a few occasions this led to disruptions of the Stargate network. Now that the distributed chord algorithm is in use, these problems are magnified.
Obfuscating the in world code increases the level of effort required to make changes, and should reduce the number of frivilous unconsidered changes.
The raw, unobfuscated source code is available as part of the distribution (see the link at the beginning of this document).
You will need some sort of Unix environment. I use Linux ( http://www.linux.org/ ). Cygwin ( http://www.cygwin.com/ ) on Windows will work just as well.
Your environment must have "perl", "make", "gcc", and "lynx" installed. While the Makefile doesn't actually use gcc, it does use cpp (the standard C preprocessor), part of all gcc installations. If you want to build the html version of the documentation, you will also need "txt2html" installed.
Your environment MUST support UTF8. The Makefiles produce .o files which contain UTF8 text.
It's that easy. The Makefile will build and populate the open2/bin directory. Look there for your compiled lsl scripts.
No. They won't compile, you'll have a ton of undefined symbols. Some of them, like the menu.msl file, aren't even LSL.
Your Open Stargate will be one small part of a network of Stargates. Modifications to your Stargate which cause problems with the network and other users' enjoyment of the system will result in your gate being deleted without warning.
Please conduct all tests responsibly, in an isolated manner that does not interfere with the rest of the network.
There is a common misconception that "OpenGate causes lag". Most users have a poor perception of "lag", partly because Second Life does not have any good tools for measuring lag, and partly because the users do not have a clear idea of what actually causes lag. Users who notice performance problems will look at an OpenGate object, see four dozen scripts, and immediately jump to the conclusion that this is the sole cause of all their woes.
This couldn't be further from the truth.
There are two types of "lag" we can talk about.
"Client" or "Viewer" lag occurs on the end user's personal computer. This can be caused by a number of variables, such as the video card type and the network bandwidth. Since these things are mostly out of our control, there's not much we can do about them.
"Server" or "Simulator" lag occurs on machines hosted by Linden Labs. Script behavior does have an impact here, and this is within our control. Server lag occurs when the resources of the server become overtaxed, causing frame rate to drop.
Linden Labs provides two tools for measuring script impact on frame rate. The first is the "Statistics Bar" as described in http://wiki.secondlife.com/wiki/Statistics_Bar_Guide and the second is the estate manager tools "Top Scripts" as described in http://wiki.secondlife.com/wiki/Region_Performance_Improvement_Guide . If you haven't had the time to read these documents, we STRONGLY urge you to do so, as the rest of this section references them frequenty.
Ideally, we'd like to use the estate manager's "Top Scripts" tool to look at performance. Indeed, in the past, we have worked with various estate managers to fine tune scripts, but this contact is sporadic. Since we're not rich, and don't own an estate, we don't have access to these tools on a day to day basis. We'd like a methodology that quantifies our effect on server frame rate, in a way that anyone can confirm and verify.
So let's look at the Statistics Bar. The important thing to note is the "total frame time" and the "script time". The "total frame time" is the amount of time it takes the server to do everything it needs to do during each frame. On an unloaded simulator, this is 44 frames per second, or 22.2ms per frame. When the total time exceeds that, the frame rate will start to drop.
Another important thing to note is that number of "active scripts". This is the total number of running scripts on the simulator. On most simulators on the mainland, this number is in the thousands. How do we get the statistics bar to show us only the details about our objects? At first glance this does not seem possible.
We have developed the following testing methodology. It is designed to measure the impact of a single object on "script time".
This method will give you isolated data about your object and its impact on server frame rate.
We did this for three objects. We're currently using this data to improve our performance. We chose a current release OpenGate, a future release OpenGate, and a current Alteran Stargate. Here's what we found.
| Object | script time min/avg/max |
|---|---|
| OpenGate v231 | 0.2ms / 0.3ms / 0.8ms |
| OpenGate v300 | 0.1ms / 0.1ms / 0.6ms |
| Alteran Tollan 1.1.3 | 0.1ms / 0.1ms / 0.9ms |
Note that ALL of these numbers are substantially lower than the 22.2ms required for full frame rate operation.
Conclusion? The current release of OpenGate does not cause an excessive amount of server load compared to other objects. Armed with this new testing methodology, the next release version will cause even less load.
Boy do I wish I could channel the raw enthusiasm I see for this into the OpenSim project.
The more correct question to ask here is "Does OpenSim currently support enough LSL functionality to run the Astria Porta Open Stargate Network code?"
At this time, the answer is unfortunately "no".
According to http://opensimulator.org/wiki/Download , "As OpenSim is still at an alpha code maturity stage, there is absolutely no guarantee that functionality works or is stable, even in the numbered releases."
The Astria Porta Open Stargate Network relies on a large number of features available on the Linden Main Grid which simply aren't implemented yet in OpenSim.
I have spent about a week attempting to port the code to OpenSim. To that end, I have contributed a number of patches to the OpenSim project.
Sadly, I have realized that what I consider to be a logical goal for OpenSim (100% LSL compatability) is not one of their actual goals. I find this attitude frustrating and difficult to work with. Patches I've submitted to OpenSim have been met with a great deal of "Not Invented Here" combined with a lack of appreciation for the "Principle of least astonishment". I could rant on, but the short story is that OpenSim's LSL implementation is laughably broken, and will not likely improve for some time. (See http://opensimulator.org/mantis bugs 3199, 3187, 3144, 3174, 3201, 3176, 3145, 3157, 3152, and 3143) (In particular, see http://opensimulator.org/mantis/view.php?id=3187 and http://opensimulator.org/mantis/view.php?id=3144 for an example of what I'm talking about)
As of v205, the code should at least compile in OpenSim. I have removed reliance on several SecondLife LSL features not currently supported in OpenSim. However, since I am not actively maintaining this, there is no guarantee that they will not creep back in.
Actual support for OpenSim would require another experienced C# developer to fix OpenSim's horribly broken LSL implementation. I have neither the time nor the patience to deal with the OpenSim development team any further.
At minimum, OpenSim should support llEmail, llRequestURL, and and http_request. The methods are critical for intersim object communications. The documentation currently says it supports these things, but if you look more closely, you will find that their implementation is incomplete and nonfunctional for the purposes of allowing objects in different sims to communicate with each other.
I am, as always, willing to accept patches that work around OpenSim's limitiations if they do not impair the functionality of the code on the main grid. To date, no one other than me has submitted any such patches.
Yes, but don't get too excited just yet.
The same code that allows dials to other networks (/dial >alteran, etc...) could in theory also work with OGP or Hypergrid regions. However, since no grid besides the Linden main grid supports LSL, (see above) there's not much point.
I've recently learned the OpenSim Hypergrid Team has their own Stargate project. Their event horizon textures and DHD sculpt maps look familiar. I wonder where they got them from? See http://www.mariasworlds.com/2009/04/internet-history-made-today-travels-thorugh-the-stargate/ and http://opensimulator.org/wiki/HyperGrid_Team/Current_Projects/HyperGrid_Stargate for more details. While the Hypergrid team is part of OpenSim, and is therefore in theory open source, their stargate source code is not available to the public. IMs to project maintainers have gone unanswered.
