OniGalore - User contributions [en]

User:Mai X

2025-10-09T19:12:49Z

Mai X: Corrected occupation...

{| class="wikitable" align="center" width=290px
!About me
|-
|style="text-align: center;"|https://konoko.oni2.net/cila_avatar.PNG
full version of avatar [http://konoko.oni2.net/%5BImages%5D/%5BSynergia%5D/%5BArts%5D/cila_art.PNG here]
 
 
{|class="wikitable" align="center" width=290px
!General info
|-
|style="text-align: left;"| '''Nickname:''' Mai-X, Konoko
|-
|style="text-align: left;"| '''Real name:''' Cila <code>['saila]</code>
|-
|style="text-align: left;"| '''Age:''' 18
|-
|style="text-align: left;"| '''Gender:''' Female
|-
|style="text-align: left;"| '''Orientation:''' Ficto
|}
{|class="wikitable" align="center" width=290px
!Biological info
|-
|style="text-align: left;"| '''Diseases:''' Epileptic seizures
|-
|style="text-align: left;"| '''Last time occurred:''' 05.10.2025
|}
{|class="wikitable" align="center" width=290px
!Personal info
|-
|style="text-align: left;"| '''Preferences:''' Acting, Music, 3D-modelling, Archiving data, Digitizing analog audio/video
|-
|style="text-align: left;"| '''Occupation:''' VGTRK (voiceover actress, camera crew)
|-
|style="text-align: left;"| '''Love:''' [http://konoko.oni2.net/garbage/scaramouche.PNG Scaramouche] (from [https://genshin-impact.fandom.com/wiki/Scaramouche Genshin Impact])
|-
|style="text-align: left;"| '''Contact (e-mail):''' [mailto:maihasegawa17@gmail.com maihasegawa17@gmail.com]
|}
{|class="wikitable" align="center" width=290px
!Current Projects
|-
|style="text-align: left;"| '''Oni related:''' NG Graphics for Oni (see section below this table for all demos)
|-
|style="text-align: left;"| '''Personal:''' Panasonic NV-M40 complete restoration, Sony VAIO P video playback enhancements
|-
|style="text-align: left;"| '''Work:''' Voiceovering in VGTRK
|}
|}

 
'''Name:'''
 
Okay... it's true, that my name is Cila... really... Reads as <code>['saila]</code> with a stress on first syllable...

 

'''Epilepsy:'''
 
Yeah... I have seizures... so, my main weakness is flashing light... And after our voiceovering session in InterMediA (at 17.12.2022) we had a "party"... with f**king strobes! Everyone were having fun... before my epileptic seizures occurred...
 
Ah... it's complicated... excessive emotionality, depression, nightmares... all that are consequences of epilepsy... whatever, seizures don't happen too frequently (usually when any conditions affect me), so I can live with them...

 

'''Archiving:'''
 
I have a private archiving system of 3 units in 3 independent places... I use it for my digitized copies of VHS/Beta/Video8/MiniDV videos, Compact Cassette audios and some old software (Lightscape, 3D Studio, BFW, MotionDV Studio, etc.)...
I've used it for storing diff... ah... whatever... forget what I said...

 

'''Current project:'''
 
For now I'm working on graphics update for Oni... It includes lighting system update, normal mapping support, pixel shaders (for camera filter effects), dynamic shadows and unlimited world space... This project is going too slow, because my seizures got worse, but I'll try to get this project done as fast as I can... Try to guess, how that graphical updates were implemented... I'll wait for any answers via e-mail or Discussions here... For now I've finished demo video of my update ([http://konoko.oni2.net/%5bVideos%5d/OniDemoChief%20(full,%20fixed).MOV Demo video] and [http://konoko.oni2.net/%5bImages%5d/NG_Oni.png Demo image])... I used Master Chief model as a character model, because I've not found any high-poly or realistic enough models of Konoko... And Chief is still related to Bungie, so I used him as a player character for my demo...
 
For now, I'm working on NG-ing the ManPlant level... When it will be ready, I'll make a video comparison... It'll show 2 my versions of the engine: Light-weight version with only 2 implemented features (8192x8192 textures and multiplicative-blended OGL lightmaps) and NG version with completely new GFX, procedural animations for characters, IK and "playable" vehicles...
 
 
If anybody have '''any''' hi-res textures for Oni levels ('''any''' level), please send me them through G-Drive (via e-mail or "Discussion" page here)... I'm '''not''' speaking about hi-res textures, that are hosted on Mod Depot (I've already downloaded all of them)...
 
 
 
 
 
Feel free to discuss any of sections (via "Discussion" page or e-mail)... Please, don't even try to write me in Discord... It is '''blocked''' in Russia... If you want to write me something, use e-mail or "Discussion" page here...
 
 
 
''Cila''
 
 
19:12, 9 October 2025 (UTC)

[[Category:Userspace]]

User:Mai X

2025-10-09T19:11:34Z

Mai X: L-T-O + work project...

{| class="wikitable" align="center" width=290px
!About me
|-
|style="text-align: center;"|https://konoko.oni2.net/cila_avatar.PNG
full version of avatar [http://konoko.oni2.net/%5BImages%5D/%5BSynergia%5D/%5BArts%5D/cila_art.PNG here]
 
 
{|class="wikitable" align="center" width=290px
!General info
|-
|style="text-align: left;"| '''Nickname:''' Mai-X, Konoko
|-
|style="text-align: left;"| '''Real name:''' Cila <code>['saila]</code>
|-
|style="text-align: left;"| '''Age:''' 18
|-
|style="text-align: left;"| '''Gender:''' Female
|-
|style="text-align: left;"| '''Orientation:''' Ficto
|}
{|class="wikitable" align="center" width=290px
!Biological info
|-
|style="text-align: left;"| '''Diseases:''' Epileptic seizures
|-
|style="text-align: left;"| '''Last time occurred:''' 05.10.2025
|}
{|class="wikitable" align="center" width=290px
!Personal info
|-
|style="text-align: left;"| '''Preferences:''' Acting, Music, 3D-modelling, Archiving data, Digitizing analog audio/video
|-
|style="text-align: left;"| '''Occupation:''' InterMediA Studio (voiceover actress, camera crew)
|-
|style="text-align: left;"| '''Love:''' [http://konoko.oni2.net/garbage/scaramouche.PNG Scaramouche] (from [https://genshin-impact.fandom.com/wiki/Scaramouche Genshin Impact])
|-
|style="text-align: left;"| '''Contact (e-mail):''' [mailto:maihasegawa17@gmail.com maihasegawa17@gmail.com]
|}
{|class="wikitable" align="center" width=290px
!Current Projects
|-
|style="text-align: left;"| '''Oni related:''' NG Graphics for Oni (see section below this table for all demos)
|-
|style="text-align: left;"| '''Personal:''' Panasonic NV-M40 complete restoration, Sony VAIO P video playback enhancements
|-
|style="text-align: left;"| '''Work:''' Voiceovering in VGTRK
|}
|}

 
'''Name:'''
 
Okay... it's true, that my name is Cila... really... Reads as <code>['saila]</code> with a stress on first syllable...

 

'''Epilepsy:'''
 
Yeah... I have seizures... so, my main weakness is flashing light... And after our voiceovering session in InterMediA (at 17.12.2022) we had a "party"... with f**king strobes! Everyone were having fun... before my epileptic seizures occurred...
 
Ah... it's complicated... excessive emotionality, depression, nightmares... all that are consequences of epilepsy... whatever, seizures don't happen too frequently (usually when any conditions affect me), so I can live with them...

 

'''Archiving:'''
 
I have a private archiving system of 3 units in 3 independent places... I use it for my digitized copies of VHS/Beta/Video8/MiniDV videos, Compact Cassette audios and some old software (Lightscape, 3D Studio, BFW, MotionDV Studio, etc.)...
I've used it for storing diff... ah... whatever... forget what I said...

 

'''Current project:'''
 
For now I'm working on graphics update for Oni... It includes lighting system update, normal mapping support, pixel shaders (for camera filter effects), dynamic shadows and unlimited world space... This project is going too slow, because my seizures got worse, but I'll try to get this project done as fast as I can... Try to guess, how that graphical updates were implemented... I'll wait for any answers via e-mail or Discussions here... For now I've finished demo video of my update ([http://konoko.oni2.net/%5bVideos%5d/OniDemoChief%20(full,%20fixed).MOV Demo video] and [http://konoko.oni2.net/%5bImages%5d/NG_Oni.png Demo image])... I used Master Chief model as a character model, because I've not found any high-poly or realistic enough models of Konoko... And Chief is still related to Bungie, so I used him as a player character for my demo...
 
For now, I'm working on NG-ing the ManPlant level... When it will be ready, I'll make a video comparison... It'll show 2 my versions of the engine: Light-weight version with only 2 implemented features (8192x8192 textures and multiplicative-blended OGL lightmaps) and NG version with completely new GFX, procedural animations for characters, IK and "playable" vehicles...
 
 
If anybody have '''any''' hi-res textures for Oni levels ('''any''' level), please send me them through G-Drive (via e-mail or "Discussion" page here)... I'm '''not''' speaking about hi-res textures, that are hosted on Mod Depot (I've already downloaded all of them)...
 
 
 
 
 
Feel free to discuss any of sections (via "Discussion" page or e-mail)... Please, don't even try to write me in Discord... It is '''blocked''' in Russia... If you want to write me something, use e-mail or "Discussion" page here...
 
 
 
''Cila''
 
 
19:24, 30 April 2025 (UTC)

[[Category:Userspace]]

User talk:Mai X

2025-05-15T20:56:38Z

Mai X:

==Projects==
===Graphical updates===
That's an [http://konoko.oni2.net/%5bImages%5d/NG_Oni.png impressive example] you got there. As if it was made in blender. Does it use a HD mod package for the training level?

I can only imaging that you modified the source code and compiled you own executable. Or maybe its part of Oni X or a fork? I didn't follow the engine modding on discord as they pretty much only (re-)added known bug-fixes?

Anyway, keep us updated, okay? :) --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 16:39, 24 November 2024 (UTC)

:Yeah, I used [http://mods.oni2.net/node/92 this] texture pack for my update... I made normal maps from some of textures with [https://www.smart-page.net/smartnormal/ this] service... But I've not used Blender for any stage of making my updates (especially, not for rendering)... I've used Autodesk Softimage 2015 for assigning materials and shaders... But rendering was done in my own version of engine (BFW-17) with deep code modifications... I don't support OniX in any way (contributing to it or forking it), so I'll not be using their engine version or forking it for my modifications...
:For now, I'm about to finish a small demo video of my graphical updates...

:Of course, I'll keep you updated... At least, I'll try to do it as much as I can... --[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 19:26, 24 November 2024 (UTC)

I'm impressed too! Your work looks very promising. What sort of plans do you have for the future? P.S.: Wasn't Konoko HD Armor high-poly enough for you? --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 21:59, 28 November 2024 (UTC)

:For now, my plan is just to have some rest... Plans for my updates: add better HDR support, implement Autodesk Scaleform for HUD and menus (instead of textures + 9-slice), add JPEG and PNG-ZIP texture compression support, implement GDF compression with LZMA-2... P.S.: Chief model has bundled normal maps with it, has over 60 000 polygons and has 4096x4096 uncompressed textures... HD Konoko is not so HQ as that model... --[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 07:28, 1 December 2024 (UTC)

Today I found the time to watch the video you added. Great work!

Unfortunately, the msVo encoded audio didn't play so for the fun of it, here's [http://paradox.oni2.net/wiki/user/Mai_X/talk/Mai_X_OniDemoChief_Mai_X_at_the_new_edge_of_modding.mp4 another version]. ^_^

Like Iritscen said, hopefully you can add Mai (package 26000 [http://paradox.oni2.net/wiki/user/Mai_X/talk/26000_Konoko_HD_Armor.png Konoko HD Armor]) in another iteration of the scene. It's not super highpoly but for Oni's standards it's quite decent. You probably you really wanted to make a point about the high poly count with master chief. Though I cannot stop feeling he is still to much of an ''alien'' there. --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 19:12, 18 December 2024 (UTC)

:The original music is called "Velta Theme" from Synergia OST... I've re-encoded it to MP3, so you can get it [http://konoko.oni2.net/%5bMusic%5d/Velta%20Theme.MP3 here]...
:Your version is even better, than mine... Thank you... You've got the "atmosphere" of the video completely right...
:I'll try to use that model of "HD" Konoko in my next video (featuring ManPlant level; info is on main page)... --[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 06:43, 6 May 2025 (UTC)

==Let us cheer you up*==
You enrich society in many ways. But first of all you enrich society by simply being not an ignorant asshole. But for that you need to stay alive.

'''Even if nobody tells you - and that proofs even more that your presence is needed.'''

You haven’t founded a family yet? Is that what your parents expect from you? So what? You can still do that later. For now, it means you are still more free to be a [https://www.deviantart.com/ deviant], an unconventional ("eccentric") and creative person.

I’m not really a friend of geyser, never met him in person, but I know him good enough by our talks to say that I deeply respect him. He was really happy about you when you joined this place and to work with you together. When he said you are a good and capable person, I had no doubt that you are.

"Why I’m alive." That's the 100 million dollar question most people have to think through at some time point in their life.

Committing suicide helps nobody. If someone tells you so, *punch that <s>asocial</s> '''antisocial mobbing bastard''' hard in the face.

(Of course, this wasn't an instruction. It was meant to cheer you up and to better let you hold a ''righteous grudge'' against others, than a self-destructive, imaginary one against yourself.)
--[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 07:58, 29 March 2023 (CEST)

Oh... thank you for that... you and GeySer... only you two can understand me in such moments... Now I feel a little bit better (no suicidal thoughts anymore)... Now I'm trying to stop myself from going to St. Pet. and destroying RAIDs...
--[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 09:32, 29 March 2023 (CEST)

:Sometimes, in order to be true to ourselves, we have to take a course that doesn't satisfy our parents' wishes. It's more common than you think. You still have plenty of time to figure out what path you want to take in life. And in the end, your parents probably just want to see you succeed, so if you do that, eventually they'll be happy. P.S.: I've kept all my computer files since my first Mac in 1993 ;-) --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 22:15, 29 March 2023 (CEST)

::Maybe... maybe that will happen... About archiving: I started it when I was 12, after accidental destruction of Seagate ST32132A (HDD from my first PC)... --[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 20:40, 30 March 2023 (CEST)

:::Okay, so starting at the same age as me then :-) I've been lucky; I've lost HDs but never any data that wasn't in another place too. These days I have redundant backups of all my data on local HDs and in the cloud. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 22:28, 30 March 2023 (CEST)

==OBD updates==
Thanks for your work on those pages, you've made some good edits! I was surprised to see so many mistaken inclusions of 0xDEAD space at the ends of types, and had to investigate. It looks like confusion sometimes slipped in during the process of editing a page. For instance [[Special:Permalink/4457|this revision]] of ONCV listed the final bytes starting at 0x4C as 32-byte alignment filler, but the next edit by Ssg wiped out geyser's description and simply called them "unused". Perhaps Ssg and other editors knew what they were, but no editors thought to write "alignment padding" instead of "unused" for that range, which is misleading for the reader.

Anyway, I just have one question: are you planning to fill in those offsets where you added a new field but placed "----" for the address? --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 19:36, 12 May 2025 (UTC)
:I won't leave those "----" for addresses, of course... I'll re-calculate those addresses right after I'll finish cleaning up 0xDEADs and renaming not only paddings back to "padding", but also all "int" to "'''u'''int" where it's needed...--[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 21:51, 12 May 2025 (UTC)
::Okie. Don't over-work yourself :-) --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 21:56, 12 May 2025 (UTC)
::For the record, here are the pages with added fields that have "----" for addresses: OBD:Mtrl, OBD:Impt, <strike>OBD:ENVP</strike>, OBD:AKEV. Maybe there are others, but those are the ones I noticed. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 22:02, 13 May 2025 (UTC)
:::Update: I realized there was room for improvement/clarification on ENVP, so while I was working on that I filled in the offsets as well. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 23:26, 13 May 2025 (UTC)
::As I'm looking over ONCC, I noticed the note "overridden by char's MELE profile if possible", but I'm not seeing that in the code. In fact it looks like the MELE's "dazed" fields are ignored by Oni entirely. There are various references to them in the editor and importer code, but I don't see where the game logic looks at them. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 15:54, 14 May 2025 (UTC)
:::<code>ONI_Character.h, line 167</code>... It is stated in the dev's comment...--[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 21:29, 14 May 2025 (UTC)
::::Oh, if only we could rely on developers' comments to be accurate ;-) You'll notice that the comment right above that one is misleading too, since not all ONCCs have a <code>turning_nimbleness</code> of 1.0 (see my note on that field on OBD:ONCC). Anyway, BWest's intention might have been to allow MELE to override the dazed fields, but it seems they never got around to it. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 14:47, 15 May 2025 (UTC)
:::::I'm sorry... I forgot to trace that field through the code, like I usually do with other fields...--[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 20:56, 15 May 2025 (UTC)

User talk:Mai X

2025-05-14T21:30:32Z

Mai X:

User talk:Mai X

2025-05-14T21:29:50Z

Mai X:

==Projects==
===Graphical updates===
That's an [http://konoko.oni2.net/%5bImages%5d/NG_Oni.png impressive example] you got there. As if it was made in blender. Does it use a HD mod package for the training level?

I can only imaging that you modified the source code and compiled you own executable. Or maybe its part of Oni X or a fork? I didn't follow the engine modding on discord as they pretty much only (re-)added known bug-fixes?

Anyway, keep us updated, okay? :) --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 16:39, 24 November 2024 (UTC)

:Yeah, I used [http://mods.oni2.net/node/92 this] texture pack for my update... I made normal maps from some of textures with [https://www.smart-page.net/smartnormal/ this] service... But I've not used Blender for any stage of making my updates (especially, not for rendering)... I've used Autodesk Softimage 2015 for assigning materials and shaders... But rendering was done in my own version of engine (BFW-17) with deep code modifications... I don't support OniX in any way (contributing to it or forking it), so I'll not be using their engine version or forking it for my modifications...
:For now, I'm about to finish a small demo video of my graphical updates...

:Of course, I'll keep you updated... At least, I'll try to do it as much as I can... --[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 19:26, 24 November 2024 (UTC)

I'm impressed too! Your work looks very promising. What sort of plans do you have for the future? P.S.: Wasn't Konoko HD Armor high-poly enough for you? --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 21:59, 28 November 2024 (UTC)

:For now, my plan is just to have some rest... Plans for my updates: add better HDR support, implement Autodesk Scaleform for HUD and menus (instead of textures + 9-slice), add JPEG and PNG-ZIP texture compression support, implement GDF compression with LZMA-2... P.S.: Chief model has bundled normal maps with it, has over 60 000 polygons and has 4096x4096 uncompressed textures... HD Konoko is not so HQ as that model... --[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 07:28, 1 December 2024 (UTC)

Today I found the time to watch the video you added. Great work!

Unfortunately, the msVo encoded audio didn't play so for the fun of it, here's [http://paradox.oni2.net/wiki/user/Mai_X/talk/Mai_X_OniDemoChief_Mai_X_at_the_new_edge_of_modding.mp4 another version]. ^_^

Like Iritscen said, hopefully you can add Mai (package 26000 [http://paradox.oni2.net/wiki/user/Mai_X/talk/26000_Konoko_HD_Armor.png Konoko HD Armor]) in another iteration of the scene. It's not super highpoly but for Oni's standards it's quite decent. You probably you really wanted to make a point about the high poly count with master chief. Though I cannot stop feeling he is still to much of an ''alien'' there. --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 19:12, 18 December 2024 (UTC)

:The original music is called "Velta Theme" from Synergia OST... I've re-encoded it to MP3, so you can get it [http://konoko.oni2.net/%5bMusic%5d/Velta%20Theme.MP3 here]...
:Your version is even better, than mine... Thank you... You've got the "atmosphere" of the video completely right...
:I'll try to use that model of "HD" Konoko in my next video (featuring ManPlant level; info is on main page)... --[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 06:43, 6 May 2025 (UTC)

==Let us cheer you up*==
You enrich society in many ways. But first of all you enrich society by simply being not an ignorant asshole. But for that you need to stay alive.

'''Even if nobody tells you - and that proofs even more that your presence is needed.'''

You haven’t founded a family yet? Is that what your parents expect from you? So what? You can still do that later. For now, it means you are still more free to be a [https://www.deviantart.com/ deviant], an unconventional ("eccentric") and creative person.

I’m not really a friend of geyser, never met him in person, but I know him good enough by our talks to say that I deeply respect him. He was really happy about you when you joined this place and to work with you together. When he said you are a good and capable person, I had no doubt that you are.

"Why I’m alive." That's the 100 million dollar question most people have to think through at some time point in their life.

Committing suicide helps nobody. If someone tells you so, *punch that <s>asocial</s> '''antisocial mobbing bastard''' hard in the face.

(Of course, this wasn't an instruction. It was meant to cheer you up and to better let you hold a ''righteous grudge'' against others, than a self-destructive, imaginary one against yourself.)
--[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 07:58, 29 March 2023 (CEST)

Oh... thank you for that... you and GeySer... only you two can understand me in such moments... Now I feel a little bit better (no suicidal thoughts anymore)... Now I'm trying to stop myself from going to St. Pet. and destroying RAIDs...
--[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 09:32, 29 March 2023 (CEST)

:Sometimes, in order to be true to ourselves, we have to take a course that doesn't satisfy our parents' wishes. It's more common than you think. You still have plenty of time to figure out what path you want to take in life. And in the end, your parents probably just want to see you succeed, so if you do that, eventually they'll be happy. P.S.: I've kept all my computer files since my first Mac in 1993 ;-) --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 22:15, 29 March 2023 (CEST)

::Maybe... maybe that will happen... About archiving: I started it when I was 12, after accidental destruction of Seagate ST32132A (HDD from my first PC)... --[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 20:40, 30 March 2023 (CEST)

:::Okay, so starting at the same age as me then :-) I've been lucky; I've lost HDs but never any data that wasn't in another place too. These days I have redundant backups of all my data on local HDs and in the cloud. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 22:28, 30 March 2023 (CEST)

==OBD updates==
Thanks for your work on those pages, you've made some good edits! I was surprised to see so many mistaken inclusions of 0xDEAD space at the ends of types, and had to investigate. It looks like confusion sometimes slipped in during the process of editing a page. For instance [[Special:Permalink/4457|this revision]] of ONCV listed the final bytes starting at 0x4C as 32-byte alignment filler, but the next edit by Ssg wiped out geyser's description and simply called them "unused". Perhaps Ssg and other editors knew what they were, but no editors thought to write "alignment padding" instead of "unused" for that range, which is misleading for the reader.

Anyway, I just have one question: are you planning to fill in those offsets where you added a new field but placed "----" for the address? --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 19:36, 12 May 2025 (UTC)
:I won't leave those "----" for addresses, of course... I'll re-calculate those addresses right after I'll finish cleaning up 0xDEADs and renaming not only paddings back to "padding", but also all "int" to "'''u'''int" where it's needed...--[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 21:51, 12 May 2025 (UTC)
::Okie. Don't over-work yourself :-) --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 21:56, 12 May 2025 (UTC)
::For the record, here are the pages with added fields that have "----" for addresses: OBD:Mtrl, OBD:Impt, <strike>OBD:ENVP</strike>, OBD:AKEV. Maybe there are others, but those are the ones I noticed. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 22:02, 13 May 2025 (UTC)
:::Update: I realized there was room for improvement/clarification on ENVP, so while I was working on that I filled in the offsets as well. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 23:26, 13 May 2025 (UTC)
::As I'm looking over ONCC, I noticed the note "overridden by char's MELE profile if possible", but I'm not seeing that in the code. In fact it looks like the MELE's "dazed" fields are ignored by Oni entirely. There are various references to them in the editor and importer code, but I don't see where the game logic looks at them. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 15:54, 14 May 2025 (UTC)
:::<code>ONI_Character.h, lines 167-168</code>... It is stated in the dev's comment...--[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 21:29, 14 May 2025 (UTC)

User talk:Mai X

2025-05-12T21:51:45Z

Mai X:

==Projects==
===Graphical updates===
That's an [http://konoko.oni2.net/%5bImages%5d/NG_Oni.png impressive example] you got there. As if it was made in blender. Does it use a HD mod package for the training level?

I can only imaging that you modified the source code and compiled you own executable. Or maybe its part of Oni X or a fork? I didn't follow the engine modding on discord as they pretty much only (re-)added known bug-fixes?

Anyway, keep us updated, okay? :) --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 16:39, 24 November 2024 (UTC)

:Yeah, I used [http://mods.oni2.net/node/92 this] texture pack for my update... I made normal maps from some of textures with [https://www.smart-page.net/smartnormal/ this] service... But I've not used Blender for any stage of making my updates (especially, not for rendering)... I've used Autodesk Softimage 2015 for assigning materials and shaders... But rendering was done in my own version of engine (BFW-17) with deep code modifications... I don't support OniX in any way (contributing to it or forking it), so I'll not be using their engine version or forking it for my modifications...
:For now, I'm about to finish a small demo video of my graphical updates...

:Of course, I'll keep you updated... At least, I'll try to do it as much as I can... --[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 19:26, 24 November 2024 (UTC)

I'm impressed too! Your work looks very promising. What sort of plans do you have for the future? P.S.: Wasn't Konoko HD Armor high-poly enough for you? --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 21:59, 28 November 2024 (UTC)

:For now, my plan is just to have some rest... Plans for my updates: add better HDR support, implement Autodesk Scaleform for HUD and menus (instead of textures + 9-slice), add JPEG and PNG-ZIP texture compression support, implement GDF compression with LZMA-2... P.S.: Chief model has bundled normal maps with it, has over 60 000 polygons and has 4096x4096 uncompressed textures... HD Konoko is not so HQ as that model... --[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 07:28, 1 December 2024 (UTC)

Today I found the time to watch the video you added. Great work!

Unfortunately, the msVo encoded audio didn't play so for the fun of it, here's [http://paradox.oni2.net/wiki/user/Mai_X/talk/Mai_X_OniDemoChief_Mai_X_at_the_new_edge_of_modding.mp4 another version]. ^_^

Like Iritscen said, hopefully you can add Mai (package 26000 [http://paradox.oni2.net/wiki/user/Mai_X/talk/26000_Konoko_HD_Armor.png Konoko HD Armor]) in another iteration of the scene. It's not super highpoly but for Oni's standards it's quite decent. You probably you really wanted to make a point about the high poly count with master chief. Though I cannot stop feeling he is still to much of an ''alien'' there. --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 19:12, 18 December 2024 (UTC)

:The original music is called "Velta Theme" from Synergia OST... I've re-encoded it to MP3, so you can get it [http://konoko.oni2.net/%5bMusic%5d/Velta%20Theme.MP3 here]...
:Your version is even better, than mine... Thank you... You've got the "atmosphere" of the video completely right...
:I'll try to use that model of "HD" Konoko in my next video (featuring ManPlant level; info is on main page)... --[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 06:43, 6 May 2025 (UTC)

==Let us cheer you up*==
You enrich society in many ways. But first of all you enrich society by simply being not an ignorant asshole. But for that you need to stay alive.

'''Even if nobody tells you - and that proofs even more that your presence is needed.'''

You haven’t founded a family yet? Is that what your parents expect from you? So what? You can still do that later. For now, it means you are still more free to be a [https://www.deviantart.com/ deviant], an unconventional ("eccentric") and creative person.

I’m not really a friend of geyser, never met him in person, but I know him good enough by our talks to say that I deeply respect him. He was really happy about you when you joined this place and to work with you together. When he said you are a good and capable person, I had no doubt that you are.

"Why I’m alive." That's the 100 million dollar question most people have to think through at some time point in their life.

Committing suicide helps nobody. If someone tells you so, *punch that <s>asocial</s> '''antisocial mobbing bastard''' hard in the face.

(Of course, this wasn't an instruction. It was meant to cheer you up and to better let you hold a ''righteous grudge'' against others, than a self-destructive, imaginary one against yourself.)
--[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 07:58, 29 March 2023 (CEST)

Oh... thank you for that... you and GeySer... only you two can understand me in such moments... Now I feel a little bit better (no suicidal thoughts anymore)... Now I'm trying to stop myself from going to St. Pet. and destroying RAIDs...
--[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 09:32, 29 March 2023 (CEST)

:Sometimes, in order to be true to ourselves, we have to take a course that doesn't satisfy our parents' wishes. It's more common than you think. You still have plenty of time to figure out what path you want to take in life. And in the end, your parents probably just want to see you succeed, so if you do that, eventually they'll be happy. P.S.: I've kept all my computer files since my first Mac in 1993 ;-) --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 22:15, 29 March 2023 (CEST)

::Maybe... maybe that will happen... About archiving: I started it when I was 12, after accidental destruction of Seagate ST32132A (HDD from my first PC)... --[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 20:40, 30 March 2023 (CEST)

:::Okay, so starting at the same age as me then :-) I've been lucky; I've lost HDs but never any data that wasn't in another place too. These days I have redundant backups of all my data on local HDs and in the cloud. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 22:28, 30 March 2023 (CEST)

== OBD updates ==

Thanks for your work on those pages, you've made some good edits! I was surprised to see so many mistaken inclusions of 0xDEAD space at the ends of types, and had to investigate. It looks like confusion sometimes slipped in during the process of editing a page. For instance [[Special:Permalink/4457|this revision]] of ONCV listed the final bytes starting at 0x4C as 32-byte alignment filler, but the next edit by Ssg wiped out geyser's description and simply called them "unused". Perhaps Ssg and other editors knew what they were, but no editors thought to write "alignment padding" instead of "unused" for that range, which is misleading for the reader.

Anyway, I just have one question: are you planning to fill in those offsets where you added a new field but placed "----" for the address? --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 19:36, 12 May 2025 (UTC)
:I won't leave those "----" for addresses, of course... I'll re-calculate those addresses right after I'll finish cleaning up 0xDEADs and renaming not only paddings back to "padding", but also all "int" to "'''u'''int" where it's needed...--[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 21:51, 12 May 2025 (UTC)

OBD:QTNA

2025-05-12T19:13:23Z

Mai X: ...

{{OBD_File_Header | type=QTNA | prev=PSUI | next=SNDD | name=Quad Tree Node Array | family=Level | align=center}}

[[image:qtna_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | res_id |FF0000| 01 46 02 00 | 582 | 00582-.QTNA }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr| 0x08 | char[20] |00FF00| AD DE | dead | padding }}
{{OBDtr| 0x1C | uint32 |00FFFF| C1 1D 00 00 | 7617 | array size }}
{{OBDtrBK}}
{{OBDtr| 0x00 | uint32hb |FFC8C8| 3A 09 00 80 | 2362, high bit | negative u, negative v child index }}
{{OBDtr| 0x04 | uint32hb |FFFFC8| 3B 09 00 80 | 2363, high bit | positive u, negative v child index }}
{{OBDtr| 0x08 | uint32hb |C8FFC8| 01 00 00 00 | 1 | negative u, positive v child index }}
{{OBDtr| 0x0C | uint32hb |C8FFFF| 54 09 00 80 | 2388, high bit | positive u, positive v child index }}
|}

;Child index
:If the high bit is not set then the child index is the index of another quadtree node (into the same array). Otherwise it is the index of an [[OBD:OTLF|OTLF]] entry.
;U and V meaning
:X aligned node - U = Y, V = Z
:Y aligned node - U = X, V = Z
:Z aligned node - U = X, V = Y
:;Note
::The alignment of a node depends on the leaf face that referenced it because there is no orientation information in a quadttree node.

{{OBD_File_Footer | type=QTNA | prev=PSUI | next=SNDD | name=Quad Tree Node Array | family=Level}}

{{OBD}}

OBD:PSUI

2025-05-12T19:07:14Z

Mai X: Removing DEAD part... It is NOT a part of the type...

{{OBD_File_Header | type=PSUI | prev=PSpL | next=QTNA | name=Part Specifications UI (User Interface) | family=Interface | align=center}}

[[Image:psui_all.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | res_id |FF0000| 01 4F 06 00 | 1615 | 01615-psui_g206.PSUI }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr| 0x08 | link |FFC8C8| 01 32 06 00 | 1586 | link to 01586-ps_g206_background.[[OBD:PSpc|PSpc]] }}
{{OBDtrBK|1=Other 42 links }}
{{OBDtr| 0xB4 | link |FFC8C8| 01 40 06 00 | 1600 | link to 01600-ps_g206_folder.[[OBD:PSpc|PSpc]] }}
|}

{{OBD_File_Footer | type=PSUI | prev=PSpL | next=QTNA | name=Part Specifications UI (User Interface) | family=Interface}}

{{OBD}}

OBD:PSpL

2025-05-12T19:01:51Z

Mai X: ...

{{OBD_File_Header | type=PSpL | prev=PSpc | next=PSUI | name=Part Specification List | family=Interface | align=center}}

[[Image:pspl_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | res_id |FF0000| 01 71 06 00 | 1649 | 01649-partspec_list.PSpL }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr| 0x08 | char[20] |00FF00| AD DE | dead | padding }}
{{OBDtr| 0x1C | uint32 |00FFFF| 07 00 00 00 | 7 | array size }}
{{OBDtrBK}}
{{OBDtr| 0x00 | uint32 |FFC8C8| 00 00 00 00 | 0 | part type }}
{{OBDtr| 0x04 | link |FFFFC8| 01 6C 06 00 | 1644 | link to 01644-ps_none_none_none.[[OBD:PSpc|PSpc]] }}
|}

;Used part types:
:0 - Transparent in-game UI background
:1 - Black out-of-game UI background
:5 - Sound debug panel background (<tt>sound_show_debug=1</tt>)

{{OBD_File_Footer | type=PSpL | prev=PSpc | next=PSUI | name=Part Specification List | family=Interface}}

{{OBD}}

OBD:PSpc

2025-05-12T18:57:10Z

Mai X: ...

{{OBD_File_Header | type=PSpc | prev=PNTA | next=PSpL | name=Part Specification | family=Interface | align=center}}

[[Image:pspc_all.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | res_id |FF0000| 01 39 00 00 | 57 | 00057-level_3_part.PSpc }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtrBK|1=Array of 9 point elements: first element }}
{{OBDtr| 0x08 | int16 |FFC8C8| 00 00 | 0 | x-coordinate of top left corner of top left rectangle }}
{{OBDtr| 0x0A | int16 |FFC8C8| 00 00 | 0 | y-coordinate of top left corner of top left rectangle }}
{{OBDtrBK|1=End of array }}
{{OBDtrBK|1=Array of 9 point elements: first element }}
{{OBDtr| 0x1A | int16 |FFC8C8| 00 00 | 0 | x-coordinate of bottom right corner of top left rectangle }}
{{OBDtr| 0x1C | int16 |FFC8C8| 00 00 | 0 | y-coordinate of bottom right corner of top left rectangle }}
{{OBDtrBK|1=End of array }}
{{OBDtr| 0x50 | link |FFFFC8| 01 38 00 00 | 0 | link to 00056-h_03.[[OBD:TXMP|TXMP]] }}
|}

:''For a visualization of nine-slice rendering, see [https://learn.microsoft.com/en-us/previous-versions/windows/desktop/windows-media-center-sdk/bb189722(v=msdn.10) HERE] or [[XML:PSpc]].

;What is stored
:There are 9 rectangles defined in PSpc: 4 corners, 4 sides and one interior rectangle. Typically all 9 are used (to draw buttons for example) or only one is used (the top left corner, to draw checkboxes for example). There are cases where the top left corner and the interior rectangle are both present, which indicates that the code can choose which part to draw.
:The reason for using 9 rectangles is to allow drawing of buttons (and anything else that has defined corners) in various sizes without distorting the corners.
:*the corners are never rescaled
:*horizontal sides can be stretched horizontally
:*vertical sides can be stretched vertically
:*the interior can be stretched both ways
:Of course that means that the sides and the interior must be specially designed to be stretchable without visible distortion.

;How it is stored
:A pair of int16 fields make a texture coordinate. The first 9 texture coordinates in the file (18 bytes) are the top-left corners of the 9 rectangles. The latter 9 coordinates are the bottom-right corners of the 9 rectangles. When both coordinates are 0 then the rectangle is not used. The order of the coordinates is top to bottom, left to right. Thus the order of the 9 rectangles is: top left, top center, top right, middle left, middle center, middle right, bottom left, bottom center, bottom right.

{{OBD_File_Footer | type=PSpc | prev=PNTA | next=PSpL | name=Part Specification | family=Interface}}

{{OBD}}

OBD:PSpc

2025-05-12T18:53:56Z

Mai X: Removing DEAD part... It is NOT a part of the type...

{{OBD_File_Header | type=PSpc | prev=PNTA | next=PSpL | name=Part Specification | family=Interface | align=center}}

[[Image:pspc_all.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | res_id |FF0000| 01 39 00 00 | 57 | 00057-level_3_part.PSpc }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtrBK|1=Array of 18 point elements: first element }}
{{OBDtr| 0x08 | int16 |FFC8C8| 00 00 | 0 | x-coordinate of top left corner of top left rectangle }}
{{OBDtr| 0x0A | int16 |FFC8C8| 00 00 | 0 | y-coordinate of top left corner of top left rectangle }}
{{OBDtrBK|1=End of array }}
{{OBDtr| 0x50 | link |FFFFC8| 01 38 00 00 | 0 | link to 00056-h_03.[[OBD:TXMP|TXMP]] }}
|}

:''For a visualization of nine-slice rendering, see [https://learn.microsoft.com/en-us/previous-versions/windows/desktop/windows-media-center-sdk/bb189722(v=msdn.10) HERE] or [[XML:PSpc]].

;What is stored
:There are 9 rectangles defined in PSpc: 4 corners, 4 sides and one interior rectangle. Typically all 9 are used (to draw buttons for example) or only one is used (the top left corner, to draw checkboxes for example). There are cases where the top left corner and the interior rectangle are both present, which indicates that the code can choose which part to draw.
:The reason for using 9 rectangles is to allow drawing of buttons (and anything else that has defined corners) in various sizes without distorting the corners.
:*the corners are never rescaled
:*horizontal sides can be stretched horizontally
:*vertical sides can be stretched vertically
:*the interior can be stretched both ways
:Of course that means that the sides and the interior must be specially designed to be stretchable without visible distortion.

;How it is stored
:A pair of int16 fields make a texture coordinate. The first 9 texture coordinates in the file (18 bytes) are the top-left corners of the 9 rectangles. The latter 9 coordinates are the bottom-right corners of the 9 rectangles. When both coordinates are 0 then the rectangle is not used. The order of the coordinates is top to bottom, left to right. Thus the order of the 9 rectangles is: top left, top center, top right, middle left, middle center, middle right, bottom left, bottom center, bottom right.

{{OBD_File_Footer | type=PSpc | prev=PNTA | next=PSpL | name=Part Specification | family=Interface}}

{{OBD}}

OBD:PNTA

2025-05-12T18:37:07Z

Mai X: ...

{{OBD_File_Header | type=PNTA | prev=PLEA | next=PSpc | name=3D Point Array | family=General | align=center}}

[[Image:pnta_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | res_id |FF0000| 01 DA 00 00 | 218 | 00218-.PNTA }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr| 0x08 | char[12] |00FF00| AD DE | dead | padding }}
{{OBDtr| 0x14 | float |00FFFF| 00 00 10 C1 | -9.000000 | min. x-coordinate of all elements below }}
{{OBDtr| 0x18 | float |00FFFF| 47 BC C9 BE | -0.394015 | min. y-coordinate (height) of all elements below }}
{{OBDtr| 0x1C | float |00FFFF| FF FF 6F C1 | -14.999999| min. z-coordinate of all elements below }}
{{OBDtr| 0x20 | float |FF00FF| 00 00 10 41 | 9.000000 | max. x-coordinate of all elements below }}
{{OBDtr| 0x24 | float |FF00FF| 56 BC C9 3E | 0.394015 | max. y-coordinate (height) of all elements below }}
{{OBDtr| 0x28 | float |FF00FF| 70 6E 73 41 | 15.214462 | max. z-coordinate of all elements below }}
{{OBDtr| 0x2C | float |FF8000| 00 00 00 00 | 0.000000 | x-coordinate of the center [ ((max. x-coord. - min. x-coord.) ÷ 2) + min x-coord. ] }}
{{OBDtr| 0x30 | float |FF8000| 00 00 70 34 |0.000000...| y-coordinate (height) of the center [ ((max. y-coord. - min. y-coord.) ÷ 2) + min y-coord. ] }}
{{OBDtr| 0x34 | float |FF8000| 40 9C DB 3D | 0.107232 | z-coordinate of the center [ ((max. z-coord. - min. z-coord.) ÷ 2) + min z-coord. ] }}
{{OBDtr| 0x38 | float |FF0080| E6 B6 8C 41 | 17.589306 | distance from the center to each of the both points above }}
{{OBDtr| 0x3C | uint32 |960096| 10 00 00 00 | 16 | array size }}
{{OBDtrBK}}
{{OBDtr| 0x00 | float |FFC8C8| 00 00 10 C1 | -9.000000 | x-coordinate of the first point }}
{{OBDtr| 0x04 | float |FFFFC8| 1A BC C9 BE | -0.394013 | y-coordinate (height) of the first point }}
{{OBDtr| 0x08 | float |C8FFC8| FF FF 6F C1 | -14.999999| z-coordinate of the first point }}
|}

The first image below shows the points which are encoded above in the data marked in light blue, lilac and dark orange. In my opinion these points are used to create the bounding box.

The second image gives you an overview of the elements in the coordinate array. Every triad of 32-bit numbers contains the x- y- and z-coordinate of a point. In this example every point exists in duplicate, so that you can only see 8 points. These points are needed to build up the mesh (triangles) for a door.

Image number three is a fusion of the first and the second image.

[[Image:pnta_0.gif]]       [[Image:pnta_1.gif]]       [[Image:pnta_2.gif]]

{{OBD_File_Footer | type=PNTA | prev=PLEA | next=PSpc | name=3D Point Array | family=General}}

{{OBD}}

OBD:PLEA

2025-05-12T18:32:02Z

Mai X: ...

{{OBD_File_Header | type=PLEA | prev=OTLF | next=PNTA | name=Plane Equation Array | family=Level | align=center}}

[[image:plea_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | res_id |FF0000| 01 41 02 00 | 577 | 00577-.PLEA }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr| 0x08 | char[20] |00FF00| AD DE | dead | padding }}
{{OBDtr| 0x1C | uint32 |00FFFF| 03 00 00 00 | 13554 | array size }}
{{OBDtrBK}}
{{OBDtr| 0x00 | float |FFC8C8| 00 00 00 00 | 0.000000 | 'a' coefficient of the plane equation (x component of plane's normal) }}
{{OBDtr| 0x04 | float |FFFFC8| 00 00 00 00 | 0.000000 | 'b' coefficient of the plane equation (y component of plane's normal) }}
{{OBDtr| 0x08 | float |C8FFC8| 00 00 80 3F | 1.000000 | 'c' coefficient of the plane equation (z component of plane's normal) }}
{{OBDtr| 0x0C | float |C8FFFF| 00 00 19 44 |612.000000| 'd' coefficient of the plane equation }}
|}

;Plane equation
:The canonical equation for a [https://mathworld.wolfram.com/Plane.html plane] in 3D is
::'''a * x + b * y + c * z + d = 0,'''
:with (a, b, c, d) being 4 real numbers and (a, b, c) forming a nonzero vector (the plane's "normal").
:*The set of points (x, y, z) verifying '''a * x + b * y + c * z + d = 0''' are said to be in the plane or at the plane.
:*The set of points (x, y, z) verifying '''a * x + b * y + c * z + d > 0''' are said to be in front of the plane.
:*The set of points (x, y, z) verifying '''a * x + b * y + c * z + d < 0''' are said to be behind the plane.
:'''N.B.''' If a=b=c=0, then the equation is degenerate and applies either to the whole space (if d=0) or to no points at all (if d is non-zero).

:As a further convention, if (a,b,c) is normalized at unit length (i.e., '''a*a + b*b + c*c = 1''') then d is the distance from the plane to the world's origin, along the normal vector.
:The four floats in each element of a PLEA are exactly the (a, b, c, d) of the above definition.
:In the above example, the first element defines the plane (0 * x + 0 * y + 1 * z + 612 = 0), i.e., the vertical plane z = -612.

;What planes are for and how they are referenced
:Planes are used for environment culling, collision detection and [[wikipedia:Binary_space_partitioning|BSP]].
:The plane equations stored in PLEA are referenced from such data as [[ABNA]], [[AKBP]], [[AKBA]] and [[AGQC]] by means of a 32-bit array index.
:However, the high bit of those 32-bit references is not part of the array index, instead it indicates whether the facing of the plane should be flipped.
:*If the high bit is not set, then the 4 values (a, b, c, d) are used as described above. (If referencing the above example without a high bit, then any points with z > - 612 will be in front of the plane, whereas points with z < -612 will be behind the plane.)
:*If the high bit is set, then the plane equation coefficients become (-a, -b, -c, -d). (If referencing the above example with a high bit, then any point with z > - 612 will be behind the plane, whereas points with z < -612 will be in front of the plane.)
:This means that the actual array index is a 31-bit value (i.e., there can "only" be up to 2,147,483,648 distinct planes in a level), but the same array element can be used for two different facing directions.

{{OBD_File_Footer | type=PLEA | prev=OTLF | next=PNTA | name=Plane Equation Array | family=Level}}

{{OBD}}

OBD:OTIT

2025-05-12T18:30:43Z

Mai X: ...

{{OBD_File_Header | type=OTIT | prev=OSBD | next=OTLF | name=Oct Tree Interior Node Array | family=Level | align=center}}

[[image:otit_a.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x00 | res_id |FF0000| 01 44 02 00 | 580 | 00580-.OTIT }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr| 0x08 | char[20] |00FF00| AD DE | dead | padding }}
{{OBDtr| 0x1C | uint32 |00FFFF| 6E 0A 00 00 | 2670 | array size }}
{{OBDtrBK}}
{{OBDtr| 0x00 | uint32hb |FFC8C8| 01 00 00 00 | 1 | negative x, negative y, negative z child index }}
{{OBDtr| 0x04 | uint32hb |FFFFC8| 30 00 00 00 | 48 | positive x, negative y, negative z child index }}
{{OBDtr| 0x08 | uint32hb |C8FFC8| 52 01 00 00 | 338 | negative x, positive y, negative z child index }}
{{OBDtr| 0x0C | uint32hb |C8FFFF| 93 01 00 00 | 403 | positive x, positive y, negative z child index }}
{{OBDtr| 0x10 | uint32hb |FFC8FF| A8 06 00 00 | 1704 | negative x, negative y, positive z child index }}
{{OBDtr| 0x14 | uint32hb |FFC800| DC 06 00 00 | 1756 | positive x, negative y, positive z child index }}
{{OBDtr| 0x18 | uint32hb |C800C8| F2 07 00 00 | 2034 | negative x, positive y, positive z child index }}
{{OBDtr| 0x1C | uint32hb |C87C64| 42 08 00 00 | 2114 | positive x, positive y, positive z child index }}
|}

;Child index
:If the child index does not have its high bit set then it is the index of another octtree interior node (in the same array). Otherwise it is the index of an octtree leaf (from [[OBD:OTLF|OTLF]])
;Example
:In the above interior node all children are other interior nodes, there are no leafs in this interior node.

{{OBD_File_Footer | type=OTIT | prev=OSBD | next=OTLF | name=Oct Tree Interior Node Array | family=Level}}

{{OBD}}

OBD:OTLF

2025-05-12T18:30:23Z

Mai X: ...

{{OBD_File_Header | type=OTLF | prev=OTIT | next=PLEA | name=Oct Tree Leaf Node Array | family=Level | align=center}}

[[image:otlf_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | res_id |FF0000| 01 45 02 00 | 581 | 00581-.OTLF }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr| 0x08 | char[20] |00FF00| AD DE | dead | padding }}
{{OBDtr| 0x1C | uint32 |00FFFF| 03 49 00 00 | 18691 | array size }}
{{OBDtrBK}}
{{OBDtr| 0x00 | uint12-20 |FFC8C8| 00 00 00 00 | 0, 0 | bits 0-11 (12 bits) contain the number of gunk quads that intersect this leaf, bits 12-31 (20 bits) contain the index of the gunk quad list; see details below }}
{{OBDtr| 0x04 | uint32hb |FFFFC8| FF FF FF FF | -1 | negative x neighbour }}
{{OBDtr| 0x08 | uint32hb |C8FFC8| 01 00 00 80 | 1, high bit | positive x neighbour }}
{{OBDtr| 0x0C | uint32hb |C8FFFF| FF FF FF FF | -1 | negative y neighbour }}
{{OBDtr| 0x10 | uint32hb |FFC8FF| 02 00 00 80 | 2, high bit | positive y neighbour }}
{{OBDtr| 0x14 | uint32hb |FFC800| FF FF FF FF | -1 | negative z neighbour }}
{{OBDtr| 0x18 | uint32hb |C800C8| 04 00 00 80 | 4, high bit | positive z neighbour }}
{{OBDtr| 0x1C |uint9-9-9-5|C87C64| 7F FE FC 39 | 127, 127, 127, 7 | bits 0-8 (9 bits) contain the index of max x, bits 9-17 (9 bits) contain the index of max y, bits 18-26 (9 bits) contain the index of max z and bits 27-31 (5 bits) contain the index of the size of this leaf; see details below }}
{{OBDtr| 0x20 | uint8-24 |B0C3D4| 00 00 00 00 | 0, 0 | bits 0-7 (8 bits) intersected BNV count, bits 8-31 (24 bits) BNV list index; see details below }}
|}

[[Image:Penny_Arcade_-_EvilCorp_Too.png|thumb|300px]]
;Intersected gunk quads
:An octtree leaf (OTLF) stores its size and position and the gunk quads that intersect it. The first field contains an index/count pair that is used to access the first [[OBD:IDXA|IDXA]] field that is stored in the [[OBD:AKOT|AKOT]] that owns this leaf. This [[OBD:IDXA|IDXA]] contains the gunk quad numbers that intersect the leaf. In theory there can be at most 4095 gunk quads that intersect a leaf but in practice this number is much lower (max is 462). In addition the threshold limit used to build the octree seems to be 19 gunk quads per leaf. I.e., in Oni's levels, only the smallest leaves (with size 16x16x16) have more than 19 quads; larger leaves containing 20 and more quads are subdivided into "other, smaller boxes".
;Intersected BNVs
:An octtree leaf can intersect some BNVs (see [[OBD:AKVA|AKVA]]). The last field contains the index and count of this list in the second [[OBD:IDXA|IDXA]] field of [[OBD:AKOT|AKOT]].
;Position and size
:The position (of leaf's positive corner) is stored as three 9 bit fields. These values are not the x, y and z coordinates themselves but they are indices into a constant table. This constant table has 512 entries starting with -4080.0 and going up to 4096.0 in 16 units increments.
:The size of leaf is stored in a 5 bit field and it is and index into another constant table. This table has 9 entries starting with 16.0 and going up to 4096.0 (each entry is double the previous one).
:*Maximum environment size is (8192.0, 8192.0, 8192.0)
:*Minimum coordinate is (-4096.0, -4096.0, -4096.0)
:*Maximum coordinate is (4096.0, 4096.0, 4096.0)
:*Minimum leaf size is 16.0
:*Maximum leaf size is 4096.0 (this means that there will always be at least 8 leaves because the size of the environment is double).
;Neighbours
:A leaf can have 6 neighbours (one for each face). If a face does not have a neighbour (it's on an environment border) then the coresponding field is -1. If a neighbour field value has its high bit set then the value (without the high bit) is the index of another octtree leaf (this is the case when when the neighbour leaf is equal to or larger than the leaf). If the high bit is not set then the value is an index into a quadtree node array (the [[OBD:QTNA|QTNA]] field of [[OBD:AKOT|AKOT]]) (this is the case when there is more than one leaf neighbour for a face).
;Example
:The above leaf does not intersect any quads, has its maximum corner at (-2048.0, -2048.0, -2048.0), a size of 2048.0, no neighbours for all negative faces (it's right in the negative corner of the environment) and positive faces have leaves as neighbours (no quadtree nodes here).
;Theoretical limits
:If the environment (size 8192x8192x8192) is subdivided into minimal cubes (size 16x16x16) in all three directions, the total number of leaves is 512x512x512 = 134,217,728, and with a maximum of 4095 quads per leaf one could expect a theoretical maximum of 549,621,596,160 distinct quads per level. (Half a trillion quads, or a trillion triangles. That's ''crazy'' much.)
:However, the maximum size of the AKOT's first IDXA that can be referenced through a leaf's 0x00 field is actually 1,052,670 (a combination of the 20-bit index to the start of a leaf's quad list and the 12-bit length of that list). Thus the maximum number of distinct quads in a level (properly referenced by oct-tree leaves) can not exceed 1,052,670, which is much more comfortable sanity-wise (two million triangles is fairly common for game environments nowadays).
:In practice, though, the engine imposes even more modest limitations:
:*only up to 8192 environment triangles are expected to be ''visible'' (rendered) at any given time (they can be packed as 4096 quads, or as 8192 actual triangles, or any combination of tris and quads).
:*:If you attempt to view more than 8192 triangles at once, Oni will ''not'' crash, but:
:*:*it will complain with the dev-console message "Exceeded max visible GQs #", where # is the number of ''triangles'' in excess of 8192;
:*:*it will start dropping random triangles from the rendering pipeline;
:*:*collision will start to fail on the "dropped" triangles.
:*:The amount of other visible geometry (characters, particles etc) does not affect this limit.
:*only up to 262140 triangles (e.g., as 131070 quads) are allowed in a level's environment. Attempting to load a level with 262141 environment triangles (as any combination of triangles and quads) will cause Oni to [[Blam]].
:*:(N.B. This has been identified as a bug that will be fixed in future versions, so that the theoretical maximum of 1,052,670 quads (2,105,340‬ triangles) can be reached: if you cut a level into "sections" ("rooms" or "scenes") where you can view no more than 8192 triangles at once, then basically you are allowed to have 256 such "sections" in a level. If you add an extra set of environment polygons for cel-shading and/or lightmapping, then the limit will be cut in 2 or 3.)

{{OBD_File_Footer | type=OTLF | prev=OTIT | next=PLEA | name=Oct Tree Leaf Node Array | family=Level}}

{{OBD}}

OBD:OTIT

2025-05-12T18:21:28Z

Mai X: ...

{{OBD_File_Header | type=OTIT | prev=OSBD | next=OTLF | name=Oct Tree Interior Node Array | family=Level | align=center}}

[[image:otit_a.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x00 | res_id |FF0000| 01 44 02 00 | 580 | 00580-.OTIT }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr| 0x08 | char[20] |00FF00| AD DE | dead | unused }}
{{OBDtr| 0x1C | uint32 |00FFFF| 6E 0A 00 00 | 2670 | array size }}
{{OBDtrBK}}
{{OBDtr| 0x00 | uint32hb |FFC8C8| 01 00 00 00 | 1 | negative x, negative y, negative z child index }}
{{OBDtr| 0x04 | uint32hb |FFFFC8| 30 00 00 00 | 48 | positive x, negative y, negative z child index }}
{{OBDtr| 0x08 | uint32hb |C8FFC8| 52 01 00 00 | 338 | negative x, positive y, negative z child index }}
{{OBDtr| 0x0C | uint32hb |C8FFFF| 93 01 00 00 | 403 | positive x, positive y, negative z child index }}
{{OBDtr| 0x10 | uint32hb |FFC8FF| A8 06 00 00 | 1704 | negative x, negative y, positive z child index }}
{{OBDtr| 0x14 | uint32hb |FFC800| DC 06 00 00 | 1756 | positive x, negative y, positive z child index }}
{{OBDtr| 0x18 | uint32hb |C800C8| F2 07 00 00 | 2034 | negative x, positive y, positive z child index }}
{{OBDtr| 0x1C | uint32hb |C87C64| 42 08 00 00 | 2114 | positive x, positive y, positive z child index }}
|}

;Child index
:If the child index does not have its high bit set then it is the index of another octtree interior node (in the same array). Otherwise it is the index of an octtree leaf (from [[OBD:OTLF|OTLF]])
;Example
:In the above interior node all children are other interior nodes, there are no leafs in this interior node.

{{OBD_File_Footer | type=OTIT | prev=OSBD | next=OTLF | name=Oct Tree Interior Node Array | family=Level}}

{{OBD}}

OBD:OSBD

2025-05-12T18:18:26Z

Mai X: Removing DEAD part... It is NOT a part of the type...

{{OBD_File_Header | align=center | type=OSBD | prev=OPge | next=OTIT | name=Oni Sound Binary Data | family=General}}

[[Image:osbd_all.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x00 | res_id |FF0000| 01 E4 18 00 | 6372 | 06372-AirCon5.amb.OSBD }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr| 0x08 | uint32 |FFC8C8| D0 00 00 00 | 208 | size of the chunk in the raw/separate file in bytes }}
{{OBDtr| 0x0C | offset |FFFFC8| 20 5E B2 01 | 01 B2 5E 20 | start of the chunk in the raw/separate file }}
|}

;raw/separate file chunk
:It has 3 different sub-formats :
:*[[OBD:OSBD/OSAm|OSAm]] (Oni Sound : Ambient)
:*[[OBD:OSBD/OSGr|OSGr]] (Oni Sound : Group)
:*[[OBD:OSBD/OSIm|OSIm]] (Oni Sound : Impulse)
:The format is not known when following the link at 0x0C above
::(even if it can be inferred from the name of the OSBD file)
:The engine knows how to parse the raw/separate file once it's read the first 4 bytes
::(same as for [[OBD:BINA|BINA]])

{{OBD_File_Footer | type=OSBD | prev=OPge | next=OTIT | name=Oni Sound Binary Data | family=General}}

{{OBD}}

OBD:OPge

2025-05-12T18:15:06Z

Mai X: ...

{{OBD_File_Header | type=OPge | prev=ONWC | next=OSBD | name=Objective Page | family=Interface | align=center}}

[[Image:opge_all.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x00 | res_id |FF0000| 01 37 00 00 | 55 | 00055-level_3.OPge }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr| 0x08 | char[2] |FFC8C8| AD DE | dead | padding }}
{{OBDtr| 0x0A | uint16 |FFFFC8| 03 00 | 3 | level 3 }}
{{OBDtr| 0x0C | link |C8FFC8| 01 00 00 00 | 0 | link to 00000-.[[OBD:IGPA|IGPA]] }}
|}

{{OBD_File_Footer | type=OPge | prev=ONWC | next=OSBD | name=Objective Page | family=Interface}}

{{OBD}}

OBD:OPge

2025-05-12T18:14:54Z

Mai X: Removing DEAD part... It is NOT a part of the type...

{{OBD_File_Header | type=OPge | prev=ONWC | next=OSBD | name=Objective Page | family=Interface | align=center}}

[[Image:opge_all.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x00 | res_id |FF0000| 01 37 00 00 | 55 | 00055-level_3.OPge }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr| 0x08 | char[2] |FFC8C8| AD DE | dead | padding }}
{{OBDtr| 0x0A | int16 |FFFFC8| 03 00 | 3 | level 3 }}
{{OBDtr| 0x0C | link |C8FFC8| 01 00 00 00 | 0 | link to 00000-.[[OBD:IGPA|IGPA]] }}
|}

{{OBD_File_Footer | type=OPge | prev=ONWC | next=OSBD | name=Objective Page | family=Interface}}

{{OBD}}

OBD:ONWC

2025-05-12T16:58:53Z

Mai X: Removing DEAD part... It is NOT a part of the type...

{{OBD_File_Header | type=ONWC | prev=ONVL | next=OPge | name=Oni Weapon Class | family=Character | align=center}}

ONWC files in level[1-19]_Final are 0-byte files. The actual data is in the ONWC files of level 0; below is an example.

Unless specified otherwise, the coordinates are relative to the weapon's mesh (x = forwards, y = left, z = up).

==0x000 to 0x0D7 - Weapon main part ==
[[Image:onwc_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x000 | res_id |FF0000| 01 75 0E 00 | 3701 | 03701-w1_tap.ONWC }}
{{OBDtr| 0x004 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
|}

===0x008 to 0x053 - Laser sight parameters===
{{Table}}
{{OBDth}}
{{OBDtr| 0x008 | float |FFC8C8| F5 A4 49 40 | 3.150693 | x-offset of laser sight origin }}
{{OBDtr| 0x00C | float |FFC8C8| F4 2C A5 3B | 0.005041 | y-offset of laser sight origin }}
{{OBDtr| 0x010 | float |FFC8C8| 21 4E D2 3E | 0.410752 | z-offset of laser sight origin }}
{{OBDtr| 0x014 | float |FFC8C8| 23 A6 7F 3F | 0.998629 | x-component of laser sight direction }}
{{OBDtr| 0x018 | float |FFC8C8| AA 6C 56 BD | -0.052349 | y-component of laser sight direction }}
{{OBDtr| 0x01C | float |FFC8C8| 69 66 AA B7 | -0.000020 | z-component of laser sight direction }}
{{OBDtr| 0x020 | float |FFC8C8| 00 40 9C 45 |5000.000000 | maximal length of laser sight vector }}
{{OBDtr| 0x024 | color |FFFFC8| 00 00 FF FF | 0, 0, 255; 255 | laser sight color (blue, green, red); laser sight transparency }}
{{OBDtr| 0x028 | link |C8FFC8| 01 94 05 00 | 1428 | crosshair texture (link to 01428-target_1A.[[TXMP]]) }}
{{OBDtr| 0x02C | color |C8FFC8| FF FF FF 00 |255, 255, 255; 0| crosshair background color (blue, green, red); crosshair background transparency }}
{{OBDtr| 0x030 | float |C8FFC8| CD CC 4C 3F | 0.800000 | crosshair scale factor }}
{{OBDtr| 0x034 | link |C8FFFF| 01 95 05 00 | 1428 | locked crosshair texture (link to 01429-target_1B.TXMP) }}
{{OBDtr| 0x038 | color |C8FFFF| FF FF FF 00 |255, 255, 255; 0| locked crosshair background color (blue, green, red); locked crosshair background transparency }}
{{OBDtr| 0x03C | float |C8FFFF| CD CC 4C 3F | 0.800000 | locked crosshair scale factor }}
{{OBDtr| 0x040 | link |FFC8FF| 00 00 00 00 | unused | tunnel texture (link to a TXMP) }}
{{OBDtr| 0x044 | color |FFC8FF| FF FF FF 00 |255, 255, 255; 0| tunnel background color (blue, green, red); tunnel background transparency }}
{{OBDtr| 0x048 | float |FFC8FF| 00 00 80 3F | 1.000000 | tunnel scale factor }}
{{OBDtr| 0x04C | uint32 |FFC800| 0F 00 00 00 | 15 | number of tunnel textures }}
{{OBDtr| 0x050 | float |C800C8| 00 00 20 41 | 10.000000 | spacing of tunnel textures }}
|}

;Crosshair
:Default crosshair appears where the laser sight hits environment, corpses, etc.
:Locked crosshair appears when the laser sight hits characters (including the shooter)
:"Tunnel" is used by '''w8_mbo''' as a complement to the crosshair
:'''w2_sap''', '''w5_sbg''', '''w7_scc''' and '''w9_scr''' use it with no crosshair

===0x054 to 0x05F - Ammo meter===
{{Table}}
{{OBDth}}
{{OBDtr| 0x054 | link |C87C64| 01 7E 0E 00 | 3710 | link to 03710-tap_icon.[[TXMP]] }}
{{OBDtr| 0x058 | link |C87C64| 01 7F 0E 00 | 3711 | link to 03711-tap_empty.TXMP }}
{{OBDtr| 0x05C | link |C87C64| 01 80 0E 00 | 3712 | link to 03712-tap_fill.TXMP }}
|}

===0x060 to 0x0D7 - Weapon parameters===
{{Table}}
{{OBDth}}
{{OBDtr| 0x060 | link |C87C64| 01 76 0E 00 | 3702 | link to 03702-.[[M3GM]] (3D geometry) }}
{{OBDtr2|0x064 | char[32] |B0C3D4| w1_tap | weapon name }}
{{OBDtr| 0x084 | float |E7CEA5| 00 00 80 3F | 1.000000 | weapon mouse sensitivity (applies to AI, too) }}
{{OBDtr| 0x088 | float |E7CEA5| A6 92 2B 3D | 0.041888 | recoil base (e.g. for w1_tap and w2_sap) }}
{{OBDtr| 0x08C | float |E7CEA5| 92 0A 86 3E | 0.261799 | recoil max }}
{{OBDtr| 0x090 | float |E7CEA5| 00 00 A0 40 | 5.000000 | recoil factor }}
{{OBDtr| 0x094 | float |E7CEA5| E2 A3 7B 3B | 0.003839 | recoil return speed }}
{{OBDtr| 0x098 | float |E7CEA5| 88 C3 E4 3A | 0.001745 | recoil firing return speed }}
{{OBDtr| 0x09C | float |E7CEA5| 00 00 00 00 | 0.000000 | secondHandVector X (disabled IK stuff) }}
{{OBDtr| 0x0A0 | float |E7CEA5| 00 00 00 00 | 0.000000 | secondHandVector Y}}
{{OBDtr| 0x0A4 | float |E7CEA5| 00 00 00 00 | 0.000000 | secondHandVector Z }}
{{OBDtr| 0x0A8 | float |E7CEA5| 00 00 00 00 | 0.000000 | secondHandUpVector X}}
{{OBDtr| 0x0AC | float |E7CEA5| 00 00 00 00 | 0.000000 | secondHandUpVector Y}}
{{OBDtr| 0x0B0 | float |E7CEA5| 00 00 00 00 | 0.000000 | secondHandUpVector Z}}
{{OBDtr| 0x0B4 | float |E7CEA5| 00 00 00 00 | 0.000000 | secondHandPosition X}}
{{OBDtr| 0x0B8 | float |E7CEA5| 00 00 00 00 | 0.000000 | secondHandPosition Y}}
{{OBDtr| 0x0BC | float |E7CEA5| 00 00 00 00 | 0.000000 | secondHandPosition Z}}
{{OBDtr| 0x0C0 | uint16 |FFDDDD| 00 00 | 0 | freeTime (unused); always zero }}
{{OBDtr| 0x0C2 | uint16 |FFDDDD| 95 00 | 149 | recoil animation type (149 {{=}} autopistol_recoil) }}
{{OBDtr| 0x0C4 | uint16 |FFDDDD| A4 00 | 164 | reload animation type (164 {{=}} reload_pistol) }}
{{OBDtr| 0x0C6 | uint16 |FFDDDD| 19 00 | 25 | pause after reload in 1/60 seconds }}
{{OBDtr| 0x0C8 | uint16 |FFDDDD| 0A 00 | 10 | amount of shots }}
{{OBDtr| 0x0CA | uint16 |FFDDDD| 06 00 | 6 | amount of particles }}
{{OBDtr| 0x0CC | uint16 |FFDDDD| 01 00 | 1 | amount of firing modes }}
{{OBDtr| 0x0CE | uint16 |FFDDDD| 0A 00 | 10 | pause before reload in 1/60 seconds }}
{{OBDtr| 0x0D0 | uint16 |FFDDDD| 04 00 | 4 | release delay; delay between the moment the trigger is released and the moment the weapon stops firing }}
{{OBDtr| 0x0D2 | uint16 |FFDDDD| 00 00 | 0 | padding }}
{{OBDtr| 0x0D4 | uint32 |FFDDDD| 30 | 0x30 C0 02 00 | weapon options; the following bits are possible (values in hex):

:0x'''02''' 00 00 00 - weapon can't be holstered
:0x'''04''' 00 00 00 - weapon reloads with energy cells
:0x'''08''' 00 00 00 - weapon is a rifle (two-handed)
:0x'''10''' 00 00 00 - recoil affects aiming
:0x'''20''' 00 00 00 - sustained fire (applies only to primary fire)
:0x'''40''' 00 00 00 - runtime only; do not use
:0x'''80''' 00 00 00 - stun switcher; used for w6_vdg, see below

:0x00 '''01''' 00 00 - knockdown switcher; used for w4_psm, see below
:0x00 '''02''' 00 00 - explosive; used for w5_sbg and w11_ba1
:0x00 '''04''' 00 00 - secondary fire enabled
:0x00 '''08''' 00 00 - barabbas weapon; see below
:0x00 '''10''' 00 00 - heavy weapon; run, jump and creep disabled
:0x00 '''20''' 00 00 - auto release trigger; used for w11_ba1
:0x00 '''40''' 00 00 - has release delay; see the release delay field above
:0x00 '''80''' 00 00 - laser sight visible

:0x00 00 '''02''' 00 - crosshair scaling, used for w1_tap, w2_sap, w3_phr and w8_mbo
:0x00 00 '''08''' 00 - weapon doesn't fade
:0x00 00 '''10''' 00 - drain ammo; used by w4_psm to decrement ammo while firing because its firing mode is continuous rather than repetitive
}}
|}

'''stun switcher''' - if enemy is inside shooting distance (between min and max) and is '''knockdown'''ed/'''stun'''ed or '''blownup'''ped, AI with this weapon switches to melee for a time specified in a *fight timer* field

'''knockdown switcher''' - if enemy is inside shooting distance (between min and max) and is '''knockdown'''ed or '''blownup'''ped, AI with this weapon switches to melee for a time specified in a *fight timer* field

'''barabbas weapon''' - reload disabled; also used for ai2_barabbas_retrievegun (it teleports a weapon to a character); nearest available gun becomes chosen if character had no weapon to begin, then always this weapon is teleported back to character (when command used again)

==0x0D8 to 0x1D7 - Firing modes==
Every ONWC has 2 firing mode slots (128 = 0x80 bytes each.)

The number of slots actually used by the weapon is specified at 0xCA.

===0x0D8 to 0x157 - Primary firing mode===
{{Table}}
{{OBDth}}
{{OBDtr| 0x0D8 | uint32 |64AAAA| 00 00 00 00 | 0 | firing mode options; only the following bit is used (value in hex):
:0x'''01''' 00 00 00 - No wild shots}}

{{OBDtrMatrix4x3|0x0DC|EBEBEB|23 A6 7F 3F|05 6D 56 3D|F4 8D A9 37|05 6D 56 BD|23 A6 7F 3F|D0 1D 0E B5|F4 8D A9 B7|D0 1D 0E B5|00 00 80 3F|00 00 00 00|00 00 00 00|00 00 00 00|0.998629|0.052350|0.000020| -0.052350|0.998629| -0.000001| -0.000020| -0.000001|1.000000|0.000000|0.000000|0.000000| targeting inverse transform matrix - the inverse of the matrix that gives the targeting direction}}

{{OBDtrVector3| 0x10C |EBEBEB| 23 A6 7F 3F | AE 6C 56 BD | AF 8D A9 B7 | 0.998629 | -0.052349 | -0.000020 | targeting direction; sets orientation of firingspread }}
{{OBDtrVector3| 0x118 |EBEBEB| DC FE 08 3C | 5C 11 23 3E | 39 C6 2A 3F | 0.008362 | 0.159246 | 0.667087 | targeting origin; sets deviation of AI's aim from target's origin (target's origin + this vector {{=}} direction where to aim and fire) }}
{{OBDtr| 0x124 | float |EBEBEB| 00 00 61 44 | 900.000000 | prediction speed; the speed of the projectile that AI prediction should take into account when calculating where to fire in order to hit a moving target }}
{{OBDtr| 0x128 | float |EBEBEB| 00 00 20 41 | 10.000000 | max. inaccuracy angle; sets max angle between weapon's aiming vector and target's position; when AI exceeds this angle (by recoil or target running away), AI stops shooting and aims weapon again straight to the target, then resume shooting }}
{{OBDtr| 0x12C | float |EBEBEB| 00 00 20 40 | 2.500000 | aim_radius; always the same; possibly related to the inaccuracy angle above }}
{{OBDtr| 0x130 | float |EBEBEB| 00 00 96 43 | 300.000000 | weapon sound sphere radius; defines radius of the AI sound sphere (gunfire type, see {{SectionLink|AI|Vision and hearing}} to learn about AI sound spheres) which is created for a short moment when this weapon is fired }}
{{OBDtr| 0x134 | float |EBEBEB| 00 00 40 41 | 12.000000 | minimal shooting distance; if target is closer than this, the AI ceases fire and moves away from the target till at least this distance is achieved; this is a '''diameter, not a radius''', so effective distance from AI to target is half of this value }}
{{OBDtr| 0x138 | float |EBEBEB| 00 00 61 44 | 900.000000 | maximum shooting distance; if target is further than this, the AI ceases fire and moves towards the target until it is below this distance }}
{{OBDtr| 0x13C | uint16 |8C8CCC| 05 00 | 5 | UNUSED; maximum startle misses; the maximum number of shots to which extra inaccuracy can be added when an AI begins firing at the player (always 5, but Oni does not use this field) }}
{{OBDtr| 0x13E | uint16 |8C8CCC| 01 00 | 1 | skill index (links weapon to the [[ONCC]] shooting skill table); here are the values used by Oni's ONWCs:
:0x'''01''' 00 - w0_sec (not in game)
:0x'''02''' 00 - w1_tap
:0x'''04''' 00 - w2_sap
:0x'''08''' 00 - w3_phr
:0x'''10''' 00 - w4_psm
:0x'''20''' 00 - w5_sbg
:0x'''40''' 00 - w6_vdg
:0x'''80''' 00 - w7_scc
:0x00 '''01''' - w8_mbo
:0x00 '''02''' - w9_scr
:0x00 '''04''' - w10_sni (not in game)
:0x00 '''08''' - w11_ba1
:0x00 '''10''' - w12_ba2}}
{{OBDtr| 0x140 | uint32 |8C8CCC| 00 00 00 00 | 0 | fight timer, 240 for w4_psm, 200 for v6_vdg }}
{{OBDtr| 0x144 | float |FF00C8| 00 00 00 00 | 0.000000 | ballistic projectile speed for AI prediction purposes; if this field is unused, the projectile is assumed to be infinite speed; field is always zero except 150 for Superball Gun and 160 for Wave Motion Cannon's secondary trigger }}
{{OBDtr| 0x148 | float |FF00C8| 00 00 00 00 | 0.000000 | ballistic projectile gravity for AI prediction purposes; always zero except 0.5 for SBG and 0.3 for WMC's secondary trigger }}
{{OBDtr| 0x14C | float |FF00C8| 00 00 34 43 | 180.000000 | length of a firing spread; AI will perform gunfire dodging when it finds itself inside of a firing spread (see {{SectionLink|AI|Basic combat behaviors}}); can be visualized with *ai2_showfiringspreads{{=}}1* (180 for w1_tap, 150 for w2_sap, 120 for w4_psm) }}
{{OBDtr| 0x150 | float |FF00C8| 00 00 40 40 | 3.000000 | width of the firing spread's base; can be seen by ai2_showfiringspreads{{=}}1 }}
{{OBDtr| 0x154 | float |FF00C8| 50 77 D6 3D | 0.104719 | firing spread's skew; can be seen by ai2_showfiringspreads{{=}}1 (0.1 for w1_tap, 0.21 for w2_sap) }}
|}

;Transform matrix
:Probably defines the orientation, scaling and position of the firing spread. It doesn't appear to be used.

===0x158 to 0x1D7 - Secondary firing mode===
The only vanilla weapon for which these fields are not all zero is '''w11_ba1'''. They are the exact counterparts of the fields at 0xD8 - 0x157.

==0x1D8 to 0x6D7 - Weapon particle array==
Every ONWC has 16 particle slots (80 at 0x50 bytes each). The number of slots actually used by the weapon is specified at 0xCA. Offsets are relative to the beginning of a slot.

{{Table}}
{{OBDth}}
{{OBDtrBK|1=First of 16 elements (black outline).}}
{{OBDtr| 0x000 | float |F0F096| AE 6C 56 3D | 0.052349 | transformation matrix, xx term }}
{{OBDtr| 0x004 | float |F0F096| 23 A6 7F 3F | 0.998629 | transformation matrix, xy term }}
{{OBDtr| 0x008 | float |F0F096| C2 53 90 B3 | -0.000000... | transformation matrix, xz term }}
{{OBDtr| 0x00C | float |F0F096| 23 A6 7F 3F | 0.998629 | transformation matrix, yx term }}
{{OBDtr| 0x010 | float |F0F096| AE 6C 56 BD | -0.052349 | transformation matrix, yy term }}
{{OBDtr| 0x014 | float |F0F096| AF 8D A9 B7 | -0.000020 | transformation matrix, yz term }}
{{OBDtr| 0x018 | float |F0F096| BA 59 A9 B7 | -0.000020 | transformation matrix, zx term }}
{{OBDtr| 0x01C | float |F0F096| 5B 02 85 35 | 0.000001 | transformation matrix, zy term }}
{{OBDtr| 0x020 | float |F0F096| 00 00 80 BF | -1.000000 | transformation matrix, zz term }}
{{OBDtr| 0x024 | float |F0F096| 6F 63 57 40 | 3.365444 | x-offset of particle to weapon }}
{{OBDtr| 0x028 | float |F0F096| B3 1D 89 BC | -0.016738 | y-offset of particle to weapon }}
{{OBDtr| 0x02C | float |F0F096| C5 C1 2A 3F | 0.667019 | z-offset of particle to weapon }}
{{OBDtr2|0x030 | char[16] |00C864| w1_tap_e01 | particle name (reference to 06226-3RAPw1_tap_e01.[[OBD:BINA/PAR3|BINA]]) }}
{{OBDtr| 0x040 | offset |00C8FF| 00 00 00 00 | 0 | raw offset of the particle class (raw pointer to it); runtime only }}
{{OBDtr| 0x044 | uint16 |00C8FF| 01 00 | 1 | ammo decrement (different for the 2 firing modes of w11_ba1) }}
{{OBDtr| 0x046 | uint16 |00C8FF| 0C 00 | 12 | delay between shots in frames (12 frames {{=}} 0.2 seconds) }}
{{OBDtr| 0x048 | uint16 |00C8FF| 04 00 | 4 | 'roughjustice' delay between shots in frames }}
{{OBDtr| 0x04A | uint16 |00C8FF| 00 00 | 0 | number in frames for active firing mode (1st frame for activate); Used for w4_psm and w11_ba1 }}
{{OBDtr| 0x04C | uint16 |00C8FF| 00 00 | 0 | 0 {{=}} particle is triggered by fire1; 1 {{=}} particle is triggered by fire2; -1 {{=}} particle is triggered by both firing modes }}
{{OBDtr| 0x04E | uint16 |00C8FF| 00 00 | 0 | delay before firing }}
|}

;Transformation matrix
:That's what defines orientation, stretching, etc. See [[OBD:CRSA|CRSA]] for details.

==0x6D8 to 0x71F - End of file==
[[Image:onwc_e.gif]]

{{Table}}
{{OBDth}}
{{OBDtr2|0x6D8 | char[32] |C80040| weapon _empty | empty weapon sound (reference to 08993-weapon_empty.[[OBD:OSBD/OSIm|imp.OSBD]]) }}
{{OBDtr| 0x6F8 | offset |FFCD96| 00 00 00 00 | 0 | raw offset to the empty weapon sound; runtime only }}
{{OBDtr| 0x6FC | link |C8C864| 01 81 0E 00 | 3713 | link to 03713-w1_glow.[[TXMP]] }}
{{OBDtr| 0x700 | link |C8C864| 01 82 0E 00 | 3714 | link to 03714-w1_glow_ammo.TXMP }}
{{OBDtr| 0x704 | float |0096C8| 00 00 80 3F | 1.000000 | x-scale factor of glow textures }}
{{OBDtr| 0x708 | float |0096C8| 00 00 80 3F | 1.000000 | z-scale factor of glow textures }}
{{OBDtr| 0x70C | float |0096C8| 76 65 EB 3F | 1.839034 | x-offset of pickup handle }}
{{OBDtr| 0x710 | float |0096C8| 96 4C A9 3D | 0.082666 | y-offset of pickup handle }}
{{OBDtr| 0x714 | float |0096C8| 06 E2 14 3E | 0.145393 | z-offset of pickup handle }}
{{OBDtr| 0x718 | float |0096C8| 00 00 00 00 | 0.000000 | hovering height of dropped weapon }}
|}

;Glow textures
:They're applied to the lower face of the M3GM's bounding box. The factors above are the ratio between the x/z extent of that face and the half-length/width of the glow textures. So if both factors are 0.5, the glow textures fit the bounding box exactly.
;Pickup handle
:The tolerance is hardcoded. The offsets are not relative to the weapon's axes, but to the world axes (!). This is a rather nasty "feature" because the offsets should be relative to the weapon's orientation. The way it is now, the pickup volume of a weapon is not necessarily next to the handle. That's why the WMC is so hard to pick up that some players conclude it's not possible; being the largest weapon, it has the largest potential discrepancy between its visual handle location and its pickup volume.

{{OBD_File_Footer | type=ONWC | prev=ONVL | next=OPge | name=Oni Weapon Class | family=Character}}

{{OBD}}

OBD:ONVL

2025-05-12T14:36:53Z

Mai X: ...

{{OBD_File_Header | type=ONVL | prev=ONTA | next=ONWC | name=Oni Variant List | family=Character | align=center}}

[[Image:onvl_a.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x00 | res_id |FF0000| 01 8A 06 00 | 1674 | 01674-variant_list.ONVL }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr| 0x08 | char[20] |00FF00| AD DE | dead | padding }}
{{OBDtr| 0x1C | uint32 |00FFFF| 35 00 00 00 | 53 | array size }}
{{OBDtrBK}}
{{OBDtr| 0x00 | link |FFC8C8| 01 82 06 00 | 1666 | link to 01666-any.[[OBD:ONCV|ONCV]] }}
|}

;Note
:The lookup of the [[OBD:ONCV|ONCV]] from the [[OBD:ONCC|ONCC]] can be done directly.
:The ONVL list could be used for security purposes.
:One way to check if the lookup is made ''via'' ONVL is just to remove links from it.
:(too lazy to check right now)

;Also note
:The ONVL contains the IDs of all the 54 [[OBD:ONCV|ONCV]], except '''bomber''', who used to be a variant of '''striker'''.
:It ''does'' contain the obsolete '''irondemon''' and '''tanker_casual''' [[OBD:ONCV|ONCV]].

{{OBD_File_Footer | type=ONVL | prev=ONTA | next=ONWC | name=Oni Variant List | family=Character}}

{{OBD}}

OBD:ONSK

2025-05-12T14:32:15Z

Mai X: ...

{{OBD_File_Header|align=center|type=ONSK|prev=ONSA|next=ONTA|name=Oni Sky Class|family=Level}}

[[Image:onsk_all.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x00 | res_id |FF0000| 01 C3 03 00 | 963 | 00963-sunset.ONSK }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr| 0x08 | link |00FF00| 01 0D 25 00 | 9485 | skybox top; link to sunset_top.[[OBD:TXMP|TXMP]] }}
{{OBDtr| 0x0C | link |00FF00| 01 0E 25 00 | 9486 | skybox left; link to 09486-sunset_left.[[OBD:TXMP|TXMP]]; link always used }}
{{OBDtr| 0x10 | link |00FF00| 01 0F 25 00 | 9487 | skybox left; link to 09487-sunset_right.[[OBD:TXMP|TXMP]]; link always used }}
{{OBDtr| 0x14 | link |00FF00| 01 0C 25 00 | 9484 | skybox front; link to 09484-sunset_front.[[OBD:TXMP|TXMP]]; link always used }}
{{OBDtr| 0x18 | link |00FF00| 01 0B 25 00 | 9483 | skybox back; link to 09483-sunset_back.[[OBD:TXMP|TXMP]]; link always used }}
{{OBDtr| 0x1C | link |00FF00| 00 00 00 00 | unused | skybox bottom; unused; always the same }}
{{OBDtr| 0x20 | link |00FF00| 01 10 25 00 | 9488 | planet 1; link to 09488-sunset_sun.[[OBD:TXMP|TXMP]]; only used in level 2 and 3 }}
{{OBDtr| 0x24 | link |00FF00| 00 00 00 00 | unused | planet 2; unused; always the same }}
{{OBDtr| 0x28 | link |00FF00| 00 00 00 00 | unused | planet 3; unused; always the same }}
{{OBDtr| 0x2C | link |00FF00| 00 00 00 00 | unused | planet 4; unused; always the same }}
{{OBDtr| 0x30 | link |00FF00| 00 00 00 00 | unused | planet 5; unused; always the same }}
{{OBDtr| 0x34 | link |00FF00| 00 00 00 00 | unused | planet 6; unused; always the same }}
{{OBDtr| 0x38 | link |00FF00| 00 00 00 00 | unused | planet 7; unused; always the same }}
{{OBDtr| 0x3C | link |00FF00| 00 00 00 00 | unused | planet 8; unused; always the same }}
{{OBDtr| 0x40 | link |00FF00| 00 00 00 00 | unused | sun flare texture; unused; always the same }}
{{OBDtr| 0x44 | link |00FF00| 01 11 25 00 | 9489 | star 1; link to 09489-lensflare02.[[OBD:TXMP|TXMP]]; always used (see below) }}
{{OBDtr| 0x48 | link |00FF00| 00 00 00 00 | unused | star 2; unused; always the same }}
{{OBDtr| 0x4C | link |00FF00| 00 00 00 00 | unused | star 3; unused; always the same }}
{{OBDtr| 0x50 | link |00FF00| 00 00 00 00 | unused | star 4; unused; always the same }}
{{OBDtr| 0x54 | link |00FF00| 00 00 00 00 | unused | star 5; unused; always the same }}
{{OBDtr| 0x58 | uint32 |00FFFF| 01 00 00 00 | 1 | number of used planets }}
{{OBDtr| 0x5C | uint32 |FF00FF| FF FF FF FF | -1 | number of planets with lensflares }}
{{OBDtr| 0x60 | float |FFC8C8| 00 00 80 3F | 1.000000| planet 1; U-scaling }}
{{OBDtr| 0x64 | char[28] |FFC8C8| AD DE | dead | planets 2-8; U-scaling }}
{{OBDtr| 0x80 | float |FFFFC8| 00 00 80 3F | 1.000000| planet 1; V-scaling }}
{{OBDtr| 0x84 | char[28] |FFFFC8| AD DE | dead | planets 2-8; V-scaling }}
{{OBDtr| 0xA0 | float |C8FFC8| 00 00 00 00 | 0.000000| planet 1; elevation in radians }}
{{OBDtr| 0xA4 | char[28] |C8FFC8| AD DE | dead | planets 2-8; elevation in radians }}
{{OBDtr| 0xC0 | float |C8FFFF| 00 00 00 00 | 0.000000| planet 1; azimuth in radians }}
{{OBDtr| 0xC4 | char[28] |C8FFFF| AD DE | dead | planets 2-8; azimuth in radians }}
{{OBDtr| 0xE0 | float |FFC8FF| 00 00 80 40 | 4.000000| lensflare size }}
{{OBDtr| 0xE4 | float |FFC800| 00 00 80 3F | 1.000000| lensflare alpha }}
{{OBDtr| 0xE8 | uint32 |C800C8| 00 00 00 00 | 0 | number of stars to generate }}
{{OBDtr| 0xEC | uint32 |C87C64| 45 00 00 00 | 69 | random seed for star generation }}
{{OBDtr| 0xF0 | uint32 |B0C3D4| 01 00 00 00 | 1 | star textures count; ignored }}
|}

;Skybox
:The skybox is just a cube drawn using the skybox textures. The bottom face of the cube is never used/drawn.

;Planets
:There can be up to 8 "planets" displayed using the specified textures, sizes and positions. Unfortunately there is a bug and they're no occluded by anything.

;Sun Flare
:For the first "planet" an optional "flare" can be drawn. It does not appear to work correctly and since planets don't display correctly the flare is not of much use.

;Stars
:A fixed number of stars can be displayed at random positions in the sky. Doesn't appear to work, the stars are not visible and the game crashes when the level ends.

;Original ONSK
*afternoon (level 1)
*sunset (level 2 and 3)
*crapsky (level 19)
*night (all the other levels except level 13, which has no ONSK)

{{OBD_File_Footer|type=ONSK|prev=ONSA|next=ONTA|name=Oni Sky Class|family=Level}}

{{OBD}}

OBD:ONOA

2025-05-12T14:24:34Z

Mai X: ...

{{OBD_File_Header | type=ONOA | prev=ONMA | next=ONSA | name=Object Gunk Array | family=Level | align=center}}

[[image:onoa_a.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x00 | res_id |FF0000| 01 A0 02 00 | 672 | 00672-.ONOA }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr| 0x08 | char[20] |00FF00| AD DE | dead | padding }}
{{OBDtr| 0x0C | uint32 |00FFFF| 22 01 00 00 | 290 | array size }}
{{OBDtrBK}}
{{OBDtr| 0x00 | uint32 |FFC8C8| 15 19 00 03 | 6421; 3| object ID (first 3 bytes); [[OBD:BINA/OBJC#OBJC types|object type]] (last byte) - the following object types exists:

:0x01 - character
:0x02 - patrol path
:0x03 - door
:0x04 - flag
:0x05 - furniture
:0x08 - particle
:0x09 - powerup
:0x0A - sound
:0x0B - trigger volume
:0x0C - weapon
:0x0D - trigger
:0x0E - turret
:0x0F - console
:0x10 - combat
:0x11 - melee
:0x12 - neutral
}}
{{OBDtr| 0x04 | link |FFFFC8| 01 1A 02 00 | 673 | link to [[OBD:IDXA_ONOA|00673.IDXA]] }}
|}

Obviously not all object types have coresponding gunk quads. The only object types that are used in ONOA by the original levels are door, furniture, turret, trigger and console. In addition it appears that the engine only searches for door type.

{{OBD_File_Footer | type=ONOA | prev=ONMA | next=ONSA | name=Object Gunk Array | family=Level}}

{{OBD}}

OBD:ONLV

2025-05-12T14:21:25Z

Mai X: ref. Oni_Level.h, lines 134-161...

{{OBD_File_Header | type=ONLV | prev=ONLD | next=ONMA | name=Oni Game Level | family=Level | align=center}}

[[image:onlv_all.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x000 | res_id |FF0000| 01 34 02 00 | 564 | 00564-lab.ONLV }}
{{OBDtr| 0x004 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr2|0x008 | char[64] |FFC8C8| lab | level name }}
{{OBDtr| 0x048 | link |FFFFC8| 01 3F 02 00 | 575 | link to [[OBD:AKEV|00575-lab.AKEV]] }}
{{OBDtr| 0x04C | link |FFFFC8| 01 55 02 00 | 597 | link to [[OBD:OBOA|00597-.OBOA]] }}
{{OBDtr| 0x050 | link |FFFFC8| 01 98 02 00 | 664 | link to [[OBD:ONMA|00664-.ONMA]] }}
{{OBDtr| 0x054 | link |FFFFC8| 01 99 02 00 | 665 | link to [[OBD:ONFA|00665-.ONFA]] }}
{{OBDtr| 0x058 | link |FFFFC8| 01 9A 02 00 | 666 | link to [[OBD:ONTA|00666-.ONTA]] }}
{{OBDtr| 0x05C | link |FFFFC8| 01 C3 03 00 | 963 | link to [[OBD:ONSK|00963-sunset.ONSK]] }}
{{OBDtr| 0x060 | float |FFFFC8| 00 00 00 00 | 0 | sky height; not used }}
{{OBDtr| 0x064 | link |FFFFC8| 01 9C 02 00 | 668 | link to [[OBD:AISA|00668-level3_scripts.AISA]] }}
{{OBDtr| 0x068 | link |FFFFC8| 01 9D 02 00 | 669 | link to 00669-level3_scripts.[[OBD:AITR|AITR]] }}
{{OBDtr| 0x06C | link |FFFFC8| 01 9E 02 00 | 670 | link to [[OBD:ONSA|00670-level3_scripts.ONSA]] }}
{{OBDtr| 0x070 | link |FFFFC8| 01 9F 02 00 | 671 | link to [[OBD:OBDC|00671-level3_scripts.OBDC]] }}
{{OBDtr| 0x074 | link |FFFFC8| 01 A0 02 00 | 672 | link to [[OBD:ONOA|00672-.ONOA]] }}
{{OBDtr| 0x078 | link |FFFFC8| 01 9B 02 00 | 667 | link to [[OBD:ENVP|00667-.ENVP]] }}
{{OBDtr| 0x07C | uint32 |C8FFC8| AD DE AD DE | dead | action markers array size; runtime only }}
{{OBDtrBK|1=Array of 32 action marker elements: first element }}
{{OBDtr| 0x080 | uint32 |C8FFC8| AD DE AD DE | dead | action marker ID; runtime only }}
{{OBDtr| 0x084 | float |C8FFC8| AD DE AD DE | dead | action marker X position; runtime only }}
{{OBDtr| 0x088 | float |C8FFC8| AD DE AD DE | dead | action marker Y position; runtime only }}
{{OBDtr| 0x08C | float |C8FFC8| AD DE AD DE | dead | action marker Z position; runtime only }}
{{OBDtr| 0x090 | float |C8FFC8| AD DE AD DE | dead | direction, that char needs to face to use the action marker; runtime only }}
{{OBDtrBK|1=End of array }}
{{OBDtr| 0x300 | link |C8FFFF| 01 35 02 00 | 565 | link to [[OBD:CRSA|00565-.CRSA]] }}
|}

{{OBD_File_Footer | type=ONLV | prev=ONLD | next=ONMA | name=Oni Game Level | family=Level}}

{{OBD}}

OBD:ONLD

2025-05-12T14:06:20Z

Mai X: ...

{{OBD_File_Header | type=ONLD | prev=ONIA | next=ONLV | name=Oni Game Level Descriptor | family=Level | align=center}}

[[Image:onld_all.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x00 | res_id |FF0000| 01 D5 05 00 | 1493 | 01493-level_01.ONLD }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr| 0x08 | uint16 |FFC8C8| 01 00 | 1 | current level number }}
{{OBDtr| 0x0A | uint16 |FFFFC8| 02 00 | 2 | next level number (ignored; Oni will pick the next highest level number no matter what you place here) }}
{{OBDtr2|0x0C | char[64] |C8FFC8| TCTF-Training | name of the level; you'll find it in the list, when you load a level }}
|}

;Hardcoded level name
The name of Chapter 1, "Syndicate Warehouse", is hardcoded into the engine rather than coming from the ONLD. That's because [[{{C0}}]] and [[{{C1}}]] share level1_Final.dat, which means that the ONLD could only provide a name for one chapter or the other. The loser was Syndicate Warehouse; BWest hardcoded its name to appear in place of what would have been Save Point 1 of TCTF Training (and shifted the numbering of the other save points down by one). The historical reason for this odd two-levels-in-one situation is that Combat Training was added to Oni in the final rushed month of development.

{{OBD_File_Footer | type=ONLD | prev=ONIA | next=ONLV | name=Oni Game Level Descriptor | family=Level}}

{{OBD}}

OBD:ONIA

2025-05-12T14:04:18Z

Mai X: ...

{{OBD_File_Header | align=center | type=ONIA | prev=ONGS | next=ONLD | name=Oni Character Impact Array | family=Character}}

[[image:onia_a.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x00 | res_id |FF0000| 01 FA 03 00 | 1018 | 01018-.ONIA }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 0 }}
{{OBDtr| 0x08 | char[16] |00FF00| AD DE | dead | padding }}
{{OBDtr| 0x18 | bool |00FF00| 00 | | is loaded (is indices found); must be 0, set to 1 at runtime }}
{{OBDtr| 0x19 | char[3] |00FF00| AD DE | dead | padding }}
{{OBDtr| 0x1C | uint32 |00FFFF| 02 00 00 00 | 2 | array size }}
{{OBDtrBK}}
{{OBDtr2|0x00 | char[16] |FFC8C8| konflash1 | impact name (looked up from the [[OBD:TRAM|TRAM]] file) }}
{{OBDtr2|0x10 | char[128]|FFFFC8| Kon_Super_Punch | impact type name (reference to Kon_Super_Punch.[[OBD:Impt|Impt]]) }}
{{OBDtr2|0x90 | char[16] |C8FFC8| Heavy | impact modifier; possible values are Any, Heavy, Medium, Light }}
{{OBDtr| 0xA0 | uint16 |C8FFFF| FF FF | -1 | impact type; runtime only }}
{{OBDtr| 0xA2 | uint16 |FFC8FF| 00 00 | 0 | modifier type; runtime only }}
|}

{{OBD_File_Footer | type=ONIA | prev=ONGS | next=ONLD | name=Oni Character Impact Array | family=Character}}

{{OBD}}

OBD:ONGS

2025-05-12T14:00:53Z

Mai X: ...

{{OBD_File_Header | type=ONGS | prev=ONFA | next=ONIA | name=Oni Game Settings | family=General | align=center}}

The first pic shows the first part of this file. The second pic the second part, the third pic the third part and the last pic the fourth part of it.

[[Image:ongs_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x000 | res_id |FF0000| 01 00 00 00 | 0 | 00000-game_settings.ONGS }}
{{OBDtr| 0x004 | file_id |FFFF00| 01 00 00 00 | 0 | level0_Final.dat }}
{{OBDtr| 0x008 | float |FFC8C8| 00 00 00 40 | 2.000000 | max overpower HP factor }}
{{OBDtr| 0x00C | float |FFC8C8| 00 00 80 3E | 0.250000 | normal hypo strength (see details below) }}
{{OBDtr| 0x010 | float |FFC8C8| 00 00 80 3F | 1.000000 | overpower hypo strength }}
{{OBDtr| 0x014 | float |FFC8C8| 00 00 C0 3F | 1.500000 | overpower min damage factor (see details below) }}
{{OBDtr| 0x018 | float |FFC8C8| 33 33 13 40 | 2.300000 | overpower max damage factor }}
{{OBDtr| 0x01C | uint32 |FFFFC8| 04 00 00 00 | 4 | number of used key health values for health bar color }}
{{OBDtr| 0x020 | float |C8FFC8| 00 00 00 00 | 0.000000 | 0 percent of full health }}
{{OBDtr| 0x024 | float |C8FFC8| C2 F5 28 3F | 0.660000 | 66 percent of full health }}
{{OBDtr| 0x028 | float |C8FFC8| 47 E1 7A 3F | 0.980000 | 98 percent of full health }}
{{OBDtr| 0x02C | float |C8FFC8| 00 00 80 3F | 1.000000 | 100 percent of full health }}
{{OBDtr| 0x030 | float |C8FFC8| AD DE AD DE | unused | additional space for percent of full health; unused }}
{{OBDtr| 0x034 | float |C8FFC8| AD DE AD DE | unused | additional space for percent of full health; unused }}
{{OBDtr| 0x038 | float |C8FFC8| AD DE AD DE | unused | additional space for percent of full health; unused }}
{{OBDtr| 0x03C | float |C8FFC8| AD DE AD DE | unused | additional space for percent of full health; unused }}
{{OBDtr| 0x040 | float |C8FFC8| AD DE AD DE | unused | additional space for percent of full health; unused }}
{{OBDtr| 0x044 | float |C8FFC8| AD DE AD DE | unused | additional space for percent of full health; unused }}
{{OBDtr| 0x048 | float |C8FFC8| AD DE AD DE | unused | additional space for percent of full health; unused }}
{{OBDtr| 0x04C | float |C8FFC8| AD DE AD DE | unused | additional space for percent of full health; unused }}
{{OBDtr| 0x050 | float |C8FFC8| AD DE AD DE | unused | additional space for percent of full health; unused }}
{{OBDtr| 0x054 | float |C8FFC8| AD DE AD DE | unused | additional space for percent of full health; unused }}
{{OBDtr| 0x058 | float |C8FFC8| AD DE AD DE | unused | additional space for percent of full health; unused }}
{{OBDtr| 0x05C | float |C8FFC8| AD DE AD DE | unused | additional space for percent of full health; unused }}
{{OBDtr| 0x060 | color |FFC8FF| 00 00 FF FF | 0, 0, 255; 255 | health color at 0 percent of full health (red) (see details below) }}
{{OBDtr| 0x064 | color |FFC8FF| 00 FF FF FF | 0, 255, 255; 255 | health color at 66 percent of full health (yellow) }}
{{OBDtr| 0x068 | color |FFC8FF| 2B A1 13 FF | 43, 161, 19; 255 | health color at 98 percent of full health (greenish) }}
{{OBDtr| 0x06C | color |FFC8FF| 00 FF 00 FF | 0, 255, 0; 255 | health color at 100 percent of full health (green) }}
{{OBDtr| 0x070 | color |FFC8FF| AD DE AD DE | unused | additional space for health color; unused }}
{{OBDtr| 0x074 | color |FFC8FF| AD DE AD DE | unused | additional space for health color; unused }}
{{OBDtr| 0x078 | color |FFC8FF| AD DE AD DE | unused | additional space for health color; unused }}
{{OBDtr| 0x07C | color |FFC8FF| AD DE AD DE | unused | additional space for health color; unused }}
{{OBDtr| 0x080 | color |FFC8FF| AD DE AD DE | unused | additional space for health color; unused }}
{{OBDtr| 0x084 | color |FFC8FF| AD DE AD DE | unused | additional space for health color; unused }}
{{OBDtr| 0x088 | color |FFC8FF| AD DE AD DE | unused | additional space for health color; unused }}
{{OBDtr| 0x08C | color |FFC8FF| AD DE AD DE | unused | additional space for health color; unused }}
{{OBDtr| 0x090 | color |FFC8FF| AD DE AD DE | unused | additional space for health color; unused }}
{{OBDtr| 0x094 | color |FFC8FF| AD DE AD DE | unused | additional space for health color; unused }}
{{OBDtr| 0x098 | color |FFC8FF| AD DE AD DE | unused | additional space for health color; unused }}
{{OBDtr| 0x09C | color |FFC8FF| AD DE AD DE | unused | additional space for health color; unused }}
{{OBDtrBK|Names of the meshes used for powerup items (first entry shown, six used, room for seven)}}
{{OBDtr2|0x0A0 |char[128]|C800C8| powerup_ammo | name of the 3D model of the red ammo clip (M3GMpowerup_ammo) }}
|}
;Hypo strength
:This is the coefficient for how much of the character's health is healed by a hypo. The numbers specified here mean that 25% of their max health will be restored under normal conditions, but if the character is already at maximum health then 100% of their max HP is added, doubling their health and taking them into overpower. If they are at less than max health, but high enough that the hypo's 25% effectiveness will take them above max health, then the remainder of the hypo counts at a 100% coefficient. For example, a character with a max of 200 HP and current health of 190 HP uses a hypo: it heals those 10 points and then, because 60% of the hypo's healing power is remaining, it is applied at a rate of 60% of that character's max health, taking them into overpower by an additional 120 HP (60% * 200).

;Damage factors
:The 1.5 and 2.3 figures are multipliers for damage done by melee attacks if the character is capable of overpower mode. For instance, when Konoko is at peak overpower she will do 2.3x damage with each attack, and this will ramp down to 1.5x when she is 1 point above her max HP and about to leave overpower mode.

;Health colors
:The colors are specified in the order BGRA. These are not only used for the health bar in the HUD but also hit flashes when striking enemies and for any particle that uses the "special tint" flag (e.g. Barabas' regeneration particles). The actual color used in these circumstances will be an interpolation between the specified key values, so for instance at 33% health you should expect to see a color halfway between 0%'s pure red and 66%'s pure yellow (i.e. orange).

;Order of the powerup types
:Ballistic ammo, energy ammo, hypo, shield, invisibility, [[LSI]]

----
[[Image:ongs_m1.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtrBK|Names of the "glow" textures displayed for powerups lying on the ground (first entry shown, six used, room for seven}}
{{OBDtr2| 0x420 |char[128]|C87C64| glowtex_ammo | name of the glow texture for red ammo clips (reference to 01448-glowtex_ammo.[[OBD:TXMP|TXMP]]) }}
|}

----
[[Image:ongs_m2.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x7A0 | float |B0C3D4| 00 00 A0 40 | 5.000000 | red ammo glow x size }}
{{OBDtr| 0x7A4 | float |B0C3D4| 00 00 A0 40 | 5.000000 | red ammo glow y size }}
{{OBDtr| 0x7A8 | float |B0C3D4| 00 00 A0 40 | 5.000000 | green energy cell glow x size }}
{{OBDtr| 0x7AC | float |B0C3D4| 00 00 A0 40 | 5.000000 | green energy cell glow y size }}
{{OBDtr| 0x7B0 | float |B0C3D4| 00 00 A0 40 | 5.000000 | hypo glow x size }}
{{OBDtr| 0x7B4 | float |B0C3D4| 00 00 A0 40 | 5.000000 | hypo glow y size }}
{{OBDtr| 0x7B8 | float |B0C3D4| 00 00 A0 40 | 5.000000 | force shield glow x size }}
{{OBDtr| 0x7BC | float |B0C3D4| 00 00 A0 40 | 5.000000 | force shield glow y size }}
{{OBDtr| 0x7C0 | float |B0C3D4| 00 00 A0 40 | 5.000000 | phase cloak glow x size }}
{{OBDtr| 0x7C4 | float |B0C3D4| 00 00 A0 40 | 5.000000 | phase cloak glow y size }}
{{OBDtr| 0x7C8 | float |B0C3D4| 00 00 C0 40 | 6.000000 | LSI glow x size }}
{{OBDtr| 0x7CC | float |B0C3D4| 00 00 C0 40 | 6.000000 | LSI glow y size }}
{{OBDtr| 0x7D0 | float |B0C3D4| AD DE AD DE | unused | extra powerup glow x size; unused }}
{{OBDtr| 0x7D4 | float |B0C3D4| AD DE AD DE | unused | extra powerup glow y size; unused }}
{{OBDtrBK|23 links to sounds of various gameplay events }}
{{OBDtr2|0x7D8 | char[32]|FFDDDD| ... | sound name; unused; (reference to an [[OBD:OSBD|OSBD]] file) }}
|}
;Glow size
:In local coordinates, because the orientation of a ''dropped'' powerup can be anything.
;Event impulse sounds
:0. (unused) - some missing door sound
:1. door_fail
:2. door_lock
:3. (unused) - door_unlock
:4. use_hypo
:5. (unused)
:6. inventory_fail
:7. receive_ammo
:8. receive_cell
:9. receive_hypo
:10. receive_lsi
:11. compass
:12. objective_new
:13. objective_prompt
:14. objective_complete
:15. autosave
:16. (unused)
:17. (unused)
;Event ambient sounds
:18. health_low
:19. health_over
:20. shield
:21. invis
:22. (unused)

----
[[Image:ongs_m3.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtrBK| the following 9 factors affect the notice, block and dodge specified in the [[OBD:BINA/OBJC/MELE|melee]] profile }}
{{OBDtr| 0xAB8 | float |64AAAA| 33 33 33 3F | 0.700000 | notice factor if you play on easy }}
{{OBDtr| 0xABC | float |64AAAA| 00 00 80 3F | 1.000000 | notice factor if you play on normal }}
{{OBDtr| 0xAC0 | float |64AAAA| 33 33 B3 3F | 1.400000 | notice factor if you play on hard }}
{{OBDtr| 0xAC4 | float |64AAAA| 9A 99 19 3F | 0.600000 | enemy block chance factor if you play on easy }}
{{OBDtr| 0xAC8 | float |64AAAA| 00 00 80 3F | 1.000000 | enemy block chance factor if you play on normal }}
{{OBDtr| 0xACC | float |64AAAA| 66 66 A6 3F | 1.300000 | enemy block chance factor if you play on hard }}
{{OBDtr| 0xAD0 | float |64AAAA| CD CC 4C 3F | 0.800000 | dodge factor if you play on easy }}
{{OBDtr| 0xAD4 | float |64AAAA| 00 00 80 3F | 1.000000 | dodge factor if you play on normal }}
{{OBDtr| 0xAD8 | float |64AAAA| 00 00 C0 3F | 1.500000 | dodge factor if you play on hard }}
{{OBDtr| 0xADC | float |64AAAA| 9A 99 99 3F | 1.200000 | weapon accuracy factor if you play on easy }}
{{OBDtr| 0xAE0 | float |64AAAA| 00 00 80 3F | 1.000000 | weapon accuracy factor if you play on normal }}
{{OBDtr| 0xAE4 | float |64AAAA| 9A 99 19 3F | 0.600000 | weapon accuracy factor if you play on hard }}
{{OBDtr| 0xAE8 | float |64AAAA| 00 00 80 3F | 1.000000 | enemy health factor if you play on easy }}
{{OBDtr| 0xAEC | float |64AAAA| 00 00 80 3F | 1.000000 | enemy health factor if you play on normal }}
{{OBDtr| 0xAF0 | float |64AAAA| 00 00 A0 3F | 1.250000 | enemy health factor if you play on hard }}
{{OBDtr| 0xAF4 | float |64AAAA| 66 66 A6 3F | 1.300000 | player health factor if you play on easy }}
{{OBDtr| 0xAF8 | float |64AAAA| 00 00 80 3F | 1.000000 | player health factor if you play on normal }}
{{OBDtr| 0xAFC | float |64AAAA| 00 00 80 3F | 1.000000 | player health factor if you play on hard }}
{{OBDtr| 0xB00 | uint32 |EBEBEB| 10 00 00 00 | 16 | array size }}
{{OBDtrBK}}
{{OBDtr2|0x000 | char[32]|8C8CCC| hypo | event name }}
{{OBDtr| 0x020 | uint16 |FF00C8| 01 00 | 1 | first level with autoprompting }}
{{OBDtr| 0x022 | uint16 |F0F096| 02 00 | 2 | last level with autoprompting }}
{{OBDtr2|0x024 | char[32]|00C864| autoprompt_hypo | raw file anchor for the text message (it belongs to the [[OBD:SUBT|SUBT]] file) }}
|}
;Prompts
:hypo, cell, ammo, invis, shield, lsi (5 different prompts), weapon, useconsole, usealarm, usedoor, usehypo, nci (talk to character).

{{OBD_File_Footer | type=ONGS | prev=ONFA | next=ONIA | name=Oni Game Settings | family=General}}

{{OBD}}

OBD:ONCV

2025-05-12T13:36:12Z

Mai X: Removing DEAD part... It is NOT a part of the type...

{{OBD_File_Header | type=ONCV | prev=ONCP | next=ONFA | name=Oni Character Variant | family=Character | align=center}}

All ONCV files are 0 byte files. That means that Oni takes the information out of the ONCV files of level 0.

[[Image:oncv_all.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | res_id |FF0000| 01 99 06 00 | 1689 | 01689-konoko.ONCV }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr| 0x08 | link |FFC8C8| 01 82 06 00 | 1666 | link to 01666-any.ONCV (pointer to the parent at runtime) }}
{{OBDtr2|0x0C | char[32] |FFFFC8| Konoko | character type name; Oni spawns this type when you start the game}}
{{OBDtr2|0x2C | char[32] |C8FFC8| unused | character type name; if the "upgrade difficulty" bit in the [[OBD:BINA/OBJC/CHAR|BINA/CHAR]] is set, Oni spawns this type if you play on Hard }}
|}

;Note 1: The ONCVs are used for random [[OBD:ONCC|ONCC]] selection (e.g. spawning striker_easy_1, striker_easy_2 or striker_easy_3, at random).
:If character variants are enabled (in [[OBD:BINA/OBJC/CHAR|BINA/CHAR]]):
:#The ONCC specified in BINA/CHAR is selected.
:#The ONCV link in that ONCC is looked up.
:#The actual ONCC is chosen at random from all ONCCs linking to the ONCV.

In order to experiment with this, you have to change the ONCV links in several ONCCs. For example:
:Make '''ONCCstriker_easy_1''', '''ONCCstriker_easy_2''' and '''ONCstriker_easy_3''' link to '''ONCVstriker_hard''' and vice versa:
:Make '''ONCCstriker_hard_1''', '''ONCCstriker_hard_2''' and '''ONCCstriker_hard_3''' link to '''ONCVstriker_easy'''.
Then you won't notice any change for those spawns where the character variant was disabled, and for those where it's enabled, you'll get hard Strikers instead of easy ones and vice versa.

;Note 2: The ONCV defines the "harder" characters spawned on Hard mode (if enabled in BINA/CHAR). If "harder character variants" are enabled (in BINA/CHAR):
:#The ONCC specified in BINA/CHAR is selected.
:#The ONCV link in that ONCC is looked up.
:#The "harder" ONCV name in that ONCV is looked up.
:#The actual ONCC is chosen at random from all ONCCs linking to that new ONCV.
:#In case there is no matching ONCC, the ONCC in step 1 is kept.
Thus, if you take e.g. '''ONCVninja_med''' and replace the string "ninja_hard" with "striker_hard" (not forgetting about the null char), you'll have a surprise at the start of Rooftops. In fact, anywhere where you used to have a blue Ninja on Easy and Normal,
and a red one on Hard, you'll have a red ''Striker'' on Hard. Nice, eh? (If you want a ''real'' challenge, just try "Konoko"....)

;Note 3: ONCVkonoko links to ONCVany, which links to nothing.
:Inter-ONCV linking can serve the same purpose: in Notes 1.3 and 2.4 above, any ONCC linking to the ONCV via another ONCV could also be selected.
:In order to play with that, however, you have to rename a level's ONCV, because originally only the more specific ones are included (not ONCVstriker or ONCVany).

{{OBD_File_Footer | type=ONCV | prev=ONCP | next=ONFA | name=Oni Character Variant | family=Character}}

{{OBD}}

OBD:ONCP

2025-05-12T13:33:55Z

Mai X: ...

{{OBD_File_Header | type=ONCP | prev=ONCC | next=ONCV | name=Oni Character Particle Array | family=Character | align=center}}

[[image:oncp_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | res_id |FF0000| 01 F9 03 00 | 1017 | 01017-.ONCP }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr| 0x08 | char[16] |00FF00| AD DE | dead | padding }}
{{OBDtr| 0x18 | bool |00FF00| 0 | 0 | is loaded; must be 0, set to 1 at runtime }}
{{OBDtr| 0x19 | char[3] |00FF00| AD DE | dead | padding }}
{{OBDtr| 0x1C | uint32 |00FFFF| 0D 00 00 00 | 13 | array size }}
{{OBDtrBK}}
{{OBDtr2|0x00 | char[16] |FFC8C8| acid | particle name (referenced by [[OBD:TRAM/raw0x2C|TRAM particles]]) }}
{{OBDtr2|0x10 | char[64] |FFFFC8| env_splash_e01a | [[OBD:BINA/PAR3|particle class name]] }}
{{OBDtr| 0x50 | uint16 |C8FFC8| FF FF | -1 | number of the bodypart; see below }}
{{OBDtr| 0x52 | char[2] |C8FFFF| 5F 00 | 95 | padding }}
{{OBDtr| 0x54 | offset |FFC8FF| 00 00 00 00 | 0 | raw offset of particle class; runtime only }}
|}

;Note
:The ONCP is the list of all the particles (motion trails, combo flashes, etc) that will be available for the [[OBD:ONCC|ONCC]] that links to it.
:Nothing bad happens if an ONCC doesn't find a particle required by an animation, you just get a warning at the console.
:However, [[AE]]'s glass-breaking animations will give you a ''lot'' of warnings without the right ONCP (basically for all combat moves, not just flashy ones).

;Bodypart number
*0-19 - this is a super particle attached to the specified bodypart when the character has daodan powers; the particle name must start with super for this to work; particle events are as follows:
**particle is "create"d (if absent) and "start"ed when entering overpower while the character is "active";
**particle is "stop"ped when overpower runs out;
**particle is killed (either is deleted or "die"s on its own) when/if the character goes "inactive".
*0xFFFF - the particle is attached by an animation (the animation specifies the bodypart); particle events are as follows:
**the animation can "create" multiple instances of a particle as necessary (one per bone involved), at the start of the animation;
**particle is "start"ed and "stop"ped according to the frames specified in [[OBD:TRAM/raw0x2C|TRAM]];
**particle is killed at the end of the animation
*0x8000 - the particle is attached by an animation (the animation specifies the bodypart) and it also generates a Self_Damage_Killed impact (user by back breaking animations); particle event rules are same as for 0xFFFF

{{OBD_File_Footer | type=ONCP | prev=ONCC | next=ONCV | name=Oni Character Particle Array | family=Character}}

{{OBD}}

OBD:ONCC

2025-05-12T13:30:02Z

Mai X: ref. ONI_Character.h, lines 448-506...

{{OBD_File_Header | type=ONCC | prev=OFGA | next=ONCP | name=Oni Character Class | family=Character | align=center}}

[[Image:oncc_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x000 | res_id |FF0000| 01 DF 03 00 | 991 | 00991-konoko_generic.ONCC }}
{{OBDtr| 0x004 | lev_id |FFFF00| 01 00 00 06 | 0 | level 3 }}
{{OBDtr| 0x008 | float |00FF00| CD CC 0C 3F | 0.550000 | fall speed (always 0.55) (mostly unused, see below) }}
{{OBDtr| 0x00C | float |00FF00| 8F C2 75 3D | 0.060000 | strength of gravity for this character }}
{{OBDtr| 0x010 | float |00FF00| CD CC 8C 3F | 1.100000 | starting velocity for a simple (tap) JUMP }}
{{OBDtr| 0x014 | float |00FF00| 00 00 80 C0 | -4.000000 | maximum velocity for jumping and falling }}
{{OBDtr| 0x018 | float |00FF00| 8F C2 F5 3C | 0.030000 | upward acceleration as long as you hold JUMP }}
{{OBDtr| 0x01C | uint16 |00FFFF| 07 00 | 7 | fall timer (always 7) (mostly unused, see below) }}
{{OBDtr| 0x01E | uint16 |00FFFF| 14 00 | 20 | how long you can continue holding down JUMP to increase the height of your jump }}
{{OBDtr| 0x020 | float |FF00FF| 00 00 34 42 | 45.000000 | maximum falling height without damage }}
{{OBDtr| 0x024 | float |FF00FF| 00 00 07 43 | 135.000000 | maximum falling height with damage }}
|}

;Units
:times are in frames
:heights are in world units (0.1m or 4")
:velocities are in world units per tick (1/60s)
:accelerations are in world units per tick squared

;Fall speed and timer
:These two fields are only looked at when predicting whether an attack will hit a target while the attacker is in midair. They are probably a development relic that is looked at in error, as the actual falling speed is determined by 0x00C and the actual fall timer is 0x01E.

;Jetpack timer
:You can press JUMP multiple times during the time window when it's large enough. See the [http://mods.oni2.net/node/83 Barabas Jetpack mod] for an application of this principle.

;Falling height: let FH1 be the height at 0x20
:let FH2 be the height at 0x24
:let BH be the base health of the character
:let FH be the actual falling height
:then, if FH > FH2, the character is killed
:if FH < FH1, the character takes no damage
:if FH1 < FH < FH2, the character takes damage (FH - FH1) / (FH2 - FH1) * BH

;Shadow Constants

{{Table}}
{{OBDth}}
{{OBDtr| 0x028 | link |FF8000| 01 F8 03 00 | 1016 | link to 01016-shadow1.[[OBD:TXMP|TXMP]] }}
{{OBDtr| 0x02C | float |FF8000| 00 00 40 41 | 12.000000 | height where the diameter of the shadow shrinks to 0x03C }}
{{OBDtr| 0x030 | float |FF8000| 00 00 00 41 | 8.000000 | height range over which the diameter of the shadow decreases from 0x034 to 0x038 and the shadow starts to fades out from 0x040 to 0x042 }}
{{OBDtr| 0x034 | float |FF8000| 00 00 C0 40 | 6.000000 | maximum diameter of the shadow }}
{{OBDtr| 0x038 | float |FF8000| 00 00 90 40 | 4.500000 | diameter that the shadow shrinks to when 0x030 is reached }}
{{OBDtr| 0x03C | float |FF8000| 00 00 40 40 | 3.000000 | minimum diameter of the shadow }}
{{OBDtr| 0x040 | uint16 |FF8000| 30 00 | 48 | starting transparency of the shadow as the character rises towards 0x030 }}
{{OBDtr| 0x042 | uint16 |FF8000| 30 00 | 48 | starting transparency of the shadow when the character begins to get above 0x030 }}
|}

;Jump Constants

{{Table}}
{{OBDth}}
{{OBDtr| 0x044 | float |FF0080| 00 00 C8 41 | 25.000000 | jump distance; unused (always 25) }}
{{OBDtr| 0x048 | uint8 |FFC8C8| 16 | 22 | jump height; unused (always 22) }}
{{OBDtr| 0x049 | uint8 |FFC8C8| 06 | 6 | jump distance squares(?); unused (always 6) }}
{{OBDtr| 0x04A | char[2] |FFC8C8| AD DE | dead | padding }}
|}

;Cover Constants

{{Table}}
{{OBDth}}
{{OBDtr| 0x04C | float |FFFFC8| 00 00 20 42 | 40.000000 | ray increment(?); unused (always 40) }}
{{OBDtr| 0x050 | float |FFFFC8| 00 00 96 43 | 300.000000 | ray max(?); unused (always 300) }}
{{OBDtr| 0x054 | float |FFFFC8| 35 FA 8E 3C | 0.017453 | ray angle(?); unused (always π/180) }}
{{OBDtr| 0x058 | float |FFFFC8| DB 0F C9 3F | 1.570796 | ray angle max(?);unused (always π/2) }}
|}

;Autofreeze Constants

{{Table}}
{{OBDth}}
{{OBDtr| 0x05C | float |FFFFC8| 00 00 A0 40 | 5.000000 | distance X+Z(?); unused (always 5) }}
{{OBDtr| 0x060 | float |FFFFC8| 00 00 80 3F | 1.000000 | distance Y(?); unused (always 1) }}
|}

;Inventory Constants

{{Table}}
{{OBDth}}
{{OBDtr| 0x064 | uint16 |C8FFC8| 06 00 | 6 | hypo regeneration rate in ticks per hit point restored }}
{{OBDtr| 0x066 | char[2] |C8FFC8| AD DE | dead | padding }}
|}

;LOD Constants
Squares of the distance from the camera at which each LOD kicks in ([[LOD|this article]] has the full calculation for arriving at the LOD to use)
{{Table}}
{{OBDth}}
{{OBDtr| 0x068 | float |C8FFFF| 00 10 3D 48 |193600.000000| distance squared(?); always 440 squared }}
{{OBDtr| 0x06C | float |C8FFFF| 00 10 3D 47 | 48400.000000| distance squared(?); always 220 squared }}
{{OBDtr| 0x070 | float |C8FFFF| 00 10 3D 46 | 12100.000000| distance squared(?); always 110 squared }}
{{OBDtr| 0x074 | float |C8FFFF| 00 00 00 00 | 0.000000 | distance squared(?); always 0 }}
{{OBDtr| 0x078 | float |C8FFFF| 00 00 00 00 | 0.000000 | distance squared(?); always 0 }}
|}

;Hurt Sound Constants

See [[XML:ONCC#.3CHurtSoundConstants.3E|HERE]] for the full calculation of whether to play a hurt sound and which sound to play.

{{Table}}
{{OBDth}}
{{OBDtr| 0x07C | uint16 |FFC8FF| 23 00 | 35 | minimum chance <code>in %</code> of playing a pain sound (always 35) }}
{{OBDtr| 0x07E | uint16 |FFC8FF| 5A 00 | 90 | maximum chance <code>in %</code> of playing a pain sound in % (always 90) }}
{{OBDtr| 0x080 | uint16 |FFC8FF| 0F 00 | 15 | at least this much damage <code>in %</code> must be done to play a pain sound (always 15) }}
{{OBDtr| 0x082 | uint16 |FFC8FF| 78 00 | 120 | time in ticks before the damage tracker used for this AI's pain sounds resets (always 120) }}
{{OBDtr| 0x084 | uint16 |FFC8FF| 23 00 | 35 | time in ticks that must pass between pain sounds being played (always 35) }}
{{OBDtr| 0x086 | uint16 |FFC8FF| 01 00 | 1 | number of times that AI will play light pain sound before "upgrading" to a medium pain sound (always 1) }}
{{OBDtr| 0x088 | uint16 |FFC8FF| 02 00 | 2 | number of times that AI will play medium pain sound before "upgrading" to a heavy pain sound (always 2) }}
{{OBDtr| 0x08A | uint16 |FFC8FF| 64 00 | 100 | chance of playing a death sound (always 100) }}
{{OBDtr| 0x08C | uint16 |FFC8FF| 0A 00 | 10 | minimum damage required for an AI to play the pain sound at maximum volume (always 10) }}
{{OBDtr| 0x08E | uint16 |FFC8FF| 0C 00 | 12 | cumulative damage before a light pain sound gets upgraded to a medium pain sound (always 12) }}
{{OBDtr| 0x090 | uint16 |FFC8FF| 16 00 | 22 | cumulative damage before a medium pain sound gets upgraded to a heavy pain sound (always 22) }}
{{OBDtr| 0x092 | bool |FFC800| 00 | 0 | runtime only: if sound pointers have been set (if sounds are found) }}
{{OBDtr| 0x093 | char[1] |C800C8| DE | dead | padding }}
{{OBDtr| 0x094 | float |C87C64| 00 00 00 3F | 0.500000 | minimum volume of pain sound (before 0x08C is reached and volume becomes 100%) }}
{{OBDtr2|0x098 | char[32] |B0C3D4| konoko_hurt_light | light hurt sound (reference to 08121-konoko_hurt_light.[[OBD:OSBD|imp.OSBD]] of level 0) }}
{{OBDtr2|0x0B8 | char[32] |B0C3D4| konoko_hurt_medium | medium hurt sound (reference to 08123-konoko_hurt_medium.imp.OSBD of level 0) }}
{{OBDtr2|0x0D8 | char[32] |B0C3D4| konoko_hurt_heavy | heavy hurt sound (reference to 08119-konoko_hurt_heavy.imp.OSBD of level 0) }}
{{OBDtr2|0x0F8 | char[32] |B0C3D4| konoko_death | death sound (reference to 08115-konoko_death.imp.OSBD of level 0) }}
{{OBDtr| 0x118 | offset |E7CEA5| 00 00 00 00 | 0 | runtime only: raw offset of light hurt sound }}
{{OBDtr| 0x11C | offset |E7CEA5| 00 00 00 00 | 0 | runtime only: raw offset of medium hurt sound }}
{{OBDtr| 0x120 | offset |E7CEA5| 00 00 00 00 | 0 | runtime only: raw offset of heavy hurt sound }}
{{OBDtr| 0x124 | offset |E7CEA5| 00 00 00 00 | 0 | runtime only: raw offset of death sound }}
|}

;AI Constants

{{Table}}
{{OBDth}}
{{OBDtr| 0x128 | bitset |E7CEA5| 17 00 00 00 | 23 | AI options bitset; see below }}
{{OBDtr| 0x12C | float |FFDDDD| 00 00 80 3F | 1.000000 | AI rotation speed factor; always 1.0 }}
{{OBDtr| 0x130 | uint16 |64AAAA| 06 00 | 6 | minimum number of frames AI remains in fallen position when it is knocked down; overriden by char's MELE profile if possible }}
{{OBDtr| 0x132 | uint16 |64AAAA| 18 00 | 24 | maximum number of frames AI remains in fallen position when it is knocked down; overriden by char's MELE profile if possible }}
{{OBDtr| 0x134 | uint32 |EBEBEB| 0F 00 00 00 | 15 | number of frames after which AI realizes that it is in the firing spread and it starts dodging }}
{{OBDtr| 0x138 | float |8C8CCC| 00 00 80 3F | 1.000000 | minimum dodge time; how long AI should perform dodging/hiding in response to being inside a firing spread (the higher it is, the longer he will hide/dodge even after firing spread disappears) }}
{{OBDtr| 0x13C | float |8C8CCC| 00 00 80 3F | 1.000000 | dodge priority dampening; the higher it is, the lower priority the AI gives to dodging }}
|}

;AI options bitset
:allows or disables some parts of the AI behavior
*no flags - startle anim is enabled, rest is disabled
*0x01 - startle anim disabled
*0x02 - firing spread/projectile dodge enabled for melee
*0x04 - requires 0x02; firing spread/projectile dodge enabled for weapons; AI tries to face shooter and shoot back while dodging
*0x08 - requires 0x02, overrides 0x04 if both are set; firing spread/projectile dodge enabled for weapons; AI isn't shooting, it just tends to run away, not facing shooter
*0x10 - bit not used

;AI rotation speed factor
:reference rotation speed is about 1 turn (360°) per second
:the setting is only effective if the AI is in control
:so it's a bit like the AI's mouse sensitivity :)

;AI Targeting Prediction Constants

See [[XML:ONCC#.3CTargeting.3E|HERE]] for how the variables here interact to control the AI's target prediction.

{{Table}}
{{OBDth}}
{{OBDtr| 0x140 | float |8C8CCC| 00 00 00 3F | 0.500000 | multiplied against target's distance to get error in AI's/turret's first wild shot (always 0.5) }}
{{OBDtr| 0x144 | float |8C8CCC| 00 00 C8 41 | 25.000000 | max value for result of multiplication above (always 25) }}
{{OBDtr| 0x148 | float |8C8CCC| 00 00 80 3F | 1.000000 | accuracy multiplier for prediction of target's position (always 1) }}
{{OBDtr| 0x14C | uint32 |FF00C8| 00 00 00 00 | 0 | maximum allowed frames of lookback to be used for predicting target's position (always 0) }}
{{OBDtr| 0x150 | uint32 |FF00C8| 05 00 00 00 | 5 | frames of delay in recognizing target's current position (always 5) }}
{{OBDtr| 0x154 | uint32 |FF00C8| 0F 00 00 00 | 15 | number of frames over which AI can average target's velocity to help predict position (always 15) }}
{{OBDtr| 0x158 | uint32 |FF00C8| 3C 00 00 00 | 60 | size in frames of target's history location buffer (always 60) }}
|}

;AI Weapon Skills

This is an array of 13 sets of skill variables, one for each weapon. Below is the data for the first element:

{{Table}}
{{OBDth}}
{{OBDtr| 0x15C | float |F0F096| 00 00 00 00 | 0.000000 | recoil compensation amount (0.0 <nowiki>= no compensation, 1.0 =</nowiki> no recoil) }}
{{OBDtr| 0x160 | float |F0F096| 00 00 00 00 | 0.000000 | minimum aiming error as an angle in radians }}
{{OBDtr| 0x164 | float |F0F096| 00 00 00 00 | 0.000000 | shot grouping error as a percentage }}
{{OBDtr| 0x168 | float |F0F096| 00 00 80 3F | 1.000000 | how quickly aiming inaccuracy decreases or increases while shooting (ranges from 0.0 to 1.0) }}
{{OBDtr| 0x16C | float |F0F096| 00 00 80 3F | 1.000000 | shooting inaccuracy multiplier }}
{{OBDtr| 0x170 | uint16 |00C864| 00 00 | 0 | minimum delay in ticks before pulling the trigger again }}
{{OBDtr| 0x172 | uint16 |00C864| 00 00 | 0 | maximum delay in ticks before pulling the trigger again }}
|}

AI weapon skills can be reviewed with e.g. '''ai2_skill_select konoko_generic w1_tap''' and then either '''ai2_skill_show''' (prints to console) or '''ai2_skill_save''' (prints to file).

The first weapon (weapon 0) is not in the game anymore, whatever it was. Mutant Muro's thunderbolt is handled as animation-bound particles, although it used to be handled as a weapon (same for Mukade's Devil Star, except '''w10_sni''' is still available). Barabas' Wave Motion Cannon is a bit mixed up since the beam is made of '''w12_ba2''' particles and the grenade is a '''w11_ba1''' particle.

{{Table}}
|- bgcolor="#E9E9E9" align=center
!Weapon ||Offset ||recoil||bestangle||error||decay||inaccuracy||delays
|- align=center
|'''w0_sec''' ||0x15C/0x173|| 0.0 || 0.000000|| 0.00|| 1.0 || 1.0 || 0 - 0
|- align=center
|'''w1_tap''' ||0x174/0x18B|| 0.0 || 0.000000|| 0.40|| 0.4 || 0.0 || 30 - 45
|- align=center
|'''w2_sap''' ||0x18C/0x193|| 0.3 || 0.013962|| 0.13|| 1.0 || 1.0 || 0 - 0
|- align=center
|'''w3_phr''' ||0x194/0x20B|| 0.3 || 0.010472|| 0.05|| 0.5 || 1.0 || 0 - 0
|- align=center
|'''w4_psm''' ||0x20C/0x213|| 0.3 || 0.015707|| 0.03|| 0.2 || 1.0 || 0 - 0
|- align=center
|'''w5_sbg''' ||0x214/0x22B|| 0.3 || 0.001745|| 0.00|| 0.1 || 1.0 || 0 - 0
|- align=center
|'''w6_vdg''' ||0x22C/0x233|| 0.3 || 0.001745|| 0.13|| 0.9 || 1.0 || 0 - 0
|- align=center
|'''w7_scc''' ||0x234/0x24B|| 0.3 || 0.001745|| 0.05|| 0.1 || 1.0 || 0 - 0
|- align=center
|'''w8_mbo''' ||0x24C/0x253|| 0.3 || 0.005236|| 0.01|| 0.5 || 1.0 || 0 - 0
|- align=center
|'''w9_scr''' ||0x254/0x26B|| 0.3 || 0.010472|| 0.04|| 0.5 || 1.0 || 0 - 0
|- align=center
|'''w10_sni'''||0x26C/0x273|| 0.0 || 0.000000|| 0.00|| 1.0 || 1.0 || 0 - 0
|- align=center
|'''w11_ba1'''||0x274/0x28B|| 0.0 || 0.000000|| 0.00|| 1.0 || 1.0 || 0 - 0
|- align=center
|'''w12_ba2'''||0x28B/0x293|| 0.0 || 0.000000|| 0.00|| 1.0 || 1.0 || 0 - 0
|}

;Other AI Behaviors
[[Image:oncc_m.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x294 | uint32 |00C8FF| 5A 00 00 00 | 90 | how long AI will continue shooting a dead body to make sure it's dead (always 90) }}
{{OBDtr| 0x298 | uint32 |00C8FF| F0 00 00 00 | 240 | how long AI will stand over dead body before returning to last job (always 240) }}
{{OBDtr| 0x29C | uint32 |00C8FF| B4 00 00 00 | 180 | how long after losing sight of target until AI engages pursuit mode (always 180) }}
{{OBDtr| 0x2A0 | uint32 |00C8FF| 28 00 00 00 | 40 | chance (as a percentage) of AI taunting a dead body }}
{{OBDtr| 0x2A4 | uint32 |00C8FF| 37 00 00 00 | 55 | chance (as a percentage) of AI running to some weapon to pick it up; can be checked in Dev Mode with the '''debug_gun_behavior''' command }}
{{OBDtr| 0x2A8 | uint32 |00C8FF| 3C 00 00 00 | 60 | chance (as a percentage) of AI performing a running weapon pickup (including acrobatics moves, slides) instead of the normal "stop and pick up"; this is calculated after the engine decides that the AI will go for a gun }}
{{OBDtr| 0x2AC | uint16 |C80040| 00 00 | 0 | combat profile ID; for example *0D* is for Mutant Muro }}
{{OBDtr| 0x2AE | uint16 |C80040| 16 00 | 22 | melee profile ID }}
{{OBDtr| 0x2B0 | uint8 |FFCD96| 64 | 100 | "taunt" sound probability (always) }}
{{OBDtr| 0x2B1 | uint8 |FFCD96| 00 | 0 | "alert" sound probability (never) }}
{{OBDtr| 0x2B2 | uint8 |FFCD96| 00 | 0 | "startle" sound probability (never) }}
{{OBDtr| 0x2B3 | uint8 |FFCD96| 00 | 0 | "checkbody" sound probability (never) }}
{{OBDtr| 0x2B4 | uint8 |FFCD96| 00 | 0 | "pursue" sound probability (never) }}
{{OBDtr| 0x2B5 | uint8 |FFCD96| 00 | 0 | "cower" sound probability (never) }}
{{OBDtr| 0x2B6 | uint8 |FFCD96| 64 | 100 | "superpunch" probability (always) }}
{{OBDtr| 0x2B7 | uint8 |FFCD96| 64 | 100 | "superkick" probability (always) }}
{{OBDtr| 0x2B8 | uint8 |FFCD96| 00 | 0 | "super3" sound probability (never) }}
{{OBDtr| 0x2B9 | uint8 |FFCD96| 00 | 0 | "super4" sound probability (never) }}
{{OBDtr| 0x2BA | char[2] |C8C864| 00 00 | 0 | padding }}
{{OBDtr2|0x2BC | char[32] |0096C8| c17_99_28konoko | "taunt" sound (reference to 08108-c17_99_28konoko.[[OBD:OSBD|amb.OSBD]] of level 0) }}
{{OBDtr2|0x2DC | char[32] |0096C8| unused | "alert" sound name }}
{{OBDtr2|0x2FC | char[32] |0096C8| unused | "startle" sound name }}
{{OBDtr2|0x31C | char[32] |0096C8| unused | "checkbody" sound name }}
{{OBDtr2|0x33C | char[32] |0096C8| unused | "pursue" sound name }}
{{OBDtr2|0x35C | char[32] |0096C8| unused | "cower" sound name }}
{{OBDtr2|0x37C | char[32] |0096C8| c18_79_14konoko | "superpunch" sound name (reference to 08110-c17_99_28konoko.amb.OSBD of level 0) }}
{{OBDtr2|0x39C | char[32] |0096C8| c18_79_15konoko | "superkick" sound name (reference to 08112-c17_99_28konoko.amb.OSBD of level 0) }}
{{OBDtr2|0x3BC | char[32] |0096C8| unused | "super3" sound name (only Mukade uses this slot) }}
{{OBDtr2|0x3DC | char[32] |0096C8| unused | "super4" sound name (never used in game data) }}
{{OBDtrBK|The following 7 vision fields are used to detect if a character can be seen by AI; see Vision Field below for explanation }}
{{OBDtr| 0x3FC | float |FF80C0| 00 80 ED 43 | 475.000000 | central vision distance }}
{{OBDtr| 0x400 | float |FF80C0| 00 00 16 43 | 150.000000 | peripheral vision distance }}
{{OBDtr| 0x404 | float |FF80C0| 7D 1B 44 3F | 0.766044 | vertical vision range }}
{{OBDtr| 0x408 | float |FF80C0| F3 B3 51 3F | 0.819152 | central vision range }}
{{OBDtr| 0x40C | float |FF80C0| E8 D5 12 3F | 0.573576 | central vision max }}
{{OBDtr| 0x410 | float |FF80C0| D5 D0 31 3E | 0.173648 | peripheral vision range }}
{{OBDtr| 0x414 | float |FF80C0| 6B 61 D8 BE | 0.422618 | peripheral vision max }}
{{OBDtr| 0x418 | uint32 |D0C0AF| B4 00 00 00 | 180 | how long will AI know exactly where its enemy is even if it can't see him with central vision field, and attempt to attack him }}
{{OBDtr| 0x41C | uint32 |D0C0AF| 84 03 00 00 | 900 | how long will AI remain strongly convinced that there is an enemy, but will investigate his presence rather than attack him }}
{{OBDtr| 0x420 | uint32 |D0C0AF| 10 0E 00 00 | 3600 | how long an AI will remain weakly convinced of an enemy's presence, looking around aimlessly to find him (Glance pursuit mode) }}
{{OBDtr| 0x424 | uint32 |D0C0AF| 10 0E 00 00 | 3600 | decay time for dropping back from high alert to medium alert }}
{{OBDtr| 0x428 | uint32 |D0C0AF| 50 46 00 00 | 18000 | decay time for dropping back from medium alert to low alert }}
{{OBDtr| 0x42C | uint32 |D0C0AF| A0 8C 00 00 | 36000 | decay time for dropping back from low alert to no alert status }}
{{OBDtr| 0x430 | float |EEDDFF| 00 00 80 3F | 1.000000 | hearing radius; defines size of the sound-detection sphere around an AI }}
|}

;Vision Field
See [[XML:ONCC#.3CVisionConstants.3E|HERE]] for details on how this works.

;File Links

{{Table}}
{{OBDth}}
{{OBDtr| 0x434 | link |C5FF8A| 01 FB 03 00 | 1019 | link to 01019-konoko.[[OBD:ONCV|ONCV]]; defines variants and upgrades }}
{{OBDtr| 0x438 | link |C5FF8A| 01 F9 03 00 | 1017 | link to [[OBD:ONCP|01017-.ONCP]]; lists the particles available for this character (trails, flashes, etc) }}
{{OBDtr| 0x43C | link |C5FF8A| 01 FA 03 00 | 1018 | link to [[OBD:ONIA|01018-.ONIA]]; lists the special impact sounds (used for special combat moves) }}
{{OBDtr| 0x440 | bool |C5FF8A| 00 | unused | indices found(?); runtime only }}
{{OBDtr| 0x441 | uint8 |C5FF8A| 00 | unused | padding }}
{{OBDtr| 0x442 | uint16 |C5FF8A| 00 00 | unused | modifier type; runtime only }}
{{OBDtr2|0x444 | char[16] |C0C0C0| Light | modifier; either hardcoded or defunct (only visible in pm_mod_type.WMM_, level 0)
edit: WMDD says: Effects found for Impact x on Material y with Modifier: pm_mod_types }}
{{OBDtrBK|1=Array of 15 impact elements: first element }}
{{OBDtr2|0x454 | char[128] |FF0080| Footstep_Walk | walk impact (reference to 04124-Footstep_Walk.Impt of level 0); always the same; without the impacts you can't hear the steps of a character }}
{{OBDtr| 0x4D4 | uint16 |FF0080| FF FF | -1 | set at runtime to the value stored at 0x08 in [[OBD:Impt|Impt]] }}
{{OBDtrBK|1=End of array }}
{{OBDtr| 0xBF2 | char[2] |FFFFA5| 00 00 | unused | padding (seen below) }}
|}
 
 

[[Image:oncc_e.gif]]

{{Table}}
{{OBDth}}
{{OBDtr2|0xBF4 | char[64] |71FFB8| unused | special death particle; only the Mad Bomber uses it }}
{{OBDtr| 0xC34 | offset |0000BF| 00 00 00 00 | unused | runtime: raw offset of death particle class }}
{{OBDtr| 0xC38 | offset |0000BF| 00 00 00 00 | unused | runtime: raw offset of cache of derived information on body model geometry }}
{{OBDtr| 0xC3C | link |0000BF| 01 E6 03 00 | 998 | link to [[OBD:TRBS|00998-konoko_body_high.TRBS]] }}
{{OBDtr| 0xC40 | link |0000BF| 01 E7 03 00 | 999 | link to [[OBD:TRMA|00999-konoko002_high_texture_generic.TRMA]] }}
{{OBDtr| 0xC44 | link |0000BF| 01 E8 03 00 | 1000 | link to [[OBD:CBPM|01000-.CBPM]] }}
{{OBDtr| 0xC48 | link |0000BF| 01 EC 03 00 | 1004 | link to [[OBD:CBPI|01004-.CBPI]] }}
{{OBDtr| 0xC4C | uint32 |804040| 2C 01 00 00 | 300 | how long in ticks before character can leave fight mode }}
{{OBDtr| 0xC50 | uint32 |804040| 30 75 00 00 | 30000 | how long in ticks before the Idle animation can be played the first time }}
{{OBDtr| 0xC54 | uint32 |804040| 30 75 00 00 | 30000 | how long in ticks before the Idle animation can be played another time }}
{{OBDtr| 0xC58 | uint32 |804040| C8 00 00 00 | 200 | base health of the character model; specific health information for every unique character is stored in the [[OBD:BINA/OBJC/CHAR|Character.BINA]] file}}
{{OBDtr| 0xC5C | uint32 |804040| 48 00 00 00 | 72 | the bits that marks the characters feet; unused }}
{{OBDtr| 0xC60 | float |FF22FF| 00 00 80 3F | 1.000000 | minimum body size factor }}
{{OBDtr| 0xC64 | float |FF22FF| 00 00 80 3F | 1.000000 | maximum body size factor }}
{{Anchor|DamageTypes}}
{{OBDtrBK|The following 7 float values are ONCC-specific multipliers for each of the 7 PAR3 DamageTypes. See [[Particle damage types]] for an explanation of DamageTypes. Values range from 0.0-1.0, with 0 meaning "no immunity" and 1 meaning "total immunity". 
Note: These multipliers only affect the stun damage and knockback components of a PAR3 action, not the HP damage dealt.}}
{{OBDtr| 0xC68 | float |FF22FF| 00 00 00 00 | 0.000000 | "Normal" DamageType multiplier }}
{{OBDtr| 0xC6C | float |FF22FF| 00 00 00 00 | 0.000000 | "MinorStun" DamageType multiplier }}
{{OBDtr| 0xC70 | float |FF22FF| 00 00 00 3F | 0.500000 | "MajorStun" DamageType multiplier }}
{{OBDtr| 0xC74 | float |FF22FF| 00 00 80 3E | 0.250000 | "MinorKnockdown" DamageType multiplier }}
{{OBDtr| 0xC78 | float |FF22FF| 00 00 00 00 | 0.000000 | "MajorKnockdown" DamageType multiplier }}
{{OBDtr| 0xC7C | float |FF22FF| 00 00 00 00 | 0.000000 | "Blownup" DamageType multiplier }}
{{OBDtr| 0xC80 | float |FF22FF| 00 00 00 00 | 0.000000 | "Pickup" DamageType multiplier }}
{{OBDtr| 0xC84 | float |FF22FF| 00 00 00 3F | 0.500000 | damage reducer, employed when the character has a [[boss shield]] (0.0-1.0 <nowiki>=</nowiki> 0%-100%) }}
{{OBDtr| 0xC88 | link |808080| 01 F6 03 00 | 1014 | link to 01014-konoko_animations.[[OBD:TRAC|TRAC]] }}
{{OBDtr| 0xC8C | link |808080| 01 F6 03 00 | 1015 | link to 01015-konoko_screens.[[OBD:TRSC|TRSC]] }}
{{OBDtr| 0xC90 | uint16 |FFAA82| 1E 00 | 30 | AI rate of firing; unused }}
{{OBDtr| 0xC92 | uint16 |FFAA82| 00 00 | 0 | time between death and deletion, in frames (0 for all characters except Mad Bomber, who is 190 ticks) }}
{{OBDtr| 0xC94 | bool |00D900| 00 | 0 | TRSC bitset; see below }}
{{OBDtr| 0xC95 | bool |00D900| 01 | 1 | character has Daodan powers (can overheal with hypos, do more damage in overpower mode) and can display a Daodan aura particle)}}
{{OBDtr| 0xC96 | bool |00D900| 00 | 0 | character has [[supershield]] }}
{{OBDtr| 0xC97 | bool |00D900| 00 | 0 | knockdown resistant (used by MutantMuro.ONCC) }}
|}

;TRSC bitset
:Determines whether character is left-handed or right-handed (weapon is attached to left or right fist bone). Must be consistent with character's TRSC or glitches appear. Possibilities are:
:NONE - Character is right-hander with both pistols and rifles
:0x01 - Character is left-hander with both pistols and rifles
:0x02 - Character is left-hander with pistols but "right-hander" with rifles (however, animations for rifles are treated as left-handed)

;Body size factor
{|align=right
|[[Image:ONCC_body_size_factor-original.jpg|120px]]
|-
|[[Image:ONCC_body_size_factor-spawn_order_change.jpg|120px]]
|}

:The geometry specified in a character's [[TRBS]] (Totoro body set) can be multiplied by a scale factor. For example, the '''minime''' and '''behemoth''' [[cheats]] set that factor to 0.25 or 1.8, and back to 1. The size can be used for specific purposes (mini-Strikers, Mutant Muro, giant Shinatama), or it can be used to add generic variety to Oni's characters, as a complement to "character variants" ([[ONCV]]).
:The floats at 0xC60 and 0xC64 define a range in which Oni can pick a random body size factor (if the two values are identical, then the body size factor is effectively fixed instead of random). Konoko, Shinatama (both regular and zombified), Griffin (both variants) and Muro all have a fixed body size of 1. Mini-Strikers have 0.5 and giant Shinatama has 7 (yes, [[seven]]).
:Everybody else (including Barabas, Mukade and Kerr) has a random body size within 5% of 1 (i.e., the floats at 0xC60 and 0xC64 are 0.95 and 1.05). Mutant Muro is a bit odd because his "minimum" body size 1.75 and the "maximum" is 1.74 (the difference is barely noticeable anyway). In the [[Anniversary Edition]], some characters have altered factors (e.g., [[Shinatama Too]]).
:The random value is different every time the [[ONCC]] is looked up (e.g., when a character is spawned or shapeshifted) and is not reproducible. Here is a simple script for {{C|6}} a.k.a. [[IGMD/tctf]] (remove all BSL files and leave only the one below):
func main
{
ai2_allpassive 1
ai2_spawn a_v3
ai2_spawn Lv_40
ai2_spawn lobby_victim05
chr_location 1 -1255 -1.5 50
chr_location 2 -1255 -1.5 60
chr_location 3 -1255 -1.5 70
chr_location 4 -1255 -1.5 80
ai2_lookatme
}
:This script lines up four "usual suspects" against a wall in the parking lot of the TCTF HQ. Load the level repeatedly and note how their heights vary.

{{OBD_File_Footer | type=ONCC | prev=OFGA | next=ONCP | name=Oni Character Class | family=Character}}

{{OBD}}

OBD:OFGA

2025-05-12T11:54:25Z

Mai X: ...

{{OBD_File_Header | type=OFGA | prev=OBOA | next=ONCC | name=Object Furn Geom Array | family=Level | align=center}}

[[Image:ofga_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | res_id |FF0000| 01 C5 02 00 | 709 | 00709-.OFGA }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr| 0x08 | char[16] |00FF00| AD DE | dead | padding }}
{{OBDtr| 0x18 | link |00FFFF| 00 00 00 00 |unused | link to an [[OBD:ENVP|ENVP]] file }}
{{OBDtr| 0x1C | uint32 |FF00FF| 05 00 00 00 | 5 | array size }}
{{OBDtrBK}}
{{OBDtr| 0x00 | uint32 |FFC8C8| 00 80 01 00 | 00 80 01 00 | same flags as used by [[OBD:AGQG|gunk quads]]; used at import time for geometry that needs to be baked into the environment }}
{{OBDtr| 0x04 | link |FFFFC8| 01 C6 02 00 | 710 | link to 00710-.[[M3GM]]}}
{{OBDtr| 0x08 | link |C8FFC8| 00 00 00 00 | 0 | link to an old [[OBD:OBLS|OBLS]] file, never used in Oni }}
|}

;Usage
:OFGA instances are mostly used by the level editing tool. In game they're rarely used, only to get the bounding box of the geometry.

{{OBD_File_Footer | type=OFGA | prev=OBOA | next=ONCC | name=Object Furn Geom Array | family=Level}}

{{OBD}}

OBD:OBOA

2025-05-12T11:51:06Z

Mai X: ...

{{OBD_File_Header | type=OBOA | prev=OBDC | next=OFGA | name=Starting Object Array | family=Level | align=center}}

[[image:oboa_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | res_id |FF0000| 01 55 02 00 | 597 | 00597-.OBOA }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr| 0x08 | char[22] |00FF00| AD DE | dead | padding }}
{{OBDtr| 0x1E | uint16 |00FFFF| 62 00 | 98 | array size }}
{{OBDtrBK| First array element (black outline): "setup" for a door or physical/animated object}}
{{OBDtr| 0x00 | link |FFC8C8| 01 56 02 00 | 598 | link to [[OBD:M3GA|00598-.M3GA]] - geometry (or a glued-together set of geometries) displayed for this object }}
{{OBDtr| 0x04 | link |FFFFC8| 00 00 00 00 | unused | link to [[OBD:OBAN|OBAN]] - animation played when the object is created; a different animation can be selected with env_setanim }}
{{OBDtr| 0x08 | link |C8FFC8| 00 00 00 00 | unused | link to [[OBD:ENVP|ENVP]] - particles attached to this object (e.g., vehicle headlights)}}
{{OBDtr| 0x0C | bitset32 |C8FFFF| 00 12 00 00 | in use, face collision | flags; the bits are as follows:
:'''0x02''' 00 00 00 - never used in Vanilla data ("is door"; set at runtime when creating a level's doors)
:'''0x04''' 00 00 00 - never used in Vanilla data ("ignore characters"; never used by the engine)
:'''0x08''' 00 00 00 - never used in Vanilla data ("force draw"; can be set at runtime with obj_force_draw)
:'''0x10''' 00 00 00 - never used in Vanilla data ("light source"; never used by the engine)
:'''0x40''' 00 00 00 - never used in Vanilla data ("delete me"; never used by the engine)
:'''0x80''' 00 00 00 - never used in Vanilla data ("notify collision"; set at runtime for a level's doors)
:0x00 '''01''' 00 00 - never used in Vanilla data ("invisible"; set at runtime with obj_show and obj_hide)
:0x00 '''02''' 00 00 - in use; if disabled, there is no object setup in this element at all (see "Empty array elements" below)
:0x00 '''04''' 00 00 - no collision; used for "blender" machine parts in manplant and for a piece of rope in Airport_III
:0x00 '''08''' 00 00 - never used in Vanilla data ("no gravity"; disables gravity, keeps other forces, if any)
:0x00 '''10''' 00 00 - face collision (actually uses a bounding box); overrides 0x0400 if both are present; used only for doors in Vanilla
:0x00 '''20''' 00 00 - never used in Vanilla data ("particles created"; runtime only)
:0x00 '''40''' 00 00 - never used in Vanilla data ("jello objects"; runtime only)
:0x00 '''80''' 00 00 - never used in Vanilla data ("flat lighting"; used in combination with obj_shade)
}}
{{OBDtr| 0x10 | uint32 |FFC8FF| 46 89 00 00 | 35142 | the index of the doorframe GQ; used only for doors (0 for other objects)}}
{{OBDtr| 0x14 | uint32 |FFC800| 01 00 00 00 | 1 | door ID; used only for doors (0 for other objects); for doors that work in pairs the IDs differ by 4096 (i.e. by the 0x1000 bit)}}
{{OBDtr| 0x18 | uint32 |C800C8| 00 00 00 00 | 0 | "physics level"; the following values are possible:
:0 - None; used for doors
:1 - Static; never used in Vanilla data
:2 - Linear; response to external forces and collision (if any); never used in Vanilla data
:3 - Animated; used for non-doors
:4 - "Newton"; response to external forces and collision (if any); never used in Vanilla data
}}
{{OBDtr| 0x1C | uint32 |C87C64| FF FF 00 00 | 65535 | script ID (for obj_create, env_setanim etc); doors use 65535 }}
{{OBDtr| 0x20 | vector |B0C3D4| 00 00 4F 43 1F 05 F6 42 98 7F CC C3 |207.0 123.010002 -408.996826 | object position }}
{{OBDtr| 0x2C | quaternion|E7CEA5| F2 04 35 3F 74 BC 82 B9 74 BC 82 B9 F3 04 35 3F | 0.707107 -0.000249 -0.000249 0.707107 | object rotation }}
{{OBDtr| 0x3C | float |FFDDDD| 00 00 80 3F | 1.0 | object scale }}
|- ALIGN=CENTER VALIGN=TOP
|0x40||matrix
|BGCOLOR="#64aaaa"|
{|cellspacing=1 style="white-space:nowrap;width:100%;"
|-
|FC FF 7F 3F || 00 00 00 00 || 8A E3 38 BA
|-
|8A E3 38 BA || 2E DE 4C 32 || FC FF 7F BF
|-
|C9 F5 13 2D || 00 00 80 3F || 2B DE 4C 32
|-
|00 00 4F 43 || 1F 05 F6 42 || 98 7F CC C3
|}
|
{|cellspacing=1 style="white-space:nowrap;width:100%"
|-
|0.999999 || 0.0 || -0.000705
|-
| -0.000705 || 0.0 || -0.999999
|-
|0.0 || 1.0 || 0.0
|-
|207.0 || 123.010002 || -408.996826
|}
|ALIGN=LEFT|debug origin matrix
{{OBDtr2|0x70 | char[64] |EBEBEB| object_door_1 | name of the object; informational only }}
{{OBDtr2|0xB0 | char[64] |8C8CCC| L3_Gunk.ENV | file name from which this object was created; informational only }}
|}

The primary use of this data is to display animated objects in the environment (cars, helis, fans etc.). "Physics" may also work but the implementation is buggy and incomplete: you may be able to add a object that can be pushed around but if you try to jump on it you fall. The two flavors "Linear" and "Newton" are equivalent (if there ever were differences between the two, they are gone now).

Position, rotation and scale are used only when the object is not animated, otherwise the origin matrix is used instead.

Objects are not automatically created when a level is loaded, they need to be created from scripts using the '''obj_create''' command. After that they can be controlled with other commands like '''obj_show''', '''obj_hide''', '''obj_kill''', '''obj_shade''', '''env_anim''' and '''env_setanim''' (also '''obj_force_draw''', '''env_anim_block''' and '''env_setanim_block''').

In some cases a level's geometry contains a static duplicate of the object's polygons, which is typically hidden (through "env_show objectScriptID 0") while the OBOA object is shown (and vice-versa).
----
;Flags
:Besides the trivial "in use" flag, only two are used in Vanilla game data: "no collision" (possibly useless, because collision is off by default anyway) and "face collision" (used for doors).
:Some of the other flags (e.g. "particles created") are reserved for runtime use, others can be specified in game data. Some intriguing ones, like "light source", are completely defunct.

----
;Empty array elements
:The last 32 elements of a level's OBOA are always empty (all data values are zero). Below is an overview table for Vanilla levels (OBOA array size vs. number of actual door/object setups).
{|border=1 cellspacing=0
!level#_Final
!1
!2
!3
!4
!6
!8
!9
!10
!11
!12
!13
!14
!18
!19
|-
!OBOA array size
|180
|69
|98
|69
|99
|146
|78
|78
|106
|50
|54
|116
|117
|100
|-
!Actual elements
|148
|37
|66
|37
|67
|114
|46
|46
|74
|18
|22
|84
|85
|68
|}
For a new level built from XML by OniSplit, there are also 32 empty elements at the end of the array. The purpose of these extra elements is not currently documented.

----
;M3GA use (single M3GM vs. actual sets of several M3GMs)
:The link at 0x00 in an object setup is to an M3GA, i.e., an array that can hold several M3GMs - which, in the OBOA context, behave as a single object (driven by the same animation or force - if any), as if glued together.
:In Vanilla game data, the only OBOA objects to have several M3GMs in their M3GA are doors with glass sections (this is needed because (a) an M3GM can have only one texture, and (b) door frames are required to have a fully opaque texture, or they will have an "inside-out" look because of the front-to-back rendering order). The only exception is door 45 in level6 (Airport Cargo Hangars), which has no transparent parts, and instead just links to the same M3GM twice.
:One would expect the M3GA feature to be used for large animated objects that consist of several meshes, e.g. the express elevator in Griffin's office (intro of level18) or the satellite dish in the final chapter - but no, these are set up as separate "objects", with one M3GM per M3GA, animated synchronously. This is in contrast to the named M3GA found in [[level0_Tools]], which ''are'' actually used to group several M3GMs together, into pieces of "furniture".

----
;Script IDs of grouped objects
:Objects animated synchronously (e.g. a vehicle and its wheels) are typically set up with a continuous range of script IDs: all related script commands, from '''obj_create''' to '''obj_shade''' to '''env_anim''', can operate both on single objects and on ''ranges'' of objects (e.g., '''obj_create 10 12''' creates objects 10 through 12).
:Contiguous objects can move as a rigid "whole", or there can be some relative motion within the group (e.g., wheels turning, doors opening, rotors tilting). This is because each object belongs to a separate OBOA element and thus has its own animation, assigned at creation or via script ID.
:The hierarchy of contiguous objects in the original scene (as modeled by the developers) is typically not known. It would make sense for wheels/doors to be "parented" to a vehicle's chassis, but at Oni level there is no parenting, i.e., both the chassis and the wheels/doors are animated in world space.
:The order of script IDs for contiguous groups of objects is not a reliable indicator of hierarchy. Thus, recurrent object sets (e.g., armored truck, motorcycle, Syndicate van) are not ordered consistently in all the levels where they appear:
:*Armored truck (level1, gunk IDs): cabin 201, trailer 202, wheel pairs 203 to 207 (front to back); no gunk IDs for doors (so they can't be hidden).
:*Armored truck (level1, OBOA IDs): cabin 207, trailer 206, wheel pairs 205, 203, 204, 201 and 202 (front to back); no animated door objects.
:*Armored truck (level19, gunk IDs before ramming): cabin 152, trailer 151, wheel pairs 157, 155, 156, 159 and 158 (front to back), doors 154 (left) and 153 (right).
:*Armored truck (level19, gunk IDs after ramming): cabin 252, trailer 251, wheel pairs 257, 255, 256, 259 and 258 (front to back), doors 254 (left) and 253 (right).
:*Armored truck (level19, OBOA IDs): cabin 52, trailer 51, wheel pairs 57, 55, 56, 59 and 58 (front to back), doors 54 (left) and 53 (right).
:*Motorcycle (level3, gunk IDs and OBOA IDs): bike 10, wheels 8 (front) and 9 (rear)
:*Motorcycle (level4, gunk IDs and OBOA IDs): bike 10, wheels 11 (front) and 12 (rear)
:*Motorcycle (level8, gunk IDs): bike 110, wheels 111 (front) and 112 (rear)
:*Motorcycle (level8, OBOA IDs): bike 10, wheels 11 (front) and 12 (rear)
:*BlackVan (level3 and level4, OBOA IDs): front/back 2, sides 3, top/bottom 4, wheel pairs 5 (front) and 6 (rear), doors 7
:*BlackVan (level8, gunk IDs): front/back 101, sides 103, top/bottom 104, wheel pairs 105 (front) and 106 (rear), doors 108 (left) and 107 (right)
:*BlackVan (level8, OBOA IDs): front/back 1, sides 3, top/bottom 4, wheel pairs 5 (front) and 6 (rear), doors 8 (left) and 7 (right)
:The bottom line is that there don't seem to be any rules for the order of script IDs in a group. Possibly the IDs were not auto-assigned during import and were specified more or less manually.

----
;Unused or missing object setups
:Some object setups are left over from early development, completely unused in the game. The most famous example is Konoko's clothes from Chapter 4 (level4_Final), but hidden doors at the Warehouse also fall into that category.
:Some object setups are completely missing from Oni, but can be inferred through eponymous OBAN instances (object animations). OBAN are also used for cameras and "env-boxed" character animation (gliding, elevator/motorcycle rides, etc), but camera and/or env-box animations are usually easy to tell apart from object motion.
:The most significant evidence of missing objects is in level2 a.k.a. Musashi Manufacturing Plant, with the following big set of "orphaned" OBANs:
:*solarpanel, solarbracket
:*scanner, scanring, scanlens, scanlens2
:*weldarm1, weldarm2, weldarm3, weldarm4, weldarm5
:All 11 animations have a common length of 2400 frames (= 40 seconds) and are located in one of the "engine rooms" where the current "blender" and "fan" OBANs are. It seems to correspond to an elaborate manufacturing sequence (welding) involving a "solar panel" mounted on a moving bracket, a robotic welding arm and a "scanner" analyzing the process
:level2 also features an unused OBANwoof (299 frames = 5 seconds long), located in the lobby, not clearly intended for a camera or a flying object, as well as a missing env-box for Shinatama.

{{OBD_File_Footer | type=OBOA | prev=OBDC | next=OFGA | name=Starting Object Array | family=Level}}

{{OBD}}

OBD:BINA/OBJC

2025-05-12T11:36:29Z

Mai X: ...

{{OBD BINA Header|prev=TMBD|type=OBJC|next=ONIE|name=Objects|onistuff=bina}}

==Introduction==
"OBJC" is short for "Objects", which refers to lists of files which are stored in the [[separate file]] when available (Windows demo, Mac) or in the [[raw file]] otherwise (Windows). OBJC is registered as a tag (and is also a sub-tag of [[BINA]]), but it serves as a wrapper for other tags. OBJCs are lists composed of a standard wrapper with a little header data and then elements of specific data types which have their own tags. Objects listed in OBJCs could be edited in-game by the developers using the GUI which was discovered by fans in the [[European Mac releases]] of Oni. Screenshots of the editing interface are shown on the pages of each type which the interface could edit.

==File description==
;Example file
:[[OBD:BINA/OBJC/PWRU|BINACJBOPowerUp]] from level3
;Offsets
:Offsets are given with respect to the start of the raw file's data part.

[[Image:Bin r pu.gif]]

{{table}}
{{OBDth}}
{{OBDtr|0x00|char[4]|FF0000|43 4A 42 4F|OBJC|tag}}
{{OBDtr|0x04|uint32 |FFFF00|18 02 00 00|536|size to end of object list from 0x08, in bytes}}
{{OBDtr|0x08|uint32 |00FF00|27 00 00 00|39|object format version}}
{{OBDtr|0x0C|uint32 |00FFFF|28 00 00 00|40|size of next object (black outline)}}
{{OBDtrBK|0x10 - 0x37 : first object (40 bytes)}}
{{OBDtr|0x38|uint32 |FFFFFF|28 00 00 00|40|size of next object}}
{{OBDtrBK|0x3C - ... : second object (40 bytes), etc.}}
|}
;General layout
:The list's header (first 16 bytes) and layout is common to all 16 OBJC types (see below).
:*The size of the whole list is announced at 0x04 (int32), followed by the list.
:*Unlike ONIE and TMBD (which are arrays), OBJC announces the size of every object (int32).
:*After the last object, the end of the list is signaled by a null next object size.

;Object header
:All objects start with the following header:

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FFC8C8| 52 52 57 50 | PWRU | object type }}
{{OBDtr| 0x04 | uint32 |FFFFC8| AC 1C 00 00 | 7340 | object ID }}
{{OBDtr| 0x08 | bitset32 |C8FFC8| 00 00 00 00 | 0x00 | object flags, only used at runtime in [[Tool mode]]}}
{{OBDtr| 0x0C | float |C8FFFF| E8 92 77 44 | 990.254 | x position }}
{{OBDtr| 0x10 | float |C8FFFF| 00 00 D8 41 | 27.000000 | y position }}
{{OBDtr| 0x14 | float |C8FFFF| 71 DD 98 43 | 305.73 | z position }}
{{OBDtr| 0x18 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the x axis in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the y axis in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z axis in degrees }}
|}

==OBJC types==
A given list can only hold objects of one type, which can be:
{|
|
{|{{OBDtable}}
|-bgcolor=#E9E9E9
!Type!!Long name!!File name
|-
|[[OBD:BINA/OBJC/CHAR|CHAR]]||Character||BINACJBO'''Character'''
|-
|[[OBD:BINA/OBJC/CMBT|CMBT]]||Combat profile||BINACJBO'''Combat'''
|-
|[[OBD:BINA/OBJC/CONS|CONS]]||Console||BINACJBO'''Console'''
|-
|[[OBD:BINA/OBJC/DOOR|DOOR]]||Door||BINACJBO'''Door'''
|-
|[[OBD:BINA/OBJC/FLAG|FLAG]]||Flag||BINACJBO'''Flag'''
|-
|[[OBD:BINA/OBJC/FURN|FURN]]||Furniture||BINACJBO'''Furniture'''
|-
|[[OBD:BINA/OBJC/MELE|MELE]]||Melee profile||BINACJBO'''Melee Profile'''
|-
|[[OBD:BINA/OBJC/NEUT|NEUT]]||Neutral behaviour||BINACJBO'''Neutral'''
|-
|[[OBD:BINA/OBJC/PART|PART]]||Particle||BINACJBO'''Particle'''
|-
|[[OBD:BINA/OBJC/PATR|PATR]]||Patrol path||BINACJBO'''Patrol_Path'''
|-
|[[OBD:BINA/OBJC/PWRU|PWRU]]||Powerup||BINACJBO'''PowerUp'''
|-
|[[OBD:BINA/OBJC/SNDG|SNDG]]||Sound Group||BINACJBO'''Sound'''
|-
|[[OBD:BINA/OBJC/TRGV|TRGV]]||Trigger Volume||BINACJBO'''Trigger_Volume'''
|-
|[[OBD:BINA/OBJC/TRIG|TRIG]]||Trigger||BINACJBO'''Trigger'''
|-
|[[OBD:BINA/OBJC/TURR|TURR]]||Turret||BINACJBO'''Turret'''
|-
|[[OBD:BINA/OBJC/WEAP|WEAP]]||Weapon||BINACJBO'''Weapon'''
|}
|}

{{OBD BINA Footer|prev=TMBD|type=OBJC|next=ONIE|name=Objects|family=General}}

{{OBD}}

OBD:OBAN

2025-05-12T11:33:31Z

Mai X: ...

{{OBD_File_Header | type=OBAN | prev=Mtrl | next=OBDC | name=Object Animation | family=General | desc='''OBAN'''s are arrays for storing keyframes in an object or camera animation, as well as basic info like whether the animation loops, and how it does so. | align=center}}

[[Image:oban_a.gif]]

{{Table}}
{{OBD Table Header}}
{{OBDtr|0x00|res_id|FF0000|01 '''86 00 00'''|134|00134-Blackvan_FB.OBAN}}
{{OBDtr|0x04|lev_id|FFFF00|01 00 00 '''06'''|3 |level 3}}
{{OBDtr|0x08|char[12]|00FF00|00 00 00 00 |0 |padding }}
{{OBDtr|0x14|uint32 |00FF00|00 00 00 00 |0 |flags; used values:
:0x'''01''' 00 00 00 - loop animation normally
:0x'''02''' 00 00 00 - loop animation back to back
:0x'''04''' 00 00 00 - select start frame randomly
:0x'''08''' 00 00 00 - autostart animation (after an animated object is created)
:0x'''10''' 00 00 00 - local animation; this animation does not contain world positioning information, the object position is determined by the origin matrix in [[OBOA]]; local animations also use a Z-up coordinate system
}}
|- ALIGN=CENTER VALIGN=TOP
|0x18||matrix||
{|border=1 cellspacing=0 style="white-space:nowrap"
|-BGCOLOR="#FFC8C8"
|C2 F5 E8 3F||AB D7 AA B3||EC 89 13 35
|-BGCOLOR="#FFFFC8"
|EC 89 13 35||ED 89 13 B4||C2 F5 E8 BF
|-BGCOLOR="#C8FFC8"
|B1 D7 AA 33||C2 F5 E8 3F||EB 89 13 B4
|-BGCOLOR="#C8FFFF"
|6B 9A 94 44||97 FD 5B C2||5D 06 DA C2
|}
|
{|border=1 cellspacing=0 style="white-space:nowrap"
|1.819999||-7.955471e-8||5.496247e-7
|-
|5.496247e-7||-1.374061e-7||-1.819999
|-
|7.955475e-8||1.819999||-1.374061e-7
|-
|1188.825561||-54.997646||-109.012428
|}
|ALIGN=LEFT|initial position transform matrix
|- ALIGN=CENTER VALIGN=TOP
|0x48||matrix||
{|border=1 cellspacing=0 style="white-space:nowrap"
|-BGCOLOR="#FFC8FF"
|C2 F5 E8 3F||00 00 00 00||00 00 00 00
|-BGCOLOR="#FFC800"
|00 00 00 00||C2 F5 E8 3F||00 00 00 00
|-BGCOLOR="#C800C8"
|00 00 00 00||00 00 00 00||C2 F5 E8 3F
|-BGCOLOR="#C87C64"
|00 00 00 00||00 00 00 00||00 00 00 00
|}
|
{|border=1 cellspacing=0 style="white-space:nowrap"
|1.819999||0.0||0.0
|-
|0.0||1.819999||0.0
|-
|0.0||0.0||1.819999
|-
|0.0||0.0||0.0
|}
| ALIGN=LEFT | fixed transform matrix
{{OBDtr|0x78|uint16|B0C3D4|50 00|80 | ticks per frame; does not work}}
{{OBDtr|0x7A|uint16|E7CEA5|F5 01|501 | animation length in frames}}
{{OBDtr|0x7C|uint16|FFDDDD|00 00|0 | stop frame for the first "half" of the animation; used by door animations to distinguish between open and close sequences }}
{{OBDtr|0x7E|uint16|64AAAA|65 00|101 | number of keyframes}}
{{OBDtrBK|First keyframe (black outline)}}
|- ALIGN=CENTER VALIGN=TOP
|0x00||quaternion||
{|border=1 cellspacing=0 style="white-space:nowrap"
|-BGCOLOR="#EBEBEB"
| F4 04 35 BF||6A 19 C4 B3||CE 3C 03 B4||F3 04 35 BF
|}
|
{|border=1 cellspacing=0 style="white-space:nowrap"
| -0.7071068|| -9.131584e-8|| -1.222244e-7|| -0.7071067
|}
|ALIGN=LEFT|object rotation
|- ALIGN=CENTER VALIGN=TOP
|0x10||vector||
{|border=1 cellspacing=0 style="white-space:nowrap"
|-BGCOLOR="#8C8CCC"
|C2 F5 E8 3F||AB D7 AA B3||EC 89 13 35
|}
|
{|border=1 cellspacing=0 style="white-space:nowrap"
|1188.825561||-54.997646||-109.012428
|}
|ALIGN=LEFT|object position
{{OBDtr|0x1C|uint32|FF00C8|00 00 00 00 |0 |current frame}}
|}

Object animations are used to animate [[OBD:OBOA|objects]] (doors included), [[OBD:TRIG|triggers]], cameras and characters. Object animations may be referenced from OBOA but they can also be set using env_setanim script command. Camera animations are never referenced from data files, they're started from script using cm_anim/cm_interpolate. Because of this the only way to tell if an animation is intended for camera or for an object is to look at the level scripts.

Characters can have an object animation applied to them by using chr_envanim/chr_envanim_block. The object animation controls the movement of the character and it's normally used together with a [[OBD:TRAM|Totoro animation]] that has the 'real world' flag set. This can be used to make the character appear attached to another animated object, for example the motorcycle in the opening of Lab level.

;Transform matrices
:Like all matrices in Oni, they are composed of 3 vectors defining rotation/scaling/shearing and a 4th vector defining a translation.
:In the above table the 4 vectors are presented as rows ([[wp:Row-_and_column-major_order|Direct 3D convention]]), although OpenGL and Oni use them as columns.
:[[wp:Transformation_matrix#Affine_transformations|Affine transformations]] use a 4x4 matrix with 4 extra coefficients (in the presentation above, one would add one column on the right):
::three [[wp:3D_projection|projection transform]] coefficients (all of them are zero here); one final coefficient (always 1.0 for an affine transform matrix).
:Alternatively, one can think of the 3x4 matrix as a 3x3 rotation/scaling matrix and a position vector
::*Let X=(x, y, z) be the position of a vertex in the M3GM
::*Let M=(m11, m21, m31; m12, m22, m32; m13, m23, m33) be the 3x3 matrix
::*Let R=(m14, m24, m34) be the translation vector
::Then the absolute position of the vertex in the 3D world will be: X M + R
::(left multiplication is used because of the row-major notation above)
;Initial transform matrix
:It is used to position the object in the environment before the animation is played, it coresponds to the first animation frame.
:When the animation is played, they use the fixed transform matrix and a quaternion.
;Fixed transform matrix
:This transformation is applied before the quaternion+position transform at every keyframe.
:The only transform that can't be handled by the quaternion+position is scaling/mirroring.
:Thus, the fixed transform is a scaling matrix most of the time (no rotation or translation).
:In the above example, the fixed transform scales the van up by 1.82 (along all three axes).
;Quaternions
:Those are used in Oni whenever interpolation of 3D rotation is involved (e.g., [[OBD_talk:TRAM/raw0x34#Quaternions|TRAM rotation]])
:In this case, rotation at intermediate frames is interpolated from the keyframe quaternions.

----
----
{{OBD_File_Footer | type=OBAN | prev=Mtrl | next=OBDC | name=Object Animation | family=General | align=center}}

{{OBD}}

OBD:Mtrl

2025-05-12T11:24:42Z

Mai X: Removing DEAD part... It is NOT a part of the type...

{{OBD_File_Header | type=Mtrl | prev=M3GM | next=OBAN | name=Material | family=General | align=center}}

[[image:mtrl_all.gif]]

{{Table}}
{{OBDth}}
{{OBDtr|0x00|res_id |FF0000|01 E5 0F 00|4069 |04069-Armor.Mtrl}}
{{OBDtr|0x04|lev_id |FFFF00|01 00 00 00|0 |level 0}}
{{OBDtr|0x08|uint16 |FFC8C8|FF FF |-1 |ID; ignored; runtime only}}
{{OBDtr|0x0A|uint16 |FFFFC8|AD DE |dead |depth; unused; runtime only}}
{{OBDtr| ---- |bool |FFFFC8|AD |dead |breakable; unused; runtime only}}
{{OBDtr| ---- |char[3] |FFFFC8|DE AD DE |dead |padding}}
{{OBDtr|0x10|res_id |C8FFC8|01 E6 0F 00|4070 |link to 04070-Character.Mtrl (parent material) }}
|}

;Mtrl usage
:The materials are looked up from [[OBD:BINA/ONIE|Impact_Effects.BINA]] and [[OBD:BINA/TMBD|Texture_Materials.BINA]] as well as from [[OBD:CBPM|CBPM]] and maybe a few other places ^^

;Mtrl tree
*Default [5]
**Character [4]
**#Armor [0]
**#Cloth [0]
**#Flesh [0]
**#Shield [1]
**#*Super_Shield [0]
**Glass [4]
**#Clear_Glass [0]
**#Small_Glass [0]
**#Tinted_Glass [0]
**#Unbreak_Glass [0]
**Liquid [0]
**Mesh [0]
**Solid [4]
**#Carpet [0]
**#Hard [3]
**#*Metal [3]
**#**Heavy_Metal
**#**Light_Metal
**#**Resonant_Metal
**#*Stone [2]
**#**Asphalt
**#**Concrete
**#*Stucco [0]
**#Loose_Ground [2]
**#*Dirt [0]
**#*Snow [0]
**#Plastic [0]
**#Soft [0]

{{OBD_File_Footer | type=Mtrl | prev=M3GM | next=OBAN | name=Material | family=General | align=center}}

{{OBD}}

OBD:M3GM

2025-05-12T11:17:49Z

Mai X: ...

{{OBD_File_Header | type=M3GM | prev=M3GA | next=Mtrl | name=Geometry | family=General | align=center}}

[[image:m3gm_all.gif]]

{{Table}}
{{OBDth}}
{{OBDtr|0x00|res_id |FF0000|01 D7 00 00|215 | 00215-door_1_0.M3GM}}
{{OBDtr|0x04|lev_id |FFFF00|01 00 00 06|3 | level 3}}
{{OBDtr|0x08|uint32 |FFC8C8|00 00 00 00|0 | geometry flags; runtime only }}
{{OBDtr|0x0C|link |FFFFC8|01 DA 00 00|218 | link to [[OBD:PNTA|00218-.PNTA]] (vertex XYZs) }}
{{OBDtr|0x10|link |FFFFC8|01 F7 00 00|247 | link to [[OBD:VCRA|00247-.VCRA]] (vertex normals) }}
{{OBDtr|0x14|link |FFFFC8|01 F0 00 00|240 | link to 00240-.[[OBD:VCRA|VCRA]] (face normals) }}
{{OBDtr|0x18|link |FFFFC8|01 ED 00 00|237 | link to [[OBD:TXCA|00237-.TXCA]] (vertex UVs) }}
{{OBDtr|0x1C|link |FFFFC8|01 0C 01 00|268 | link to [[OBD:IDXA_M3GM_1|00268-.IDXA]] (triangle strips) }}
{{OBDtr|0x20|link |FFFFC8|01 11 01 00|273 | link to [[OBD:IDXA_M3GM_2|00273-.IDXA]] (face grouping by normal) }}
{{OBDtr|0x24|link |FFFFC8|01 D8 00 00|216 | link to 00216-.[[OBD:TXMP|TXMP]] (texture) }}
{{OBDtr|0x28|link |C8FFC8|00 00 00 00|unused| obsolete GMAN (geometry animation) link; never used in Oni}}
|}

;Vertices
:XYZ and UV coordinates are stored in parallel (same number of entries in PNTA and TXCA).
;Vertex normals
:The first VCRA stores the normals for every vertex (same entries as in PNTA and TXCA).
:Vertex normals are used by Gouraud shading (directional lighting).
;Face normals
:The second VCRA stores the normals for every face (groups defined by the second IDXA).
:Face normals are used for backface culling.
;Triangle strips
:The first IDXA lists the triangles as strips. The IDs are the ones in PNTA and IDXA.
:The start of a new strip is signaled by a high bit in the ID of its first vertex.
:Strips are more optimal for rendering, they are generated when authoring an M3GM.
;Face groupings
:The second IDXA groups the triangles into faces (oriented by the second VCRA).
;Geometry animation
:Geometry animation worked in a way similar to texture animation, by picking M3GMs from an array (GMAN) and displaying them at a specified frame rate, optionally with randomization.

----
;PS2 implementation
:PS2 M3GMs have the same data size as PC and Mac ones (0x24 bytes of actual data, 0x2C if counting the instance and level IDs), but the layout is different.
:*Face normals aren't stored at all, and vertex normals aren't stored as VCRA either, therefore both VCRA and the second IDXA are simply missing, which frees up 12 bytes worth of space for data fields unique to the PS2 format.
:*8 of the 12 freed-up bytes are used by explicitly storing the number of vertices (i.e., the array size common to PNTA and TXCA) and the number of faces (same count as the 2nd VCRA on PC and Mac), as two int32's.
:*The other 4 bytes are used to reference the compressed storage of vertex normals in the.raw file. This storage is very compact/lossy, using only 1 byte per normal (instead of 12 bytes per normal in the case of VCRA storage).
:An an example, consider M3GMaxes of level0_Final.
{{Table}}
{{OBDth}}
{{OBDtr|0x00|res_id |FF0000|01 63 00 00|99 | 00099-axes.M3GM}}
{{OBDtr|0x04|lev_id |FFFF00|01 00 00 00|0 | level 0}}
{{OBDtr|0x08|uint32 |FFC8C8|00 00 00 00|0 | runtime geometry flags (supposedly the same as for PC and Mac) }}
{{OBDtr|0x0C|uint32 |FFC8C8|60 00 00 00|96 | number of faces (same as in second VCRA on PC and Mac) }}
{{OBDtr|0x10|link |FFFFC8|01 64 00 00|100 | link to [[OBD:PNTA|00100-.PNTA]] (vertex XYZs) }}
{{OBDtr|0x14|link |FFFFC8|01 65 00 00|101 | link to [[OBD:TXCA|00101-.TXCA]] (vertex UVs) }}
{{OBDtr|0x18|link |FFFFC8|01 66 00 00|102 | link to [[OBD:IDXA_M3GM_1|00102-.IDXA]] (triangle strips) }}
{{OBDtr|0x1C|uint32 |FFC8C8|6C 00 00 00|108 | number of vertices (same as in PNTA and TXCA); also size of .raw part in bytes }}
{{OBDtr|0x20|offset |FFFFC8|A0 8E 01 00| 0x00018EA0 | offset into the .raw file where the the 108 compressed vertex normals are stored:
'''2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D F8 F8 C2 55'''
'''40 40 10 D4 D4 09 C2 5F 6B 6B 6B 6B 6B 6B 6B 6B'''
'''6B 82 82 D9 16 E3 E3 00 EB EB 6D 6D 6D 6D 6D 6D'''
'''6D 6D 6D 6D AB AB EB 80 52 FC 95 30 30 EA EA EA'''
'''EA EA A7 A7 24 EA EA EA EA 24 02 02 02 A7 A7 A7'''
'''A7 EF EA EA EA EA 02 02 02 02 24 24 24 24 F8 2D'''
'''2D 2D 2D A7 A7 A7 A7 EA EA EA EA 16'''
See below for a overview of the compression/decompression rule, i.e., how the 256 values of a compressed normal are mapped to the unit sphere.
}}
{{OBDtr|0x24|link |FFFFC8|01 67 00 00|103 | texture link (to the empty 00103-_AXIS.[[OBD:TXMP|TXMP]]; the actually relevant 00104-_axis.TXMP is orphaned) }}
{{OBDtr|0x28|link |C8FFC8|00 00 00 00|unused| supposedly the same GMAN link (geometry animation) as for PC and Mac }}
|}
;OniBrowser being able to load PS2 M3GMs (a mystery of the modern times)
:Somehow OniBrowser is able to display M3GMs from PS2 instance files (except those with textures), even though all the links (PNТA, TXCA, IDXA) are in the wrong positions. Apparently, in the case of M3GM, OniBrowser reads in all the fields past 0x0C as a bunch of non-typed instance links, then identifies their types and populates the PNTA, VCRA, TXCA and IDXA references with the first encountered instance of the matching type.
;Compressed vertex normals
[[Image:Four-fold tetrahedron.jpg|right|160px]]
:It is somewhat uncommon to pack a normal vector into a single byte, but it turns out that there is a relatively straightforward way to subdivide the unit sphere into 256 sectors. One starts by splitting the sphere into four large quadrants (based on tetrahedral symmetry), and then each of the big "triangles" is subdivided into 4, then 16, then 64 smaller triangles, like the picture to the right. There is some distortion near the four poles, but other than that it's a valid way to pack normals if space is an issue (if packing to 2 bytes or more, then one would typically work in plain spherical coordinates instead, i.e. azimuth and elevation).
:There isn't much of a point in giving a detailed description of the mapping here, but the basic idea would be to use the lowest 64 values for the first quadrant, the next 64 values for the second quadrant, etc. In actuality the PS2 implementation uses 63 for the first quadrant, 62 for the second, 63 for the third, and 68 for the last - for whatever reason. Within a quadrant the distribution isn't entirely regular, either. To be documented later if at all.
;"Bad door lighting"
:When looking at the .raw part of the M3GM for some doors (level geometry), a striking observation is that there are only three distinct normal values (0xDE, 0x6A and 0x82), rather than the 6 normals that you'd expect for an axis-aligned box. Apparently half of those are bad, inward-pointing normals that no one ever bothered fixing. The regular VCRA normals for the same doors (on PC and Mac) are messed up in exactly the same way. Possibly this is related to the BSL variable '''door_pop_lighting''' ("uses bad door lighting").

{{OBD_File_Footer | type=M3GM | prev=M3GA | next=Mtrl | name=Geometry | family=General | align=center}}

{{OBD}}

OBD:M3GM

2025-05-12T11:16:56Z

Mai X: ...

{{OBD_File_Header | type=M3GM | prev=M3GA | next=Mtrl | name=Geometry | family=General | align=center}}

[[image:m3gm_all.gif]]

{{Table}}
{{OBDth}}
{{OBDtr|0x00|res_id |FF0000|01 D7 00 00|215 | 00215-door_1_0.M3GM}}
{{OBDtr|0x04|lev_id |FFFF00|01 00 00 06|3 | level 3}}
{{OBDtr|0x08|uint32 |FFC8C8|00 00 00 00|0 | geometry flags; runtime only }}
{{OBDtr|0x0C|link |FFFFC8|01 DA 00 00|218 | link to [[OBD:PNTA|00218-.PNTA]] (vertex XYZs) }}
{{OBDtr|0x10|link |FFFFC8|01 F7 00 00|247 | link to [[OBD:VCRA|00247-.VCRA]] (vertex normals) }}
{{OBDtr|0x14|link |FFFFC8|01 F0 00 00|240 | link to 00240-.[[OBD:VCRA|VCRA]] (face normals) }}
{{OBDtr|0x18|link |FFFFC8|01 ED 00 00|237 | link to [[OBD:TXCA|00237-.TXCA]] (vertex UVs) }}
{{OBDtr|0x1C|link |FFFFC8|01 0C 01 00|268 | link to [[OBD:IDXA_M3GM_1|00268-.IDXA]] (triangle strips) }}
{{OBDtr|0x20|link |FFFFC8|01 11 01 00|273 | link to [[OBD:IDXA_M3GM_2|00273-.IDXA]] (face grouping by normal) }}
{{OBDtr|0x24|link |FFFFC8|01 D8 00 00|216 | link to 00216-.[[OBD:TXMP|TXMP]] (texture) }}
{{OBDtr|0x28|link |C8FFC8|00 00 00 00|unused| obsolete GMAN (geometry animation) link; never used in Oni}}
|}

;Vertices
:XYZ and UV coordinates are stored in parallel (same number of entries in PNTA and TXCA).
;Vertex normals
:The first VCRA stores the normals for every vertex (same entries as in PNTA and TXCA).
:Vertex normals are used by Gouraud shading (directional lighting).
;Face normals
:The second VCRA stores the normals for every face (groups defined by the second IDXA).
:Face normals are used for backface culling.
;Triangle strips
:The first IDXA lists the triangles as strips. The IDs are the ones in PNTA and IDXA.
:The start of a new strip is signaled by a high bit in the ID of its first vertex.
:Strips are more optimal for rendering, they are generated when authoring an M3GM.
;Face groupings
:The second IDXA groups the triangles into faces (oriented by the second VCRA).
;Geometry animation
:Geometry animation worked in a way similar to texture animation, by picking M3GMs from an array (GMAN) and displaying them at a specified frame rate, optionally with randomization.

----
;PS2 implementation
:PS2 M3GMs have the same data size as PC and Mac ones (0x24 bytes of actual data, 0x2C if counting the instance and level IDs), but the layout is different.
:*Face normals aren't stored at all, and vertex normals aren't stored as VCRA either, therefore both VCRA and the second IDXA are simply missing, which frees up 12 bytes worth of space for data fields unique to the PS2 format.
:*8 of the 12 freed-up bytes are used by explicitly storing the number of vertices (i.e., the array size common to PNTA and TXCA) and the number of faces (same count as the 2nd VCRA on PC and Mac), as two int32's.
:*The other 4 bytes are used to reference the compressed storage of vertex normals in the.raw file. This storage is very compact/lossy, using only 1 byte per normal (instead of 12 bytes per normal in the case of VCRA storage).
:An an example, consider M3GMaxes of level0_Final.
{{Table}}
{{OBDth}}
{{OBDtr|0x00|res_id |FF0000|01 63 00 00|99 | 00099-axes.M3GM}}
{{OBDtr|0x04|lev_id |FFFF00|01 00 00 00|0 | level 0}}
{{OBDtr|0x08|int32 |FFC8C8|00 00 00 00|0 | runtime geometry flags (supposedly the same as for PC and Mac) }}
{{OBDtr|0x0C|int32 |FFC8C8|60 00 00 00|96 | number of faces (same as in second VCRA on PC and Mac) }}
{{OBDtr|0x10|int32 |FFFFC8|01 64 00 00|100 | link to [[OBD:PNTA|00100-.PNTA]] (vertex XYZs) }}
{{OBDtr|0x14|link |FFFFC8|01 65 00 00|101 | link to [[OBD:TXCA|00101-.TXCA]] (vertex UVs) }}
{{OBDtr|0x18|link |FFFFC8|01 66 00 00|102 | link to [[OBD:IDXA_M3GM_1|00102-.IDXA]] (triangle strips) }}
{{OBDtr|0x1C|int32 |FFC8C8|6C 00 00 00|108 | number of vertices (same as in PNTA and TXCA); also size of .raw part in bytes }}
{{OBDtr|0x20|offset |FFFFC8|A0 8E 01 00| 0x00018EA0 | offset into the .raw file where the the 108 compressed vertex normals are stored:
'''2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D F8 F8 C2 55'''
'''40 40 10 D4 D4 09 C2 5F 6B 6B 6B 6B 6B 6B 6B 6B'''
'''6B 82 82 D9 16 E3 E3 00 EB EB 6D 6D 6D 6D 6D 6D'''
'''6D 6D 6D 6D AB AB EB 80 52 FC 95 30 30 EA EA EA'''
'''EA EA A7 A7 24 EA EA EA EA 24 02 02 02 A7 A7 A7'''
'''A7 EF EA EA EA EA 02 02 02 02 24 24 24 24 F8 2D'''
'''2D 2D 2D A7 A7 A7 A7 EA EA EA EA 16'''
See below for a overview of the compression/decompression rule, i.e., how the 256 values of a compressed normal are mapped to the unit sphere.
}}
{{OBDtr|0x24|link |FFFFC8|01 67 00 00|103 | texture link (to the empty 00103-_AXIS.[[OBD:TXMP|TXMP]]; the actually relevant 00104-_axis.TXMP is orphaned) }}
{{OBDtr|0x28|link |C8FFC8|00 00 00 00|unused| supposedly the same GMAN link (geometry animation) as for PC and Mac }}
|}
;OniBrowser being able to load PS2 M3GMs (a mystery of the modern times)
:Somehow OniBrowser is able to display M3GMs from PS2 instance files (except those with textures), even though all the links (PNТA, TXCA, IDXA) are in the wrong positions. Apparently, in the case of M3GM, OniBrowser reads in all the fields past 0x0C as a bunch of non-typed instance links, then identifies their types and populates the PNTA, VCRA, TXCA and IDXA references with the first encountered instance of the matching type.
;Compressed vertex normals
[[Image:Four-fold tetrahedron.jpg|right|160px]]
:It is somewhat uncommon to pack a normal vector into a single byte, but it turns out that there is a relatively straightforward way to subdivide the unit sphere into 256 sectors. One starts by splitting the sphere into four large quadrants (based on tetrahedral symmetry), and then each of the big "triangles" is subdivided into 4, then 16, then 64 smaller triangles, like the picture to the right. There is some distortion near the four poles, but other than that it's a valid way to pack normals if space is an issue (if packing to 2 bytes or more, then one would typically work in plain spherical coordinates instead, i.e. azimuth and elevation).
:There isn't much of a point in giving a detailed description of the mapping here, but the basic idea would be to use the lowest 64 values for the first quadrant, the next 64 values for the second quadrant, etc. In actuality the PS2 implementation uses 63 for the first quadrant, 62 for the second, 63 for the third, and 68 for the last - for whatever reason. Within a quadrant the distribution isn't entirely regular, either. To be documented later if at all.
;"Bad door lighting"
:When looking at the .raw part of the M3GM for some doors (level geometry), a striking observation is that there are only three distinct normal values (0xDE, 0x6A and 0x82), rather than the 6 normals that you'd expect for an axis-aligned box. Apparently half of those are bad, inward-pointing normals that no one ever bothered fixing. The regular VCRA normals for the same doors (on PC and Mac) are messed up in exactly the same way. Possibly this is related to the BSL variable '''door_pop_lighting''' ("uses bad door lighting").

{{OBD_File_Footer | type=M3GM | prev=M3GA | next=Mtrl | name=Geometry | family=General | align=center}}

{{OBD}}

OBD:M3GM

2025-05-12T11:14:29Z

Mai X: Removing DEAD part... It is NOT a part of the type...

{{OBD_File_Header | type=M3GM | prev=M3GA | next=Mtrl | name=Geometry | family=General | align=center}}

[[image:m3gm_all.gif]]

{{Table}}
{{OBDth}}
{{OBDtr|0x00|res_id |FF0000|01 D7 00 00|215 | 00215-door_1_0.M3GM}}
{{OBDtr|0x04|lev_id |FFFF00|01 00 00 06|3 | level 3}}
{{OBDtr|0x08|uint32 |FFC8C8|00 00 00 00|0 | geometry flags; runtime only }}
{{OBDtr|0x0C|link |FFFFC8|01 DA 00 00|218 | link to [[OBD:PNTA|00218-.PNTA]] (vertex XYZs) }}
{{OBDtr|0x10|link |FFFFC8|01 F7 00 00|247 | link to [[OBD:VCRA|00247-.VCRA]] (vertex normals) }}
{{OBDtr|0x14|link |FFFFC8|01 F0 00 00|240 | link to 00240-.[[OBD:VCRA|VCRA]] (face normals) }}
{{OBDtr|0x18|link |FFFFC8|01 ED 00 00|237 | link to [[OBD:TXCA|00237-.TXCA]] (vertex UVs) }}
{{OBDtr|0x1C|link |FFFFC8|01 0C 01 00|268 | link to [[OBD:IDXA_M3GM_1|00268-.IDXA]] (triangle strips) }}
{{OBDtr|0x20|link |FFFFC8|01 11 01 00|273 | link to [[OBD:IDXA_M3GM_2|00273-.IDXA]] (face grouping by normal) }}
{{OBDtr|0x24|link |FFFFC8|01 D8 00 00|216 | link to 00216-.[[OBD:TXMP|TXMP]] (texture) }}
{{OBDtr|0x28|link |C8FFC8|00 00 00 00|unused| obsolete GMAN (geometry animation) link; never used in Oni}}
|}

;Vertices
:XYZ and UV coordinates are stored in parallel (same number of entries in PNTA and TXCA).
;Vertex normals
:The first VCRA stores the normals for every vertex (same entries as in PNTA and TXCA).
:Vertex normals are used by Gouraud shading (directional lighting).
;Face normals
:The second VCRA stores the normals for every face (groups defined by the second IDXA).
:Face normals are used for backface culling.
;Triangle strips
:The first IDXA lists the triangles as strips. The IDs are the ones in PNTA and IDXA.
:The start of a new strip is signaled by a high bit in the ID of its first vertex.
:Strips are more optimal for rendering, they are generated when authoring an M3GM.
;Face groupings
:The second IDXA groups the triangles into faces (oriented by the second VCRA).
;Geometry animation
:Geometry animation worked in a way similar to texture animation, by picking M3GMs from an array (GMAN) and displaying them at a specified frame rate, optionally with randomization.

----
;PS2 implementation
:PS2 M3GMs have the same data size as PC and Mac ones (0x24 bytes of actual data, 0x2C if counting the instance and level IDs), but the layout is different.
:*Face normals aren't stored at all, and vertex normals aren't stored as VCRA either, therefore both VCRA and the second IDXA are simply missing, which frees up 12 bytes worth of space for data fields unique to the PS2 format.
:*8 of the 12 freed-up bytes are used by explicitly storing the number of vertices (i.e., the array size common to PNTA and TXCA) and the number of faces (same count as the 2nd VCRA on PC and Mac), as two int32's.
:*The other 4 bytes are used to reference the compressed storage of vertex normals in the.raw file. This storage is very compact/lossy, using only 1 byte per normal (instead of 12 bytes per normal in the case of VCRA storage).
:An an example, consider M3GMaxes of level0_Final.
{{Table}}
{{OBDth}}
{{OBDtr|0x00|res_id |FF0000|01 63 00 00|99 | 00099-axes.M3GM}}
{{OBDtr|0x04|lev_id |FFFF00|01 00 00 00|0 | level 0}}
{{OBDtr|0x08|int32 |FFC8C8|00 00 00 00|0 | runtime geometry flags (supposedly the same as for PC and Mac) }}
{{OBDtr|0x0C|int32 |FFC8C8|60 00 00 00|96 | number of faces (same as in second VCRA on PC and Mac) }}
{{OBDtr|0x10|int32 |FFFFC8|01 64 00 00|100 | link to [[OBD:PNTA|00100-.PNTA]] (vertex XYZs) }}
{{OBDtr|0x14|link |FFFFC8|01 65 00 00|101 | link to [[OBD:TXCA|00101-.TXCA]] (vertex UVs) }}
{{OBDtr|0x18|link |FFFFC8|01 66 00 00|102 | link to [[OBD:IDXA_M3GM_1|00102-.IDXA]] (triangle strips) }}
{{OBDtr|0x1C|int32 |FFC8C8|6C 00 00 00|108 | number of vertices (same as in PNTA and TXCA); also size of .raw part in bytes }}
{{OBDtr|0x20|offset |FFFFC8|A0 8E 01 00| 0x00018EA0 | offset into the .raw file where the the 108 compressed vertex normals are stored:
'''2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D F8 F8 C2 55'''
'''40 40 10 D4 D4 09 C2 5F 6B 6B 6B 6B 6B 6B 6B 6B'''
'''6B 82 82 D9 16 E3 E3 00 EB EB 6D 6D 6D 6D 6D 6D'''
'''6D 6D 6D 6D AB AB EB 80 52 FC 95 30 30 EA EA EA'''
'''EA EA A7 A7 24 EA EA EA EA 24 02 02 02 A7 A7 A7'''
'''A7 EF EA EA EA EA 02 02 02 02 24 24 24 24 F8 2D'''
'''2D 2D 2D A7 A7 A7 A7 EA EA EA EA 16'''
See below for a overview of the compression/decompression rule, i.e., how the 256 values of a compressed normal are mapped to the unit sphere.
}}
{{OBDtr|0x24|link |FFFFC8|01 67 00 00|103 | texture link (to the empty 00103-_AXIS.[[OBD:TXMP|TXMP]]; the actually relevant 00104-_axis.TXMP is orphaned) }}
{{OBDtr|0x28|link |C8FFC8|00 00 00 00|unused| supposedly the same GMAN link (geometry animation) as for PC and Mac }}
{{OBDtr|0x2C|char[20]|C8FFFF|AD DE |dead | unused}}
|}
;OniBrowser being able to load PS2 M3GMs (a mystery of the modern times)
:Somehow OniBrowser is able to display M3GMs from PS2 instance files (except those with textures), even though all the links (PNТA, TXCA, IDXA) are in the wrong positions. Apparently, in the case of M3GM, OniBrowser reads in all the fields past 0x0C as a bunch of non-typed instance links, then identifies their types and populates the PNTA, VCRA, TXCA and IDXA references with the first encountered instance of the matching type.
;Compressed vertex normals
[[Image:Four-fold tetrahedron.jpg|right|160px]]
:It is somewhat uncommon to pack a normal vector into a single byte, but it turns out that there is a relatively straightforward way to subdivide the unit sphere into 256 sectors. One starts by splitting the sphere into four large quadrants (based on tetrahedral symmetry), and then each of the big "triangles" is subdivided into 4, then 16, then 64 smaller triangles, like the picture to the right. There is some distortion near the four poles, but other than that it's a valid way to pack normals if space is an issue (if packing to 2 bytes or more, then one would typically work in plain spherical coordinates instead, i.e. azimuth and elevation).
:There isn't much of a point in giving a detailed description of the mapping here, but the basic idea would be to use the lowest 64 values for the first quadrant, the next 64 values for the second quadrant, etc. In actuality the PS2 implementation uses 63 for the first quadrant, 62 for the second, 63 for the third, and 68 for the last - for whatever reason. Within a quadrant the distribution isn't entirely regular, either. To be documented later if at all.
;"Bad door lighting"
:When looking at the .raw part of the M3GM for some doors (level geometry), a striking observation is that there are only three distinct normal values (0xDE, 0x6A and 0x82), rather than the 6 normals that you'd expect for an axis-aligned box. Apparently half of those are bad, inward-pointing normals that no one ever bothered fixing. The regular VCRA normals for the same doors (on PC and Mac) are messed up in exactly the same way. Possibly this is related to the BSL variable '''door_pop_lighting''' ("uses bad door lighting").

{{OBD_File_Footer | type=M3GM | prev=M3GA | next=Mtrl | name=Geometry | family=General | align=center}}

{{OBD}}

OBD:BINA

2025-05-12T11:09:38Z

Mai X: Removing DEAD part... It is NOT a part of the type...

{{OBD_File_Header | type=BINA | prev=AKVA | next=CBPI | name=Binary Data | family=General | align=center}}

==Introduction==
"BINA" is short for "binary data", which refers to chunks of data that are stored in the [[separate file]] when available (Windows demo, Mac) or in the [[raw file]] otherwise (Windows). BINA is registered as a tag, but is really a wrapper for other tags. One of those tags, OBJC, is a wrapper for still more tags (see below).

==File description==
[[image:bina_all.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | res_id |FF0000| 01 67 23 00 | 9063 | 09063-CJBOCharacter.BINA }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr| 0x08 | uint32 |FFC8C8| 34 8B 00 00 | 35636 | size of the part in the raw/separate file in bytes }}
{{OBDtr| 0x0C | offset |FFFFC8| 40 DD E4 00 |00 E4 DD 40| at this position starts the part in the raw/separate file }}
|}

==Overview of BINA types==
The different sub-tags of BINA are:

{{Table}}
|-BGCOLOR="#E9E9E9"
!COLSPAN=8|[[OBD:BINA/OBJC|OBJC]]: Objects...
|-ALIGN=CENTER
|WIDTH=12%|[[OBD:BINA/OBJC/CHAR|CHAR]] Character
|WIDTH=13%|[[OBD:BINA/OBJC/CMBT|CMBT]] Combat profile
|WIDTH=12%|[[OBD:BINA/OBJC/CONS|CONS]] Console
|WIDTH=13%|[[OBD:BINA/OBJC/DOOR|DOOR]] Door
|WIDTH=12%|[[OBD:BINA/OBJC/FLAG|FLAG]] Flag
|WIDTH=13%|[[OBD:BINA/OBJC/FURN|FURN]] Furniture
|WIDTH=12%|[[OBD:BINA/OBJC/MELE|MELE]] Melee profile
|WIDTH=13%|[[OBD:BINA/OBJC/NEUT|NEUT]] Neutral behaviour
|-ALIGN=CENTER
|[[OBD:BINA/OBJC/PART|PART]] Particle
|[[OBD:BINA/OBJC/PATR|PATR]] Patrol path
|[[OBD:BINA/OBJC/PWRU|PWRU]] Powerup
|[[OBD:BINA/OBJC/SNDG|SNDG]] Sound Group
|[[OBD:BINA/OBJC/TRGV|TRGV]] Trigger Volume
|[[OBD:BINA/OBJC/TRIG|TRIG]] Trigger
|[[OBD:BINA/OBJC/TURR|TURR]] Turret
|[[OBD:BINA/OBJC/WEAP|WEAP]] Weapon
|-BGCOLOR="#E9E9E9"
!COLSPAN=8|[[OBD:BINA/ONIE|ONIE]]: Oni Impact Effects
|-BGCOLOR="#E9E9E9"
!COLSPAN=8|[[OBD:BINA/PAR3|PAR3]]: 3D Particle
|-BGCOLOR="#E9E9E9"
!COLSPAN=8|[[OBD:BINA/SABD|SABD]]: Sound Animations Binary Data
|-BGCOLOR="#E9E9E9"
!COLSPAN=8|[[OBD:BINA/TMBD|TMBD]]: Texture Materials Binary Data
|}

==Global BINA types==
These are stored in '''level0_Final''' and are available globally. The file names link to the raw/separate file parts of every BINA type (or object type, for OBJC).

{{Table}}
|-BGCOLOR="#E9E9E9"
! WIDTH=30% | Filename || WIDTH=35% | Meaning || WIDTH=35% | Function
|-
| [[OBD:BINA/PAR3|3RAP''particle_name''.BINA]]
| PAR3 = 3D particles
| Explosions, projectiles, flashes, trails... everything
|-
| [[OBD:BINA/OBJC/CMBT|CJBO'''Combat'''.BINA]]
| Combat profile; [[OBD:BINA/OBJC|OBJC]] = Objects
| Stores specific (non-melee) behavior: weapon logic, etc.
|-
| [[OBD:BINA/ONIE|EINO'''impact_effects'''.BINA]]
| ONIE = Oni Impact Effects
| Footsteps, combat sounds, etc.
|-
| [[OBD:BINA/OBJC/MELE|CJBO'''Melee Profile'''.BINA]]
| Melee profile; [[OBD:BINA/OBJC|OBJC]] = Objects
| Melee profiles
|-
| [[OBD:BINA/SABD|DBAS''character_name''.BINA]]
| SABD = Sound Animations Binary Data
| Linked to (by name) from the [[OBD:ONCV|ONCV]] files
|-
| [[OBD:BINA/TMBD|DBMT'''TextureMaterials'''.BINA]]
| TMBD = Texture Materials Binary Data
| Assigns a material to a texture
|}

==Level-specific BINA types (OBJC)==
Most BINA/OBJC files are stored on a level-by-level basis, though two global OBJCs are listed above. The file names link to the overview of every OBJC type. The table shows whether a BINA/OBJC is present in a certain level.

{{Table}}
|-BGCOLOR="#E9E9E9"
! WIDTH=30% | BINA file / Level || WIDTH=5% | 1 || WIDTH=5% | 2 || WIDTH=5% | 3 || WIDTH=5% | 4 || WIDTH=5% | 6 || WIDTH=5% | 8 || WIDTH=5% | 9 || WIDTH=5% | 10 || WIDTH=5% | 11 || WIDTH=5% | 12 || WIDTH=5% | 13 || WIDTH=5% | 14 || WIDTH=5% | 18 || WIDTH=5% | 19
|-ALIGN=CENTER
| ALIGN=LEFT | [[OBD:BINA/OBJC/CHAR|CJBO'''Character'''.BINA]] ||X||X||X||X||X||X||X||X||X||X||X||X||X||X
|-ALIGN=CENTER
| ALIGN=LEFT | [[OBD:BINA/OBJC/CONS|CJBO'''Console'''.BINA]] ||X||X||X||X||X||X||X||X||X|| || ||X||X||X
|-ALIGN=CENTER
| ALIGN=LEFT | [[OBD:BINA/OBJC/DOOR|CJBO'''Door'''.BINA]] ||X||X||X||X||X||X||X||X||X||X||X||X||X||X
|-ALIGN=CENTER
| ALIGN=LEFT | [[OBD:BINA/OBJC/FLAG|CJBO'''Flag'''.BINA]] ||X||X||X||X||X||X||X||X||X||X||X||X||X||X
|-ALIGN=CENTER
| ALIGN=LEFT | [[OBD:BINA/OBJC/FURN|CJBO'''Furniture'''.BINA]] ||X||X||X||X||X||X||X||X||X||X||X||X||X||X
|-ALIGN=CENTER
| ALIGN=LEFT | [[OBD:BINA/OBJC/NEUT|CJBO'''Neutral'''.BINA]] ||X||X||X||X||X||X||X||X||X||X||X||X||X||X
|-ALIGN=CENTER
| ALIGN=LEFT | [[OBD:BINA/OBJC/PART|CJBO'''Particle'''.BINA]] ||X||X||X||X||X||X||X||X||X||X||X||X||X||X
|-ALIGN=CENTER
| ALIGN=LEFT | [[OBD:BINA/OBJC/PATR|CJBO'''Patrol_Path'''.BINA]] ||X||X||X||X||X||X||X||X||X||X||X||X||X||X
|-ALIGN=CENTER
| ALIGN=LEFT | [[OBD:BINA/OBJC/PWRU|CJBO'''PowerUp'''.BINA]] ||X||X||X||X||X||X||X||X||X||X||X||X||X||X
|-ALIGN=CENTER
| ALIGN=LEFT | [[OBD:BINA/OBJC/SNDG|CJBO'''Sound'''.BINA]] ||X||X||X||X||X||X||X||X||X||X||X||X||X||X
|-ALIGN=CENTER
| ALIGN=LEFT | [[OBD:BINA/OBJC/TRGV|CJBO'''Trigger_Volume'''.BINA]] ||X||X||X||X||X||X||X||X||X||X||X||X||X||X
|-ALIGN=CENTER
| ALIGN=LEFT | [[OBD:BINA/OBJC/TRIG|CJBO'''Trigger'''.BINA]] ||X||X|| || ||X||X|| || ||X|| ||X||X||X||X
|-ALIGN=CENTER
| ALIGN=LEFT | [[OBD:BINA/OBJC/TURR|CJBO'''Turret'''.BINA]] || ||X|| || || ||X|| || ||X|| ||X||X||X||X
|-ALIGN=CENTER
| ALIGN=LEFT | [[OBD:BINA/OBJC/WEAP|CJBO'''Weapon'''.BINA]] || || ||X|| || ||X||X||X||X||X|| || ||X||X
|}

{{OBD_File_Footer | type=BINA | prev=AKVA | next=CBPI | name=Binary Data | family=General}}

{{OBD}}

OBD:AKDA

2025-05-12T11:08:05Z

Mai X: ...

{{OBD_File_Header | type=AKDA | prev=AKBP | next=AKEV | name=Door Frame Array | family=Level | align=center}}

[[image:akda_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr | 0x00 | res_id |FF0000| 01 C2 03 00 | 962 | 00962-.AKDA }}
{{OBDtr | 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr | 0x08 | char[20] |00FF00| AD DE | dead | padding }}
{{OBDtr | 0x1C | uint32 |00FFFF| 3D 00 00 00 | 61 | array size }}
{{OBDtrBK}}
{{OBDtr | 0x00 | uint32 |FFC8C8| BC 88 00 00 | 35004 | [[OBD:AGQG|AGQG]] element ID }}
{{OBDtr | 0x04 | float |FFFFC8| 00 00 46 43 | 198.000000 | x-coordinate of the lower left point of the doorframe }}
{{OBDtr | 0x08 | float |FFFFC8| 00 00 D8 42 | 108.000000 | y-coordinate (height) of the lower left point of the doorframe }}
{{OBDtr | 0x0C | float |FFFFC8| 00 80 CC C3 | -409.000000| z-coordinate of the lower left point of the doorframe }}
{{OBDtr | 0x10 | float |C8FFC8| 00 00 58 43 | 216.000000 | x-coordinate of the upper right point of the doorframe }}
{{OBDtr | 0x14 | float |C8FFC8| 00 00 0A 43 | 138.000000 | y-coordinate (height) of the upper right point of the doorframe }}
{{OBDtr | 0x18 | float |C8FFC8| 60 7E CC C3 | -408.987305| z-coordinate of the upper right point of the doorframe }}
{{OBDtr | 0x1C | float |C8FFFF| 00 00 4F 43 | 207.000000 | x-coordinate of the center point of the doorframe }}
{{OBDtr | 0x20 | float |C8FFFF| 00 00 F6 42 | 123.000000 | y-coordinate (height) of the center point of the doorframe }}
{{OBDtr | 0x24 | float |C8FFFF| 98 7F CC C3 | -408.996826| z-coordinate of the center point of the doorframe }}
{{OBDtr | 0x28 | float |FFC8FF| 8C E3 38 3A | 0.000705 | facing of the doorframe }}
{{OBDtr | 0x2C | float |FFC8FF| 02 00 90 41 | 18.000004 | width of the doorframe }}
{{OBDtr | 0x30 | float |FFC8FF| 00 00 F0 41 | 30.000000 | height of the doorframe }}
|}

{{OBD_File_Footer | type=AKDA | prev=AKBP | next=AKEV | name=Door Frame Array | family=Level}}

{{OBD}}

OBD:AKBP

2025-05-12T11:07:48Z

Mai X: ...

{{OBD_File_Header | type=AKBP | prev=AKBA | next=AKDA | name=BSP Node Array | family=Level | align=center}}

[[Image:akbp_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr | 0x00 | res_id |FF0000| 01 50 02 00 | 592 | 00592-.AKBP }}
{{OBDtr | 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr | 0x08 | char[22] |00FF00| AD DE | dead | padding }}
{{OBDtr | 0x1E | uint16 |00FFFF| C4 06 | 1732 | array size }}
{{OBDtrBK}}
{{OBDtr | 0x00 | uint32hb |FFC8C8| 00 00 00 00 |0, high bit| plane index (in the environment [[PLEA|plane array]], see [[OBD:AKEV|AKEV]]), reverse plane normal if set }}
{{OBDtr | 0x04 | uint32 |FFFFC8| 01 00 00 00 | 1 | back AKBP package number, -1 if none }}
{{OBDtr | 0x08 | uint32 |C8FFC8| FF FF FF FF | -1 | front AKBP package number, -1 if none }}
|}

AKBP contains one [[wikipedia:Binary_space_partitioning|BSP tree]] for each [[AKVA|BNV]] (the index of the root of the tree is stored in BNV). Such a tree is used to detect if a point is inside a BNV.

It should be noted that for convex BNVs the BSP tree degenerates to a list, only concave BNVs (and there aren't many of them) need a "real" tree.

{{OBD_File_Footer | type=AKBP | prev=AKBA | next=AKDA | name=BSP Node Array | family=Level}}

{{OBD}}

OBD:AKBA

2025-05-12T11:07:35Z

Mai X: ...

{{OBD_File_Header | type=AKBA | prev=AKAA | next=AKBP | name=Side Array | family=Level | align=center}}

[[image:akba_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr | 0x00 | res_id |FF0000| 01 4F 02 00 | 591 | 00591-.AKBA }}
{{OBDtr | 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr | 0x08 | char[20] |00FF00| AD DE | dead | padding }}
{{OBDtr | 0x1C | uint32 |00FFFF| B7 06 00 00 | 1719 | array size }}
{{OBDtrBK}}
{{OBDtr | 0x00 | uint32hb |FFC8C8| 00 00 00 00 |0, hig bit| plane index for this "side" (see [[OBD:AKEV|AKEV]] / [[OBD:PLEA|PLEA]]); high bit flips the plane }}
{{OBDtr | 0x04 | uint32 |FFFFC8| 00 00 00 00 | 0 | [[OBD:AKAA|AKAA]] range start (adjacencies for this side) }}
{{OBDtr | 0x08 | uint32 |C8FFC8| 01 00 00 00 | 1 | [[OBD:AKAA|AKAA]] range end (adjacencies for this side) }}
{{OBDtr | 0x0C | uint32 |C8FFFF| 00 00 00 00 | 0 | ghost GQ start index; ignored }}
{{OBDtr | 0x10 | uint32 |FFC8FF| 01 00 00 00 | 1 | ghost GQ end index; ignored }}
{{OBDtr | 0x14 | uint32 |FFC800| 00 00 00 00 | 0 | BNV quad start index; ignored }}
{{OBDtr | 0x18 | uint32 |C800C8| 01 00 00 00 | 1 | BNV quad end index; ignored }}
|}

;Plane
It appears that the plane is ignored by the engine. In particular if a side has adjacencies then it has ghost quads and any quad has an associated plane. Sometimes the ghost quads are inside the BNV (instead of being on the edge) and in that case the quad plane is different from the side plane.

;[[OBD:AKAA|AKAA]] range
:These 2 fields make up a range of "adjacencies" (see [[OBD:AKAA|AKAA]]). If the fields are equal then the range is empty.

{{OBD_File_Footer | type=AKBA | prev=AKAA | next=AKBP | name=Side Array | family=Level}}

{{OBD}}

OBD:AKAA

2025-05-12T11:05:55Z

Mai X: ...

{{OBD_File_Header | type=AKAA | prev=AITR | next=AKBA | name=Adjacency Array | family=Level | align=center}}

[[image:akaa_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr | 0x00 | res_id |FF0000| 01 52 02 00 | 594 | 00594-.AKAA }}
{{OBDtr | 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr | 0x08 | char[20] |00FF00| AD DE | dead | padding }}
{{OBDtr | 0x1C | uint32 |00FFFF| B3 02 00 00 | 691 | array size }}
{{OBDtrBK}}
{{OBDtr | 0x00 | uint32 |FFC8C8| 01 00 00 00 | 1 | adjacent [[OBD:AKVA|AKVA]] element number }}
{{OBDtr | 0x04 | uint32 |FFFFC8| 88 91 00 00 | 34961 | [[OBD:AGQG|AGQG]] element number. These quads use either TXMPNONE or TXMPBLUEGRID02 textures and have "ghost", "stairs up" or "stairs down" set. }}
{{OBDtr | 0x08 | uint32 |C8FFC8| 00 00 00 00 | 0 | flags; ignored; always 0 }}
|}

{{OBD_File_Footer | type=AKAA | prev=AITR | next=AKBA | name=Adjacency Array | family=Level}}

{{OBD}}

OBD:AITR

2025-05-12T11:05:42Z

Mai X: ...

{{OBD_File_Header | type=AITR | prev=AISA | next=AKAA | name=AI Script Trigger Array | family=Level | align=center}}

[[image:aitr_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr | 0x00 | res_id |FF0000| 01 F8 02 00 | 760 | 00760-level8_scripts.AITR }}
{{OBDtr | 0x04 | lev_id |FFFF00| 01 00 00 10 | 8 | level 8 }}
{{OBDtr | 0x08 | char[22] |00FF00| 00 00 | dead | padding }}
{{OBDtr | 0x1E | uint16 |00FFFF| 03 00 | 3 | array size }}
{{OBDtrBK}}
{{OBDtr | 0x00 | int16 |FFC8C8| 13 00 | 19 | ID }}
{{OBDtr | 0x02 | int16 |FFFFC8| 13 00 | 19 | flag ID }}
{{OBDtr | 0x04 | uint16 |C8FFC8| 01 00 | 1 | type (Script Trigger Type) }}
{{OBDtr | 0x06 | uint16 |C8FFFF| 06 00 | 6 | flags (Trigger Class Flags) }}
{{OBDtr | 0x08 | uint16 |FFC8FF| FF FF | 65535 | team }}
{{OBDtr | 0x0A | uint16 |FFC800| 00 00 | 0 | ref restrict }}
{{OBDtr | 0x0C | float |C800C8| 00 00 00 00 | 0.000000 | horizontal radius }}
{{OBDtr | 0x10 | float |C87C64| 00 00 00 00 | 0.000000 | vertical radius }}
{{OBDtr2| 0x14 | char[64] |B0C3D4| unused | ref name }}
|}

This is the only level, which contains some packages. The AITR files of the other levels are all zero.

{{OBD_File_Footer | type=AITR | prev=AISA | next=AKAA | name=AI Script Trigger Array | family=Level}}

{{OBD}}

OBD:AISA

2025-05-12T11:05:27Z

Mai X: ...

{{OBD_File_Header | type=AISA | prev=AGQR | next=AITR | name=AI Character Setup Array | family=Level | onistuff=aisa | align=center}}

[[image:aisa_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr | 0x000 | res_id |FF0000| 01 9C 02 00 | 668 | 00668-level3_scripts.AISA }}
{{OBDtr | 0x004 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr | 0x008 | char[22] |00FF00|   | dead | padding }}
{{OBDtr | 0x01E | uint16 |00FFFF| 0D 00 | 13 | array size }}
{{OBDtrBK}}
{{OBDtr2| 0x000 | char[32] |FFC8C8| unused | name of AISA character }}
{{OBDtr | 0x020 | uint16 |FFFFC8| 00 00 | 0 | ID of the character, which you can spawn with the script command [[chr_create]] }}
{{OBDtr | 0x022 | int16 |C8FFC8| 00 00 | 0 | flag where character is spawned; must be a valid flag ID (from the [[OBD:BINA/OBJC/FLAG|BINACJBOFlag]] collection) }}
{{OBDtr | 0x024 | uint16 |C8FFFF| 00 00 | 0 | flags; ignored }}
{{OBDtr | 0x026 | uint16 |FFC8FF| 00 00 | 0 | team ID (see [[CHAR]] for possible values) }}
{{OBDtr | 0x028 | link |FFC800| 01 DF 03 00 | 991 | link to [[OBD:ONCC|00991-ONCCkonoko_generic]]; must be a valid ONCC; replaced with first available ONCC if missing }}
{{OBDtr2| 0x02C | char[32] |C87C64| unused | variable, which is affected on game events; ignored }}
{{OBDtr | 0x04C | uint32 |C800C8| 00 00 00 00 | 0 | script flags; ignored }}
{{OBDtr2| 0x050 | char[32] |B0C3D4| intro | script event called when character is created; see [[CHAR]] }}
{{OBDtr2| 0x070 | char[32] |E7CEA5| unused | script event called when the character dies; see [[CHAR]]... }}
{{OBDtr2| 0x090 | char[32] |FFDDDD| unused | script event called when the character first notices an enemy }}
{{OBDtr2| 0x0B0 | char[32] |64AAAA| unused | script event called when the character is alarmed (group event)}}
{{OBDtr2| 0x0D0 | char[32] |EBEBEB| unused | script event called when the character is hurt for the first time }}
{{OBDtr2| 0x0F0 | char[32] |8C8CCC| unused | script event called when the health of the character reaches 1 for the first time }}
{{OBDtr2| 0x110 | char[32] |FF00C8| unused | script event called when the character uses up its initial ammo clips or cells }}
{{OBDtr2| 0x130 | char[32] |F0F096| unused | script event supposed to be called when the character can't pathfind }}
{{OBDtr | 0x150 | link |00C864| 00 00 00 00 |unused| link to an [[OBD:ONWC|ONWC]] file }}
{{OBDtr | 0x154 | uint16 |00C8FF| 00 00 | 0 | weapon ammo (in %?) }}
{{OBDtr | 0x156 | uint16 |C80040| FF FF | -1 | number of ammo(?) to drop; ignored }}
{{OBDtr | 0x158 | uint16 |FFCD96| 00 00 | 0 | number of clips to drop; ignored }}
{{OBDtr | 0x15A | uint16 |FFCD96| 00 00 | 0 | number of hypos to drop; ignored }}
{{OBDtr | 0x15C | uint16 |C8C864| 00 00 | 0 | number of cells to drop; ignored }}
{{OBDtr | 0x15E | char[2] |C8C864| 00 00 | 0 | padding }}
|}
;Player character
:If the index is 0, the character is spawned as a player character, stealing controls (but not focus) from the current player. Focus is transferred as well if the old player is deleted ''immediately before'' the new one is created.
;Automatic naming
:If the name field is left blank, the engine will generate an automatic name "ai_#", where # is the runtime ID of the character (first empty slot in memory at the time of the spawning). The ID is not zero-padded: "ai_0, "ai_1", ...
;Missing [[FLAG]] issue
:If the flag ID requested by [[chr_create]] is obsolete or otherwise unavailable, chr_create will fail with a message to the console.
;Missing [[ONCC]] issue
:Missing ONCCs are resolved by picking the first available ONCC (in ASCII order, i.e., '''SH_generic''' comes before '''barabus'''). In Vanilla Oni this only happens once (for AISA): "lab" scripts use <tt>chr_create 1004</tt> in the bomber cutscene (for the cop who talks to Konoko on the radio): the missing ONCC TCL_2 is luckily resolved as the close-enough TCTF_lite_1. In the [[Anniversary Edition]], the custom ONCC Cop_generic was added to take care of this situation (both to prevent the Vanilla "lab" logic from resolving to '''CopfemA1''' and to give some screen time to TRBSTCL_2, which is present in Vanilla Oni, but somehow doesn't have a matching ONCC).
:If the eventually used ONCC is invalid (e.g., if it has a missing TRAC or if its ONCV is missing from ONVL), Oni will crash. This applies to [[CHAR]] a.k.a. [[ai2_spawn]], [[AISA]] a.k.a. [[chr_create]], and [[ai2_chump]] (hardcoded to spawn ONCCstriker_easy_1; in Vanilla Oni there are three levels where ai2_chump's ONCC is resolved due to a missing striker_easy_1: to CopfemA1 in '''state''' and '''tctf_II''', and to TCTF_swat_blackops_1 in '''compound'''; in '''neuro''' the full set of Strikers is available, as well as comguys, the mad bomber, and Muro).
;Missing [[ONWC]] issue
:Some of the vanilla AISA entries contain a link to an invalid (obsolete) ONWC: two Strikers in '''tctf''' (in the cutscene where Barabas kidnaps Shinatama) have a link to ONWCp_rifle; there are eleven more AISA characters (not used in Vanilla scripts) who have links to ONWCautopistol, ONWCsmg, ONWCp_rifle and ONWCp_stream. The engine resolves such bad links by not giving any weapon to the character. (There are no valid ONWC links in Vanilla AISA, but providing a valid link in a modified AISA shows that the weapon field is interpreted by the engine, unlike other inventory fields which are ignored.)
;Inventory and script events.
:Since nearly all the inventory fields are ignored, AISA characters can't be created with inventory items, and so the "out of ammo" script function is irrelevant. The inventory can still be set with scripting (items that the character can use, not what they drop when killed). The "no path" function doesn't seem to work, neither does it seem to work for [[CHAR]].

{{OBD_File_Footer | type=AISA | prev=AGQR | next=AITR | name=AI Character Setup Array | family=Level}}

{{OBD}}

OBD:AGQR

2025-05-12T11:05:04Z

Mai X: ...

{{OBD_File_Header | type=AGQR | prev=AGQG | next=AISA | name=Gunk Quad Render Array | family=Level | align=center}}

[[image:agqr_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr | 0x00 | res_id |FF0000| 01 4A 02 00 | 586 | 00586-.AGQR }}
{{OBDtr | 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr | 0x08 | char[20]|00FF00| AD DE | dead | padding }}
{{OBDtr | 0x1C | uint32 |00FFFF| 15 A8 00 00 | 35349| array size }}
{{OBDtrBK}}
{{OBDtr | 0x00 | uint16 |FFC8C8| 66 00 | 102 | [[OBD:TXMA|TXMA]] element number }}
{{OBDtr | 0x02 | uint16 |FFFFC8| AD DE | dead | alpha; unused; always the same; used at runtime }}
|}

35349 is the amount of gunk quads. Two faces (triangles) form a gunk quad.

{{OBD_File_Footer | type=AGQR | prev=AGQG | next=AISA | name=Gunk Quad Render Array | family=Level}}

{{OBD}}

OBD:AGQG

2025-05-12T11:04:50Z

Mai X: ...

{{OBD_File_Header | type=AGQG | prev=AGQC | next=AGQR | name=Gunk Quad General Array | family=Level | align=center}}

[[Image:agqg_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr | 0x00 | res_id |FF0000| 01 49 02 00 | 585 | 00585-.AGQG }}
{{OBDtr | 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr | 0x08 |char[20]|00FF00| AD DE | dead | padding }}
{{OBDtr | 0x1C | uint32 |00FFFF| 15 A8 00 00 | 35349 | array size }}
{{OBDtrBK}}
{{OBDtr | 0x00 | uint32 |FFC8C8| 00 00 00 00 | 0 | [[OBD:PNTA|PNTA]] element for 1st vertex }}
{{OBDtr | 0x04 | uint32 |FFC8C8| 01 00 00 00 | 1 | [[OBD:PNTA|PNTA]] element for 2nd vertex }}
{{OBDtr | 0x08 | uint32 |FFC8C8| 02 00 00 00 | 2 | [[OBD:PNTA|PNTA]] element for 3rd vertex }}
{{OBDtr | 0x0C | uint32 |FFC8C8| 03 00 00 00 | 3 | [[OBD:PNTA|PNTA]] element for 4th vertex }}
{{OBDtr | 0x10 | uint32 |FFFFC8| F5 0F 00 00 | 4085 | [[OBD:TXCA|TXCA]] element for 1st vertex }}
{{OBDtr | 0x14 | uint32 |FFFFC8| F3 0F 00 00 | 4083 | [[OBD:TXCA|TXCA]] element for 2nd vertex }}
{{OBDtr | 0x18 | uint32 |FFFFC8| F4 0F 00 00 | 4084 | [[OBD:TXCA|TXCA]] element for 3rd vertex }}
{{OBDtr | 0x1C | uint32 |FFFFC8| F6 0F 00 00 | 4086 | [[OBD:TXCA|TXCA]] element for 4th vertex }}
{{OBDtr | 0x20 | color |C8FFC8| 00 00 00 00 | 0, 0, 0, 0 | byte-swapped ARGB color for 1st vertex }}
{{OBDtr | 0x24 | color |C8FFC8| 00 00 00 00 | 0, 0, 0, 0 | byte-swapped ARGB color for 2nd vertex }}
{{OBDtr | 0x28 | color |C8FFC8| 02 07 09 00 | 2, 7, 9, 0 | byte-swapped ARGB color for 3rd vertex }}
{{OBDtr | 0x2C | color |C8FFC8| 06 15 1E 00 | 6, 21, 30, 0 | byte-swapped ARGB color for 4th vertex }}
{{OBDtr | 0x30 |bitset32|C8FFFF| 00 00 08 02 | 0, 0, 8, 2 | flags; used values:
:0x'''01''' 00 00 00 - door frame (invisible quad that uses the TXMP_DOOR_FRAME texture)
:0x'''02''' 00 00 00 - ghost (pathfinding volume separator, see [[OBD:AKVA|AKVA]] etc)
:0x'''04''' 00 00 00 - stairs up
:0x'''08''' 00 00 00 - stairs down
:0x'''10''' 00 00 00 - stairs
:0x'''20''' 00 00 00 - (runtime only) marks quads as [[Jello-cam|jelloed]]; never used in file data
:0x'''40''' 00 00 00 - triangle (see below)
:0x'''80''' 00 00 00 - transparency (if 0 then alpha is ignored, color is just RGB shading)
:0x00 01 00 00 - unused ("draw flash")
:0x00 '''02''' 00 00 - two-sided
:0x00 04 00 00 - unused ("trigger")
:0x00 '''08''' 00 00 - no collision
:0x00 10 00 00 - unused ("flash state")
:0x00 '''20''' 00 00 - invisible
:0x00 '''40''' 00 00 - no object collision
:0x00 '''80''' 00 00 - no character collision
:0x00 00 '''01''' 00 - no occlusion
:0x00 00 '''02''' 00 - danger
:0x00 00 '''04''' 00 - (runtime only) marks quads hidden with [[env_show]]; never used in file data
:0x00 00 '''08''' 00 - vertical collision: slope < 70°
:0x00 00 '''10''' 00 - horizontal collision: slope > 70°
:0x00 00 '''20''' 00 - unused, runtime only ("breakable")
:0x00 00 '''40''' 00 - grid ignore
:0x00 00 '''80''' 00 - no decal
:0x00 00 00 '''01''' - furniture
:0x00 00 00 '''02''' - projection plan bit 0, see below
:0x00 00 00 '''04''' - projection plan bit 1, see below
:0x00 00 00 '''08''' - sound-transparent
:0x00 00 00 '''10''' - impassable
}}
{{OBDtr | 0x34 | uint32 |FFC8FF| FF FF FF FF | -1 | object ID and type to which this quad belongs (see [[ONOA]] for details); -1 if it does not belong to an object }}
{{OBDtrBK|Data fields exclusive to the PS2 implementation (4 extra bytes at the end of each AGQG array element)}}
{{OBDtr | 0x38 | int16 |FFC8FF| 00 80 | 32768 (high bit set) | unknown; always the same? }}
{{OBDtr | 0x3A | int16 |FFC8FF| 00 80 | 32768 (high bit set) | unknown; always the same? }}
|}
;Triangles
:Many quads are in fact triangles: the last two vertices have the same [[OBD:PNTA|PNTA]] and [[OBD:TXCA|TXCA]] entries, and the ARGB color is (255, 205, 205, 205) (80% gray, 100% opaque). There is also a flag specifying that.

;Ghost, Stairs up, Stairs down
:These flags are used for BNV adjacencies, see [[AKAA]]. Stairs up/down are used instead of Ghost when the quad is placed at the bottom/top of the stairs. These quads are not visibile. The script variable env_show_ghostgqs is intended to control the visibility of such quads but it requires "debug" level files.

:There are a couple of ghost quads that aren't referenced from [[AKAA]]. It's likely that those quads are useless.

;Door frame
:This appears to be another type of "ghost" quad (its visibility is controlled by the same env_show_ghostgqs variable). Sometimes it is used together with the Ghost flag but not always. Only the door frames that also have the Ghost flag are used as adjacencies so it's unclear if the rest of the door frames serve any purpose. In fact it appears that this flag has no effect other than making the quad invisible.

;Stairs
:This is applied to the invisible ramp quad that covers the stairs. In general this flag is also applied to the visible stairs geometry but there are some exceptions (errors? see level 19 stairs).

;No occlusion
:This flag tells the octtree raycaster to ignore the quad when doing ray/quad intersections. This is tipically used for small quads that are unlikely to affect the overall environment visibility.

;Projection plane flags
:These 2 flags can be 00, 01, 10 and 11. That means the values 0,1,2 and 3 which have the following meanings:
:*0 - No projection plane specified. One can be computed if needed. Never used in files, may slow down the game if used.
:*1 - Project quad on XY plane.
:*2 - Project quad on XZ plane.
:*3 - Project quad on YZ plane.
:The projection plane is used to determine if a point is in a quad (this point is usually the result of an intersection between a ray and the quad plane).

;Grid ignore
:Appears to be unused. Its likely purpose is to mark quads that don't count as obstacles in the pathfinding grid.

;Danger
:Appears to be unused. Its likely purpose is to create danger areas in the pathfinding grids. Usually there's a trigger volume nearby that hurts/kills the character. This quads are always invisible.

;Invisible
:Invisible quads have a couple of different uses:
:* block player access to some parts of the environment
:* stairs ramp
:* collision geometry (used by some "complex" furniture)
:* danger quads (see above)
:* some other apparently useless quads

;Furniture
:Set for all quads that belong to a furniture object. It doesn't appear to be used. It is also redundant since all the furniture quads have an object id.

;No decal
:Prevents the creation of decals on the quad. Set for door quads because the decals would disappear when the door opens. That's why shooting a door doesn't leave a mark.

{{OBD_File_Footer | type=AGQG | prev=AGQC | next=AGQR | name=Gunk Quad General Array | family=Level}}

{{OBD}}

OBD:AGQC

2025-05-12T11:04:32Z

Mai X: ...

{{OBD_File_Header | type=AGQC | prev=AGDB | next=AGQG | name=Gunk Quad Collision Array | family=Level | align=center}}

[[image:agqc_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr | 0x00 | res_id |FF0000| 01 4B 02 00 | 587 | 00587-.AGQC }}
{{OBDtr | 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr | 0x08 | char[20] |00FF00| AD DE | dead | padding }}
{{OBDtr | 0x1C | uint32 |00FFFF| 15 A8 00 00 | 35349 | array size }}
{{OBDtrBK}}
{{OBDtr | 0x00 | uint32hb |FFC8C8| 22 28 00 80 | 10274, high bit | [[OBD:PLEA|PLEA]] element number; high bit set means that the normal of the plane must be reversed }}
{{OBDtr | 0x04 | float |FFFFC8| C8 9F A0 C4 | -1284.993164 | max. neg. x-position of the gunk quad }}
{{OBDtr | 0x08 | float |FFFFC8| 00 14 5C C1 | -13.754882 | max. neg. y-position (height) of the gunk quad }}
{{OBDtr | 0x0C | float |FFFFC8| 18 92 F8 C4 | -1988.565429 | max. neg. z-position of the gunk quad }}
{{OBDtr | 0x10 | float |C8FFC8| 60 CA 94 C4 | -1190.324218 | max. pos. x-position of the gunk quad }}
{{OBDtr | 0x14 | float |C8FFC8| 00 40 AB BF | -1.337890 | max. pos. y-position (height) of the gunk quad }}
{{OBDtr | 0x18 | float |C8FFC8| 60 5D E7 C4 | -1850.917968 | max. pos. z-position of the gunk quad }}
|}

35349 is the amount of gunk quads. Two faces (triangles) form a gunk quad.

{{OBD_File_Footer | type=AGQC | prev=AGDB | next=AGQG | name=Gunk Quad Collision Array | family=Level}}

{{OBD}}

OBD:ABNA

2025-05-12T11:04:09Z

Mai X: ...

{{OBD_File_Header | type=ABNA | prev=WPge | next=AGDB | name=BSP Tree Node Array | family=Level | align=center}}

[[image:abna_a.gif]]

{{Table}}
{{OBDth}}
{{OBDtr | 0x00 | res_id |FF0000| 01 51 02 00 | 593 | 00593-.ABNA }}
{{OBDtr | 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr | 0x08 | char[20] |00FF00| AD DE | dead | padding }}
{{OBDtr | 0x1C | uint32 |00FFFF| E8 03 00 00 | 1000 | array size }}
{{OBDtrBK}}
{{OBDtr | 0x00 | uint32 |FFC8C8| 68 89 00 00 | 35176 | [[OBD:AGQG|AGQG]] element number }}
{{OBDtr | 0x04 | uint32hb |FFFFC8| 73 00 00 00 | 115, high bit | [[OBD:PLEA|PLEA]] element number; if high bit set the plane normal must be reversed }}
{{OBDtr | 0x08 | uint32 |C8FFC8| 01 00 00 00 | 1 | front ABNA child package index; -1 if there is none }}
{{OBDtr | 0x0C | uint32 |C8FFFF| DB 01 00 00 | 475 | back ABNA child package index; -1 if there is none }}
|}

{{OBD_File_Footer | type=ABNA | prev=WPge | next=AGDB | name=BSP Tree Node Array | family=Level}}

{{OBD}}

OBD:M3GA

2025-05-12T11:02:42Z

Mai X: ...

{{OBD_File_Header | type=M3GA | prev=KeyI | next=M3GM | name=Geometry Array | family=General | align=center}}

[[image:m3ga_all.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | res_id |FF0000| 01 56 02 00 | 1532 | 00598-.M3GA }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr| 0x08 | char[20] |00FF00| AD DE | dead | padding }}
{{OBDtr| 0x1C | uint32 |00FFFF| 01 00 00 00 | 1 | array size }}
{{OBDtrBK}}
{{OBDtr| 0x00 | link |FFC8C8| 01 D7 00 00 | 215 | link to [[OBD:M3GM|00215-door_1_0.M3GM]] }}
|}

Used to attach multiple geometries to an [[OBD:OBOA|object]]. This allows an object to use more than one texture.

{{OBD_File_Footer | type=M3GA | prev=KeyI | next=M3GM | name=Geometry Array | family=General}}

{{OBD}}