- Only the most recent entries are visible
- (older ones have been commented out).
- geyser 17:25, 18 November 2006 (CET)
- Thanks for keeping it short. :p
- ssg
- Thank you for cooperating
- (e.g., for taking the time to reply)
- I try to keep things organized, hope you like it.
- geyser 04:25, 18 November 2006 (CET)
- It's best if all talk page comments are signed,
- in case someone else wonders what's going on...
- ... and "who's who"
- geyser 04:25, 18 November 2006 (CET)
- Bold-faced lines are best achieved with the "definition" markup (leading ";")
- like this
- (the only limitation is that you can't use ":" normally)
- (and you have to be careful when indenting, too)
- geyser 04:25, 18 November 2006 (CET)
- I'd also recommend the use of hlines to break up not-too-related content
- (e.g., on the ABNA page, what was wrong with the hlines before the footer?)
- geyser 04:25, 18 November 2006 (CET)
- I also don't like "Translation" and "Meaning" at all [...]
- geyser
- You can change it if you want. Only one template to alter.
- ssg
- I will, thank you. ^^ But since the world's in motion...
- (I mean, templates will be split, renamed, etc...
- Any column names will do for now)
- (even "shpadoinkle" or "kalamazoo") (sorry ^^ )
- geyser 04:25, 18 November 2006 (CET)
- As for the "Bytes", I think I'd replace it with a type when applicable
- geyser
- Well, the type is stored indirectly in the "translation" column. So I'd prefer "bytes".
- ssg
- Illustrative examples are OK (I wouldn't say your examples are always very illustrative)
- But I would prefer to provide the actual information in a way that isn't tied to the example used
- (same as in a struct def, ideally)
- So "type" for me, definitely. The names "short", "long", "float", "char" ring an immediate bell,
- whereas looking at the "bytes" column, then at the "translation", then back...
- (I'm willing to give in to Delphi folks and capitalize those types : Short, Char, etc)
- (Also, I don't mind about String[X] rather than char[X] for strings of size X)
- geyser 04:25, 18 November 2006 (CET)
- As for Oni's internal types : I'd "define" extra types for file-ids and raw-addresses.
- Same as the OUP types and extensions. We've talked about that with Alloc, basically we need :
- 1 type for a DAT's ID, and another one for its level-ID
- 98 more types for DAT-links (ignoring the 16 defunct filetypes)
- 21 more types for RAW/SEP-links
- (1 for BINA, AKVA, OSBD, SNDD SUBT and TXMP; 2 for AGDB; 13 for TRAM)
- Tell me about any other types that come to your mind : we should "define" them too.
- (yes, I think we really need that, otherwise the info will be incomplete)
- geyser 04:25, 18 November 2006 (CET)
- I think the "long-with-high-bit" occurring, e.g., in the IDXA,
- is best viewed as two shorts... "Bitsets" are best viewed as chars.
- geyser 04:25, 18 November 2006 (CET)
- If the table row is a template (cf. "good idea" below),
- the name of a type could be a hyperlink to its "definition"
- (common page + anchor in that page).
- It's quite easy to set up, really.
- geyser 04:25, 18 November 2006 (CET)
- I think a good compromise would be to split the "OBD File Table" in two
- geyser
- Yes, that's a good idea. I'd suggest to take
{| WIDTH=100% BORDER=1 CELLSPACING=0 CELLPADDING=2 STYLE="border-style:solid; border-width:1px; border-collapse:collapse; empty-cells:show; background:#F9F9F9;"
|- ALIGN=CENTER BGCOLOR="#E9E9E9"
- as a basic "prettytable"-like template. Maybe we should call the template "wikitable" or something like that.
- ssg
- You misunderstood me as for the splitting.
- I meant to have nothing but that first line in the basic template : no header row.
- Some of your flags seem redundant to me, but I might be wrong. More, later.
- geyser 04:25, 18 November 2006 (CET)
- Actually, there are lots of table templates on Wikipedia and elsewhere.
- Not that we should pick from them (yours is fine), but of course we can ^^
- Since it's a very plain-looking table, I'd call the template
- ("...Header" to reflect that it's not a full set of table tags, just the opening)
- I'd call it Template:GrayTable... if we weren't so likely to change the wiki's bg color... :P
- And I'd have it look like this (with flexibility in mind) :
{|BORDER=1 CELLSPACING=0 CELLPADDING=2 STYLE="border-style:solid; border-collapse:collapse; empty-cells:show; background:#F9F9F9;" WIDTH={{{1|100%}}} ALIGN={{{2|center}}}
- Tell me what you think.
- geyser 04:25, 18 November 2006 (CET)
- Choose a good name. (Please don't use words like "fancy". It confuses more than it explains.)
- ssg
- I'm sorry for the misunderstanding, but the "fancification" was a joke.
- Not a good one, maybe, but a joke nonetheless ^^
- geyser 04:25, 18 November 2006 (CET)
- "Fancy" is not confusing, though.
- I think it unambiguously and accurately reflects the spirit of your endeavour :
- custom in a nice-looking way, somewhat stylish. No offence meant, of course.
- We'll choose a good name. Heck, I'll let you choose it. Be my guest.
- (I can always rename the template around as long as it's not widely used :P )
- geyser 04:25, 18 November 2006 (CET)
- The
! WIDTH=5% | Start || WIDTH=5% | Bytes || WIDTH=10% | Hex || WIDTH=10% | Translation || WIDTH=70% | Meaning
- I'd put in a template called f.e. "OBD_Table_Title_Row".
- (Same here. Choose a good name.)
- ssg
- I'd make it :
|- BGCOLOR="#E9E9E9"
! WIDTH=5% | Offset || WIDTH=5% | Type || WIDTH=10% | Raw Hex || WIDTH=10% | Value || WIDTH=70% | Description
- And I'll let you choose the name, again
- (|- BGCOLOR="#E9E9E9"
| Offset |
Type |
Raw Hex |
Value |
Description is fine by me)
- (maybe a bit confusing if we use "...Header" for the basic one)
- (yup, the basic one should be just
- geyser 04:25, 18 November 2006 (CET)
- On second thought, those wide tables will only be the most common OBD tables.
- but by no means the only ones used to document Oni's binary data.
- Dunno what objective would suit them. We want something short enough to type.
- Since these tables will converge with OUP's Struct Defs eventually,
- (e.g., the info in the "Meaning" column should be as light as in a struct def)
- maybe either Template:OBD Struct Header or Template:OBD Struct Def Header is best.
- Or Template:OBDstructHeader
- geyser 12:52, 18 November 2006 (CET)
- Oh, and then of course we'd have another template called, say, Template:OBD Struct Row
- (or Template:OBDstructRow)
- that would go like this :
|- ALIGN=center
|{{{1|Offset?}}}
|[[OBD:Data#{{{2|Data types}}}|{{{2|Type?}}}]]
|BGCOLOR="#{{{3|F9F9F9}}}" style="white-space:nowrap"|{{{4|Raw hex?}}}
|style="white-space:nowrap"|{{{5|Value?}}}
|ALIGN=left|{{{6|Description?}}}
- Another one for strings, say, Template:OBD Struct Row 2 or Template:OBDstructRow2 :
|- ALIGN=center
|{{{1|Offset?}}}
|[[OBD:Data#{{{2|Data types}}}|{{{2|Type?}}}]]
|BGCOLOR="#{{{3|F9F9F9}}}" COLSPAN=2 style="white-space:nowrap"|{{{4|String?}}}
|ALIGN=left|{{{5|Description?}}}
- Finally, an extra one for the "Below follows" thing, say, Template:OBD Struct Row 0 or Template:OBDstructRow0:
|- ALIGN=center BGCOLOR="#000000"
|COLSPAN=5|<FONT SIZE=2 COLOR="#FFFFFF">{{{1|Text?}}}<FONT>
- And that would be enough to get us started.
- Tell me if I forgot anything.
- geyser 12:52, 18 November 2006 (CET)
- [...] which is a semantic pleonasm BTW
- geyser
- But if I write "Below follows the second package" (because, f.e. the pic shows the second package),
- instead of "Below follows the first package", and it is the first package in the table,
- it wouldn't a semantic pleonasm any longer, right?
- (Unbelievable that you still know so much about that stuff.
- I remember that I heard something about that at school years ago.
- But I forgot all.)
- ssg
- I actively remember all the time ^^.
- Nice try, but both your examples up there are equally pleonastic (redundant).
- Simply because of "Below follows". Those two words are redundant of each other.
- (I formulated that line a bit differently on a few pages, most recently on ABNA)
- (It's really no big deal, but when one sees it often... Hm. Hehe. Just delete all this... ^^)
- geyser 04:25, 18 November 2006 (CET)
- And that's exactly my problem : no one will ever want to thumbnail them
- geyser
- I don't follow. What's exactly your problem?
- If you upload an image with 300x150, Wiki shows it with 300x150.
- Why do you care about so much, that "no one will ever want to thumbnail them".
- Sorry, but I don't get it.
- ssg
- Auto-thumbnailing to any size you specify in an article,
- along with auto-hyperlinking to the "image page"
- (possibly holding informative content or a redirect),
- is the main advantage of wiki-based media content.
- Your images make no use of that, which is why the point for having them wiki-based is weak.
- geyser 04:25, 18 November 2006 (CET)
- Another reason why, e.g., Wikipedia has all its media wiki-based
- is that it there's no user directories stored on the server alongside the wiki
- (something we do have on oni2.net, and "always will" : both run in parallel)
- geyser 04:25, 18 November 2006 (CET)
- Some wikis prevent the display of external images. We do not, and the main reason
- is the ability, e.g., for me to link to Oni's OST MP3 or SoE screenshots
- (all that resides on oni2.net, and takes no more time to load than if it was wiki-based, maybe less)
- That also makes the point for uploading "plain-transcluded" images rather weak.
- geyser 04:25, 18 November 2006 (CET)
- The inability to rename the images
- geyser
- You can rename them. (Why the heck do you want to rename them?)
- ssg
- You can not rename ("move") media files. I'm sorry, but it's true.
- You can only delete them and/or upload them with a new name.
- I want to be able to rename them because the current names are
- a (not too pretty) relict of your own site's nomenclature.
- I want to be able to rename them because that's part of the full-control editing you're aiming at.
- It's wrong to massively edit (and ultimately split/merge) a file and be tied by the name someone else gave it, long ago.
- geyser 04:25, 18 November 2006 (CET)
- lousy short-term flexibility
- geyser
- As I said: Split it and override the existing one. I can't see a problem here.
- ssg
- See above : that's not what I call overwhelming editorial freedom.
- geyser 04:25, 18 November 2006 (CET)
- Make it PNG rather than GIF
- geyser
- Yes, Wiki says: use png instead of gif, because gif supports only 256 colours.
- But: None of my hex screenshots uses more than 50 different colours.
- So it would be IMO really pretty stupid to change the file format without any need.
- ssg
- There are a few other reasons to use PNG instead of GIF
- It's open, not proprietary, but perhaps that's what we care about the least
- It allows for advanced transparence effects (OK, that doesn't apply here either)
- It compresses the images to much smaller sizes, despite the higher color depth.
- A high compression rate means more processor stress on the client side (peanuts)
- But the downloaded size is much smaller, which is especially felt by the server.
- How much is "much"? Well, it turns out that the PNG are about 70% smaller
- For instance, abna_a.gif takes up 5646 bytes.
- Converting it to PNG takes the size down to 1710 bytes.
- That's not much for a single download, of course.
- But it always helps to ease the load on the server, right?
- geyser 04:25, 18 November 2006 (CET)
- Capitalize the names according to the names of the actual files
- geyser
- Er... why should I do that? Are you trying to use a steamroller to crack a nut?
- ssg
- Dunno. We use properly capitalized extensions everywhere : page names, OUP, plain text...
- The only exception is your site, and while I can't make you rename your own images, ^^
- I'd rather the ones you upload didn't inherit the "inconsistent" lowercase names.
- I so wish you'd have asked before uploading all of them... If you only knew... ^^
- geyser 04:25, 18 November 2006 (CET)
- Whatever your "OBD Image" template is supposed to do, it's probably a bad idea.
- geyser
- Well, this has something to do with style.
- If f.e. someone changes the wiki background colour, so that it isn't longer white, you will have
- a centered header,
- an image with white background but with a max. width of 690px on the left,
- and a table with a width of 100 percent.
- That sucks. It doesn't look good.
- But if you put the white-backgrounded image in a white-backgrounded table with a width of 100 percent,
- it will look much better. (Try it if you don't believe me.)
- ssg
- Personally and generally, I don't give a crap about the nice looks as long as the content is there.
- And, as I've said, I'm colorblind, so I feel like leaving the color issues entirely to your expertise.
- So I guess we could say I do "believe" you in those matters (I mean web design in general).
- geyser 04:25, 18 November 2006 (CET)
- However, I've never seen a MediaWiki build with a non-white background : that'd be 100% vain.
- That is what would suck. Oni or no Oni, I don't think I could stand running a vain wiki.
- geyser 04:25, 18 November 2006 (CET)
- How you systematically stretch your tables to the page's width is not exactly fine by me, either.
- In many cases, stretching the content over a large screen looks like a waste of space
- (and I feel like left-aligning or centering them without stretching them, instead)
- (if not for the main OBD tables, at least the auxiliary ones are often quite small)
- (see BINA)
- geyser 04:25, 18 November 2006 (CET)
- It's nothing I can't live with, of course. Most of the time page-wide tables look nice.
- And I always have the possibility to customize an O table'sembed a "100%" table into a normal table.
- (I insist on that right : see my suggestion for the wiki-wide table template)
- (custom width and custom alignment : you have to allow for those)
- geyser 04:25, 18 November 2006 (CET)
- Oh, and as for the centered header : it doesn't have to be centered.
- The alignment is one of the template's parameters, by design.
- First, the longer files (e.g., ONCC) have a table of contents.
- (with the fields split up, even not too thematically, it allows one to
- jump from the top of the page to the region one is interested in).
- The header is supposed to fit alongside the TOC on a reasonably large monitors (see, e.g., CRSA)
- geyser 17:25, 18 November 2006 (CET)
- Second, even when there is no TOC, one can provide a few initial "words of wisdom".
- Something that introduces the reader to the general purpose of the file
- and outlines its layout in the most synthetic way (see, e.g., ONVL)
- or ONVC, or even OBD:ONWC:ONWC, although it certainly need reorganizing.
- geyser 17:25, 18 November 2006 (CET)
- Info on links, too : what kind of resources this file links to, as well as "what links here".
- All that infromation is IMO best presented before the detailed breakdown of the structure.
- Such a summary (very Wikipedia-like) would very well fit alongside the "header".
- Whenever there is a TOC, I'd still have the TOC alongside the header, though.
- geyser 17:25, 18 November 2006 (CET)
- I'd like to use the image template for the hex images (even if we don't need it now).
- ssg
- I have a few more considerations for you, and an alternative. Check out ABNA.
- geyser 04:25, 18 November 2006 (CET)
- We should have a zip file with all the current struct defs somewhere.
- ssg
- On svn.oni2.net, of course. In the same folder as the individual struct defs will be.
- We'll have to redefine all of them (see above, talk to Alloc) in the "near" future...
- They have to allow for unambiguous browsing of the file-system by OUP (e.g., patching).
- Starting from a named file (same name on all versions), the patcher should use
- nothing but version-independent information to browse the level-files.
- Then, and only then, can we create a "legal" patcher that works the same on every version
- and doesn't allow one to download all of Oni's resources for free.
- (I already stressed the other advantage of that system : modularity)
- geyser 04:25, 18 November 2006 (CET)
- Actually, it may sound crazy, but I feel like taking THIS experiment a bit further.
- geyser
- Well, if you have enough time, you can do that. Have fun. :p
- ssg
- I did it. It works. Check it out HERE or on ABNA.
- I didn't implement the black/gray outlines but I don't think we really need them.
- The markup takes up half as much space as the PNG (and 84% less than a GIF, fa fa fa! )
- The rendered HTML takes up more space than a PNG, but it's still less than half as big as a GIF.
- The editability is unrivaled.
- Doing those by hand takes a reasonable time, I'd say, because of the handy layout.
- For larger chunks, though, scripts may be in order.
- Since it's fully editable, you can omit the irrelevant stuff
- (e.g., senseless ASCII, confirmed garbage...)
- geyser 04:25, 18 November 2006 (CET)
- But I'd still appreciate if crucial files like AGQG were kept in sync with Oni Stuff...
- geyser
- I'm not sure I understand correctly what you want, but if we agree on the design,
- I'll adapt the html2wiki translator to that and update all file pages with the new code.
- Ssg 12:57, 17 November 2006 (CET)
- You got it right. I'm looking forward to that.
- geyser 04:25, 18 November 2006 (CET)
|