Namespaces

Namespaces will probably be implemented by the time UT2003 and U2 are concurrent. Until then see UT2003 for how to deal with new pages.

Proposals

Mychaeel: I've kept thinking about this, and I'm suggesting the following (not claiming it hasn't been mentioned before):

Introduce technical support for namespaces.
Create namespaces for the various games, not by engine version but by game name: U, UT, UT2003, UE2, DX...
As soon as the class structure of UT2003 is known, move all UT classes that have no UT2003 counterpart, or whose UT2003 counterpart of the same name has a different meaning or a sufficiently different implementation to justify a separate page, into the UT namespace. Create pages on classes only present in UT2003 (see above) in the UT2003 namespace.

Unqualified page links will automatically lead to pages in the current namespace if possible, or to pages in the global namespace otherwise, or open a "new page" edit field within the current namespace.

The only pages that remain in the global namespace are those that apply to all engine versions.

Old Discussion

to set the scene...

Tarquin: Implement some heavy Wiki techology such as namespaces so the global namespace is the latest version of the engine, and for example current page Actor becomes UT:Actor. Would require major scripting.

Mychaeel: ...but is definitely the preferable way. Everything else is bound to lead to major confusion.

Tarquin: urg. But do we simply fool the current system into accepting names like "UT:actor" by using some sort of escape character and then detect it in the GetLink subs, or do we have to majorly hack the way the data is stored? Or even somehow hijack the built-in InterWiki links – they work like this: Wikipedia:Pagename AFAIK, but I haven't implemented them.

Mychaeel: We could make it upside-down: Not consider the namespace a new top-level branch but a page-level distinction (as if we were to provide each page in different languages). Then all versions of a page could even be stored in the same file without having to mess around with the whole data storage code. If you are viewing a certain flavor of a given page, all links would default to the same flavor of other pages in case they're present.

EntropicLqd: That's not a bad idea. Conceptually you could argue that the next gen Unreal engine stuff is really another language. It's stretching the metaphor a little but sounds easier than creating a whole new namespace. However, thinking ahead to Christmas we'll probably need some Unreal 2 specific stuff as well - but goodness knows just how similar UT2K3 and U2 will be.

Mychaeel: I'm meanwhile strongly in favor of real namespaces.

Tarquin: yup, I think we have to go for some sort of technical namespace thingy. My display idea for the class thing has gone all wrong BTW: if I use SPAN instead of TABLE it won't work on more than one line

Technical Implementation

Tarquin: whether we use a top-level change so Wiki can use pagenames like "UT:Bot", or the flavour system, I think different namespace pages of the same name should behave to the user as different pages.

Showing all versions together for editing & using new tags could have advantages (eg a tutorial like Making Waterfalls might have only minor differences between engines) but I think it could be very confusing when editing. Some pages (Bot, for example) may be completely different in each engine.

Mychaeel: As it happens, Making Waterfalls will have to undergo some changes for the new engine – due to a couple of fundamental changes in how things like, for instance, panning textures are done in the new engine. In any case there should be a clear indication of the current namespace on every page and a way to switch to a different namespace easily.

Tarquin: Agreed. The title of a page should be "UT:Bot" for example. Are you still planning on putting the different versions of a page in the one file & using UMW's superscript 3 seperator somehow?

Mychaeel: No – actually I'm thinking more along the lines of branching the subdirectory structure directly below the level of wiki-data/page and wiki-data/keep.

Interface

Suggestions for how it should work for the user:

Within Global namespace:
- plain page links stay in global
- namespace links go to that namespace
- plan page that doesn't exist edits the new page in Global
within a namespace
- namespace links (another namespace of "global:Bot") go to that namespace
- the tricky issue is what to do for the plain name:
  - if the page in the same namespace exists, go there
  - if the page doesn't exist in that namespace...

Mychaeel: ...jump to that page in the global namespace if it exists there, or create a new page within the current namespace otherwise. (That accommodates best Wiki growth as the engine grows.) – The behavior in the global namespace suggested above is just a special case of this behavior, by the way.

Tarquin: that's probably the best thing.

Usage

Tarquin: Are namespaces just for classes and script differences? Are things about mapping in general going to be in global?

Mychaeel: Umm, anything that is specific to a particular engine version. Particle emitters should be something in the UT2003 namespace, for instance.

Suggestions for namespaces...

Feb 2003

Tarquin: I had a funny thought the other day. It seems to me we've just about implemented namespaces by the back door. The "Page (UT)", "Page (ut2003)" syntax is pretty much a namespace system. The only thing that's missing is the "smart" links as discussed above.

Mychaeel: Yes, you're right... but it turns out to have just the problems that made me think of namespaces as a somewhat untidy solution. (Plus a few more that come from our rather crude implementation of them by adding a page name suffix.)

The main problem is that namespaces put every page into one single category, and that they have a granularity of pages rather than parts of pages. Some things are naturally exclusive to one category, like personal pages; other things like the Actor class in UT and UT2003 are actually the result of an evolution where most of the content is shared, but some things are particular to either UT or UT2003.

An optimal solution would allow us to assign categories to parts of pages without disrupting the reading flow when viewing the content of one category. (If I look at a page in "UT2003 mode" I'd like to see all content that applies to UT2003 even if it partly overlaps with UT or U2 content.)

On the other hand, some things like UT's and UT2002's Bot class differ in more things than they have in common to a degree that warrants a distinct page for UT and UT2003 each.

Something's on my mind that might solve that dilemma, but it's too vague yet to be put into words...

Fyfe: Can I poke this topic back into life Are we going about the grouping of pages wrong here? At the moment we are splitting it by game, and this mainly comes down to UT and UT2003 (Unreal Tournament 3 will open this can of worms again when it arrives).

The result is

and ghost links to

[Triggers (U2)]
[Triggers (UE2)]

Now some people have wrongly assumed that because we have a page for UT and UT2003 we need one for every game (eg Triggers (UT2004)). When in reality UT represents Unreal Engine 1, UT2003 represents UE 2, UT2004 represent UE 2.5 and Unreal Tournament 3 will represent UE 3.

So would it not make more sense to split the wiki by engine version?? There are exceptions where a game will implement new features that we want to document in the wiki.

Same topic, different question, and using Triggers as an example would the following layout be better...

Triggers (UT) – As is UT specific info
Triggers (UT2003) – As is UT2003 specific info
Triggers – This redirects to the latest version, in this case Triggers (UT2003)

Then when Unreal Tournament 3 comes along we create (if it's needed) [Triggers (UT2007)] and Triggers is changed to point at [Triggers (UT2007)].

Comments????

EricBlade: It seems to me that potentially each game could have an Actor class, such as [Land of the Dead/Actor]. Or any other class, or any other topic. If you compared Postal 2, to whatever Unreal game was from a similar build of it's engine, I doubt you'd even be able to recognise that their UC files came from the same source. I'd wonder if it would be best to do it like that, with each page referring back to what it is most similar to, and then detailing the differences.. hmm...