3ds Max offers many new possibilities that PyPRP did not have, and it's great to see ages using them. However, at least one of them is much more complicated and troublesome than many age writers realize: Linking responders. You need to set up the linking rules they are using, within 3ds Max, and doing this right requires knowledge about how linking works internally, and how it is related to the vault. Some of that is documented, feel free to ask questions if you want to know more details.
If you are using the kOwnedBook linking rule, this should cause a new instance to be created for each player - and no fan age offers any way of sharing that link currently. However (and to make things worse), the only multiplayer environment fan ages are played in currently (Alcugs) does not implement all linking rules the same way as UU did and MOUL does: It has different rules to decide about instancing, so this issue is partially hidden, and all players getting to the age arrive in the same instance, no matter what the linking rule was. However, their vault still gets a link to that age, needlessly filling up the database. If the link is a kBasicLink, you would get a blank new instance each time, with no way of sharing - however, on Alcugs this is actually the best linking rule to use, as it leaves no traces in the vault. It is the one that Relto Shelf and Nexus use to link to fan ages. Offline, there's just one player and every linking rule is treated as kOriginalBook, so age authors don't notice.
And even worse, some ages use this to link to Cyan ages: It is really important that all links to an age use the same settings, and that a spawn point is always called the same way (we have had weird issues by links not considering this, like being unable to collect a Nexus link if you didn't already have it while linking).
You may wonder where the different between a linking responder and a link done in Python (which is what you had to use with PyPRP) is in that regard - there is none so far. However, since Python links are completely controlled by Python, I wrote some scripts that automatically redirect the linking code served by the Deep Island dataserver to go through parts of my Offline KI, that in turn uses the linking information I collect at AvailableLinks.inf (which literally was a work of months), so I am confident every link in any fan age going trough Python will either succeed and cause no issues, or show an error message and do nothing else. Other Shard admins might take similar measures. However, that is not possible for linking responders: I can edit the linking details manually, but I can not just say "I want to city, LinkInPointFerry, let the Python figure out the rest for me" (and Python uses information from the vault that's not available when the actual patching is done).
So, if you want to link to another fan age, please read Andy's tutorial about how to do linking through Python, and ask for help if needed. I would appreciate a lot if you used that one instead of the responders - and you get a proper book GUI as bonus
. It will also save your Shard admins some headaches 
. A currently usable working-around is to set the linking rule to kBasicLink, which will have no side-effects in Alcugs servers. It will not work as expected on UU Shards though, or when we get a MOUL Shard running (however, the latter will be open-source, so I think we should do something about the linking there anyway).If you want to link a Cyan age, best thing is not do do it. If you *really* want to, make sure the whole linking information is correct to the last character (I mean it!), and use Python to make it easily fixable. Even then, people playing offline will not get the fixes (unless you decide to require the Offline KI for playing, and change the script to make the link accordingly - ask me for how to do that). Really, it's not a good idea - even if the linking information is correct, it can break gameplay, like for example the link from Camp Bravo to the Cleft which allows players to get there while they are still playing the first journey, which ought to be impossible (and Cyan's scripting partially depends on that). Cyan themselves screwed those responders up in POTS as they stopped caring about multiplayer, requiring me to add tons of work-arounds. Nexus is kind of special here since most of the linking rule is ignored, so it can safely be linked to with any linking rule.
Linking is much more complicated than those innocent responder settings may make you believe, as Cyan managed to screw that whole system up totally. It's a mess of a design, but we have to deal with it, and the consequences of mistakes go beyond the scope of the usual programming errors you can make in an age: It will leave some permanent traces in the vault, not fixable by resetting a single age or similar. This does not mean you should stop to add links to other ages, but you should be careful, and know what you do.
(EDITed to fix a broken link)
EDIT (2015-07): By now, there's also a beautiful tutorial by Sirius for how to create a linking book that does safe linking.
