OBD:File types: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
mNo edit summary |
||
Line 4: | Line 4: | ||
<B>@geyser: Stop destroying my artwork. Please wait until I've finished it. Btw., this site sucks totally.</B> | <B>@geyser: Stop destroying my artwork. Please wait until I've finished it. Btw., this site sucks totally.</B> | ||
Dear ssg, | |||
#"this site" is a wiki, so : | |||
#*it's ''nothing'' like a "site" | |||
#*it doesn't suck totally : it only feels like it does if you're misusing it | |||
#*even if it ''did'' suck totally, please note that I'm not the one technically running the MediaWiki engine. | |||
#*so ''that'' comment is not BTW at all, and it should have read '''@ Alloc : this site sucks totally.''' | |||
#Wiki pages are not the best place for private communication, but may I in turn ask you to ''please'' stop (note the "please") : | |||
#*Capitalizing common nouns (or other words) that are not part of acronyms or similar. You don't have any overcapitalization ''in'' your tables, so why should you have any elsewhere? | |||
#*Putting the word "File" (capitalized or at all) everywhere. We know they're files, not potatoes. I'd only put "file" or "files" when the grammatical construction requires it, and omit them otherwise. | |||
#*Creating files of the same type (namely, BINA) as standalone wiki pages. I strongly suggest the use of subpages. | |||
#Additionally, you shouldn't be offended by people experimenting on your work. There are two recommended attitudes : | |||
#*either your stuff is a "work of art", something perfect and complete (and what's more, you think it looks ugly when displayed on a wiki). In that case, just keep it on your site. We can provide minor feedback via mail or IM if needed, and your state-of-the-art database will be linked to from here as it is now. | |||
#*or you allow other people to reconsider the presentation of your work. If I think the big list of file types is not too convenient, I may feel like experimenting with a more hierarchical layout. If I think the <== and ==> links allowing one to browse ''only to the next and previous resource in alphabetical order'' is not right, I may try and add an alternative browsing scheme. | |||
#Actually, I wonder if porting your whole database to the wiki is much of a priority right now : adding data interpreters for known stuff to Alloc's OUP looks like a greatly needed task to me... | |||
#If it ''must'' be ported, I'd invite you to reconsider the ''way'' you do it : | |||
#*As you've noticed, your tables are, so far, the object on this wiki most prone to vandalism (or just unconsiderate edition). Luckily I'm someone you can reason with, but can you tell a dozen unidentified IPs to " stop destroying your "artwork" "? | |||
#*The major point here is that whereas some people will check their guesses before filling in an ''unknown'' field, others will have ''wrong guesses'' and screw up your tables in no time. | |||
#*Maintaining the whole database will be a pain even for someone who's 100% familiar with the existing information (and don't count on me to log in, check "recent changes", see that an unidentified IP has changed the interpretation of some field, load the reference, on your site, run Oni...). Maintenance here requires a quick response, you're the only one who can do it reliably, ''but'' need I remind you about your famous Oni-at-home-and-internet-at-the-university problem? Will you be able | |||
#*You're making a ''major reference'' (much larger in size than, say, the Combat move database) available for edition to the public. I only want to point out that every amendment to such a database should be required to go through a checking procedure. That long-term maintenance will be a problem. And that I will continue to look at the backup rather that on the wiki-powered version anyway... | |||
#Basically the way it happened back on the forum was fine, and it ''can'' be ported to the wiki. Here's my suggestion : | |||
#*Linking to the database on your site should be well enough, and actually better. We keep the Fyle-type hierarchy we already created, and on every page, we put a link to the corresponding page on your site ''and that's all'' (no duplicates of the GIFs, no duplicate of the hex breakdown) | |||
#*After browsing your site, if we think anything is wrong or incomplete on page such-and-such, we add a minor comment to an otherwise almost empty page (link to your reference version of the moment + our comments ''or guesses'' : occasional proofreading remarks, comments of the type "I ''think'' 0x###### is such-and-such") | |||
#*The reference source data stays out of reach on your server. | |||
The table below shows all of Oni's file types. | The table below shows all of Oni's file types. |
Revision as of 01:20, 31 December 2005
Main Page >> Oni Binary Data >> File Types
OK, I've tried to organize it a little bit. The first little table is in alphabetical order, and the other ones are thematic. The thematic grouping is subject to change and further hierarchisation.
@geyser: Stop destroying my artwork. Please wait until I've finished it. Btw., this site sucks totally.
Dear ssg,
- "this site" is a wiki, so :
- it's nothing like a "site"
- it doesn't suck totally : it only feels like it does if you're misusing it
- even if it did suck totally, please note that I'm not the one technically running the MediaWiki engine.
- so that comment is not BTW at all, and it should have read @ Alloc : this site sucks totally.
- Wiki pages are not the best place for private communication, but may I in turn ask you to please stop (note the "please") :
- Capitalizing common nouns (or other words) that are not part of acronyms or similar. You don't have any overcapitalization in your tables, so why should you have any elsewhere?
- Putting the word "File" (capitalized or at all) everywhere. We know they're files, not potatoes. I'd only put "file" or "files" when the grammatical construction requires it, and omit them otherwise.
- Creating files of the same type (namely, BINA) as standalone wiki pages. I strongly suggest the use of subpages.
- Additionally, you shouldn't be offended by people experimenting on your work. There are two recommended attitudes :
- either your stuff is a "work of art", something perfect and complete (and what's more, you think it looks ugly when displayed on a wiki). In that case, just keep it on your site. We can provide minor feedback via mail or IM if needed, and your state-of-the-art database will be linked to from here as it is now.
- or you allow other people to reconsider the presentation of your work. If I think the big list of file types is not too convenient, I may feel like experimenting with a more hierarchical layout. If I think the <== and ==> links allowing one to browse only to the next and previous resource in alphabetical order is not right, I may try and add an alternative browsing scheme.
- Actually, I wonder if porting your whole database to the wiki is much of a priority right now : adding data interpreters for known stuff to Alloc's OUP looks like a greatly needed task to me...
- If it must be ported, I'd invite you to reconsider the way you do it :
- As you've noticed, your tables are, so far, the object on this wiki most prone to vandalism (or just unconsiderate edition). Luckily I'm someone you can reason with, but can you tell a dozen unidentified IPs to " stop destroying your "artwork" "?
- The major point here is that whereas some people will check their guesses before filling in an unknown field, others will have wrong guesses and screw up your tables in no time.
- Maintaining the whole database will be a pain even for someone who's 100% familiar with the existing information (and don't count on me to log in, check "recent changes", see that an unidentified IP has changed the interpretation of some field, load the reference, on your site, run Oni...). Maintenance here requires a quick response, you're the only one who can do it reliably, but need I remind you about your famous Oni-at-home-and-internet-at-the-university problem? Will you be able
- You're making a major reference (much larger in size than, say, the Combat move database) available for edition to the public. I only want to point out that every amendment to such a database should be required to go through a checking procedure. That long-term maintenance will be a problem. And that I will continue to look at the backup rather that on the wiki-powered version anyway...
- Basically the way it happened back on the forum was fine, and it can be ported to the wiki. Here's my suggestion :
- Linking to the database on your site should be well enough, and actually better. We keep the Fyle-type hierarchy we already created, and on every page, we put a link to the corresponding page on your site and that's all (no duplicates of the GIFs, no duplicate of the hex breakdown)
- After browsing your site, if we think anything is wrong or incomplete on page such-and-such, we add a minor comment to an otherwise almost empty page (link to your reference version of the moment + our comments or guesses : occasional proofreading remarks, comments of the type "I think 0x###### is such-and-such")
- The reference source data stays out of reach on your server.
The table below shows all of Oni's file types.
|
Misc files
Main Page >> Oni Binary Data >> File types
Unsorted
Type | Description | Notes |
---|---|---|
BINA | Binary Data | Start file |
FILM | Film | - |
IDXA | Index Array | - |
M3GA | Geometry Array | - |
M3GM | Geometry | - |
Mtrl | Material | 0 byte file |
OBAN | Object Animation | - |
PNTA | 3D Point Array | - |
SNDD | Sound Data | - |
TXAN | Texture Map Animation | - |
TXCA | Texture Coordinate Array | - |
TXMB | Texture Map Big | - |
TXMP | Texture Map | - |
VCRA | 3D Vector Array | - |
Message files
Type | Description | Notes |
---|---|---|
IGPA | IGUI Page Array | - |
IGPG | IGUI Page | - |
IGSA | IGUI String Array | - |
IGSt | IGUI String | - |
IPge | Item Page | not in all levels |
OPge | Objective Page | - |
PSpc | Part Specification | - |
TSFF | Font Family | 0 byte file |
TxtC | Text Console | - |
Defunct files
|
|
Level 0 files
|
|
Level files
Unsorted
|
|
Character files
|
|
BIG table
Main Page >> Oni Binary Data >> File types
- BLAH* means that there are no BLAH files in Oni's binaries and that they're probably defunct (same as
BLAHabove)
|
|
Main Page >> Oni Binary Data >> File types