User talk:Ssg

current entries are on the bottom of the page

old entries are out-commented

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 name 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={{{0|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 geyser 04:25, 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 embed 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) 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)