Talk:FF7/Kernel/Kernel.bin

Detaching the tables?

Somethings been bugging me. You think we should "Detach" the KERNEL.BIN format and place it as it's own article ala the TIM example? This will allow 1)The search function be able to pick up "kernel.bin" and return a intelligent response, and also 2) Keeps a particular article from being overloaded with tables. We can check to see if anything's been orphaned using the special pages. I think we should do this for things like the savemap as well, or any global resource that gets frequently refrenced.

Another issue is my html export of Gears uses tags, which this wiki does not parse. How do you remove these in a quick manner to make these tables?--Halkun 22:50, 8 Mar 2005 (CST)

I've finished this section and just looking at the length of the tables it might be a good idea to somehow break it up, not just from a stylistic point of view but when I edit it the Wiki tells me that since the article is more than 32KB there may be some browsers that cannot edit it. I don't know if these are just older browsers since IE6 and Firefox 1.0 don't seem to have any issues.

About the tables, if you want me to go over them and format them in the Wiki's native table format so that it's easier to edit, I can do that, or if you want, take a look at the formatting for the tables on this page I've done and apply them to tables elsewhere (or copy/paste/edit if it's easier). --SB 06:22, 9 Mar 2005 (CST)

Detaching parts of the contents is a good idea IMO, especially in such a "modular" case where the kernel.bin format is completely explained in another article (about what uses the file). This article can be easily rewritten to a short reference to FF7/Kernel.bin, or even use wiki code to include the latter in the former. I think the linking solution is preferable, though. Edit: In fact I think the descriptions on the various blocks och kernel.bin can be split into articles as well, especially since these are direct memory dumps (i.e. they will be referred to by their own right from other articles). --Qhimm 10:10, 9 Mar 2005 (CST)

I've been doing some though on this. I guess in my (our?) zen to convert Gears to wiki, we are falling into a trap.

I'm not really liking this subdirectory thing. The whole FF7/XXX/YYY does nothing but break the direct search function. The only perk I see is that we have a referal at the top of the article to the one previous. Don't we already have a "back" button on our browsers that do that function already? Can someone think of a good reason why I can't just make a savemap table and simply call it Savemap or what about Walkmesh and simply refer to it though a) the search function ar b) crosslinking from other articles? Wiki has tools to keep things from getting "lost" and I think we can fix disabiguities when we come across them. Then again, we are now in the prossess of converting a liniar document (Gears) to one much more dynamic. One of the fears, I guess, is that we don't want to mix up FF7s "savemap" with FF8's "savemap", but when I have edited Wikipedia pages, It's nice to just be able to stick in a reference without having to remeber what directory it's in. I don't think we should be afraid to pop in a blank refrence and simply edit it. I think we should let the wiki do it's job.

Probably agood plan of action is to at least Get gears in here first. I might just be a little put off by the "new car smell" of a brand new wiki and don't want redirects from here to high-water as we shove things around. (Even though they are invisable)

On a slightly related note, SB, how exactly are you converting Gear's tables from PDF to wiki? Are you doing it by hand? I'm using an exported html file from Acrobat, and the output is really crufty.

--Halkun 18:46, 9 Mar 2005 (CST)

Yeah, I'm converting them by hand. At first it was a thankless task but I'm actually pretty quick at them now so don't mind going over them.

I agree about the FF7/XX/YY thing and yes, it would look better if it was just for example Savemap. The only issue I've then got is as you say differentiating between FF7 and FF8 savemaps and unless this was strictly an FF7 technical wiki I'm not sure how you'd fix that. You could use Disambiguation pages - so that if someone types in Savemap in the search, there are links to FF7 Savemap and FF8 Savemap pages, though this seems a bit clunky to me. I'm not sure, definetly something to ponder. Qhimm? --SB 19:52, 9 Mar 2005 (CST)

I'm going to give catagories a shot. I wonder if this will make things a lot easier and not cruft up the namespace.--Halkun 20:59, 9 Mar 2005 (CST)

Sorry Halkun, but I have to say I'm in complete disagreement. I'll respond to your issues in order. Firstly, the direct search function isn't really a search, it just looks up an article if and only if you type in its exact title. Anything else, you need to use the full search. This is the same thing as a dictionary, you won't find "post card" looking under the letter C. The subpages hasn't broken the search function; sure you made some other scheme to disambiguate entries, Savemap (FF7) for example has builtin wiki support, but you still wouldn't find it by searching for "Savemap".

