OniGalore:Current events

WIKI WORK IS FUN!
THAT IS, FOR A DAY OR TWO THEN IT GETS BORING

These are only suggestions, although some are more obviously needed than others.

Whatever in this list looks interesting to you, feel free to tackle it, even if you only have a little time here and there.

However, if you are leaving a project half-done until you can resume it, please note that under the item in this list.

Thanks for whatever you can do to contribute.

If you're not confident about editing a wiki, check out our Help page, and meta.wikimedia.org for further reference.

Organizing the modding side of the wiki

I'd like to throw a general blueprint out there and see if there's any in agreement, or at least any who disagree. It concerns what we're doing with our modding-related articles on the wiki, which is generally One Big Mess right now. The basic principle behind these changes is simple: "groups things logically; present information clearly".

Proposal for organizing things:

• first half of Modding Oni becomes History of Oni modding -- this part has very little to do with the second part, when you think about it
• second half of Modding Oni is made into a page that gathers general ideas for modding, not in connection with the Edition, something like Modding brainstorms or whatever, where we can all add ideas; if some of these ideas are already decided on for inclusion in the AE, well, then, they should be in one of the two places in the next bullet point
• current and planned/in-progress features of the Edition are already listed on the Anniversary Edition page, or in greater detail on the pages grouped under Category:AE To-do, so we leave them alone
• at some point, the Edition needs to document all the changes it makes, not in an informal list like "Basic features", "Coming soon enough", but in a carefully maintained page like what Loser has done beautifully here (frankly, that page right there is a lot of the work done already, the overall AE documentation would just explain a few other things and link to that page for the rest)
• the WIP tutorials that paradox is writing will need a place, and there's other tutorials lurking out there too, some unfinished; let's start a Category:Tutorials to group them together
• specific tutorials simply get placed at root level on the wiki with obvious names, not like this: AE:Importing_weapon_models; there's no reason for that page to be under the AE prefix (requiring the use of .oni files is not a good enough reason); take off the prefix, though, and you've got a good example in how to name tutorial pages
• put all WIP mods under Category:Modding projects
• either delete AE:ONK or replace it with a historical blurb citing its accomplishments before it was superceded by the AE, but either way, move it out of the AE prefix; if it's not deleted, leave it in the "Outdated modding projects" category; in any case, move the page's links to mods that were produced by the ONK to a their own pages, and integrate them with the categorization system discussed in the next point
• gradually bring wiki documentation of finished mods into sync with the Mod Depot; because the Depot is strictly categorized, it makes more sense to start there and copy that structure to here; as we see files get added there, we add pages here, or for smaller mods add them to one combinatory page, and link back to the actual files on the Depot for download
• the Main Page's "For Modders" section will guide the reader's approach to modding; it will look like this:

• Intro to modding -- a short explanation of where to start if someone is totally new so they know whether they should start by reading a tutorial, or browsing a database, etc.
• Tutorials -- a link to Category:Tutorials; these include the yet-to-be-finished BSL tutorials that are currently under the BSL prefix
• OBD Database
• BSL Database -- of course we can provide a link to the BSL tutorials from here, but those pages should be in the same domain as the other tutorials
• History of modding -- link to what's currently the first part of the Modding Oni page

• the link "Mods" under the "For Players" section will look like:

• The Mods

• By Platform
  • Mac OS -- this is a link to a category like Category:Mac-compatible mods
  • Windows -- this is a link to a category like Category:Windows-compatible mods
• By Mod Type
  • ... -- you get the idea if you've seen the Depot; since a mod's page can have more than one category, mods can be categorized by Platform as well as Mod Type, as well as Install Method if desired and we just link to those mods in their different groupings using this submenu-style structure

• write an interlocking (interlinking!) page for OBD (called something like Overview of file types) that explains in plain English what each file does; this puts it all in one place, unlike putting summaries at the top of each page so that a newbie has to follow each file type link to that page to read about the file type; for the format would be something like:

"==QXRF== The QXRF type is for tracking the hats the characters are wearing; hat geometries are stored in VPRW files. At level-load, Oni scans the QXRF array and loads the VPRWs. Then, it textures them with the hat textures stored in BINA/LDWF and applies them using the UV maps in that BINA resource that are in the FLSJ format." -- each four-letter type links to an subheading on the same page that explains that type more fully but without any technical details; until this is done, the hard work performed in reverse-engineering these files is shadowed in obscurity for newbies because of the lack of plain English in the OBD pages

• move OBD:BIP out of that prefix, it's as much BSL-related as OBD-related and, anyway, it's a project page; we should keep the OBD and BSL spaces for just documenting information
• add to AE:Weapons (which still has the ONK image branded on it) any items on AE:New weapons that have definitely been adopted for the AE; the rest should then be moved to a more logical root-level name -- either a combinatory page like Weapons mods or their own separate pages -- since they are not part of the AE; they can be browsed there as candidates for the AE, but since they're not part of it, why leave them in that namespace?

