Community Nexus

[GPNMilano]

If it comes to pass that some fan ages can be instanced; will it be up to the author(s) to decide which ages are public only?

Well I certain hope so, that is authors who will decide whenever they want particular age to be public only, private only, or both.
It's all the matter of designing particular age. Most of Fan Ages don't even present any puzzles, so they might stay public without any harm to exploring them.
Some event are designed as public ages (I'm looking at You Ahra Pahts). But even then players might want to explore them without extra lag from other players.

And there are ages which just scream for ability to have private instance. I think that prime example is "DRA Officle": puzzles, story, whole design of the age. I think that because of this kind of ages "resetage" command was introduced (BTW: try to IC that), which just shows that instances i just needed sometimes.

Since I brought up the subject of Instancing let me clarify why I'm on this train of thought:

The reason that all D'ni areas (IE anything in the D'ni Cavern) should be public and not instanced, and this includes Fehnir's House, Chloe's Hood Office, the (hopefully) soon to be released Dorehn and any other Fan or Cyan created cavern location is a very simple one. If they are not public, and we instance them we are left with this scenario: If you link to an instanced version of D'ni then, theoretically, you as an explorer could travel on foot up the Great Shaft to the Cleft. Once at the Cleft you could walk to the nearest town or city. From there you could catch a plane, or catch a bus and head home. And when you get home you will find yourself face to face with an exact copy of yourself. Because you are no longer in your world, you are now in a instanced version of Earth, which is a carbon copy. Meaning that everything on Earth is also copied. Including the people. Note, this the problem with instancing D'ni. D'ni is on Earth. It is not a seperate age where you don't exist on that age. It's your home world, instancing your home world is a really bad idea.

[diafero]

Well I certain hope so, that is authors who will decide whenever they want particular age to be public only, private only, or both.

If the system works by extending the current Offline KI linking management (which btw is not tied to all the KI commands, so it could be easily ported to UU and MOUL), it will be the one who edits the config file who decides about all that. So, we would need age writers to clearly state their configuration wishes somewhere for them to be put into the config file.
Alternatively, one could extend the .age file format... but then people might use options (or change options) in away that leads to unexpected results.

And there are ages which just scream for ability to have private instance. I think that prime example is "DRA Officle": puzzles, story, whole design of the age. I think that because of this kind of ages "resetage" command was introduced (BTW: try to IC that), which just shows that instances i just needed sometimes.

I agree, and DRA was designed by someone who knows linking well enough . But for example Sonavio and The Company Nexus would need to change their linking rules to properly work as instanced age (making the Nexus a sub-age of Sonavio, so no sharing is needed). Since they both use python linking, I could even do that without touching the ages by changing some options in the config files - it's not that easy for ages created in 3ds Max and using "Linking Responders". And then fan-ages might link to fan-ages of other authors, in which instance do you arrive? This goes on and on... linking in Uru was clearly not designed well (as in, "write down what you need, think of the easiest system possible to do that, and implement it as fail-safe as possible").

On instancing - Hmm, maybe we could make it so Ages are "cleared" from the system upon leaving the instance. To explain better:
1. At the WNexus, Player A hits the "Toggle Private" button.

Oh my god, what? "Toggle private"? You are aware that the "Toggle private" button of the hood only changes the appearance of that hood in the global hood list, it got nothing to do with instancing at all. This is only decided by linking rules (or server-side hacks, in case of Alcugs, since Cyan screwed linking rules in POTS ), and then we could for example decide that Nexus always links you to your private instance. Or the public one. Or offers both.

On Nexi - Perfect! We should have three sections, one for Cyan Ages, another for Fan Ages, and a third for invites. Thus, we can create an ultimate Nexus and apply most of the concepts we have talked about!

What is this referring to, and didn't we agree that fan-ages should NOT be strictly separated from Cyan ages anymore, but e.g. all D'ni locations should be put together?

The reason that all D'ni areas (IE anything in the D'ni Cavern) should be public and not instanced, ...

I completely agree, this is another good reason.

If I understood that correctly, the WNexus does not deal with hoods or similar at all?
Seeing we are on page 15, maybe we should make some kind of writeup on the rough "architecture" (how the Nexi are separated, what gets where)?

[Egon]

So, we would need age writers to clearly state their configuration wishes somewhere for them to be put into the config file.

Yes, this is that I was having in mind.

it's not that easy for ages created in 3ds Max and using "Linking Responders".

Ough. I wasn't aware of that. I though it is just like in PyPRP: fix Python code and we ready to go.

On instancing - Hmm, maybe we could make it so Ages are "cleared" from the system upon leaving the instance. To explain better:
1. At the WNexus, Player A hits the "Toggle Private" button.

Oh my god, what? "Toggle private"? You are aware that the "Toggle private" button of the hood only changes the appearance of that hood in the global hood list, it got nothing to do with instancing at all. This is only decided by linking rules (or server-side hacks, in case of Alcugs, since Cyan screwed linking rules in POTS ), and then we could for example decide that Nexus always links you to your private instance. Or the public one. Or offers both.