The "perk" of using subpages is the extremely handy URL which can be easily and intuitively remembered and linked from outside, say the forums. The content structure has the same format as a normal web page with directories, something most web users are already familiar and comfortable with -- which one would you prefer to link to, http://wiki.qhimm.com/FF8/Kernel_memory_management or http://wiki.qhimm.com/Kernel_memory_management_%28for_FF8%29 ? The subpage structure isn't about preventing things from getting lost; people should still find what they want through searching and cross-references -- but surely it doesn't hurt if they can also find it intuitively by typing in a logical URL? Subpages are not making life harder for anyone (except that you have to enter "FF7/" for references), rather they help keep the wiki structured and easier to search. The reason major wikis like wikipedia are so delightfully flat in its structure is because they need to contain all possible kinds of entries and thus cannot even begin to impose some additional structure on the content. QhimmWiki is a highly specialized wiki about very similar sets of information, i.e. very much suitable (indeed begging) for a more structured approach. Furthermore this is not a free wiki, it's a wiki around a very specific subject, and more importantly it's a wiki designed so you can learn about the entire subject, not just look up small aspects. Optimally, all pages revolving FF7/FF8/PSX should be structured and cross-referenced so it's possible to read the entire wiki back to back. Having subpages is just one more means of intuitively informing the reader where in the wiki he is -- like having chapter headings and page numbers in a book.

And yes, the primary reason for using subpages is of course that you can define one FF7/Savemap and one FF8/Savemap without there ever being any possibility of confusion. I'm sorry if this puts an unreasonable amount of pressure on article authors, but I think it's really not too much to ask that people remember what game they're writing about. Yes you have to write an extra "FF7/" on every reference (and rewrite the link title), but in all honesty you are referring to the FF7 savemap, not "some" savemap; write it! If this wiki was just about FF7 there wouldn't be a need for this discussion, but eventually this wiki will contain the same set of information for two nearly identically-structured games; I do not want to be the one to try and clean hundreds of ambiguous pages and references up later if we don't think about structure now. Sure it's easier to just "slap in references as you type" right now, but what about later when you slap in a reference to FF8's savemap and later notice that it's pointing to FF7's? Do we then start doing makeshift solutions like Savemap (this one for FF8)? I think you are underestimating the ambiguity problem; if FF7's content fills up the general namespace, future FF8 authors are going to be almost completely unable to "slap in references" as you put it, simply because all the generic names are taken by FF7's pages. At this point people will be so tired of pre-checking if a generic page name exists they'll start naming all their pages Something (FF8) or FF8/Something just to avoid the problem -- so if this is going to happen for half of the wiki anyway, why can't be nip the problem in the bud and do the same from the start (and get a very well-structured wiki to boot)?

Please use the subpage structure. You may be content with editing problems later as they pop up, but I see no reason to add extra work later, especially when we know it will become an issue. If there was a way for the wiki to assume that pages referenced from a FF7/ page were part of the same subpage (or at least try it), would that make things easier? (I still think this is a bit of self-constraint that should be left to the author though...) For now I will forcibly move any pages I find in the wrong hierarchy, with the old unclassified page left as a redirect. This is not a solution though, because if you keep writing like that for FF8 later we will have the same problem of pages referring to "a savemap" with no idea of which savemap. The only other alternative would be to have each and every "generic" page contain or point to data for each of the two games, i.e. while following a trail of FF7 links you would have to explicitly click "FF7" for every other link you follow. This is not what we (or at least I) want -- I prefer it much more if the viewer percieve FF7/ and FF8/ as two sets of wiki content who happen to share a common address (http://wiki.qhimm.com/). Just because FF8 pages don't yet exist, just because it works right now is IMO no excuse to clutter up the namespace with ambiguous pages and references. We need some form of disambiguation between FF7 pages and FF8 pages, why not let it be via subpages and be rid of the ambiguity problem once and for all?

Oh, and as for categories, by all means. Having a category for "FF7", "FF8", "Kernel", "File formats" etc. will make the wiki even more easily searchable, which is always a good idea (it's not a substitute for the required subpages-or-other-constructed-disambiguation-naming-scheme though). If you have a proposal for a better means of structure and disambiguation (than subpages), please present it and I'll take it under proper consideration. --Qhimm 23:44, 9 Mar 2005 (CST)

Ok, I think it's just a growing pain of going from a hirearchal database (Gears) to a relational one (Wiki) I did detach the tables, and I'm pretty sure all of this will be pretty good to go as soon as the table of contents fleshs out.

--Halkun 00:07, 10 Mar 2005 (CST)

Heh, we should probably bookmark discussions like these for when we let the public in... :) --Qhimm 00:23, 10 Mar 2005 (CST)