HyperGates and the HyperGrid in Layman’s Terms.
I have been experimenting with a variety of HyperGates, scripted objects that trigger a teleport around the HyperGrid.
The “Classic” HyperGate is made to look like a StarGate from the movie and TV franchise. I have always felt a little bothered by that one: sooner or later, I figure, the people who own the rights to that image are going to take notice and some sort of resolution will be found. (Anybody’s guess what that resolution will be.)
John “Pathfinder” Lester has been trying other kinds of gates, including one of my own creations, with the HyperGrid Adventurer’s Club in JokaydiaGrid. He started out with “BlamGates”, single-destination gates made to look like stone archways. You walk into the gate, and it triggers osTeleportAgent() and you are (hopefully!) sent to a region in another Grid.
The last time I was at one of the HGAC meetings, we tried my Queue-Gate, which is designed for moving a group of people from one grid to another. Everybody clicks on the Gate, and they are added to a list, or “Queue”. One by one, they are teleported to the destination. Overall the test went well, but in the end we managed to crash both Pathlandia and Permutation. That this was a successful test ought to tell you something about the status of HyperGrid Technology right now!
During the meeting, I got a lot of useful feedback. I also got a strong sense of frustration with the crashes and other problems encountered–frustration that is quite understandable! While I am not one of the HyperGrid developers (I don’t “speak” that particular programming language), I have had to learn a fair bit about the theory, and I would like to explain as best I can how HyperGates work, and why they don’t always work like we wish they would!
First, I need to dispel a common misunderstanding. The scripts inside the in-world objects do not teleport you. Scripted Objects do not do anything directly, themselves. Scripts are a list of instructions to the region server, a formal request to the region saying “Can you do this for me, please?” The region considers the request, determines if you are allowed to do that or if it is possible at all, and reacts accordingly. So, while Scripts can make a HyperGrid Teleport worse, they cannot do anything better: they are limited by what the server can do. When we Scripters are working to improve HyperGates, we are just trying to keep from making things any worse than they have to be!
The HyperGrid is a very new thing, still under construction. The only way to improve it is to stress-test it, find the bugs, and figure out ways to improve the technology! There may be other efforts underway that stress-test the HyperGrid as much as the HGAC, but I am not aware of them. 🙂 So, things are going to go “boom”, and they are going to go “boom” in new, interesting, and difficult-to-predict ways. Some of us show up just to see how it’s going to explode!
How does a HyperGrid jump work, in layman’s terms?
Let’s assume a case like what we had the other night at the HGAC meeting: 15 people or so making a jump from Pathlandia region in JokaydiaGrid to Permutation region in ReactionGrid. That is going to involve at least 19 different computers scattered around the world. In reality, it’s more than that, but we’ll stick to that figure of 19 for purposes of illustration.
Looking at the HyperGrid Protocol, we find that there are three types of computer involved: Grid-Level Service, Simulator, and Viewer.
- JokaydiaGrid: this is our starting grid.
- ReactionGrid: this is our destination grid.
- Pathlandia: this is our starting region.
- Permutation: this is our destination region.
Viewer: this is the client software we all use to connect to the Virtual World. Inventory, textures, sounds, gestures, chat, groups, everything we see and do in the virtual world is negotiated by the Viewer. Multiply this times 15!
So, when you jump from Pathlandia to Permutation, you activate the script in Pathlandia, which asks Pathlandia to teleport you to Permutation. Pathlandia hands this off to JokaydiaGrid, which negotiates with ReactionGrid. ReactionGrid accepts you, you are “logged in” to their grid and connected with Permutation. Pathlandia sends a token to Permutation. You are still getting your inventory from JokaydiaGrid, and you are downloading terrain data, textures, group information, and other stuff from ReactionGrid and Permutation.
As we have seen, when 15 people all try to do this within a few seconds, something is going to go “boom”.
As a scripter, I have been working with Jokay Wollongong and, through her, the folks at ReactionGrid to understand where the problems are, and we are trying to mitigate them. I can’t fix them! That requires developing better OpenSimulator software. I do not have either the time or the knowledge to attempt that. Instead, I have been focusing on three things:
- Improving the “User Interface”. Let’s make regular gates simple enough for my six-year-old daughter to understand and use. She regularly uses my versions of a “Blamgate” to move around within JokaydiaGrid.
- Simplifying the code for large-group events. BlamGates use collision events, which involves the physics engine. Physics is one of the big Achilles Heels of OpenSimulator right now, and adding the stress of 15 collision events to 15 HyperGrid teleports can really hurt a region–and sometimes even a whole grid. When designing for group excursions, I use a different method.
- Slowing the group down. I look forward to the day when 15, or even 30, avatars are “jumped” together from JokaydiaGrid to a new world to explore, but right now that’s just not possible. We need to give all 19 computers, and the 4 Grid and Region servers especially, time to handle all these changes. The Queue-Gate has a default spacing of 10 seconds, though we obviously haven’t found the “sweet spot” yet.
If you are one of the intrepid souls who came along on the first big Queue-Gate ride, thank you! I appreciate your faith in me, and I was listening carefully to what you said. Please continue to give me honest and constructive feedback. It really does help.
Hang in there! When I joined Second Life, the idea that I would be able to walk through a door and find myself in a different grid hadn’t really been conceived of yet. The OpenSimulator developer community, driven by dedicated volunteers who want all this to work, have come a long way in a very short time. We are pioneers, and we are still moving around in covered wagons.
The train is coming, though. Promise! We just have to lay the tracks.