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 catch'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)

I've had a look at those doors. Rather than making them invisible (what for? no one said invisible walls don't block you), I made those walls into a floor and ceiling, by swapping two pairs of vertices.

For the floor, I edited the AGQC accordingly. Since the now-horizontal quad still thought it was a wall, I had to (un)set the appropriate flag(s) in the bitset.

It looks and feels quite nice since there is a doorsill now. Wonder if pathfinding will work when the grid is fixed...

Is there any way to look up the ID of a quad in Oni other than by browsing env_highlight_gq values?

I'm interested in the quad just above the original 18454, but couldn't find it after a quick search.

geyser 12:05, 1 February 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 hinting 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... is... whatever. 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)

Oh, and a priori I don't know WTF "ghost" is, so in case you know better, a few words of wisdom are always welcome.

geyser 13:56, 31 January 2007 (CET)

ghost = something you can't see + touch. So a ghost GQ is invisible and not solid.

Ssg 13:13, 1 February 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.

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)

OK, I found where the 3003 is mapped to 3058 etc. I'd have been quicker if you hadn't flagged AKEV as "done" :P

Because it's in the AKEV. Well, not in the AKEV "selbst", but in its specific IDXA.

(but they're just links, of course, so we don't consider them as unknown AKEV data, right? ^^ )

Anyway. The first IDXA lists the quads (AGQG, AGQC and AGQR entries) that can be turned on and off.

The second IDXA lists the "gunk" IDs in parallel. The same "gunk" ID can be assigned to several quads.

The two IDXA can be used for two-way lookup. Only gunk -> quad is used when you use env_show etc.

geyser 12:05, 1 February 2007 (CET)

---

Cool. Thanks.

Ssg 13:21, 1 February 2007 (CET)

---

As for the ONOA, that one is related to the unknown field of the AGQG (the one which is not always 0xFFFFFFFF).

That field is an object ID, looked up in the ONOA. Several quads can belong to the same object (same ID).

The IDXA next to the ID (in the ONOA) lists the AGQG belonging to every object. So, two-way lookup.

The high byte of the ID is an object type. 0x05 is furniture, 0x03 is doorframe, 0x0D is trigger guide, 0x0F is console, etc.

geyser 12:05, 1 February 2007 (CET)

---

I figured that out yesterday too. 0E is turret. And that's it. There're no others. The first 2 bytes are the old file ID. It's the same as in the BINA files.

Why Oni needs this file (ONOA)? Any idea. IMO Oni needs only the door entries, because if you disable them, the doors aren't any longer solid. But if I disable the other objects I can't see an effect.

Ssg 13:21, 1 February 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 (1 lists script-hideable quads) (2 lists the IDs used by env_show etc)

Used by ONOA (an "object ID" is associated to an IDXA listing the AGQG of that object)

Used by AKOT (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)