If you're thinking, "Yeah, but who's going to do all this?", don't. Don't let the list intimidate you. Many of these steps are quick and easy; others can be chipped away at, over time. Certainly I will do what I can to pitch in when it comes to the areas of the wiki I understand. And if everyone contributes in the area they understand, we'll each gradually come to a better grasp of all the content that's on the wiki; right now, a lot of content is lurking in corners, like this little gem, and is just begging to have something done with it that reflects where we are in 2008. --Iritscen 00:43, 22 September 2008 (CEST)

General wiki maintenance

1. Just browse Special:Wantedpages, and pick an interesting topic to write about!
2. We are in the process of replacing the system of subpages under Images with categories. So, for instance, the Images/In-Game/Talking Heads should all be in the category Category:Talking heads. Then we can delete the Talking Heads subpage. Image categories will be listed on Images for convenience.
3. If an image is neither used to illustrate a page nor categorized (not used as an article of its own right, which can be justified in some cases), then maybe it's not getting the attention it deserves, or maybe it's useless/redundant. Feel free to do something about such "out-of-the loop" images or just point them out.
4. Categorize categories. We don't want to go nuts here, of course. Wikipedia has a crazy-complex tree of categories. We don't want that. All we want are a second level of categories that separate the base level of categories. So, when we look at the main Categories page, we don't see categories like "Art by Guido" next to "Tables". Unless you have a good grasp of what each template does, you can just leave this to me (Iritscen).

   I (Iritscen again) am currently second-guessing this approach, and planning to delete the few category categories already in existence. Creating a second level of categories muddies up the Special:Categories page more than it clarifies it. My mistake was in thinking that the page would show only the top-level of categories if I set things up correctly, but in fact every wiki's Categories page shows all categories regardless of their place in an overall hierarchy (just look at Wikipedia's categories page, it's millions of screens of category names despite their careful hierarchy). Only the installation of something like WP's Category Tree would help at all, and after some extensive investigation a while back I concluded that the Tree's default display was not even going to work in a way that was user-friendly, showing an expandable list of the hierarchy of categories like I would want to see. So, in short, it looks like this is a waste of time for a wiki our size and one level of categories is enough, even though it does make for some strange bedfellows on the Special:Categories page.

5. Set up handy redirects. These can be great time savers.

Coverage of Oni content

1. The canonical version of Oni is English, so if your language version mistranslated something important, we'd like to know about it. Check out the canonical quotes HERE and point out discrepancies HERE.
2. Some characters pages are stubs and/or feature inaccurate/incomplete information: Kerr, Hasegawa, Griffin... Try to objectively present the content actually present ingame. Most of these characters appear in the Character category. You can speculate and elaborate in the Added value section (typically the second half of a page). See Muro for an example.
3. Some chapter pages may have incorrect/incomplete plot summaries: they're also supposed to be concise, linking to other pages whenever the summary or the Added value section starts growing out of shape.
4. Places (like Regional State Building) and entities (like BGI) typically deserve a page of their own, meant to take some load off the Chapter summaries, both in terms of "facts" and "added value", while providing more or less technical trivia.
5. It would be nice to have a frame-by-frame overview/analysis of the following: 1998#Trailer, 1999#Trailer, Intro AMV, Outro AMV. Please name the representative screenshots of Intro AMV and Outro AMV in accordance with THESE TWO pages.

and beyond...

1. Use Lost Chapters to elaborate on what may have happened to Konoko in the time gaps between the original chapters (e.g., between CHAPTER 12 . SINS OF THE FATHER and CHAPTER 13 . PHOENIX RISING). You can also elaborate on sequels/prequels/interquels/paraquels, which may fit under a general philosophy (to be detailed HERE). Depending on the nature of your stuff, it may end up as more than fan fiction, either by being implemented in the Anniversary Edition or by inspiring dôjinshi-oriented artwork.
2. Plagiarism is not nice, but "Oni 2" can still be influenced by anime/cyberpunk/other references. See HERE to review the influences so far, elaborate on them some more, or point out new ones.

Adding to the databases

1. Despite its relative simplicity, BSL is vastly underdocumented. Most of the stuff is well-known to experts, but designing a comprehensive guide that will get novice scripters started and keep them going requires didactic skills and lots of patience. There are a few programming language basics that someone ought to say a few words of wisdom (like functions or operators). Long-term goals are: a cross-referenced set of mini-tutorials that document the preset functions and variables in a standalone way (see, e.g., ai2_allpassive); maybe a functional breakdown of the original scripts (see, e.g., HERE)
2. There's still progress to be made in the field of binary hacking. Note the "OK?" column on OBD:File_types. Any page not marked with a happy face still has data stored within that file type that is not understood.
3. Aside from doing actual research on Oni's binaries, you can also make sure that each file type's page in the OBD namespace actually explains what that file type is for, to help out newbies. An overview at the top of each page will make things much more user-friendly.