This file is part of the Astria Porta Open Stargate Distribution available at http://ma8p.com/~opengate/open2/open2.tar.gz
Questions / problems / miseries / pizza / beer can be sent to adam-opengate@ma8p.com
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
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.
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.
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.
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 "/d <alias>", "/sgc <alias>", "/dsgc <alias>", and "dd:<alias>". This was done as a compatability convenience for travelers who may be familiar with other Stargate networks. The "/sgc" and "/dsgc" variants dial faster than the other commands. This is done for command compatability with other Stargate networks (Arcturus, Alteran, Cleary).
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. "alpha site"), 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 help menu. One of the choices there is "automap". Click this, and 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 Portal 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:
Some roleplayers have asked for a rapid Asgard/Nox style dial. The /asgard command does this. These are rapid dials that bypass many of the Stargate's internal protocols, so they are slightly more complicated. There are two forms of this command.
Immediately opens a wormhole to the specified location. If there is a Stargate at that location, it is NOT notified. No incoming wormhole is opened.
Immediately opens a wormhole to the specified location, and notifies the Stargate with the specified UUID to open an incoming wormhole.
Go to secondlife://Laserlight/113/187/146 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.
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] [alpha site]" it's aliases will be "prime" and "alpha site".
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].
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.
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.
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 the 11 prim model. See "Stargate Prims" below for more details. When using the 11 prim model, the chevrons are real (not temp-on-rez) objects, and the {nochevrons} flag has no effect.
DO NOT SET THIS FLAG UNLESS YOU REALLY KNOW WHAT YOU ARE DOING.
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.
The Stargate will attempt to determine if it has such permission, and notify you if there is a problem. However, due to LSL limitations, there are some situations involving special permissions on group owned land where the OpenGate may not be able to tell if it has sufficient permissions. In these rare cases, your OpenGate may tell you there is a problem when no problem actually exists. If this happens to you, you can disable this check by adding the "{cancreate}" flag to your object.
Note that this only disables the check, and does not actually change anything about the way the OpenGate functions. If the Stargate really doesn't have object create permissions, setting this flag will NOT fix the problem; it will merely disable the warning.
FOR DEBUGGING USE ONLY. DO NOT SET THIS FLAG ON YOUR STARGATE.
Disables use of llRegionSay calls.
SETTING THIS FLAG WILL SERIOUSLY IMPAIR YOUR STARGATE. DON'T DO IT.
FOR DEBUGGING USE ONLY. DO NOT SET THIS FLAG ON YOUR STARGATE.
Disables use of llEmail calls.
SETTING THIS FLAG WILL SERIOUSLY IMPAIR YOUR STARGATE. DON'T DO IT.
FOR DEBUGGING USE ONLY. DO NOT SET THIS FLAG ON YOUR STARGATE.
Disables use of llHTTPRequest calls.
SETTING THIS FLAG WILL SERIOUSLY IMPAIR YOUR STARGATE. DON'T DO IT.
FOR DEBUGGING USE ONLY. DO NOT SET THIS FLAG ON YOUR STARGATE.
Enables additional memory usage statistics.
SETTING THIS FLAG WILL SERIOUSLY IMPAIR YOUR STARGATE. DON'T DO IT.
Stargates come with 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 "themes" 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". 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 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 |
| 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.
Stargates operate in one of two configurations; a single prim config and an eleven prim configuration. You can freely switch between the two by selecting "settings"/"prims"/"transform" from the dialog menu.
The single prim config uses temp-on-rez chevrons and dialing ring. This is good for very small plots, or where prim count is a concern.
The eleven prim config does not use temp-on-rez for chevrons or dialing ring. This is good where lag is a concern.
Both configs still use a temp-on-rez Event Horizon.
Whenever possible, prefer using the updater 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 updater 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.
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://support.secondlife.com/ics/support/KBAnswer.asp?questionID=4780
as well as
https://support.secondlife.com/ics/support/KBAnswer.asp?questionID=4235
(If those links don't work, try
https://secondlife.com/community/support.php?questionID=4780 and
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")
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.
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/2009/03/29/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]
Arcturus [Zachary Carter, Peter Lameth, Kegan Loon]
Prometheus [Mintopia Ambassador]
Quantum Portal Stargate [Darling Brody]
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
See also http://www.alpha-fox.com/resources/asn/history/
MUST HAVE:
NICE TO HAVE:
There are two main components to the Astria Porta Open Stargate Network. In order of importance, these are "Stargates", and "Nodes". Stargates are in world objects that organize the network and coordinate the opening of wormholes. Nodes are external HTTP servers that provide information for travelers. Strictly speaking, Nodes are not required for the actual business of opening wormholes. The network will continue to operate even if all Nodes fail.
Primary communication from Stargate to Stargate is through llEmail(), llRegionSay(), and llHTTPRequest().
Secondary communication from Stargate to Node is through llHTTPRequest().
XML-RPC communication is not used because of speed and reliability issues.
Communication is handled primarily by mailops.lsl, which uses a hook and handler architecture to include mailsend.lsl and mailrecv.lsl The use of the word "mail" in the script names is historical; earlier versions of the code used only llEmail(). The current code is much more flexible, and will chose the most efficient method available.
One of three methods is chosen for message passing, based on how much is known about the destination Stargate.
If the source Stargate knows the destination Stargate is in the same region, then llRegionSay() is used. Each Stargate listens on a channel derived from its UUID. This is the most efficient method for sending messages.
Beginning in SL server version 1.27, objects can receive and respond to inbound http requests. If the source Stargate knows the HTTP URL for the destination Stargate, and the destination Stargate is in a different region, then llHTTPRequest() is used. This is slightly less efficient than llRegionSay().
If neither of the above two methods is available, then llEmail() is used for message passing.
The mailsend.lsl script uses llMessageLinked() calls and link_message() to communicate with other scripts. The actual business of calling llEmail occurs in one of the mailfarm.lsl scripts, which are used round-robin fashion.
The mailrecv.lsl script continually calls llGetNextEmail(). When it receives one, it notifies other scripts via a link message.
The mail scripts also initiate the send of a return acknowledgement email.
The mail scripts watch for both send and receive messages. If an email is sent, but no acknowledgement is received within 15 seconds, the scripts generate a failure link message.
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 cloud for any reason, a random entry in the seeds list is chosen to reinitiate contact with the cloud. If this contact fails, another random entry is chosen.
On startup and every three minutes thereafter, cache.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 (via email) 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 provided by a Node is updated using HTTP.
This is handled by "web.lsl" in the Stargate objects. On startup and every 5 minutes thereafter, this script notifies the Node (via ping.cgi) of it's existence via HTTP.
The failure of a Node will not at all impact the in world function of the Stargates in the network.
Nodes provide an HTTP interface for the list of Stargates.
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 Node 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 listener.lsl also listens on channel 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.
Nodes have a concept of "Grid". 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.
Nodes recognize the difference between the Teen Grid and the Main Grid. The code should works 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 a TSLEmporium.com vendor, 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 me.
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)
The file open2/src/api.lsl demonstrates the minimum steps needed to resolve a Stargate name, determine the location of a Stargate, and open a wormhole to a Stargate. The implementation suffers slightly from the 20 second delay in llEmail() calls. A more sophisticated implementation would move this call to multiple seperate scripts.
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 Event Horizon wormhole and woosh textures were donated to the project by Micheil Merlin and Doran Zemlja.
The Pegasus graphics were donated to the project by Dargo Fetid.
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.
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, 3203, 3144, 3174, 3201, 3176, 3145, 3157, 3152, and 3143) (In particular, see http://opensimulator.org/mantis/view.php?id=3187 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.
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...) should also work with OGP/Hypergrid regions. However, since no grid besides the Linden main grid supports LSL, (see above) there's not much point.
