OniGalore:Current events

WIKI WORK IS FUN!
ENOUGH FOR A JOKE 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:

• 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)
• 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
• 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 from the subpage "Images/In-Game/Talking Heads" were placed in the category Fly-in portraits. Then we deleted the Talking Heads subpage and set the Images page to link to the "Fly-in portraits" category page instead of that subpage.
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. 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 Characters 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 1999 trailer.

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.