In Memoriam: Tai'lahr
OpenUru.org, along with the rest of the Mystonline community, is mourning the loss of Tai'lahr on October 16th, 2019.
Rest in Peace, friend.
Linking Rules
The following information about Linking Rules was provided to me from D'Lanor. While some of this may not seem important, it actually is VERY important if you are building Ages that you plan or hope will be on a game server.
Linking Rules - What Are They?
Linking Rules are just that: Rules about the avatar when he or she links to another Age.
Most people will think that Linking is just Plasma's way of exiting one Age and loading up another. While it is true that "Linking" is simply the game engine's way of getting you from point A to point B, Uru has some very special conditions that you do not see on too many other online games.
When you play a FPS (First Person Shooter) type of game, you normally have 2 modes that you play: Offline (known also as Stand Alone or Solo) and Online (your computer is communicating with a game server and you will be interacting with other live people, also known as Multiplayer). Most of these types of games will have 2 sets of "Maps" (you can think of them as "Ages") one set is for Solo play, the other is for Multiplayer. The reason for this, is that when playing Solo, you'll have certain events (like a movie cut scene) that you don't want happening when you play Multiplayer. The Multiplayer version of the maps tend to be simply an "empty" map that has just all the objects in the map rendered.
Uru on the other hand, does NOT have multiple versions of the game "Maps" (known as "Ages"). You do not have a Solo version of Teledahn and then a Multiplayer version of Teledahn. What you have is ONE single version of Teledahn in your "dat" folder of your game.
Yes, things change in your Teledahn that you caused: The power is on, and the elevator is unlocked. The reason that the power doesn't shut down and the elevator becomes locked again when you link in another time is because of your SDL file.
The game engine uses a special file, who's extension is known as .sdl. You can find these files in the "sdl" folder of your game. And you'll notice that each Age has it's own .sdl file. The game engine looks in here to see what the state of things are suppose to be in your Age, and sets them according to what this file says. If you change something (IE you shut the power back off), the game will write this in, so that the next time you link in, the power is still shut off.
So.....what happens when you are playing MOUL: Again, and you get an invite to a friend's Teledahn? Will the power look like it's turned off to you, but on to your friend? The answer is no. If the power is on, you'll both see it, this is because, the game engine knows that you linked to your FRIEND'S Age, and not yours.
And how does the game engine know this? Why by using Linking Rules of course!
Okay, okay, So Tell Me What Each Means Already!
When you are working with Cyan's Plugin, when you've decided that a Responder's action is going to be to have the Avatar Link somewhere, you have to tell the Plugin what Linking Rule to use:
http://assets.openuru.org/wiki/andy/MaxTutPics1/linkrules.jpg
As you can see, it's the FIRST thing you have to set up for the link! (don't ask me why each rule has a small "k" in front of it's name.....maybe the programmer has his "k" key stuck with BBQ sauce......I have no idea why....).
Here is the name of each, and a brief explanation of what it is, and when you would use it:
kBasicLink
The Rule to this one is: "Does not create an 'agelink' node in 'AgesIOwnFolder' (read that as 'Ages-I-Own-Folder'). One must provide full age info to the link manager when using this linking rule or it will create a new (temporary) instance of an age."
What this means, is that if you use this Linking Rule in your Age for a Linking Book you're making to let's say, Teledahn, when the player uses it, they will not link to THEIR OWN Teledahn. They will link to a brand new instance of it, where everything is reset.
When this is used: Used for linking to "Public Instances" like the City or Hoods and Book Sharing. Also used for the Bahro Caves.
kOriginalBook
The Rule to this one is: "If the agelink node does not exist in the AgesIOwnFolder (Meaning: Does the player have this Book or page of a book on their Shelf or listed in the Nexus?) a new one will be created (Meaning it will be placed on your shelf in Relto and the Nexus. Now you know why when you use the linking book of one of the 4 "prime" ages when they are in your Relto Totem Pole, they suddenly end up on your Shelf when you link back to Relto). The player info node is placed into the AgeOwnersFolder of the age info node. When using this linking rule it is important to set the correct age info (age name, age instance name, spawnpoint name, spawnpoint title etc).
When this is used: You would normally use this for "Personal" Ages. Like if you wanted the player to link to THEIR own Teledahn.
kSubAge
The Rule to this one is: "Does not create an agelink node in AgesIOwnFolder, but creates one inside the SubAgesFolder of the age you link from."
Explanation here: A "SubAge" is an Age that is considered within another Age. A good example of this would be Eder Tsogal or Eder Delin. You can ONLY link to those Ages from a Hood, using the books provided in the Hood. Both of those Ages are considered a "SubAge" of that Hood.
When this is used: You would use this to create a link to an Age which is considered a "SubAge" of your Age.
It is VERY Important that only one age in the sub age set is accessed from the outside by another linking rule such as kOriginalBook. Multiple outside access points will result in the creation of a whole new instance of the entire sub age set.
kOwnedBook
The Rule to this one is: "Will only link a player to an Age that he or she owns (is already on their book shelf)."
If you try to use this, and the player does not already "own" the Age, the linking will simply fail.
When this is used: Let's say you want to make a link to Eder Kemo. Well you don't want the player to link there before they've solved Gira first. The player is not suppose to get to Kemo, until they've solved the puzzle of the vent covers. Using the rule will keep the player from linking to Kemo before they are suppose to get there.
kVisitBook
The Rule to this one is: "Used for ages someone is invited to by another player. The agelink node must be in the AgesICanVisitFolder and the player info node must be in the CanVisitFolder of the age. Or in other words, the player must have an invite."
When this is used: Private Links (Nexus).
kChildAgeBook
The Rule to this one is: "A parent age must be set. Creates an agelink node in the ChildAgesFolder of the parent age. Used for the GreatZero in UU. The parent age in this case is the Neighborhood and it can be set with: als.setParentAgeFilename('Neighborhood'). The player info node is NOT placed into the AgeOwnersFolder of the created age info node (so the UU server cleanup script for "unowned" ages will eventually delete it)."
I think this can be used also with the Live Server in the same way.
That's it folks. Very special thanks to D'Lanor for providing this information!
Return To: 3DS Max Plugin Tutorials
A copy of the license is included in the section entitled "GNU Free Documentation License".