<- 12345 ->
^^
vv
List results:
Search options:
Use \ before commas in usernames
ConfirmEdit is installed, I've bumped into it once or twice myself. I assume the spambots have a few live people who are filling them out, or they're just smart enough to deal with MediaWiki's fairly basic math problem captchas.
Metroid Wiki
Maybe switching to the QuestyCaptcha would be useful. Some simple Nintendo related questions shouldn't be too bad.
I could try out some other things if you guys want. Restricting registrations certainly isn't ideal, but honestly given how small the userbase is it's not the worst idea ever since it would guarantee the wiki stays completely spam-free.
Well I switched it to QuestyCaptcha. We'll see if it works I guess.
Edit history:
Aruki: 2015-02-07 01:13:39 pm
looking for some quick feedback - I'd like to get some pages up on the wiki listing every unique file from each pak, and a text description of what that file actually is. For example, we could write that Metroid1/b2b41738.CMDL is Meta-Ridley, and that'd make it much easier for anyone looking for a particular asset to find it.

The plan is to write a quick program to parse every pak file from each game and generate a Wiki table for it, and then the descriptions could be filled in manually. The thing I'm looking for feedback on is layout. There are two options that I can see - either have every file in the same table, sortable, or split them off into separate tables based on resource type. Each pak would get its own page either way. What would you guys rather see?

edit: If anyone's got any input on that or on what other kinds of info should be on that table, please tell me now. I really don't want to have to generate these tables more than once.
Edit history:
DJGrenola: 2015-02-07 01:22:49 pm
some of the PAKs have tens of thousands of entries, do they not? wondering whether that might be too many to shove into one table. dunno though. you'll probably encounter similar problems no matter how you split them up.
Edit history:
Aruki: 2015-02-07 01:24:36 pm
Some of the MP3 ones do, yeah, but it's not as high as you'd think discounting duplicates. Like MP1 Metroid3.pak has 16000 files and a good 10k of those are duplicates. One of the MP3 paks has like 37k files.. and 20k of them are duplicates. We're obviously not gonna be listing duplicates, heh.

You're probably right though, which would mean splitting by asset type is probably the way to go.
Edit history:
Antidote: 2015-02-07 01:25:09 pm
I think the largest pak had something on the order of 4k, excluding dupes.

Yeah, breaking it up by type is a good idea, I also think we should list what paks they appear in, rather than the paks content.
ah that could be worse then.

what columns would you have in the table? file ID, asset type, name table entry (if present), description? anything else?
any value in having things like filesize in there? perhaps not.
Edit history:
Antidote: 2015-02-07 01:28:16 pm
Might be helpful, but otherwise I agree. It might also be a good idea to list how many times it appears in a particular pak, for verification purposes.
hmm, I'm not sure about the name table entry, mostly because 99% of file don't use it so it'd be empty on almost everything. Maybe we should have a separate table entirely for named resources and then list the regular ToC in the main table (repeating the named ones in both tables).

I'm thinking file ID, asset type (if needed - probably won't be if we split it?), and description. I'm also somewhat considering if we should have something indicating where a given resource is used, but I feel like that might take up too much space.. not to mention all the work that would be required to find all the places a resource is used in.

I don't think the sizes are necessary. Not super useful and it gets hairy when you start taking compression into account.
Edit history:
Antidote: 2015-02-07 01:32:59 pm
Excluding the name entry table is probably a good idea for the most part, we could notate which files are named in the related file format articles, since the list is extremely small it doesn't affect the article too drastically.
you could use the name table entry to populate the description field though initially for files that have them.
Uhh, I really really don't think it belongs in the file format articles.

Yeah DJ that's a good idea actually. I'm still kinda thinking it would be good to have both tables.
red chamber dream
you might want to put all this stuff in a database somewhere
the wiki has a database *flees*
And yeah, parax you're probably right
red chamber dream
well yeah it would have to, but i mean one you control

dunno how much access wiki dbs give you
Edit history:
Antidote: 2015-02-07 01:39:50 pm
practically none, other than viewing/editing pages.
red chamber dream
that's what i figured
Would that be much better than just having the tables? :s I dunno how we'd set that up on a wiki.
Edit history:
arkarian: 2015-02-07 01:41:23 pm
red chamber dream
you probably couldn't, but i was thinking of a separate db, just to have a place holding all the data that you can access quickly

since you mentioned building the tables or whatever was a pain
red chamber dream
no idea if that's useful though, i just read this thread today
We could probably setup an SQLite DB, but then that would require an external application to view it :/