Nathan was referring to my idea from previous pages:

My idea about enabling links to private/public/neighborhood instances would be like this:
instead of whole categories like "Private links", "Public links" which are awful at use (because number of links), we might get a "toggle" button in the top right corner of Writer's Nexus interface which would toggle between "private/public/neighborhood". We have something similar in current Nexus but it's controlling visibility of neighborhood.
In Writer's Nexus this toggle button would allow to choose "To which instance of link I would like to be taken".

[kaelisebonrai]

Chloe, Tweek, (diafero?):

What would each of you say the architecture would be / should be?

Reasoning for asking these 2 (3?),

Chloe is/was modelling it, and will possibly be implementing most of it, if not the python coding. =P

Tweek is pretty much the resident expert on canon and lore.

(diafero would probably be the one who designs and implements the python etc stuff for it >.> (if he wants, up to him of course, I'm not nominating anyone =P) )

before anything more is done - some base architecture needs to be hashed out, preferably by one of those three. =P

I've been reading this discussion since pretty much the beginning, and *I* have no idea what the intended final form is to be. =P

Do we even all have the /same/ view of the intended final product? =P

[nathan2055]

I've been reading this discussion since pretty much the beginning, and *I* have no idea what the intended final form is to be. =P

Do we even all have the /same/ view of the intended final product? =P

I am confused also, about both GUI and the actual thing (less the actual thing).

And then fan-ages might link to fan-ages of other authors, in which instance do you arrive? This goes on and on... linking in Uru was clearly not designed well (as in, "write down what you need, think of the easiest system possible to do that, and implement it as fail-safe as possible").

Thinking about it, that seems exactly right. I think we should stop with instancing for now. After all, all we need is the new Nexus, not to reinvent instancing.

The reason that all D'ni areas (IE anything in the D'ni Cavern) should be public and not instanced, and this includes Fehnir's House, Chloe's Hood Office, the (hopefully) soon to be released Dorehn and any other Fan or Cyan created cavern location is a very simple one. If they are not public, and we instance them we are left with this scenario: If you link to an instanced version of D'ni then, theoretically, you as an explorer could travel on foot up the Great Shaft to the Cleft. Once at the Cleft you could walk to the nearest town or city. From there you could catch a plane, or catch a bus and head home. And when you get home you will find yourself face to face with an exact copy of yourself. Because you are no longer in your world, you are now in a instanced version of Earth, which is a carbon copy. Meaning that everything on Earth is also copied. Including the people. Note, this the problem with instancing D'ni. D'ni is on Earth. It is not a seperate age where you don't exist on that age. It's your home world, instancing your home world is a really bad idea.

Actually, I think that makes since!

Ages are never deleted from the Vault (at least in MOULa, and most UU servers). To clean up "orphaned" nodes requires some extra garbage collection script to be running, or for someone to manually delete them with a vault editor.

OK, so that's out.

[diafero]

Count me in, kaelis, I am very happy and willing to help. My time schedule is dictated by university though

Ough. I wasn't aware of that. I though it is just like in PyPRP: fix Python code and we ready to go.

No, it's not: In case of linking responders, a responder is doing all the work of specifying the linking rules. No way Python can change that, since some ages even link without any Python (the clicking activator is directly connected to the linking responder). An example would be Huiiii with it's Nexus (I had to fix the prp files to use the proper linking rules before putting them on the Shard - after I even noticed this, so some people will have this age in their AgesIOwnFolder, usually there should be no side-effects), and... another age, but I forgot which one

Regarding a rough architecture: I think the biggest thing to decide is whether we want to replace Cyan's Nexus (something we never did with a Cyan age before, on the other hand it's a small age that exists solely for technical and game-play reasons), or whether we add our own one. I'd like to read some opinions about this (if that was already discussed en detail, sorry for that).
My personal consideration is that I refrain from replacing a Cyan age. It'd essentially mean removing the (admittedly not that great) original age. The price is an inconsistent interface, and the need to find a good way to make the new Nexus reachable (as Cyan's is reachable from almost everywhere easily). The pro, besides the concerns I mentioned, is that the new Nexus does not have to do anything with hoods and can focus solely on providing a good interface for browsing a relatively large set of ages. For the time being however, even a complete replacement Nexus could only be used on POTS Shards and would not mean hood management either (or is UU compatibility a design goal? That'd basically mean someone has to properly port/rewrite a sane linking manager for UU). The discussions here showed that a Nexus separation that is not too confusing can be done (D'ni ages vs. the rest). From what I understood, in an IC-way, the "two Nexi" would be more logical as it would mean we created our own, instead of also replaying all the links to the old Nexus - or is that fairly minor?

[nathan2055]

Count me in, kaelis, I am very happy and willing to help. My time schedule is dictated by university though

Ough. I wasn't aware of that. I though it is just like in PyPRP: fix Python code and we ready to go.

