<- 12345 ->
^^
vv
List results:
Search options:
Use \ before commas in usernames
Edit history:
arkarian: 2015-02-07 02:03:30 pm
red chamber dream
if there's a good wiki api then you could automate it too

this one lets you embed a whole spreadsheet into the wiki http://www.mediawikiwidgets.org/Google_Spreadsheet ... but not sure how much formatting it allows
mediawiki does have an API built in, however I think it's RO by default.
Edit history:
Antidote: 2015-02-07 02:07:16 pm
That extension seems to largely depend on the settings of the doc, i.e if the doc allows free editing then you can edit it, however without a good live example you really can't tell.

Also that footer is hideous.
at the end of the day you can do it either way, if you want to take the wiki markup and convert it into something else it can certainly be done, it's just slightly more complicated that way round
Yeah, at some point we're going to have to make a compromise between accessibility and ease of editing.
Edit history:
arkarian: 2015-02-07 02:09:30 pm
red chamber dream
yeah for sure, just some thoughts i had while reading the thread

it just weirds me out as a programmer to have your primary source of data be a database you can't access easily
yeah both of those extensions are kinda ugly heh. If we can agree on the layout then changing it down the road might not end up being that much of an issue after all. Like DJ said it's certainly possible to take the page source and convert it back into a binary format.. it would be a pain but it's doable.
I'd just carry on with what you were going to do parax, I mean you've been the one doing all the work lol so you kind of have the right to do it your way
the point of the whole thing is collaboration though, I mostly just don't want to generate pages for everything and then have someone show up and go "oh why don't we do it this way you never thought of instead" and then I have to redo everything
red chamber dream
oh yeah, i don't even really care at all anyway. it's saturday morning and i have nothing else to do :)
Edit history:
Aruki: 2015-02-07 02:16:34 pm
I do think the way I was going to do it is probably fine though, I just want to make sure we know what the layout should be before we do it.

It sounds like the main issue at this point is whether we split by game or by pak. I'd rather split by pak but I can definitely see the advantages of splitting by game.

edit: and separate name tables - y/n? I'm thinking we would either have a separate table for named resources at the top of the page which would be completely automatically generated, followed by the main ToC (duplicating the named ones in both tables), which would have the description field pre-filled in with the names where applicable; or we would only have the main ToC table with the description field pre-filled in with the name.
the separate name table table never needs editing though does it? that's totally fixed, static data. so you'd probably never want to edit it in any meaningful way, so honestly I'd just leave that, it can be added later if it becomes important.

regarding split by PAK / split by game, you'll have less duplicated effort if you split by game because things like the fonts that show up repeatedly you'd have to label multiple times, but the tradeoff is that the table will get a lot bigger. there's also the issue that you have world PAKs and non-world PAKs and to some extent they contain completely different things, but you'd know more about that than I would.

(trying to remember which file actually has two name table entries for the same file ID, because that definitely happens somewhere)
that is true. Bah, this is more complicated than I thought it would be, lol.
Maybe what we should do is have a separate page for each format

"List of CMDL Files (Metroid Prime)"
"List of TXTR Files (Metroid Prime)"
"List of MREA Files (Metroid Prime)"
"List of SCAN Files (Metroid Prime)"

etc
i guess I can't see anything immediately wrong with doing it like that
although it does then definitely become harder to convert the tables into other formats because you end up with a bunch of pages
Edit history:
DJGrenola: 2015-02-07 02:43:10 pm
but then that's true of doing it by PAK also ... I dunno man
red chamber dream
List of CMDL Files (Metroid Prime.*)

that's not much harder than searching

List of CMDL Files
red chamber dream
i wouldn't worry about number of pages if you try to export, in other words
Honestly what would work out best is if we could have a centralized, editable database of assets, and have something that periodically automatically generates the other pages - for each pak as well as maybe other pages for more global lists. Then you could update it once and it would be updated across every page. Unfortunately I have no clue how to set that up.
Edit history:
DJGrenola: 2015-02-07 07:36:57 pm
all right how about I figure something out for that

no idea what yet lol but I'll think about it
if you wanna go for that, that'd be awesome. If you wanted to you could write a customized extension for it in PHP.
I'll look into it ... I may need some help with the games and PAK file formats that I don't actually have though (so everything except mp1 and mp2), somebody may have to generate me some lists of what's in those other PAKs or something like that but I'll figure something out for the gamecube stuff and then we can worry about the rest later.

not sure I want to modify the wiki software because the problem with doing that is that you tend to have to keep patching it when the wiki software is updated but yeah anyway i'll think of something
Yeah I can definitely do that. Just lemme know what you need/what format you need it in.
oh god when did this become a static thread