75th Instancing - Revision history

Mac Fife: /* Name of objection. */ Add category

2009-02-17T11:13:46Z

Name of objection.: Add category

Mustardjeep: /* Name of objection. */

2009-02-13T06:52:30Z

Name of objection.

Mustardjeep: /* Name of objection. */

2009-02-13T06:50:58Z

Name of objection.

Mustardjeep: /* Public Ages */

2009-02-13T06:44:58Z

Public Ages

75th Trombone at 05:56, 12 February 2009

2009-02-12T05:56:47Z

75th Trombone at 05:47, 12 February 2009

2009-02-12T05:47:38Z

75th Trombone: /* Introduction */ g'bye

2009-02-12T02:18:06Z

Introduction: g'bye

75th Trombone: Begin

2009-02-12T02:17:47Z

Begin

New page

This is '''75th Trombone's bare-bones instancing plan'''. My goal for this page is to start with the bare minimum number of instancing mechanics I can possibly think of, and for individual objections to be raised and addressed.

As necessary, The Plan will be amended to work around any objections and exceptions that don't have a satisfying rebuttal. My goal isn't to start out with a finished model; it's to start out with the simplest possible model and only add to it where there is no other recourse.

Feel free to edit this page, especially to add objections to the appropriate section. '''Please do not delete anything''' in the Plan section.

Note that this is independent of the KI/Nexus/Relto interface for instancing, or invitation systems, or anything else. The Plan is strictly about the instancing behavior of Ages themselves, NOT the accompanying user-facing controls (though objections may question whether the mechanics are possible to express in a decent interface).

== Introduction ==

== The Plan ==

There are only two categories of Ages, plus the neighborhoods.

=== Public Ages ===

* Open areas in Ae'gura are public. Isolated areas are private and will be partially enumerated later.
* Individual neighborhoods are, strictly speaking, public as well. (It's the Bevin neighborhood prototype, not the 'hoods themselves, that can be said to be 'hood-instanced.) The new/revamped invitation and membership mechanisms can control access to each 'hood.
* Perhaps there should be one Bevin-type neighborhood (Bevin itself?) that is entirely public, for neighborhood story events.

=== Private Ages ===

'''All areas not listed above are private.''' This includes all ABM/PotS/MO:UL Ages, even the formerly 'Hood instanced ones. It seems to me that the main problem with the instancing of these Ages is controlling who gets end-of-Age rewards.

* For the Uru Prime/PotS Ages, you can only "complete" the Age in your private instance.
* For the MO:UL gardens and such with extremely limited gameplay mechanics, you can complete the Age in any instance.

In addition, certain areas of Ae'gura are private:

* The Tokotah journal rooftop
* The Kadish gallery
* Balconies
* The Great Zero
* Etc.

== Objections/Exceptions ==

=== Name of objection. ===

Content of objection goes here. This should be one or two sentences concisely describing the objection or alleged exception to the rules stated in The Plan.

* ''Anyone with a concise rebuttal to an individual exception may post it in an italic list item after the exception text. Conversation threads deeper than one objection and its top-level rebuttals should probably be moved to the talk page.''

← Older revision		Revision as of 11:13, 17 February 2009
Line 43:		Line 43:

	(1) There were several areas of MO:UL that made isolated areas private, the end result was the creation of several "ghost" Cities. If your trying to clean up instancing the publicly viewable "isolated areas" need public views. [[Isolated Areas]]		(1) There were several areas of MO:UL that made isolated areas private, the end result was the creation of several "ghost" Cities. If your trying to clean up instancing the publicly viewable "isolated areas" need public views. [[Isolated Areas]]
		+
		+
		+	<!-- Do not edit! -->
		+	[[Category:Instancing]]

← Older revision		Revision as of 06:52, 13 February 2009
Line 42:		Line 42:
	* ''Anyone with a concise rebuttal to an individual exception may post it in an italic list item after the exception text. Conversation threads deeper than one objection and its top-level rebuttals should probably be moved to the talk page.''		* ''Anyone with a concise rebuttal to an individual exception may post it in an italic list item after the exception text. Conversation threads deeper than one objection and its top-level rebuttals should probably be moved to the talk page.''

−	(1) There were several areas of MO:UL that made isolated areas private, the end result was the creation of several "ghost" Cities. If your trying to clean up instancing the publicly viewable "isolated areas" need public views.	+	(1) There were several areas of MO:UL that made isolated areas private, the end result was the creation of several "ghost" Cities. If your trying to clean up instancing the publicly viewable "isolated areas" need public views. [[Isolated Areas]]

← Older revision		Revision as of 06:50, 13 February 2009
Line 41:		Line 41:

	* ''Anyone with a concise rebuttal to an individual exception may post it in an italic list item after the exception text. Conversation threads deeper than one objection and its top-level rebuttals should probably be moved to the talk page.''		* ''Anyone with a concise rebuttal to an individual exception may post it in an italic list item after the exception text. Conversation threads deeper than one objection and its top-level rebuttals should probably be moved to the talk page.''
		+
		+	(1) There were several areas of MO:UL that made isolated areas private, the end result was the creation of several "ghost" Cities. If your trying to clean up instancing the publicly viewable "isolated areas" need public views.

← Older revision		Revision as of 05:56, 12 February 2009
Line 4:		Line 4:

	So for the time being, consider this a primer for people (including myself) to fully understand the implications of instancing mechanics and problems.		So for the time being, consider this a primer for people (including myself) to fully understand the implications of instancing mechanics and problems.
		+
		+	Go ahead and put your objections and stuff here, in bite-sized, easily-parseable form. Maybe this'll be useful in giving us a good overview of what problems a new instancing scheme has to solve.

@@ Line 1: / Line 1: @@
-This is '''75th Trombone's bare-bones instancing plan'''. My goal for this page is to start with the bare minimum number of instancing mechanics I can possibly think of, and for individual objections to be raised and addressed.
+'''I've been a bit stupid.'''
-As necessary, The Plan will be amended to work around any objections and exceptions that don't have a satisfying rebuttal. My goal isn't to start out with a finished model; it's to start out with the simplest possible model and only add to it where there is no other recourse.
+In separating the Instancing mechanics from the interface, I've separated the very easy part from the part everyone's been talking about.
-Feel free to edit this page, especially to add objections to the appropriate section. '''Please do not delete anything''' in the Plan section.
+So for the time being, consider this a primer for people (including myself) to fully understand the implications of instancing mechanics and problems.

@@ Line 15: / Line 15: @@
 === Public Ages ===
-* Open areas in Ae'gura are public. Isolated areas are private and will be partially enumerated later.
+* Open areas in Ae'gura are public. Isolated areas are private and will be partially enumerated later. (1)
 * Individual neighborhoods are, strictly speaking, public as well. (It's the Bevin neighborhood prototype, not the 'hoods themselves, that can be said to be 'hood-instanced.) The new/revamped invitation and membership mechanisms can control access to each 'hood.
 * Perhaps there should be one Bevin-type neighborhood (Bevin itself?) that is entirely public, for neighborhood story events.

@@ Line 7: / Line 7: @@
 Note that this is independent of the KI/Nexus/Relto interface for instancing, or invitation systems, or anything else. The Plan is strictly about the instancing behavior of Ages themselves, NOT the accompanying user-facing controls (though objections may question whether the mechanics are possible to express in a decent interface).
-== Introduction ==
 == The Plan ==