No, it's not: In case of linking responders, a responder is doing all the work of specifying the linking rules. No way Python can change that, since some ages even link without any Python (the clicking activator is directly connected to the linking responder). An example would be Huiiii with it's Nexus (I had to fix the prp files to use the proper linking rules before putting them on the Shard - after I even noticed this, so some people will have this age in their AgesIOwnFolder, usually there should be no side-effects), and... another age, but I forgot which one

Regarding a rough architecture: I think the biggest thing to decide is whether we want to replace Cyan's Nexus (something we never did with a Cyan age before, on the other hand it's a small age that exists solely for technical and game-play reasons), or whether we add our own one. I'd like to read some opinions about this (if that was already discussed en detail, sorry for that).
My personal consideration is that I refrain from replacing a Cyan age. It'd essentially mean removing the (admittedly not that great) original age. The price is an inconsistent interface, and the need to find a good way to make the new Nexus reachable (as Cyan's is reachable from almost everywhere easily). The pro, besides the concerns I mentioned, is that the new Nexus does not have to do anything with hoods and can focus solely on providing a good interface for browsing a relatively large set of ages. For the time being however, even a complete replacement Nexus could only be used on POTS Shards and would not mean hood management either (or is UU compatibility a design goal? That'd basically mean someone has to properly port/rewrite a sane linking manager for UU). The discussions here showed that a Nexus separation that is not too confusing can be done (D'ni ages vs. the rest). From what I understood, in an IC-way, the "two Nexi" would be more logical as it would mean we created our own, instead of also replaying all the links to the old Nexus - or is that fairly minor?

I agree, we shouldn't edit or remove the Cyan Nexus. The Fan Ages and Cyan Ages should be separate. And we definitely shouldn't leave Fan D'ni Locations in the Cyan Nexus. That would cause more problems-and leave the ones we set out to fix!

[GPNMilano]

agree, we shouldn't edit or remove the Cyan Nexus. The Fan Ages and Cyan Ages should be separate. And we definitely shouldn't leave Fan D'ni Locations in the Cyan Nexus. That would cause more problems-and leave the ones we set out to fix!

You have missed the point entirely I'm afraid. What Diafero means is that all D'ni locations (be it fan or Cyan made) will remain in the CyanNexus only. All the rest of the fan ages will be moved to the CommunityNexus. The invite system will remain in the CyanNexus. This will allow all links to D'ni to be public ages, and thus their will be no private instances of D'ni. The CommunityNexus will be used for accessing fan ages, and all the links in the CyanNexus to fan ages (with the exception of D'ni Locations) will be moved to the CommunityNexus.

[nathan2055]

You have missed the point entirely I'm afraid. What Diafero means is that all D'ni locations (be it fan or Cyan made) will remain in the CyanNexus only. All the rest of the fan ages will be moved to the CommunityNexus. The invite system will remain in the CyanNexus. This will allow all links to D'ni to be public ages, and thus their will be no private instances of D'ni. The CommunityNexus will be used for accessing fan ages, and all the links in the CyanNexus to fan ages (with the exception of D'ni Locations) will be moved to the CommunityNexus.

OK, that wouldn't solve any problems. It would leave Restoration Links in the Nexus, which is the reason I made this thread. There should be a different Nexus for Fan Ages and Fan D'ni Locations, which will be handled through the WNexus. It will include a D'ni category, so all Cyan locations will be in the Cyan Nexus, we won't have to mess with instancing, Personal Links returns, and everything will be fixed. I hope.

[GPNMilano]

OK, that wouldn't solve any problems. It would leave Restoration Links in the Nexus, which is the reason I made this thread. There should be a different Nexus for Fan Ages and Fan D'ni Locations, which will be handled through the WNexus. It will include a D'ni category, so all Cyan locations will be in the Cyan Nexus, we won't have to mess with instancing, Personal Links returns, and everything will be fixed. I hope.

What problem wouldn't it solve? The restoration links tab would no longer be used by fan ages. The only fan created ages left in the CyanNexus would be D'ni locations (IE places within the cavern like from the age contest). IC there is no reason for D'ni locations to be located within the CommunityNexus if it was built by explorers to access age's they've written or found. If anything it would keep the continuity straight as the CyanNexus is used for accessing the cavern, with a side structure of dealing with invites to people's personal ages. Hence all D'ni locations be it fan or Cyan created should fall under the CyanNexus umbrella. Putting them into the CommunityNexus would make just a copy of the Nexus we currently have save for Cyan ages. Which would look like we're just growing the already established rift in the community of Fan Vs. Cyan.

When I first suggested the idea of a nexus for fan ages way back when, the idea was simple: A way to streamline the CyanNexus's overbloated gui by removing the access point to fan ages from there. While at the same time finding a way not to make it Fan Vs. Cyan. This way is the best way to do that. It allows for fan areas to still be accessed from the CyanNexus (if only a certain type of fan age) while at the same time not bloating the CyanNexus' gui with unneeded clutter like over 100 fan ages. Both IC and OOC it's the perfect solution IMO.