Retro Modding Wiki

2015-02-01 06:44:47 pm

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.

embyr_75

2015-02-01 06:48:36 pm

Metroid Wiki

Maybe switching to the QuestyCaptcha would be useful. Some simple Nintendo related questions shouldn't be too bad.

Aruki

2015-02-02 10:59:18 am

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.

Aruki

2015-02-03 09:03:22 am

Well I switched it to QuestyCaptcha. We'll see if it works I guess.

Aruki

Edit history:

Aruki: 2015-02-07 01:13:39 pm

2015-02-07 12:41:14 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.

DJGrenola

Edit history:

DJGrenola: 2015-02-07 01:22:49 pm

2015-02-07 01:20:58 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.

Aruki

Edit history:

Aruki: 2015-02-07 01:24:36 pm

2015-02-07 01:24:03 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.

Antidote

Edit history:

Antidote: 2015-02-07 01:25:09 pm

2015-02-07 01:24:28 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.

DJGrenola

2015-02-07 01:25:17 pm

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?

DJGrenola

2015-02-07 01:26:38 pm

any value in having things like filesize in there? perhaps not.

Antidote

Edit history:

Antidote: 2015-02-07 01:28:16 pm

2015-02-07 01:26:57 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.

Aruki

2015-02-07 01:28:30 pm

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.

Antidote

Edit history:

Antidote: 2015-02-07 01:32:59 pm

2015-02-07 01:32:36 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.

DJGrenola

2015-02-07 01:33:01 pm

you could use the name table entry to populate the description field though initially for files that have them.

Aruki

2015-02-07 01:33:39 pm

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.

arkarian

2015-02-07 01:34:50 pm

red chamber dream

you might want to put all this stuff in a database somewhere

Antidote

2015-02-07 01:35:11 pm

the wiki has a database *flees*

Antidote

2015-02-07 01:35:24 pm

And yeah, parax you're probably right

arkarian

2015-02-07 01:35:50 pm

red chamber dream

well yeah it would have to, but i mean one you control

dunno how much access wiki dbs give you

Antidote

Edit history:

Antidote: 2015-02-07 01:39:50 pm

2015-02-07 01:39:36 pm

practically none, other than viewing/editing pages.

arkarian

2015-02-07 01:40:00 pm

red chamber dream

that's what i figured

Aruki

2015-02-07 01:40:02 pm

Would that be much better than just having the tables? :s I dunno how we'd set that up on a wiki.

arkarian

Edit history:

arkarian: 2015-02-07 01:41:23 pm

2015-02-07 01:40:39 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

arkarian

2015-02-07 01:40:58 pm

red chamber dream

no idea if that's useful though, i just read this thread today

Antidote

2015-02-07 01:42:01 pm

We could probably setup an SQLite DB, but then that would require an external application to view it :/