OBD talk:Oni Binary Data

Incoming from my talk page. Could do with some further trimming (obviously). geyser 20:15, 30 January 2007 (CET)

Adding files to DAT

Hi Geyser,

Can you tell me please how I can add file to level.dat structure???

I have figured that I have to add something at the beginning of the file and at the end of the file.

But Oni still BLAMs. Can you tell me what is needed???

Or, can you tell me( or us, if possible) how can I import files into dat structure via OUP?

Thank you in advance

Loser

Hi. I suggest you to try and have a little patience or something. ^^

Oni modding (especially BINA) is modular, so why can't you deliver a few more quality BINAs?

Whatever you are up to, any modular modification will come in handy when you release something big.

I understand you're a bit like me: figure out something, have a little fun, move on...

But that's not very rewarding. For you, maybe, but not for "us"... Oh well.

ssg has tried adding files to a DAT before you, and failed. Have a look HERE if you haven't already...

There's a lot of stuff to take care of, and it's definitely not something you should do manually.

(not that it's impossible, but even if you manage to do it, it will be of no general use)

Alloc's OUP is almost there: a little while ago it was able to pack together whole level archives.

There seems to be a bug somewhere that causes incorrect packing of the textures, and can cause Blams, too.

You could get the latest version and help us figure out where exactly the repacking goes wrong...

So "I'm sorry. I can't help you now. No one can." ^^

geyser 17:09, 12 January 2007 (CET)

---

"ssg has tried adding files to a DAT before you, and failed."

Only 50% correct. I've failed to add a character to the level0.dat file, because Oni wants all named files in the dat-head/part2 in alphabetical order. First according to the file extension and then according to the file name. I didn't know that, when I've added the new character, so Oni crashed.

But it's not a problem to add unnamed files to dat file. F.e. I've added all WMDD's of the level0_tools.dat to the level0_final.dat without problems.

ssg

Nameless DAT importing... How useful is this, actually? Aren't nameless files always part of a named file's hierarchy?

Extra WMDDs is about where it ends, right? (OK, one can add lots of TXANs and animation TXMPs, but no ONCCs, definitely)

geyser

Big Blue Box Beta

PPPS: The Blue Box "Mac exe" contains some more debug messages than the "PC exe". Maybe you can hand over the level0_tools + level0_final + the "Mac exe" to EdT. Perhaps he can enable the level0_tools files (because there's no message to skip it). Btw, the readme of the Blue Box Oni says, that it is version 1.1 . Maybe we should check, if there are other version out there.

ssg

The BBBB (Big Blue Box Beta) is indeed interesting (particularly because of how it doesn't ignore the Tools),

but it's not as unASM-friendly as OMNI's port (which is basically a debug build: all functions and globak vars are named...)

AFAIK, SFeLi is concentrating on that one (OMNI's) but he could give the BBBB a try. Keep looking for other vers, sure.

Hidden doors in Warehouse

PPS: Remember the hidden doors of level 1? The gunk quads in front and behind door 11 (~ door position: -320 0 -450) are 18454 and 18455. If you open the AGQG file of level 1 with OUP and open these packages and change the last bytes from 00 00 10 02 FF FF FF FF to 02 00 10 02 FF FF FF FF, you can make the wall invisible (maybe you can hide it with env_show; I haven't tested that). Unfortunately you can't pass the door, because there's still another invisible wall. But I don't know the ID of it. (Package 31789 has the same points as package 18455, so I've changed it too, but no luck. I couldn't pass the door even though.) Plus the door has no doorframe, so it hangs in the air.

ssg

I'll have a look at the hidden doors in level1. Fixing them is all the more appealing as now we can fix the BNVs, too...

Thanks for the two IDs: they're a good start. I'll try to cath'em all (when I get some free time, heh).

Collision is probably defined separately from the visible geometry (in the AGQC rather than in the AGQG).

Unfortunately, env_show only works for "objects" (static bike, van, truck, etc). Same for env_texswap...

geyser 15:37, 26 January 2007 (CET)

---

File names

Btw, what does BNV stand for? IMO V = volume, because it is one. But B and N. Any ideas? Perhaps B = binary?

PPPPS: To SNDG (from BINA/Sound): Imo : It stands for Sound Geometry and not Sound Group. amb.OSBD and imp.OSBD are called up first. These link to grp.OSBD and this to a SNDD file. Imo SNDG doesn't call up the grp.OSBD directly.

Ssg 09:29, 25 January 2007 (CET)

I don't care too much about initials (BNV, SNDG, all that...). As for BNV, N (or NV) could stand for Navigation. B could stand for Bungie ^^

If you want to talk about specific files (e.g., SNDG), I'd recommend to use their respective talk pages. Why here, dammit?

And if you want to fix something that's obviously wrong (like that "sound group" thing), just go ahead ( !!! ).

geyser

Data types

Bitset

Oh, and another rant, about bitsets: once and for all, there is NO "0" bit

geyser

0 bit: It's just an info, that nothing happens when you write 0.

ssg

The "0 bit" info is misleading. All the bits in a bitset are cumulative

(and if they're all OFF, of course you get 0 = "nothing")

But you make it seem like the only valid ("possible") values are 0, 1, 2, 4, 8, etc.

(which is what is misleading: the only options are 1, 2, 4, 8, etc; each one of those options is either ON or OFF)

In other words, your list gives "everything OFF" too much of a special status. It's... yes, misleading.

geyser

Bitset: As the name say, it's a bitset. So it's IMO not misleading.

ssg

Re:Obviously, I don't want to argue about this forever. I'll reformulate when I get the chance.

My basic point is that there is no "0" bit, and no "option" corresponding to it, and that anything stating otherwise, e.g.

option 1; it's a bitset; the following options are possible (values in dec):
0  - none
1  - unknown
2  - ghost
4  - stairs up
8  - stairs down
16 - stairs
32 - unknown
64 - unknown
128- unknown

is... pick your own word. ^^

geyser 20:15, 30 January 2007 (CET)

Anyway, I'd suggest to leave "dec" alone altogether, and to write:

Option bitset 1
0x01  - unknown
0x02  - ghost
0x04  - stairs up
0x08  - stairs down
0x10 - stairs
0x20 - unknown
0x40 - unknown
0x80 - unknown

Love it or leave it, of course.

geyser 13:54, 31 January 2007 (CET)

OBD update

Now a question: where were we with the rehaul of OBD pages?

One thing to consider is that wikibooks (PDF dumps of whole namespaces) can't include images.

So converting hex screenshots to tables seems worthwhile indeed.

geyser

"Now a question: where were we with the rehaul of OBD pages?" Dunno. I've stopped it.

First you say I can do what I want, and when I do what I want, you say I have to hold on.

Ssg 16:36, 26 January 2007 (CET)

Before you resume your update of the OBD pages, could you give me a list of field types you'll be putting in there? Maybe we should discuss those a little bit. That was what I suggested when I "told you to stop". A exhaustive list of data types will be useful for OUP, too (new struct def format, patching engine...).

Another thing was our disagreement as for whether OBD table rows should be templated.

Templates have an advantage: alignment and other cell attributes can be set globally in a nice-looking way. Only actually informative data needs to be entered on the "client" page.

Templates have a drawback: unlike table rows, everything has to be on the same line (although one can hack around this, see Template:HexRow)

I also need your opinion (again, yes) on the templated tables (rather than GIFs) for the hex screenshots.

They're more mirror- and wikibook-friendly.

What do you think?

geyser 17:22, 26 January 2007 (CET)

OBD: You wanna discuss again? You have some questions again? I'm sorry, but IMO that are rhetorical questions. IMO you only accept the answers, you want to hear.

So I'm not interested in to discuss it any longer.

What about this: I update the missing files in my way (when I have time). And after that you can alter them in your way (f.e. images as hex).

ssg

Siiiiiiighhhhhh...

Please go ahead and update everything as you see fit. Just don't call me a dictator ^^

Be careful not to overwrite new information with older stuff, or anything like that.

I'd really appreciate if you put a list of field types HERE, for example.

IMO that's absolutely not "rhetorical". Whatever you think "rhetorical" means... ^^

geyser 20:15, 30 January 2007 (CET)

---

Something else

Something else: Level 1 Training, last room, where have to shoot the glass with the pistol.

The first fixture on the left side. The lowest glass. You can hide it with "env_show 3003 0"

But the AGQG package ID is 3058 (I've checked it, I can alter the glass, if I alter that package).

So where does Oni get the Information that the glass has the env_ID 3003?

It's not in the OBOA. And I couldn't find the 3003 in another file.

ssg

I'll have a look. Note that "3003" (as well as gunk IDs in other script commands) refers to a group of quads.

So you don't want to look at AGQG number 3003, obviously, but at something that lists several AGQG IDs together.

My a priori guess would be the ONOA, and the IDXA therein. 3003 could refer to the unknown ID stored inside an ONOA.

geyser 20:15, 30 January 2007 (CET)

Generic files

VCRA

That one is only used by M3GM (vertex normals and face normals), so it's not that generic.

No distinction depending on the role of the file.

geyser 20:15, 30 January 2007 (CET)

IDXA

Used by M3GM (1 lists triangles as strips, 2 assigns face normals to triangles) (1 has a specific format (high-bit))

Used by AKEV (role?)

Used by AKOT (role?)

Used by ONOA (role?)

Is that all?

geyser 20:15, 30 January 2007 (CET)

PNTA

Used by a few files, format seems to be invariant.

geyser 20:15, 30 January 2007 (CET)