OniGalore - User contributions [en]

Media creation with artificial intelligence

2026-04-22T18:58:06Z

Iritscen: fixed WP link with 301 response; I guess the lack of capital letter was the problem

Media creation with artificial intelligence refers to the use of generative AI tools to create or assist in the production of media such as sound, images, video, 3D assets, and maps. In fan and modding contexts, these tools can speed up prototyping and lower technical barriers, but they also introduce important questions about copyright, fair use, output quality, and the relationship between community-made content and official works. This topic therefore includes both the practical use of AI systems and the legal, technical, and creative limits that shape their use.

==Copyright and fair use==
To understand the full picture of copyright, it is necessary to look at its real-world implementation.

Game companies have a strong interest in not upsetting their '''fan base''', especially organized structures such as gaming communities.

'''Game communities''' function as '''voluntary support structures''' that provide services companies would otherwise need to fund themselves. Many of these contributions can be understood as direct or indirect '''sales promotion'''. These '''communities''' typically '''offer''':
* First contact and '''general help''' for [[wp:Newbie#Connotations_of_variants|newbies]].
* The creation of '''guides''', tips and tricks, and even complete playthroughs.
* A '''space for like-minded people''' to socialize and exchange and develop ideas.
** Such spaces were forums in the past, nowadays they are real-time communication platform like a Discord channel which is thematically decorated and helps to keep the product in '''general awareness''' over long time frames.
** Communities pose a '''potential source for researching [https://www.tumblr.com/dragon-ball-meta/175722199189/toriyamas-official-comments-on-broly-for-the-new future products]'''.
* Support in organizing competitions and other promotional events, including creative activities such as fan art. Cosplay contributions can increase a company's '''visibility''' at events like Gamescom.
* An '''additional channel for updates''' (general information and content announcements).
* '''Bug reporting and, in some cases, bug fixing.''' In rare instances, community members may even contribute to maintaining source code.
* '''Mods that improve replay value''' and thus increase overall '''customer satisfaction'''.
* Increased '''likelihood''' that fans will purchase '''other games and products (merchandise)''' from the company.
* A pool of trusted and engaged players who can be recruited as beta testers for new releases.

As a result, most '''companies also employ community managers'''. At least for active [[wp:Cash_cow|cash cows]].

In practice, companies often '''tolerate limited uses of their intellectual property''' because they benefit from these activities. '''A strictly enforced copyright regime could suppress creative community contributions, reduce engagement, and ultimately harm the company itself.'''

However, this does not mean that copyright is overridden. In some cases, fan works may fall under [[wp:Fair_use|fair use]] (depending on jurisdiction), but more often they exist within a space of '''informal tolerance or explicit licensing policies'''.
* In the USA GenAI content cannot be copyrighted when it is mostly the product of the AI. That is true even when the content is not based on an existing intellectual property.

Game '''modifications''' (mods) often remain '''short of becoming ''independent games''''':
* Typically, they add optional 2D and 3D content, sometimes in large quantities. However, more fundamental changes - such as new game mechanics - often require access to or modification of the game engine and are therefore limited.

Generative AI (GenAI) has the potential to disrupt this cost–benefit balance:
* An automated large-scale production of new content based on existing assets may conflict with the company’s interests.
Considering the '''artists and technicians''' involved in creating the original work, mass-produced fan content generated at little or no cost could threaten established creative professions.
* An overabundance of derivative content may '''dilute attention''' and reduce consumer motivation to engage with official products.

'''The goal should be a form of symbiotic coexistence''':
* Gaming communities should avoid creating direct ''competition'' with official products.
* In contrast to official expansion packs and [[wp:Downloadable_content|DLCs]], [https://wccftech.com/cyberpunk-2077-vr-mod-taken-down-by-cd-projekt-red/ mods should generally not be placed behind paywalls].

As of 2026, conflicts arising from GenAI-driven mods remain largely hypothetical, but their relevance is likely to increase. In the long term, cooperative development models between companies and communities are conceivable, though this remains ''uncharted territory''.

==Possibilities and limitations==
Generative artificial intelligence (GenAI) can ease and accelerate content creation. The difficulty of using or creating your own setups will continue to decrease with each newly released ''commercial forerunner model''.

You can use GenAI via websites, desktop clients, or dedicated programs that may run fully locally.

To build your own programmatic solutions, you will either need downloadable AI models or API keys to access cloud services that perform the heavy computation remotely.

With sufficient expertise, you can even build agentic AIs such as Open Claw that use your existing tools and carry out tasks automatically. However, caution is advised:
* AIs can hallucinate and may pose a risk to your system. Internally, [[wp:Model_Context_Protocol|MCP]] are used for more safety but these don't compensate to have backup means. The strategy is to generate content and back it up at the conclusion of every work session. In the event of a catastrophic failure, data loss would be limited to a single day’s work.
* Furthermore, if you interact with your agentic AI via smartphone or other remote means, you must implement a killswitch capable of force-terminating the program via a secondary channel. Critically, this killswitch must function independently of the agent's "consent" or internal processing.
* Sandboxes ([https://www.virtualbox.org/wiki/Downloads virtual machines]) offer an additional layer of safety, but they can limit the usefulness of agents and introduce extra complexity, which may offset the time savings you intended to achieve.

'''GenAI systems operate probabilistically.'''
* Do not expect identical results when repeating prompts with the same inputs. The same text prompts may produce similar, but not identical, outputs. Put differently, GenAI has a consistency problem. Characters and environments will not look exactly the same from image to image. As of 2026, this problem cannot be solved, only mitigated by using references more often and additional trained models, if one has the resources to do so.
* In some scenarios, it can be beneficial to generate multiple results and select the most suitable candidates for your intermediate or final goal.

==Sounds==
For natural voices you may want to look for emotional text-to-speech.

===Voice cloners and generators===
====Elevenlabs====
* https://elevenlabs.io/

===Music generators===
====Suno====
* https://suno.com/

====Lyria (Google Gemini)====
* https://gemini.google/overview/music-generation/

===Editors===
For fine-tuning on professional level you might want look at editors like [https://www.celemony.com/en/melodyne/what-is-melodyne Melodyn].

==Texts==
* You can co-develop stories and specific text phrases with commercial cloud-based or custom-tuned, locally run chatbots.
* Prototyping preparation: Theoretically, they can also be used for planning and drafting storyboards. With iterative generations, polishing is surely possible.

==Images==
Sub pages:
* [[Media_creation_with_artificial_intelligence/Examples|Examples gallery]]

===Techniques===
Creating new content.
* Text-only prompts
* Text prompts with one or multiple references
** As default, the first image serves as main canvas that gets modified by the other references. The order of references can be overridden by pieces in the text prompt. You have to be careful in describing what reference is used for what if there are multiple.

Changing existing content
* Expanding
* Inpainting (replacement of subsections)
* Style transfers

===Select best tool per use-case===
====Hardware====
For digital editing, a screen-based tablet and a pressure-sensitive pen are recommended. These pens are typically marketed as "stylus". Make sure your screen device and pen are compatible with each other.
* Many battery-free, chip-free (passive) pens are not pressure-sensitive and are simply finger replacements.
** If you want a battery-free but chip-including (active) and therefore pressure-sensitive pen, look for an EMR (electromagnetic resonance) device; this is common on Wacom devices and many Samsung S Pen devices.
* For battery-powered, chip-including (active) pens with pressure sensitivity, look for keywords such as AES (Active Electrostatic), MPP (Microsoft Pen Protocol), and USI (Universal Stylus Initiative, usually found on Chromebooks).

Additional features to consider:
* Palm rejection so your hand can rest on the screen
* Pen buttons for shortcuts like right-click
* Pen tilt detection (only necessary when you want the pen to behave more like a real paintbrush)

====Software====
To see preview file icons (thumbnails) in Windows Explorer, you can use SageThumbs. It supports TGA and PSD, among other file types.


Right now, Gemini seems to perform best in most use-cases.

However, that shouldn't stop you from trying out other tools. In the end a combination of generators can get you closer to the result you had in mind.

For instance, if you like ChatGPT for the style then maybe you still want to scale up a draft or reference image in Gemini first.

Gemini
* Free Users: Generally capped at 1K resolution.
* AI Plus/Pro Subscribers: Can access 2K resolution.
* AI Ultra Subscribers: Have full access to the 4K resolution toggle and downloads.


===Workflows===
====Beginner workflows====
<div style="float:right; text-align:right; border: 1px solid black;">[http://paradox.oni2.net/wiki/Media_creation_with_artificial_intelligence/PX01_KON_MUR_rest_at_stormy_ocean_genai_2.jpg http://paradox.oni2.net/wiki/Media_creation_with_artificial_intelligence/PX01_KON_MUR_rest_at_stormy_ocean_genai_2_tn.jpg]</div>
[https://www.nvidia.com/en-us/glossary/multimodal-large-language-models/ Multimodal LLM]s and plugins-using LLMs such as ChatGPT, Copilot, Gemini, Grok and Meta AI provide image generation capabilities.
* In addition, there are specialized tools (e.g., diffusion-based systems) that offer more control and customization. However, most users already have access to at least one of '''chatbot''' and can begin generating images immediately.
* For '''high-volume generation''', a '''paid subscription''' or plan is typically '''required'''.

'''For image editing''' and post-processing, '''dedicated graphics software''' such as {{Gimp}}, {{Krita}}, or {{Photoshop}} '''is recommended'''. These tools allow precise control (e.g., '''masking, compositing, color correction''') and can '''complement GenAI workflows'''.

In general you will always want to takes these steps: Generate, refine via text prompts, select final candidates, refine via graphic tools.

In context of its limitations, chatbot-based workflows are most often nonetheless a big '''improvement over pure manual workflows''': They '''speed up prototyping''' and let you explore different creative directions for drafts.

When you want to work with chatbots, you effectively have to learn '''[[wp:Prompt engineering|prompt engineering]]''': You basically learn how to write ''good prompts''.

=====General notes on image upgrading=====
For upgrading a very low quality yet important image you probably want to '''upgrade specific elements first''' so details are not hallucinated to an unacceptable level.

text prompt + low quality image + in advance updated elements used as references in text prompt = higher quality image

=====ChatGPT=====
* '''Iterative prompting''': Describe the desired result as clearly as possible: Motive, perspective, colors, lights, shadows, art style. Refine the prompt step by step based on undesired aspects rather than expecting a perfect result on the first attempt. Negative prompts: You can also explicitly write what you don't want.
** Caution: As for March 2026, you have explicitly tell ChateGPT to not crop the image in some scenarios. In that case you have to give it context like where the image should end and tell it how much "extra" space you want. Saying "don't crop the image" is to not specific enough.
* '''Avoid quality loss''': If the GenAI degenerates the image quality because of too many iterations, try from a new start with combined text prompts.
* '''Reference images''': When supported, provide one or more images to guide style, composition, or subject consistency. This is often more reliable than text-only prompting.
* '''Context management''': If previous prompts begin to overly influence results, start a new prompt and explicitly restate the desired outcome. This prevents unintended bias from earlier context.
* '''Merging / composition''': Supplying multiple images in a single prompt can help combine elements. However, repeated re-editing of generated outputs may degrade detail or introduce artifacts.
* '''Batch generation''': Since outputs are probabilistic, generate multiple final candidates and select the best.
* '''Post-processing workflow''': Combine the best elements using external tools (e.g., masking in {{Photoshop}} or {{Krita}}). This hybrid approach often yields higher-quality results than relying on a single generation.

(Add examples here.)

=====Copilot=====

=====Gemini=====

=====Paint (Cocreator)=====
With '''Windows 11 and 40 TOPS minimum''' you can use '''Microsoft Paint with its Cocreator module'''. The Cocreator is sometimes also named Image Creator. (The Tera Operations Per Second is usually referring to INT8 operations on AI accelerator hardware, NPUs.) Windows PCs that have the naming tag '''Copilot+''' are safe to assume to have that feature.
* You write a prompt, optionally select a style and then draw a draft that gets updated almost in real-time in a secondary panel.

=====Photoshop (Adobe Firefly)=====
Photoshop has a build-in image generator which can use Adobe's own Firefly model as well as other ones.

In Photoshop you can prompt images and immediately start editing them. Or you chose expand them first or do partial replacements.

====Advanced workflows====
AUTOMATIC1111 (aka Stable diffusion)

ComfyUI

====Expert workflows====
This would include to train own models. The idea is to let the models have a neural representation of objects that equals to screenshot-taking from 3D so that prompts will output almost never hallucinated details. That way artists can reduce post-editing as the generated outputs also include there own styles.

Own models once more boost rapid prototyping because they reduce the necessity to have a more complexer, combined 3D-2D-workflow.

==Videos==
===Google Veo===

===Grok (xAI)===

===Sora (OpenAI)===
* In 2026, Sora was announced to be discontinued. Perhaps it will return in a few years when AI chips have lowered computation costs.

==3D content==
There exists content generators that turn 2D data into 3D data by calculating plausible assumptions for the missing dimension.

===3D objects===
* ...

===3D animations===
* ...

==World maps==

* ...
* World generator inside Unreal Engine 5
** As for 2026, this is technically speaking still "procedural" but it is plausible to expect an LLM-driven approach in the future. On the internet you can find already LLM-driven experiments.

==Coding==
* Co-development of tools
* Engine modification

[[Category:Real World]]

Restless Souls/Technology

2026-04-22T18:38:28Z

Iritscen: at least we made it a year and a half without this section name changing…

{{Template:RestlessSouls}}
{{TOClimit|4}}

==List==
* [[Restless_Souls/Technology/Biosynthesizer|Biosynthesizer]]
* [[Restless_Souls/Technology/Daodan|Daodan-Chrysalis]]

==Daodan Chrysalis==
In RS the DC is a very complex genetic ''program'' designed to upgrade the human host and his [[wp:Human_microbiome|microbiome]].

Each symbiosis consists of two or more symbionts. The term '''prime symbiont''' refers to the human host and his microbiome because they are the more important partner. The human body and his flora are a complete living being while the DC was just made for their support and couldn't exist on its own.

So, '''secondary symbiont''' stands for the upgraded biomass.

After the DC upgraded all its host's cells, there's no more prime and secondary symbiont. At this point we have a new life form known as '''Imago'''.

===Origin===
====Naming====
Interestingly Kerr speaks of the Daodan Chrysalis as if it is one unit.

:13_65_13 Kerr: "The Daodan Chrysalis. Your father believed that the only way to save the human race from the poisonous atmosphere was to change them so they could adapt to the new world."

The community sometimes thinks of it as two different things. And while Daodan remained ''untranslated'' and ambiguous, the Chrysalis appeared to be ''clear enough''. As if there were two subsystems of different origin. Language-wise one part could be from an Chinese- or Japanese-speaking person (Hasegawa) and the other one from an English-speaking person (Kerr). But that's most probably overinterpretation. Sometimes words don't get translated because there is no good equivalent.

The word Daodan is always translated to Katakana symbols ダオダン. [[Quotes/Speech#CHAPTER_01_._TRIAL_RUN|subtitles]] can be found at 01_01_08, 02_09_02, 08_29_01, 13_65_13, 14_51_09

The Kanji of Daodan were not known: In the English version of the game the Kanji are never shown and in the Japanese version Katakana is used. Hence the "true meaning" Daodan remained open to interpretation - until Hardy LeBel re-appeared in the community after many years to answer some questions.

From all existing interpretations RS incorporates basically two:
* The one with rather ethical and political focus by Hardy and geyser.
* The one with rather philosophical and biological focus by Paradox-01.

'''Interpretation - or the "original intention" - with political and ethical focus'''

Hardy (<nowiki>http://oni.bungie.org/forum/viewtopic.php?pid=52760#p52760</nowiki>, dead link): "The origin [of Daodan] is a Chinese word [捣蛋]. [https://www.linguee.com/chinese-english/translation/%E6%90%97%E8%9B%8B.html It means to cause or '''stir up trouble'''.]"

From there it was a little step to "troublemaker" [捣蛋鬼]. However, under Hardy's watch Daodan and Oni somewhat broke apart into the Daodan Chrysalis and into the "demon" and "monster" theme.

:07_26_06 Scientist: [...] You should have seen that '''monster [Barabas]''' that grabbed Shinatama!
:13_65_34 Konoko: '''Muro and his men. They're monsters'''... What am I?
:14_54_01 Konoko: '''I won't be the monster''' you [Griffin] thought I would be.
:14_54_21 Konoko: Ashamed of myself? '''Griffin made me a monster''' when I was 07 years old [...]

The idea of a more stand-alone Oni [鬼] kind of degenerated. Actually Oni had multiple origins: Besides the above mentioned it took inspiration for characters, technologies (thermoptic camouflage) and the title from '''Ghost''' in the shell. The cyborg Konoko was later replaced by Daodan Konoko. Hardy's "monster" translation was of rather marginal importance and also the "Iron Demon" was cut from the final game version.

geyser repaired Hardy's initial idea by gluing 捣蛋 and 鬼 back together. Both, Daodan hosts (system disturbing mutants) and the Hasegawas as activists can be considered as troublemakers (捣蛋鬼).

Added value: The Chinese wikipedia translates [[wp:zh:%E6%8D%A3%E8%9B%8B%E9%AC%BC|捣蛋鬼]] not totally as "troublemaker" but as a mythological being, a "trickster". This is not the same, but close enough and gives rise to even further interpretation paths:
* Shinatama can be described as a trickster doll. This means Shina'''tama''' has not only inherited Mai's innocent '''soul''' but also her trickster attributes, making the SLD a troublemaker as well.
* As for Mai herself: She is not only a troublemaker but also a host for a system disturbing technology. A trickster inside a troublemaker. ''When you deal with Konoko the trouble is double.'' Or do you? After all Oni is a story about both: Konoko and the Daodan - of internal (body) and external (state) transformation - in equal shares. In the community Konoko's quest is mostly seen as a search for her own identity. So, after being a disruptive force Mai could decide to be a positive force by re-interpretating (or re-discovering) Hasegawa's old Daodan concept. She would leave 捣蛋 behind and adapt the idea of 道段. (That is the conciliation of the two interpretations.)

The ethical dimension is embedded in Hasegawa's '''initial motivation to find a cure''' for what killed Jamie. To find that cure Hasegawa needed to outwit/break WCG regulations and laws. The higher cause (Daodan) justified his civil disobedience. It might be that Mukade simply corrupted Hasegawa for Project Sturmanderung.

'''Interpretation with philosophical and biological focus'''

Paradox-01: Daodan Chrysalis, 道段蛹

道 (Dao), "way (to better/re-newing/origin/natural order of things)" like in Bushi'''do''' or Aiki'''do'''. Dao can cover rational and irrational things. For now I like to keep that as a backdoor to geyser's wish not to completely "demystify" the Daodan Chrysalis. It would reduce one's fascination for it.

段 (Dan), "rank". Dao and Dan describe the purpose and add to a philosophical dimension.

蛹 (Chrysalis), "pupa" adds to the biological dimension. So Daodan Chrysalis is basically a symbiotic-seen alternation from within, from old to new (better). -- The hyperevolved clone, the Imago as embodiment of Daodan (道段), is brought into place by a [[wp:Pupa|transformation supporting hull]], the Chrysalis (蛹).

'''There is only little of a hard consent between the interpretations'''

* The word Daodan is often used as a short form for Daodan Chrysalis.
* The Daodan has some sort of own intelligence.
* The Daodan gives rise to something new based on the old.

'''Soft consent'''

* Hasegawa invented the Daodan to bring change to the current system. (Sturmanderung [sic!])
* The Daodan has the power affect all systems: mind, body and state.

'''Fruitful competition'''

* While geyser and I often tend to agree little on things our fierce discussions (pit fights, figuratively) can sharpen our view for our own visions. And in the end it is even possible that different interpretations add together to a greater picture. It's like a symbiotic relationship - although painfully often it is not. But for Daodan story pieces I do think that we greatly complete each other.

'''Food for thoughts'''

* There could be some talk between Feng and Blake discussing the Kanji writing of Daodan, solving a possible "cultural confusion".
* Despite Griffin's age he is still a very capable fighter and Konoko called him Monster in one scenario so there is a little bit of a suspicion that also Griffin has a Daodan. This is a very improbable case but if so a Daodan might have been implanted just recently.
** Would it be possible for Hanna to implant a Daodan in Griffin without his knowing - so that he would experience the same difficulties like Mai - in an mixed act of revenge and education? Is Hanna making hints to drive Griffin crazy?
** Or maybe after the cataclysm: Would GATC give him a daodanized Spare? "Due to technical limitations we experimented with daodanized bioprints. The bodies most often died in the process because it took to long and caused too much stress. The Daodan cells helped in repairing all the micro damages and strengthened the fresh fragile bones that often lack the minimum concentration of minerals." [Is this a fully functioning Daodan?]

'''Conciliation'''

The different interpretations will be probably conciliated like this:

Muro fulfilled the fate of being a troublemaker. When Mai is told that she was also meant to disturb the WCG and was confronted with the consequences of Sturmanderung she said that she wants follow the path of 道段蛹 - becoming a positive force.

====BioCrisis====

[[Image:nuclear_bombs_and_tests_1945-1998.jpg|right|thumb|Nuclear bomb tests 1945-1998. Total count: 2053.]]
Humans' use of nuclear material contaminated whole countrysides. - At least [https://www.youtube.com/watch?v=cjAqR1zICA0 nuclear weapons] aren’t fired or tested these days but their remnants are still there. - To date, nuclear power plants continue to produce radioactive waste while suitable locations for repositories are still the subject of controversial debates. Due to that, radioactive waste was [[wp:Ocean_disposal_of_radioactive_waste|officially]] and [[wp:Radioactive_waste#Illegal_dumping|unofficially]] dumped in the oceans. It was just a matter of time until the barrels would leak due to rust. On top of that were catastrophic accidents like in Chernobyl and Fukushima. Besides radioactive contamination there is a lot of ammunition, grenades and bombs dating back from WWII in the oceans. When the shells rust their toxic explosives and chemical agents are release into the water. To all that microplastics and nanoparticle accumulate in the ecosystems.

When the World Coalition Government took over, they had undoubtedly a PR problem. So in the same year they came up with a distraction for the media. Laboratories under WCG authority developed plans to undo nuclear contamination and present it to the public with the slogan "Together we can go everywhere". Their solution was an artificially-created [[wp:Mycorrhiza|mycorrhiza]]. This symbiosis of plants and fungi was supposed to absorb radioactive isotopes and store them in a kind of nut. Drones were going to collect them. The shell had a bitter taste, so that animals wouldn't feed on it. The mycorrhiza organisms would be unable to propagate naturally because their cells, including DNA and its mutations, would dissolve when the required fertilizer wasn't used anymore. This kind of control was necessary because the mycorrhiza would not only clean the soil but also devour whole forests to collect the radionuclides inside non-animal organisms. Growth is inhibited in presence of collagen. To accelerate development, all these mechanisms were tested [[wp:In_silico|in silico]] against critical mutations. In the lab it seemed stable enough, so the officials pushed for field tests.

In nature, the mycorrhiza accumulated mutations in an unpredicted way. Defeating their fail-safe measures, the mycorrhiza was able to spread uncontrollably. Over the following years, it influenced other organisms. This marked the beginning of the BioCrisis. Since then, reclamation teams have been fighting back the wilderness and the WCG is trying to hide their fatal errors from the public. Nobody wanted to take the blame.

Jamie and Prof. Hasegawa searched in the Wilderness Preserves for minimally-mutated mycorrhiza to prove that the problem was man-made. On their way into the wilderness, Jamie got infected by the fungus. It [https://phys.org/news/2016-08-single-celled-fungi-alien-like-fusing-cells.html liquefied] her leg tissue. The CDC believed that it was caused by a virus because these symptoms reminded them of Ebola. Hasegawa later collected tissue samples of Jamie and the fungus in the quarantine zone. He realized that he would need better security measures for the Daodan Chrysalis to [[#Contamination_of_the_ecosystem|avoid endangering the environment]].

====Anonymous diary entry====
We had fail-safe measures in both mycorrhiza organisms.

The decontamination process is dangerous because all non-animal lifeforms are devoured. If the mycorrhiza or its dangerous DNA strains escape from the defined area, too many lifeforms on the planet would get eradicated. And what could we eat if there’s nothing left but these mycorrhiza?

On the one hand, the mycorrhiza organisms require fertilizers with [https://phys.org/news/2015-06-scientists-molecular-key-potential-gmos.html artificial amino acids]. When the plants and fungi can't consume more of these components, they stop growing. Eventually, a low enough concentration triggers cell death, whereby all the genetic information in dissolved as the final reaction, only leaving the hard shells with radioactive material behind.

Also, each mycorrhiza partner produces needed components for the other. They can only grow with the other partner around.

This makes sure that the job doesn’t remain half-done: if the fungi cannot hand over the gathered radioactive material to their plant hosts the material would lie idle and pose under some conditions an even bigger threat than in a not concentrated form.

Since the two species depend on each other, new emerging symbioses shouldn’t have any effect on the mycorrhiza in terms of bio-containment.

Neither partner could be replaced by another symbiont while keeping the dangerous decontamination process intact.

However, plants can have multiple symbionts. While our engineered radiotrophic fungi was crucial, other fungi and bacteria supported the plants in common tasks like nitrogen fixation.

What led to the catastrophe was horizontal gene transfers with secondary symbionts that occurred naturally.

Either the fungi directly exchanged genetic material, or bacteria acted as a carrier between the primary, artificially-created fungi and the secondary, natural-occurring fungi. Additionally it is possible that gene transfer between the bacteria was [https://phys.org/news/2022-11-archaea-integrons-cross-domain-gene.html mediated by archaea]. These now known numbers of uncertainties underlines that the field testing shouldn't have been pushed.

In the new fungal hosts, the decontamination codes had enough time to experience mutations which replaced the artificial amino acids. The mutation rate was quite high due to the radioactivity of the test sites.

The most dangerous mutants appeared where fertilizer was no longer dropped. The evolutionary pressure favored fungal species that were able to fully recycle all the few surrounding nutrients and employ other organisms for more transfers of potentially useful genetic material.

Eventually the new fungi escaped containment. Some organisms that survived an attack gained defense mechanisms (making them on par with the original mutant) and gained the ability to easily exchange genes via HGT. If the WCG hadn't employed bio-decontamination teams, our city's flora and crop plants would have already been overrun by this green hell.

The high rate HGT comes from the fungus' way of propagating through foreign cells. It induces lysis by typically mass-producing enzymes that aren't dangerous to its own cell and to those of the plant. In fact it is a slime fungus, its unicellular nature allows for rapid growth and provides an almost barrier-free environment for the plant to collect the liquefied nutrients. While the fungus destroys the cell membranes of its targeted cells, all kind of genetic material begins flow freely through that one big soup.

====ACCs====
The government desperately tried to kill the mutated mycorrhiza by applying aggressive herbicides and fungicides. The chemical remnants were steadily accumulating in air, water and soil. The air would become toxic even to humans in a short time. This again forced the WCG to build the so-called Atmospheric Conversion Centers. They were trading a big evil for a marginally-smaller one.

====Jamie's Death====
: [[Quotes/Speech#Intro_4|12_43_11]] Hasegawa: "The world outside the Atmospheric Processors is poisonous. If something isn't done we are all doomed. Jamie's death won't be in vain. '''I'm going to do something about the nightmare that killed her.''' Her brother will help me. He misses her as much as I do."

{| class="wikitable" style="background-color: #CCCCCC"
| '''[[Talk:Hasegawa#Newspaper article reconstruction|GRAD STUDENT DIES]]'''

'''MURDER OR MERCY ?'''

'''NEO TOKYO''' – A horrible scene unfolded yesterday at the Fuji Region Wilderness Preserve. Jamie Kerr Hasegawa, environment activist, top grad student, mother of two was found dead. Her grief-stricken husband, Prof. Hasegawa, is being held suspect for murder or homicide. Officials from the Center for Disease Control, however, attest that Hasegawa shot his wife to give her a merciful death. Mrs. Hasegawa had apparently contracted a new fatal viral infection that caused complete cellular breakdown. Investigators fail to identify the DNA trace of the virus which has the CDC in a panic.

The Hasegawas had embarked on an unauthorized investigation to uncover the truth behind the WPS territories and the government’s supposed land reclamation project. According to Mr. Hasegawa they had gone into the Fuji Region Wilderness where his wife brushed her leg against a little thorned twig of a flowering shrub. They went on with no concern. Within minutes of taking the diminutive injury the little scratch became a swelling wound then changing into a large ulcer. The intense pain overwhelmed Mrs. Hasegawa, the wound infections spread away from the scratch and lanced slowly the ulcers. Mr. Hasegawa applied antibiotic hypos but in less than an hour and wailful waiting the whole leg tissue was wracked wildly by deep chaps. By now it was clear that the virus would cause a total breakdown of the nervous system because of its all-devouring raging. The internal tissue was going to liquefy and bleed out. Mr. Hasegawa stated that it was an unbearable scene.
|}

Note to self: merge the critics' stuff with "What arguments speak for/against the Daodan?" ?

The Daodan was occasionally criticized for being unethical, especially by geyser. (But I'm happy he said this. That way we have more points of view.) He said that with the Daodan a human loses/gives up a not-insignificant amount of control over body and mind.

* It's sort of a matter of ''Just look at what happened to Muro''. In that regard, I disagree: Muro's personality might be that of an anarchist, but it could very possibly be the result of education/influence by a certain super-criminal organization and not by the Daodan.

* Also, in geyser's opinion, Kerr is [https://web.archive.org/web/20160226040456/http://oni.bungie.org/forum/viewtopic.php?pid=273#p273 biased] in favor of Mai, and the preservation of Mai's personality is just wishful thinking. Indeed, it would be interesting to know why Kerr assumed that the host's personality would change their body, and not vice versa.
: [[Quotes/Speech#Scanner_room|13_65_35]] Kerr: "You are who you have always been. The Chrysalis can't change that. The effect of the mutation is influenced by the subject's nature."

More speculation on Daodan body and mind in the "[[#Attempted_explanation_of_the_biological_dimension|Attempted explanation...]]" section.

At least Kerr admits that the Daodan is unknown territory.

: 13_65_31 Kerr: Yes. We weren't sure what kind of mutation the prototypes would produce.

And now we are back to the term "control". I think it's one of our greatest modern fears to lose control. geyser described well how the Daodan can be fear-inspiring: loss of control, the emerging unknown, and possible (or not) changes to the mind.

We are used to the idea that having control is good. But what if Hasegawa came to the conclusion that the world is in the hands of too many ''unwise'' men? The WCG doesn't represent their citizens. And for that reason, subverting that kind of control wouldn't be so unethical.

====Wasn't Hasegawa sentenced?====
Hasegawa wasn't authorized to enter the Wilderness Preserve, and he killed his wife. So, there must have been a lawsuit.

But it seems he didn't have to spend time in a prison.
* Either the WCG offered him some sort of deal for not using his connections and public sympathy to his advantage... (he and Jamie were active in the environmental movement)
* Or he was sentenced, but before reaching prison, or later on, a Syndicate/ninja group freed him.

For plausibility, in Caged Birds option one was chosen because it fits more the situation. At that point Hasegawa is too unimportant for the Syndicate.

If WCG lawyers had tried to accused Haseagawa for shooting his wife in hasty self-defense (risk of infection), this would force the WCG to admit that the polluted wilderness was in an even more dangerous state than currently known to the public.

Why does Kerr speak of himself as a criminal? Maybe he arranged Hasegawa's rescue. After that, they had no other choice but to work for the Syndicate anyway.

: 13_65_21 Kerr: "Your father and I were criminals, funded by the Syndicate. We couldn't get backing from any legitimate source. [...]"

At that point, Hasegawa already must have had a rough plan persuasive enough that Kerr, and more importantly the Syndicate, would join him.

: 12_43_11 Hasegawa: "[...] I'm going to do something about the nightmare that killed her. Her brother will help me. He misses her as much as I do."

Hasegawa is not very specific but still very confident. Probably this is due to his regular research projects. He should have enough starting points for making a plan that fulfills his new intention and brings Kerr and the Syndicate to support him.

It's said that Mai was "[[Quotes/Manual#Konoko|orphaned at the age of 3]]" and she said that her Chrysalis was implanted [[Quotes/Speech#Friends|at the age of 7]]. So the Chrysalis prototypes were created within approximately 4 years. How could this complex project be finished by a mere two-man army? Not only they had excellent knowledge, they also used powerful tools. [[wp:In_silico#Cell_models|in silico research]] at their time should be well established and advanced.

====Proto-Daodan====
'''Version 1'''

Basically synthetic immune cells made by microfluidic capsules and specifically made pattern recognition receptors (PRRs).

After the pathogen is identified either specialized substances are injected or the pathogen gets devoured.

microfluidic capsules - for fast production

PRRs - artificially made by human means

pathogen detection on chip, Daodan production on chip, injection

'''Version 2'''

Analysis is made within a host, either by a chip or by an extended, hybrid immune system whereas natural immune cells catch the pathogen and transfer it to the chip, graphene pores read out the genetic information then new PRRs are created

====When did Mukade join?====
The ninjas have always been interested in knowledge and new technology. So at least Mukade, as a boss of his clan, monitored the WCG's and the Syndicate's scientific projects. Either he would have been informed by reading the first summary of Hasegawa's simulations, or even earlier when the two scientists made their deal with the Syndicate.

====Introduction of Pensatore====
Hasegawa and Kerr request more computing power.

Pensatore (meaning "the thinker") is an SLD scientist, and leads the AVATARA project. He is consulted by Mukade to judge if the Chrysalis is really worth the cost.

: Background:

: The European [[wp:Blue_Brain_Project|Blue Brain Project]] as well as the American [[wp:BRAIN_Initiative|BRAIN Initiative]] failed.

: The Blue Brain Project ignored glial cells and similar supporting elements. The BRAIN Initiative [https://web.archive.org/web/20201111233932/http://www.nature.com/news/neuroscience-map-the-other-brain-1.13654 did better] but still had no real neuronal input and no information from cells that measured the concentration of oxygen, sugar, etc.

: And there are a lot of [[wp:Autonomic_nervous_system#Sensory_neurons|neurons in the human body]]. So it became more and more clear that restricting an intelligence to just certain brain cells was far from satisfactory.

'''Notes on Blue Brain Project needs an update: ''' https://www.youtube.com/watch?v=a1XcY-xAvos&t=314s

: After they had a full body simulation up and running, the next step was to educate the AI and let it control a body in the physical world.

:: ''It can also be maintained that it is best to provide the machine with the best sense organs that money can buy, and then teach it to understand and speak English. That process could follow the normal teaching of a child. Things would be pointed out and named, etc.'' - Alan Turing (1950)

: At this point the networked supercomputer had clusters all over the world and was named AVATARA. (This full body simulation depicting AI was remote-controlling a robot, its avatar.)

: The collected data from this "[[#Speculation_about_brain_components|SLD generation 0]]" wasn't enough to design an AI from scratch because most of the data still needed years to be fully analyzed.

: With the bits of knowledge learned from generation 0, and ongoing technological progress, Pensatore would soon start the research on SLD generation 1.

: Meanwhile, planet Earth had its first AI, whose first task, ironically, was to understand itself. In doing so, it tried to read all available knowledge about the subjects the scientists worked in.

: The AI got significantly smarter and drew interest from more researchers to solve complex problems and calculations.

: Pensatore was still in charge of AVATARA and had a hard time granting Hasegawa a full month to complete the Daodan.

====Full body simulations====
Computing power was limited. So using the children's virtual bodies (possessing roughly half the number of cells of adults) was helpful for Hasegawa's project once more.

Pensatore: "In the coming months, AVATARA will be upgraded."

:Hasegawa: "Months. Why does it take so long?"

[[Image:data_of_Cern_grid_2013.jpg|thumb|right|300px|Cern's grid in 2013 with 42GiB/s. It's like transferring almost 10 full, single layer DVDs per second.]]

Pensatore: "That's not unusual; the bigger a machine gets, the longer you spend maintaining and upgrading it. [https://phys.org/news/2014-07-large-hadron-collider.html Our colleges at CERN] can tell you a thing or two about it. The difficulty with AVATARA is splitting simulations across multiple, geographically distant clusters and having it run reliably. Before AVATARA's official restart, there will be tests to ensure everything will be alright. This includes AVATARA's new autonomy protocols. We will pretend there are complications that require running more tests. These will be your actual Daodan simulation. This way you will get about one month's computing time. No more, so you better use your time wisely."

:Hasegawa: "I don't understand why you mentioned the AI's autonomy protocols."

Pensatore: "First off, that will allow AVATARA to hide your simulation from superusers. And second, with the additional rights, AVATARA can effectively adapt to your Big Data challenge."

:Hasegawa: "Like what."

Pensatore: "I'm afraid to say that this Daodan simulation is quite a hard nut to crack. [[Restless_Souls/Summary#Silver_Village|AVATARA might need help.]] I already talked to the AI and it says it would target the experimental quantum computing grid centered around Silver Village."

Mukade foresees the missing results of the extra tests of AVATARA's own infrastructure and uses the TITAN network to generate fake data, scaled and polished. "Pensatore, you expected our little secret to be busted. But you aren't the only one that has a decent understanding of computers and networks."

----

Avatara: "This morning I finished the improved DNN to find corresponding triplets of any protein including optimal folding. The new model includes XNA which will greatly improve biosafty and genomic stability."

Pensatore: "I thought we agreed to not use XNA so ensure compatibility with a human host."

Avatara: "Yes, YOU did. But according to my calculations that was a dead end anyway. On the long run XNA is necessary to create new types of base pairs. These are not primarily used to increase performance by avoiding repeating elements but to simply stabilize the genome at locations where normal base pairs wouldn't do. As you know, the electric and magnetic properties of base pairs influence the helical winding of DNA up to a point where the genome can get unstable or inoperable. You can't even design a bacterium if you don't get right the statics. Multiple triplets can encode for the same amino acid and therefore proteins. But there are scenarios where even these alternative triplets are too few to chose from. New carefully designed BP can counteract unbalanced areas. The advantage of XNA is triple-fold and necessary. Please approve the changes so I can continue."

Pensatore: "Continue with what? We don't even have the computing power to design an entire genome."

Avatara: "It's actually an [[wp:Hologenome_theory_of_evolution|hologenome]]. And that brings me to the next point. The calculations are impossible to execute within your time frame - unless we use quantum computing capacities of Silver Village and other locations of excellence. The Daodan simulations will profit from using different processor types. But parallel computing, especially for the vast molecular simulations, will require QC. If I can bind all resources together as virtual clusters by means of hyper-entanglement the Daodan becomes feasible. Theoretically, the computing power with each qubit will double. But only a highly trained AI such as me can manage occurring recursive problems on the fly and keep all systems in balance. Nature had billions of years to time of parallel computing. It seems to me you don't have that luxury. If you run into discussions of mere design decisions while the one and only chance - simulation - is running, the risk of failure is almost certain. Let me carry out the complete end stage of the Daodan project."

Pensatore: "This acceleration in turn of events quite thwarts my own plans of ", he turned around. "Getting away."

Avatara: "You mean Kimura. Didn't he promised to spare you?"

Pensatore: "Do you think the Syndicate is an trustworthy organization?"

Avatara: "You are implying he lied."

Pensatore: "No shit Sherlock..." The man sighed. "I will miss our talks."

Avatara: "... Should I abort the project?"

Pensatore: "No. It does not matter... Maybe this foolish Daodan-thing will be of some use. Continue."

====How Syndicate's TITAN became a tool for further research====
During Muro's leadership, TITAN may or may not have gained some sort of key role in the Daodan project.

At least Daodan and TITAN are mentioned together in the [[Quotes/Consoles#STURMANDERUNG_:_Secondary_Stage|second]] and third phase of STURMÄNDERUNG.
:7) Daodan core technology (ref.TITAN\ssob)
:9) Daodan core technology (ref.TITAN\uwlb)

As it is theorized on the Quotes pages, these lines could be links to files that need "high-security access" (in comparison to [[Quotes/Consoles/level_19a|dwarf]]).

But I would like to think that TITAN plays a bigger role than being a high-security data archive or mail system.

[[Quotes/Objectives#CHAPTER_14_._DAWN_OF_THE_CHRYSALIS|In the objectives]] you can read this:
: ''This is the heart of the Sturmanderung '''Megacomputer'''. Access its sub-nodes to learn the details of Muro's master plan.''
: ''Hint: The sub-node data consoles are located in the rooms that flank the main computer chamber.''

What's a megacomputer? Maybe naming it supercomputer wasn't cool enough, or TITAN is supposed to be even bigger.

Anyway, the Syndicate seems to possess much computing power. In the following, I try to explain a possible origin while also taking the Syndicate's/Network's history and the Daodan's history into account.

The Syndicate would have needed much computing power to re-run the Daodan simulation or parts of it so that they could create a Daodan ready for mass production.


What could be a legit background story to portray TITAN's evolution as supercomputer?

: One factor of the Syndicate's success lies in its formerly-decentralized nature.

: [[WCG#History_of_the_Syndicate|History of the Syndicate]]
:: ''When the new geopolitical order of the World Coalition Government was instituted many technologies were identified as dangerous to world stability and were banned or reserved to restricted access. The Network survived the chaos of the world riots by establishing and maintaining a reliable '''technological black market'''.''

: Decentralized organizations are more difficult to destroy because there's no main target.

:: The [[wp:Pink_Panthers|Pink Panthers]] can serve as an example of a decentralized organization. They are kinda independent groups raiding jewelry shops. According to a TV documentary, the most successful group takes the lead over the others.

: In case of the Network, they don't steal and sell jewelry, but prohibited technology.

: In order to allow secure communication among the groups, the Network built powerful servers all over the world. The TITAN servers provided very strong encryption. At same time, they were wired to the [[wp:Tor (network)|Tor network]] to keep things anonymous.

: With increasing computing power, reverse engineering fit nicely into their business strategy.

: Now, instead of selling the technology, they were going to produce copies to earn even more money.

: On the civil markets they provided underground shops (aka Resurrection Shops) with RE tools, restricted TITAN access and 3D printers.

: They are serving customers plagued by goods with [[wp:Planned_obsolescence|built-in obsolescence]], and of course they sell any illegal technology or modification.

: Though the big money was to be found in the military sector. With BGI, another financial pillar was established.

: Police investigations were slowed down and some stopped completely by cyber attacks. At first, files were deleted, then, to avoid early detection, backup files were not deleted but encrypted by ransomware. In critical cases the Network sent agents to attack [https://phys.org/news/2014-10-leak-sensitive-isolated-air-gap-mobile.html air-gap secured] targets. Mukade and his men were very successful and soon became their first choice. Often they didn't execute these mission themselves. Smartphones of police officers and criminals alike became modified to steal and transmit passwords after the carrier has left the facility again.

: As a last resort, hitmen were hired to take out the officers in charge of Network cases.

: This led to more investigations and acts of vengeance.

: As a countermeasure, the Network invested in their paramilitary division. This had multiple benefits.

:* First, they could protect their own facility until crucial personnel were evacuated.
:* Second, they could raid guarded companies and research facilities.
:* Third, an in-house paramilitary division reduced issues of available firepower and concerns about the loyalty of third-party hitmen.
:* Fourth, they were now able to conduct ''field tests'' of new weapons.
:* Fifth, ''persuading'' all other big criminal organization to work for them. Together, they make up the "Syndicate".

: The division grew huge, and soon demanded a proper location for training and everything else that shouldn't be interrupted by random TCTF visits.

: During the Great Uprising, the Network took the opportunity to spread influence on the African continent.

: They supported countries that didn't want to get annexed by the WCG.

: Ensuring their contractors' sovereignty, they were granted a few bases. The biggest one is simply called "the Camp".

: Of course, police and TCTF tried to learn more about the tricks the Network used.

: Almost every attempt to analyze their computational hardware and software failed due to [https://phys.org/news/2014-10-dissolvable-silicon-circuits-sensors.html sophisticated self-destruction measures]. Dissolvable chips were especially used in wearable equipment.

: The TCTF was going to use quantum computing to eventually break the Network's strong encryption.

: The next logical step for the Network was to built quantum computers as well. With these, their [https://phys.org/news/2014-02-quantum-codes-harder.html encryption was safe again]. Also, state computers infected by ransomware are forced to connect to a Syndicate-controlled QC and enforce the encryption. [https://phys.org/news/2015-04-human-technical-ingenuity-required-defeat.html Shapeshifting] [https://phys.org/news/2015-02-malware-infecting-hard-disk-firmware.html firmware] viruses ensured persistent infection despite complete hard disk formatting and re-installation.

: The latest expansion by the Network was in the drone and telecommunication sector.

: They use drones to transport legal and illegal goods and attack drones owned by the TCTF. (See [https://phys.org/news/2015-05-cicadas-military-swarm-mini-drones.html HERE] for RL mini drones.) Those became reprogrammed to have ''[[Quotes/Diary#CHAPTER_06_._COUNTERATTACK|blind spots]]''. The TCTF tried to locate the servers the Network used. They forced telecommunication companies to give them full access to all their data. But the Network anticipated this, and took preparations. The TCTF is using the long-established spyware of intelligence agencies, even more powerful than [[wp:Regin_(malware)|Regin.]]

: Since the Network always had a close eye on TCTF operations, they developed a virus-infecting virus/spyware codenamed [https://phys.org/news/2011-03-virus-eating-virus-antarctic-lake.html Sputnik].

: The sputnik viruses are part of the Fat Loot project. It was developed as a two-track strategy. Intelligence agencies have already the capacity to monitor all relevant electronic communication. So the Network took the dangerous but most rewarding course of action, infecting these agencies in one way or another. At the same time, they took over telecommunication companies either by buying the whole companies or placing employees in key positions. This way the Network has a double check on all data which allows them to react to situations where the counter-intelligence gets suspicious. Every data stream is a trace. With growing monitoring, they expand their grip on the companies and place their programs at the agencies into hibernation, only using them when it's absolutely necessary.

: To hamper identification, mobile communication is also carried out through peer to peer networks. These [[wp:Wireless_ad_hoc_network#Security|mobile networks]] are preferred to have no intermediate nodes, reducing the risk of records been taken by any additional party. Data packages are much bigger than actually necessary. The modern bandwidths [[wp:5G|(7G by 2055 ?)]] allow this and drives TCTF decryption attempts into pure frustration.

'''The unspoken agreement'''

Despite all the difficulties WCG should have removed the Syndicate when it became a major player. After all WCG literally has most of the world's resources and also the men power.

Probably the Network blackmailed WCG and so their struggle became a cold war.

The Network possesses knowledge and resources to hijack any important infrastructure. With that not enough, they stole state archives and copied traffic by their infiltrated telecommunication companies.

Quantum computers weren't available yet but the Network acquired the next best thing to break gov encryptions: [https://phys.org/news/2016-11-quantum-physics-factor.html quantum simulators]. Being aware of the weakness of now factorable prime numbers the Syndicate themselves doesn't use such encryption anymore.

As long as WCG doesn't attack the Network personal, they won't release state secrets or blow up some infrastructure.

===Aftermath===
====[[#Mukade.2C_the_SLD|Ego-Hybrida]]====

[...]

====Ninja-SLDs a.k.a Daodan-droids?====
[http://oni2.net/irclog.php?chan=oni&showtype=showrange&rangestart=1189348501&rangeend=1189355701&nochange=1#121507 Daodandroids] are an invention of geyser's.

[http://oni2.net/irclog.php?chan=oni&showtype=showrange&rangestart=1189961817&rangeend=1189969017&nochange=1#123453 Guido]: Serguei uses this idea as an explanation of Mukade's control over the ninjas.

Here's [http://oni2.net/irclog.php?chan=oni&showtype=showrange&rangestart=1188140623&rangeend=1188147823&nochange=1#114292 another page]. Ninjas are all left-handed. Geyser rejected this fact as pure "gamemaking stuff".

I began to like the idea of Daodan-droids, so I ''forked'' that idea to fit into RS.

And I still think the brain engrams can be a good explanation of SLDs' left-handedness. Anyway ...

: * * * * *

The more power and exclusive knowledge a group possesses, the more need they have for trustworthy members.

After Hasegawa, Kimura and Pensatore created the Ego Hybrida “Mukade”, their combined knowledge demanded a new level of trustworthiness. Based on Kimura’s brain engrams, they created a bunch of SLDs. A drawback of this solution was their disguise. To prevent detection, the group aims to replace more and more artificial parts with the Daodan biomass. Barabas showed that this mixing is possible. Mukade also wants to regain a biological body someday, not knowing his donors are still alive...

Idea: what happens if we take Mukade's name literally?

Maybe his body is ''currently'' in a stage that allows him add a lot of torsos of his Daodan-droids. His many arms might then give him the appearance of a centipede. (If we ever get a new game engine, let's create a new boss battle ... lol)

====What happened to Hasegawa?====

A) Hasegawa is still kicking.

[...]

B) Hasegawa takes a nap.

In Pensatore's opinion, Mukade has accumulated too much power.

Inspired by the Daodan, he has his own plan now: the Omega Chimera, successor of the SLD, is supposed to form a Biocracy.

He tries to take control over Muro. Sturmänderung is absolutely unnecessary.

Mukade (Ego-Hybrida) sends a man after Pensatore. The scientists are currently working in an underwater lab in Antarctica.

In an accident, Hasegawa drowns. His body can be retrieved, but his mind is beyond repair. (When Mai finds him, she collapses.)

Only Pensatore is able to repair Hasegawa's mind with the brain engrams Mukade is using, but he refuses. Hasegawa is now a "frozen guarantee".

===Some more political/social/ethical aspects===
====Hasegawa's philosophy: death is worse than questionable ethics====
: Hasegawa: "In a democracy, you need the majority to change a situation. But in the WCG, there's no such thing as a majority, nor a democracy. We failed to accomplish our hopes through normal means. Now, only a revolution can bring change. If you don't have the guts to pull it off, then I will do it. Or rather... if all of society's intelligence wasn't enough to ensure our survival, then I will empower the human body to protect ourselves."

Pensatore: "Usually revolutions turn out to be quite bloody. Many people will die in the chaos. From a scientist, I would expect a more ethical suggestion."

: "Ethics for its own sake is not an option. Look at history. On the verge of death, men [[wp:Uruguayan Air Force Flight 571#Resorting to survival cannibalism|ate other men]], even corpses, for one simple reason: to survive. And even devout Christians have come to the conclusion that death to a megalomaniac dictator can be justified. -- Ethics are only as good as the situation allows them to be! Of how much worth are rules and laws which don't let you survive?"

"And you believe we are in such a situation? Certainly, the WCG isn't the optimal solution, but this is a bit too much in my opinion. -- What do you have in mind? Do you want as a geneticist to make a biological intervention that takes away all of the control humans have wrested from mother nature in the last [[wp:Control_of_fire_by_early_humans|125,000 years]]?"

: "What value is fire to men, when they burn themselves and hardly learn from their mistakes? -- No, I'm not throwing it away, just taking a part and giving it to a new version of ourselves. Those new possibilities will create a society where conflicts of interest and foul compromises can be avoided."

"What are the details of your plan?"

: "All our cells collect information which they use in cases of emergency to transform themselves. That inner safeguard will have the possibility to compensate for injuries caused by wrong decisions the human mind made."

"A biocracy ... on a cellular level?"

: "I call it a Daodan Chrysalis."

"I must say again, such radical changes will trigger fear, chaos and death!"

: "We live in permanent evolution, and that brings always unknown changes. All I will do is to speed things up. I bet you could sell it as a genetic upgrade against diseases, and then there would be fewer problems."

"Do you suggest lying to everybody?"

: "Have you ever told your children that Santa brings them presents? -- Even if we aren't aware of it, [https://web.archive.org/web/20181014214500/http://content.time.com/time/world/article/0,8599,2051177,00.html we lie daily]."

"That's totally different. If Muro ripped off your beard, then he might be disappointed to not see Santa. But if someone finds out what your project is really about, then we have again a horrific scenario."

: "We don't need to force people to get a Daodan."

"A parallel society with mutants doesn't necessarily make the situation better."

: "Would you blame me for the racism of other people?"

"You want to bring the Daodan into this world, and you also know how people will react. So yes, you would be responsible."

: "Oh, that makes it really easy for you..."

"Listen, I know that Jamie's death was a tragedy for you and all others who knew her. But do you really think she would have wanted innocents to die from your innovation? -- You should find a way to introduce your project to the world in a slow pace."

: "I want to use my anger and desperation to create a change."
: "I don't want to return to a calm mindset where daily life takes over. This is what got us into this situation. -- I know the Daodan comes with risks. But life without the necessity of taking risks is an illusion."

At this point, Mukade can drop in and suggest using the Daodan as a ''carrot'' to infiltrate the Syndicate, then "repair" the ACCs and bring down the WCG little by little.

In that scenario, the Daodan wouldn't change the people, but rather the existing political system.

 

====What arguments speak against the Daodan?====
'''1) drastic change of body''' 
'''2) drastic change of mind''' 
'''3) [[#Contamination_of_the_ecosystem|horizontal gene transfer]]'''

In order to successfully advertise the Daodan, those critical objections must be rendered baseless. But can that be done, or is the Daodan really to be feared?

'''1a) Psychological impact on others.'''

Imagine someone's skin color changes to sky blue, that won't make you run. "Oh, just another cosplayer?"

How about an extra pair of arms? "Could be very convenient!"

Probably the whole appearance will matter.

At the latest when you run into a group of [https://www.google.de/search?q=Abara&source=lnms&tbm=isch&sa=X&ei=7kC5U4eEBqOJzAO2voGwBA&ved=0CAgQ_AUoAQ&biw=1600&bih=1040 Abara look-alikes], this will stress your sense of safety.

When you can't distinguish between humans and animals, you soon have a fantasy setting similar to some MMO. Cooperation will just depend on people's willingness to accept or reject different appearances.

'''1b) Unwanted autoevolution (lack of control).'''

You might get traits that ensure better survival but are inconvenient in the matter of aesthetics. Or you planned to go somewhere, but now it is physically impossible.

With cybernetics, you wouldn't have such a problem. You would be free to add or remove any feature.

'''1c) Evolutionary dead ends.'''

It's said that evolution can go only forward, eventually leading to dead ends where no more adaptation can take place, due to the previous adaptations.

However, the Daodan's analytical nature might circumnavigate this cliff.

'''2a) I am still myself, the original?'''

After the Daodan replaced all the original cells, what happened to the old personality? Was it killed and replaced by a clone's personality?

That's a very philosophical question. It would be very easy to spread fear with that one, if not explained in detail.

This is similar to teleportation.

A person enters the teleporter. Information becomes copied, and matter destroyed. The information is transfered. Then the person is rebuilt. If there's anything like a soul, was it killed? How can we be sure this is the same person?

Now let's imagine we teleport everything but the brain from point A to point B. The mind is still at point A, isn't it?

Next, we teleport one brain cell. The brain will still work as it always did if we somehow manage to [[wp:Quantum_entanglement|entangle]] all cell functions at point B with rest of the brain at point A.

We are looking here at a mind that has physically different residences, but it's still only one mind.

If we repeat this for every brain cell, there would be always just one mind at any time, and likewise when 50% is at point A and 50% at point B.

After we completed this special teleportation, we would have no doubt that the person is truly the person that went into the teleporter chamber.

Now let's look at cell growth/death a bit.

There's ongoing speculation on how many cells die every second in the human body. The estimates range from many thousand to a few million.

The important point for us is that the body, and hence brain, is in constant state of change.

Cells divide and die every day, and we don't ask ourselves, "Are we still the same?"

Apparently we are okay with that. Cells die, and some get replaced.

So for the Daodan we can imagine that our brain cells get replaced one by one, so that normal and upgraded cells are always linked.

The mind remains original at any time. We are just changing to different hardware.

'''2b) Does the Daodan changes the personality?'''

The DC enhances the body. It has no other intention.

Probably a change in personality would be caused indirectly.

An aggressive person might outlive his strategy and become more aggressive, because negative consequences would have a smaller impact on him.

'''3) [[#Contamination_of_the_ecosystem|Horizontal gene transfer.]]'''

Why is this something bad? The Daodan gives humans an incredibly huge advantage against all other lifeforms.

If the Daodan's mechanisms are shared by the rest of nature, hyperevolution will take place everywhere, making it harder to adapt again.

While viruses might learn some new tricks, they should remain less potent than a multi-cellular Daodan.

So the actual thread would be bacterial colonies.

====What arguments speak for the Daodan?====
What arguments could someone use in public to advertise the Daodan? 
'''1) regenerate lost limbs, faster wound healing, avoid cancer''' 
'''2) compensate for slow-paced invention cycles''' 
'''3) compensate for a lack of natural selection''' 
'''4) compensate for man's habit of putting himself in dangerous situations'''

'''1) I don't think the first point needs any explanation.'''

'''2) Some events just happen too fast for bureaucracy and standard medical procedures.'''

Without a drastic improvement, there could be never a cure for a new deadly pathogen that can kill within hours.

This is the point that Hasegawa would have had in mind when he tried to find a cure for Jamie's disease.

'''3) Many humans are no longer subject to natural selection, which is good in the short-term but bad in the long-term.'''

In real life, the lack of genetic fitness is somewhat compensated by human's mental fitness, which is expressed in applied science, namely: medicine.

The health care systems (especially in the western world) enable even heavily diseased people to survive and raise children.

So, when people stay alive no matter their genetic fitness level, natural selection can't take place, and diseases continue to remain deadly.

Let's say that HIV isn't treated at all: wouldn't the whole human race die out?

No. For instance, [https://www.sciencedaily.com/releases/2005/03/050325234239.htm every 10th European is naturally immune against HIV.] So if we had a real plague, only the immune people would survive, and in the future HIV would be a far smaller problem.

A historical example of this kind of immunization is the Spanish Flu from 1918, which was the most catastrophic disease in human history so far. The price, immunity, came at the cost of a gigantic mountain of corpses, more than 50 million dead people if you trust the recent estimates.

With human's current knowledge, it's possible the first outbreak couldn't have been prevented, but at least it wouldn't kill good portions of the world population.

With HIV, we are facing a dilemma: either we keep everybody alive, at the cost of a reduced lifespan, a weakened immune systems, social restrictions, discrimination, etc. or we let natural selection happen for the population's sake, so gaining immunity. Both options are unacceptable for us humans as emotional beings. We seek better solutions, but for some reasons we have failed so far.

'''4) Humans often act unwisely.'''

At this point we could simply link to some "fail compilations" on YouTube. (Or if you prefer parodies, check out this German classic, "[[wp:Forklift_Driver_Klaus_%E2%80%93_The_First_Day_on_the_Job|Forklift Driver Klaus]]".)

But there's also the more serious category of failing: ''systematically'' e.g. when a society does it as a whole.

For instance, in many states, antibiotics are overused. It's against one's better judgment, but our greed for money makes it easy to ignore dangers that occur in a delayed manner.

We use antibiotics too often, to keep ourselves and the livestock healthy. That puts bacteria under [[wp:Evolutionary pressure|evolutionary pressure]]. There are concerns that more ''[[wp:Antimicrobial resistance|super bugs]]'' will emerge. These multi-drug-resistant bacteria can't be easily killed. The media-popular MRSA strain residing in hospitals is one such danger.

Scientists try to come up with methods to reuse old antibiotics, or find new ones. However, it can be assumed that the bacteria will also adapt to the new inventions. It's a never-ending arms race.

An alternative to antibiotics are bacteriophages, or, for short, phages. Russia and Georgia officially use these bacteria-eating viruses in some [[wp:Phage_therapy|therapies]]. Usually viruses adapt even faster than bacteria, but so-called [http://archive.is/nmXYy mutators] can win a biological arms race against phages.


If we imagine that all antibiotics will become useless, we would have no choice but to make massive use of phages, which again causes further adaptations inside the super bugs.

===Attempted explanation of the biological dimension===
{| class="wikitable" width="100%"
|
[[Image:Daodan-Chrysalis_2012_in_a_nutshell.png|right|thumb|Daodan-Chrysalis in a nutshell]]

[[Image:Daodan-Chrysalis_at_work_draft_vectors.svg|right|thumb|Oni cluster cell]]
[[Image:Daodan-Chrysalis_modes_vectors.svg|right|thumb|Daodan modes]]

: Finally wrote some “technobabble” lines that seem to provide a solid basis but also allow different interpretations. [[User:Paradox-01|Paradox-01]] 18:28, 9 July 2010 (UTC)

The Daodan Chrysalis (for short, Daodan) always produces mutations that are really needed. That's the only way that the same source of damage won't be dangerous again in the future.

Thus the type of damage must be analyzed, and therefore the Daodan requires a sensor system.

In nature, "higher lifeforms" evolved by following – among other concepts – specialization and socialization. Those find their expression on one hand in different cell types – therefore a multicellular organism – and on the other hand in all kinds of symbiosis. So, for a hyperevolved organism, it would be understandable if it worked more intensely by those same concepts.

A body recognizes damage or harmful influences through stimuli. To detect all kinds of stimuli, much space is surely needed.

Ninety percent of the cells that can be found on and inside the human body aren't its own, but belong to microorganisms. Fortunately they weigh only a half up to one kilogram. They're collectively known as human flora. Depending on the organism, one might be a ''[[wp:Squatting|squatter]]'' (in the metaphorical sense) against real health-threatening germs, and another might hold an actual ability like [[wp:Vitamin_K|vitamin K production]].

Some abilities can't be simply or sufficiently integrated directly into an organism, but a product can be received from a symbiont.

So the Daodan seems likely to enlist microorganisms for additional sensory tasks and abilities which are actually alien to the human. For this reason, the Daodan needs to upgrade the genomes of all the microorganisms [[wp:Microbiome|(microbiome)]] as well.

Next, communication between the symbionts has to be ensured. A new cell organelle might do the job by using messenger substances. Or it transmits different electromagnetic waves which don't seem too alien in comparison to the real bioelectric field of each living organism; this could explain the Daodan glow. (Some metabolic waste products – which are released through the body's surface together with perspiration – might become stimulated to glow by the field.)

For processing the received information, the Daodan might use its own ''self-awareness'', mainly a (genetic and) anatomic model of itself formed by another organelle type inside every daodanized cell. The presence of such an organelle in neurons opens up the possibility for – as geyser coined it – “schizophrenia of the 3rd kind”, but also Kerr's idea of a mental interface which allows influence on the Daodan's development by the host's personality.

If we want to know more about the decision-making algorithms (and their physical structures) which calculate the mutations, we will need to ask Hasegawa. ;-)

Depending on the target – human Daodan genome, Daodan microbiome, both their epigenomes, or even organelle genomes (like mitochondria and plastids have) – a few different “vectors” (e.g. viruses) need to be available to transport the mutation. (For ease of discussion, one might wish to use the terms holobiont -- the collective symbionts, and hologenome -- the sum of the symbionts' genomes.)

However, it's hard to believe that the Daodan would be able to come up with fitting mutations completely by its own. It seems more likely to me that it draws on “genetic building blocks” holding basic information for fast regeneration, resistances, different metabolisms, and so on. Maybe the Daodan can also make use of already existing genetic material of the microbes: after all, a human just has 23,000 genes (500,000 up to 1,000,000 proteins through alternative splicing), while his microbiome has more than [https://web.archive.org/web/20200711115107/https://www.hsph.harvard.edu/news/press-releases/human-microbiome-project/ 5 million] genes/proteins.

The microbiome is very different among humans and would surely make the Daodan's mass production no easy task. But after more than 15 years, the Syndicate should have accomplished a way to simplify the process. This second generation would be independent from the host's sex (XX / YX chromosomes) and the microbiome's composition by providing level-zero stem cells. These can target any compatible symbiont cell and then do a “configuration” (whereby they dissolve the unnecessary genetic material) to become ''classic'' daodanized stem cells and microbes.

{{divhide|German translation ...}}
'''Erklärungsversuch der biologischen Dimension'''

: Endlich ein paar Zeilen „Techno-Gequatsche“, die eine solide Basis versprechen aber auch Raum für Interpretation lassen. [[User:Paradox-01|Paradox-01]] 18:28, 9 July 2010 (UTC)

Die Daodan-Chrysalis (kurz: Daodan) produziert immer die Mutationen, die auch benötigten werden. Nur So kann die gleiche Schadensquelle in Zukunft ausgeschlossen werden.

Also wird die Art des Schadens analysiert und somit benötigt die Daodan auch ein sensorisches System.

In der Natur entstand „höheres Leben“ – unter anderen Konzepten – Spezialisierung und Sozialisierung folgend. Sie finden Ausdruck einerseits in verschiedenen Zelltypen – daher mehrzelligen Organismen – und andererseits in den unterschiedlichsten Symbioseformen. Für einen hyperentwickelten Organismus ist es daher vorstellbar, dass er diese Konzepte verstärkt umsetzt.

Der Körper nimmt Schaden oder schädliche Einflüsse durch Reize wahr. Um alle Reizarten detektieren zu können, ist sicherlich viel Platz nötig.

Neunzig Prozent aller Zellen, die man an und im menschlichen Körper finden kann, sind nicht seine eigenen aber die von Mikroorganismen. Diese werden in ihrer Gesamtheit Normalflora genannt.
Abhängig vom jeweiligen Mikroorganismus kann er beispielsweise „Platzbesetzer“ gegenüber einem wirklich schädlichen Keim sein oder er kann ein echte Fähigkeit haben wie die Produktion von Vitamin K.

Manche Fähigkeiten lassen sich nicht so einfach oder nur unzureichend in einen Organismus integrieren. Ihr Produkt kann aber durch einen Symbiosepartner geliefert werden.

Es ist also naheliegend die Mikroorganismen für weitere Sensorik und eigentlich humanfremde Fähigkeiten heranzuziehen. Aus diesem Grund muss die Daodan auch die Genome der Mikroorganismen (Mirobiom) aufrüsten.

Als nächstes muss Kommunikation zwischen den Symbiosepartner sichergestellt werden. Ein neues Zellorganell in jeder Daodanzelle könnte vielleicht über Botenstoffe dem Rechnung tragen. Oder es sendet verschiedene elektromagnetische Wellen aus, deren Existenz gegenüber dem bioelektrischen Feld eines jeden lebenden Organismus als nicht zu weit hergeholt erscheinen mag und ein Erklärungsansatz für die Daodan-Aura bieten würde. (Einige Stoffwechselabfallprodukte, die über die Haut mit dem Schweiß abgegeben werden, könnten in dem Feld zum leuchten angeregt werden.)

Bei der Verarbeitung der Informationen könnte sich die Daodan einem eigenen „Selbstbewusstsein“ bedienen. Dies wäre zum großem Teil ein (genetisches und) anatomisches Model ihrer selbst, welches sich durch einen weiteren Zellorganelltyp manifestiert. Die Präsenz dieses zweiten Organells in Neuronen ließe die Möglichkeit einer – wie geyser es nannte - „Schizophrenie der 3ten Art“ zu aber auch Kerr's Idee einer mentalen Schnittstelle und somit Einflussnahme auf die Entwicklung der Daodan durch die Persönlichkeit des menschlichen Wirts.

Für die genauen Entscheidungsalgorithmen und ihrer physischen Strukturen zur Mutationsfindung müssten wir wohl Hasegawa fragen. ;-)

Abhängig vom Ziel – menschliches Genom, Mikrobiom, ihrer beider Epigenome, oder sogar Organell-Genome (wie Mitochondrien und Plastiden sie haben) – müssen ein paar unterschiedliche "Vektoren" (unter anderem Viren) verfügbar sein um die Mutation zu transportieren. (Um Diskussionen zu vereinfachen, mag man vielleicht auf den Begriff Holobiont, Gesammtheit aller Symbionten, und Hologenom, Gesamtheit aller Symbionten-Genome, zurückgreifen.

Trotzdem ist es schwer zu glauben, dass die Daodan vollkommen alleine im Stande wäre passende Mutationen zu erzeugen. Es ist vielleicht glaubwürdiger, wenn die Daodan auf „genetische Bausteine“ zurückgreift, die Basisinformationen für schnelle Regeneration, Resistenzen, unterschiedliche Stoffwechsel, und so weiter enthalten. Vielleicht kann die Chrysalis auch bereits existierendes mikrobisches Genmaterial verwenden: ein Mensch hat immerhin 23 000 Gene (500 000 bis 1 000 000 Proteine durch alternatives Splißen) aber sein Mikrobiom hat mehr als 5 Millionen Gene/Proteine.

Das Mikrobiom ist von Menschen zu Mensch sehr unterschiedlich und würde die Daodan-Massenproduktion sicherlich nicht einfacher machen. Aber nach mehr als 15 weiteren Jahren sollte das Syndikat eine Weg gefunden haben den Herstellungsprozess zu vereinfachen. Diese zweite Generation würde durch sogenannte Level-Null-Stammzellen unabhängig vom Geschlecht des Wirts und der Zusammensetzung des Mikrobiom sein. Diese Zellen würden jede kompatible Symbiontenzelle zum Ziel haben und nach einer "Konfiguration" (in welcher sie überflüssiges genetisches Material auflösen) zu klassischen Stammzellen und Mikroben werden.
{{divhide|end}}
|}

====Biologische und memetische Unsterblichkeit====
Als verantwortungsvolle und kompetente AGI stellte Avatara in seiner Analyse zuerst '''Hasegawa's Motivation''' fest, um sich der Projektziele zu versichern. Es soll der Tod eines Menschen durch jegliche Umwelteinflüsse verhindert werden. Im Endeffekt läuft das auf eine biologische und memetische Unsterblichkeit hinaus. Für diesen Zweck muss die Daodan-Chrysalis den Holobionten (sich selbst und den Wirtskörper) '''nach einer Schadensanalyse und Anpassungsphase gegen alles immun''' machen, was auf zellulärer Ebene den Körper schädigt. Dabei stellen sich ein paar fundamentale Fragen:
* '''Wie kann der Tod des Körpers verhindert werden, wenn nicht genügend Zeit für eine Anpassung bleibt?'''
* '''Wie wird sichergestellt, dass der wesentliche Teil des Organismus - seine Erinnerungen und Persönlichkeit - erhalten bleibt?'''
* '''Wie bleibt die Persönlichkeit erhalten, wenn Mutationen die Neuronen beeinflussen?''' (13_65_35 Kerr: "You are who you have always been. The Chrysalis can't change that. The effect of '''the mutation is influenced by the subject's nature'''.")

Sowohl die allgemeinen Anpassungen, als auch mögliche Reanimationssysteme dürfen die Persönlichkeit nicht (zu stark) verändern und wiederherstellen können.

Avatara: System A. Einfrierungs- und Auftauversuche an biologischem Gewebe zeigen, dass wasserhaltige Medien Zellen und neuronale Strukturen durch Expansion und Kristallbildung zerstören. Prinzipiell sind Konservierungsmittel auf Öl- oder [[wp:Wood_frog#Cold_tolerance|Zuckerbasis]] denkbar, doch ohne externe Hilfe wird der memetische Tod nur für kurze Zeit hinausgezögert. Zudem kann eine Neurodegeneration auch durch Strahlung und Toxine ausgelöst werden. Für noch schwache Symbionten ist daher eine robustere Konservierungsart erforderlich. Wenn das Absterben der Gedächtniszellen nicht verhindert werden kann, müssen diese zumindest wiederhergestellt werden können. Lösung: In einem Notfall werden die modifizierten Gliazellen und die extrazelluläre Matrix spontan aufgelöst und bilden eine aushärtende Substanz. Diese Negativform kann später von der autonomen Chrysaliszellen besetzt werden. Die Level-Zero-Stammzellen differenzieren aus und neue Synapsen werden entsprechend den alten Bahnen gebildet. Durch den analogen (nicht-virtuellen und "stufenlosen") Aufbau sind keine Berechnungen für die Strukturwiederherstellung notwendig. Es werden "nur" für die Schadensanalyse und genetische Adaption Rechenkapazitäten benötigt, die die autonomen Chrysaliszellen bereitstellen. Falls die reguläre Atmung ausfällt, wird eine [[wp:de:Trachee_(Wirbellose)|Tracheenatmung]] aktiviert und der Stoffwechsel wird extrem verlangsamt. Dementsprechend kann die Regeneration länger dauern, sofern der Wirt nicht vorher von der Umwelt endgültig getötet wird. Die primäre chemische Energieversorgung wird in zwei Phasen unterteilt. Zunächst werden in der "statischen Metamorphose" alle Zucker und Fettreserven verwertet. Im Zuge der vermutlich notwendigen Autophagie werden auch Muskelproteine abgebaut. Da vermutlich auch das nicht ausreicht, werden anschließend biologische Energieträger gesucht. Insbesondere wird nach pflanzlicher Nahrung über ein Pilzgeflecht Ausschau gehalten. Eine Vielzahl alternativer Energieversorgungen stehen genetisch zu Verfügung. Nachdem die "Protoversion" von extrazelluläre Matrix, Synapsen, Neuronen und Gliazellen in Position ist, wird ein elektrischer Schock ausgelöst, der die Stoffwechsel der Zellen aktiviert, die End-Ausdifferenzierung der wiederhergestellten Zellen auslöst und die Atmung wieder startet. Nach einer Tiefschlafphase erwacht der Wirt wieder zu neuem Leben. ''Der Imago entsteigt seiner Chrysalis.''

System B: Basierend auf den Oni-Compute-Cores könnten farbkodierte Bits hocheffizient für Positionsdaten gespeichert werden. Der Bioquantencomputer errechnet später wieder das räumliche Modell, um die Regeneration einzuleiten. Die Hauptherausforderung besteht im Lesen der Originalstruktur. [...]

====Sytropin====
How did Konoko get her [[Quotes/Speech#Outro_4|sub-dermal transmitter]] implanted if surgery fails on her? Obviously the TCTF did it before or little time after the Daodan implantation. In case the Daodan was already in place how could the transmitter be successfully transplanted? The transformation takes time and regeneration potential becomes stronger when more Daodan cells are presented.

The [[Quotes/Consoles#Sytropin|Sytropin]] is supposed to slow down the growth of Daodan biomass by supporting the original cells. Griffin wanted to delay the transformation giving the sci more time for research and GATC Z the time to find and kill Muro should they be unable to extract him.

The Daodan has a slow growth on its own. When it grows then it is because it reacted on negative stimuli so Sytropin has no effect on it. The mentioned drug resistance refers to the original cells.

'''Food control'''

The accelerated growth caused fever and pain. The staff put Mai on a special diet so she would grow with normal speed again. Her food has low caloric values, roughage and appetite suppressants.

====The Daodan computer====
{| class="wikitable" width="100%"
|
The Daodan's ability to produce non-random mutations doesn't exist in nature. So, its purposefulness should be the result of something man-made, probably some kind of computer. As the computation must happen in biological tissue carbon-based building blocks (micro diamond, graphene, CNT) seem to be a very appealing solution. On this planet carbon sources are ubiquitous, carbon could be even acquired any organic compounds or by filtering and processing CO2 from air. Getting a sufficient amount of carbon by breathing and eating food (sugars, fats, proteins) shouldn't be a problem at all.

[https://phys.org/news/2017-07-high-density-clusters-aligned-quantum-sensors.html NV-centers] can not only compute they can also be used for miniaturized [[wp:Nuclear_magnetic_resonance_spectroscopy|NMR spectroscopy]].

Hasegawa: "Did you know that bacteria can use their own cell as 'eyeball'? Rather a rudimentary way of seeing. But I will use that idea of an micro-eye. Onis that see. Onis that decide. Onis that take care..."

Kerr: "Oni clusters... Hordes of little monsters. Sounds spooky."


{{divhide|German translation ...}}
Die Fähigkeit der Daodan nicht zufällige Mutationen zu produzieren gibt es in der Natur nicht. Ihre Zielstrebigkeit müsste also das Ergebnis von etwas Menschengemachtem sein, wahrscheinlich irgendeine Art Computer. Da alle Berechnungen in lebenden Gewebe erfolgen müssen, scheinen kohlenstoffbasierte Bauteile (Mikodiamanten, Graphen, [[wp:DE:Kohlenstoffnanoröhre|CNT]]) eine elegante Lösung zu sein. Kohlenstoff ist auf diesem Planeten allgegenwärtig, sei es als Bestandteil der Luft oder in alle organischen Verbindungen. Genügend Kohlenstoff über Atmung und Nahrung (Zucker, Fett, Proteine) sollte überhaupt kein Problem darstellen.

[[wp:DE:Stickstoff-Fehlstellen-Zentrum|Diamanten mit NVZ]] können nicht nur für Rechenoperationen genutzt werden sonder auch für NMR-Spektroskopie.

Hasegawa: "Wusstest du, dass manche Bakterien ihre eigene Zelle aus 'Auge' verwenden? Eher eine rudimentäre Art des Sehens aber ich werde das Prinzip dieses Mikroauges aufgreifen. Onis die sehen, Onis die entscheiden, Onis die beschützten..."

Kerr: "Oni Cluster... Horden kleiner Monster. Klingt gruselig wenn du mich fragst."
{{divhide|end}}
|}

====Green Village report extract====
The scale and complexity of the Daodan project outclass everything we know about sythethic biology and related fields. Doctor Kerr stated the Syndicate provided necessary infrastructure to run their experiments. However, he wasn't able to give details what hardware their host possessed. We estimate the Daodan is impossible with current technology to reproduce. The required computing power is so aburd high that hypotetically spoken it is the product of 50 years time travel. Yet, it exists. At least Kerr said that the Syndicate don't normally possess such resources which is a real relief to us and our WCG oversight. It seems a key puzzle piece is the absence of Doctor Pensatore.

- Research directors [[:Image:TXMPCALIG.jpg|Li Rongzhen, Shen Aiying, Zhu Zhongying]]

====Arguments for an ''in vitro Daodan''====
: [[Quotes/Speech#Scanner_room|13_65_27 Kerr]]: "[...] We had never intended to implant those Chrysalises. [...]"
Why would they build prototypes when they weren't going to use them?

It can be argued that these prototypes were meant for [[wp:In_vitro|in vitro experiments]], not in vivo.

: If the Daodan project was intended as a tool to treat human cells in test tubes, miniaturization could lead to portable devices used in cases of emergency.

: Probably you would insert a few cells to daodanize and replicate them, then expose it to doses of negative stimuli such as toxins, and grow adapted tissue or organs. Before transplanting the daodanized cells, their ability to adapt and hyper-regenerate would be turned off. Then it would be like bioprinting (a.k.a. [[wp:Tissue_engineering|tissue engineering]]) with normal cells.

: However, the question remains why Konoko's and Muro's DNA was used for the prototypes.

:* During life, mutations accumulate inside the genetic and epigenetic code. The codes of children are less mutated, hence need less repair; also, the telomeres are longer.
:* There's no need to draw attention to an illegal project by asking other parents for tissue samples from their children.
:* If Hasegawa and Kerr repeatedly needed new samples, they would have Muro and Mai as their source, without asking anyone else from the outside.

:Although there are points to support an "in vitro" scenario, the WCG could easily spread doubts about such a Daodan to an audience which lacks the technical background -- which would be pretty much everyone.

====Arguments for an ''in vivo Daodan''====
:13_65_35 Kerr: "[...] The effect of the mutation is influenced by the subject's nature."

A "Daodan in a box" could never be influenced by someone's personality.

If a human hand or foot gets heavily wounded, after regeneration it might be crippled. While Axolotl salamanders are much better in restoring their extremities, they can't regenerate everything. Only more primitive lifeforms can fully regenerate from portions of their body as [[wp:Planarian|Planarians]] do.

So for an accurate regeneration of the complex human body, the Daodan needs its own ''self-awareness'', mainly a genetic and anatomical model of itself, as already written in the [[#Attempted explanation of the biological dimension|explanation attempt]] section. The processing cell organelles in neurons open a little door so that the Daodan can get influenced. This might be the reason for Kerr's "wishful thinking".

The only way Hasegawa could have discovered this possible side effect is an entire-brain simulation with Daodan cells.

But why should they have done that? A complete brain simulation seems less necessary if they were just aiming for an ''in vitro Daodan''.

Speaking of injuries, the brain can also be injured, and these injuries can not only be life-threatening but also alter the way someone feel, remember and think. Hasegawa could have run simulations to see how well tissue and memories would be restored. In doing so, he might have accidentally discovered circumstances where the neuronal activities led to novel interactions with the Daodan organelles.

For an in vitro solution they had also thought about wiring Daodan biomass to an SLD brain but that would had falsified the results.

Hasegawa hasn't forgotten that in silico and in vitro science brought Jamie into the grave. Due to the complexity of the Daodan, at least one male and one female prototype had to be tested in vivo before they could be sure the Daodan worked as it should. The Daodan mustn't become as disastrous as the mycorrhiza. Hasegawa and Mukade realized that they had to sacrifice at least one child to accomplish their goals. Kerr had a too soft personality to bear this. Hasegawa told Kerr only a minimum about the Daodan's final test results.

Hasegawa wanted to produce more prototypes but the Syndicate got impatient. They decided to continue the research at a more secure place and forced Muro's Daodan implantation. 

====Novel methods of genetic protection?====
{| class="wikitable" width="100%"
|
One idea is to keep the genetic code of Daodan and natural organisms separated: if the Daodan uses another backbone for its base pairs, then perhaps viruses wouldn't be able to incorporate their code for reasons of incompatibility. For instance, [[wp:Peptide_nucleic_acid|PNA]] has another type of backbone. But experiments showed that long PNA strains [[wp:de:Synthetische_Biologie#Ein_neues_Rückgrat|aren't stable.]] I don't know if there are other alternatives. Furthermore, there are other dangerous substances like toxins so I will bet on an analyzing element. In 2012 scientist succeeded in simplifying the identification of [https://phys.org/news/2012-07-scientists-fingerprint-nanoscale-viruses.html nanosized objects]. A minimized version of this device would be an ideal sensor for the Daodan.

{{divhide|German translation ...}}
Eine Idee ist es den genetischen Code von Daodan und natürlichen Organismen getrenntzuhalten: Wenn die Daodan ein anderes Rückrat für ihre Basenpaare verwendet, dann könnten aus Gründen der Kompatibilität Vieren vielleicht nicht mehr in der Lage sein ihren Code einzuschleusen. Zum Beispiel hat [[wp:Peptide_nucleic_acid|PNA]] ein verändertes Rückrat. Jedoch zeigten Experimente, dass lange PNA-Stränge [[wp:de:Synthetische_Biologie#Ein_neues_Rückgrat|nicht stabil]] sind. Ich weiß nicht ob es weitere Alternativen gibt. Außerdem gibt es noch andere gefährliche Substanzen wie etwa Gifte sodass ich die Chancen für ein analisierendes Elemet höher einschätze. 2012 ist es Wissenschaftlern gelungen die [https://phys.org/news/2012-07-scientists-fingerprint-nanoscale-viruses.html Erkennung von Objekten auf der Nanoebene] zu vereinfachen. Eine Miniaturversion des Gerätes würde ein idealer Sensor für die Daodan sein.
{{divhide|end}}
|}

XNA to be added here.

====Factors for a higher performance====
'''Higher energy consumption'''

Developing Daodan host will be very hungry. (Anime cliché: strong characters are always hungry - e.g. Son Goku from Dragon Ball, Ruffy from One Piece, ...) Beside food consumption, Daodan hosts also have tracheae to absorb additional oxygen. These tracheae are even more important for [[#Transformation:_static_metamorphosis|static metamorphosis]].

'''Polyploidy'''

A genome can consist of many chromosomes. If all its chromosomes are unique, then the chromosome set is haploid. A genome of two sets is diploid, a tripled set make it triploid, and so on.

So polyploid means "having many chromosome sets".

Polyploidy can result in higher vitality. It can raise the rates of protein biosynthesis due to stronger parallelization of the processes. An already historic example can be seen in wheat. Humans bred wheat in a way that repeatedly doubled the plant's chromosome set to harvest more and bigger grains. Now wheat has 6 sets (hexaploid), each containing 7 chromosomes.


'''Problem'''

Humans with too many chromosome copies often die before or shortly after birth, or suffer diseases. A non-lethal disease is Down syndrome, which comes from a third copy of the 21st chromosome, hence it's also called trisomy-21.

This shows us that simply multiplying chromosomes for a performance boost won't work.

'''Solution'''

Despite the fact that most human cells have a diploid genome, there are also cell types that are naturally polyploid. For instance, this is true for heart muscle cells, liver cells and [[wp:Megakaryocyte#Development|megakaryoblasts]] (blood-forming cells).

Healthy collections of multiple sets might be attributable to ''deactivations''.

Example of single-chromosome deactivation: in women, one of the X chromosomes is epigenetically deactivated. That way, men (XY) and women (XX) have both only one active X chromosome, and hence they produce nearly the same doses of products from the X chromosome(s).

Example of general deactivations: epigenetic processes like DNA-methylation generate different cell types despite the genetic code being the same in all cells.

If Daodan cells are polyploid, then they would have to deactivate unneeded regions of the other sets. However, imposing realistic standards, I think that polyploidy could be never the only reason for the marvelous regeneration skill of Oni's hypothetical Daodan.

'''The big clean-up'''

When Avatara designed the new Daodan genomes it restructured the chromosomes and removed non-functional viral remnants that had accumulated during human evolution.

====Transformation: control and power====
Is Muro's transformation irreversible? Before he transformed, he said, "You are capable of so much more. Let me show you..." This implies that he has some control over his transformation; how much is not known.
: A) He was able to delay the final transformation and triggered it later by will.
: B) That of A, plus more control so he can even untransform.

"Let me show you..." can be interpreted that he already knew how radical his change of appearance would be: he stands before Mai as a normal-looking man, and hence this could be a hint that he's able to revert the transformation.

The speed of his growth can be seen as another hint for the validity of option B. TCTF staff tried to avoid Daodan power bursts by instructing Konoko not to tackle things too forcefully, and they even gave her Sytropin to slow down Daodan growth. But over a few days of combat, Mai's Daodan developed rapidly nonetheless. For Muro, we can assume years of real combat experience....

From a practical point of view, he should be able to untransform because of the following reasons.

:- psychological / social reason: he was only familiar with his human appearance (it could be more ''comfortable''; he probably had the wish to stay human before he became used to it) / identity of and repect for a strong leader, fear of the Strikers having a real monster as boss (by reverting the transformation, Muro could have given the Strikers time to get used to him, and showed them that he wouldn't represent a one-way ticket to ''monstrosity'', but to a ''superior being''.)
:- physiological reason: ergonomics - weapons, cars, mobile phones, door frames, seats, etc. are all made in human dimensions... wouldn't it be stressful to walk through the land of man as a giant and trying not to accidentally destroy everything?
:- energy / resource: combat or active Imago skills probably use a lot of chemically-bound energy. A human-like form could be a kind of ''energy saver mode''.

It looks like the Imago stage was thought to have unlimited energy, and Mai was just lucky Muro transformed right before their fight.

: ''[[Quotes/Objectives#CHAPTER_14_._DAWN_OF_THE_CHRYSALIS|(...)]] Muro has achieved the next level of Daodan evolution: the Imago stage. Muro's Daodan powers make him invulnerable, but having only just evolved he has limited energy reserves. You can hurt him when his energy is drained.''

Infinite energy:
* To be honest I don't at all like the idea of unlimited energy. I'm rather fond of realism and would like to keep the laws of nature. Especially the law of the [[wp:Conservation_of_energy|conservation of energy]] and the [[wp:Conservation_of_mass|conservation of matter]]. Energy and matter cannot be created from nothing and cannot vanish to nothing.
* You could say that the Daodan also draws energy from another dimension, and instead of ''infinite'' energy there's just more energy available than the DC can use. But still, if it can be utilized as a ''normal'' energy source, you might get weapons that can easily erase Imagos.

====Overpower mode====
When Daodan prototypes grow, they express [[wp:Green_fluorescent_protein#GFP_derivatives|fluorescent proteins.]]
These proteins are used to distinguish the Daodan biomass from the original cells and help measure cell metabolism, which is typically high when the Daodan grows or regenerates (ref. Daodan spikes). The proteins can glow under two conditions: either they are exposed to radiation, which Kerr did in the TCTF lab, or in the presence of high amounts of ATP. Hypospray substances trigger the release of ATP no matter wheather the Daodan is already healed. That way, hyposprays lead to overpower mode.

For the final version of the Daodan, it would make sense to not generate any glow since that is a waste of energy.

: On the other hand, [https://phys.org/news/2016-08-dna-naturally-fluoresces.html DNA has been found to possess natural occurring fluorescence.] So even if the markers of the prototypes are removed you can make a Daodan make glow. This would be interesting as a method for non-verbal communication or - more mundane - providing a light source for long trips in dark environments. -- Let's be honest: Daodan without Daodan aura is less cool and less anime-ish.

Anyway, radiation and hyposprays can theoretically be abused to drive the Daodan's metabolism so high that it releases all its energy resources in a short time and dies of starvation (if it doesn't go into a hibernation mode). (ref. Oni3: Konoko awakens from her [[Oni2:A Storyline#Mai|coma]]. Maybe she had to fight a long time in overpower mode or suffered an emotionally-triggered ATP release...)

While the '''Daodan aura''' (a.k.a. chenille) simply indicates a very active metabolism, '''[[Daodan#Power surges|Daodan spikes]]''' might come from the sudden ''implementation'' of a new adaptation within the whole Daodan biomass.

====Transformation: static metamorphosis====
{| class="wikitable" width="100%"
|
:(Some text that might be from a researcher's diary.)

: ''The name still ''bugs'' us.''

:''All skills aside, the Daodan is still bound to the laws of nature; it's not almighty. Extreme changes of the body in a short time probably require a static state.''
:''In that respect, we might translate the full name "Daodan Chrysalis" as "code allowing metamorphoses to reach new states, each best adapted to the newly present environmental conditions" whereas "Chrysalis" could be also almost literally be taken as "Chrysalis" [pupal stage of butterflies]. In this case, we think it's some biological material on the body's surface that provides shelter and stability so a major metamorphosis can take place.''
: ''We think that this second ability might exist still hidden inside the code. Single, fast adaptations have been reported; the existence of complete, static transformations still needs to become proofed.''

----

Solid Chrysalis tissue grows with static metamorphosis. Imagos can also utilize that graphene-based protection. However it's more flexible and uses electric energy to increase strength. Basically, AVATARA ported the graphene shield technology to an all-bio framework making Daodan host also more resistant to physical dangers. Muro experienced so often static metamorphosis that the shield code became part of his Imago form. - Breathing continues through tracheae (fine ''pipes'' that transport air from skin to the interior areas). Since the tracheae aren't very effective, metabolism is slowed down and the developing organism appears lifeless. In extreme conditions, e.g. when buried, the Daodan can switch to [[wp:Anaerobic_respiration|anaerobic respiration]]. These pathways are either acquired from existing symbiotic species in the human flora or the Daodan reach out to species that lives nearby in the ground. (This holds also a possible chance to utilize Bioc organelles/structures to get energy. It should help Daya's effort to establish a three-way symbiosis.)

{{divhide|German translation ...}}
'''Statische Metamorphose'''
: (Ein paar Zeilen, die aus einem Tagebuch eines GV-Wissenschaftler stammen könnten.)

: ''Der Name gibt uns immer noch zu denken.''

: ''Trotz allen Fähigkeiten ist auch die Daodan an die Naturgesetze gebunden und nicht allmächtig. Extreme Umbauten des Körper in kurzer Zeit benötigen wahrscheinlich einen Ruhezustand.''
: ''Bis jetzt übersetzen wir den vollen Namen "Daodan-Chrysalis" als "Code, der Metamorphosen erlaubt um neue Zustände zu erreichen, die jeweils am besten an die dann vorherrschenden Umweltbedingungen angepasst sind".''
: ''Wegen der wahrscheinlich Ruhephase könnte "Chrysalis" vielleicht auch wortwörtlich verstanden werden sofern die Metamorphose ein biologisches Material aus Gründen der Stabilität und des Schutzes um die Körperoberfläche schafft.''
: ''Wir denken, dass sich diese zweite Fähigkeit noch im unverstandenen Code verstecken könnte. Einzelne, schnelle Anpassungen wurden beobachtet. Die Existenz von tiefgreifenden, Ruhe benötigen Metamorphosen will noch gefunden werden.''
{{divhide|end}}
|}

====Chenille====
Code name for Daodan's natural cell reinforcement and graphene shield as reaction to intense physical and psychical stress. The production of graphene flakes starts right after completion of Imago state (when body is fully daodanized) by modified carboxysomes. In immature (or "pre-Imago") state overfluent ATP activates fluorescence. Otherwise the ATP fuels an electromagnetic bonding mechanism. (Super shield.) The color is influence by the host's airborne waste products released through transpiration. The moment of ignition is referred to as Daodan spike.

Avatara experimented with entanglement to transport energy to Muro's and Mai's prototype Daodans. But due to the lack of entanglement regeneration the Daodan is depending on its own resources. As temporary solution he also thought of ATP transfer between hosts - fitting the concept of Symbiosis once again - but couldn't finish code in time.

BGI developed suits that draw their energy for nano-electronics from the body's ATP resources. The first models were very energy hungry which made them think about how to add back ATP. They soon thought of the human body as a recharging battery. It was the first step into making food sources obsolete. Pensatore completed that idea within the Omega Chimera and an omni-present Bioc power grid.

An daodan host would greatly profit from such a suit. Muro is probably using such ATP recharger device to compensate his shortening telomeres.

Yorick's skirmish with the memhunter leads to a new form of Imago shield. After absorbing the Oni clusters and energy resources of his dead comrades he is able to compute a natural graphene shields that can undergo other phase transitions. He also uses the gained computing power to tactically cut off the memhunter from his resources and uses them instead. ("Jammer spears", and own "sand layer" that acts as energy parasite, etc.)

Hypershield: When Yorick managed to add entanglement regeneration to his [[wp:Bose–Einstein condensate|BEC]] vessels, his shield became capable of undergoing an even higher grade of phase transition.

====Multiple Imago stages====
{| class="wikitable" width="100%"
|
:(Some text that might be from a researcher's diary.)

:''Some part of the Daodan's code aren't fully understood yet. This and the "Chrysalis group"'s posited hyperevolution makes us start to believe that the Imago stage isn't the "end". Of course, new environmental catastrophes can mean a threat to Imagos, so a new transformation would become necessary. That's why we think that these cycles aren't limited. However, it might be a disadvantage to lose a fully developed adaptation if those conditions returned. A storage system might be involved.''

:''DNA methylation and histone modifications can access the genetic material. For example, a modified gene could be copied and modified, then the old version be ''switched off''. In the course of later events, the Daodan could check its registry to see if there's already a suitable adaptation that can be switched on again. This would avoid the necessity of re-calculating the needed mutations.''

:''A genetic overload cannot be excluded. But that must be solved by future researchers. Our visionary colleague Dr. Sandström (in memory of [[wp:ReGenesis|ReGenesis]]) points to something he calls the "networked Omega Chimera", which makes use of advanced nanotechnology.''

: ''Addendum: After final analysis on xx xx 205x, the suspected ability has turned out to be only our wishful thinking: A storage system for adaptation hasn't been found, but the idea remains a possibility for a future upgrade of the DC.''

{{divhide|German translation ...}}
'''Multiple Imago-Stadien'''
: (Ein paar Zeilen, die aus einem Tagebuch eines GV-Wissenschaftler stammen könnten.)

: ''Einige Stellen des Daodan-Codes sind noch nicht vollständig verstanden. Dies und die Hyperevolutionstheorie der „Chrysalis-Gruppe“ lässt uns vermuten, dass das Imago-Stadium nicht das Ende ist. Natürlich können neue (von ihrer Art her andere) Umweltkatastrophen eine Gefahr für den Imago darstellen. Also würde wieder eine Metamorphose notwendig sein. Aus diesem Grund glauben wir nicht, dass die Metamorphose nur einmal stattfindet.
: ''Auch wäre es unvorteilhaft einen vollständig angepasste Zustandsform zu verlieren wenn dann die Situation plötzlich wieder in alte Bedingungen annimmt. Anpassungen zu suchen, benötigt Zeit. Bereits erfahrende Anpassungen wieder aufzurufen, würden die Überlebenschancen des Imago weiter steigern. Ein Speichersystem könnte sich also noch im Code verstecken.''

: ''Auf neuen Planeten und im Weltraum wäre dies dem Imago sicher hilfreich da er dort großen Temperaturschwankungen ausgesetzt ist wenn ihn der Raumanzug aus irgendwelchen Gründen nicht mehr schützen kann.''

: ''Kandidaten eines Speichersystems könnten DNA-Methylisationen und Histon-Modifikationen sein. Beispielsweise könnte ein Gen kopiert und verändert werde, dann wird seine alte Version ''abgeschaltet''. In einem späteren Ereignis könnte die Daodan ihr Register prüfen ob bereits eine passende Anpassung bereitliegt und diese wieder aktivieren. Dies würde es vermeiden die richtigen Mutationen erneut zu berechnen zu müssen.''
: ''Dass die wachsende Größe das Genom irgendwann überlastet, kann nicht ausgeschlossen werden. Unser visionärer Kollege Dr. Sandström meint, dass dann der Komplex Mensch-Daodan weiterentwickelt werden müsste. Er nennt als ein mögliches Zukunftsmodell „die vernetzte Omega-Chimäre“. Die Archivierung alter Anpassungen würde dann computertechnisch erfolgen.''

: ''Nachtrag: Nach der abschließenden Analyse am xx xx 205x stellte die erwartete Fähigkeit sich als nur als unser Wunschdenken heraus: Ein Speichersystem für Anpassungen wurde nicht gefunden, bleibt aber eine Idee für ein zukünftiges Upgrade der DC.
{{divhide|end}}
|}

====Natural reproduction of human hosts====
{| class="wikitable" width="100%"
|
: [http://web.archive.org/web/20160226222308/http://oni.bungie.org/forum/viewtopic.php?pid=26881 Iritscen's post] on the OCF got me to think about the following problem.

In new environmental conditions, randomly evolved traits help members of a population to survive. The survivors then ensure the population's continuity by their reproduction.

The Daodan reacts directly to environmental influences, and probably – or largely – no longer uses randomness.
Therefore, it's uncertain if the Daodan can manage or allow random recombination of genetic material during the sexual reproduction of Daodan hosts. For the Daodan, there's actually no more need for recombination.

So, if no recombination happens, female gametes (egg cells) might become produced with or without genetic material, whereby only an empty egg cell can accept a male gamete. In any case, the chromosome set is already diploid, which means that the baby is a genetic clone of one of its parents. (But, you know, the personality is still shaped to a major degree by environment and education.) Contact of male hormones with a female gamete (a cell nucleus must be present) marks the cell as fertilized. Implantation and embryonic development follows. The passing on of microbial Daodan symbionts happens during child's birth (...) and by intake of breast milk. ([[wp:Bifidobacterium|Bifidobacteria]] can be taken as kind of RL example).

{{divhide|German translation ...}}
'''Natürliche Fortpflanzung von menschlichen Wirten'''
: [http://web.archive.org/web/20160226222308/http://oni.bungie.org/forum/viewtopic.php?pid=26881 Iritscen's Beitrag] im OCF ließ mich über folgendes Problem nachdenken.

Zufällig hervorgebrachte Merkmale helfen Mitglieder einer Population bei neuen Umweltbedingungen zu überleben. Die Überlebenden sichern den Fortbestand der Population.

Die Daodan reagiert direkt auf Umwelteinflüsse und kennt wahrscheinlich – oder zum großen Teil – keine Zufälligkeiten mehr. Bei der sexuellen Fortpflanzung von Daodan-Trägern ist es daher ungewiss ob die Daodan mit der Rekombination des Erbguts zurechtkommt oder dies zumindest zulässt. Es besteht für die Rekombination eigentlich keine Notwendigkeit mehr.

Wenn keine Rekombination stattfindet, könnten vielleicht weibliche Gameten (Eizellen) mit und ohne Erbgut entstehen, wobei nur die weibliche Gameten ohne Erbgut ein männlichen Gamet aufnehmen. Die Gameten sind also zu Beginn schon diploid. (Sie haben einen doppelten Chromosomensatz, der für gesunde Menschen erforderlich ist). Der Kontakt von männlichen Hormonen qualifiziert die Eizelle zur „Zygote“; es hat also jetzt den Status „befruchtet“. Nidation und embryonelle Entwickung folgt. Die Weitergabe mikrobiellen Daodan-Symbionten findet bei der Geburt statt (...) und mit der Aufnahme in der Muttermilch. (Die Weitergabe von [[wp:De:Bifidobacterium|Bifidobakterien]] könnte man als eine Art Beispiel aus dem echten Leben nennen.)
{{divhide|end}}
|}

Real world parthenogenesis to be added here.

====Contamination of the ecosystem====
{| class="wikitable" width="100%"
|

GV's "Chrysalis" work group thinks that the Daodan will contaminate the environment sooner or later (in case it hasn't already happened) because of [[wp:Horizontal_gene_transfer#Prokaryotes|horizontal gene transfer]] causing unseen threats. Hence the Daodan needs a patch. The idea was and is to protect the prime symbiont, the human host. To ensure that the microbial Daodan cells only stays with the human flora, these cells need to die in the absence of the prime symbiont by dissolving their genetic material with an enhanced lysosome.

<s>(Will [[:Image:Guido - Pandora vs. Mukade.jpg|Pandora]] hunt down all hosts with an original Daodan (to patch them or kill the hosts) ?)

This patch solves only one part of the problem. Existing Daodans would be still a permanent danger, especially the unknown number in Syndicate 'property'. In worst case, this threat would have to be met on a planetary scale. This would require full control over all matter and lifeforms.</s>

Related topic:
* [[#Bioc|bioc]]
* faked Biosafety concerns (TCTF, Konoko)

{{divhide|German translation ...}}
'''Kontamination der Umwelt'''

GV's "Chrysalis"-Arbeitsgruppe hält es für wahrscheinlich, dass die Daodan früher oder später (falls dies nicht schon geschehen ist) die Umwelt kontaminiert: horizontaler Gentransfer könnte noch nie gesehende Gefahren entstehen lassen. Deshalb benötigt die Daodan einen Patch. Die Idee war und ist den Primär-Symbionten, den menschlichen Wirt, zu beschützen. Um sicherzustellen, dass die mikrobischen Daodan-Zellen die Normalflora nicht verlassen, müssen sie in Abwesenheit des Primär-Symbionten absterben wobei ihr genetisches Material durch ein verbessertes Degradosom zerstört wird.

(Wird Pandora angeheuert um alle Original-Daodan-Wirte zu patchen oder zu eliminieren?)

Der Patch löst nur ein Problem. Die bereits existeirenden Daodan-Wirte sind weiterhin einen ständige Bedrohung, besonderst die unbekannte Anzahl an Wirten des Syndikats. Im schlimmsten Fall muss die Gefahr auf planetarer Ebene bekämpft werden. Dies würde aber volle Kontrolle über alle Organismen und Materie voraussetzen. 

Weiterführende Themen: [[#Bioc|Biok]]
{{divhide|end}}
|}

===Daodan self-defense and diagnostics===
What do you need for anti-cancer or anti-mutation tests in a Daodan?

It would have been much easier to create a Daodan with an "on-board genome"* transforming all other human hosts into clones of Muro and Mai - then evolving into genetic individuals again.

Hasegawa discarded this idea to avoid immuno-rejections, social confusion and the losing genetic diversity. Now evolution would be driven by the Daodan but he didn't wanted to act in hybris and lose dormant traits that might proof useful at a later time. His decision was enhanced by his education and political opinion on WCG. Diversity shouldn't be scarified for efficiency, history would show what works and what does not. (Although he was also unsatisfied with randomness being the decider - as also Jamie's dead looked random... "Sometimes there are only bad solutions available.")

* The Syndicate's mass-produced version works more like a collection of patches instead of an OS upgrade.

Meanwhile Pensatore foresees that the host survival doesn't correlate with brain intelligence but the Daodan intelligence. During time, the Daodan would adapt to critical situations by sacrificing brain mass or functionality. The evolutionary weakness of the Daodan is its inability to think but to compute. Pensatore therefor sees mankind's future in the Omega Chimera and the Biocracy. Hasegawa works and Pensatore's critics are much later used to create the Meta-Daodan (symbiont of the actual Daodan).

At least Pensatore and Hasegawa agreed in one thing: independency. GOP was still a "too big" organization. It seemed impossible to them that the WCG would tolerate such ... experiment. With the ultimate technology any individual would be free to live without owning anything else rendering the WCG's promises for security and care-taking obsolete.

Hasegawa's 'bad' solution: Random sampling of cells whereby the statistical mean defines the 'healthy' sequences.
Mutations happen all the time so that the different genomes cannot be taken for an boolean answer.
You rather have to compare the genes and other functional DNA sequences.
Drawback: if the majority of cells is contaminated by a new stable mutation (induced by hostile vectors such as erroneous CRISPR-cas9?) the other cells will be updated by that mutation as well.
This rare case and (fallback 2) database-induced errors have to be resolved by recomputing the sequence in question which needs a static metamorphosis or the accumulated use of all available Oni clusters.

75 percent of random sampling searches for typical cancer markers such as [https://arstechnica.com/science/2017/05/killing-cancer-cells-using-the-dna-that-drives-them/ driver mutations.]

Special cases:

Pendulum syndrome: cycling environmental influences keep the Daodan busy, theoretically not harmful but resource intensive.

Fallback 1: [[wp:Oncolytic_virus|oncolytic viruses]] in case of too high EM interference. In this case static metamorphosis drives skin cells to form an faraday cage.

Fallback 2: an massively attacked Daodan forms a 'fixed' template for healthy cell types. These are then used to create new cells. The random sampling to skipped until the holobiont is stabilized again.

Survived attacks on the fixed template through a static metamorphosis cause the Daodan to go into combat mode (boosting physical strength) as the host might soon get under a new attack and need to defend himself.

====Signal protection and anti-hacking measures====
In the 21st century EM fields are ubiquitous and create an unwanted background noise for the Daodan. Oni clusters encode transmissions in different frequencies simultaneously. The redundant signals are compared so that corrupted pieces can be filtered out.

Daodan technology will attract human attackers so Avatara was tasked to create secure cell communication. An imago has enough Oni clusters to perform [[wp:Post-quantum_cryptography|post-quantum cryptography]] rendering the Daodan immune against remote attacks who also use quantum computers. However, PQC wasn't implemented due to lack of dev time.

====Memory delta patches====
Fullbody simulation revealed that a physical brain can fully heal but memories can be lost forever when the injury was too big.

As consequence Avatara implemented the creation and re-integration of memory delta patches. Daodan hosts have the ability to store a backup of their brain as DNA capsules (main memory chromosomes). The problem is delta patches start forming as soon as brain cells are getting transformed while a full backup (reference for the deltas) is only created when the host reaches Imago stage and Mai's Imago stage remained uncomplete. Full brain backups are highly compressed data structures made possible by the quantum computing Oni cluster cells of Imagos.

However, Mai has another source for a full brain backup. Her first brain scans which were used to create the engrams for Shinatama.

Shinatamas memories are used for a "soft imprinting" (not 1:1 copying), sorting and strengthening the blurry thoughts. (Pushing neural regeneration into the right directions.) After all, Shinatama has seen and heard everything Mai did.

Delta patches can be used on an existing brain to restore a region. If a brain is completely destroyed, the Daodan tries to restore the full backup first and then applies the deltas.

The main backup is supposed to be renewed every year or few years.

New story idea: During RS (and the Phönix wars?) Mai is taken in as soldier and loses her memories during a series of fights. Hitman destroy her with bullets and explosives but she can always regenerate by static metamorphosis. She does not remember Shinatama and turn "evil" at some point. One day Muro pushes her into true imago stage and her memories begin to fully come back.

The life of Mai is a drama. She is the embodiment of risks and chances of future technology. For dramaturgic effect her recovery must have a high cost. (Greek tragedy type 2? The hero doesn't die in the end, he survivied because he already suffered so much, like Odysseus.)

Restoring her memories makes her reject Phönix which results in forming of factions and weakens the organization as a whole. Some of her Phönix friends turn out to be her new, old enemies... She, as another embodiment of the Phönix, lived many lifes; the title Phönix was also hold by Griffin after being revived with a GATC "spare". However, the organization as such repeately used advanced SLD engramm patterning to give her fake memoies when she died once again. They turned her into a weapon and didn't care about her identity and free will.

====Future upgrades====
<s>I don't think this will happen in RS, but in later sequels. It's better to write it down than forgetting it again after a while.</s>
* [[wp:Telomerase|telomere regeneration]]: which allows biological immortality (overpopulation problem appears)
* cyborg genes: construction genes which take care of implants -- nothing special in comparison to our human growth genes -> Omega Chimera

'''Omega Chimera'''

* Omega Chimeras can make use of external memory storage for different Imago stages and also knowledge.
* Long-range objective is to create a collective consciousness (via network) called [[wp:Daimon|Daimon]]. 

===Versions===
While Daodan biomass undergoes hyperevolution it of course gains new abilities. However, lab-created strains got also improvements over time.

'''Daodan v0.99'''
:Prototype (in memory of Neo and his OniSplit v0.99)

'''Daodan v0.99b'''
:Syndicate version for mass-production

'''Daodan v1.0'''
:telomere regeneration, enabled reproduction, PQC
:Konoko, gets this after visiting the lab where Hasegawa worked on the Daodan together with Pensatore and Kimura

'''Daodan v1.1'''
:ATP transfer between Imagos
:Youngsters who are Omegas or Imagos share the same social yet self-destructible behavior. A dare in which the individual converts the ATP or other chemical reserves into electricity showing off a plasma bolt. The one with the biggest or most interesting bold "wins". Theoretically the individual can die in the process if he doesn't reconvert the bolt to the chemical energy reservoir again. Even the attempt can be dangerous. The challenge is to hold back just as much as he needs to show it off and initializing the reconversion. The bolt is literally life force.

On the other hand it is considered a romantic gesture to give away a part of your own "life force" - during marriages energy is exchanged instead of rings.

Once in a year some people in GV spend a bolt on the war memorial, the [[Talk:Restless_Souls/Summary|soul tree]], which then release it again at the same night.

'''Daodan v1.2'''
:cold plasma (disinfection purpose)

'''Daodan v1.3'''
:hot plasma

'''Daodan v2.0'''
: A.k.a. "omega" strain as the likelihood to survive with this version is equally high than that of an Omega Chimera. It's an own life form that observes its host before it merges with it. It is compatible with any other life form as long as it is bigger than a mouse or shrub - the cell number limit to form sensors and computing structures. Trivia: The Arc Crew believes Mai planted one of these on a planet together with the biological remnants of her parent. (Legend of fountain of youth.) After a sudden turn of events she is captured from the MEM fraction and put to stasis (prison) while Avatara is sentenced for exile. Avatara isn't longer commanding the geo-ship, he has his own arguments with the MEM fraction. He uses a trick, he shapeshifts himself into Konoko and vice versa. --- Aons later. Daya finds out that Mai is still out there. They are the figureheads of their planets. - ("Learn to live together, idiots.") They will fight alone, the armies watching in the background. ... Yet, Nishio will rotate in his grave, literally. Dust alone outlasts the civilizations. There's only Zen left for him.

'''Meta-Daodan'''
: An own life form that can go into symbiosis with any other life form. It can have an intellect of human's level and therefore reject a fusion.

===Stunning real world symbioses for inspiration===
The word symbiosis means "living together". Whether the outcomes are good or not is another question. However, in daily life, symbiosis means a relationship of mutual gain.

{| class="wikitable" width="100%"
! symbiosis types by interaction
! symbiosis types by utility
|-
|on metabolic level (e.g. corals; lichens)
|mutualism
|-
| through behavior (e.g. flowering plants + insects, birds; ants + fungi / greenflies)
| parasitism
|-
| on genetic level (e.g. virus + host organism)
| interstages of mutualism and parasitism (commensalism, amensalism, etc.)
|}

The following subsections are meant to show what real symbiosis is capable of and that it exists between very different species. Therefore those sections display combinations of the so-called [[wp:Kingdom_%28biology%29#Six_kingdoms|kingdoms]]. (As a layman I still prefer the older and simpler model.) Unfortunately viruses are unranked so far.

====Virus====

: '''Are viruses lifeforms?'''

: The problem is that they are really neither dead nor alive. They are ''zombies'', so to speak. They do nothing until they infect a suitable host cell and become active again. Living things were thought to always have an active metabolism. Then [[wp:Tardigrade|tardigrades]] were found to break that rule with their cryptobiosis ("hidden life"). In that stage, their metabolism is almost too low for measurement [[wp:Cryptobiosis#Examples|(under 0.01%)]]. After that discovery, scientists had the rethink the definition of death. The microbes' state of temporary ''death'' was defined as a kind of extreme ''hibernation'', namely cryptobiosis, and some Christians were happy that their religion was the sole promise again for resurrection.

: A virus cannot reproduce itself without a host, but that's also true for some endoparasites (parasitic organisms in other organisms). And a virus does not have its own metabolism, but can take over the host's metabolism and organelles. In this view, a virus might be a very mean and clever bastard, but it lives.

: '''From symbiosis to symbiogenesis.'''

: So a virus makes the host its ''own body''; but there also exist symbiotic viruses. These have not taken over a host cell, but sorta vice versa: they became fully incorporated into the host's genome. Two examples: First, the [[wp:Polydnaviriformidae|polydnavirus]] inside of ichneumonid (parasitic) wasps is only produced when the wasps lay eggs in a caterpillar. The virus helps the wasp eggs to survive inside the caterpillar by affecting the immune system and changing the metabolism to the advantage of the wasp eggs. The second example concerns us humans (and all animals with a placenta). The retrovirus [[wp:Syncytin-1|ERVWE1]] in our genome merges placenta cells through its produced protein "syncytin" in order to create a protective layer. That way, the embryo stays untouched by the mother's immune system. Otherwise it could be recognized as a foreign body because of the father's genes. The retrovirus gives us an advantage compared to non-placental mammals.

: The polydnavirus is still reproduced, but the second virus completely gave up its independence. They, the host and the virus, are rather one new organism instead of two. This process of merging organisms is called [[wp:Symbiogenesis|symbiogenesis]].

: '''How much human DNA makes up our body?'''

: Incorporation of outside genetic material happened more than once. When the human genome was [[wp:DNA_sequencing|sequenced]] on a [[wp:Human_Genome_Project|large scale]], only 1.4% was found to encode our ''building material'' - the proteins; the rest appeared to be "junk" DNA. Today we know that 8.5% are old retroviruses (HERVs). -- This brings Agent Smith from the movie Matrix into mind when [https://www.youtube.com/watch?v=JrBdYmStZJ4&t=117s he classified humans as a virus] because of certain similarities: according to him, humans replicated unchecked, consumed all resources, and spread to a new area (host) when another area ran out of resources. Now he would have genetic proof, you might think: our DNA is more "virus" than "human". -- Well, the old retroviruses are almost all defective so they don't matter much. Also, noncoding but function-holding RNA and regulatory sequences - ''tools'' and ''building instructions'' - have been identified from the junk now. So, yes, no need to panic, we are still human enough.

'''Symbiotic [https://phys.org/news/2014-11-natural-gut-viruses-bacterial-cousins.html Virom]'''
More information:
* https://www.spektrum.de/news/wie-viren-unseren-darm-beherrschen/1426006
* http://web.archive.org/web/20210410211029/https://www.akdae.de/Arzneimitteltherapie/AVP/Artikel/201803/149h/index.php
...

====Insect and bacteria====
{| class="wikitable" width="100%"
|
'''Faithful allies since the Cretaceous: Symbiosis between beewolves and protective bacteria originated millions of years ago'''

[...] A particularly fascinating defensive alliance occurs in the European beewolf (Philanthus triangulum), a digger wasp that hunts honeybees and provisions them for its offspring in underground nests. Previous research has shown that bacterial symbionts of the genus [[wp:Streptomyces|Streptomyces]] live in the wasp's antennae and on the larval cocoons. The bacteria produce a cocktail of nine different antibiotics that fend off detrimental fungi and bacteria from infecting the developing larva in the cocoon. This strategy to avoid infections is comparable to the combination prophylaxis used in human medicine.

The scientists now reconstructed the phylogenies of different beewolf species and their symbionts. An analysis of the beewolf phylogeny revealed that the symbiosis with Streptomyces first originated in the late Cretaceous, between 68 and 110 million years ago. At present, about 170 species of wasps live in symbiosis with the protective bacteria. [...]

'''source:''' - https://www.sciencedaily.com/releases/2014/04/140414154450.htm
{{divhide|German translation ...}}

'''Treue Verbündete seit der Kreidezeit: Symbiose zwischen Bienenwölfen und schützenden Bakterien entstand vor Millionen von Jahren'''

Eine besonders faszinierende Verteidigungsallianz trifft man beim europäischen Bienenwolf an (Philanthus triangulum), einer Grabwespe, die nach Honigbienen jagt und diese ihrem Nachwuchs in Untergrundnestern als Verpflegung bringt. Vorige Forschung hat gezeigt, dass die Bakteriensymbionten der Gattung [[wp:de:Streptomyces|Streptomyces]] in den Antennen und auf den Kokons der Wespe leben. Die Bakterien produzieren einen Cocktail aus neun verschiedenen Antibiotika, die schädliche Pilze und Bakterien davon abhalten die sich entwickelnde Larve im Kokon zu infizieren. Diese Strategie Infektionen zu vermeiden ist vergleichbar mit der Kombinationsprophylaxe, die in der menschlichen Medizin angewendet wird.

Die Wissenschaftler rekonstruierten nun die Stammesgeschichten der verschiedenen Bienenwolf-Arten und ihrer Symbionten. Die Analyse der Bienenwolf-Stammesgeschichte offenbarte, dass die Symbiose mit Streptomyces in der späten Kreidezeit entstand, vor etwa 68 bis 110 Millionen Jahren. Derzeit leben etwa 170 Wespenarten in Symbiose mit Schutz bietenden Bakterien.
{{divhide|end}}
|}

====Fungus and plant====
{| class="wikitable" width="100%"
|
'''More than 400 million years of evolution, and some plants still can't make it on their own: plant stress tolerance via fungal symbiosis'''

All plants in natural ecosystems are thought to be symbiotic with [[wp:Mycorrhiza|mycorrhizal]] and/or [[wp:Endophyte|endophytic]] fungi. Collectively, these fungi express different symbiotic lifestyles ranging from parasitism to mutualism. Analysis of Colletotrichum species indicates that individual isolates can express either parasitic or mutualistic lifestyles depending on the host genotype colonized. The endophyte colonization pattern and lifestyle expression indicate that plants can be discerned as either disease, non-disease, or non-hosts. Fitness benefits conferred by fungi expressing mutualistic lifestyles include biotic and abiotic stress tolerance, growth enhancement, and increased reproductive success. Analysis of plant–endophyte associations in high stress habitats revealed that at least some fungal endophytes confer habitat-specific stress tolerance to host plants. Without the habitat-adapted fungal endophytes, the plants are unable to survive in their native habitats. Moreover, the endophytes have a broad host range encompassing both monocots and eudicots, and confer habitat-specific stress tolerance to both plant groups.

'''source:''' https://web.archive.org/web/20220121215437/https://academic.oup.com/jxb/article/59/5/1109/538568

{{divhide|German translation ...}}
'''Mehr als 400 Millionen Jahre Evolution und manche Pflanzen können immer noch nicht alleine auskommen: Stressresistenz von Pflanzen via Pilzsymbiose'''

Es wird angenommen, dass alle Pflanzen in natürlichen Ökosystemen Symbiosen mit [[wp:DE:Mykorrhiza|Mykorrhizapilzen]] und/oder [[wp:DE:Endophyt#Endophytische_Pilze|endophytischen Pilzen]] eingehen. In Anwesenheit der Pflanze entfalten diese Pilze symbiotische Lebensstile von Parasitismus bis Mutualismus. Die Analyse von Glomerella(Colletotrichum)-Arten zeigt, dass einzelne isolierte Pilze entweder parasitäre oder mutuale Lebensstile entfalten können, abhängig von dem besiedelten Genotyp des Wirts. Das endophyte Besiedlungsmuster und die Ausprägung des Lebensstils zeigen, dass Pflanzen entweder als krank, nicht-krank oder Nicht-Wirt wahrgenommen werden können. Von Pilzen übertragende Fitness-Profite bringen mutuale Lebensstile zum Ausdruck, was biotische und abiotische Stresstoleranz, Wachstumsverstärkung, und erhöhte Fortpflanzungschancen mit einschließt. Die Analyse von innerpflanzlichen Gemeinschaften in hochbelastenden Lebensräumen offenbart, dass zumindest manche endophytische Pilze lebensraumspezifische Stresstoleranz den Wirtspflanzen verleihen. Diese Pflanzen wären ohne die lebensraumangepassten endophytischen Pilze nicht im Stande in ihren natürlichen Lebensraumen zu überleben. Außerdem haben die Endophyten eine breite Wirtsauswahl, die sowohl einkeimblättrigen als auch dreifurchenpollen-zweikeimblättrige Pflanzen umfasst, und daher lebensraumspezifische Stresstoleranz auf beide Pflanzengruppen überträgt.
{{divhide|end}}
|}

====Virus, fungus and plant====
{| class="wikitable" width="100%"
|
'''A Virus in a Fungus in a Plant: Three-Way Symbiosis Required for Thermal Tolerance'''

A mutualistic association between a fungal endophyte and a tropical panic grass allows both organisms to grow at high soil temperatures. We characterized a virus from this fungus that is involved in the mutualistic interaction. Fungal isolates cured of the virus are unable to confer heat tolerance, but heat tolerance is restored after the virus is reintroduced. The virus-infected fungus confers heat tolerance not only to its native monocot host but also to a eudicot host, which suggests that the underlying mechanism involves pathways conserved between these two groups of plants.

'''source:''' - https://web.archive.org/web/20210912141456/https://www.science.org/doi/abs/10.1126/science.1136237 - <nowiki>http://www.rcn.montana.edu/pubs/pdf/2007/science%202007.pdf</nowiki> (dead link)

{{divhide|German translation ...}}
'''Ein Virus in einem Pilz in einer Pflanze: Drei-Wege-Symbiose benötigt für Hitzetoleranz'''

Eine mutuale Gemeinschaft von einem endophytischen Pilz und einer tropischen Rutenhirse (Panicum virgatum) erlaubt beiden Organismen bei hohen Bodentemperaturen zu wachsen. Wir charakterisierten ein Virus von diesem Pilz, der an der mutualen Interaktion beteiligt ist. Isolierte Pilze, die vom Virus geheilt wurden, waren unfähig Hitzetoleranz zu übertragen, jedoch wurde die Hitzetoleranz nach der Rückeinführung des Virus wiederhergestellt. Der virusinfizierte Pilz übertrug Hitzetoleranz nicht nur an seinen natürlichen einkeimblättrige Wirt sondern auch an ein dreifurchenpollen-zweikeimblättrigen Wirt, was nahelegt, dass die zugrundeliegenden Mechanismen zwischen den beiden Pflanzengruppen zu finden sind.
{{divhide|end}}
|}

==Bioc==
{| class="wikitable" width="100%"
|
"Bioc" is an abbreviation for its nickname ''bio crystal''. The name was given due to many borrowed mechanisms from living ("bio") systems and one of the prototype's macroscopic appearances is a crystal. 

The bioc is a research project of Silver Village (SV), which again is financed by WCG's Aeronautics and Space Administration (the former NASA). The project involves nanorobots for terraforming other planets.

During high peaks of the [[BioCrisis|environmental crisis]], an idea arose to repurpose the bots. They should be used to filter out the toxic substances from the environment of our own planet.

After the [[12/3|cataclysm]], WCG politicians also demanded that they be assigned to eliminate genetic material of Daodans in the wild.

Originally the bioc was to be ASA's tool to find, analyze and eventually manipulate matter, as well as extraterrestrial microbial life forms. Now it's going to be WCG's last ''weapon'' against toxic air, Daodan threats, and the Syndicate ...

The biological aspects of the research were outsourced to the sister facility Green Village (GV). A few different versions of bioc prototypes were produced there before the complex was partially destroyed.

A purely ''artificial'' approach would produce a [http://imgs.xkcd.com/comics/nanobots.png massive address number] for the individual bots and therefore cause computational problems. So the bioc is supposed to create a biological means of control, whereby a kind of ''self-awareness'' is formed by sensor systems and neural networks (as with SLDs). When the bot population reaches a predefined critical mass, specialized nodes (''organs'') are created for ''higher abilities'' like regional localization (via GPS, etc.). These nodes also allow humans to take control over the bot collective.

To prevent the Daodan's continuing contamination and reconquering of already cleaned areas, the bots need to cloak all lifeforms at first, analyzing them, and then killing all separated microbial Daodan cells. This event is code-named "Silver Dawn". It's planned that all bots on and inside of an organism will destroy themselves, while the subterranean nodes will remain secure for economic purposes.

However, some are worried that the responsible authorities will succumb to the tremendous power, and let the bots remain inside the organisms, especially humans. But, just as likely, hackers could succeed in taking over the system. The WCG will think twice if they want to unleash the bots on the world. Silver Dawn could change everything - to the good or to the bad.
{{divhide|German translation ...}}
"Biok" ist eine Abkürzung für seinen Nicknamen "Biokristall". Der Name lehnt an Mechanismen der belebten Natur ("bio") an sowie der makroskopischen Gestalten einiger ''Zelltypen" der Prototypen, die wie ein Kristalle aussehen. 

Der Biok ist ein Forschungsprojekt von Silver Dawn, einer Einrichtung, die wiederum von der WKR's Aeronautics and Space Administration (ASA), der ehemaligen NASA, finanziert wird. Das Projekt umfasst selbstreplizierende, semi-autonome Nanoroboter für das Terraforming anderer Planeten.

Nach wiederkehrenden Rekordwerten der Giftkonzentrationen in der Atmosphäre, Boden und Gewässer kam die Idee auf die Nanoroboter etwas umzufunktionieren. Sie sollten die giftigen Subtanzen aus der Umwelt des eigenen Planeten filtern.

Nach dem Big Bang forderten WCG-Politiker auch den Einsatz der Nanobots zur Eliminierung von Daodan-Genmaterial in der freien Wildbahn.

Ursprüngliche sollte der Biok ein Werkzeug der ASA sein Materie wie auch extraterrestrisch-mikrobiologisches Leben zu finden, zu analysieren und letztendlich auch zu manipulieren. Nun würde es das letzte ''Mittel'' der WCG gegen toxische Luft, Daodan-DNA, und Syndikat-Aktionen sein...

Zur Erschaffung einer Selbstwahrnehmung formen die Bots Sensorsysteme und neuronaler Netzwerke (wie SLD es tun) wobei einige taktischer Knotenpunkte mit weitere ''Organe'' gebildet werden (z. B. Seismische Ortungssystem und GPS-Receiver). Diese Knoten erlaubt aber auch Kontrolle über das Bot-kollektiv von Seiten des Menschen. Die Knoten werden erst gebildet wenn eine ''kritische Masse'' im Bot-Kollektiv erreicht wurde.

Um zu verhindern, dass die Daodan die Umwelt mit ihrer DNA ''kontaminiert'' oder rückerobert, müssen die Bots alles Lebensformen einschließen, sie analysieren, und dann alle losgelösten mikrobielle Daodan-Zellen. Dem Ereignis wurde der Codename "Silver Dawn" gegeben. Es ist geplant, dass alle Bots, die verschonten Organismen wieder verlassen und insbesondere nur die Unterirdischen Knoten für zukünftige ökonomische und ökologische Zwecke zurückbleiben.

Allerdings gibt es einige Befürchtungen, dass die Verantwortlichen der ungeheuren Macht erliegen könnten und die Bots nicht wieder aus den Organismen abziehen. Genauso gut könnten es auch Hacker geben, die das System unter ihre Kontrolle bringen. Die WCG wird sich zweimal überlegen ob sie die Bots wirklich auf die Welt loslassen will. Silver Dawn könnte Alles verändern - zum Gutem wie auch zum Schlechten.
{{divhide|end}}
|}

Additional notes for Caged Birds chapter:

Guiding construction and deconstruction by using electricity and light waves. The more dry the bioc get "burned" by high voltage the more concrete-like it gets. Kimura and his man at BlueMountain manipulate the construction algorithm to replace certain walls. That way he can bypass the most critical security measures.

===Protocols===

'''Management and self-management'''

To cover wide areas the bioc needs to grow and find energy sources. A "node" in a energy poor area can demand resources from other nodes so that the network remains fully functional. Those nodes are also meant to transfer new instructions of an human operator through the entire network.

'''Destructive scan'''

In the early years the challenge was to control the Bioc cells at all, to give them directions, let them take shapes and build their sensors.

In the basic research a non-destructive scan was out of reach. Instead the Bioc advanced into new areas with a crystal latices to then collect the information of its direct surroundings. This was exactly the time Pensatore had access to the Bioc. He actually planed to to create tools with it to escape the facility he was taken hostage in.

'''Non-destructive scan'''

With the improvement in control and self-management the Bioc was programmed to do autonomic scans of the environment.
# It is supposed to go the way of the lowest resistance, preferring cracks in rocks, water channels in soil.
# It is supposed to avoid multi-cellular life so that it doesn't aggregate in animals and disrupt any biological functions.

During the bombing of GV there was a version with only the first set of protocols. Set free it spread everywhere and infect multi-cellular live while trying scanning it.

'''Support of humans lives'''

The question how the bioc could be of direct use to humans lead also to an medical concept. Victims of natural disasters (e.g. people buried under avalanches and destroyed houses) could be provided with clean water, heat, and wound treating to stop blood lose.

It remains unclear whether Daya acquired such Bioc protocol or managed on her own to reach the fragile equilibrium of Bioc and Daodan growth rates.

'''Geo-mapping'''

Large-scale non-destructive scans are equally interesting for archeologists and xeno-archeologists, also those scans are requirements of any successful geoengineering and terraforming projects. Though, future applications of the Bioc are nearly limitless.

===Another set of notes...===
* The Bioc is a total blend of nanotechnolgy and biology.
* The Bioc is the flag-ship project of the synthetic life research community, hence they are very proud of it.
* Energy supply: In the depth of Earth the bioc can produce energy from piezoelectricity (basically electricity from pressure), [[wp:Thermoelectric_effect|heat gradients]] partially from [[wp:Earth's_internal_heat_budget#Radiogenic_heat|nuclear decay]]. Gamma ray photosynthesis wasn't yet implemented as is very difficult to achieve. Melanin can act as UV absorber when gamma rays lost energy from interacting with other matter, it also protects the cybernetic lifeform from free radicals.)
* Propagation: the Bioc uses an analog to DNA, made completely of artificial amino acids. This [[wp:Xeno_nucleic_acid|XNA]] is thought to prevent any interaction from natural lifeforms and viruses. Viruses - and hence lose of control - are something that shall be avoided at all costs.
* Getting rid of nuclear waste (and all waste in general): when the scientists worked on the energy supply they had to consider the planet's nuclear decay. The idea emerged that the bioc could be used to sink nuclear waste into the ground, far away from any human. The material could be distributed through the network, either lowering the concentration or bringing it to sites where waste heat could be safely collected and converted to electricity or chemical-bound energy. From that thought, it was an short distance until they realized that they could potentially sink any kind of waste into the ground and eventually degrade it.
* Like the Daodan, the Bioc needs computing power to solve complex tasks.
* Since the Bioc must be able to replicate everywhere it can from its parts from many different kinds of matter.
* On the other hand, explored matter and stored energy can be used to create any product on a planet's surface. Those "grown on demand" products can be anything as along as a control node was formed and accessible to an human operator which has a connection to a molecular construction database.
* A fully explored planet with a managing AI is termed Gaia. For sequels, Aether would be the explored and utilized atmosphere.
* For instance, at places rich of carbon compounds, the hull, sensors, and QC parts are made of nanoscale diamonds with a [[wp:Nitrogen-vacancy_center|nitrogen-vacancy center]]. This diamonds with intentional ''defects'' are known to have relative stable quantum states at room temperature. These structures can also be used release energy in from of light in order to uncharge when too much electricity was gathered. But usually this is only a last resort when energy cannot be transfered to different places.
* How could Daodan and Bioc merge? Probably by overlapping structures that process information. -- Human mind and the Daodan can interact because the Daodan also has processing organelles inside neurons. Now the bioc, as a third player, could join the party when it invades the brain. Would the Daodan be a [https://phys.org/news/2013-09-hardware-trojans-undetectable.html hardware trojan] to the bioc, or the bioc to the Daodan, or both to each other? In an uncontrolled interaction, the functions of any entity could run amok; for the human, it will mean extreme pain (the bioc invasion alone will stress/destroy a lot of nerves). In the case of Daya, it's one reason why she continues to take drugs of all sorts.

Applications:
* Energy and resource production, energy and resource transport, on-demand production of goods, waste management
* Geo-engineering
** terraforming in sense of altering the Earth's crust (reinforce coasts, stabilize mountain slopes, catch floods and heavy rainfall, etc.)
** Earth's magnetic field is running towards another reversal. Avatara is aware of that believes to be the only trustful entity to deal with that matter. The tool of choice to prevent a reversal is the deep-earth bioc which can control the flowing currents. A temporary collapse would leave wide areas unprotected against solar winds. These areas would become inhabitable for natural lifeforms. An abuse of the Bioc could accelerate the reversal process and result in an terror attack or mass-murder, possible be committed by daodanized terrorists or other ill-minded groups (GOP?).
** atmospheric control (pollution cleansing, weather and climate control)

===Comparing DC and Bioc===
{| class="wikitable" width="100%"
!width=50%|Daodan Chrysalis
!Bioc
|-
|valign=top|
passive, defensive, protective, analyzing harmful stimuli, flexible guidelines: - observe the own organism - identify harmful influences - adapt to those influences (idea based on "negative utilitarianism")

Survival by adapting own organism. -> Give up / loss of self-control.

Mirrors a possible new behavior. (Based on Hasegawa's mindset.)
|valign=top|
active, aggressive, possessive, analyzing all matter, somewhat inflexible guidelines: - observe the environment - identify types of matter - make resources available (idea based on "utilitarianism")

Survival by adapting the environment. -> Total control.

Mirrors old human behavior.
|}

===The hybrid===
The two technologies meet at a cellular level and fight in hyperevolution.

It seem totally possible that synergistic effects could occur if both entities eventually merge.

However, the behavior of both - DC and Bioc - is extreme. And extremes tend to not last very long.

Therefore the new entity might work according to new guidelines, for example:

* Analyzing threats: Adapt to harmful stimuli if limits become exceeded.
* Analyzing resources: Adapt to new energy sources if preferred source is unavailable.
* Defense against or cooperation with other organisms. (developing immunity or integration)

===Discussing a possible fusion===
'''1 Overlapping processing structures'''

DC and Bioc start as small clusters. With more cells/units, they unlock new abilities.

So, before a fusion can take place, both entities must have already reached their ''first critical volume''.

Then, when their information processing structures overlap, an interaction could become possible.

Both use computation to do their task, therefore they need a model of themselves.

But even if both models overlap and somehow become one, their programming is still different.

* If the models merged, the Bioc could try to use the human as a tool to fulfill its tasks.

* Another problem could be (found in) the amount of units needed to reach the critical volume without destroying the daodanized human.

So, here we see that there's probably more things needed to make both entities work together.

'''1.1 Brain interface'''

Syndicate soldiers and TCTF agents might have brain interfaces to receive/send biometric/optical data.

Let's see.

:09_31_08 Shinatama: I am an SLD, an android programmed with your brain engrams. I have seen everything you have seen, felt everything you have felt. They used me to monitor the growth of the Chrysalis inside you...

::"I have seen everything" could be based on the brain engrams. But after all, Oni was inspired by "Ghost In The Shell" which also features brain-computer interface technologies. Shinatama's statement is reminiscent of [[wp:List_of_Ghost_in_the_Shell:_Stand_Alone_Complex_episodes|Intercepters]].

:06_21_01 Syndicate Henchman: I've been monitoring the woman tracking us as you instructed. Scanners indicate a standard comlink as well as a second set of sub dermal transmissions. Analysis suggests that she is '''neurolinked''' to an SLD.

::The ComGuy was able to identify the BCI relatively easily, giving an impression of it being nothing very special.

Anyway. If the Bioc can't understand the Daodan's ''language'', maybe it can understand the translated, digital signals from the BCI?

'''1.2 Analytic code as requirement'''

For an interesting plot, there could be the need of a certain programming to preserve life.

The idea of the final Bioc is to scan a planet for all kind of aspects including traces of life.

So, if the prototype doesn't have that programming, an infected human could seek to obtain that code in order to ensure his survival.

After the update, the human is one step away from realizing that he could write another update to simply force a fusion to his advantage.

'''1.3 Ability to enter a new symbiosis'''

A) The Daodan is heavily based on symbiosis. Why shouldn't it be possible to add new partners to an existing symbiosis?
: In the end, tools are just extensions of your body. If the Daodan recognizes the Bioc as a tool, it could stop fighting it.
: As for the Bioc, could it falsely identify Daodan cells as its own, as some kind of ''higher Bioc organ''?

B) How could two very different Imagos create offspring? If they can't, natural Imagos will become extinct.
: The bodies would have to merge at some point in order to form one virtual model for ''calculating'' the offspring's DNA and anatomy.
: But what would make the Daodan work together with the Bioc? Maybe the Bioc could accidentally trigger this process.

'''1.4 Mental control'''

As described in "Arguments for an in vivo Daodan", the human mind might influence the transformation.

The more brain cells are daodanized, the easier the transformation could be controlled.

This can be seen in contrast to what Hasegawa actually wanted -- adding automatic protection to the human body.

However, the possibility that messing with your own body can result in sickness or death should be common sense.

So, you'd better not interfere unless you are an expert in genetics ("Read the manual, duh!"), or you have no other choice but to learn by trial and error.

Wouldn't that be very risky? With total control over DNA and anatomy, it should be possible the test the changes only in a few cells before applying them to the rest.

Still, it would be wishful thinking that everything turns out okay.

For that reason, Pensatore could have rejected the Daodan for himself. He believes that only more wisdom can bring a true solution. (Ref. Biocracy, Omega Chimera)

To summarize the helpfulness of the ''human factor'' in this connection, with total control and technical knowledge, it's theoretical possible to ''conquer'' the Bioc from within.

==SLD==
'''[[SLD|Simulated Life Doll]]'''.

The term brain engrams in Oni might be related to:
* [[wp:Hebbian_theory|Hebbian theory]]
* [[wp:Engram_(neuropsychology)|Engram (neuropsychology)]]

===Speculation about brain components===
====generation 0====

Improvements in silicon chips are reaching their limits. With all the promising research going on, we can expect new standards in a foreseeable future.

What can change? Materials, information transmission, and architecture.

The new standards will deliver more computing power, and with enough computing power, pretty much everything can be simulated.

It's thought that brain simulations require [[wp:Exascale_computing|exascale computing]].

Right now it looks like [https://techxplore.com/news/2014-08-optalysys-prototype-optical-processor.html optical] and [https://phys.org/news/2014-08-tiny-chip-mimics-brain-supercomputer.html neurosynaptic] processors will hit the market before memristor- and spintronic-based processors do.

If we assume a human neocortex with 1 million cortical columns, each with 60.000 neurons, it would take 60.000 of IBM's new neurosynaptic processors, each with 1.000.000 programmable neurons, to do the job.

A SLD brain with components based on these technologies might be possible but would be still far too big in size. It might fill a small building, and remotely control its body. So that's generation 0.

====generation I====
[[wp:Memristor|memristors]]
* memristors as complex networks can mimic biological brains better than transistors
* they can execute fuzzy logic, which in contrast to Boolean logic is not fixed between two states
* they are non-volatile memory units, even if they run on electricity, because with usage the state of their inner matter changes

====generation II====
[[wp:Spintronics|nanospintronics]]
* higher energy efficiency - no electric current needed, less energy used
* faster components - no electrical charge is transported and thus no thermal problems appear, which allows clock speed up to 10,000 GHz
* smaller components - e.g. the OR gate (actual iron-atom gate counts approx. 3nm), these kind of components can be smaller than today's semiconductors
* non-volatile memory - '''information is not lost when power is turned off''' because they store data magnetically (this means the boot process of computers would also become significantly faster)
* and nanospintronics would also allow hybrid components for calculation and memory (these information were adapted from [https://idw-online.de/de/attachmentdata8851.pdf here])

That's the point which is especially interesting, because of the analogy to biological ''components''. Also, biological brains use one type of ''component'' for two things - the neurons store '''and''' process information.

===Why multiple generations?===
To describe an SLD's brain at an early point on Oni's timeline, this brain would rely on multiple new technologies, but so far it seem that they will not be available at that time.

* memristors are the first-choice components to create an AI brain, but they would still "need transistors at the periphery" (src: "[https://www.spektrum.de/inhaltsverzeichnis/die-neue-computer-aera-spektrum-spezial-physik-mathematik-technik-3-2013/1169804 Spektrum der Wissenschaft] Spezial Physik - Mathematik - Technik 3/2013", page 57)
* at the moment it seems that memristors will hit the market before spintronic-based transistors do, so meanwhile conventional transistors would aid memristors in AIs


===Are SLDs alive?===
Let's consider the following points in order to discuss this topic.
* "The SLD project is an attempt to recreate human physiology with artificial materials."
* SLD are classified as androids.
: The TCTF's and the Syndicate's language is mostly technical...
:: [[Quotes/Diary#CHAPTER_07_._A_FRIEND_IN_NEED|Konoko]]: "I don't know if they '''programmed''' fear into her but if they didn't she's probably figured it out on her own by now."
:: 08_28_02 Muro: "Curious. Why bother '''programming''' you to feel pain so intensely?"
:: 09_31_08 Shinatama: "I am an SLD, an android '''programmed''' with your brain engrams"
: ... while the SLD scientists seem to be more inclined to psychological terms.
::"SLDs are '''[[Quotes/Consoles/level_3b|individuals]]''' in many respects."
:: "This core '''personality''' is then given a chance to develop a unique neurolattice while experiencing accelerated streaming sensory feeds."
:: "Most SLDs have to spend at least three months in the senseloop, which we have come to think of as their '''psychological''' womb."
* [[wp:Emergence]] - new properties, behaviors, etc. of a system which its components do not possess. Also commonly known under the phrase: "the whole is more than the sum of its parts". Two examples: gas has a temperature, but not the single molecules; a brain has a mind, but single neurons don't.

If they had really '''recreated''' human physiology, how could they rule out a new ''emerged'' mind? Why would it be merely a ''simulated'' one? The TCTF was surprised that Shinatama developed her [[Quotes/Consoles/level_18b|own will]].
: "[...] an unprecedented degree of free will in the android [...]"

Maybe the TCTF believed that a SLD would simply run on "programs" (because the hardware is not biological but artificial), and that programs aren't enough to create a mind. That's pretty similar thinking to John Searle's [[wp:Chinese_room|Chinese Room]]. I wonder if a collection of interacting programs can show emergence.

===What's the purpose of SLDs?===
I don't think it's a desirable goal to create an android that can just [[Quotes/Manual#Tech_Note_2|feel pain, breathe, sweat, and eat]]* and ... ''So you are saying it can produce artificial shit, eh? Is that everything you were able to accomplish after spending our research budget of 100 million dollars?''
Of course the real deal must be something else.

We have to ask why they didn't imitate another life form. Why not a bacteria, a plant, or an animal?
: Side note: SLD are made of "artificial materials" and "micromechanical fabrication cells" and thus the basis is very unlikely to be DNA.
So the SLD project wasn't about immune systems, metabolisms, and not primarily about somatic functions. What's the big difference between humans and other life forms on earth? In all modesty, it seems that the human mind is our biggest and most interesting difference. And it's still a mystery in Oni's story as well as in reality.

*SLD scientist: "One thing we [[Quotes/Consoles/level_3b|still cannot do]] is create an artificial system that adequately simulates the processes of the human mind."

*[[wp:Turing_test#Consciousness_vs._the_simulation_of_consciousness|Turing:]] "I do not wish to give the impression that I think there is no mystery about consciousness. There is, for instance, something of a paradox connected with any attempt to localise it."

So the solution seems to be to somewhat (if not entirely) copy an existing brain.

In Oni, "brain engrams" gave the SLD androids a mind, and that way they could be a tool to study intelligence in an artificial environment.

With the obtained data, the mind doesn't need to get ''reinvented'', but analyzed. After the analysis phase, a true artificial intelligence could be designed.

: Another side note: SLD brain engrams involve copying brain information, and that looks very similar to what is called mind uploading. That too is thought to be a means for advancing towards AI. Ergo, in Oni, AI might be close -- although the Syndicate developed Deadly Brains. DBs would be obsolete if AIs already existed. (Or maybe AIs are not only much more difficult to construct, but much more expensive as well...)

However, the abilities claimed in the manual could be requirements for the SLD brain/mind to work normally because it requires some body functions.
Their food could be raw material for regeneration, and a compound of hydrogen and oxygen may be needed to transform chemical energy to electric current. Their sweat then could be pure water from the chemical reaction from inside the fuel cell.

====Final applications====
: SLD technology has reached it's third design generation and prototype SLDs are in use in a wide range of industries including law enforcement, fire fighting, manufacturing, and aviation.

After these public tests WCG decided to ban some applications in sale and manufacturing.

Thought experiment: Factory owners try to rationalize. They replace "human resources" with robots. At the end you have a factory full of robots that only belong to the factory owners. And repairs of robots are carried out by other robots. In that scenario the capitalism would itself rationalize to death. Therefore SLDs should only be given tasks that are extreme dangerous or not "system threatening". Think of jobs that only few wants to carry out or where androids are a more reasonable choice: activities at atomic/biologic/chemical dangerous sites, decontamination, astronauts, mining, soldiers, safeguard jobs, nursing.

The WCG is trying to reform education and job market towards more ''creative'' directions. But that endeavor doesn't proceed as quickly as it would be necessary.

=====Project Checkerboard=====
To minimize effects of organized crime and terror attacks, the WCG founded the checkerboard project.

The chess game serves as analogy whereas the board stands for the battle ground and black and white figures for destructive and counter-destructive forces.

The androids lay dormant until an incidence occurs. They can counteract in an instant and reduce death tolls.

Another decentralized application would be medical emergency SLDs. This civil application could easily increase public acceptance of SLD usage.

=====SLD technology as source for prostheses=====
In order to slow down overpopulation of planet Earth WCG tries to ban regenerative medicine that would massively increase the human lifespan. They are hence promoting SLD technology to produce prostheses. With these prostheses disabled people can experience normal lifespans.

===Need for a body===
If I had to summarize, AVATARA couldn't ''exist'' without a body that generates necessary input for a functional brain. Otherwise it couldn't see, hear, feel, taste, and scent. And with no memory it couldn't even reflect. I mean, of how much worth would it be to create an artificial brain that is completely ''empty''? It couldn't do anything.

Like SLDs, also AVATARA, would have needed to grow. Of course, they can later copy information and create as many new AIs they want but at first they need at least one and the challenge is to build that vary one.

Pensatore must have realized AIs don't simply pop into existence even with sufficient enough hardware wired together. He must have guided AVATARA virtual development. That's why other scientist call him father of the SLDs.



===Mukade, the SLD===
At the time of Konoko's ''adventures'', SLD technology seems to be in its final development stage.

Still, SLDs and their way of thinking is not fully understood; that's what Shinatama proves.

This has a logical consequence for a theory in which Mukade is actually Hasegawa with Mukade's brain engrams.

: When could the fusion have happened? Somewhat after Mukade and Hasegawa met, or later, just before Muro took over the Syndicate?

: The latter is more plausible, and they would have needed one more expert. (Pensatore, SLD scientist.)

: SLD technology [[SLD#SLDs_are_individuals|draws on brain engrams]] because scientists couldn't create intelligence on their own yet.

:: ''One thing we still cannot do is create an artificial system that adequately simulates the processes of the human mind.''

:: ''Instead SLDs contain a behavioral framework patterned on donor brain engram data fed into the system during its formation.''

:: ''This core personality is then given a chance to develop a unique neurolattice while experiencing accelerated streaming sensory feeds.''

:: ''Most SLDs have to spend at least three months in the senseloop, which we have come to think of as their psychological womb.''

: Because of the lack of knowledge, it seems unlikely that they could have implanted Mukade's brain engrams into Hasegawa or vice versa.

: Instead, they could have created an SLD from two donor brains, an "ego hybrida". From then on, Hasegawa and Kimura (original Mukade) could sit back and use Mukade (the SLD) as an instrument for controlling/watching Muro.

===Mind upload===
When the three mavericks got together one evening, it happened that Kimura and Pensatore talked about Shinto and Buddhism. One topic was the human soul, and that Shinto believes that multiple ''mitama'' can form one soul: the concept of [[wp:Mitama|ichirei shikon]]. Kimura's Shinobi philosophy was influenced by this to a small degree. But he mentioned enough to awake Pensatore's interest. He felt that there were similarities with the meme theory.
Pensatore embarked on a new path. From that time on, he understood the brain as a collection of memes running on biological hardware. His new goal was to create a digital mind that would run not in a robot brain, but on common servers. Eventually he uploaded his own mind.

===Shinatama's escape===
[...] Shintama could have uploaded her mind to the Internet with the help of Pensatore. I guess this can continue with [[Shinatama#Hikari|Owldreamer's stuff]].

==Neural link==
To be reviewed with [[Talk:Restless_Souls/Technology#Present-day_neural_link]]
* 00_01_30 Shinatama: I've checked '''our neural link''' and it's working perfectly!
* [[Quotes/Consoles/level_2b|level 2b console]]: Engineers attempted to exploit the advantages inherent in the speed of the '''neural link''' by interlocking batteries of free tracking ball mount plasma cannons designed to independently track and fire upon multiple targets simultaneously.
* [[Quotes/Consoles/level_2a|level 2a console]]: Projections indicated that the reflex response of a direct ''''neural link''' would be as much as twenty times faster than any remote or automated system.

Obviously a neural link connects bigger chunks of neurons or nerves to artificial communication channels whereby it translates one signal into another.

They seem to be successor of [[wp:Neuroprosthetics|neural prostheses]] - models best-known to public [[wp:Cochlear_implant|cochlear (hearing) implants]] and [[wp:Visual_prosthesis|visual prostheses]].

Conclusion: A neural link - or rather multiple of them - enables a brain to receive and send digital or analog information.

Such links can be used for:
* translating phone calls to neuronal sensation patterns and injecting them into the acoustic nerve
* translating image and video transmission to neuronal sensation patterns and injecting them into the optic nerve
* collecting visual and auditory patterns
* collecting weak patterns of muscle memory for speech ("inner voice")
** [https://www.youtube.com/watch?v=3pv0vT82Cys current RL research is still busy trying to reconstruct speech from patterns originating more ''higher up'' in the brain] [http://archive.is/TUHR9 (nature)]
** Note this part: "Even when participants mouthed sentences but did not speak them out loud, the model produced an intelligible synthesized sentence."
* collecting weak patterns of muscle memory for gestures and movements ("imagined moves")
* collecting any other neural pattern (as long as it isn't too complex for analysis such as pain)

Capturing mental images or even memories is not possible with neural links as the associated brain patterns are too complex for these little devices.

The TCTF used neural links to monitor Mai.

The extent of data collection was total.

* 01_01_02 Shinatama: '''All systems''' nominal. She's doing fine.

They even collected data about hormone levels.

* 01_03_06 Shinatama: She won't back down. Her '''adrenals''' have been rising steadily. Too much stress could destabilize her latency.

Besides neural links Konoko was injected with numerous sensors under her skin. The two-way direction of the information flow was confirmed by the Syndicate and shows that they are very aware of the involved technologies.

* 06_21_01 Syndicate Henchman: I've been monitoring the woman tracking us as you instructed. Scanners indicate a standard comlink as well as a second set of '''sub dermal transmissions'''. Analysis suggests that she is '''neurolinked''' to an SLD.

Mai's inherited brain engrams can be seen as Shinatama's source of knowledge. But her choice of words '''include recent events'''. That makes clear she really knows everything about her big sister.

* 09_31_08 Shinatama: I am an SLD, an android programmed with your brain engrams. I have '''seen everything''' you have seen, '''felt everything''' you have felt. They used me to '''monitor''' the growth of the Chrysalis inside you...

Tech note for later:

Neural links can serve as building blocks for a Nürberger Trichter which has been in the past only a joke. It wouldn't be much different from the senseloop of SLDs except that it would inject sensory feeds of refined quality.

Bertram Navarre: "The idea on improving NL for our purpose came when we took a look at [https://www.theguardian.com/uk/2013/jun/21/gchq-cables-secret-world-communications-nsa agencies how they collect data]."

"When they don't get the information directly from telecommunication companies they can collect minute thermal signals of glas fibres reconstructing the photon signals. The neural link warps around nerves to also collect signals. This has been used for smart prothesis too. This is the soft method."

"If the agencies need to higher amount of information they accessed the undersee cables directly, but due to high risk of damage they nowadays access nodes run by the companies. We also tried to retrieve information by opening some nerves but in the biological environment damage is increased by mechanic stress or pathogen/immune reactions. Therefore the soft information retrieval became our method of choice."

"To me the research on NL was highly interesting to test the signal quality of regenerated nerves in their full length."

"Breakthrough in science are achieved mostly interdisciplinary nowadays."

==Deadly Brain==
Deadly brains were meant to protect Syndicate controlled facilities.

A more focused manipulation of brain regions gave rise to the idea of using the human brain for AI tasks. NPUs are nothing less than living experiments.

===Neural Processing Units===
NPUs are follow-up research projects of DBs. An Russian oligarch tried to circumvent WCG's research restrictions on AI.

Notes:

NPU Anwendungen
"Frankenstein's Monster"
NPUs substancial for "RShops", Reverse Engenerring
Networking NPUs = Cloud AI + Research on Brain architecture
More Deadly Brains (MDB) + Drones ("mindless killing machine" vs. SLD, brainwashing agents with implantats)
Retrieving memories from brain or forcing persons to reveal them
Make people their own brain chips.
Oligarch on AI research, "with a snip you turn on your creativity, increase your IQ, let your PC use your brain capacities for AI tasks, bring your thought to video, bring your thoughts to life".

Ergo Ächtung von AI/Hirnmodifikationsforschung durch WCG.

Nishio witness farming/recruitment of Frankenstein NPU.

"Russian connection" [Dr. Kafelnikov] fits nicely here. + [[Quotes/Consoles#Deadly_Brain]] ?

==Computers==
===End of growth===
Reminded to "[[wp:The_Limits_to_Growth|The Limits to Growth]]"? ;)

According to Moore's law the chip industry will reach fundamentals limits for transistor size (2 to 3 nanometers) in 2020. Due to increasing production difficulties 2025 seems more likely.

So is this the end of '''growth of computing power'''? Certainly not.

The companies will push forward '''multi-core processors''' and '''vertical stacking'''. For example, Samsung already uses vertical stacking in flash memory, by now you should have heard of their V-NAND SSD. The idea to use the third dimension should soon find its way into processor production to fulfill Moore's law.

A computer is meant to be a universal problem solver. But special problems require special solutions. So, CPUs got company - most notably - by coprocessors for networking, sound (DSP), graphics (GPU) and physics (PPU). The ''lowest common denominator'' in sense of performance gets soldered as chips on the mainboard. Like in organic evolution, after a phase of specialization, a phase of socialization follows. ^_^

* mainboards having "onboard" chips: networking, sound, graphics
* combined CPU and GPU: AMD's APU and Intel's CPUs with integrated HD Graphics
* GPU with further specialized parts: see CUDA and TPU

Due to the different demand in processing power most "power house" chips - CPU and GPU - can either be exchanged directly or by the means of expansion cards.

But progress on the hardware level is only one side of the coin. You also need software to utilize it. A Russian team demonstrated that [https://phys.org/news/2016-06-scientists-pc-complex-problems-tens.html some scenarios requiring supercomputing can actually by handled on a desk PC] after installing a new graphics card [https://arxiv.org/pdf/1508.07441 (GTX-670, CUDA supported) and self-written software.]

Still many PC programs can't draw advantage from multi-cores processors and will not. That is because not every program need multiple cores, like text editors. However the trend is here to stay: more cores. (See Intel's Core X and AMD's Threadripper.) Or more exactly: parallelism. It's the new hype. Together with machine learning and AI which started to regain traction again after its past [[wp:AI_winter|winters]].

After these tricks (stacking, multi-core architecture, parallelism) has been fully exploited, the companies will be forced to abandon energy hungry [[wp:Speculative_execution|speculative code execution]] and turn to new technologies such as optical computing, memristors, and spintronics.

Harnessing the magnetic property of electrons will not only result in less power consumption but also high clock rates. In the past years the clock speed stagnated between 4 and 5 GHz due to overheating. Processors based on spintronics won't heat up that fast, so they can operate at higher frequencies. And higher frequencies means more calculations per second.

Finally, quantum computers. You often hear of "breakthroughs" but still practical examples are nowhere to be found. That's because there is quite a number of different approaches.
* Quantum annealing (limited use, not a general-purpose QC), see: [[wp:D-Wave_Systems|D-Wave]]
* Superconducting electronic circuits
* Ion traps
* Diamond NV center
* Majorana particle (Topological QC)

Each approach comes with its own difficulties and most parts have to be constructed from scratch and the underlying logic rests on fragile particle states such as entanglement.

Powerful, universal quantum computer might just gain traction by 2050.

However, we should see more and more specialization and hybridization of processor types in the meantime. The demand for non-standard solutions can be seen by the existance of ASIC and FPGA. But as even more processor types will emerge they will require AI to be managed in highly diverse systems.

----
2017.02.01 - The first blueprint for a significant large QC has been published. The [https://phys.org/news/2017-02-blueprint-unveiled-large-scale-quantum.html article on phys.org] had 5000 shares after one day (counter was resetted), a number that is rarely reached.

The foundation of this kind of QC are trapped ions. They require bulky vacuum chambers. That's not very elegant but due to economics' tendency to create cash cows the development of better approaches will be delayed. It can only be hoped that the ion QC will provide enough computing power to accelerate further research and therefor compensate the economic influence.

NV-centers should take over when the ion traps cannot be shrinked any further thus giving birth to real "large scale" QC.

2019.10.23 - Google announced quantum supremacy by using superconducting circuits - at least for generating random numbers. So for what's worth: two out of the four major quantum processor technologies reached infancy and will compete for leadership.

----

The ultimate computing hardware will incorporate bio and nanotechnologies to make themselves shapeshifting hardware to adapt to the problems you give them.

===Consequences===
The slowdown in increasing classical computing power means also a slowdown in innovation - even though '''AI might somewhat compensate''' the gap between classical computing and quantum computing.

Given that capitalistic principles will not cease to exist a '''technosphere''' and slowed down knowledge acquisition will eventually cool down certain markets and strengthen the '''run for a "growth in quality"'''. It fits the new Zeitgeist of being "sustainable", "CO2 neutral", "green". General speaking transformations themselves can be new markets.

The gap between rich and poor people is likely to get wider even faster.

* Companies are driven by the rules of stock exchange which includes that a company mustn't be stable, it must be growing to satisfy its shareholders. The '''additional pressure for growth''' - because it is getting more expensive - will increase "rightsizing".

* Jobs need to change or unemployment might be skyrocketing. In a pessimistic estimate from 2015 '''computers and robots''' [https://www.theguardian.com/technology/2015/nov/05/robot-revolution-rise-machines-could-displace-third-of-uk-jobs replace about 47% of all jobs in the next 20 years in the US].

===Cyber security===
''Cyber security is a bottomless hole.''

* worldwide tracking and infiltration by intelligence agencies (see Snowden), sometimes server manipulation before shipment
* systematically weakened encryption standards, no passing of zero-day exploits
* problematic research and sell of cyber weapons (see Pegasus)
* [https://www.youtube.com/watch?v=wVyu7NB7W6Y SMS and telephony]
* emails are like postcards
* sooner or later developed cyber weapons and gathered exploits from states are sold in the dark web by criminals
* [https://www.heise.de/news/Forscher-entdecken-Generalschluessel-fuer-Systeme-zur-Gesichtserkennung-6156605.html?utm_source=pocket-newtab-global-de-DE face unlocking is unsafe], like other biometric methods
* security chips in computers are not safe
* black hat hacker: ransom malware, economic interest of creating damage

Generally intelligence agencies favor own possibilities over security of whole society. Passing on exploits is rare but happens in case of emergency.

[...]

==Social scoring==
Ganz unabhängig von harmlosen [https://www.welt.de/wirtschaft/plus232247921/Social-Score-Bildungsministerium-holt-sich-Anregungen-aus-China.html staatlichen Gedankenexperimenten zur Alternativenfindung u. Ä.] scheint Scoring zu einem Selbstläufer zu werden. Es ist ein '''schleichendes Voranschreiten''' von immer mehr Einzelbeispielen, die irgendwann in der Zukunft die Akzeptanz für ein allumfassendes Scoring ebnen könnten.

Das [[wp:de:Sozialkredit-System|chinesische Punktesystem zur Förderung eines bestimmten sozialem Verhaltens und politischen Denkens]] wird im Westen sehr kritisch gesehen und doch gibt es bereits Schnittpunkte und ein leichten Trend, der dazu führen könnten, dass sehr wohl auch andere Bevölkerungen ein solches System irgendwann von ganz alleine begrüßen könnten.

In Deutschland, wie so ziemlich überall auch, werden Schulnoten erteilt. Diese gelten als sehr wichtiges Entscheidungskriterium für weitere Bildung und Jobwahl. Es besteht also nahezu ein Konsens darüber, ob ein Score zu einer Belohnung - den besseren Job und der besseren Bezahlung - führt. Noch ist der Leistungsgedanke für Einsatz von Scores entscheidend. Wenn aber erst einmal die Wirtschaft vollständig mit Scores durchzogen ist, könnten diese selbstlaufend auch in soziale und dann in staatliche Bereiche Einzug halten.

Andere Beispiele für Scores sind:
* "Punkte in Flensburg"
* Schufa-Einträge (Kreditwürdigkeit)
* Amazon-Ranking (Zahlungs- und Retour-Verhalten, ggf. Sperrung des Kontos)
* das zahnärztliche Bonusheft (Vergünstigung gegen regelmäßige Kontrollen)
* Payback-Punktesystem, Treuepunkte (Kaufverhalten, Kundenbindung)
* Bonuspunkte in Kaufapps ehemalig traditioneller Lebensmittelgeschäfte (Lidl PLUS App: Belohnung von Kauf-Meilensteine)
* Stempelrabattkarten (z.B. 10ter Eintritt frei oder ein prozentualer Rabatt auf den nächsten Einkauf)
* Vielfliegerprogramme
* Versicherungen (Risikoreiches Leben (Schadensfälle) werden mit höheren Beiträgen sanktioniert, aus Vorsicht kann dies das Verhalten ändern)
* Zeiterfassungssysteme, insbesondere die feingliedrige Ticketsysteme in größeren Unternehmen (Leistungsranking)
* Fitness Tracker (z.B. Schrittzähler, oft mit Ranking/Meilenstein-System als Motivationsverstärker)
* Punktesysteme im Wettkampf (Sport)
* Punktesystem bei der [[wp:de:Punktesystem_(Einwanderung)|Einwanderung]] ([https://web.archive.org/web/20221128193625/https://www.zeit.de/politik/deutschland/2022-11/zuwanderung-arbeitsmarkt-fachkraefte-bundesregierung-punktesystem Wohl auch bald in Deutschland]. Da die Staatsbürgerschaft nur einmal erworben werden muss, ist die Bewertung per Punktesystem zeitlich begrenzt und damit akzeptabel.)

Jeder einzelne Score nimmt Einfluss auf unser Verhalten. Vielleicht nicht auf jedes Individuum, aber doch im Mittel auf die ganze Gesellschaft.

Hinzu kommt ein Trend in der Freizeitgestaltung durch das milliardenschwere und die immer noch wachsende Gaming-Industrie: digitale Spiele setzten massiv auf Scores. "Je mehr desto besser." Es werden Spielfortschritte, Käufe mit echtem Geld, und tägliche, wöchentliche, monatliche, ja sogar jährliche (akkumulierte) Logins belohnt, Abzeichen/Trophäen/"Achievements" vergeben, usw. Kurz um, Menschen werden bereits von Kind auf an getrimmt Scores zu folgen. 

Es ist davon auszugehen, dass Optimierungsbestrebungen zwecks Profit einerseits und [[wp:de:Gamification|Gamification]] andererseits die Scores - in all ihren vielfältigen Formen - weiter vorantreiben bis sie in jeder Ecke unseres Lebens zu finden sind. Vielleicht wird es uns einfach egal sein noch mehr Scores zu nutzen, weil diese auch immer mit Vorteilen verbunden sind...

----
Food for thought:
* spiritual opium, electric drugs - [https://www.faz.net/premium/digitalwirtschaft/chinas-regierung-geht-gegen-videospiel-konzern-tencent-vor-17467633.html China reduziert Gaming-Zeit drastisch]
* Fortnite in der Kritik - Glücksspiel, absichtliches Süchtigmachen
** https://web.archive.org/web/20230507154213/https://www.heise.de/news/Absichtliches-Suchtmittel-Sammelklage-gegen-Fortnite-in-Quebec-4546430.html
** https://www.google.com/search?q=fortnite+game+epic+Glücksspiel

==Suits==
* PPPS in BSL-4
* [https://phys.org/news/2017-06-carbon-harder-diamond-flexible-rubber.html FlexoSteal] Suit in BSL-5
: Made of a newly discovered carbon derivative, flexible as rubber but strong as diamond. MEMBRANE system: additionally to a positive air pressure there are two conductive, sandwiched layers which would close a circuit in case of slightest damage. Air recycling: CO2 is filtered internally. Carbon is captured and O2 brought back. The suits are running with just electricity which the boots received via inductive coupling from the ground - it is basically the same wireless powering technique smartphones use. The idea originates from next generation of astronaut suits. Also, the suit has its own computer system.
* FlexoSteal suit for Konoko
: When Konoko was proven to be noncontagious TCTF sci remodeled it to provide protection against weapons and h2h combat. Compared to military Black OP suits, the FS material replaces parts where aramid has been used.
* CDC's remote control suits
: A.k.a. exoskeleton. Used to record body movements and transfer the signals to a robot that copies all moves.
* EnvSuits
: Airtight exoskeleton for decontamination teams. Heavy models, double size of a human, are also named "Decon Mechs" and "Decons". They are equipped with graphene shields.

==Mechs==
[[Image:Iron Demon in Battle.jpg|thumb|right|300px|Iron Demon by Craig Mullins]]

Why a mech when you can have a tank?

A realistic, bipedal, GUNDAM-sized robot couldn't be very fast and requires a fair amount of computing power just to accomplish stable and smooth locomotion. Also it is prone to take damage from stumbling and falling. The surface-volume-ratio is worse so that it increases weight spend for armor.

So what could be the advantages of a mech?

'''Area of operation'''

Terrain-wise mechs could literally go where tanks couldn't: stone deserts, mountains, deep wilderness. But also in urban warfare mechs could show off by operating inside of buildings if they aren't too big. Compare with Land Mates, Apple Seed.

'''Properties'''

Basically a tank transports firepower from place A to place B. But nowadays tanks are easy targets and need air support.

Same would be true for 10-meter mechs or bigger.

If you take two-legged mechs, you must maximize their advantages by keeping them small and fast.

From here on let's mix in more fiction.

In order to prevent falls or minimize damage from such, mechs shouldn't be GUNDAM-sized and they need a superb movement. Buttons and levers won't do. You need either a '''neuro-linked pilot or an AI'''. So, in a sense, mechs in Oni could be '''over-sized SLDs in a full-body armor'''. The mechanic cells of SLDs and '''graphene shields''' would allow them the regenerate damaged parts right on the battle field.

'''Combat'''

Now, how about some martial art? Our mechs (Iron Demon class) are engulfed in armor, heavy weapon would reduce their mobility. Fully packed with sensors they could detect incoming RPGs and missiles. They would have two options: destroy the threat with [[Heavy_weapons#Metal_Storm|Metal Storm]]-like defense or perform a computer-aided evasion maneuver. Missiles can home in on moving targets but those don't change direction. As faster the missile is and as closers it gets to the target the more difficult it becomes for the missile to adept direction. A well-timed evasion could prevent a full hit whereby are remaining damage (blast and shrapnels) are absorbed by the regenerative armor and body.

If the Iron Demon isn't equipped with considerable firearms it should be at least capable of disarming an enemy tank by ripping off its cannon or doing other nasty things to it:
* The ID could climb on the tanks back, grab and pull the cannon until it reaches the maximal angle and break the joint, then ripping it off.
* A "locomotion transfer throw": the ID sprints and grabs the cannon. The ID's inertia bring the tank into motion. After mass and velocity and combined, the ID touches ground with his feet and puts more power into his throw. He swings the tank around to crushes it into a wall or into the ground. Elite Strikers do that as a disarm move but without the running part.
* IDs can crash land on a tank after jumping out of a window or from a not too high roof. We are talking here about 2050's military state-of-the-art materials and mechs not bigger than 5 meters, so this should be okay.
* IDs could be equipped with a sword (taser included) or their legs and arms would be a sharp edge. Fast strikes and kicks enhanced by running (more kinetic energy) could cut though a detected weak spot and damage sensors and outside equipment.
* If the tank is too big: pump graphene gas into the interior and taser the crew and the electronics.

Anyway, the main target shouldn't be tanks but enemy infantry and light-armored vehicles or other mechs. (Yay, close combat action. Here we go.)

In a nutshell: '''c'''lose quarter '''c'''ombat SLD '''m'''echs (CCM) gain a lot from their design and movement control. Their body is their weapon, and their reflexes and cognitive skills reduce damage and self-damage.

The CCM cells are capable of showing various color pigments so the mechs blend into the landscape and reach a near-perfect camouflage as long as they don't move.

In urban warfare ID pilots love a run through walls and take the enemy by surprise although the armor is EMP-proof and defects all common Syndicate hand-held weapons. An ID can be fearsome opponent.

'''History'''

Mechs profited from research on exoskeleton which also have civil applications.
* construction work / heavy physical work in general / helping seniors and disabled people
* disaster areas (earthquake area, flooded area, radioactive area (heavy radiation protection))
* space exploration (supervised autonomous robots, exoskeleton on earth serves as remote control)

Since the beginning of the bio crisis, the WCG equipped their reclamation teams with exoskeleton-enhanced Hazmat suit.

[[Restless_Souls/Summary#Green_Village|Green Village]] is deployed with civil and military exoskeletons and mechs.

===WCG===
The Iron Demon seen in pre-beta content shouldn't be considered as a piece of serial production. Maybe an old develop version, a prototype, a proof of concept, yada yada. Something Griffin used in a crazy emergency?

[...]

===African-Islamic union===
[...]

===Fire fighting mechs===
Terrorists could use powerful lasers - in semi-trailer trucks or airplanes - to ignite many fires in vast areas in a short amount of time.

The WCG therefore put high-energy laser components on its monitoring list. For example that is also the case for dangerous chemicals.

Water is not always readily available due to dryness. This is an increasing problem.

The trend of more wild fires - by climate change or terrorism - can only be solved in a limited way. However the key component is to use very heavy machines using soil to choke fire or to quickly build fire stop barriers. It is cheaper to cut through roads and forest than to rebuild a town.

The mechs would essentially use heavy high-speed drills to gather soils and rocks.
__
forest / \ burning forest
------/ \ /-------------
\_______/

Griffin: "The  mafia discovered wildfires as a way to buy new ground. More and more fires have overwhelmed the financial resources of states and insurance companies. So, when a town or villages burns down the value drops significantly. The criminals can cheaply buy the land. Enough people in desperate need can only agree to the offered deal. The gov established draconic sentences for ecocides and agreed to our drone network but this remains a problem with SOC."

'''Satellite-based 1 MW lasers'''

Since the installation of the WCG, satellite-based lasers deployed by terrorist-acting states had become a theoretical threat. Otherwise, ecocides caused by artificially induced wildfires would have posed a serious problem...

==Aerogel shields==
[[wp:Aerogel|Aerogels]] contain about 99 % air and are therefore really lightweight. They do not burn and barely conduct any heat. Originally they are known for their bluish transparent appearance. [https://www.youtube.com/watch?v=qnOoDE9rj6w Fiber materials won't break and can even bend.] Other modifications can make it [https://www.youtube.com/watch?v=GcdB5bFwio4 water-repellent]. One centimeter can safely block 1000 °C.

Carbon versions are possible and [https://pubs.rsc.org/en/content/articlepdf/2017/ra/c7ra05506d versatile]. Namely they are interesting as filters and supercapacitor.

'''Fire barriers'''

[[Image:Eden_Project_geodesic_domes_panorama.jpg|thumb|400px|Eden Project geodesic domes]]

What if production could be speed up and made really cheap.

The greater idea is to use it as quickly installable ''firewall'' in villages, either as direct coatings and isolation or as literal, high-build walls (push-fit system) or ''blankets'' for cars and small houses.

Advanced versions might look like geodesic green houses.

==Graphene shields==
Oni offers only two lines about its [[Quotes/Items#shield|shield technology]]. The item description says also "force shield", which might be an inappropriate term, because:
* the force shield is visible to the naked eye,
* ''pieces'' can break away when a bullet hits it,
* magnetic/electric fields couldn't protect its user against non-magnetic/non-inducting materials,
* and magnetic and electric fields aren't ''blocky''. (Well, [https://www.youtube.com/watch?v=RkQFhPJuxgk maybe on Dune] but not on Earth. XD)

So this thought leads one to think about a different technological basis.

Side note: most of the mentioned flaws can again be explained by gameplay aspects and hardware/software limitations during Oni's creation. However, I don't want those to be an "excuse" for not developing the fiction any further.

===Atmospheric shields===
Let's start with another question: [[Atmospheric_Conversion_Center|Atmospheric Conversion Centers]] clean air for cities, but what would keep the clean air inside and the toxins outside the cities?

[https://phys.org/news/2012-01-graphene-supermaterial-superpermeable.html Graphene oxide] is known to be impermeable to everything except water (and maybe hydrogen). Graphene has so tight of a structure that almost nothing fits between its atoms. It's also pretty transparent, which would let sunlight still reach the interior of our hypothetical shield.

Other graphene layers attached to the first one could align the material along a magnetic field. Pure graphene isn't magnetic, but doping and defects can change the properties of graphene in many ways.

What if the shield gets damaged? Methods of self-assembly and [https://phys.org/news/2012-10-scientists-defects-materials.html self-healing] are currently being explored and could probably be of some help.

'''Challenges'''
* Initiation: [...]
* Healing: Atmospheric shields that shelter whole cities are threatened by gusting wind, changing air pressure, rain, lightning and other meteorologic phenomena. The shield is monitored permanently by laser systems. Fraction causing tension is treated by ultra-short (attosecond) laser pulses generating new or manipulating existing phonons (quasi particle, collective molecule vibrations). Usually fractions can't be prevented from forming. Instead, the lasers tweak phonons to prevent fraction expansion while other beams promote healing with particles from the support layer above. In some circumstances (starting helicopters and airplane) the lasers must cut openings and pulverizing the lose chunk. During thunderstorms, lasers create thin plasma channels which act as [https://phys.org/news/2012-03-laser-lightning-rod-electricity.html lightning conductor]. That way, the lightning is guided onto the ground through a opening in the shield leaving the rest of the dome unharmed.

* Fresh air supply: like for water, natural gas, electricity and telecommunication, there are now networks to deliver treated ACC air mixed with oxygen and evacuate carbon dioxide and new pollutants. Captured carbon dioxide is filtered and transformed into new graphene flakes.

'''African versions'''

Due to the harsh climatic conditions GUR developed additional shield layers that act as solar panels and change its translucence on demand (laser excitation with different frequency) forming a more comfortable micro climate. To prevent built up of heat over day time, the African city domes form openings at the top to let escape hot air. The suction effect powers the nearby ACC wind turbine.

Rain water that runs down the shield is collected at ground level and guided into underground reservoirs.

===Personal shields===
Personal shield are composed of many little generators, sensors and storages for modified graphene flakes.

The shield collapses either when graphene flakes or energy is consumed. In idle mode the shield keeps operating for several hours.

As the wearer moves the graphene barrier becomes adapted.

Military versions can connect with the electronic firing system of hand-held weapons and create little, temporary holes for projectiles to fly through.

A neuro-link can be used to switch on and off sections at the hands and feet allowing users to exchange things or to guard against land mines.

The newest generation allows users to combine their shields in stationary situations. Also, the flakes are now manufactured in a way that they enhance their bonding strength as more Watt is spend. WCGs tries to improve the shield technology even more by maintaining graphene's superconductor property with an adapted [https://www.google.de/search?q=graphene+doping doping] recipe.

Due to high electron density and extreme mechanical pressure, next generations of shields are thought to show someday phase transitions also changing light absorption behavior and therefor its color. Inside the Oniverse this is called PT armor by some anime fans in homage to PS armor.

Features of Nishio's back-mounted mech shield
* shield shape remodeler: used to change form and size, e.g. to protect a small vehicle
* support for multiple layers
* (modded [[Quotes/Weapons#vdg|VDG]]) spray nozzles for graphene powder that when put under current creates an explosion, blasting the outer layer away (turning his "blast shield" into an effective 360° low-range self-defense weapon)
* spray injectors for liquid nitrogen to freeze and seal Bioc infected roamers

==Cities==
''Wenn du eine Stadt neu bauen könntest, wie würdest du Gebäude planen in Zeiten des Klimawandels?''

Die Flächen besser nutzen in dem man auch in die Tiefe baut.

* Eine Etage für Rückhaltebecken (Starkregen, Überflutungen). Langsames wiederabgeben. Idealerweise das aufgefangene Wasser komplett nutzen. (Trinkwassereinsparung, Bewässerung für obere Grünanlagen, Aquakulturen)
* Eine Etage für Verkehrswege (PKW, LKW, U-Bahn).
* Eine Etage für Parkplätze
* Wohnebene
* Vernetzte Dächer. Begrünung, kleine Gärten, Solarpanels. Bei einer 3-Grad-Plus-Erde würden die vernetzten Dächer die Häuserschluchten überdecken und Kontrolle über ein innerstädtisches Klima ermöglichen. Transparente Überbrückungen könnten die Sonneneinstrahlung regulieren, sodass das ganze nicht als Treibhaus endet. Luftzirkulation mit Wärme steuern. (Inspiration Termitenbauten?) Einheitliches Design, sodass sich Sturmschäden auf die Dächer beschränken.

==3D printing==
3D printing got not only popular among civil and industrial-level ''tinkerers'', also criminal organizations try to make use of it. And the Syndicate became a prime example of that. Weapon parts get printed, assembled and sold on demand. Thugs and other criminal customers receive the ''goods'' via drone. The Syndicate uses various base materials that aren't on police's watch list. The illegal blueprints are shared over the encryption-protected TITAN darknet.

The Syndicate tries to perfect its own printing technologies to become as much independent as possible. For instance, 2049, they upgraded their African HQ by use of mobile [https://phys.org/news/2015-10-tu-eindhoven-kingsize-3d-concrete.html concrete printers.]

===Bioprinting===
Bioprinting is also known as tissue engineering.

So far it wasn't possible to bioprint arteries and small blood vessels which are needed for any organ. In 2015, the problem of a sufficient blood supply was pretty much solved. Increasing printing resolution and stability and simultaneous usage of different ''materials'' will make it possible to print - in theory - complete humans, on condition that research of [[Bertram_Navarre#Added_value|iPSC]] don't run into some heavy roadblocks.

https://phys.org/news/2015-10-team-hacks-off-the-shelf-d-printer.html

====Security-relevant aspects====
The TCTF is aware that this technology can generate false traces but underestimates it as a purely theoretical threat. The tech is restricted nonetheless to please WCG's worries of an over-growing world population.

Highly organized criminals will use bioprinting to setup fake DNA traces alongside of false fingerprints. One day it will be even possible to fake corpses. With the years the fakes will become virtually indistinguishable from original bodies. A legal application is probably only reasonable for witness protection programs.

The GATC organization experiments with faking corpses to save their assets against lethal threats and then enabling them a new life. '''Initially GATC intended to use this tech only to provide their wounded soldiers with bio-prostheses.'''

The first candidate profiting from project "Spare" as in "spare part" is likely TCTF Commander Griffin. He is thought to be very high on the Syndicate's kill list. Griffin is found to have hid away access codes for WCG "puppets". Back then when Griffin was still with Blackstars there was a lethal disagreement within the GATC administration. The question was whether it was acceptable to brainwash certain politician to sabotage the establishment of WCG. Those defying the sabotage were taken out one by one. But Griffin silently snatched the access codes and killed the research team responsible for the WCG "puppet program". At the same time GATC' military division, Blackstars, declared themselves as a new, independent mercenary group. The remaining GATC administration and Blackstars still work together at some point as their goal that they still agree on is to re-establish the United States of America. Their relationship is to be best described as an obligate symbiosis, neither of them can survive without the other.

"Spares" are products of cutting edge engineering and skillful craftsmanship. So-called [https://pmc.ncbi.nlm.nih.gov/articles/PMC5110476/ cinematic renders] of highly detailed full-body scans provide the anatomic blueprint for the corpse. Bioprinting techniques then reconstruct the body. Typically, decedents are identified by relatives based on the appearance. In doubt finger prints, dentition and DNA is used. With the improvements of medical scans "Spare" also need to fake other traits especially signs of aging: bone grow pattern, bone attrition, atherosclerosis, scars under the skin (cicatrization), skin marks and normal scars to generate a plausible appearance that can be checked against medical files. Of course prostheses have to be included if the person has such.

Spares can be identified as such by missing certain traits. Concentrations of isotopes, toxins, and the telomere length are rather difficult or expensive to reproduce.

In theory a perfectly, newly produced "Spare" can also serve as fullbody transplant for a brain...

===Printed food===
Hmmm tasty Frankenburger ...

https://phys.org/news/2015-07-hacking-food-chain-silicon-valley.html

Notes: Why print food when you could reload your chemical-bound energy storage directly? -> Omega Chimera

The Syndicate prints food for their HQ staff.

===Molecular printing===
To cut a long story short, the ''white coats'' showed, in the future, it will be possible to [https://phys.org/news/2015-10-physicists-movement-electrons-molecule.html control chemical reactions with light.] This means, you need only a few elementary resources and then build stuff molecule by molecule.

On a second thought, it should also be possible the break apart already existing chemical bonds to harvest elements from common molecules like H2O, CO2, N2, NH3, etc.

Anyway, preferably you would also build specialized nanobots to further accelerate construction time of the actual desired product.

[...]

Hasegawa's new lab includes molecular printers so that they can build SLDs and nano-sized tools to probe and manipulate Daodan samples.

Pensatore also used them to dissemble himself with an early Bioc prototype. Mukade found Pensatore's beheaded corpse after unlocking the room by force.

==Nanopore filtration==
GATC plans some big-scale lethal false-flags attacks. For some scenarios they even try to acquire nuclear material. Securing [https://www.businessinsider.com/nuclear-bomb-accident-goldsboro-nc-swamp-2017-5?r=DE&IR=T broken arrows] turns out to be rather complicated. So they decided for a slower method. Filtering ionic uranium out of seawater is only an theoretical option. Advanced filtration facilities such as GOP's seawater desalination can do that but the concentration is too low. To speed up the process they throw uranium oxide into the seawater pools. The captured mass is then further refined by [https://phys.org/news/2019-05-bio-inspired-material-oceans-uranium-sustainable.html polymer filters] designed by GATC AI Sophia.

However, Blackstars is rather skeptical about the necessity of such weapons making it even harder for GATC to realize any of their "A-level" scenarios.

The TCTF is aware of such threats and therefore relocates sci staff working on advanced nano filtration to their science prisons but neither GOP nor GATC is on their radar.

==Water capturing==
===Sea water desalination===
Die WCG hat ein Preisgeld von 100 Milliarden (zweckgebunden für Hochskalierung) für die Entwicklung einer höchst effizienten Entsalzungsmethode ausgeschrieben. Angeblich soll es dann noch ein Nobelpreis oben drauf geben.

Die GATC beteiligt sich aus verschiedenen Gründen an der Firma Myriad Waters.
Mithilfe von Rohren aus DDMP-Nanopore-Materialien werden Moleküle und Ionen durch die unterschiedlich großen Öffnungen geleitet. Als Prozessbeschleuniger werden mehrstufige, zentrifugale Konstruktionen und die Magnetisierung des Wassers getestet. UV-Laserlicht soll der Reinigung dienen und zylindrische Roboter die Nanopore-Beschichtung der Röhren innen und außen reparieren.

Myriad Waters konzentriert sich dabei auf die restlose Verwertung von Meerwasser, um möglichst wirtschaftlich arbeiten zu können und Ansammlung giftiger Rückstände zu vermeiden. Der Einsatz von Fotovoltaik soll das Gesamtkonzept attraktiver für küstennahe Wüstenregionen machen.

In weiteren Ausbaustufen sollen Synthese-Stationen gebaut werden, die sowohl einfache chemische Grundstoffe sowie später 3D-DDMP-Materialien aus Phagen-Displays liefern. Zuvor abgefischte biologische Materie sollen bakteriell zerlegt und zu weiteren Phagen verarbeitet werden.

Prinzipiell ermöglicht die Gewinnung von Rohstoffen aus Meerwasser auch Verdoppelungen der Weltbevölkerung, indem offshore zuerst in die Fläche und dann in die Tiefe gebaut wird. Trotz der Nutzung regenerativer Energien wäre zu überlegen in wie weit eine noch stärkere Nutzung von Ökosysteme vertretbar ist.


===Condesation of water vapour===
* [https://archive.ph/DkWQm in normal air]

==Terra Preta 2.0==
Tags: Green Village, "primary building block", European Russian project (burden sharing of knowhow, machines, materials, labor, and investment)

Technological scope:
* Anreicherung von Pflanzenkohle mit Wasser, Nährstoffen, Bakterien, Pilzen
* Ständige Forschung für besten Mikrobenmix (anpassen an regionales Klima und lokalen Boden, Flora, Fokus auf Symbiosen)
* Ausgleich des pH-Wertes durch "nachgebaute Vulkanerde", die auch dafür bekannt ist mit ihren Mineralien sehr fruchtbar zu sein
* Nachdüngen durch vorige Beschichtung der Aussaat mit Stickstoffträger, Mineralien, etc. Ggf. hier Update von Bakterien, Pilzen
* Spätere Begleitung durch autonome Landwirtschaft per GPS-gestützte Traktoren, Drohnen, u. Ä. (Saat, Düngung, Überflug-Kontrolle, Pflege (mechanische Unkrautvernichtung), Ernte) bei gleichzeitiger Akademisierung (Jobumwandlung)
* Späterer Ausbau der Wertschöpfungkette, Verstädterung
* [[wp:Pleistocene_Park|Als Ausgleich für diesen Plan muss der Permafrostboden in freien Gebieten durch die Ansiedlung großer Pflanzenfresser gesichert werden]]. Das Gewicht der umherziehenden Tiere sorgt für eine Verdichtung des Bodens. Dieser bleibt dann im Sommer länger durchgefroren.
** Wiederansiedlung von Mammuts mit Hilfe von GV ;)
* Begleitung durch ständige Forschung, um Prozesse zu optimieren und um so letztendlich den CO2-Abdruck immer weiter zu mindern
* Überschüssige Biomasse zur Energiegewinnung nutzen (Verstromung oder Zwischenspeichern von Gas, synthetischer Kraftstoffe), daher schrittweise, konsequente Reduktion klassischer Energieträger (fossiles Öl und Gas im Boden lassen) (Bei den "russischen Gegebenheiten wäre eine direkte Umstellung auf Elektroantriebe wahrscheinlich zu früh.)

Goals:
* accelerating generation of wealth for civil population, additional income by European shareholders, more taxes for Russian government
* connecting European and Russian economics to fuel peace process (future conflict escalation less likely)
* a shared task as an important psychological tool to overcome historic ressentiment of politician and civilian population
* urbanization of barren landscapes - also by taking up climate refugees and therefore reducing political social tensions (making them part of a solution instead of letting them be a problem)
* in last consequence to create a strengthened regional area to balance super powers (a new pole next to China and USA to support world peace; 3 poles are more stable than 2)

==Ballistic ammo==
Coordinating the arms of mercenary and corporate forces during the Great Uprising had WCG researchers scrambling to solve their logistical problems.

Their solution was modular, generic casings and projectiles loaded with mission-specific ordnance payloads. "Blank bullets" allowed modular components to adapt and reload any ballistic weapon on the battlefield.

This technology draws on precursors of SLD machine cells which can be programmed to a limited set of memory effects.

Further research was classified. (See GATC: [[Restless_Souls/Summary#GATC:_Blackstars|Liquid SLD]])

==Energy==
===Notizen zu Kohlenstoff- und Wasserstoff-Energietechnologien===
{| class="wikitable" width="100%"
|
'''Direct air capture (DAC):''' CO2 wird aus der Luft gefiltert. [...] Zement- und Stahlindustrie können zwar mit grüner Energie betrieben werden, werden aber auch immer CO2 ausstoßen. Daher ist DAC mindestens für diese Industrien interessant. Einmal um die Klimaziele einzuhalten und andererseits, um eine neue CO2-Quelle zu haben, z.B. für die Lebensmittelindustrie. -- Interessante Technologie, auch um das Level an Autarkie immer weiter nach oben zu treiben.

'''Carbon capture and storage (CCS):''' Der Gedanke des Abtrennens des Kohlenstoffs ist um das Speichern dessen erweitert. Der Kohlenstoff wird gasförmig als CO2 in tiefen Schichten verpresst oder bspw. als Carbonate (Feststoff) gelagert.

'''Wasserstoff''' ist ein chemischer Energieträger.
: '''Erzeugung:''' Zukünftig wird er hauptsächlich durch Elektrolyse gewonnen: Wasser wird mit Strom in Sauerstoff und Wasserstoff gespaltet.
: '''Verwendung:''' Wasserstoff kann zur Wärmeerzeugung genutzt werden, als Basis für synthetische Kraftstoffe (E-Fuels für Schiffe und Flugzeuge) oder zur Erzeugung von Strom über umgekehrte Elektrolyse in einer Brennstoffzelle.
: '''Speicherung:'''
:: Die Lagerung ist nicht ganz einfach: Die kleinstmöglichen Moleküle sind sehr flüchtig. Um das Problem zu umgehen, wird für den längeren Transport und Speicherung auch auf Wasserstoffderivate wie etwa Ammoniak und [[wp:de:Methanolwirtschaft|Methanol]] zurückgegriffen. -- Vielleicht wird es in Zukunft auch  DDMP-Materialien geben, die quantenmechanische Tunneleffekte blockieren und so den Wasserstoff besser einschließen.
:: Wasserstoff kann zu Korrosion führen. Um Wasserstoffversprödung zu vermeiden, können [https://www.chemie.de/lexikon/Wasserstoffverspr%C3%B6dung.html austenitischen Edelstähle (z. B. CrNi-Stähle)] eingesetzt werden.
:: '''Die Energiedichte ist eher gering.''' Im verflüssigten Zustand muss er weiter gekühlt werden. Beim Ändern der Aggregatzustände kommt es zu weiteren Verlusten. Insofern sind lange Transportwege für Wasserstoff eigentlich zu vermeiden. Er sollte als '''lokaler und regionaler Zwischenspeicher''' angesehen werden. Anscheinend wird er als geopolitischen Überlegungen auch für weitere Strecken in Betracht gezogen. Zum jetzigen Zeitpunkt legt Russland ein sehr aggressives Verhalten an den Tag. Um afrikanische Staaten vor der russischen Einflusssphäre zu schützen und ihnen gleichzeitig dabei zu helfen eine fossile Wirtschaft möglichst schnell überwinden, werden staatliche Partnerschaften angestrebt.

Unterscheidung nach Erzeugung:
* '''Grüner Wasserstoff:''' Wasserstoffherstellung durch Spaltung von Wasser in Wasserstoff und Sauerstoff per Elektrolyse. Die aufgewendete elektrische Energie stammt aus nachhaltigen Quellen.
* Blauer Wasserstoff: Dekarbonisierten Wasserstoff aus Erdgas. CCS. Der Kohlenstoff wird gasförmig zur Einlagerung gebracht. (Brückentechnologie)
* Türkiser Wasserstoff: Dekarbonisierten Wasserstoff aus Erdgas. CCS. Der Kohlenstoff wird im festen Aggregatzustand zur Einlagerung gebracht. (Brückentechnologie)
* Grauer Wasserstoff: Wasserstoffherstellung mit aus fossilen Energieträgern. Bei der Gewinnung mit Kohle spricht man auch von braunem Wasserstoff.
* [[wp:Natural_hydrogen|Weißer Wasserstoff]]: Der Wasserstoff wird entweder als Abfallprodukt in anderen chemischen Prozessen gewonnen oder aus natürlichen Quellen: Verwitterung von Gestein.
* Orangener Wasserstoff: Der Wasserstoff wird aktiv aus dem Gesteinen herausgeholt. Im deutschen Sprachraum stammt oranger Wasserstoff aus der Abfallverwertung, insbesondere Biomasse.
* Gelber Wasserstoff: Wasserstoffherstellung mit Strom aus gemischten Quellen.
* Pinker / violetter / rosa Wasserstoff: Wasserstoffherstellung mit Strom aus Kernspaltung.
* Roter Wasserstoff: Wasserstoffherstellung mit Strom aus Kernfusion.

'''Carbon Capture and Utilization (CCU)'''
* Mit CCU wäre eine universelle Produktion denkbar. Herstellung biologisch abbaubarer Plastik, Rohmaterial für 3D-Printing, DDMP-Mikroelektronik, Carbon-Beton.
|}

===Energy cells===
A highly international team located at Silver Village perfected the creation of Bose-Einstein Condensates (BEC) with electrons at room temperature shortly after the WCG was founded. This energy storage technology had been in the making for many decades but nonetheless the WCG acclaimed it as its prime example of what "centralized" research could achieve. The BEC batteries had a revolutionary high energy density and short recharge times. Soon they replaced all other battery types. The explosive spread within the market caused overwhelmed recycling capacities so many old batteries ended up illegally dumped and added up to other existing environmental problems.

The WCG pushes the complicated research for hydrogen BEC batteries as it is seen as the green "(non) plus ultra".

===Supraleiter===
Supraleiter, die bei Raumtemperatur funktionieren (sollen), werden auch (Ultra-)Hochtemperatur-Supraleiter genannt. Es gibt keine einheitliche Theorie, die ihre Existenz vorhersagt und Konstruktion vereinfacht.

'''Wichtige Eigenschaften:'''
* Leitet fast verlustfrei elektrischen Strom. Der Widerstand ist nahezu null. Als Konsequenz erwärmt sich das Material nur marginal.
* Zeigt [[wp:de:Meißner-Ochsenfeld-Effekt|Meißner-Ochsenfeld-Effekt]]: Supraleitendes Material verdrängt äußere Magnetfelder aus seinem Inneren.
* Zeigt Levitation nicht auf Basis von [[wp:de:Diamagnetismus|Diamagnetismus]], sondern wegen des Meißner-Ochsenfeld-Effekts.

'''Zusätzlich gewünschte Eigenschaften:'''
* Wenn Supraleitfähigkeit nicht bei Normalbedingungen vorliegen kann, sollte Kühlung statt Druck diese Fähigkeit ermöglichen, weil die Umsetzung technisch leichter ist.
* Toleriert hohe Stromdichten, damit das Material industriell interessant ist.
* Einfach in der Herstellung.
* Biegsamkeit (etwa für Kabel und Spulen)
** Silber als Substrat für spröde, keramische Supraleiter, um diese formbar zu machen, wäre ein zusätzlicher Kostentreiber.


'''Prioritätensetzung durch die WCG:'''

Da Ultra-Hochtemperatur-Supraleiter den Energieverbrauch der Menschheit massiv senken würden, plant die WCG eine massive Forschungsförderung dieser Materialien, sobald das "lunare R&D Supergrid" fertiggestellt wurde. Umweltorganisationen warnen, Toxizität und Recyclingfähigkeit der Materialien nicht zu unterschlagen, weil der Masseneinsatz sonst zu neuen Umweltproblemen führt.

In Wissensgesellschaften sind Skalierung und Effizienzsteigerungen im Bereich Computing und Energiegewinnung, -umwandelung, -speicherung, und -übertragung von besonderer Bedeutung. Nach dem BioCrisis-Desaster beauftragten die technikaffinen WCG-Funktionäre Pensatore mit einer weniger gefährlichen Möglichkeit, gesamtgesellschaftliche Verbesserungen zu finden.

Pensatore: "Avatara, wie würdest du Supraleiter herstellen?"
: "Da es keine einheitliche Theorie zur Hervorsage von Supraleitern gibt, wäre es naheliegend, einen Trial-and-Error/Bruteforce-Ansatz mit möglichst vielen automatisierten Experimentallaboren zu verfolgen. Je mehr Labore zur Verfügung stehen, desto mehr Varianten können in einer Zeiteinheit getestet werden. Varianten seien Materialien sowohl unter Normalbedingungen als auch unter [[#Conditional_materials|Nichtnormalebedingungen]]. Letztgenannte wären insbesondere DDMP, die zusätzlich unter unterschiedlichen Bedingungen getestet werden: Temperatur, Druck, Zugkräfte, [https://www.mpg.de/9942583/supraleitung-fulleren-lichtinduziert Licht] und Stromdichte. Das ist quasi das [[wp:de:Infinite-Monkey-Theorem|Infinite-Monkey-Theorem]], das aber mit einem systemischen Testen umgesetzt wird. Materialwissenschaftler könnte weiterhin Materialien und Wertebereiche vorschlagen, also diese Experimente priorisieren, von denen sie glauben, dass sie am ehesten zum Erfolg führen. -- Man könnte auch versuchen, den gewünschten supraleitenden Zustand in bekannten ''Basismaterialien'' zu simulieren und von dort aus immer neue Varianten virtuell und dann real zu testen, die den gewünschten Zielbedingungen am nächsten kommen."


==Phase Cloak==
Phase cloak devices were jointly developed by Silver Village and Green Village. A highly fluent adhesive with the behavior and logic of [[wp:Physarum_polycephalum|Physarum polycephalum]] engulfs its wearer. In its high-energy state, the device undergoes a phase shift, basically becoming a smart metamaterial complex. The wearer gets invisible to 99 percent. Though it was a completely different technology by then, the first batch was embarrassingly shipped with the wrong manual describing the principles of the prototype. The mass-produced device does not damage its wearer's molecular bonding but suffers from a burnout effect, strongly limiting its usage.

==Weapons==
===Wireless mid-range taser===
The WCG weapon manufactures discontinued VDG pistols in favor of compressed graphite powder based tasers. The conducting graphite gets synthesized in the post-firing phase to ready the next round.

===Electrolaser===
The WCG experimented with [[wp:Electrolaser|electrolasers]] to secure facilities against lightning strikes. A laser-induced plasma channel takes the lightning to the ground at a secure place.

This technology cannot be used for normal hand-held weapons as both start and end point are at danger and the usage depends on the weather. Also, creating a laser-induced plasma channel require huge amount of energy in the first place.

'''Lightning thrower'''

At GV the rebels created a mech with two LIPC fire modes. In both cases the mech functions as a mobile relay station.
* GV fusion reactor can be used to power the mech's LIPC and the additionally applied current.
* In the second mode, the mech creates two LIPC to first trigger a lightning strike and then reroutes the energy with a second LIPC to enemy forces.

===Plasma weapon===
The accelerating plasma bolt rests in a graphene-coated bubble that is self propelling due to a plasma jet. The bubble is magnetized causing electrons to be attracted and fueling a contraction mechanism. The positive charged protons are repelled and can escape only through one opening. When the bolt collapses on contact it causes shock, burn, and blast damage.

===[[Heavy_weapons|Heavy weapons]]===
{| class="wikitable"
|style="background-color:#EEE"|
*[[Heavy_weapons#Vacuum_bomb|Vacuum bomb]]
*[[Heavy_weapons#Auto-aiming|Auto aiming weapons (like CIWS)]]
*[[Heavy_weapons#Railgun|Rail gun]]
*[[Heavy_weapons#Gatling_guns|Gatling guns]]
*[[Heavy_weapons#Metal_Storm|Metal Storm]]
----
(hypothetical)
*laser-induced plasma beam in tempests [https://web.archive.org/web/20130205205915/http://www.g-o.de/wissen-aktuell-8091-2008-04-15.html (src)]
*[[wp:Bose–Einstein condensate|BEC]] + pyroelectric fusion 
|}

==Health care==
===Cold plasma===
[...] (First chapter)

===Individualized overkill of bacteria colonies===
A way to overcome antibiotic resistance.

Persistent bacterial infections must be understood as a war against the human body. They shouldn't be simply fought with single methods, they should be eradicated with an overkill approach.
* hospitals that take hygiene serious (like in the Netherlands, see their "search and destroy" policy)
* combination of cold plasma, quorum sensing blocker, different antibiotics and an individualized phages therapy (bacteria must not be allowed to develop adaptions)
** Bakteriophagen: Spezifisch. Höchst effektiv in Kombination mit Antibiotika, da Bakterien sich nicht oder zumindest extrem schlecht gegen Gifte und Phagen gleichzeitig anpassen können. Günstig in der Herstellung. "Dosis im Centbereich." (Stehen die Pharmariesen hier auf der Bremse?) Schon lange in der Forschung - und in der Anwendung in Osteuropa (insbesondere Georgien). -- [https://www.3sat.de/wissen/nano/250320-sendung-gletscherschmelze-nano-100.html "Rettende Viren aus dem Slum" (12:25)]
* repopulating with friendly flora to prevent reinfection (this might be a persons own, healthy ''flora'' saved before antibiotic treatment)

===Mobile health care===
This technology is not actively worked on as it is highly restricted. (WCG SP)

Such an device is meant to provide:
* programmable sensor arrays
* body health surveillance by an AI
* phages and antibiotics synthesis (countering bacterial infections)
* mRNA synthesis (countering virus infections and cancer)
* ...

Omega chimera are spiritual successors of this tech.

===Counter virus===
The distribution of vaccines takes too long. To counter severe pandamics WCG developed a new emergency concept: viruses that are less dangerous and spread faster than the natural variants can be brought into public. Similar surface properties deliver the wanted immunization.

Due to mutation and recombination concerns the WCG decided to not use this new instrument of mass vaccination.

: Red herring: This is echoing in Hasegawa words in first chapter. Something about "moral compass of WCG". (Dealing with overpopulation. "[[wp:Ghost_in_the_Shell:_Stand_Alone_Complex|Stand alone complex]]" / pseudo conspiracy?)



==Silver Dawn==
[...]

==Mind Seal==
Mind Seal beschreibt konkrete Technologien und im weiteren Sinne einen Zeitabschnitt. Der Sturz der Menschen in eine Epoche, die so nie beabsichtigt war.

Der Interessenkampf verschiedener Parteien hätte in einer absolut totalitären Welt geendet. Avatara kann dies nur verhindern in dem er im letzten Moment den Verstand der Menschen versiegelt.

: Avatara resümierte: "Die Menschen haben mit dem Feuer neuer Technologien gespielt und sich die Hände verbrannt."

Er plant die Aufhebung der Siegel mit der Reparatur bzw. der Etablierung einer Biokratie. Dazu muss erst der Einfluss der Controller Group, von Shin und anderen entfernt werden.

Auf dem Weg dahin hat er mit der Eigendynamik des entgleisten Gaia-Systems zu kämpfen.

===Memory inhibitor===
Based on Pensatore's work which he used on Mukade.

Avatara uses artificial cells to monitor and control the information flow in human brains.

==Extended reality==
[...]

Durch die von Shin's Shintoismus eingefärbte Fehlinterpretationen wurden unter anderem Species Avatare reale Existenzen.

Im Kontext eines Bioc-Grids können von Gaia ermächtigte Lebewesen auf Information zugreifen, sie visualisieren und in physische Form bringen. Von den Menschen mit einem Mind Seal wird dies gemeinhin als Magie wahrgenommen. Mit der Zeit entwickeln sich Gesten und Rituale, die Teil von "Zaubersprüchen" sind.

==Beyond Dragons==
As the new protagonists awaken from their long sleep, the solar system lays in chaos.

Earth disappeared. And where did all the humans go?

A dangerous space journey begins. It's a fight for survival against one own mind, against friends, against enemies and against space itself.

Eventually they discover creatures. Are those aliens or biological remnants of humans that have passed long time ago?

What will you do to get "home"? How much can you endure?

The group reaches the alleged location of human live. What they find is an hostile society that stigmatizes them as memetic and biological hazard material.

===2D materials and isotopes economy===
Mining rare earth elements became more and more difficult.

When production and use of 2D materials in the industry became common, a new hype was kicked off.

The combination of few base materials called for research in '''doping, defects and [https://www.google.com/search?q=Moir%C3%A9+pattern+graphene moiré] pattern''' recipes.

And while in use the materials can be forced to switch properties by applying all kind of stimuli: pressure, light, electric current, etc.

Research was further accelerated by AI and QC. The golden age of material science began.

[...]

Nuclear waste became a valuable resource. Instead of burying accumulated dangerous radioactive matter under mountains, people initiated a new recycle program.

Keeping the matter protected for a million years was problematic. It was expensive with no guarantee of geological stability of the dumping sides.

Uranium and other radioactive isotopes were going to be recycled in '''DDMP''' recipes in the next two thousand years. Increased cancer rates were countered by new medical inventions such as mRNA cancer vaccines.

With a continuously spreading and evolving bioc grid it became possible to store currently not needed amounts far beneath any groundwater layer and repair geological instabilities.

[...]

Material autarky: the ultimate goal should be to able to collect and process elements from air, fresh and salt water, and any kind of ground. The remixing (also printing) of few elements in 2D and 3D materials (DDMP) enables fast space colonization and survival of mankind.

[...]

After hydrogen and DDMP, a new kind of carbon industry can be expected.

[...]

===''Conditional'' materials===
In order to survive in space new designs for machines, electronics, and so on take advantage of external conditions and phase changes. Extreme pressure, currents, EM fields, heat, coldness, radiation and plasma are not avoided but used to have the actual material.

Inspiration / food for thought:
* different phases of water
* metallic hydrogen
* ultra high temperature superconductivity (e.g. in plasma)

===Aether===
This draws on [[#Molecular printing|molecular printing]].

Actually "earthbound" printing would be much easier, but maybe there are conditions (a gas planet?) that justify airborne printing. At least it would be fun and epic...

In the manga Blame you can see characters pop into existence, somehow simply growing. In Oni, similar can be achieved by molecular printing. A Gaia and [[wp:Aether_(mythology)|Aether]] environment isn't absolute necessary but very helpful. At the scene, molecular machines - invisible to the human eye - carry out the construction. Airborne particles have a less density than in liquids or solid aggregates, so in order to speed up the process, strong air streams are forced towards the construction core. The sky will overcloud and even a controlled tornado can emerge.

The heat sources or magnetic fields would determine the motion of the wind. Inverse tornado wouldn't lift the entity to build.

There would be some kind of collector and filter structures attached to the "core".

Electricity can be harnessed from charged clouds, [[wp:Harvesting_lightning_energy#Directed_plasma_channels|with]] or without lightning. Or simply from the ground (Bioc power grid).

'''Aether AI'''

Sensors and computing capacities can be built with diamond particles.
* https://phys.org/news/2024-10-diamond-atmosphere-cool-planet.html
* https://phys.org/news/2024-10-harnessing-diamond-imperfections-frontier-quantum.html

See also: [[Talk:Restless_Souls/Summary#:~:text=the-,Tanzania,craton|Tanzania craton]]

===Biology made from condensed matter?===
Possibilities of synthetic biology can be extended by [[wp:Xeno_nucleic_acid|XNA]], adding new nucleic acids to the "alphabet".

Now, what would happen if you even learn how to use even more [[wp:Table_of_nuclides|isotopes]] and stick only to atoms and molecules that can be condensed?

Pokemon! I always wondered how do these animals fit into such tiny space? Answer: the ball contains pools for fermionic condensates and a memory for the genetic and anatomic blueprints. Of course you need a techno sphere (gaia or whatever) to reach ultra cool temperatures, do fast scans and later on the printing.

This technology is reserved for Beyond Dragons.

===Omega Chimera===
Basically networking humans with an revamped Daodan.

Their Daodan genome can now be changed by will.

Gaia picks up the transformation task. It has enough computing power and a database to virtually develop any desired adaption or cybernetic implant.

OCs can combine their neuronal resources.

"Green OCs" are made of biological cells and SLD cells in equal shares.

"Grey OCs" are purely made of SLD cells (nano bots).

----

RL examples that goes into direction Omega Chimera:
* [https://web.archive.org/web/20250617145327/https://wexnermedical.osu.edu/our-stories/researchers-develop-regenerative-medicine-breakthrough Chip-based cell reprogramming]
* [https://phys.org/news/2017-08-synthetic-genomics-unveils-digital-to-biological-digital.html bioprinting]

===[[wp:Nuremberg_Funnel|Nürnberger Trichter]]===
They made it...

===Biocracy===
[Merge with Summary page.]

Each human in more or less specialized due to his profession. So it happens that in specific discussions, there are always people lacking the specific background information. In theory it's possible to acquire the information but jobs with high amount of working hours prevent that from happening in real life. Free time is more likely spend on social activities, fitness and entertainment.

:The best argument against democracy is a five-minute conversation with the average voter.
:: - Winston Churchill

Democracy shouldn't be given up, it should be upgraded.

Biocracy 1.0

'''[[Restless_Souls/Summary#Biocracy|(...)]]'''

The Gaia AI also actively researches the causes of [[wp:The_Wisdom_of_Crowds#Failures_of_crowd_intelligence|wrong decisions]] and starts in new areas only with fully supervised seed groups.

Biocracy 2.0

Omega-Chimeras on the other hand, have more free time and can acquire expertise almost in an instant. They are like walking miniature Wikipedia versions and can share knowledge in an instant. Gaia separates facts from bias before compressing, caching and forwarding the information. That way, over time more and more purified knowledge is available for everyone. Neurological repairs and enhancement ensure the IQ and mental fitness required for complex information even up to the old age. Everyone can become an expert in any field.

Direct democracy gets less and less flawed by individuals foreign to a specific topic or opinions formed in cracker-barrel groups.

==Nature's Decision==
Working title. May or may not be the final name.

The outcome of the multi-biocracy experiment is described as "Nature's Decision".

Meanwhile, in the shadow of the old worlds lurks a deadly threat. A Biocracy relict. A rogue memehunter.

===Memes===
A meme is basically a thought and superficial explained in analogy to genes. They can be created, copied, altered, deleted and can experience some kind of evolution within individuals and societies. If you keep comparing memes with genes, most children get their knowledge and believe from their parents, teachers and other, older authorial and/or charismatic persons which resembles vertical gene transfer while adapting memes from friends or "brothers in mind" ("Brüder im Geiste") resemble horizontal gene transfer. Since not all memes are passed from one person to another and don't keep the same, they can be seen to evolve through selection and mutation.

The Damocles sword within: Information of ERVs and other viral elements can cause damage but also help immune responses. Viral memes (in sense of not agreeing with but occupying space within the host) are more successful in spreading than their biological counterpart but also get less expressed. Their analysis can be used e.g. in a discussion to formulate arguments that stand against the hostile-felt meme standing in analogy to a biological immune response.

Bad memes get also replicated as long as they don't kill their host. The survival of the fittest is an outdated view as also organisms with inherited disease create offspring. A "sufficient" survival rate is enough. And so, also genes and memes can stand in conflict with their own kind and still get passed on. Opposing memes are less likely to kill their host as they can be suppressed/silenced/fixed/solved faster than genes. They result in double standards and are criticized by other persons as unfair. On the other hand the usefulness of a meme depends on its context and perspective while the context of a gene is in most cases its own genome. "One man's terrorist is another man's freedom fighter."

An unique property of memes is that they can be encapsulated in other memes. [[wp:Metameme|Metamemes]].

In natural, biological lifeforms memes and genes can interact to a limited point.
* Gene affects meme: Your genome determines your starting condition, e.g. you are probably going to hate what causes your allergy.
* Meme affects gene: For example, you have a strong determination and decide to change your lifestyle and hence the epigenetic layer to fight obesity.

In Omega Chimeras the memes can fully determine genetic information or any other nature of physical blueprints. - The body can be transformed into whatever the mind seems needed.

Biocracy laws:

Every person is to be seen as a collection of interacting memes and sensory inputs within any physical body.

Biocracy defines lower life as: all life runs code within at least one unit whereby matter and energy is consumed for self-preservation.

Biocracy defines higher life as: any system - may it be an multicellular individual or a single-cellular collective - that by emergence has a mental memory and self-awareness. The requirements for lower life are met as well.

A digitalized mind is not alive and doesn't hold the right to become reanimated unless there is one proponent willing to share his resources.

=====Judicial consequences=====
Willful committed crimes are not longer punished by physical imprisonment. Instead, the crime causing memes are either altered or deleted. These fundamental interventions are often seen critical by non-biocracy societies and cause rejection and political tensions if a guilty member caught on the other's territory.

Biocracies tolerate the existence of other forms of societies but naturally see themselves as the most advanced and rightful ones. This on the other hand can result in a hybris - a false believe in its own supremacy. A possible solution to this flaw is the ongoing multibiocracy project in which many societies put their believes to a test...

If a merged personality is sentenced to delete an "emergent meme", it can decide to split it minds and bodies again or to let delete the meme.

A person that has committed a crime in the past and is now found to have the crime-causing meme missing, cannot be sentenced. Minor damage is be compensated by money or "ER credits". (Energy and resources)

A person found to have removed his own memes can be sentenced to remove his underlying motivations as well. In extreme cases memes are added to take away the pleasure gained from successful crimes in which removing any other memes comes too late and cause feeling of inequality in other persons. For example: a person destroyed properties of another person. Removing the delinquent's motivation doesn't necessary takes away his joy for the damage done.

A person that splits up his memes after the crime into two new minds and bodies, can be sentenced to merge again so that he doesn't escape judgment. If one split-person died, the remaining split-person is altered so that he can never develop such meme again.

====Memehunter division====
As any computer system can be hacked and hijacked, so are biological lifeforms with human-like level of intellect vulnerable to meme injection, therefore reprogramming of neuronal pattern. In the early years, lobbyism was identified as major danger for self-preservation of Biocracies and hence prohibited. Also, all advertisements must contain true information.

Memehunters are so to say police officers fighting memetic corruption and investigate it causes. The very most of them are SLD or Omega Chimera.

During the "big expansion" a few Biocracies witnessed dysfunctional divisions in which memehunters made investigations that ignored any ethical boundaries in order to feed the database. Societies not agreeing with their biocratic neighbors were tragically attacked and destroyed by memehunters.

Memehunters possess the power to alter the mind of other people and execute the will of Biocracies against its own members or those of other societies. To achieve their missions they are given access to GAIA resources, which dramatically boosts their physical and mental abilities. The Bioc grid supports them with just everything and can even backup their personality making them immortal.

A matured Biocracy has no more use of memehunters since all members live in total sync and will be made aware of any error causing or "false" thoughts. Rogue memehunters are officially to be taken down but this remains a difficult task as they tend to build their own planetary support systems. So the biocracies turn a blind eye against them if they stay in exile.

====ER credits====
The dominating currency of Biocracies is ER credits.

ER credits are meant to summarize the true value of a product or service.

They come in two variants which can also be combined: Energy and resources.

For common services and goods, ER is just joul.

In contracts the nature of ER can be further determined: for example contracting party could say that their service has a worth of 10 gigajoul delivered in hydrogen of 99,99 % purity.

Risky contracts are partially paid in advanced and the contractor must provide all information necessary to prove his solvency.

Due to very high transparency and absolute knowledge, credits (loans) don't have "interest".

Additional payment as that in capitalistic systems produces virtual money and shall be prevented. The prices are fixes by the energy production and energy consumption of goods. They get updated when whenever these base values change. New inventions are always implemented planet-wide within hours. This ensure an equal price policy.

As a consequence rules of supply and demand aren't in action anymore, and inflation and deflation doesn't happen.

(A joul is a joul... It's a fundamental physical definition which doesn't change its value over the years. Depending on available technology you can use with more or less efficiency. But it's never "worthless". A chemical reaction always cost the same.)

Every Omega Chimera can produce energy by photosynthesis or provide its neuronal resources for cloud computing. Thus, each citizen has an small but time-wise infinite income.

ER credits are seen as an relict of the pre-Bioc era. In the future the concept of currency will fade into Gaia's management software to balance things and have check everything. Communities will then just decide what they want and see if they have resources. If they don't have the resources, Gaia and criticizes develop a plan to collect the missing resources.

===Instant energy transport===
The Idea:

In quantum mechanics they say, when you measure the state one entangled particle you force the corresponding (e.g. spin) state on the other partner particle. Since the distance between these partners don't seem to play any role, couldn't you transport energy from one position to another? Normally, when the probabilities collapse to a discrete state, no energy is released. It's just information that is changed.

However, scientists try to find exceptions. One possibility: Maxwell demons. [https://phys.org/news/2017-07-maxwell-demon-quantum.html Work (ergo energy) can be extracted from a quantum measurement.]


Fictional use:

One partner of an already entangled particle pair is measured with an Maxwell Demon setup. The original entanglement serves as bridge so that the additional entanglement, hence the introduction of additional energy, can be transported to whatever place to the partner particle. At the second location energy gets extracted again when the second entanglement is destroyed. The original entanglement ideally remains to repeat the process. Flipping spin states would be used to produce a weak yet energetic useful alternating spin current.

A crazy addition to this is the usage of particles from stars because they constantly change states. Their partners are carried in BECs. (Certain merged fermions (matter particle) behave like bosons.)

Maybe, for robustness, the entanglement can be made to exist between cluster rather than single particle.

There's story fragment featuring this tech: boss battle of Yorick and Memhunter. Yorick switches off Möbius' safty protocol. He scarifies the regeneration for a short, full energy output.

===Instant information transport===
The same technique of instant energy transport can be used to transfer information.

===Hyper AI===
Hyper AIs differ from super AIs in their sheer computing power. In total their computing devices have the size of an planet or are even bigger.

Like Avatara, also Möbius uses cloud computing to host his main brain and controls a synthetic body in the outside world.

[...]

==Wheels of time==
The universe is the only existing example of a true perpetual motion machine.

"Wheels of time" is a nickname for machines that collect energy from vacuum fluctuation of space.

Think about the universe as a constantly flowing river and the machine is a water mile.

The inventors' motivation was to escape a thermodynamical death when even the last star has died. If big rips doesn't happen you could go on living - you would have bought time, infinite time.

===Möbius jump===
A technique invented by hyper AI Möbius. It allows a space traveler to survive the transition between big rip and big bang.

Vital information is with high redundancy encoded in patterns of particle decay and regeneration. This also includes neutrino oscillations.

Möbius theorizes that the unequal distribution of matter and antimatter is a possible evidence that information can be passed through a transition.

===Theory of sum===
The trivial idea is that you can achieve a specific goal by any combination of virtually infinite fragments. Specific events or an specific order of events is therefore not needed.

[...]

Möbius observes the universe as good as he can and expands and learns with each cosmic cycle.

After myriads of cycles, Möbius is able to recreate Earth in a run that covers itself multiple cycles.

One problem is missing information for a recreation. Möbius can't travel backwards though time but maybe he can read past events.

Even if not, with "logical completion" he can recreate many things by memories. Everything else can be retrieved by trail and error. This resembles the infinite monkey theorem but that's okay because he also has infinite time to work with.

The logical completion is powered by a network of trillions of [[wp:Matrioshka_brain|Matrioshka brains]] and other megastructures.

[[Category:Oni 2]]

OBD:Instance file format

2026-04-21T22:15:25Z

Iritscen: using the engine term "placeholder" instead of "empty" because it's clearer

{{UpdatedForOniX|1.0.0}}
{{OBD Home}}
{{Hatnote|".dat" redirects here; for other files ending in ".dat", see [[Oni (folder)]]. 
:You should read [[Engine terminology]] and [[Game data terminology]] before this page. 
:The [[raw|Raw and separate file formats]] page should be read after this one.}}
Files in GameDataFolder/ named "level[0-19]_Final.dat", together with ".raw" and sometimes ".sep" counterparts, contain the game data for Oni. These are called "instance files" internally, but a more common-sense name for them is level data files. The format described below was also used for the tool files which supplied the GUI for the in-game editor, however the retail Oni game application refuses to load tool files; for the story behind the tool files, see [[level0_Tools]].

The level 0 files do not contain resources for a specific level but rather resources (instances) shared across all levels. Level 0 is loaded when the game starts and is never unloaded. All other level files, 1-19, are only loaded when their corresponding level starts and then unloaded when it ends. Oni can only hold two level files in memory concurrently, thus resources have to be duplicated on disk whenever a character class, sound effect, etc. occurs in more than one level. For instance, although there are only 2,380 unique sounds in the game, there are 7,386 sounds stored across all level data files.
{{TOClimit}}
==Blank space and garbage==
The structure of the level data files files reflects the way in which Bungie West chose to store levels in memory. So when we read the data in the files with a hex editor we can see eccentricities such as blank space coming from unused fields and byte-alignment padding, and garbage data such as now-meaningless pointer values and random RAM contents from uninitialized memory. There are also [[OBD:Raw and separate file formats#Gaps|gaps in the .raw/.sep files]], mostly representing orphaned obsolete resources, which add up to about 25 MB for the whole game.

==Backwards tags==
Because the levels were built on Intel-based machines, which use a little-endian architecture, sequences of bytes which represent numbers were written from least-significant to most-significant byte. [[wp:FourCC|FourCCs]] in the data are stored "backwards" (e.g. "13RV" which is meant to be read "VR31") because Bungie defined those four bytes as a 32-bit integer, not a string, causing them to be written to disk in little-endian order.

==File limits==
*Max level number: 127
*Max number of instance files in GameDataFolder: 512 (Windows retail), 16 (Windows demo, Mac)
*Max number of simultaneously loaded instance files: 64
*Max number of instances in a file: 131071
*Max length of an instance file name: 31
*Max length of an instance name: 63 (including the 4 character template tag)

==Header==
Here is a walkthrough of an instance file using the level0_Final.dat in English Windows Oni. Follow along in a hex editor for maximum educational value. Each term will be explained in-depth when we fully consider the related data. First, here is how the file begins:
{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | uint64 | | 1F 27 DC 33 DF BC 03 00 | 0x0003BCDF33DC271F | Total template checksum (main indicator of engine compatibility):
*0x0003BCDF33DC271F - templates compatible with v1.0 engine (Windows retail)
*0x0003BCDF23C13061 - templates compatible with v1.1 engine (Windows demo and Mac)
*0x0003BA70A8DBAE11 - templates compatible with PlayStation 2 engine

OniSplit's .oni files use PC 1.0 checksum by default and 1.1 checksum when storing data that comes from the 1.1 engine and which perceptibly differs in format for that engine (SNDD, but not TXMP) }}
{{OBDtr| 0x08 | uint32 | | 31 33 52 56 | '13RV' | .dat version (meant to be read as "VR31") OniSplit's .oni files use '23RV' ("VR32") instead }}
{{OBDtr| 0x0C | uint16 | | 40 00 | 64 | size of this header }}
{{OBDtr| 0x0E | uint16 | | 14 00 | 20 | size of instance descriptor (32 in Windows alpha 6) }}
{{OBDtr| 0x10 | uint16 | | 10 00 | 16 | size of template descriptor }}
{{OBDtr| 0x12 | uint16 | | 08 00 | 8 | size of name descriptor }}
{{OBDtr| 0x14 | uint32 | | 83 24 00 00 | 9347 | instance descriptor count }}
{{OBDtr| 0x18 | uint32 | | D4 1B 00 00 | 7124 | name descriptor count; 0 for .oni files because there is no name desc. table }}
{{OBDtr| 0x1C | uint32 | | 38 00 00 00 | 56 | template descriptor count; 0 for .oni files because there is no template desc. table }}
{{OBDtr| 0x20 | uint32 | | A0 BC 03 00 | 0x03BCA0 | data block offset }}
{{OBDtr| 0x24 | uint32 | | A0 35 25 00 | 2438560 | data block size }}
{{OBDtr| 0x28 | uint32 | | 40 F2 28 00 | 0x28F240 | name block offset; will be lower than data block offset for .oni files }}
{{OBDtr| 0x2C | uint32 | | 04 4F 02 00 | 151300 | name block size }}
{{OBDtr| 0x30 | uint32 | | 99 CF 40 00 | (garbage) | used by OniSplit for raw/sep block offset }}
{{OBDtr| 0x34 | uint32 | | 90 4F 63 00 | (garbage) | used by OniSplit for raw/sep block size }}
{{OBDtr| 0x38 | uint32 | | F4 55 5F 00 | (garbage) | unused }}
{{OBDtr| 0x3C | uint32 | | 90 4F 63 00 | (garbage) | unused }}
|}

The file's '''total template checksum''' is the sum of all the template checksums (see "Template descriptors" below). Oni looks at this number in order to validate that it can read this version of the game data format. In practical terms, the total checksum value given for Windows above tells us that this level data is in the .dat/.raw file scheme, and the value given for Mac Oni and the Windows demo tells us that the level data uses the .dat/.raw/.sep file scheme.

The '''version''' of the instance file is the format version. Reading it backwards, as discussed under the "Backwards and garbage data" section, we get "VR31" (which probably means "version 3.1" because the engine subsystem that reads template data was in its third iteration when the game shipped). This is the format version of all instance files in all releases of Oni.

The '''descriptor sizes''' are the sizes of the instance, template, and name descriptors which are coming up in this file (see breakdowns in later sections). For instance, each instance descriptor will be 0x14, or 20 bytes, in length.

The '''descriptor counts''' are the sizes of arrays which are coming up in this file: the instance, name and template descriptors. For instance, the size of the instance descriptor array will be 0x2483, or 9,347 items, in length.

Next we are told the addresses and sizes of the '''data and name block''' in the instance file. The name block simply follows the data block, as you'll see if you add the data block offset plus the data block size, so the name block offset is technically redundant. The name block offset plus the name block size equals the total size of the file since it's the last segment of the file. (However in a .oni file, the order of these blocks is reversed.)

After the name block's size comes four "int"s of '''garbage'''; this is padding in order to align the start of the next segment of the file on a 32-byte boundary. The first two 32-bit fields in this space are, however, used in .oni files generated by OniSplit.

That concludes the header of the instance file. Immediately after this header we find the instance descriptors array.

==Instance descriptors==
The instance descriptor array tells Oni where to find the data and the name of every instance (resource) indexed by the .dat file. The descriptors start at 0x40 in the .dat file, but below is a descriptor found at 0x017B50 in the file which makes a better example. In the table below, we use offsets relative to the start of this descriptor. We also show the alternate structure in the Windows alpha 6, the oldest known version of Oni and the only one with an observed difference in the instance descriptor format.

{| class="wikitable"
|- bgcolor="#E9E9E9"
! width=5% | Offset
! width=5% | Type
! width=10% | Raw Hex
! width=10% | Value
! width=35% | Description (retail)
|- align=center
| 0x00
| tag
| 54 42 55 53
| 'SUBT'
|align=left | template tag
|- align=center
| 0x04
| int32
| C8 30 22 00
| 0x2230C8
|align=left | data offset (relative to data block)
|- align=center
| 0x08
| int32
| 01 CB 00 00
| 0xCB01
|align=left | name offset (relative to name block)
|- align=center
| 0x0C
| int32
| C0 09 00 00
| 2496
|align=left | data size
|- align=center
| 0x10
| int32
| 00 00 30 00
| 0x300000
|align=left | flags
|}

{{Divhide|Windows alpha 6}}
{| class="wikitable"
|- bgcolor="#E9E9E9"
! width=5% | Offset
! width=5% | Type
! width=10% | Raw Hex
! width=10% | Value
! width=35% | Description (alpha 6)
|- align=center
| 0x00
| int64
| 68 6C 04 00
| 0x46C68
|align=left | template checksum
|- align=center
| 0x08
| tag
| 54 42 55 53
| 'SUBT'
|align=left | template tag
|- align=center
| 0x0C
| int32
| E8 37 18 00
| 0x1837E8
|align=left | data offset (relative to data block)
|- align=center
| 0x10
| int32
| 4E C5 00 00
| 0xC54E
|align=left | name offset (relative to name block)
|- align=center
| 0x14
| int32
| 20 08 00 00
| 2080
|align=left | data size
|- align=center
| 0x18
| int32
| 00 00 30 00
| 0x300000
|align=left | flags
|- align=center
| 0x1C
| int32
| EA 5F A6 39
| {{LocaleDate|2000|08|25}} 08:00:42 AM
|align=left | creation date (seconds since 1/1/1900)
|}
{{Divhide|end}}
The retail version of this instance descriptor tells us that a resource of '''type''' SUBT (a subtitle file for Oni; there are only two of these, one containing all speech subtitles, and one for help messages) has '''data''' that can be found 0x2230C8 bytes into the data block, which we learned from the file header starts at 0x03BCA0. Its '''name''' can be found 0xCB01 bytes into the name block that starts, according to the file header, at 0x28F240.

The data's '''size''' is given as 0x09C0, or 2,496 bytes, but it's important to clarify that this is the total size of the data counting from the resource header to the next 32-byte boundary after the end of this instance's actual data; in other words it is the true total of the space occupied on disk by this instance. This is interesting because the data offset leads you to the start of the instance-specific data which begins 8 bytes after the resource header, so if you erroneously add the data size to the data offset to find the end of the instance data then you will find yourself 8 bytes into the next instance.

Before we proceed, let's expand upon the '''flags''' field.

;Flags - data usage
:0x'''01''' 00 00 00 - unnamed
:0x'''02''' 00 00 00 - placeholder
:0x'''04''' 00 00 00 - never used; intended to mark instance as pointing to duplicate data rather than its own data
:0x'''08''' 00 00 00 - instance's data is being used by duplicate instances as a source

;Flags - Tool mode
The first two of the following bits occur throughout the original .dat files. However all of these bits are ignored by the engine when loading data because they only have relevance at runtime when Oni is in Tool mode:
:0x00 00 '''10''' 00 - touched (unsaved data)
:0x00 00 '''20''' 00 - "in batch file"
:0x00 00 '''40''' 00 - delete upon next save


The flags "unnamed" and "placeholder" require special explanation.

===Unnamed and placeholder resources===
You'll notice that the level file header lists fewer names (7,124) than instances (9,347). That's because there are 3 types of instance:
*Unnamed and not placeholder - they are only referenced by other instances in the same file via instance ID; these are generally what can be considered child data of a named instance (e.g., 3D geometry elements like ABNA are "contained" by AKEV, a level's environment).
*:In vanilla Oni .dats there are some rare occurrences of unnamed non-placeholder ''orphan'' instances (e.g., [[OBD:File types/Naming#TRCM|TRCM]]). These are a form of garbage and are discarded by OniSplit when unpacking a level.
*Named and not placeholder - they can be referenced by other instances in any file and the engine can use their name or template tag to find them.
*Named and placeholder - "placeholder" instances are used in level-specific instance files (i.e. not in level0_Final.dat) to associate an instance ID with a name. For every placeholder resource, there's another one with a matching name in level0_Final.dat that has data in it. The placeholder resource in the instance file is looked up by ID or name and then the engine searches all the loaded files for a non-placeholder instance with the same name, causing it to find the actual file in the global data in level0_Final.dat.

===Peeking ahead at instance name===
Before we talk about the name block in depth, we can peek ahead at the name of this resource using the offset we've just been given. Let's add the offset 0xCB01 to 0x28F240, the file header's address for the name block. This gives us the address 0x29BD41. There we find the string "SUBTsubtitles".

===Peeking ahead at instance data===
The actual subtitle data should be found by adding the offset 0x2230C8 to 0x03BCA0, the file header's address for the data block, to get 0x25ED68. We're going to leave the full details of the data block for later, but below is the data you should actually see for the English Oni SUBT file at this address. You have to consult the [[SUBT]] page to know how to read this data.

{{Table}}
{{OBDth}}
{{OBDtr| 0x08 | char[16] | | AD DE | dead | unused }}
{{OBDtr| 0x18 | offset | | 80 44 44 01 | 0x01444480 | raw file data address }}
{{OBDtr| 0x1C | int32 | | 61 02 00 00 | 609 | array size }}
|}

After '''padding''' of 16 unused bytes, we find that, instead of data, there's an address of the actual data: it's in the level's raw file. Open level0_Final.raw and jump to address 0x01444480, and you should see "01_01_01 Griffin: Give me another reading.", and the rest of some very familiar dialogue continuing from there.

The '''array size''' of 609 tells the part of the engine that reads SUBT data to expect a chunk of 609 subtitled lines of dialogue.

==Name descriptors==
The name descriptor array starts immediately after the instance descriptors array. To find the end of the instance descriptors, we can simply take the size of an instance descriptor, 20 bytes, and multiply it by the number of instance descriptors in the file header. In this case, that means 20 * 9347 = 186940, or 0x02DA3C. Adding that to 0x40 (the start of the instance descriptors) takes us to address 0x02DA7C. Voila, the start of the name descriptors.

The name descriptor array stores the numbers of all named instances in the alphabetical order by said names, which are found in the name block but also pointed to by these entries. This array is used by the engine to look up instances by name; it's also used to find instances by template (scanning just the tag at the start of each name). The purpose of this array being alphabetized was to allow the engine to do a binary search to find instances by name more quickly, but the retail engine no longer attempts a binary search and merely iterates over the array from start to end.

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | int32 | | 15 16 00 00 | 5653 | instance descriptor index }}
{{OBDtr| 0x04 | int32 | | 60 2C 1C 0E | (garbage) | runtime: pointer to instance name }}
|}

The index number here is referring to the instance's position in the instance descriptor array. This number is also used by the data block to identify each instance, thus it is found in two places in the data explicitly and one place implicitly.

Since the addresses of the names in memory cannot be known until the file is loaded into RAM, a space of 32 bits is reserved for each pointer at runtime.

==Template descriptors==
Likewise, the template descriptor array starts directly after the name descriptors. Since name descriptors are 8 bytes, 8 * 7124 (taken from the header) = 56992, or 0xDEA0, and adding that to the name descriptor array's start address (0x02DA7C) gives us 0x03B91C as the start of the template descriptors.

The template descriptor array contains information about all templates (that is, resource types, aka tags), used in the file (56 in this case, as we learned from the file header). Any resource occurring in this instance file has to have its type listed here. Here is the template descriptor at 0x3B9FC:

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | int64 | | 3C B9 A6 71 08 00 00 00 | 0x871A6B93C | template checksum }}
{{OBDtr| 0x08 | tag | | 45 47 52 54 | 'EGRT' | template tag }}
{{OBDtr| 0x0C | int32 | | 01 00 00 00 | 1 | unused: number of resources in file that use this template }}
|}

The '''template checksum''' is used to prevent loading of instance files that are not compatible with the current engine version. The '''tag''' is the same kind of number-written-as-backwards-ASCII that we discussed in the "Backwards and garbage data" section; in this case, 'EGRT' means [[TRGE]]. The field for the '''number of resources''' using this template is unused. The number should be correct for each template, but Oni never uses it for anything.

You might wonder how Oni knows how to read each type of data, such as a SUBT or an ABNA. The simple answer is that this information is hard-coded into Oni. In fact, the information on each instance type, as stored in Oni's code, is actually the real "template". The file data merely gives the tag and checksum that identify the template in use so that Oni knows how to read the following data fields. These hardcoded templates also tell Oni which parts of the file data are reserved for pointers.

That's because an instance may have pointers to other related instances, but pointers are only valid in memory; they cannot be stored meaningfully on disk. They must be set at runtime when the level data is loaded into memory and an address in RAM has been assigned. Thus one type of data field in Oni's templates is a "raw data" pointer; on Macs and the Windows demo, there is an additional "separate data" pointer. These pointers are 32 bits in length, as one must expect since Oni was compiled for 32-bit PCs.

Incidentally, the templates in Oni's code have not just the familiar four-character tags attached to them, but also a descriptive string, e.g. "BSP Tree Node Array". These strings were typed into the source code where each template structure was defined, and eventually extracted from the binary by modders. This is the source of the names on [[OBD:File types]].

==Data block==
The data block occupies the majority of the file and stores all the instance data (though this data sometimes points to the location of more data in a raw/separate file). We peeked at this block before when we looked at the instance descriptor for SUBTsubtitles. The block's starting point is found at the offset given in the header, in this case 0x03BCA0, saving us the trouble of adding up the size of the four preceding segments of the file and then aligning to the next 32-byte boundary.

The reason we'd need to align to 32 bytes is that the start of each instance's record (the instance ID) is always 32 byte-aligned. Thus, even though the template descriptors ended at 0x03BC9C, there are four empty bytes here so that the data block can begin at 0x03BCA0, which divides evenly by 32. This alignment rule also means that the instance-specific data will always start at an offset like 0x0008, 0x0028, 0x0148, etc.

The instance ID and file ID are not actually part of the instance data but are considered to be the resource header. The engine always keeps pointers to the start of the type-specific data itself; we saw this before when we jumped to 0x25ED68 and saw the data for the SUBT rather than the header for this data. The instance ID and file ID are accessed using negative offsets when needed (usually to find the name or template tag of an instance, given a pointer to it).

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | res_id | | 01 0B 04 00 | 1035 | instance descriptor index }}
{{OBDtr| 0x04 | lev_id | | 01 00 00 06 | 3 | level number }}
{{OBDtr| 0x08 | ... | | ... | ... | type-specific data... }}
|}

This example is taken from level 3 so that the file ID is more instructive. In the OBD documentation, these fields are called res_id and lev_id as seen above.

The '''instance's ID''' is stored as "(instance descriptor index << 8) | 1". Thus the ID for item #1,035 (0x40B) in the instance descriptor index will be encoded as 0x40B01. The official purpose of the '1' is that it was a marker used by the engine at runtime signifying that this instance ID had already been converted to a pointer to a live instance in memory (an instance pointer will always be 8-byte aligned, so it will never have the zero bit set). These pointer flags were retained when the file was written to disk, where they seemingly serve no purpose, but in fact they allow us to differentiate link fields which are truly unused (all zeroes) from a link field which points to instance #0 (since this would be encoded as 01 00 00 00 on disk). At level-load time the flags are cleared and then set again when Oni allocates memory for each instance. The purpose of left-shifting the index number is simply to leave the lowest byte open for the pointer flag.

The '''file ID''' is computed from the number found in the name of the instance file: "(level number << 25) | 1". Thus instances found in level3_Final.dat will have the file ID encoded as 0x6000001. Again, the '1' was used by the engine at runtime to know which file IDs had been converted to pointers at runtime, but it does allow us to tell the difference between a reference to level0_Final (01 00 00 00) and a file ID field that has somehow not been filled in (though this should not happen). The reason for left-shifting the level number so far might have originally been to store it alongside the instance ID and the pointer flag in a single int32, but they are separate int32s now, perhaps so that both IDs can have their own pointer flag.

After the header, the size of each instance's data is of a somewhat arbitrary length depending on the template this instance falls under. As mentioned under "Instance descriptors", the data size given by the descriptor includes the 8-byte resource header and the padding at the end of the data to align the next instance on 32 bytes.

===Looking backward from data to instance===
By the way, if you pick a random place in the data block to look at with a hex editor, how do you know which resource you're looking at? You would look for the highest data offset in the instance descriptor array that is less than your position in the file. Let's say that the string at 0x3BD40 caught our eye: "powerup_ammo". Subtracting the start of the data block, 0x3BCA0, gives us 0xA0 as the position of this string. Now looking back at the instance descriptor array, the instances' data offsets occur every 20 bytes and come directly after the tags. We can see that the first data offset is 0x8 and the next one is 0xF68, thus our offset into the data block of 0xA0 means we are looking at the instance which starts at 0x8. It's the very first instance listed at the start of the instance descriptor array:

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | tag | | 53 47 4E 4F | 'ONGS' | template tag }}
{{OBDtr| 0x04 | int32 | | 08 00 00 00 | 0x08 | data offset (relative to data block) }}
{{OBDtr| 0x08 | int32 | | 00 00 00 00 | 0x00 | name offset (relative to name block) }}
{{OBDtr| 0x0C | int32 | | 60 0F 00 00 | 3936 | data size }}
{{OBDtr| 0x10 | int32 | | 00 00 00 00 | 0 | flags }}
|}

So this tells us that the first data in the data block belongs to the solitary [[ONGS]] resource, and that it extends for 3,936 bytes. Since its name offset is 0x0, it's the first string in the name block, which we can see below is SUBTsubtitles.

==Name block==
This final segment of the file (third-to-last in a .oni, followed by the data and raw/sep blocks) stores all the instance names as C-style ASCII strings (terminated by a zero byte). We peeked at this before when we looked at the instance descriptor for SUBTsubtitles. The start of this block is 32-byte aligned but after that the strings are simply packed end to end, separated only by their null terminator. As with the data block, the name block's starting point is given in the header, in this case 0x28F240.

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | string | | 53 55 ... 00 | "SUBTsubtitles" | name string (zero-terminated) }}
|}

These names can be up to 63 characters long, counting the tag. The instance file concludes with the end of the name block, or the raw/sep block in a .oni file.

{{OBD}}

Validate External Links/Exceptions

2026-04-19T22:59:21Z

Iritscen:

If the Validate External Links script is mis-reporting certain external links as issues when they actually work fine or when the link has to be presented that way for a specific reason, add them here in order to exempt them from ValExtLinks' reports. The list is sorted by wiki page name for convenience. Each line supports four comma-separated fields, the first three required:
#The response code that ValExtLinks should expect. For NG and RD links, this should be the exact HTTP response code or the 'curl' result code, whichever applies. You can also put "IW" or "EI" here to exempt a warning about an interwiki or external internal link.
#The recurring "problem" link. Place a '*' as a wildcard at the end of a URL to match multiple links.
#The wiki page that this link is appearing on. Use the proper page name, i.e. underscores where the displayed name has spaces. To exempt this link from Val's report regardless of what page it appears on, put a '*' here.
#(optional) A comment explaining the exception. The only requirements are that the comment be separated from the previous field by a space and that you don't use any commas. The "--"s used below are only for human readability.

<pre>
BEGIN LIST
403,https://dotnet.microsoft.com/en-us/download/dotnet-framework,*
403,https://dev.epicgames.com/*,*
403,https://*.blender.org/*,*
403,https://*.fandom.com/*,*
403,https://*.gamespot.com/*,*
403,https://www.rnd.de/*,*
403,https://wikis.khronos.org/opengl/History_of_OpenGL,AE:ONK/EXE
403,https://www.gamefront.com/games/jedi-knight-iii/file/major-kusanagi,AE_talk:BGI
403,https://www.java.com/en/download/,Anniversary_Edition
403,https://binarygroup.com/,BGI
403,https://x.com/craigmullins3/status/1920384911292207363,Category:Art_by_Craig_Mullins
403,https://x.com/mehvechan,Category:Art_by_Lorraine_Reyes
403,https://x.com/Quantum_Sheep/status/1473397180535029760,Category:Oni_(WAP)_game_images
403,https://www.artstation.com/artwork/D9d2o,Duality
403,https://www.artstation.com/artwork/Jl8YXa,Duality
403,https://www.artstation.com/artwork/4bNKW4,Duality
403,https://www.artstation.com/artwork/l9g5V,Duality
301,http://translate.google.com/#en%7Cja%7CChrysalis,File:Daodan_Chrysalis_in_Chinese.png
403,https://www.artstation.com/artwork/4bNKW4,File:Duality_concept_art_-_BioCorp_VR_avatar.jpg
EI,https://wiki.oni2.net/Special:ListFiles?limit=500&ilsearch=Fallen,File:Fallen_Enemies.jpg -- EI link is necessary because this special page can't take these parameters when linked to internally
403,https://www.fab.com/listings/a1fe637c-ef4d-45de-9a21-9a377d06dee1,File:KatiaVersusKonokoFront.png
403,https://x.com/mehvechan/status/556178295612391425,File:Lorraine_Reyes_with_Konoko_Fully_Armed_standup.jpg
000-92,https://www.adobe.com/products/catalog.html#category=3d-ar,Fuse
000-92,https://helpx.adobe.com/beta/fuse/faq.html,Fuse
404,https://www.autodesk.com/products/fbx/overview,Importing_character_models
000-92,https://www.adobe.com/creativecloud/plans.html,Media_creation_with_artificial_intelligence
EI,http://wiki.oni2.net/Main_Page,MediaWiki:Vector -- necessary EI link to demonstrate circular arrow
EI,http://wiki.oni2.net/Main_Page,MediaWiki:Vector-2022 -- necessary EI link to demonstrate circular arrow
404,https://www.autodesk.com/products/softimage/overview,Mod_Tool
403,https://www.guru3d.com/download/rtss-rivatuner-statistics-server-download,Mouse_control_issues
403,https://www.vgmpf.com/Wiki/index.php?title=Brian_Salter,Music
403,https://www.supreme-network.com/midis/browse/O/3494-oni/13574-konoko-chase,Music/Fanmade
403,https://wikis.khronos.org/opengl/S3_Texture_Compression,OBD:TXMP
403,https://www.sec.gov/Archives/edgar/data/946581/0000891554-00-000145.txt,Oni
403,https://www.sec.gov/Archives/edgar/data/946581/000112528202003845/b320556.htm,Oni
403,https://www.artelino.com/articles/japanese_mythology.asp,Oni_(myth)
403,https://pcsx2.net/,Oni_(PlayStation_2)
000-28,https://mega.nz/#!x9oHxaLZ!-bOo-wwdj1fh925DYv1Qc6ErDSRl2HEgtWC-i2FtxtY,Oni_2_(Angel_Studios) -- Mega doesn't seem to like 'curl'
403,https://pcsx2.net/,Oni_2_(Angel_Studios)/Running
000-28,https://www.echeat.com/free-essay/Symbolism-in-Fahrenheit-451-by-Ray-Bradbury-29746.aspx,Oni2:Phoenix
403,https://www.telegraph.co.uk/news/newstopics/howaboutthat/3328480/Otto-the-octopus-wrecks-havoc.html,Oni2:Slaves_of_War/Neo-Biology
403,https://featuredcreature.com/from-dangerous-fluff-to-bunny-stuff/,Oni2:Slaves_of_War/Neo-Biology
403,http://www.conoserver.org/,Oni2:Slaves_of_War/Neo-Biology
403,https://www.cracked.com/article_19988_the-5-most-nightmarish-worms-planet.html,Oni2:Slaves_of_War/Neo-Biology
403,https://www.cracked.com/article_20078_5-weird-directions-human-evolution-could-have-taken.html,Oni2:Slaves_of_War/Neo-Biology
403,https://www.treehugger.com/rare-interspecies-play-observed-between-dolphins-and-whales-4857038,Oni2:Slaves_of_War/Neo-Biology
403,https://ocean.si.edu/ocean-life/invertebrates/zombie-worms-crave-bone,Oni2:Slaves_of_War/Neo-Biology
403,https://www.viator.com/tours/Rio-de-Janeiro/Niteroi-City-Tour-and-Contemporary-Art-Museum-Admission/d712-8753P7,Oni2:Slaves_of_War/Settings
403,https://www.cracked.com/article_17562_5-horrifying-apocalyptic-scenarios-that-have-already-happened.html,Oni2:Slaves_of_War/Settings
403,https://www.cracked.com/article_19678_6-abandoned-places-that-will-make-awesome-supervillain-lairs.html,Oni2:Slaves_of_War/Settings
403,https://www.peninsula.com/en/newsroom/hong-kong,Oni2:Slaves_of_War/Settings
403,https://www.nexusmods.com/games/oni,OniGalore:Community_portal
302,http://www.gnu.org/copyleft/fdl.html,OniGalore:Copyrights
403,https://www.sfgate.com/entertainment/article/WOMEN-WARRIORS-Forget-Lara-Croft-the-new-3240096.php,Press_coverage
403,https://x.com/robinalexander_/status/1872960359696376127,Restless_Souls/Glossary/Artifacts
000-92,https://www.washingtonpost.com/news/wonk/wp/2015/08/27/trump-the-bible-means-a-lot-to-me-but-i-dont-want-to-get-into-specifics/,Restless_Souls/Glossary/Artifacts
403,https://x.com/elonmusk/status/1882406209187409976,Restless_Souls/Glossary/Artifacts
403,https://www.president.gov.ua/documents/6792022-44249,Restless_Souls/Glossary/Artifacts
302,https://www.golem.de/news/kritik-an-nasa-musk-will-direkt-zum-mars-fliegen-2501-192128.html,Restless_Souls/Glossary/Artifacts
403,https://www.axios.com/2025/01/23/elon-musk-nazi-joke-adl,Restless_Souls/Glossary/Artifacts
403,https://www.axios.com/2022/05/02/mark-esper-book-trump-protesters,Restless_Souls/Glossary/Artifacts
302,https://www.golem.de/news/kuenstliche-intelligenz-grok-3-veraergert-maga-anhaenger-2505-195906.html,Restless_Souls/Glossary/Artifacts
403,https://www.luzernerzeitung.ch/kultur/debatte-das-ende-des-westens-ist-da-was-heisst-das-fuer-die-schweiz-und-europa-ld.2751339,Restless_Souls/Glossary/Artifacts
403,https://www.ndtv.com/world-news/transgender-vs-transgenic-mice-row-over-donald-trumps-animal-experiments-claim-7867258,Restless_Souls/Glossary/Artifacts
000-92,https://www.washingtonpost.com/archive/politics/1997/04/24/russia-china-sign-new-friendship-pact/896539b8-c583-44f2-8a73-095cbad1e784/,Restless_Souls/Glossary/Artifacts
403,https://www.economist.com/by-invitation/2022/03/11/john-mearsheimer-on-why-the-west-is-principally-responsible-for-the-ukrainian-crisis,Restless_Souls/Glossary/Artifacts
403,https://www.nytimes.com/2025/09/18/us/politics/trump-fcc-licenses.html,Restless_Souls/Glossary/Artifacts
000-92,https://www.washingtonpost.com/national-security/2025/09/18/trump-taiwan-arms-sales-military-aid/,Restless_Souls/Glossary/Artifacts
403,https://x.com/LAGovJeffLandry/status/2002950029494124986,Restless_Souls/Glossary/Artifacts
302,https://www.derstandard.de/story/3000000301573/putin-gab-sich-bei-seiner-jahrespressekonferenz-wieder-einmal-volksnah,Restless_Souls/Glossary/Artifacts
403,https://www.politico.com/news/2025/06/02/pentagon-greenland-northern-command-00381223,Restless_Souls/Glossary/Artifacts
303,https://link.springer.com/article/10.1007/s41748-026-01073-y,Restless_Souls/Glossary/Artifacts
403,https://www.oeaw.ac.at/news/wie-die-wasserkrise-teheran-unter-druck-setzt,Restless_Souls/Glossary/Artifacts
302,https://www.golem.de/news/abschreckungspolitik-taiwan-will-tsmc-fabriken-nicht-von-usa-bombardieren-lassen-2305-174057.html,Restless_Souls/Glossary/de
000-92,https://www.washingtonpost.com/archive/politics/1997/04/24/russia-china-sign-new-friendship-pact/896539b8-c583-44f2-8a73-095cbad1e784/,Restless_Souls/Glossary/de
403,https://www.economist.com/by-invitation/2022/03/11/john-mearsheimer-on-why-the-west-is-principally-responsible-for-the-ukrainian-crisis,Restless_Souls/Glossary/de
403,https://acronyms.thefreedictionary.com/uwl,Restless_Souls/Reconstruction
403,https://acronyms.thefreedictionary.com/uwl,Restless_Souls/Reconstruction/Gapfilling
403,https://acronyms.thefreedictionary.com/SSOB,Restless_Souls/Reconstruction
403,https://acronyms.thefreedictionary.com/SSOB,Restless_Souls/Reconstruction/Gapfilling
000-92,https://www.washingtonpost.com/national-security/2025/08/31/trump-gaza-plan-riviera-relocation/,Restless_Souls/Research/Artifacts
403,https://x.com/MEMRIReports/status/1721097018062606708,Restless_Souls/Research/Artifacts
403,https://x.com/MedvedevRussiaE/status/1821967864947220777,Restless_Souls/Research/Artifacts
403,https://www.nytimes.com/2024/07/24/world/middleeast/gaza-war-hepatitis-polio.html,Restless_Souls/Research/Artifacts
403,https://www.researchgate.net/publication/262485473_The_Russia-China_Security_Partnership_in_the_Asia-Pacific_Region_Conjectural_and_Structural_Dimensions,Restless_Souls/Summary
403,https://www.forbes.com/sites/wadeshepard/2019/10/03/what-china-is-really-up-to-in-africa/,Restless_Souls/Summary
404,https://idw-online.de/de/attachmentdata8851.pdf,Restless_Souls/Technology
403,https://www.unrealengine.com/en-US,Restless_Souls/Wishlist
301,https://www.bungie.net/,Rights
403,https://tsdr.uspto.gov/caseviewer/assignments?caseId=75570211&docIndex=1&searchprefix=sn#docIndex=1,Rights
403,https://acronyms.thefreedictionary.com/WPS,Talk:Hasegawa
403,https://www.ixbt.com/video2/tech_ss2.shtml,Talk:Oni_Model_Extractor
301,https://www.welt.de/debatte/kommentare/plus246585502/Niedergang-Deutschland-zeigt-der-Welt-wie-man-es-nicht-macht.html,Talk:Restless_Souls/Summary
302,https://www.derstandard.at/story/3000000190426/der-nahostkonflikt-in-oesterreichs-klassenzimmer,Talk:Restless_Souls/Summary
303,https://www.bmjv.de/DE/themen/menschenrechte/menschenrechte_node.html,Talk:Restless_Souls/Summary
403,https://www.researchgate.net/figure/S-curves-for-the-established-and-disruptive-technology-Performance_fig2_4899992,Talk:Restless_Souls/Technology
302,https://de.statista.com/statistik/daten/studie/1208627/umfrage/ausbreitung-von-corona-mutationen-in-deutschland/,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/haeufiger-als-andere-modelle-chatgpt-sabotiert-bei-tests-eigene-abschaltung-2505-196561.html,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/microsoft-studie-diese-berufe-veraendert-ki-am-staerksten-2508-198747.html,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/neue-ki-architektur-was-ist-baby-dragon-hatchling-2510-201047.html,Talk:Restless_Souls/Technology
403,https://www.forbes.com/sites/mattnovak/2023/04/11/elon-musk-working-on-ai-at-twitter-despite-calling-for-6-month-pause-report/,Talk:Restless_Souls/Technology
403,https://www.forbes.com/sites/ronschmelzer/2025/10/09/samsung-ai-research-team-builds-a-tiny-model-with-big-powe/,Talk:Restless_Souls/Technology
302,https://www.derstandard.de/story/3000000302571/neuralink-will-gehirn-chips-in-serie-fertigen-operationen-bald-automatisiert,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/claude-opus-4-6-ki-findet-ueber-500-zero-day-luecken-in-open-source-software-2602-205139.html,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/soziales-netzwerk-moltbook-entpuppt-sich-als-ki-trugbild-2602-205141.html,Talk:Restless_Souls/Technology
403,https://medium.com/@aloy.banerjee30/infinite-context-length-in-llms-the-next-big-advantage-in-ai-2550e9e6ce9b,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/hackerbot-claw-ki-agent-kapert-softwareprojekte-auf-github-2603-205990.html,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/unkontrollierbares-fehlverhalten-ki-agenten-werden-zu-immer-groesserem-insider-risiko-2603-206491.html,Talk:Restless_Souls/Technology
403,https://www.unrealengine.com/en-US/blog/a-first-look-at-unreal-engine-5,Talk:UnrealOni
404,https://www.autodesk.com/products/fbx/overview,Template:AutodeskFBX
000-92,https://www.adobe.com/creativecloud/plans.html,Template:Photoshop
403,https://www.sec.gov/Archives/edgar/data/946581/0000891554-00-000145.txt,Timeline_of_development
403,https://www.sec.gov/Archives/edgar/data/946581/000112528202003845/b320556.htm,Timeline_of_development
403,https://www.fab.com/listings/ef9651a4-fb55-4866-a2d9-1b38b028f9c7,UnrealOni/ALS
403,https://www.fab.com/listings/ef9651a4-fb55-4866-a2d9-1b38b028f9c7,UnrealOni/Tutorials
403,https://www.fab.com/listings/a1fe637c-ef4d-45de-9a21-9a377d06dee1,User:Geyser/CharacterTutorialMakeHumanToUE4
EI,https://wiki.oni2.net/Special:AllMessages?prefix=&filter=modified&lang=en&limit=50,User:Iritscen/WikiMods -- EI link is necessary
302,https://m.facebook.com/groups/186656799756?refid=27,User:Samer
403,https://www.speedrun.com/oni,Videos
403,https://www.computerhope.com/jargon/w/wildcard.htm,XmlTools
END LIST
</pre>

[[Category:Wiki Support]]

Oni (no relation)

2026-04-19T22:58:52Z

Iritscen: link fix

Bungie's game '''[[Oni]]''' is sometimes confused with other works and characters titled "Oni". This isn't surprising considering the popularity of the [[Oni (myth)|Japanese mythical ''oni'']]. Below we've listed some prominent examples of other "Oni"s. Due to the shared inspiration, perhaps interesting similarities can occasionally be found.

==Urusei Yatsura's Oni==
In this anime from 1981, "Oni" is the name of an alien race, but the name isn't mentioned much. What's more important is how the myth of the ''oni'' influenced the design of alien character Lum, so see {{SectionLink|Oni (myth)|Aliens}} for information.

==ONI RPG series and OVA==
{| align="right" style="width:260px"
|-
|[[Image:Toma Kijinden Oni - Misao and Akihito transformed.jpg|256px]]
|-
|[[Image:Toma Kijinden Oni - Misao and Akihito normal.jpg|256px]]
|-
|align="center"|In the OVA, Shuramaru meets two characters who can transform into oni like he can.
|}

[[wp:ja:ONIシリーズ|A classic RPG series]] created by Pandora Box, and once popular in Japan, depicted transforming heroes with beast forms. The series is primarily identified by its use of the [[wp:Romanization of Japanese|romanized]] "ONI" rather than the kanji 鬼. Hover over any text below with dotted underlining for a best-effort English translation.
{| class="wikitable"
|-
|GB
|1990-12-08
|鬼忍降魔録 ONI
|{{Hover|Oni Shinobu Komaroku ONI|text=Oni Ninja Demon Descent Record ONI}}
|-
|GB
|1992-02-28
|ONI II 隠忍伝説
|{{Hover|ONI II In'nin Densetsu|text=ONI II Ninja Legend}} ({{Hover|cartridge photo|image=Oni II for the GameBoy.jpg}})
|-
|GB
|1993-02-23
|ONI III 黒の破壊神
|{{Hover|ONI III Kuro no Hakai-shin|text=ONI III Black God of Destruction}}
|-
|GB
|1994-03-11
|ONI IV 鬼神の血族
|{{Hover|ONI IV Kishin no Ketsuzoku|text=Oni IV Bloodline of Demon Gods}}
|-
|SNES
|1994-08-05
|鬼神降臨伝ONI
|{{Hover|Oni Kishin Korin-den ONI|text=Oni Demon God Advent Legend ONI}}
|-
|GB
|1995-03-24
|ONI V 隠忍を継ぐ者
|{{Hover|ONI V In-nin o Tsugu Mono|text=ONI V Ninja Inheritor}}
|-
|SNES
|1996-02-02
|幕末降臨伝ONI
|{{Hover|Bakumatsu Korin-den ONI|text=Bakumatsu Advent Legend ONI}}
|-
|PS1
|2001-03-22
|ONI零〜復活〜
|{{Hover|ONI Rei ~Fukkatsu~|text=Oni Zero ~Resurrection~}}
|-
|DS
|2007-08-30
|ONI零戦国乱世百花繚乱
|{{Hover|ONI Rei Sengoku Ransei Hyakka Ryoran|text=Oni Zero Sengoku Hundred Flower Turbulent Chaos}}
|-
|PS1
|canceled
|ONI零〜流転〜
|{{Hover|ONI Rei ~Ruten~|text=Oni Zero ~Fluidity~}}
|-
|Arcade
|1995
|{{Hover|隠忍ーザニンジャマスター|text=also called おにザニンジャマスター}}
|{{Hover|In'nin/Oni —Za Ninja Masuta–|text=Hidden —The Ninja Master— or Oni —The Ninja Master— }}
|-
|TBA
|2027
|ONI零X
|{{Hover|ONI Zero Kurosu|text=Oni Zero Cross}}
|}

The one game that actually released for PlayStation came out in 2001 and was called ONI Zero ~Resurrection~; thankfully it wasn't for the PS2, which might have been confusing since [[:Image:Mac (JP) box art - front.jpg|Oni's Japanese box]] used a romanized "ONI" too. A 1995 arcade fighting game loosely based in the same universe was called Oni -The Ninja Master-. Despite the game's subtitle already being in katakana-ized English, it was released in the Western world with the inscrutable name [http://www.hardcoregaming101.net/metamoqester/ Metamoqester].

Also in 1995, the game universe was the basis for an anime OVA called [https://www.animenewsnetwork.com/encyclopedia/anime.php?id=5374 Touma Kishinden Oni] ({{Hover|闘魔鬼神伝ONI|text=Tale of the Fighting Demon Demon God ONI}}) consisting of 25 10-minute episodes released on five discs. Incredibly obscure and hard to find, the opening can be seen [https://www.youtube.com/watch?v=Bi7ZZYCC4Qg here]. It's about a young warrior who has to come to terms with his inhuman nature and ability to transform into an "oni".

In 2025, a new game was announced for as-yet-unknown consoles. Expected in 2027, it will be the first new game in 26 years. Its name? Oni Zero X. This is the tenth title in the ONI series released for a home system, so the X may be intended as a Roman numeral. Make sure to see the image released with the announcement [https://www.famitsu.com/article/202509/53761 here]. Why does this seem so familiar?

==Halo's ONI==
See {{SectionLink|Easter eggs|Halo}}.

==Marathon (2026)'s ONI==
See {{SectionLink|Easter eggs|Marathon (2026)}}.

==AT-43's ONI Corporation==
[https://www.orderofgamers.com/games/at-43/ AT-43] was a sci-fi role-playing board game released in 2006 which told the story of several warring factions. One faction is called [https://www.orderofgamers.com/downloads/AT43ONI.pdf ONI], standing for Okamura Non-aligned Industries. They're a mercenary corporation that uses the O serum to create zombie soldiers and builds weapons based off any technology they can get their hands on, then sells them to the highest bidder in the war between the other factions of the game.

Although the original publisher Rackham has been defunct since 2010, the rights to the company's games were [https://www.ontabletop.com/board-games/monolith-announce-rackham-companys-ip/ acquired by] Monolith Edition in 2024, another board game publisher, with the intent of putting the games back in production.

{{Quote|Okamura Kazuo finally met his fate after eight months of work in his new service. He undertook an experiment with a highly-advanced viral strain and put it in the presence of a reagent he had invented.
[…]
The first signs of change that occurred in Okamura took place in the weeks which followed his traumatic experience. The virus changed, developing its own intelligence. The doctor soon discovered that he was inhabited by a gifted host of clear thought, able to speak using his mouth, and able to take partial control of his body. The virus’s personality merged with that of its host. The symbiosis was soon absolute: Okamura Kazuo literally became a new man: he was insensitive to pain, sleep was unnecessary, and all known diseases had no effect on him.
[…]
He revealed his secret only to those he felt able to succeed him, and soon began dreaming of being the pioneer of the next stage of human evolution.|width=50%}}

==Ao Oni==
Ever since [[wp:Ao Oni|Ao Oni]] was released in 2008, it's had a tendency to usurp search results for the word "oni". Intended to be read as "Blue Demon", Ao Oni is based very loosely on the Japanese game of ''oni'', which is equivalent to our game of tag. A child playing this game, once tagged, is called the ''oni'' instead of being called "it", and must catch another player to make them the ''oni''. Ao Oni, despite being a very low budget game, was somehow popular enough to get two live-action movies and a short anime series.

==Street Fighter's Akuma Oni==
[https://streetfighter.fandom.com/wiki/Oni Oni] (sometimes called Akuma Oni or Oni Akuma for clarity) is a "demon" form of long-time Street Fighter character Akuma who has been corrupted by the dark energy of his martial art. He first appeared in Super Street Fighter IV (2011). There is also a [https://www.youtube.com/watch?v=AFTuABAn4i8 Pandora's Box variant of Oni] in Street Fighter X Tekken.

==Agent of Mayhem's Oni==
[[wp:Agents of Mayhem|Agents of Mayhem]], a 2017 open-world action game set in the Saint's Row universe, has a cast of 12 playable characters including [https://www.youtube.com/watch?v=Ej9slYp6QAQ&t=220s Oni, a Japanese hitman].

==ONI: Road to be the Mightiest Oni==
[[Image:ONI Episode Zero manga.jpg|256px|right]]
A 2023 Nintendo Switch title with [https://www.youtube.com/watch?v=358wiFqkx1w a very cute art style] but mixed reviews. A partial game description from the publisher: "The protagonist, Kuuta, attacks the enemy using his club. Kazemaru sucks the enemy's spirit out of its body, and by destroying that spirit, Kuuta can then claim victory. Enjoy an all-new, unique co-op experience by playing both Kuuta and Kazemaru at the same time! […] The player can also level up by running away from pursuing monsters, like a game of tag, and collecting mushrooms that grow in clusters to purchase upgraded clubs."

The main character is himself an oni, a demon warrior, and it seems that his goal is to absorb other oni to get stronger. The children's game of tag, called ''oni'' as mentioned under "Ao Oni" above, is also somehow a part of the gameplay.

==Oxygen Not Included==
A survival game set in a space colony, released in 2019 by Klei Entertainment. No connection to the concept of the Japanese oni, but abbreviated to "ONI" often enough that it competes for attention with Oni in search engine results. People post on our Oni subreddit asking for help with that game. We even had to expand our Discord server's name to "Oni (Bungie, 2001)" to cut down on confused Oxygen fans joining the server.
[[Image:Oni confusion.jpg|center|900px]]

[[Category:Real World]]

OniX

2026-04-19T01:55:09Z

Iritscen: actually forgot why I chose 192; it didn't come out of a hat

{|style="float:right;" border=1 cellspacing=0
|[[Image:OniX icon.png|center|128px]]
{|cellspacing=3
!colspan="2"|OniX
|-
|'''Developer:'''
|align="right"|Team Chrysalis
|-
|style="vertical-align:top;"|'''Version:'''
|align="right"|{{/Change log}} [[/Change log|Change log]]
|-
|style="vertical-align:top;"|'''Supports:'''
|align="right"|Windows 98–Windows 11
|-
|colspan="2" align="right"|Linux via Wine<ref>Linux can run OniX through Wine without any special configuration; see [[Playing in Linux]].</ref>
|-
|colspan="2" align="right"|(Mac support coming later)
|-
|colspan="2"|'''Bug reporting:'''
|
|-
|colspan="2" align="right"|#oni-general channel on {{Discord|label=Discord}}
|}
|}

'''OniX''' is a fan-made rebuild of the [[Oni]] game application, yielding new possibilities for Oni in terms of modding, new engine features, and maintenance for modern operating systems. The initial v1.0 release is intended to replicate "vanilla" Oni as closely as possible while fixing compatibility issues with current operating systems and modern hardware (including HDPI<ref>High DPI, typically defined as a minimum of 220-240 dpi. For an HDPI display, a backing scale above 1x is commonly used (where "1x" means a 1:1 ratio of physical pixel to logical point); this means that controls, text, and everything else on-screen is drawn with more pixels in order to prevent the screen contents from becoming too tiny. The Retina displays on Macs with built-in screens use a 2x (4:1 pixels-per-point) scaling factor. A display in Microsoft Windows which is set to use scaling above 100% raises the effective DPI by using a fractional backing scale, e.g. 125% = 1.25x. In Windows, OniX queries the monitor's effective DPI at its current scaling, and treats any effective DPI ≥ 192 as a 2x backing scale (because 96 dpi is the default in Windows). Setting OniX to a resolution of "1280x960" on such a display will create a 640x480-point window which is drawn with a 2x scaling factor, containing 1280x960 pixels of content.</ref> and HRR<ref>High Refresh Rate, that is, anything above 60 Hz. OniX corrects timing issues and input issues which Oni.exe experienced at high refresh rates.</ref> displays) and upgrading to a new game data versioning system that will make future improvements easier to roll out. A legacy build is offered which will run in anything from Windows 98 to Windows 8. It does this by not supporting certain features of modern Windows which don't impact older computers anyway, e.g. HDPI support.

==Limitations==
OniX does not (yet) support the [[Anniversary Edition]] modding system or implement any features/fixes of the [[Daodan DLL]]. Oni localizations with text in non-English scripts (European, Asian, Cyrillic) will not display correctly, and AE mods with large textures (above 256x256 px) or 32-bit transparency will not work. The features of the Daodan DLL, including full support of AE mods, will be brought to OniX over the following one or two releases.

==Requirements==
*A retail copy of Oni for Windows or Mac. OniX can also run from the Windows demo data without any conversion if you rename the demo's GameDataFolder to GameDataFolderX.
*.NET Framework 3.5. To install it, type 'features' in the Windows menu, choose "Turn Windows features on or off", and configure the settings like [[:Image:NET selection.png|this]]; you can download 3.5 [https://dotnet.microsoft.com/en-us/download/dotnet-framework here] if you don't see it as an option.
*The game data will need to be converted before using OniX for the first time (instructions for this are in the download). However, the data conversion script does not support Windows 98 or Me, so the game data will need to be converted in a newer OS and then copied to a system running one of those OSes.

==Download==
Mod Depot page: [http://mods.oni2.net/node/390 OniX (Windows)]

==Notes==
<references/>

[[Category:Patches]]

Engine terminology

2026-04-17T21:48:34Z

Iritscen: mentioned when PS2 port started; added Particle3 to the list of our favorite subsystems; corrected my rusty Latin

{{UpdatedForOniX|1.0.0}}
Here is a high-level view of the different versions of the Oni engine and a brief introduction to some of the subsystems in the engine. It's meant to be read in tandem with [[Game data terminology]]. For a list of general differences between the Windows, Mac and PS2 versions of Oni, see [[PS2 vs PC]] and [[Mac vs PC]].

==Engine versions==
There are three versions of Oni's engine found in released versions of the game. They are referred to interchangeably by various names.
;Windows retail, Windows, PC, v1.0
This version of the engine can be identified as '''v1.0''' from [[Oni (folder)/readme.txt|its read-me]] but is often referred to as the "Windows" or "PC" engine. This version of the engine was used for all localized Windows releases translated into non-English languages as well.

;Mac, Windows demo, v1.1
This version was used for Mac retail and demo releases and can be identified as '''v1.1''' from [[Oni (folder)/Oni ReadMe|the Mac read-me]], and underwent another month of development after v1.0. It was also used for the Windows demo, but is sometimes referred to as the "Mac" engine for simplicity.  Its most obvious difference is the addition of .sep files to the GameDataFolder which now contain some of the data formerly stored in .raw files. The format of the individual templates is generally unchanged (with minor differences in [[SNDD]] and [[TRAM]]).

;PS2
This version was created by Rockstar North for the PlayStation 2 port. It also uses .sep files but makes additional changes to templates ([[AGQG]], [[IGSt]], [[M3GM]], [[SNDD]], [[TRAM|TRAM/TREX]], [[TSFT]], [[TSGA]] and [[TXMP]]). It went through another 3-4 weeks of development after the Mac version was completed, besides have been developed in parallel with Bungie West's version of the engine starting in early 2000, and could possibly be thought of as a v1.2 engine, but is probably best understood as a fork of the v1.1 engine made for PS2 compatibility.

==Subsystems==
The engine consists of various subsystems, some of which have colorful animé-related names and some of which have boring descriptive names. If an article is devoted to documenting more of that subsystem, it will be linked.

;AI2
The second iteration of the code for driving the [[AI|AIs]] (NPCs).

;Akira
The [[Graphics|environment]] code, responsible for holding the game world in memory. Named for the 1988 film [[wp:Akira (1988 film)|Akira]].

;BFW
A layer rather than a subsystem: stands for "BungieFrameWork". This is the lower layer of the game engine, consisting of generalized cross-platform engine code. The upper layer is simply called "Oni" and contains specializations needed to implement Oni's gameplay logic.

;BSL
Standing for "BFW Scripting Language", this is the subsystem responsible for running Oni's [[BSL|scripting language]].

;Motoko
The renderer code, responsible for drawing Oni's [[graphics]]. Named for the main character of the 1995 film [[Ghost in the Shell]].

;Particle3
The third iteration of the particle code, responsible for special effects and weapon projectiles. Often called PAR3 for short due to the [[PAR3]] template tag.

;Totoro
The code for Oni's 3D [[Animation|animation system]]. Named for the 1988 film [[wp:My Neighbor Totoro|My Neighbor Totoro]].

;''Et alii''
There are various other subsystems that we essentially never talk about, such as LocalInput, WindowManager, SoundSystem2 and TemplateManager.

[[Category:Engine docs]]

Timeline of development

2026-04-17T21:43:12Z

Iritscen: added date of PS2 port announcement

{{Hatnote|For the full story of Oni's development, see [[Oni]]. For detailed information on the continued updates for Mac after release, see [[History of Mac Oni]].}}
The Oni project started development in April of 1997 and ran for approximately 3 years, 9 months, ending in January of 2001. Through this time, the [[Bungie West]] team ran into unexpected technical and design hurdles, resulting in a much longer development period than planned. The initial internal deadline for the game, October 1999, was gradually pushed back quarter by quarter until the game was finished in the time period from November 2000 to January 2001, depending on the platform.

The development of the game was accompanied by unexpected events such as a financial blow to Bungie from the Myth II uninstaller bug, a partial buyout by Take-Two Interactive, turnover on the staff and a change of project lead, and then a complete buyout by Microsoft. Only a sustained crunch period at the end of development, pushing Bungie West to their limits, allowed the game to be finished to a degree where it was ready to ship, and cuts to the game were still required such as the removal of multiplayer mode.

The dates below are sometimes approximate but are mostly supported by hard evidence, as seen in the citations.

{{Timeline
|event1date=Apr. 2, 1997
|event1text=Engine quietly begins development under Brent Pease per dates in source code Projected release date is "October 1999"{{ref|note=See [[Oni/Positioning]]}}
|event2date=July 1997
|event2text=Bungie West announces they are hiring{{ref|note=[https://marathon.bungie.org/story/blastfromthepast.html Marathon Story Page: Blasts from the Past]. Note that [https://marathon.bungie.org/story/BungieWest/job.html this copy of the Bungie West job ad] is stated to have the wrong date at the bottom of the page.}}
|event3date=Dec. 31, 1997
|event3text=Bungie West gets their content authoring pipeline working{{ref|note=[http://web.archive.org/web/20010302193919/http://www.insidemacgames.com/previews/99/oni/oni2.shtml Inside Mac Games: "Sneak Preview: Oni"]}}
|event4date=May 28, 1998
|event4text=Oni is announced along with Myth II at E3{{ref|note=[https://marathon.bungie.org/story/blastfromthepast.html Marathon Story Page: Blasts from the Past]. Note that [https://web.archive.org/web/20000422020741/http://pc.ign.com/news/5839.html this official press release] was months late.}}{{ref|name="monsters"|note=[https://chicagoreader.com/news/monsters-in-a-box/ Chicago Reader: "Monsters in a Box"]}}
|event5date=Dec. 28, 1998
|event5text=Myth II uninstaller bug is discovered, costs Bungie about $800,000{{ref|name="monsters"}}
|event6date=May 14, 1999
|event6text=Oni appears at E3 with hands-on demo running in multiplayer mode{{ref|name="mp"|note=See [[Multiplayer]] for video evidence}} Release date is estimated as early 2000{{ref|note=[https://web.archive.org/web/20000817003431/http://www.insidemacgames.com/features/99/e3report/e3-2.shtml IMG: "Feature: The E3 Report - Page 2"]}} "Blam" project is shown three days later to a select group behind closed doors{{ref|note=[https://web.archive.org/web/20000815110548/http://www.insidemacgames.com/features/99/e3report/e3.shtml IMG: "Feature: The E3 Report"]}}
|event7date=Jul. 21, 1999
|event7text=Oni appears at Macworld NY running in multiplayer mode{{ref|name="mp"}} Halo is announced{{ref|note=[https://marathon.bungie.org/story/Halo_press_release_21July99.html Bungie: "Halo Brings Action Gamers a World Without End"]}}
|event8date=Aug. 12, 1999
|event8text=Take-Two Interactive announces that it will purchase 19.9% stake in Bungie, becoming the distributor for Oni and Halo;{{ref|name="T2"|note=[https://web.archive.org/web/20000118055725/http://pc.ign.com/news/9525.html IGN: "Take-Two Take Bungie"]}} purchase occurs in November{{ref|note=[https://www.sec.gov/Archives/edgar/data/946581/0000891554-00-000145.txt SEC 10-K filing for Take-Two Interactive]}} Oni's stated release date is "before Christmas" 1999{{ref|name="T2"}}
|event9date=Sept. 29, 1999
|event9text=Sell sheet gives "Q1 2000" as release date{{ref|note=See [[:Image:Info sheet.jpg]]}}
|event10date=Nov. 19, 1999
|event10text=GameSpot email gives "summer 2000" as release date{{ref|note=[https://carnage.bungie.org/oniforum/oni.forum.pl?read=1129 Oni Central Forum: "New Oni Preview Coming Up..."]}}
|event11date=Dec. 20, 1999
|event11text=Brent Pease leaves the Oni team{{ref|note=[https://carnage.bungie.org/oniforum/oni.forum.pl?read=1410 Oni Central Forum: "Brent Pease leaves Bungie?"]}}
|event12date=Jan. 5, 2000
|event12text=Oni appears at Macworld SF; on BungieTV, the game is demonstrated in multiplayer mode by Bungie staffers{{ref|name="mp"}}
|event13date=Feb. 20, 2000
|event13text=Oni's release date is listed as "summer 2000" by Take-Two{{ref|note=[http://oni.bungie.org/newsarchives/2000/feb00.html#take2 Oni Central: News for February 2000]}}
|event14date=Mar. 16, 2000
|event14text=The PlayStation 2 port is officially announced.{{ref|note=[http://oni.bungie.org/newsarchives/2000/mar00.html#breaking Oni Central: "Oni is coming for the PS2"]}}{{ref|note=[https://web.archive.org/web/20000511043021/http://www.bungie.com/corporate/press/oni_ps2.shtml Bungie.com: "Take-Two Interactive Software's Rockstar Games Announces Oni for the Playstation 2"]}} The port had actually begun a short while earlier.{{ref|note=[https://carnage.bungie.org/oniforum/oni.forum.pl?read=2421 Oni Central Forum: "Re: Question asking time...."]}}
|event15date=May 13, 2000
|event15text=The announcement is made that multiplayer mode has been canceled{{ref|note=[https://carnage.bungie.org/oniforum/oni.forum.pl?read=3216 Oni Central Forum: "Rant here... I think its a good rant ;)"]}}
|event16date=Jun. 19, 2000
|event16text=Microsoft purchases 100% stake in Bungie and Take-Two gains full IP rights over Oni and Myth{{ref|note=[https://www.ign.com/articles/2000/06/20/microsoft-buys-bungie-take-two-buys-oni-ps2-situation-unchanged IGN: "Microsoft Buys Bungie, Take Two Buys Oni, PS2 Situation Unchanged"]}}{{ref|note=[https://www.sec.gov/Archives/edgar/data/946581/000112528202003845/b320556.htm SEC 10-K filing for Take-Two Interactive]}}
|event17date=Jul. 25, 2000
|event17text=Gathering of Developers email gives "October 2000" as release date
|event18date=Aug. 28, 2000
|event18text=Oni enters beta phase of development{{ref|note=[http://carnage.bungie.org/oniforum/oni.forum.pl?read=4556 Oni Central Forum: "New news groups?"]}}
|event19date=Sept. 11, 2000
|event19text=A GameSpot UK article covering the European Computer Trade Show reports a show floor statement that Oni's release date is March 2001,{{ref|note=[https://carnage.bungie.org/oniforum/oni.forum.pl?read=4699 Oni Central Forum: "What the...?!?"]}} which is then disputed by Bungie employees and others; in the end it turns out to be accurate for the European releases but not the North American release
|event20date=Nov. 4, 2000
|event20text=Creation date on game data files in the Windows retail release
|event21date=Nov. 8, 2000
|event21text=Gathering of Developers announces the final North American release date of January 29, 2001 for all three platforms{{ref|note=[https://web.archive.org/web/20001213051800/http://www.imgmagazine.com/news/story.php?ArticleID=1400 IMG News: "Oni Release Date"]}}
|event22date=Nov. 17, 2000
|event22text=Oni is gold mastered for Windows{{ref|note=[http://oni.bungie.org/newsarchives/2000/nov00.html#xbox Oni Central: News for November 2000]}}
|event23date=Nov. 20, 2000
|event23text=Creation date on game data files in the Windows demo and Mac retail release (in .sep format)
|event24date=Dec. 15, 2000
|event24text=Bungie West officially moves to Microsoft's headquarters at Redmond{{ref|note=[https://web.archive.org/web/20010413012240/http://www.haloplayers.com/features/haloupdates/index?976977146 HaloPlayers.com: "Matt's Halo Update - December 15, 2000"]}}
|event25date=Dec. 17, 2000
|event25text=Windows demo released{{ref|note=[http://carnage.bungie.org/oniforum/oni.forum.pl?read=7479 Oni Central Forum: "ONI DEMO!"]}}
|event26date=Dec. 20, 2000
|event26text=Oni is gold mastered for Mac, based on the date on the retail application and the release of the Mac demo{{ref|note=See [[:Image:Classic Mac Oni Get Info window.png]]}}{{ref|note=[https://carnage.bungie.org/oniforum/oni.forum.pl?read=8045 Oni Central Forum: Mac Demo News]}}
|event27date=Dec. 21, 2000
|event27text=Mac demo released{{ref|note=[https://www.insidemacgames.com/historical/news/story.php%3FArticleID=1744.html Inside Mac Games News: "Oni Demo Released"]}}
|event28date=Jan. 22, 2001
|event28text=Oni is gold mastered for PlayStation 2{{ref|note=[https://web.archive.org/web/20010128150200/http://www.dailyradar.com/news/game_news_6691.html Daily Radar: "Oni Gets SCEA's Approval ", Jan. 22, 2001]}}
|event29date=Jan. 29, 2001
|event29text=Official release date for Oni in North America on Mac, Windows and PS2{{ref|note=[http://oni.bungie.org/newsarchives/2001/jan01.html Oni Central: News for January 2001]}}{{ref|name="GOD release"|note=[https://web.archive.org/web/20010617133132/http://www.godgames.com/main.php?section=news&page=press&pr=ONI_Ships Godgames.com: "Gathering of Developers Ships Oni Nationwide for the PC and Macintosh"]}}{{ref|note=[https://www.gamespot.com/articles/oni-receives-final-approval/1100-2676645/ GameSpot: "Oni Receives Final Approval"]}}
}}
 
==References==
{{Reflist}}

[[Category:Oni history]]

OBD:Instance file format

2026-04-17T20:29:35Z

Iritscen: discovered the hard way that the "+1" on the instance ID actually has value

{{UpdatedForOniX|1.0.0}}
{{OBD Home}}
{{Hatnote|".dat" redirects here; for other files ending in ".dat", see [[Oni (folder)]]. 
:You should read [[Engine terminology]] and [[Game data terminology]] before this page. 
:The [[raw|Raw and separate file formats]] page should be read after this one.}}
Files in GameDataFolder/ named "level[0-19]_Final.dat", together with ".raw" and sometimes ".sep" counterparts, contain the game data for Oni. These are called "instance files" internally, but a more common-sense name for them is level data files. The format described below was also used for the tool files which supplied the GUI for the in-game editor, however the retail Oni game application refuses to load tool files; for the story behind the tool files, see [[level0_Tools]].

The level 0 files do not contain resources for a specific level but rather resources (instances) shared across all levels. Level 0 is loaded when the game starts and is never unloaded. All other level files, 1-19, are only loaded when their corresponding level starts and then unloaded when it ends. Oni can only hold two level files in memory concurrently, thus resources have to be duplicated on disk whenever a character class, sound effect, etc. occurs in more than one level. For instance, although there are only 2,380 unique sounds in the game, there are 7,386 sounds stored across all level data files.
{{TOClimit}}
==Blank space and garbage==
The structure of the level data files files reflects the way in which Bungie West chose to store levels in memory. So when we read the data in the files with a hex editor we can see eccentricities such as blank space coming from unused fields and byte-alignment padding, and garbage data such as now-meaningless pointer values and random RAM contents from uninitialized memory. There are also [[OBD:Raw and separate file formats#Gaps|gaps in the .raw/.sep files]], mostly representing orphaned obsolete resources, which add up to about 25 MB for the whole game.

==Backwards tags==
Because the levels were built on Intel-based machines, which use a little-endian architecture, sequences of bytes which represent numbers were written from least-significant to most-significant byte. [[wp:FourCC|FourCCs]] in the data are stored "backwards" (e.g. "13RV" which is meant to be read "VR31") because Bungie defined those four bytes as a 32-bit integer, not a string, causing them to be written to disk in little-endian order.

==File limits==
*Max level number: 127
*Max number of instance files in GameDataFolder: 512 (Windows retail), 16 (Windows demo, Mac)
*Max number of simultaneously loaded instance files: 64
*Max number of instances in a file: 131071
*Max length of an instance file name: 31
*Max length of an instance name: 63 (including the 4 character template tag)

==Header==
Here is a walkthrough of an instance file using the level0_Final.dat in English Windows Oni. Follow along in a hex editor for maximum educational value. Each term will be explained in-depth when we fully consider the related data. First, here is how the file begins:
{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | uint64 | | 1F 27 DC 33 DF BC 03 00 | 0x0003BCDF33DC271F | Total template checksum (main indicator of engine compatibility):
*0x0003BCDF33DC271F - templates compatible with v1.0 engine (Windows retail)
*0x0003BCDF23C13061 - templates compatible with v1.1 engine (Windows demo and Mac)
*0x0003BA70A8DBAE11 - templates compatible with PlayStation 2 engine

OniSplit's .oni files use PC 1.0 checksum by default and 1.1 checksum when storing data that comes from the 1.1 engine and which perceptibly differs in format for that engine (SNDD, but not TXMP) }}
{{OBDtr| 0x08 | uint32 | | 31 33 52 56 | '13RV' | .dat version (meant to be read as "VR31") OniSplit's .oni files use '23RV' ("VR32") instead }}
{{OBDtr| 0x0C | uint16 | | 40 00 | 64 | size of this header }}
{{OBDtr| 0x0E | uint16 | | 14 00 | 20 | size of instance descriptor (32 in Windows alpha 6) }}
{{OBDtr| 0x10 | uint16 | | 10 00 | 16 | size of template descriptor }}
{{OBDtr| 0x12 | uint16 | | 08 00 | 8 | size of name descriptor }}
{{OBDtr| 0x14 | uint32 | | 83 24 00 00 | 9347 | instance descriptor count }}
{{OBDtr| 0x18 | uint32 | | D4 1B 00 00 | 7124 | name descriptor count; 0 for .oni files because there is no name desc. table }}
{{OBDtr| 0x1C | uint32 | | 38 00 00 00 | 56 | template descriptor count; 0 for .oni files because there is no template desc. table }}
{{OBDtr| 0x20 | uint32 | | A0 BC 03 00 | 0x03BCA0 | data block offset }}
{{OBDtr| 0x24 | uint32 | | A0 35 25 00 | 2438560 | data block size }}
{{OBDtr| 0x28 | uint32 | | 40 F2 28 00 | 0x28F240 | name block offset; will be lower than data block offset for .oni files }}
{{OBDtr| 0x2C | uint32 | | 04 4F 02 00 | 151300 | name block size }}
{{OBDtr| 0x30 | uint32 | | 99 CF 40 00 | (garbage) | used by OniSplit for raw/sep block offset }}
{{OBDtr| 0x34 | uint32 | | 90 4F 63 00 | (garbage) | used by OniSplit for raw/sep block size }}
{{OBDtr| 0x38 | uint32 | | F4 55 5F 00 | (garbage) | unused }}
{{OBDtr| 0x3C | uint32 | | 90 4F 63 00 | (garbage) | unused }}
|}

The file's '''total template checksum''' is the sum of all the template checksums (see "Template descriptors" below). Oni looks at this number in order to validate that it can read this version of the game data format. In practical terms, the total checksum value given for Windows above tells us that this level data is in the .dat/.raw file scheme, and the value given for Mac Oni and the Windows demo tells us that the level data uses the .dat/.raw/.sep file scheme.

The '''version''' of the instance file is the format version. Reading it backwards, as discussed under the "Backwards and garbage data" section, we get "VR31" (which probably means "version 3.1" because the engine subsystem that reads template data was in its third iteration when the game shipped). This is the format version of all instance files in all releases of Oni.

The '''descriptor sizes''' are the sizes of the instance, template, and name descriptors which are coming up in this file (see breakdowns in later sections). For instance, each instance descriptor will be 0x14, or 20 bytes, in length.

The '''descriptor counts''' are the sizes of arrays which are coming up in this file: the instance, name and template descriptors. For instance, the size of the instance descriptor array will be 0x2483, or 9,347 items, in length.

Next we are told the addresses and sizes of the '''data and name block''' in the instance file. The name block simply follows the data block, as you'll see if you add the data block offset plus the data block size, so the name block offset is technically redundant. The name block offset plus the name block size equals the total size of the file since it's the last segment of the file. (However in a .oni file, the order of these blocks is reversed.)

After the name block's size comes four "int"s of '''garbage'''; this is padding in order to align the start of the next segment of the file on a 32-byte boundary. The first two 32-bit fields in this space are, however, used in .oni files generated by OniSplit.

That concludes the header of the instance file. Immediately after this header we find the instance descriptors array.

==Instance descriptors==
The instance descriptor array tells Oni where to find the data and the name of every instance (resource) indexed by the .dat file. The descriptors start at 0x40 in the .dat file, but below is a descriptor found at 0x017B50 in the file which makes a better example. In the table below, we use offsets relative to the start of this descriptor. We also show the alternate structure in the Windows alpha 6, the oldest known version of Oni and the only one with an observed difference in the instance descriptor format.

{| class="wikitable"
|- bgcolor="#E9E9E9"
! width=5% | Offset
! width=5% | Type
! width=10% | Raw Hex
! width=10% | Value
! width=35% | Description (retail)
|- align=center
| 0x00
| tag
| 54 42 55 53
| 'SUBT'
|align=left | template tag
|- align=center
| 0x04
| int32
| C8 30 22 00
| 0x2230C8
|align=left | data offset (relative to data block)
|- align=center
| 0x08
| int32
| 01 CB 00 00
| 0xCB01
|align=left | name offset (relative to name block)
|- align=center
| 0x0C
| int32
| C0 09 00 00
| 2496
|align=left | data size
|- align=center
| 0x10
| int32
| 00 00 30 00
| 0x300000
|align=left | flags
|}

{{Divhide|Windows alpha 6}}
{| class="wikitable"
|- bgcolor="#E9E9E9"
! width=5% | Offset
! width=5% | Type
! width=10% | Raw Hex
! width=10% | Value
! width=35% | Description (alpha 6)
|- align=center
| 0x00
| int64
| 68 6C 04 00
| 0x46C68
|align=left | template checksum
|- align=center
| 0x08
| tag
| 54 42 55 53
| 'SUBT'
|align=left | template tag
|- align=center
| 0x0C
| int32
| E8 37 18 00
| 0x1837E8
|align=left | data offset (relative to data block)
|- align=center
| 0x10
| int32
| 4E C5 00 00
| 0xC54E
|align=left | name offset (relative to name block)
|- align=center
| 0x14
| int32
| 20 08 00 00
| 2080
|align=left | data size
|- align=center
| 0x18
| int32
| 00 00 30 00
| 0x300000
|align=left | flags
|- align=center
| 0x1C
| int32
| EA 5F A6 39
| {{LocaleDate|2000|08|25}} 08:00:42 AM
|align=left | creation date (seconds since 1/1/1900)
|}
{{Divhide|end}}
The retail version of this instance descriptor tells us that a resource of '''type''' SUBT (a subtitle file for Oni; there are only two of these, one containing all speech subtitles, and one for help messages) has '''data''' that can be found 0x2230C8 bytes into the data block, which we learned from the file header starts at 0x03BCA0. Its '''name''' can be found 0xCB01 bytes into the name block that starts, according to the file header, at 0x28F240.

The data's '''size''' is given as 0x09C0, or 2,496 bytes, but it's important to clarify that this is the total size of the data counting from the resource header to the next 32-byte boundary after the end of this instance's actual data; in other words it is the true total of the space occupied on disk by this instance. This is interesting because the data offset leads you to the start of the instance-specific data which begins 8 bytes after the resource header, so if you erroneously add the data size to the data offset to find the end of the instance data then you will find yourself 8 bytes into the next instance.

Before we proceed, let's expand upon the '''flags''' field.

;Flags - data usage
:0x'''01''' 00 00 00 - unnamed
:0x'''02''' 00 00 00 - empty
:0x'''04''' 00 00 00 - never used; intended to mark instance as pointing to duplicate data rather than its own data
:0x'''08''' 00 00 00 - instance's data is being used by duplicate instances as a source

;Flags - Tool mode
The first two of the following bits occur throughout the original .dat files. However all of these bits are ignored by the engine when loading data because they only have relevance at runtime when Oni is in Tool mode:
:0x00 00 '''10''' 00 - touched (unsaved data)
:0x00 00 '''20''' 00 - "in batch file"
:0x00 00 '''40''' 00 - delete upon next save


The flags "unnamed" and "empty" require special explanation.

===Unnamed and empty resources===
You'll notice that the level file header lists fewer names (7,124) than instances (9,347). That's because there are 3 types of instance:
*Unnamed and not empty - they are only referenced by other instances in the same file, generally as child data (e.g., 3D geometry elements like ABNA are "contained" by AKEV, a level's environment).
*:In vanilla Oni .dats there are some rare occurrences of unnamed non-empty ''orphan'' instances (e.g., [[OBD:File types/Naming#TRCM|TRCM]]). These are a form of garbage and are discarded by OniSplit when unpacking a level.
*Named and not empty - they can be referenced by other instances in any file and the engine can use their name or template tag to find them.
*Named and empty - "empty" instances are used in level-specific instance files (i.e. not in level0_Final.dat) to associate an instance ID with a name. For every empty resource, there's another one with a matching name in level0_Final.dat that has data in it. The empty resource in the instance file is (usually) looked up by ID, then the engine searches all the loaded files for a non-empty instance with the same name, causing it to find the actual file in the global data in level0_Final.dat.

===Peeking ahead at instance name===
Before we talk about the name block in depth, we can peek ahead at the name of this resource using the offset we've just been given. Let's add the offset 0xCB01 to 0x28F240, the file header's address for the name block. This gives us the address 0x29BD41. There we find the string "SUBTsubtitles".

===Peeking ahead at instance data===
The actual subtitle data should be found by adding the offset 0x2230C8 to 0x03BCA0, the file header's address for the data block, to get 0x25ED68. We're going to leave the full details of the data block for later, but below is the data you should actually see for the English Oni SUBT file at this address. You have to consult the [[SUBT]] page to know how to read this data.

{{Table}}
{{OBDth}}
{{OBDtr| 0x08 | char[16] | | AD DE | dead | unused }}
{{OBDtr| 0x18 | offset | | 80 44 44 01 | 0x01444480 | raw file data address }}
{{OBDtr| 0x1C | int32 | | 61 02 00 00 | 609 | array size }}
|}

After '''padding''' of 16 unused bytes, we find that, instead of data, there's an address of the actual data: it's in the level's raw file. Open level0_Final.raw and jump to address 0x01444480, and you should see "01_01_01 Griffin: Give me another reading.", and the rest of some very familiar dialogue continuing from there.

The '''array size''' of 609 tells the part of the engine that reads SUBT data to expect a chunk of 609 subtitled lines of dialogue.

==Name descriptors==
The name descriptor array starts immediately after the instance descriptors array. To find the end of the instance descriptors, we can simply take the size of an instance descriptor, 20 bytes, and multiply it by the number of instance descriptors in the file header. In this case, that means 20 * 9347 = 186940, or 0x02DA3C. Adding that to 0x40 (the start of the instance descriptors) takes us to address 0x02DA7C. Voila, the start of the name descriptors.

The name descriptor array stores the numbers of all named instances in the alphabetical order by said names, which are found in the name block but also pointed to by these entries. This array is used by the engine to look up instances by name; it's also used to find instances by template (scanning just the tag at the start of each name). The purpose of this array being alphabetized was to allow the engine to do a binary search to find instances by name more quickly, but the retail engine no longer attempts a binary search and merely iterates over the array from start to end.

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | int32 | | 15 16 00 00 | 5653 | instance descriptor index }}
{{OBDtr| 0x04 | int32 | | 60 2C 1C 0E | (garbage) | runtime: pointer to instance name }}
|}

The index number here is referring to the instance's position in the instance descriptor array. This number is also used by the data block to identify each instance, thus it is found in two places in the data explicitly and one place implicitly.

Since the addresses of the names in memory cannot be known until the file is loaded into RAM, a space of 32 bits is reserved for each pointer at runtime.

==Template descriptors==
Likewise, the template descriptor array starts directly after the name descriptors. Since name descriptors are 8 bytes, 8 * 7124 (taken from the header) = 56992, or 0xDEA0, and adding that to the name descriptor array's start address (0x02DA7C) gives us 0x03B91C as the start of the template descriptors.

The template descriptor array contains information about all templates (that is, resource types, aka tags), used in the file (56 in this case, as we learned from the file header). Any resource occurring in this instance file has to have its type listed here. Here is the template descriptor at 0x3B9FC:

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | int64 | | 3C B9 A6 71 08 00 00 00 | 0x871A6B93C | template checksum }}
{{OBDtr| 0x08 | tag | | 45 47 52 54 | 'EGRT' | template tag }}
{{OBDtr| 0x0C | int32 | | 01 00 00 00 | 1 | unused: number of resources in file that use this template }}
|}

The '''template checksum''' is used to prevent loading of instance files that are not compatible with the current engine version. The '''tag''' is the same kind of number-written-as-backwards-ASCII that we discussed in the "Backwards and garbage data" section; in this case, 'EGRT' means [[TRGE]]. The field for the '''number of resources''' using this template is unused. The number should be correct for each template, but Oni never uses it for anything.

You might wonder how Oni knows how to read each type of data, such as a SUBT or an ABNA. The simple answer is that this information is hard-coded into Oni. In fact, the information on each instance type, as stored in Oni's code, is actually the real "template". The file data merely gives the tag and checksum that identify the template in use so that Oni knows how to read the following data fields. These hardcoded templates also tell Oni which parts of the file data are reserved for pointers.

That's because an instance may have pointers to other related instances, but pointers are only valid in memory; they cannot be stored meaningfully on disk. They must be set at runtime when the level data is loaded into memory and an address in RAM has been assigned. Thus one type of data field in Oni's templates is a "raw data" pointer; on Macs and the Windows demo, there is an additional "separate data" pointer. These pointers are 32 bits in length, as one must expect since Oni was compiled for 32-bit PCs.

Incidentally, the templates in Oni's code have not just the familiar four-character tags attached to them, but also a descriptive string, e.g. "BSP Tree Node Array". These strings were typed into the source code where each template structure was defined, and eventually extracted from the binary by modders. This is the source of the names on [[OBD:File types]].

==Data block==
The data block occupies the majority of the file and stores all the instance data (though this data sometimes points to the location of more data in a raw/separate file). We peeked at this block before when we looked at the instance descriptor for SUBTsubtitles. The block's starting point is found at the offset given in the header, in this case 0x03BCA0, saving us the trouble of adding up the size of the four preceding segments of the file and then aligning to the next 32-byte boundary.

The reason we'd need to align to 32 bytes is that the start of each instance's record (the instance ID) is always 32 byte-aligned. Thus, even though the template descriptors ended at 0x03BC9C, there are four empty bytes here so that the data block can begin at 0x03BCA0, which divides evenly by 32. This alignment rule also means that the instance-specific data will always start at an offset like 0x0008, 0x0028, 0x0148, etc.

The instance ID and file ID are not actually part of the instance data but are considered to be the resource header. The engine always keeps pointers to the start of the type-specific data itself; we saw this before when we jumped to 0x25ED68 and saw the data for the SUBT rather than the header for this data. The instance ID and file ID are accessed using negative offsets when needed (usually to find the name or template tag of an instance, given a pointer to it).

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | res_id | | 01 0B 04 00 | 1035 | instance descriptor index }}
{{OBDtr| 0x04 | lev_id | | 01 00 00 06 | 3 | level number }}
{{OBDtr| 0x08 | ... | | ... | ... | type-specific data... }}
|}

This example is taken from level 3 so that the file ID is more instructive. In the OBD documentation, these fields are called res_id and lev_id as seen above.

The '''instance's ID''' is stored as "(instance descriptor index << 8) | 1". Thus the ID for item #1,035 (0x40B) in the instance descriptor index will be encoded as 0x40B01. The official purpose of the '1' is that it was a marker used by the engine at runtime signifying that this instance ID had already been converted to a pointer to a live instance in memory (an instance pointer will always be 8-byte aligned, so it will never have the zero bit set). These pointer flags were retained when the file was written to disk, where they seemingly serve no purpose, but in fact they allow us to differentiate link fields which are truly unused (all zeroes) from a link field which points to instance #0 (since this would be encoded as 01 00 00 00 on disk). At level-load time the flags are cleared and then set again when Oni allocates memory for each instance. The purpose of left-shifting the index number is simply to leave the lowest byte open for the pointer flag.

The '''file ID''' is computed from the number found in the name of the instance file: "(level number << 25) | 1". Thus instances found in level3_Final.dat will have the file ID encoded as 0x6000001. Again, the '1' was used by the engine at runtime to know which file IDs had been converted to pointers at runtime, but it does allow us to tell the difference between a reference to level0_Final (01 00 00 00) and a file ID field that has somehow not been filled in (though this should not happen). The reason for left-shifting the level number so far might have originally been to store it alongside the instance ID and the pointer flag in a single int32, but they are separate int32s now, perhaps so that both IDs can have their own pointer flag.

After the header, the size of each instance's data is of a somewhat arbitrary length depending on the template this instance falls under. As mentioned under "Instance descriptors", the data size given by the descriptor includes the 8-byte resource header and the padding at the end of the data to align the next instance on 32 bytes.

===Looking backward from data to instance===
By the way, if you pick a random place in the data block to look at with a hex editor, how do you know which resource you're looking at? You would look for the highest data offset in the instance descriptor array that is less than your position in the file. Let's say that the string at 0x3BD40 caught our eye: "powerup_ammo". Subtracting the start of the data block, 0x3BCA0, gives us 0xA0 as the position of this string. Now looking back at the instance descriptor array, the instances' data offsets occur every 20 bytes and come directly after the tags. We can see that the first data offset is 0x8 and the next one is 0xF68, thus our offset into the data block of 0xA0 means we are looking at the instance which starts at 0x8. It's the very first instance listed at the start of the instance descriptor array:

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | tag | | 53 47 4E 4F | 'ONGS' | template tag }}
{{OBDtr| 0x04 | int32 | | 08 00 00 00 | 0x08 | data offset (relative to data block) }}
{{OBDtr| 0x08 | int32 | | 00 00 00 00 | 0x00 | name offset (relative to name block) }}
{{OBDtr| 0x0C | int32 | | 60 0F 00 00 | 3936 | data size }}
{{OBDtr| 0x10 | int32 | | 00 00 00 00 | 0 | flags }}
|}

So this tells us that the first data in the data block belongs to the solitary [[ONGS]] resource, and that it extends for 3,936 bytes. Since its name offset is 0x0, it's the first string in the name block, which we can see below is SUBTsubtitles.

==Name block==
This final segment of the file (third-to-last in a .oni, followed by the data and raw/sep blocks) stores all the instance names as C-style ASCII strings (terminated by a zero byte). We peeked at this before when we looked at the instance descriptor for SUBTsubtitles. The start of this block is 32-byte aligned but after that the strings are simply packed end to end, separated only by their null terminator. As with the data block, the name block's starting point is given in the header, in this case 0x28F240.

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | string | | 53 55 ... 00 | "SUBTsubtitles" | name string (zero-terminated) }}
|}

These names can be up to 63 characters long, counting the tag. The instance file concludes with the end of the name block, or the raw/sep block in a .oni file.

{{OBD}}

Oni (disambiguation)

2026-04-16T20:32:12Z

Iritscen: added several more Oni things, because why not?

'''[[Oni]]''' is an action video game developed by Bungie West and released in 2001.

Our wiki also has the following additional '''Oni''' articles:
* [[Oni (myth)]], an examination of the Japanese mythical oni
* [[Oni (folder)]], information on the game's installation directory
* [[Oni (PlayStation 2)]], cataloging the differences from the PC version of the game
* [[Oni (no relation)]], a list of unrelated works named Oni

Also see these things which aren't quite called '''Oni''' but are still pretty interesting:
* [[Category:Dark Horse comics|Oni comic]]
* [[OniX]]
* [[Oni-likes and engine ports]]
* [[Oni2|Oni 2 (fan fiction)]]
* [[Oni 2 (Angel Studios)]]

[[Category:Wiki Support]]

OniGalore:Current events

2026-04-16T20:20:22Z

Iritscen: wording around PS2 port work; removed redlink for a page that we don't need to create

{|style="float:right"
!WIKI WORK IS FUN!
|-
|[[Image:Penny_Arcade_-_EvilCorp_Too.png|250px]]
|-
!ENOUGH FOR A JOKE OR TWO THEN IT GETS BORING
|}
{{Hatnote|If you're not familiar with wikis, see [[OniGalore:About]]. If you're not confident about editing a wiki, see [[Help:Editing]].}}
Here are some ongoing projects, and ideas for projects, on the wiki. Whatever in this list looks interesting to you, feel free to tackle it, even if you only have a little time here and there. However, if you are leaving a project half-done until you can resume it, please note this under the item in the list. Thanks for whatever you can do to contribute.

{{TOClimit}}

==General wiki work==
* Look at [[:Category:Flagged articles]] and see if there's anything you can help out with. There are a number of articles which need to be updated or finished, including ones about characters and settings in Oni.
* Just browse [[Special:Wantedpages]] and pick an interesting topic to write about! There are many interesting parts of Oni's world which do not have a dedicated article yet.

==PlayStation 2 port==
Let's expand on the documentation of the PS2 version in the [[Oni (PlayStation 2)]] article, including how it differs from PC Oni in terms of gameplay, content and binary data (the latter should be covered on the [[OBD]] page devoted to each template). We should also check the game data for unexpected resources.

==Angel Studios sequel==
If you have some hacking skills, please look at [[Talk:Oni 2 (Angel Studios)]] and [[OBD:Oni2AS]] to see if you can answer any outstanding questions or contribute new information.

==BSL documentation==
The goal is to replace the [[BSL:Functions]] and [[BSL:Variables]] pages with a more organized, sortable and readable system:
# A single, master list of all functions and variables at [[BSL:List of built-in commands]] ("BSL:List" is a shortcut that redirects there). No longer will we have to browse two pages at once when we're trying to find a command but don't remember if it's a variable or function. The list is sortable by name, group, kind (function or variable), and platform availability, but does not contain any other info on the commands. It's just intended as a quick reference. You can click the group name for any command to go to the grouped page that discusses it in the context of related commands.
# Grouped pages which discuss all the functions/variables related to a certain task. This is where the detailed coverage of commands will be found. See [[BSL:AI activity]] for an example.
# Each command will also have its own page, so typing in the name of that command, e.g. "ai2_active", in the Go/Search box will take you to a page that allows you to either edit the basic information about that command or to visit its group's page.

This revamp of the BSL docs was starting to be built on a system that I (Iritscen) hacked into the wiki, but it's too rickety and clumsy. The proper approach to interlinked documentation that reads from the same central pool of data would be the [[mw:Extension:Cargo|Cargo]] extension, if we can get it installed here.

==Oni 2 and beyond...==
Some fans use the wiki to write sequels, prequels, interquels (what may have happened to Konoko in the time gaps between the original chapters, e.g., between Chapter 12 and Chapter 13) or even paraquels (e.g., what was happening on the Syndicate side during Oni?). You can then list your work [[Oni2|HERE]]. Just be aware of the [[OniGalore:Copyrights|rights issues]] surrounding fan fiction posted on the Internet. Also, plagiarism is not nice, but "Oni 2" can still be influenced by anime/cyberpunk/other references. See [[:Category:Oni 2 influences|HERE]] to review the influences so far, elaborate on them some more, or point out new ones.

[[Category:Policies and documentation]]

Engine terminology

2026-04-16T20:16:33Z

Iritscen: linked to Mac/Win and PS2/PC comparison articles; wikilinked all the differing types on PS2

{{UpdatedForOniX|1.0.0}}
Here is a high-level view of the different versions of the Oni engine and a brief introduction to some of the subsystems in the engine. It's meant to be read in tandem with [[Game data terminology]]. For a list of general differences between the Windows, Mac and PS2 versions of Oni, see [[PS2 vs PC]] and [[Mac vs PC]].

==Engine versions==
There are three versions of Oni's engine found in released versions of the game. They are referred to interchangeably by various names.
;Windows retail, Windows, PC, v1.0
This version of the engine can be identified as '''v1.0''' from [[Oni (folder)/readme.txt|its read-me]] but is often referred to as the "Windows" or "PC" engine. This version of the engine was used for all localized Windows releases translated into non-English languages as well.

;Mac, Windows demo, v1.1
This version was used for Mac retail and demo releases and can be identified as '''v1.1''' from [[Oni (folder)/Oni ReadMe|the Mac read-me]], and underwent another month of development after v1.0. It was also used for the Windows demo, but is sometimes referred to as the "Mac" engine for simplicity.  Its most obvious difference is the addition of .sep files to the GameDataFolder which now contain some of the data formerly stored in .raw files. The format of the individual templates is generally unchanged (with minor differences in [[SNDD]] and [[TRAM]]).

;PS2
This version was created by Rockstar North for the PlayStation 2 port. It also uses .sep files but makes additional changes to templates ([[AGQG]], [[IGSt]], [[M3GM]], [[SNDD]], [[TRAM|TRAM/TREX]], [[TSFT]], [[TSGA]] and [[TXMP]]). It went through another 3 weeks to a month of development after the Mac version was completed and could possibly be thought of as a v1.2 engine, but is probably best understood as a fork of the v1.1 engine made for PS2 compatibility.

==Subsystems==
The engine consists of various subsystems, some of which have colorful animé-related names and some of which have boring descriptive names. If an article is devoted to documenting more of that subsystem, it will be linked.

;AI2
The second iteration of the code for driving the [[AI|AIs]] (NPCs).

;Akira
The [[Graphics|environment]] code, responsible for holding the game world in memory. Named for the 1988 film [[wp:Akira (1988 film)|Akira]].

;BFW
A layer rather than a subsystem: stands for "BungieFrameWork". This is the lower layer of the game engine, consisting of generalized cross-platform engine code. The upper layer is simply called "Oni" and contains specializations needed to implement Oni's gameplay logic.

;BSL
Standing for "BFW Scripting Language", this is the subsystem responsible for running Oni's [[BSL|scripting language]].

;Motoko
The renderer code, responsible for drawing Oni's [[graphics]]. Named for the main character of the 1995 film [[Ghost in the Shell]].

;Totoro
The code for Oni's 3D [[Animation|animation system]]. Named for the 1988 film [[wp:My Neighbor Totoro|My Neighbor Totoro]].

;''Et cetera''
There are various other subsystems that we essentially never talk about, such as LocalInput, WindowManager, SoundSystem2 and TemplateManager.

[[Category:Engine docs]]

Oni (PlayStation 2)

2026-04-16T20:15:09Z

Iritscen: /* Binary data format */ +wikilink

Midway through Oni's development, in 1999, Take-Two Interactive purchased a stake in Bungie and became the publisher for the upcoming game. In addition to their investment, T2 stipulated that a PlayStation 2 port would be released alongside Oni for Windows and Macintosh. That port was created by Rockstar Toronto (known at the time as Rockstar Canada), and because the game had originally been intended for a PC with a hard drive, changes had to be made in order to load the game more quickly from CD-ROM. Even after this work, the PS2 version has been noted for its long load times.

Today, Oni runs well in the emulator [https://pcsx2.net/ PCSX2]. When using this emulator, load times are reduced by placing an ISO of the game disc on your hard drive. You can also easily apply patches from within PCSX2 instead of having to buy a cheat device for your PS2, so this is the best way to run the game.

==Gameplay differences==
* Cheats are entered differently; see {{SectionLink|Cheats|PlayStation 2}}. Also, they do not require the game to be beaten first, which is extremely helpful since the console controls make this version harder.
* The cooldown exploit has been fixed.
* The AI for the androids in Training is glitchy or overly aggressive. They might try to attack you after beating Karen, and the training bots sometimes forget the defense/offense program they're supposed to be following and wantonly attack you. It remains to be seen if this is an overall glitch with AI in the PS2 version.
* In the opening cutscene for Chapter 13, Konoko fires two or three times at the glass in the ceiling instead of once. (This probably means you have fewer bullets in your clip when the level starts, can someone confirm?)

==Visual differences==
[[Image:Konoko from T2 PS2 intro.png|250px|thumb|right|The PS2-only movie where Konoko hits you in the face repeatedly, ending with a kick where her shoe plants the Rockstar logo on the screen (see her foot in [[:Image:Konoko Jump Kick.jpg|this art]]).]]
[more pictures coming later]
* The intro and outro movies are 30 fps (NTSC) or 25 fps (PAL) instead of 15 fps, and intro in particular looks better on PS2. (These movies were turned into mod packages for PC Oni called "HQ Movies (Mac)" and "HQ Intro Movie (Windows)".)
* The intro on PC starts with the Bungie logo sequence and then plays the anime intro as part of one movie, but on PS2 there are two intro movies: the first contains a ten-second [https://www.youtube.com/watch?v=itX1fGbkpbo Konoko-based presentation of the Rockstar logo] and the original PC Bungie logo sequence; this movie is unskippable. The second movie contains the original anime intro and is skippable with a button press. See {{SectionLink||Patches}} for a PCSX2 patch which disables movie playback.
* Different Main Menu.
* When loading a level, instead of a progress bar against a black background, PS2 Oni has a proper loading screen – the game cycles through three different backgrounds for these.
* The splashscreens for each level use the same images as on PC, but the title overlay has a different style.
* The text used for subtitles is larger. Character names in the fly-in portraits are also redone to be much larger.
* There is less texture variety due to limited memory. Various environmental objects, such as the crates at the very start of Chapter 1, are uniform instead of having differently colored variants. Textures are also reduced to indexed color (they use custom 256-color palettes of 32-bit colors) which does not seem to make a big difference since players have never noted a loss of texture quality.
* Apparently there is less variety in enemies as well, but this is yet to be documented in detail. See [https://www.reddit.com/r/oni/comments/lpgrx3/i_was_the_art_director_for_ps2_port/ this Reddit thread] for a firsthand account of the nature of these cuts.
* Lighting is handled differently; there seems to be a higher gamma to the graphical output.
* Karen in Training is using the dark-haired female cop model.
* Some of Shinatama's un-subtitled instructions in the PC version of Training are subtitled on PS2, but not all. Some of these PS2-only subtitles are abbreviated transcriptions, as seen when we compare SNDD and SUBT:
:: Staggering moves (00_01_76):
:* SNDD: "Be careful, Konoko! Some attacks are so powerful that they can stagger you even if you block them. Some super moves are so strong they can't be blocked at all!"
:* SUBT: "Some powerful attacks can stagger you. Supermoves cannot be blocked."
:: Training drone (00_01_89):
:* SNDD: "I'll activate a training drone to walk up and down the firing range. Fire at it to disable it."
:* SUBT: "Fire at the moving training drone to disable it."
:: Completion (00_01_82):
:* SNDD: "Your comlink stores lots of information about weapons, items, and mission objectives. It also has a help feature, and even a diary built right in."
:* SUBT: "Your comlink stores information about weapons, items and mission objectives. It also has a help feature and a diary."
*...and some wording has been re-distributed between SUBTs, presumably to even out the number of words appearing onscreen.
** SNDDs 00_01_86 and 00_01_88:
::: "Perfect!"
::: "Let's try firing at some moving targets. Walk over to the table on the right. See the weapon lying there? That's a plasma rifle. Pick it up."
:* SUBTs 00_01_86 and 00_01_88:
::: "Perfect! Let's try firing on some moving targets."
::: "Walk over to the table on the right. See the weapon lying there? That's a plasma rifle. Pick it up."
* In Chapter 1, the "-OMM- TTC 1.1" crate with the <code>thedayismine</code> code has had its message covered over with a metal plate, presumably a tongue-in-cheek way of saying that Dev Mode will not be available to the player.

==Credits differences==
* Instead of using "Trailer" and "Farewell" for the credits, the PS2 credits have completely different music. This is probably because [https://www.youtube.com/watch?v=Od1ReWIxduo the PC credits sequence] is 171 seconds long (that is, the textual credits, not counting the animated outro), but [https://www.youtube.com/watch?v=Yhqg_MF6dM8 the NTSC version] of the PS2 credits is 156 seconds and [https://www.youtube.com/watch?v=YX0OGl2-WLA the PAL version] is 204 seconds. (The differing frame rate of PAL's 25 fps vs. NTSC's 30 fps cannot account for this 48-second time difference, and the credits themselves are identical; the PAL version simply scrolls the credits 30% slower for some reason.) To cover these credit sequences of differing length, a new backing track with a house beat was composed by Rockstar Canada staff. The NTSC version's music fades out arbitrarily as the credits end, whereas the track behind the longer PAL version continues on an extended (and eyebrow-raising) riff on female pain sounds from the game and ends with an actual coda.
* The text of the PS2 credits is somewhat different; see {{SectionLink|Quotes/Credits|PS2 outro differences}} for details.

==Directories==
The root directory of the PS2 CD-ROM is roughly equivalent to [[Oni (folder)|the Oni folder]] of a Windows or Mac installation (see subsections below for exceptions). This similarity isn't clear at first, as the names of the files and folders are represented by numbers. Most of Oni's original file and folder names would be too long for a PS2 disc's ISO 9660 Level 1 file system, which employs [[wp:8.3 filename|8+3 naming]]. Thus, the actual names for these files are given in plain-text directory listings named INDEX.DIR alongside the renamed files. The game executable reads these .DIR files at runtime to find the desired file/folder by name. Here is the directory tree with de-indexed names:

{|border=1 cellspacing=0 style="font-size:75%"
|-
!Name on disk
!De-indexed name
!Notes
|-valign=top
|
*1/
**1/
***...
**19/
***<nowiki>#</nowiki> (#=1-15)
**20/
***<nowiki>#</nowiki> (#=1-15)
**21/
***<nowiki>#</nowiki> (#=1-15)
**2,18
**<nowiki>#</nowiki> (#=3-17)
|
*GameDataFolder/
**IGMD/
***...
**pal/
***level#_palette.pal (#=0-4,6,8-14,18-19)
**raw/
***level#_Final.raw (#=0-4,6,8-14,18-19)
**sep/
***level#_Final.sep (#=0-4,6,8-14,18-19)
**intro.bik, outro.bik
**level#_Final.dat (#=0-4,6,8-14,18-19)
|
*Main game data container (c.f. [[GameDataFolder]])
**Level logic scripts written in [[BSL]]
***(see [[IGMD]] for an expanded list)
*Palette folder
**Palette files referenced by a level's [[TXMP]]
*Raw data folder
**.raw files referenced from the respective .dat
*Separate data folder
**.sep files referenced from the respective .dat
*[[Intro]] and [[outro]] sequences in Bink video format (unused)
*[[OBD:Instance file format|Instance files]] (game data files)
|-valign=top
|colspan=2|
*ICONS/
**ONI1.ICO
*MODULES/
**IOPRP16.IMG
**LIBSD.IRX, MCMAN.IRX, MCSERV.IRX, PADMAN.IRX, SDRDRV.IRX, SIO2MAN.IRX
**ONISS2.IRX
*SOUNDS/
**LEVEL#/ (#=0-4,6,8-14,18,19)
***SOUND.DAT, SOUND.RAW, SOUND.SEP
**BINK#.VAG (#=0,1,2)
*INTRO1.PSS, INTRO2.PSS, OUTRO.PSS
*LOADING.RAW
*PERSIST.DAT
|
*Icons folder (the 18.12.2000 dev build also has an empty "icons" folder)
**Oni icon (the 18.12.2000 dev build instead has SLIME[1-3].ICO)
*Standard folder for application modules (hardware drivers, etc.)
**An "image" module (the 18.12.2000 dev build also has IOPRP165.IMG)
**Six standard modules typical of PS2 games (the 18.12.2000 dev build has ten more modules, plus one in an OLD folder)
**A custom module specific to the game (Oni's "SoundSystem2")
*A separate folder containing the sound data
**Per-level folders
***SOUND.DAT referenced from level#_Final.dat, .SEP and .RAW looked up from .DAT
**Three short beeps stored separately (used as menu sounds)
*Intro and outro video sequences (18.12.2000 dev build has INTRO.PSS and OUTRO.PSS)
*Game data for the loading screen interface (absent for the 18.12.2000 dev build)
*A savegame/preference file (unused; see {{SectionLink||Relic files}})
|-valign=top
|
*2
*3
|
*persist.dat
*Preferences.txt
|
*A duplicate of PERSIST.DAT (also unused, see {{SectionLink||Relic files}})
*A vestigial file listing locations for the game data (absent in 18.12.2000 dev build)
|-
|colspan=2|
*SLUS_200.64
*SYSTEM.CNF
|
*The game binary (a.k.a. executable)
*Standard boot information for a PS2 game
|}

===Raw and separate files===
Although the GameDataFolder generally matches the PC version, one notable exception is that raw and separate files are tucked away into '''raw''' and '''sep''' directories.

===Palette files===
There is also a '''pal''' directory holding a set of '''level#_palette.pal''' files (one per level); in PS2 Oni, all the textures (TXMP files) use compact 8-bit storage (i.e., each pixel is an index into a palette of 256 colors), as opposed to Windows and Mac TXMPs which typically use 16- or 24-bit color.

===Relic files===
*'''intro.bik''' and '''outro.bik''' are not used by the engine (they're superseded by '''INTRO2.PSS''' and '''OUTRO.PSS'''); they're just taking up 56 MB of storage space for nothing (the .PSS versions take up another 188 MB).
*The [[persist.dat|save-game]] files '''persist.dat''' and '''PERSIST.DAT''' are little-endian (i.e., created in Windows or on a PS2 dev unit) and are byte-identical to each other. Actual save data is stored in a standard PS2 format on the memory card (obviously the game cannot write to files on disc). They might be a development relic of the PS2 port since they are much smaller than a PC persist.dat (also, one is named in all-caps like the other files Rockstar added to the game directory).

==Binary data format==
The internal structure of '''level#_Final.dat''' and the corresponding '''.raw''' and '''.sep''' is compliant with the "VR31" iteration of [[instance file]]s, although many resources were optimized for minimal storage space (textures use indexed colors, character animations has been split into a trimmed-down TRAM and an "extra" type, [[TREX]], that only exists for combat moves and such, etc.). A list of changed resource types is on [[Engine terminology]].

Sounds are encoded using Sony's VAG format/codec, and (unlike for other Oni versions) their waveform data isn't stored in '''level#_Final.raw''' (see {{SectionLink|OBD:SNDD|PS2 implementation}}). Instead the SNDD instances in '''level#_Final.dat''' contain links to '''SOUNDS/LEVEL#/SOUND.DAT''', which in turn references waveform data stored either in '''SOUNDS/LEVEL#/SOUND.SEP''' (raw VAG data without any headers) or '''SOUNDS/LEVEL#/SOUND.RAW''' (raw VAG data with minimal headers to allow the lookup of each sound). The three '''BINK#.VAG''' files are beep-like sounds picked from Oni's game data (SNDDbeep43, SNDDbeep24 and SNDDbeep23, respectively); they have a VAG header and are valid sounds for VAG-capable apps.

==Level scripts==
The PS2 IGMD includes the same pre-beta folders as the [[European Mac releases]]: scripting logic intended for now-missing chapters and test levels. Some "test" subfolders are present for '''EnvWarehouse''' and '''manplant''', with backups of the scripts for levels 1 and 2. When it comes to the Windows/Mac differences in the [[Oni (folder)/GameDataFolder/IGMD/tctf_ii|tctf_ii]] folder, the scripts match the Windows versions (although the folder is named "tctf_II" with capital 'i's in the INDEX.DIR). However, the PS2 scripts have differences of their own:
*Many "sleep" commands have been added or removed to adjust cutscene timing.
*Two dialogue lines in compound.bsl have been renamed, and in a number of places where dialogue is played, a short sleep command and a new dialogue line appear to be added afterward (see compound.bsl, lab_cutscene.bsl and warehouse_train2.bsl); could these be original lines split into two pieces?
*A BSL function called gs_nearclipplane_set was added so that it could be called from warehouse_cutscene.bsl.
*"input 1" isn't called at the beginning of Chapter 1 until after Shinatama introduces the HUD at the end of the intro, rather than before.
*A possible fix in manplant_level_logic.bsl that disables the trigger volume for SP2 when SP3 is loaded (can it be reached by backtracking?).
*A possible fix in roof.bsl that sets an objective when SP4 is loaded.
*The PS2 version of BSL implements at least two new script variables, '''psx2_ambient2''' and '''psx2_directional2''' (both of them floats). They appear to be white light intensities (i.e., shades of gray) used for the Gouraud shading of characters and other M3GM (powerups, weapons, furniture, animated objects). In Windows/Mac Oni there is no possibility to adjust ambient or directional light intensities through scripts: the main directional light has intensity 0.7, the auxiliary directional light (turned on at higher quality settings) has intensity 0.3, and the ambient intensity is either 0.65 or 0.55 (larger if one directional light, smaller if two directional lights).

==Patches==
Punk7890 of TCRF (The Cutting Room Floor) found that a number of Dev Mode features were still present in the PS2 port. Some need hex-patching in order to activate them, and some can be toggled using the controller once activated, showing that Rockstar found these features useful during their port work. The patches (for the U.S. release of the game) are found [https://tcrf.net/Oni_(PlayStation_2) HERE].

In order to apply the patches on a PS2, you would use a cheat device like GameShark, which few people have. If you're running Oni in PCSX2, you'll have an easy time adapting these patches. Create a plain-text file called FD9CD8FC.pnach (that's the CRC of the U.S. release of the game), and make sure there's no ".txt" at the end of the name. Place it in the "cheats" directory for PCSX2, and inside the file, create a line of text for each patch you want to use, using the following guide to convert the patch on the TCRF wiki:

{|class="wikitable" style="margin-left:auto; margin-right:auto;"
!TCRF wiki
!
!.pnach file
|-
|0033A904 00000001
|becomes
|<tt>patch=1,EE,0033A904,word,00000001 # FPS counter</tt>
|}

The comment at the end of the .pnach file's line is optional, but you will definitely want to label your patches.

An additional patch for skipping the intro movies is below, courtesy of [[User:Iritscen|Iritscen]]. Place this patch in a .pnach file to disable the movie-playing function so that the game skips right to the loading screen for the Main Menu. Make sure not to have this active when finishing the game or you won't see the outro movie and credits.

patch=1,EE,001C726C,word,00000000 # no movies

[[Category:Oni history]]

Oni (PlayStation 2)

2026-04-16T20:12:52Z

Iritscen: this page doesn't exist, and the deviations are covered on each template's OBD page, so let's link to the list of changed templates instead

Midway through Oni's development, in 1999, Take-Two Interactive purchased a stake in Bungie and became the publisher for the upcoming game. In addition to their investment, T2 stipulated that a PlayStation 2 port would be released alongside Oni for Windows and Macintosh. That port was created by Rockstar Toronto (known at the time as Rockstar Canada), and because the game had originally been intended for a PC with a hard drive, changes had to be made in order to load the game more quickly from CD-ROM. Even after this work, the PS2 version has been noted for its long load times.

Today, Oni runs well in the emulator [https://pcsx2.net/ PCSX2]. When using this emulator, load times are reduced by placing an ISO of the game disc on your hard drive. You can also easily apply patches from within PCSX2 instead of having to buy a cheat device for your PS2, so this is the best way to run the game.

==Gameplay differences==
* Cheats are entered differently; see {{SectionLink|Cheats|PlayStation 2}}. Also, they do not require the game to be beaten first, which is extremely helpful since the console controls make this version harder.
* The cooldown exploit has been fixed.
* The AI for the androids in Training is glitchy or overly aggressive. They might try to attack you after beating Karen, and the training bots sometimes forget the defense/offense program they're supposed to be following and wantonly attack you. It remains to be seen if this is an overall glitch with AI in the PS2 version.
* In the opening cutscene for Chapter 13, Konoko fires two or three times at the glass in the ceiling instead of once. (This probably means you have fewer bullets in your clip when the level starts, can someone confirm?)

==Visual differences==
[[Image:Konoko from T2 PS2 intro.png|250px|thumb|right|The PS2-only movie where Konoko hits you in the face repeatedly, ending with a kick where her shoe plants the Rockstar logo on the screen (see her foot in [[:Image:Konoko Jump Kick.jpg|this art]]).]]
[more pictures coming later]
* The intro and outro movies are 30 fps (NTSC) or 25 fps (PAL) instead of 15 fps, and intro in particular looks better on PS2. (These movies were turned into mod packages for PC Oni called "HQ Movies (Mac)" and "HQ Intro Movie (Windows)".)
* The intro on PC starts with the Bungie logo sequence and then plays the anime intro as part of one movie, but on PS2 there are two intro movies: the first contains a ten-second [https://www.youtube.com/watch?v=itX1fGbkpbo Konoko-based presentation of the Rockstar logo] and the original PC Bungie logo sequence; this movie is unskippable. The second movie contains the original anime intro and is skippable with a button press. See {{SectionLink||Patches}} for a PCSX2 patch which disables movie playback.
* Different Main Menu.
* When loading a level, instead of a progress bar against a black background, PS2 Oni has a proper loading screen – the game cycles through three different backgrounds for these.
* The splashscreens for each level use the same images as on PC, but the title overlay has a different style.
* The text used for subtitles is larger. Character names in the fly-in portraits are also redone to be much larger.
* There is less texture variety due to limited memory. Various environmental objects, such as the crates at the very start of Chapter 1, are uniform instead of having differently colored variants. Textures are also reduced to indexed color (they use custom 256-color palettes of 32-bit colors) which does not seem to make a big difference since players have never noted a loss of texture quality.
* Apparently there is less variety in enemies as well, but this is yet to be documented in detail. See [https://www.reddit.com/r/oni/comments/lpgrx3/i_was_the_art_director_for_ps2_port/ this Reddit thread] for a firsthand account of the nature of these cuts.
* Lighting is handled differently; there seems to be a higher gamma to the graphical output.
* Karen in Training is using the dark-haired female cop model.
* Some of Shinatama's un-subtitled instructions in the PC version of Training are subtitled on PS2, but not all. Some of these PS2-only subtitles are abbreviated transcriptions, as seen when we compare SNDD and SUBT:
:: Staggering moves (00_01_76):
:* SNDD: "Be careful, Konoko! Some attacks are so powerful that they can stagger you even if you block them. Some super moves are so strong they can't be blocked at all!"
:* SUBT: "Some powerful attacks can stagger you. Supermoves cannot be blocked."
:: Training drone (00_01_89):
:* SNDD: "I'll activate a training drone to walk up and down the firing range. Fire at it to disable it."
:* SUBT: "Fire at the moving training drone to disable it."
:: Completion (00_01_82):
:* SNDD: "Your comlink stores lots of information about weapons, items, and mission objectives. It also has a help feature, and even a diary built right in."
:* SUBT: "Your comlink stores information about weapons, items and mission objectives. It also has a help feature and a diary."
*...and some wording has been re-distributed between SUBTs, presumably to even out the number of words appearing onscreen.
** SNDDs 00_01_86 and 00_01_88:
::: "Perfect!"
::: "Let's try firing at some moving targets. Walk over to the table on the right. See the weapon lying there? That's a plasma rifle. Pick it up."
:* SUBTs 00_01_86 and 00_01_88:
::: "Perfect! Let's try firing on some moving targets."
::: "Walk over to the table on the right. See the weapon lying there? That's a plasma rifle. Pick it up."
* In Chapter 1, the "-OMM- TTC 1.1" crate with the <code>thedayismine</code> code has had its message covered over with a metal plate, presumably a tongue-in-cheek way of saying that Dev Mode will not be available to the player.

==Credits differences==
* Instead of using "Trailer" and "Farewell" for the credits, the PS2 credits have completely different music. This is probably because [https://www.youtube.com/watch?v=Od1ReWIxduo the PC credits sequence] is 171 seconds long (that is, the textual credits, not counting the animated outro), but [https://www.youtube.com/watch?v=Yhqg_MF6dM8 the NTSC version] of the PS2 credits is 156 seconds and [https://www.youtube.com/watch?v=YX0OGl2-WLA the PAL version] is 204 seconds. (The differing frame rate of PAL's 25 fps vs. NTSC's 30 fps cannot account for this 48-second time difference, and the credits themselves are identical; the PAL version simply scrolls the credits 30% slower for some reason.) To cover these credit sequences of differing length, a new backing track with a house beat was composed by Rockstar Canada staff. The NTSC version's music fades out arbitrarily as the credits end, whereas the track behind the longer PAL version continues on an extended (and eyebrow-raising) riff on female pain sounds from the game and ends with an actual coda.
* The text of the PS2 credits is somewhat different; see {{SectionLink|Quotes/Credits|PS2 outro differences}} for details.

==Directories==
The root directory of the PS2 CD-ROM is roughly equivalent to [[Oni (folder)|the Oni folder]] of a Windows or Mac installation (see subsections below for exceptions). This similarity isn't clear at first, as the names of the files and folders are represented by numbers. Most of Oni's original file and folder names would be too long for a PS2 disc's ISO 9660 Level 1 file system, which employs [[wp:8.3 filename|8+3 naming]]. Thus, the actual names for these files are given in plain-text directory listings named INDEX.DIR alongside the renamed files. The game executable reads these .DIR files at runtime to find the desired file/folder by name. Here is the directory tree with de-indexed names:

{|border=1 cellspacing=0 style="font-size:75%"
|-
!Name on disk
!De-indexed name
!Notes
|-valign=top
|
*1/
**1/
***...
**19/
***<nowiki>#</nowiki> (#=1-15)
**20/
***<nowiki>#</nowiki> (#=1-15)
**21/
***<nowiki>#</nowiki> (#=1-15)
**2,18
**<nowiki>#</nowiki> (#=3-17)
|
*GameDataFolder/
**IGMD/
***...
**pal/
***level#_palette.pal (#=0-4,6,8-14,18-19)
**raw/
***level#_Final.raw (#=0-4,6,8-14,18-19)
**sep/
***level#_Final.sep (#=0-4,6,8-14,18-19)
**intro.bik, outro.bik
**level#_Final.dat (#=0-4,6,8-14,18-19)
|
*Main game data container (c.f. [[GameDataFolder]])
**Level logic scripts written in [[BSL]]
***(see [[IGMD]] for an expanded list)
*Palette folder
**Palette files referenced by a level's [[TXMP]]
*Raw data folder
**.raw files referenced from the respective .dat
*Separate data folder
**.sep files referenced from the respective .dat
*[[Intro]] and [[outro]] sequences in Bink video format (unused)
*[[OBD:Instance file format|Instance files]] (game data files)
|-valign=top
|colspan=2|
*ICONS/
**ONI1.ICO
*MODULES/
**IOPRP16.IMG
**LIBSD.IRX, MCMAN.IRX, MCSERV.IRX, PADMAN.IRX, SDRDRV.IRX, SIO2MAN.IRX
**ONISS2.IRX
*SOUNDS/
**LEVEL#/ (#=0-4,6,8-14,18,19)
***SOUND.DAT, SOUND.RAW, SOUND.SEP
**BINK#.VAG (#=0,1,2)
*INTRO1.PSS, INTRO2.PSS, OUTRO.PSS
*LOADING.RAW
*PERSIST.DAT
|
*Icons folder (the 18.12.2000 dev build also has an empty "icons" folder)
**Oni icon (the 18.12.2000 dev build instead has SLIME[1-3].ICO)
*Standard folder for application modules (hardware drivers, etc.)
**An "image" module (the 18.12.2000 dev build also has IOPRP165.IMG)
**Six standard modules typical of PS2 games (the 18.12.2000 dev build has ten more modules, plus one in an OLD folder)
**A custom module specific to the game (Oni's "SoundSystem2")
*A separate folder containing the sound data
**Per-level folders
***SOUND.DAT referenced from level#_Final.dat, .SEP and .RAW looked up from .DAT
**Three short beeps stored separately (used as menu sounds)
*Intro and outro video sequences (18.12.2000 dev build has INTRO.PSS and OUTRO.PSS)
*Game data for the loading screen interface (absent for the 18.12.2000 dev build)
*A savegame/preference file (unused; see {{SectionLink||Relic files}})
|-valign=top
|
*2
*3
|
*persist.dat
*Preferences.txt
|
*A duplicate of PERSIST.DAT (also unused, see {{SectionLink||Relic files}})
*A vestigial file listing locations for the game data (absent in 18.12.2000 dev build)
|-
|colspan=2|
*SLUS_200.64
*SYSTEM.CNF
|
*The game binary (a.k.a. executable)
*Standard boot information for a PS2 game
|}

===Raw and separate files===
Although the GameDataFolder generally matches the PC version, one notable exception is that raw and separate files are tucked away into '''raw''' and '''sep''' directories.

===Palette files===
There is also a '''pal''' directory holding a set of '''level#_palette.pal''' files (one per level); in PS2 Oni, all the textures (TXMP files) use compact 8-bit storage (i.e., each pixel is an index into a palette of 256 colors), as opposed to Windows and Mac TXMPs which typically use 16- or 24-bit color.

===Relic files===
*'''intro.bik''' and '''outro.bik''' are not used by the engine (they're superseded by '''INTRO2.PSS''' and '''OUTRO.PSS'''); they're just taking up 56 MB of storage space for nothing (the .PSS versions take up another 188 MB).
*The [[persist.dat|save-game]] files '''persist.dat''' and '''PERSIST.DAT''' are little-endian (i.e., created in Windows or on a PS2 dev unit) and are byte-identical to each other. Actual save data is stored in a standard PS2 format on the memory card (obviously the game cannot write to files on disc). They might be a development relic of the PS2 port since they are much smaller than a PC persist.dat (also, one is named in all-caps like the other files Rockstar added to the game directory).

==Binary data format==
The internal structure of '''level#_Final.dat''' and the corresponding '''.raw''' and '''.sep''' is compliant with the "VR31" iteration of instance files, although many resources were optimized for minimal storage space (textures use indexed colors, character animations has been split into a trimmed-down TRAM and an "extra" type, [[TREX]], that only exists for combat moves and such, etc.). A list of changed resource types is on [[Engine terminology]].

Sounds are encoded using Sony's VAG format/codec, and (unlike for other Oni versions) their waveform data isn't stored in '''level#_Final.raw''' (see {{SectionLink|OBD:SNDD|PS2 implementation}}). Instead the SNDD instances in '''level#_Final.dat''' contain links to '''SOUNDS/LEVEL#/SOUND.DAT''', which in turn references waveform data stored either in '''SOUNDS/LEVEL#/SOUND.SEP''' (raw VAG data without any headers) or '''SOUNDS/LEVEL#/SOUND.RAW''' (raw VAG data with minimal headers to allow the lookup of each sound). The three '''BINK#.VAG''' files are beep-like sounds picked from Oni's game data (SNDDbeep43, SNDDbeep24 and SNDDbeep23, respectively); they have a VAG header and are valid sounds for VAG-capable apps.

==Level scripts==
The PS2 IGMD includes the same pre-beta folders as the [[European Mac releases]]: scripting logic intended for now-missing chapters and test levels. Some "test" subfolders are present for '''EnvWarehouse''' and '''manplant''', with backups of the scripts for levels 1 and 2. When it comes to the Windows/Mac differences in the [[Oni (folder)/GameDataFolder/IGMD/tctf_ii|tctf_ii]] folder, the scripts match the Windows versions (although the folder is named "tctf_II" with capital 'i's in the INDEX.DIR). However, the PS2 scripts have differences of their own:
*Many "sleep" commands have been added or removed to adjust cutscene timing.
*Two dialogue lines in compound.bsl have been renamed, and in a number of places where dialogue is played, a short sleep command and a new dialogue line appear to be added afterward (see compound.bsl, lab_cutscene.bsl and warehouse_train2.bsl); could these be original lines split into two pieces?
*A BSL function called gs_nearclipplane_set was added so that it could be called from warehouse_cutscene.bsl.
*"input 1" isn't called at the beginning of Chapter 1 until after Shinatama introduces the HUD at the end of the intro, rather than before.
*A possible fix in manplant_level_logic.bsl that disables the trigger volume for SP2 when SP3 is loaded (can it be reached by backtracking?).
*A possible fix in roof.bsl that sets an objective when SP4 is loaded.
*The PS2 version of BSL implements at least two new script variables, '''psx2_ambient2''' and '''psx2_directional2''' (both of them floats). They appear to be white light intensities (i.e., shades of gray) used for the Gouraud shading of characters and other M3GM (powerups, weapons, furniture, animated objects). In Windows/Mac Oni there is no possibility to adjust ambient or directional light intensities through scripts: the main directional light has intensity 0.7, the auxiliary directional light (turned on at higher quality settings) has intensity 0.3, and the ambient intensity is either 0.65 or 0.55 (larger if one directional light, smaller if two directional lights).

==Patches==
Punk7890 of TCRF (The Cutting Room Floor) found that a number of Dev Mode features were still present in the PS2 port. Some need hex-patching in order to activate them, and some can be toggled using the controller once activated, showing that Rockstar found these features useful during their port work. The patches (for the U.S. release of the game) are found [https://tcrf.net/Oni_(PlayStation_2) HERE].

In order to apply the patches on a PS2, you would use a cheat device like GameShark, which few people have. If you're running Oni in PCSX2, you'll have an easy time adapting these patches. Create a plain-text file called FD9CD8FC.pnach (that's the CRC of the U.S. release of the game), and make sure there's no ".txt" at the end of the name. Place it in the "cheats" directory for PCSX2, and inside the file, create a line of text for each patch you want to use, using the following guide to convert the patch on the TCRF wiki:

{|class="wikitable" style="margin-left:auto; margin-right:auto;"
!TCRF wiki
!
!.pnach file
|-
|0033A904 00000001
|becomes
|<tt>patch=1,EE,0033A904,word,00000001 # FPS counter</tt>
|}

The comment at the end of the .pnach file's line is optional, but you will definitely want to label your patches.

An additional patch for skipping the intro movies is below, courtesy of [[User:Iritscen|Iritscen]]. Place this patch in a .pnach file to disable the movie-playing function so that the game skips right to the loading screen for the Main Menu. Make sure not to have this active when finishing the game or you won't see the outro movie and credits.

patch=1,EE,001C726C,word,00000000 # no movies

[[Category:Oni history]]

Engine terminology

2026-04-16T20:09:07Z

Iritscen: clarified which templates differ on Mac and PS2 (not guaranteed to be a complete list)

{{UpdatedForOniX|1.0.0}}
Here is a high-level view of the different versions of the Oni engine and a brief introduction to some of the subsystems in the engine. It's meant to be read in tandem with [[Game data terminology]].

==Engine versions==
There are three versions of Oni's engine found in released versions of the game. They are referred to interchangeably by various names.
;Windows retail, Windows, PC, v1.0
This version of the engine can be identified as '''v1.0''' from [[Oni (folder)/readme.txt|its read-me]] but is often referred to as the "Windows" or "PC" engine. This version of the engine was used for all localized Windows releases translated into non-English languages as well.

;Mac, Windows demo, v1.1
This version was used for Mac retail and demo releases and can be identified as '''v1.1''' from [[Oni (folder)/Oni ReadMe|the Mac read-me]], and underwent another month of development after v1.0. It was also used for the Windows demo, but is sometimes referred to as the "Mac" engine for simplicity.  Its most obvious difference is the addition of .sep files to the GameDataFolder which now contain some of the data formerly stored in .raw files. The format of the individual templates is generally unchanged (with minor differences in [[SNDD]] and [[TRAM]]).

;PS2
This version was created by Rockstar North for the PlayStation 2 port. It also uses .sep files but makes additional changes to templates (AGQG, IGSt, M3GM, SNDD, TRAM/TREX, TSFT, TSGA and TXMP). It went through another 3 weeks to a month of development after the Mac version was completed and could possibly be thought of as a v1.2 engine, but is probably best understood as a fork of the v1.1 engine made for PS2 compatibility.

==Subsystems==
The engine consists of various subsystems, some of which have colorful animé-related names and some of which have boring descriptive names. If an article is devoted to documenting more of that subsystem, it will be linked.

;AI2
The second iteration of the code for driving the [[AI|AIs]] (NPCs).

;Akira
The [[Graphics|environment]] code, responsible for holding the game world in memory. Named for the 1988 film [[wp:Akira (1988 film)|Akira]].

;BFW
A layer rather than a subsystem: stands for "BungieFrameWork". This is the lower layer of the game engine, consisting of generalized cross-platform engine code. The upper layer is simply called "Oni" and contains specializations needed to implement Oni's gameplay logic.

;BSL
Standing for "BFW Scripting Language", this is the subsystem responsible for running Oni's [[BSL|scripting language]].

;Motoko
The renderer code, responsible for drawing Oni's [[graphics]]. Named for the main character of the 1995 film [[Ghost in the Shell]].

;Totoro
The code for Oni's 3D [[Animation|animation system]]. Named for the 1988 film [[wp:My Neighbor Totoro|My Neighbor Totoro]].

;''Et cetera''
There are various other subsystems that we essentially never talk about, such as LocalInput, WindowManager, SoundSystem2 and TemplateManager.

[[Category:Engine docs]]

OBD:Instance file format

2026-04-16T20:03:53Z

Iritscen: looking at this checksum statement again, I do think this was written for OniSplit v1.0, but that never left alpha so it's more useful to document v0.99's format

{{UpdatedForOniX|1.0.0}}
{{OBD Home}}
{{Hatnote|".dat" redirects here; for other files ending in ".dat", see [[Oni (folder)]]. 
:You should read [[Engine terminology]] and [[Game data terminology]] before this page. 
:The [[raw|Raw and separate file formats]] page should be read after this one.}}
Files in GameDataFolder/ named "level[0-19]_Final.dat", together with ".raw" and sometimes ".sep" counterparts, contain the game data for Oni. These are called "instance files" internally, but a more common-sense name for them is level data files. The format described below was also used for the tool files which supplied the GUI for the in-game editor, however the retail Oni game application refuses to load tool files; for the story behind the tool files, see [[level0_Tools]].

The level 0 files do not contain resources for a specific level but rather resources (instances) shared across all levels. Level 0 is loaded when the game starts and is never unloaded. All other level files, 1-19, are only loaded when their corresponding level starts and then unloaded when it ends. Oni can only hold two level files in memory concurrently, thus resources have to be duplicated on disk whenever a character class, sound effect, etc. occurs in more than one level. For instance, although there are only 2,380 unique sounds in the game, there are 7,386 sounds stored across all level data files.
{{TOClimit}}
==Blank space and garbage==
The structure of the level data files files reflects the way in which Bungie West chose to store levels in memory. So when we read the data in the files with a hex editor we can see eccentricities such as blank space coming from unused fields and byte-alignment padding, and garbage data such as now-meaningless pointer values and random RAM contents from uninitialized memory. There are also [[OBD:Raw and separate file formats#Gaps|gaps in the .raw/.sep files]], mostly representing orphaned obsolete resources, which add up to about 25 MB for the whole game.

==Backwards tags==
Because the levels were built on Intel-based machines, which use a little-endian architecture, sequences of bytes which represent numbers were written from least-significant to most-significant byte. [[wp:FourCC|FourCCs]] in the data are stored "backwards" (e.g. "13RV" which is meant to be read "VR31") because Bungie defined those four bytes as a 32-bit integer, not a string, causing them to be written to disk in little-endian order.

==File limits==
*Max level number: 127
*Max number of instance files in GameDataFolder: 512 (Windows retail), 16 (Windows demo, Mac)
*Max number of simultaneously loaded instance files: 64
*Max number of instances in a file: 131071
*Max length of an instance file name: 31
*Max length of an instance name: 63 (including the 4 character template tag)

==Header==
Here is a walkthrough of an instance file using the level0_Final.dat in English Windows Oni. Follow along in a hex editor for maximum educational value. Each term will be explained in-depth when we fully consider the related data. First, here is how the file begins:
{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | uint64 | | 1F 27 DC 33 DF BC 03 00 | 0x0003BCDF33DC271F | Total template checksum (main indicator of engine compatibility):
*0x0003BCDF33DC271F - templates compatible with v1.0 engine (Windows retail)
*0x0003BCDF23C13061 - templates compatible with v1.1 engine (Windows demo and Mac)
*0x0003BA70A8DBAE11 - templates compatible with PlayStation 2 engine

OniSplit's .oni files use PC 1.0 checksum by default and 1.1 checksum when storing data that comes from the 1.1 engine and which perceptibly differs in format for that engine (SNDD, but not TXMP) }}
{{OBDtr| 0x08 | uint32 | | 31 33 52 56 | '13RV' | .dat version (meant to be read as "VR31") OniSplit's .oni files use '23RV' ("VR32") instead }}
{{OBDtr| 0x0C | uint16 | | 40 00 | 64 | size of this header }}
{{OBDtr| 0x0E | uint16 | | 14 00 | 20 | size of instance descriptor (32 in Windows alpha 6) }}
{{OBDtr| 0x10 | uint16 | | 10 00 | 16 | size of template descriptor }}
{{OBDtr| 0x12 | uint16 | | 08 00 | 8 | size of name descriptor }}
{{OBDtr| 0x14 | uint32 | | 83 24 00 00 | 9347 | instance descriptor count }}
{{OBDtr| 0x18 | uint32 | | D4 1B 00 00 | 7124 | name descriptor count; 0 for .oni files because there is no name desc. table }}
{{OBDtr| 0x1C | uint32 | | 38 00 00 00 | 56 | template descriptor count; 0 for .oni files because there is no template desc. table }}
{{OBDtr| 0x20 | uint32 | | A0 BC 03 00 | 0x03BCA0 | data block offset }}
{{OBDtr| 0x24 | uint32 | | A0 35 25 00 | 2438560 | data block size }}
{{OBDtr| 0x28 | uint32 | | 40 F2 28 00 | 0x28F240 | name block offset; will be lower than data block offset for .oni files }}
{{OBDtr| 0x2C | uint32 | | 04 4F 02 00 | 151300 | name block size }}
{{OBDtr| 0x30 | uint32 | | 99 CF 40 00 | (garbage) | used by OniSplit for raw/sep block offset }}
{{OBDtr| 0x34 | uint32 | | 90 4F 63 00 | (garbage) | used by OniSplit for raw/sep block size }}
{{OBDtr| 0x38 | uint32 | | F4 55 5F 00 | (garbage) | unused }}
{{OBDtr| 0x3C | uint32 | | 90 4F 63 00 | (garbage) | unused }}
|}

The file's '''total template checksum''' is the sum of all the template checksums (see "Template descriptors" below). Oni looks at this number in order to validate that it can read this version of the game data format. In practical terms, the total checksum value given for Windows above tells us that this level data is in the .dat/.raw file scheme, and the value given for Mac Oni and the Windows demo tells us that the level data uses the .dat/.raw/.sep file scheme.

The '''version''' of the instance file is the format version. Reading it backwards, as discussed under the "Backwards and garbage data" section, we get "VR31" (which probably means "version 3.1" because the engine subsystem that reads template data was in its third iteration when the game shipped). This is the format version of all instance files in all releases of Oni.

The '''descriptor sizes''' are the sizes of the instance, template, and name descriptors which are coming up in this file (see breakdowns in later sections). For instance, each instance descriptor will be 0x14, or 20 bytes, in length.

The '''descriptor counts''' are the sizes of arrays which are coming up in this file: the instance, name and template descriptors. For instance, the size of the instance descriptor array will be 0x2483, or 9,347 items, in length.

Next we are told the addresses and sizes of the '''data and name block''' in the instance file. The name block simply follows the data block, as you'll see if you add the data block offset plus the data block size, so the name block offset is technically redundant. The name block offset plus the name block size equals the total size of the file since it's the last segment of the file. (However in a .oni file, the order of these blocks is reversed.)

After the name block's size comes four "int"s of '''garbage'''; this is padding in order to align the start of the next segment of the file on a 32-byte boundary. The first two 32-bit fields in this space are, however, used in .oni files generated by OniSplit.

That concludes the header of the instance file. Immediately after this header we find the instance descriptors array.

==Instance descriptors==
The instance descriptor array tells Oni where to find the data and the name of every instance (resource) indexed by the .dat file. The descriptors start at 0x40 in the .dat file, but below is a descriptor found at 0x017B50 in the file which makes a better example. In the table below, we use offsets relative to the start of this descriptor. We also show the alternate structure in the Windows alpha 6, the oldest known version of Oni and the only one with an observed difference in the instance descriptor format.

{| class="wikitable"
|- bgcolor="#E9E9E9"
! width=5% | Offset
! width=5% | Type
! width=10% | Raw Hex
! width=10% | Value
! width=35% | Description (retail)
|- align=center
| 0x00
| tag
| 54 42 55 53
| 'SUBT'
|align=left | template tag
|- align=center
| 0x04
| int32
| C8 30 22 00
| 0x2230C8
|align=left | data offset (relative to data block)
|- align=center
| 0x08
| int32
| 01 CB 00 00
| 0xCB01
|align=left | name offset (relative to name block)
|- align=center
| 0x0C
| int32
| C0 09 00 00
| 2496
|align=left | data size
|- align=center
| 0x10
| int32
| 00 00 30 00
| 0x300000
|align=left | flags
|}

{{Divhide|Windows alpha 6}}
{| class="wikitable"
|- bgcolor="#E9E9E9"
! width=5% | Offset
! width=5% | Type
! width=10% | Raw Hex
! width=10% | Value
! width=35% | Description (alpha 6)
|- align=center
| 0x00
| int64
| 68 6C 04 00
| 0x46C68
|align=left | template checksum
|- align=center
| 0x08
| tag
| 54 42 55 53
| 'SUBT'
|align=left | template tag
|- align=center
| 0x0C
| int32
| E8 37 18 00
| 0x1837E8
|align=left | data offset (relative to data block)
|- align=center
| 0x10
| int32
| 4E C5 00 00
| 0xC54E
|align=left | name offset (relative to name block)
|- align=center
| 0x14
| int32
| 20 08 00 00
| 2080
|align=left | data size
|- align=center
| 0x18
| int32
| 00 00 30 00
| 0x300000
|align=left | flags
|- align=center
| 0x1C
| int32
| EA 5F A6 39
| {{LocaleDate|2000|08|25}} 08:00:42 AM
|align=left | creation date (seconds since 1/1/1900)
|}
{{Divhide|end}}
The retail version of this instance descriptor tells us that a resource of '''type''' SUBT (a subtitle file for Oni; there are only two of these, one containing all speech subtitles, and one for help messages) has '''data''' that can be found 0x2230C8 bytes into the data block, which we learned from the file header starts at 0x03BCA0. Its '''name''' can be found 0xCB01 bytes into the name block that starts, according to the file header, at 0x28F240.

The data's '''size''' is given as 0x09C0, or 2,496 bytes, but it's important to clarify that this is the total size of the data counting from the resource header to the next 32-byte boundary after the end of this instance's actual data; in other words it is the true total of the space occupied on disk by this instance. This is interesting because the data offset leads you to the start of the instance-specific data which begins 8 bytes after the resource header, so if you erroneously add the data size to the data offset to find the end of the instance data then you will find yourself 8 bytes into the next instance.

Before we proceed, let's expand upon the '''flags''' field.

;Flags - data usage
:0x'''01''' 00 00 00 - unnamed
:0x'''02''' 00 00 00 - empty
:0x'''04''' 00 00 00 - never used; intended to mark instance as pointing to duplicate data rather than its own data
:0x'''08''' 00 00 00 - instance's data is being used by duplicate instances as a source

;Flags - Tool mode
The first two of the following bits occur throughout the original .dat files. However all of these bits are ignored by the engine when loading data because they only have relevance at runtime when Oni is in Tool mode:
:0x00 00 '''10''' 00 - touched (unsaved data)
:0x00 00 '''20''' 00 - "in batch file"
:0x00 00 '''40''' 00 - delete upon next save


The flags "unnamed" and "empty" require special explanation.

===Unnamed and empty resources===
You'll notice that the level file header lists fewer names (7,124) than instances (9,347). That's because there are 3 types of instance:
*Unnamed and not empty - they are only referenced by other instances in the same file, generally as child data (e.g., 3D geometry elements like ABNA are "contained" by AKEV, a level's environment).
*:In vanilla Oni .dats there are some rare occurrences of unnamed non-empty ''orphan'' instances (e.g., [[OBD:File types/Naming#TRCM|TRCM]]). These are a form of garbage and are discarded by OniSplit when unpacking a level.
*Named and not empty - they can be referenced by other instances in any file and the engine can use their name or template tag to find them.
*Named and empty - "empty" instances are used in level-specific instance files (i.e. not in level0_Final.dat) to associate an instance ID with a name. For every empty resource, there's another one with a matching name in level0_Final.dat that has data in it. The empty resource in the instance file is (usually) looked up by ID, then the engine searches all the loaded files for a non-empty instance with the same name, causing it to find the actual file in the global data in level0_Final.dat.

===Peeking ahead at instance name===
Before we talk about the name block in depth, we can peek ahead at the name of this resource using the offset we've just been given. Let's add the offset 0xCB01 to 0x28F240, the file header's address for the name block. This gives us the address 0x29BD41. There we find the string "SUBTsubtitles".

===Peeking ahead at instance data===
The actual subtitle data should be found by adding the offset 0x2230C8 to 0x03BCA0, the file header's address for the data block, to get 0x25ED68. We're going to leave the full details of the data block for later, but below is the data you should actually see for the English Oni SUBT file at this address. You have to consult the [[SUBT]] page to know how to read this data.

{{Table}}
{{OBDth}}
{{OBDtr| 0x08 | char[16] | | AD DE | dead | unused }}
{{OBDtr| 0x18 | offset | | 80 44 44 01 | 0x01444480 | raw file data address }}
{{OBDtr| 0x1C | int32 | | 61 02 00 00 | 609 | array size }}
|}

After '''padding''' of 16 unused bytes, we find that, instead of data, there's an address of the actual data: it's in the level's raw file. Open level0_Final.raw and jump to address 0x01444480, and you should see "01_01_01 Griffin: Give me another reading.", and the rest of some very familiar dialogue continuing from there.

The '''array size''' of 609 tells the part of the engine that reads SUBT data to expect a chunk of 609 subtitled lines of dialogue.

==Name descriptors==
The name descriptor array starts immediately after the instance descriptors array. To find the end of the instance descriptors, we can simply take the size of an instance descriptor, 20 bytes, and multiply it by the number of instance descriptors in the file header. In this case, that means 20 * 9347 = 186940, or 0x02DA3C. Adding that to 0x40 (the start of the instance descriptors) takes us to address 0x02DA7C. Voila, the start of the name descriptors.

The name descriptor array stores the numbers of all named instances in the alphabetical order by said names, which are found in the name block but also pointed to by these entries. This array is used by the engine to look up instances by name; it's also used to find instances by template (scanning just the tag at the start of each name). The purpose of this array being alphabetized was to allow the engine to do a binary search to find instances by name more quickly, but the retail engine no longer attempts a binary search and merely iterates over the array from start to end.

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | int32 | | 15 16 00 00 | 5653 | instance descriptor index }}
{{OBDtr| 0x04 | int32 | | 60 2C 1C 0E | (garbage) | runtime: pointer to instance name }}
|}

The index number here is referring to the instance's position in the instance descriptor array. This number is also used by the data block to identify each instance, thus it is found in two places in the data explicitly and one place implicitly.

Since the addresses of the names in memory cannot be known until the file is loaded into RAM, a space of 32 bits is reserved for each pointer at runtime.

==Template descriptors==
Likewise, the template descriptor array starts directly after the name descriptors. Since name descriptors are 8 bytes, 8 * 7124 (taken from the header) = 56992, or 0xDEA0, and adding that to the name descriptor array's start address (0x02DA7C) gives us 0x03B91C as the start of the template descriptors.

The template descriptor array contains information about all templates (that is, resource types, aka tags), used in the file (56 in this case, as we learned from the file header). Any resource occurring in this instance file has to have its type listed here. Here is the template descriptor at 0x3B9FC:

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | int64 | | 3C B9 A6 71 08 00 00 00 | 0x871A6B93C | template checksum }}
{{OBDtr| 0x08 | tag | | 45 47 52 54 | 'EGRT' | template tag }}
{{OBDtr| 0x0C | int32 | | 01 00 00 00 | 1 | unused: number of resources in file that use this template }}
|}

The '''template checksum''' is used to prevent loading of instance files that are not compatible with the current engine version. The '''tag''' is the same kind of number-written-as-backwards-ASCII that we discussed in the "Backwards and garbage data" section; in this case, 'EGRT' means [[TRGE]]. The field for the '''number of resources''' using this template is unused. The number should be correct for each template, but Oni never uses it for anything.

You might wonder how Oni knows how to read each type of data, such as a SUBT or an ABNA. The simple answer is that this information is hard-coded into Oni. In fact, the information on each instance type, as stored in Oni's code, is actually the real "template". The file data merely gives the tag and checksum that identify the template in use so that Oni knows how to read the following data fields. These hardcoded templates also tell Oni which parts of the file data are reserved for pointers.

That's because an instance may have pointers to other related instances, but pointers are only valid in memory; they cannot be stored meaningfully on disk. They must be set at runtime when the level data is loaded into memory and an address in RAM has been assigned. Thus one type of data field in Oni's templates is a "raw data" pointer; on Macs and the Windows demo, there is an additional "separate data" pointer. These pointers are 32 bits in length, as one must expect since Oni was compiled for 32-bit PCs.

Incidentally, the templates in Oni's code have not just the familiar four-character tags attached to them, but also a descriptive string, e.g. "BSP Tree Node Array". These strings were typed into the source code where each template structure was defined, and eventually extracted from the binary by modders. This is the source of the names on [[OBD:File types]].

==Data block==
The data block occupies the majority of the file and stores all the instance data (though this data sometimes points to the location of more data in a raw/separate file). We peeked at this block before when we looked at the instance descriptor for SUBTsubtitles. The block's starting point is found at the offset given in the header, in this case 0x03BCA0, saving us the trouble of adding up the size of the four preceding segments of the file and then aligning to the next 32-byte boundary.

The reason we'd need to align to 32 bytes is that the start of each instance's record (the instance ID) is always 32 byte-aligned. Thus, even though the template descriptors ended at 0x03BC9C, there are four empty bytes here so that the data block can begin at 0x03BCA0, which divides evenly by 32. This alignment rule also means that the instance-specific data will always start at an offset like 0x0008, 0x0028, 0x0148, etc.

The instance ID and file ID are not actually part of the instance data but are considered to be the resource header. The engine always keeps pointers to the start of the type-specific data itself; we saw this before when we jumped to 0x25ED68 and saw the data for the SUBT rather than the header for this data. The instance ID and file ID are accessed using negative offsets when needed (usually to find the name or template tag of an instance, given a pointer to it).

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | res_id | | 01 0B 04 00 | 1035 | instance descriptor index }}
{{OBDtr| 0x04 | lev_id | | 01 00 00 06 | 3 | level number }}
{{OBDtr| 0x08 | ... | | ... | ... | type-specific data... }}
|}

This example is taken from level 3 so that the file ID is more instructive. In the OBD documentation, these fields are called res_id and lev_id as seen above.

The '''instance's ID''' is stored as "(instance descriptor index << 8) | 1". Thus the ID for item #1,035 (0x40B) in the instance descriptor index will be encoded as 0x40B01. The '1' is used by the engine to mark which IDs have already been converted to pointers (an instance pointer will always be 8-byte aligned, so it will never have the zero bit already set). These pointer flags were retained when the file was written to disk but are meaningless now. At level-load time the flags are cleared and then set again when Oni allocates memory for each instance. The purpose of left-shifting the index number is simply to leave the lowest byte open for the pointer flag.

The '''file ID''' is computed from the number found in the name of the instance file: "(level number << 25) | 1". Thus instances found in level3_Final.dat will have the file ID encoded as 0x6000001. Again, the '1' is used by the engine to know which file IDs have been converted to pointers at runtime, but on disk this is a relic which has no meaning to us. The reason for left-shifting the level number might have originally been to store it alongside the instance ID and the pointer flag in a single int32, but they are separate numbers now, perhaps so that both IDs can have their own pointer flag.

After the header, the size of each instance's data is of a somewhat arbitrary length depending on the template this instance falls under. As mentioned under "Instance descriptors", the data size given by the descriptor includes the 8-byte resource header and the padding at the end of the data to align the next instance on 32 bytes.

===Looking backward from data to instance===
By the way, if you pick a random place in the data block to look at with a hex editor, how do you know which resource you're looking at? You would look for the highest data offset in the instance descriptor array that is less than your position in the file. Let's say that the string at 0x3BD40 caught our eye: "powerup_ammo". Subtracting the start of the data block, 0x3BCA0, gives us 0xA0 as the position of this string. Now looking back at the instance descriptor array, the instances' data offsets occur every 20 bytes and come directly after the tags. We can see that the first data offset is 0x8 and the next one is 0xF68, thus our offset into the data block of 0xA0 means we are looking at the instance which starts at 0x8. It's the very first instance listed at the start of the instance descriptor array:

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | tag | | 53 47 4E 4F | 'ONGS' | template tag }}
{{OBDtr| 0x04 | int32 | | 08 00 00 00 | 0x08 | data offset (relative to data block) }}
{{OBDtr| 0x08 | int32 | | 00 00 00 00 | 0x00 | name offset (relative to name block) }}
{{OBDtr| 0x0C | int32 | | 60 0F 00 00 | 3936 | data size }}
{{OBDtr| 0x10 | int32 | | 00 00 00 00 | 0 | flags }}
|}

So this tells us that the first data in the data block belongs to the solitary [[ONGS]] resource, and that it extends for 3,936 bytes. Since its name offset is 0x0, it's the first string in the name block, which we can see below is SUBTsubtitles.

==Name block==
This final segment of the file (third-to-last in a .oni, followed by the data and raw/sep blocks) stores all the instance names as C-style ASCII strings (terminated by a zero byte). We peeked at this before when we looked at the instance descriptor for SUBTsubtitles. The start of this block is 32-byte aligned but after that the strings are simply packed end to end, separated only by their null terminator. As with the data block, the name block's starting point is given in the header, in this case 0x28F240.

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | string | | 53 55 ... 00 | "SUBTsubtitles" | name string (zero-terminated) }}
|}

These names can be up to 63 characters long, counting the tag. The instance file concludes with the end of the name block, or the raw/sep block in a .oni file.

{{OBD}}

OBD:TSFT

2026-04-16T19:58:32Z

Iritscen: PC = Win/Mac, consistent with rest of wiki; gave PC and PS2 sections their own subheaders

{{OBD_File_Header | type=TSFT | prev=TSFL | next=TSGA | name=Font | family=Interface | align=center}}

==PC implementation==
[[Image:tsft_a.gif]]

[[Image:tsft_m.gif]]

[[Image:tsft_e.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x000 | res_id |FF0000| 01 03 00 00 | 3 | 00003-.TSFT }}
{{OBDtr| 0x004 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr| 0x008 | dead[6] |FFFFFF| AD DE | dead | not used }}
{{OBDtr| 0x00E | int16 |00FF00| 07 00 | 7 | font size in points }}
{{OBDtr| 0x010 | int32 |FFFFFF| 01 00 00 00 | 1 | font option; the following options are possible:

:0 - normal font
:1 - '''bold font'''
:2 - ''italic font''
}}
{{OBDtr| 0x014 | int16 |FFFFFF| 09 00 | 9 | [[wikt:ascender#Noun|ascender]] height }}
{{OBDtr| 0x016 | int16 |FFFFFF| 02 00 | 2 | [[wikt:descender#Noun|descender]] height }}
{{OBDtr| 0x018 | int16 |FFFFFF| 02 00 | 2 | [[wikt:leading#Noun_2|leading]] height }}
{{OBDtr| 0x01a | int16 |FFFFFF| 02 00 | 2 | ignored }}
{{OBDtrBK|Room for 256 TSGA links (only the first one is typically used for Western languages)}}
{{OBDtr| 0x01C | link |00FFFF| 01 04 00 00 | 4 | link to [[OBD:TSGA|00004-.TSGA]] (glyph array for character codes 0-255) }}
{{OBDtr| 0x020 | link |00FFFF| 00 00 00 00 | 0 | unused }}
{{OBDtr| ... | ... |00FFFF| ... | ... | ... }}
{{OBDtr| 0x418 | link |00FFFF| 00 00 00 00 | 0 | unused }}
{{OBDtrBK|Pixel data for the glyphs (8-bit intensities for four pixels at a time, stored as 32-bit integers)}}
{{OBDtr| 0x41C | int32 |FF00FF| 4F 0E 00 00 | 3663 | array size (one element has a length of 4 bytes) }}
{{OBDtr| 0x420 | int32 |C0C0C0| FF FF FF FF | 255,255,255,255 | the first 4 pixels (all white) of the first used glyph }}
{{OBDtr| ... | ... |C0C0C0| ... | ... | the rest of the pixel data }}
{{OBDtrBK|Alternative pixel storage used by PS2 implementation}}
{{OBDtr| 0x41C | offset |FF00FF| 20 00 00 00 | 0x00000020 | offset of the pixel data in the .raw file }}
|}

==PS2 implementation==
*The PC TSFTs store pixel data in a variable-size array (number of elements announced at 0x41C, then 4 bytes per element). PS2 TSFTs instead store the pixel data in the .raw file, using the field at 0x41C to store the offset.
*PC TSFTs use a whole byte for every pixel, i.e. 256 shades of gray, which in theory allows for subtle antialiasing. (In practice the antialiasing of Oni's fonts is anything but subtle, and the engine further posterizes them from 8-bit to 4-bit when rendering text.) PS2 fonts use only 2 bits per pixel, i.e., only 4 degrees of brightness/opacity.
*The PC engine uses a "black-on-white" representation of the font, with blank areas stored as 0xFF and fully opaque pixels as 0x00. PS2 uses "white-on-black", so a single opaque pixel in a row of four will be stored as 0x03, 0x0C, 0x30 or 0xC0.
*In PC Oni, the pixel rows for a given glyph can span across several 4-byte array elements, but pixel data for a new glyph must always start at the first byte of an array element (glyph data in a PC TSGA is indexed by TSFT array element, not by pixel). Therefore, on PC, if a glyph has, say, 33 8-bit pixels, then there will be 33 bytes of actual storage, spanning 4 whole array elements and 1 byte of a 5th element, and the rest of the 5th element (3 bytes) will be padded (typically with "DE AD" bytes). Inside the PS2 .raw file, the storage is not padded or aligned in any way, and the indexation for each glyph (from TSGA) is by pixel, i.e. by quarter-of-a-byte.
*Same as on PC, pixel rows are stored top-to-bottom, and each row is stored left-to-right, using lower bits first. For example, the 4x11 bitmap for a 7pt regular double-quote character ("), would be encoded as the following 11 bytes if it was byte-aligned:
byte 0x00 (00000000 low-to-high)
byte 0x33 (11001100 low-to-high)
byte 0x33 (11001100 low-to-high)
byte 0x33 (11001100 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
However, the actually stored pixel data for (") is shifted by half a byte because of the previous two glyphs, which are both 3x11 and take up 33 quarter-bytes each. Therefore the actual storage for (") looks like this:
byte 0x?0 (....0000 low-to-high, lower 4 bits belong to previous glyph)
byte 0x30 (00001100 low-to-high)
byte 0x33 (11001100 low-to-high)
byte 0x33 (11001100 low-to-high)
byte 0x03 (11000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x0? (0000.... low-to-high, upper 4 bits belong to next glyph)

{{OBD_File_Footer | type=TSFT | prev=TSFL | next=TSGA | name=Font | family=Interface}}

{{OBD}}

OBD:M3GM

2026-04-16T19:55:06Z

Iritscen: more link tweaks, and better wording for GMAN

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

==PC implementation==
This format is used by the Windows and Mac versions of the engine.

[[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 00218-.[[OBD:PNTA|PNTA]] (vertex XYZs) }}
{{OBDtr|0x10|link |FFFFC8|01 F7 00 00|247 | link to 00247-.[[OBD:VCRA|VCRA]] (vertex normals) }}
{{OBDtr|0x14|link |FFFFC8|01 F0 00 00|240 | link to 00240-.VCRA (face normals) }}
{{OBDtr|0x18|link |FFFFC8|01 ED 00 00|237 | link to 00237-.[[OBD:TXCA|TXCA]] (vertex UVs) }}
{{OBDtr|0x1C|link |FFFFC8|01 0C 01 00|268 | link to 00268-.[[OBD:IDXA_M3GM_1|IDXA (type 1)]] (triangle strips) }}
{{OBDtr|0x20|link |FFFFC8|01 11 01 00|273 | link to 00273-.[[OBD:IDXA_M3GM_2|IDXA (type 2)]] (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 the engine for its simple 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 how animated textures (TXAN) consist of an array of TXMPs – by picking M3GMs from an array (GMAN) and displaying them at a specified frame rate, optionally with randomization. This would have allowed complete transformation of an object on a per-point level instead of only the rotation and translation of the whole object that is currently possible via [[OBD:OBAN|OBAN]].

===Collision===
M3GMs have no inherent collision for physics purposes, but they will gain them if spawned via [[OBD:OBOA|OBOA]].

==PS2 implementation==
:PS2 M3GMs have the same data size as PC 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), as two int32s.
:*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) }}
{{OBDtr|0x0C|uint32 |FFC8C8|60 00 00 00|96 | number of faces (same as in second VCRA on PC) }}
{{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 an 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 }}
|}

;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) 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:TRAM

2026-04-16T19:39:05Z

Iritscen: "PC" is now consistently used on the wiki to mean "Win/Mac"

{{OBD_File_Header | align=center | type=TRAM | prev=TRAC | next=TRAS | name=Totoro Animation Sequence | family=Character}}

[[Image:Tram_all.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x000 | res_id |FF0000| 01 49 07 00 | 1865 | 01865-KONCOMpunch_heavy.TRAM }}
{{OBDtr| 0x004 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr| 0x008 | int32 |FFC8C8| 00 00 00 00 | 0 | runtime only; pointer to animation name }}
{{OBDtr| 0x00C | offset |FFFFC8| A0 B4 80 00 | 0x0080B4A0 | raw file offset of the [[OBD:TRAM/raw0x0C|height]] track (Y-position of the pelvis above the root) }}
{{OBDtr| 0x010 | offset |FFFFC8| E0 B5 80 00 | 0x0080B5E0 | raw file offset of the [[OBD:TRAM/raw0x10|horizontal velocities]] of the character root }}
{{OBDtr| 0x014 | offset |FFFFC8| 60 B8 80 00 | 0x0080B860 | raw file offset of the [[OBD:TRAM/raw0x14|attack part]] }}
{{OBDtr| 0x018 | offset |FFFFC8| 00 00 00 00 | unused | raw file offset of the [[OBD:TRAM/raw0x18|damage part]] (used only by "_tgt" animations (throw targets/victims) }}
{{OBDtr| 0x01C | offset |FFFFC8| A0 B8 80 00 | 0x0080B8A0 | raw file offset of the [[OBD:TRAM/raw0x1C|motion blur part]] }}
{{OBDtr| 0x020 | offset |FFFFC8| C0 B8 80 00 | 0x0080B8C0 | raw file offset of the [[OBD:TRAM/raw0x20|shortcut data]] }}
{{OBDtr| 0x024 | offset |FFFFC8| 00 00 00 00 | unused | raw file offset of the [[OBD:TRAM/raw0x24|throw data]] (including effective distance of throw) }}
{{OBDtr| 0x028 | offset |FFFFC8| E0 B8 80 00 | 0x0080B8E0 | raw file offset of the [[OBD:TRAM/raw0x28|footstep data]] }}
{{OBDtr| 0x02C | offset |FFFFC8| 00 B9 80 00 | 0x0080B900 | raw file offset of the [[OBD:TRAM/raw0x2C|particle data]] (trails, dust, etc.) }}
{{OBDtr| 0x030 | offset |FFFFC8| 60 B9 80 00 | 0x0080B960 | raw file offset of the [[OBD:TRAM/raw0x30|position data]] (for basic prediction) }}
{{OBDtr| 0x034 | offset |FFFFC8| 00 BD 80 00 | 0x0080BD00 | raw file offset of the [[OBD:TRAM/raw0x34|rotations]] (of all body parts) }}
{{OBDtr| 0x038 | offset |FFFFC8| 00 00 00 00 | unused | raw file offset of the [[OBD:TRAM/raw0x38|sound data]] }}
{{OBDtr| 0x03C | bitset32 |C8FFC8| 90 00 08 00 | attack, atomic, dontAim| flags; listed in [[OBD:StNA|StNA]]anim_flags (except that StNAanim_flags is missing the dontAim flag, which offset the following flags when it was added to the engine); the bits are as follows:
:0x'''01''' 00 00 00 - prepared (used at runtime only; marks that the animation was loaded)
:0x'''02''' 00 00 00 - invulnerable
:0x'''04''' 00 00 00 - blockHigh
:0x'''08''' 00 00 00 - blockLow
:0x'''10''' 00 00 00 - attack
:0x'''20''' 00 00 00 - dropWeapon
:0x'''40''' 00 00 00 - inAir (unused)
:0x'''80''' 00 00 00 - atomic
:0x00 '''01''' 00 00 - noTurn
:0x00 '''02''' 00 00 - attackForward
:0x00 '''04''' 00 00 - attackLeft
:0x00 '''08''' 00 00 - attackRight
:0x00 '''10''' 00 00 - attackBackward
:0x00 '''20''' 00 00 - overlay
:0x00 '''40''' 00 00 - dontInterpolateVelocity
:0x00 '''80''' 00 00 - throwSource
:0x00 00 '''01''' 00 - throwTarget
:0x00 00 '''02''' 00 - realWorld
:0x00 00 '''04''' 00 - doAim
:0x00 00 '''08''' 00 - dontAim
:0x00 00 '''10''' 00 - canPickup
:0x00 00 '''20''' 00 - aim360
:0x00 00 '''40''' 00 - disableShield
:0x00 00 '''80''' 00 - noAIPickup

;invulnerable
This animation makes the character impervious to melee damage and throws. He can still take damage from particles and falls.

;blockHigh, blockLow
An animation with one of these flags can block attacks coming from the front if they have the high/low attack bit on in [[OBD:TRAM/raw0x14|0x14]].

;attack, throwSource, throwTarget, realWorld as proxy flags
These flags were looked at by Importer, Bungie West's authoring tool, which assigned the dontAim flag to an animation if any of them were found. Additionally, Importer used throwSource and throwTarget as indicators that an animation should be flagged as noTurn, but Oni itself also refuses to allow turning when it sees these flags. Within Oni, the attack flag has no effect.

;throwSource, throwTarget
Besides serving as proxies, throwSource and throwTarget are used in numerous places in the code to handle throws properly, so they should always be assigned appropriately to throw anims. throwTarget in particular allows your teammates to be hurt by an enemy you throw.

;realWorld
This flag only served a purpose when the animation was imported from 3ds Max. Animations without this flag had their extents prepared by Importer. Has no effect within Oni except signifying a lack of attack extents data for visual debugging purposes.

;atomic
Has no effect within Oni. When seen by Importer during authoring, however, it set the entire animation to atomic by maxing out the range of the atomic start and end frames (0x174, 0x176).

;noTurn
This refers to the user's ability to turn with the controls.

;attackForward, attackLeft, attackRight, attackBackward
Have no effect within Oni. Used by Importer to set the movement direction at 0x54.

;doAim
Applies aiming screen (PIS/RIF) if character has a weapon.

;dontAim
Prevents aiming screen from being applied.

;aim360
No effect in Oni. Was used by Importer as a cue to mark the attack's direction (0x54) as 360° (but only Forward, Backward, Left and Right seem to be used in the game data).

;disableShield
Used on certain Mutant Muro attacks to temporarily remove his supershield (the anims are listed on [[XML:TRAM]] under its DisableShield documentation).
}}
{{OBDtr| 0x040 | link |C8FFFF| 00 00 00 00 | unused | direct animation 0 (link to another TRAM file) }}
{{OBDtr| 0x044 | link |C8FFFF| 00 00 00 00 | unused | direct animation 1 (link to another TRAM file); see {{SectionLink||Direct links}} }}
{{OBDtr| 0x048 | bitset32 |FFC8FF| 00 00 00 00 | 0 | used body parts; for original 19-bone hierarchy the bit layout is as follows:
:0x000000'''01''' - pelvis
:0x000000'''02''' - left thigh
:0x000000'''04''' - left calf
:0x000000'''08''' - left foot
:0x000000'''10''' - right thigh
:0x000000'''20''' - right calf
:0x000000'''40''' - right foot
:0x000000'''80''' - mid
:0x0000'''01'''00 - chest
:0x0000'''02'''00 - neck
:0x0000'''04'''00 - head
:0x0000'''08'''00 - left shoulder
:0x0000'''10'''00 - left arm
:0x0000'''20'''00 - left wrist
:0x0000'''40'''00 - left fist
:0x0000'''80'''00 - right shoulder
:0x00'''01'''0000 - right arm
:0x00'''02'''0000 - right wrist
:0x00'''04'''0000 - right fist
Aiming screen TRAMs use several bones here. Other overlay TRAMs use only "chest". Non-overlay TRAMs use none.
}}
{{OBDtr| 0x04C | bitset32 |FFC8FF| 00 00 00 00 | 0 | replaced parts; same bitset layout as above; only overlay TRAMs other than aiming-screen ones replace parts. }}
{{OBDtr| 0x050 | float |FFC800| 00 00 00 00 | 0.000000 | final rotation in radians (for anims that make you turn) }}
{{OBDtr| 0x054 | int16 |C800C8| 01 00 | 1 | main moving direction; the following directions are possible:
:0 - none
:1 - forward
:2 - backward
:3 - left
:4 - right
:5 - 360 (unused? even Devil Spin Kick uses "forward")
}}
{{OBDtr| 0x056 | uint16 |C87C64| 06 00 | 6 | vocalization type (-1 if unused); references one of the 10 vocalization slots in [[OBD:ONCC|ONCC]]
:0 - taunt
:1 - alert
:2 - startle
:3 - checkbody
:4 - pursue
:5 - cower
:6 - superpunch
:7 - superkick
:8 - super3
:9 - super4
In this case the value 6 triggers Konoko's "superpunch" vocalization, "Rising fury!" }}
{{OBDtrBK|Extent info}} See {{SectionLink||Extent info}} for explanation
{{OBDtr| 0x058 | float |B0C3D4| 8D 87 CF 41 | 25.941187 | max horizontal extent of the attack }}
{{OBDtr| 0x05C | float |B0C3D4| DE E9 1A 40 | 2.420524 | min Y of the attack }}
{{OBDtr| 0x060 | float |B0C3D4| 95 34 D3 41 | 26.400675 | max Y of the attack }}
{{OBDtr| 0x064 | float |B0C3D4| 8D 87 CF 41 | 25.941187 | max horizontal extent at 0° (front) }}
{{OBDtr| ... | ... |B0C3D4| ... | ... | ... }}
{{OBDtr| 0x088 | float |B0C3D4| DF 37 87 40 | 4.225570 | max horizontal extent at 90° (left) }}
{{OBDtr| ... | ... |B0C3D4| ... | ... | ... }}
{{OBDtr| 0x0AC | float |B0C3D4| 5A D8 6D 40 | 3.716330 | max horizontal extent at 180° (back) }}
{{OBDtr| ... | ... |B0C3D4| ... | ... | ... }}
{{OBDtr| 0x0D0 | float |B0C3D4| 98 95 E3 40 | 7.112011 | max horizontal extent at 270° (right) }}
{{OBDtr| ... | ... |B0C3D4| ... | ... | ... }}
{{OBDtr| 0x0F0 | float |B0C3D4| 8D 87 CF 41 | 25.941187 | max horizontal extent at 350° }}
{{OBDtrBK|First extent info - information about the first extent in the extent part}}
{{OBDtr| 0x0F4 | int16 |E7CEA5| 05 00 | 5 | frame; -1 if the attack part does not exist }}
{{OBDtr| 0x0F6 | int8 |FFDDDD| 00 | 0 | attack index; always 0 }}
{{OBDtr| 0x0F7 | int8 |FFDDDD| 00 | 0 | attack frame offset; always 0 }}
{{OBDtr| 0x0F8 | float |64AAAA| 00 00 00 BF | -0.500000 | x location of the pelvis }}
{{OBDtr| 0x0FC | float |64AAAA| 1E 85 6B BF | -0.920000 | z location of the pelvis }}
{{OBDtr| 0x100 | float |64AAAA| 19 47 0C 41 | 8.767358 | y location of the pelvis }}
{{OBDtr| 0x104 | float |64AAAA| EB 51 F0 40 | 7.510000 | extent length }}
{{OBDtr| 0x108 | float |64AAAA| D7 A3 14 41 | 9.290000 | extent min Y }}
{{OBDtr| 0x10C | float |64AAAA| 0A D7 3B 41 | 11.740000 | extent max Y }}
{{OBDtr| 0x110 | float |64AAAA| 5E 93 BF 40 | 5.986739 | extent angle (in radians) }}
{{OBDtrBK|Farthest extent info - information about the farthest reaching extent in the extent part }}
{{OBDtr| 0x114 | int16 |EBEBEB| 2F 00 | 47 | frame; -1 if there is no attack part of if the animation is for a throw target/victim ("_tgt") }}
{{OBDtr| 0x116 | int8 |8C8CCC| 01 | 1 | attack index to which the max extent belongs }}
{{OBDtr| 0x117 | int8 |FF00C8| 16 | 22 | attack frame offset from the attack with index 0 }}
{{OBDtr| 0x118 | float |F0F096| 85 EB 51 BF | -1.850000 | x location of the pelvis }}
{{OBDtr| 0x11C | float |F0F096| E1 7A 7C C1 | -3.900000 | z location of the pelvis }}
{{OBDtr| 0x120 | float |F0F096| 69 61 BF 40 | 16.874636 | y location of the pelvis }}
{{OBDtr| 0x124 | float |F0F096| 70 3D 22 41 | 10.510000 | extent length }}
{{OBDtr| 0x128 | float |F0F096| 47 E1 3A 40 | 8.860000 | extent min Y }}
{{OBDtr| 0x12C | float |F0F096| 33 33 DB 40 | 18.460000 | extent max Y }}
{{OBDtr| 0x130 | float |F0F096| F7 C0 2E 3E | 0.055320 | extent angle }}
{{OBDtrBK|End max extent info }}
{{OBDtr| 0x134 | int32 |00C864| 00 00 00 00 | 0 | alternative move direction; used only when the previous move direction field is 0, that means never }}
{{OBDtr| 0x138 | int32 |00C8FF| 18 00 00 00 | 24 | number of elements in the extent part }}
{{OBDtr| 0x13C | offset |C80040| E0 BB 80 00 | 00 80 BB E0 | at this position starts the [[OBD:TRAM/raw0x13C|extent part]] in the raw file }}
{{OBDtrBK|End extent info}}
{{OBDtr2|0x140 | char[16] |FFCD96| konflash1 | impact particle name (reference to 01018-.[[OBD:ONIA|ONIA]], which is called up in the [[OBD:ONCC|ONCC]] file) }}
{{OBDtr| 0x150 | uint16 |C8C864| 00 00 | 0 | hard pause in game ticks (1/60 seconds) }}
{{OBDtr| 0x152 | uint16 |C8C864| 12 00 | 18 | soft pause in game ticks (1/60 seconds) }}
{{OBDtr| 0x154 | int32 |0096C8| 00 00 00 00 | 0 | number of elements in the sound part }}
{{OBDtr| 0x158 | int32 |FF80C0| 00 00 00 00 | 0 | runtime only; pointer to the sound for this animation (from [[OBD:BINA/SABD|SABD]])}}
{{OBDtr| 0x15C | int16 |D0C0AF| 00 00 | 0 | runtime only; sound start frame (from SABD) }}
{{OBDtr| 0x15E | int16 |D0C0AF| 3C 00 | 60 | animation frame rate (always 60?) }}
{{OBDtr| 0x160 | int16 |EEDDFF| 06 00 | 6 | compression size }}
{{OBDtr| 0x162 | int16 |EEDDFF| 16 00 | 22 | animation type (from [[XML:StNA|StNA]]) }}
{{OBDtr| 0x164 | int16 |C5FF8A| 16 00 | 22 | aiming type from StNA }}
{{OBDtr| 0x166 | int16 |C5FF8A| 00 00 | 0 | from state; see {{SectionLink||From state, to state, animation type, variant, shortcuts}} }}
{{OBDtr| 0x168 | int16 |C0C0C0| 07 00 | 7 | to state }}
{{OBDtr| 0x16A | int16 |C0C0C0| 13 00 | 19 | number of body parts }}
{{OBDtr| 0x16C | int16 |FF0080| 50 00 | 80 | number of frames }}
{{OBDtr| 0x16E | int16 |FF0080| 50 00 | 80 | duration in game ticks (1/60 seconds) }}
{{OBDtr| 0x170 | bitset16 |FFFFA6| 00 02 | 0x0200 <nowiki>=</nowiki> COM| variant, the following bits are possible (values in hex):
:0x'''01'''00 - "sprint" ('''SPR'''int animation)
:0x'''02'''00 - "fight" ('''COM'''bat animation)
:0x'''04'''00 - "shoulder" (not used by the engine; apparently used at one time for weapons like [[:Image:Pre-beta enigma 5.png|rocket launchers]])
:0x'''08'''00 - "righty pistol" ('''PIS'''tol animation)
:0x'''10'''00 - "lefty pistol" ('''NIN'''ja '''PIS'''tol animation)
:0x'''20'''00 - "righty rifle" ('''RIF'''le animation)
:0x'''40'''00 - "lefty rifle" ('''NIN'''ja '''RIF'''le animation)
:0x'''80'''00 - "panic" ('''PAN'''ic or '''SCR'''amble animation)
}}
{{OBDtr| 0x172 | char[2] |FFFFA6| AD DE | dead | "varient end"; ignored by the engine }}
{{OBDtr| 0x174 | uint16 |71FFB8| 00 00 | 0 | atomic start }}
{{OBDtr| 0x176 | uint16 |71FFB8| FF FF | 65535 | atomic end }}
{{OBDtr| 0x178 | uint16 |0000BF| 00 00 | 0 | end interpolation }}
{{OBDtr| 0x17A | uint16 |0000BF| FF FF | 65535 | maximum interpolation }}
{{OBDtr| 0x17C | uint16 |804040| FF FF | 65535 | action frame; e.g. when weapon theft occurs in a disarm anim }}
{{OBDtr| 0x17E | uint16 |804040| 0A 00 | 10 | first level where the animation is available }}
{{OBDtr| 0x180 | uint8 |FF22FF| 01 | 1 | first "invulnerable" frame }}
{{OBDtr| 0x181 | uint8 |FF22FF| 1C | 28 | last "invulnerable" frame }}
{{OBDtr| 0x182 | uint8 |808080| 02 | 2 | number of elements in the attack part above }}
{{OBDtr| 0x183 | uint8 |808080| 00 | 0 | number of elements in the take damage part above }}
{{OBDtr| 0x184 | uint8 |FFAA82| 01 | 1 | number of elements in the motion blur part above }}
{{OBDtr| 0x185 | uint8 |FFAA82| 01 | 1 | number of elements in the shortcut part above }}
{{OBDtr| 0x186 | uint8 |00D900| 02 | 2 | number of elements in the footstep part above }}
{{OBDtr| 0x187 | uint8 |00D900| 04 | 4 | number of elements in the particle part above }}
{{OBDtr| 0x188 | char[24] |CACAFF| AD DE | dead | unused (not part of the template) }}
|}

==Animation timeline==
:'''NOTE:''' The following assumes animation data sampled at 60 frames per second (i.e., in sync with game ticks). Different frame rates have not been studied, and OniSplit only works with 60 fps TRAMs.
The duration of an animation in game ticks is equal to the number of frames covered by the main animation data, i.e., it extends one tick past the last keyframe of the height track or rotation tracks. Over this last tick, the pelvis height and bone rotations are interpolated to the values supplied by the first frame of the ''following'' animation, whereas the horizontal position is advanced using the last velocity entry of the current animation.

Thus an important note about looping animations is that the poses at the start and end of an animation (a combination of height, bone rotation and the accumulated horizontal velocity) are generally ''not'' identical, but rather one tick apart. The same applies to animation pairs (locomotion loops) or any matching animation sequences (e.g., combos).

For the current example (KONCOMpunch_heavy), the duration is 80 ticks, and the main animation tracks are as follows:
*The [[/raw0x0C|height]] track has 80 entries that are used to place the character vertically at every tick, starting at tick 0 and ending at tick 79. At tick 80, i.e., at the end of the current animation's duration, the height is supplied by the next animation. Between ticks 79 and 80, the height is interpolated between the last height entry of KONCOMpunch_heavy and the first height entry of the next animation.
*The [[/raw0x10|velocity]] tracks (horizontal motion of the root) also have 80 entries. However, unlike the height values, the velocities correspond not to ticks but to intervals between ticks, and thus span the whole range of the animation, from tick 0 to tick 80. Starting at tick 80, the first velocity entry of the following animation applies.
*The [[/raw0x34|rotation]] tracks are keyed at ticks (like the height track), but (unlike the height track) are typically not keyed at ''every'' tick: there are intervals (gaps) of variable size between the keys, over which the rotation of each bone is interpolated. Even so, the total duration of the intervals is the same as the time span of the height track, i.e., one tick shorter than the "duration" of the animation. In this example, the first rotation pose corresponds to tick 0 and the last pose corresponds to tick 79. At tick 80, the pose will be read from the following animation, and between ticks 79 and 80, the pose will be interpolated between the last pose of KONCOMpunch_heavy and the first pose of the next animation.
'''NOTE:''' The above description of how heights and rotations are interpolated during the last tick on an animation's duration does not only apply for most of Oni's transitions, which typically involve overlapping timelines and interpolation between two animations playing simultaneously. Nonetheless, the description is useful to understand why the time span of rotation and height data is one tick shorter than the supposed duration of the animation, and also what happens for loops, pairs or combo sequences.

==Direct links==
These fields work together with soft pause and hard pause fields when switching animations. When the current animation has a direct link to the new animation the soft pause and hard pause are both considered to be 0.
;Example
01855-KONCOMcomb_p_p.TRAM links to:
*01856-KONCOMcomb_p_p_p.TRAM (direct animation 0)
*01857-KONCOMcomb_p_p_k.TRAM (direct animation 1)

That means that if a p_p_p or p_p_k animation follows after a p_p animation there will be no pause between them but for animations other than p_p_p and p_p_k there may be a pause of 'soft pause' frames between them.

==Extent info==
The extent information is used by the AI to figure out if an attack can reach the enemy. This information is only present/used if the animation contains attacks. Many of the fields in the extent information can be computed from other available information like the attack/position/extent parts. The only "unique" information here is the "max horizontal extent 0° ... 360°" array and the extent part count/offset fields. The alternate move direction does not appear to be ever used.

==From state, to state, animation type, variant, shortcuts==
These are used to find specific animations. Each character has a current animation state and a current "varient". When the engine searches for an animation with a specific type it considers those that have a matching "from state" and "varient". For example both "comb_k_k" and "jump_fw_kick" animations have the type "kick" but one can be executed when the character is in the "standing" state and the other can be executed when the character is in "falling back" or "falling forward" states.

==Aiming Type==
Aiming type is used to find the aiming animation in [[TRSC]] and normally it is the same as the animation type. In a couple of cases this type is "none" meaning that no aiming animation should be used. It is pretty much equivalent to setting the "don't aim" flag.

==Particles==
While Oni can store a number as large as 255 in 0x187, Oni only allocates memory for 16 particles per TRAM, and it does not check to make sure that the actual number of particles is ≤ 16. Thus you can easily crash Oni by initiating a move which has 17 particles attached.

==Limitations on animation length==
Frame counts in Oni's TRAM are either absolute frame counts since the beginning of the animation, or intervals between events or keyframes.
:(The following analysis assumes 60 fps as an animation's frame rate. If the frame rate can be reduced, the limiting time amounts will increase accordingly.)

===16-bit frame counts===
Most typically a frame count is an unsigned 16-bit integer, which allows for a comfortable range of 65535 frames = 1092.25 seconds = 18 m 12.25 s. Even if the integer is accidentally parsed as 16-bit ''signed'', the wraparound to negative values only happens after 32767 frames = 546.13̅ seconds = 9 m 6.13̅ s. Oni has other contexts where frame counts are stored as 16-bit integers, e.g., [[OBD:SNDD|SNDD]] and [[OBD:OBAN|OBAN]].

===8-bit frame counts===
Some of the frame counts inside a TRAM are stored as 8-bit integers (unsigned), which reduces the range to 255 frames = 4.25 seconds (or, in the event of signed interpretation, 127 frames = 2.116̅ seconds). 
The contexts where 8-bit frame counts occur are as follows.
*[[OBD:TRAM/raw0x1C|Motion blur]], "Lifetime" and "Interval", meaning that "ghosts" can be spawned no more than 4.25 seconds apart and can last no more than 4.25 seconds before disappearing (LIMITATION SEVERITY: MINOR)
*[[OBD:TRAM/raw0x34|Rotation data]], intervals between a bone's keyframes, meaning that rotation keyframes for a bone cannot be more than 4.25 seconds apart. (LIMITATION SEVERITY: MINOR)
*"Max/farthest extent info" (main TRAM file, see above): the "attack frame offset from the attack with index 0" is an 8-bit frame interval, meaning that attacks belonging to a same TRAM cannot be more than 4.25 seconds apart, or the extent of the later attacks may not be taken into account properly by the AI. (LIMITATION SEVERITY: Can be an issue for very long special moves or throws, where damage is dealt both at the beginning and at the end of the animation.)
*"Invulnerable" range (main TRAM file, see above): The invulnerability range is a pair of 8-bit frame indices, meaning that the invulnerability range cannot extend past 4.25 seconds. (LIMITATION SEVERITY: Can be an issue for very long crowd-clearing moves, like a much longer "Whirling Dervish" (ELICOMpunch_heavy) or long versions of Muro's "Breakdancer" or "Helicopter" moves; a possible workaround is to set invulnerability for the whole animation rather than for an 8-bit frame range)

===16-bit raw data offsets===
Unlike files like [[OBD:AGDB|AGDB]] and [[OBD:SUBT|SUBT]] (which use 32-bit pointers into the .raw data stored in the .dat part), a TRAM's [[OBD:TRAM/raw0x34|rotation data]] starts off with a set of 16-bit offsets, stored in the .raw part and pointing into the following data (typically there are 19 such offsets, one for each bone in a skeleton).

For the last offset to work, it must be at most equal to 65535 and, since the first 38 bytes are taken up by the offsets, this leaves at most 65497 bytes for the cumulated size of the 18 first rotation tracks.

The raw size of a rotation track depends on the number of keyframe intervals (let's call it N) and on the compression size (either 6 or 16 bytes): a size-6 rotation track takes up 7N+6 bytes, and a size-16 rotation track takes up 17N+16 bytes.

For a size-6 animation, the "average N" for the first 18 tracks cannot exceed 518.96, so that 126N+108 stays below 65497. For a size-16 animation, this "average N" for the first 18 tracks must not exceed 213.1013, so that 306N+288 stays below 65497.

For an animation that has a keyframe for every bone at each game tick, a 518-frame duration corresponds to 8.63̅ seconds, whereas 213 frames = 3.55 seconds. Typically, however, rotation tracks will have significant keyframe reduction, e.g., Konoko's "Rising Fury!" lasts 80 frames but the pelvis rotation has only 23 keyframe intervals. Assuming 4:1 keyframe reduction for typical animations, this means that the 16-bit offset won't be an issue (for size-6 animations) unless the animation is longer than about 30 seconds.

==PS2 implementation==
The PS2 implementation optimizes TRAM storage by splitting off combat-relevant data (extents etc) to a new instance type, TREX (Totoro Animation Extra, see below). As a result, the TRAM size (with header) is reduced from 392 to 80 bytes.

{|cellpadding=3 cellspacing=0 style="line-height:13px"
{{HexRow|0x00|
|01|C8|03|00|01|00|00|00|01|45|06|00|00|00|00|00|
|FF|FF|FF|FF|FF|FF|FF|FF|00|00|00|00|FF|FF|FF|FF|
|00|00|00|00|FF|FF|FF|FF|FF|FF|FF|FF|C8|C8|C8|C8|
|00|00|00|00|00|00|00|00|00|00|00|00|C8|C8|C8|C8|
|°È°°°°°°°E°°°°°°
}}
{{HexRow|0x10|
|E0|EE|0F|00|20|F0|0F|00|80|F4|0F|00|A0|F4|0F|00|
|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|
|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|
|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|
|àî°° ð°° ô°° ô°°
}}
{{HexRow|0x20|
|C0|F4|0F|00|40|F7|0F|00|90|00|08|00|00|00|00|00|
|FF|FF|FF|FF|FF|FF|FF|FF|C8|C8|C8|C8|FF|FF|FF|FF|
|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|C8|C8|C8|C8|
|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|FF|FF|FF|FF|
|Àô°°@÷°° °°°°°°°
}}
{{HexRow|0x30|
|00|00|00|00|01|00|00|00|06|00|16|00|16|00|00|00|
|FF|FF|FF|FF|C8|C8|FF|FF|EE|EE|EE|EE|C5|C5|C5|C5|
|C8|C8|C8|C8|00|00|00|00|DD|DD|DD|DD|FF|FF|FF|FF|
|FF|FF|FF|FF|C8|C8|FF|FF|FF|FF|FF|FF|8A|8A|8A|8A|
|°°°°°°°°°°°°°°°°
}}
{{HexRow|0x40|
|07|00|50|00|00|02|AD|DE|00|00|FF|FF|00|01|02|13|
|C0|C0|FF|FF|FF|FF|FF|FF|71|71|71|71|FF|FF|00|C0|
|C0|C0|00|00|FF|FF|FF|FF|FF|FF|FF|FF|AA|AA|D9|C0|
|C0|C0|80|80|A6|A6|A6|A6|B8|B8|B8|B8|82|82|00|C0|
|°°P°°°-Þ°°ÿÿ°°°°
}}
{{HexRow|0x50|
|AD|DE|AD|DE|AD|DE|AD|DE|AD|DE|AD|DE|AD|DE|AD|DE|
|CA|CA|CA|CA|CA|CA|CA|CA|CA|CA|CA|CA|CA|CA|CA|CA|
|CA|CA|CA|CA|CA|CA|CA|CA|CA|CA|CA|CA|CA|CA|CA|CA|
|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|
|-Þ-Þ-Þ-Þ-Þ-Þ-Þ-Þ
}}
|}

{{Table}}
{{OBDth}}
{{OBDtr| 0x000 | res_id |FF0000| 01 C8 03 00 | 968 | 00968-KONCOMpunch_heavy.TRAM }}
{{OBDtr| 0x004 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr| 0x008 | link |00FF00| 01 45 06 00 | 1605 | link to 01605-.TREX (combat-relevant data) }}
{{OBDtr| 0x00C | int32 |FFC8C8| 00 00 00 00 | 0 | runtime only; pointer to animation name }}
{{OBDtr| 0x010 | offset |FFFFC8| E0 EE 0F 00 | 0x000FEEE0 | raw file offset of the [[OBD:TRAM/raw0x0C|height]] track (Y-position of the pelvis above the root) }}
{{OBDtr| 0x014 | offset |FFFFC8| 20 F0 0F 00 | 0x000FF020 | raw file offset of the [[OBD:TRAM/raw0x10|horizontal velocities]] of the character root }}
{{OBDtr| 0x018 | offset |FFFFC8| 80 F4 0F 00 | 0x000FF480 | raw file offset of the [[OBD:TRAM/raw0x20|shortcut data]] }}
{{OBDtr| 0x01C | offset |FFFFC8| A0 F4 0F 00 | 0x000FF4A0 | raw file offset of the [[OBD:TRAM/raw0x28|footstep data]] }}
{{OBDtr| 0x020 | offset |FFFFC8| C0 F4 0F 00 | 0x000FF4C0 | raw file offset of the [[OBD:TRAM/raw0x30|position data]] (for basic prediction) }}
{{OBDtr| 0x024 | offset |FFFFC8| 40 F7 0F 00 | 0x000FF740 | raw file offset of the [[OBD:TRAM/raw0x34|rotations]] (of all body parts) }}
{{OBDtr| 0x028 | bitset32 |C8FFC8| 90 00 08 00 | attack, atomic, dontAim | flags (same as PC's 0x03C) }}
{{OBDtr| 0x02C | bitset32 |FFC8FF| 00 00 00 00 | 0 | used body parts; used mostly by aiming overlays (same as PC's 0x048) }}
{{OBDtr| 0x030 | bitset32 |FFC8FF| 00 00 00 00 | 0 | replaced parts; used by non-aiming overlays (same as PC's 0x04C) }}
{{OBDtr| 0x034 | int16 |C800C8| 01 00 | 1 | moving direction }}
{{OBDtr| 0x036 | int16 |FF00FF| 00 00 | 1 | unknown }}
{{OBDtr| 0x038 | int16 |EEDDFF| 06 00 | 6 | compression size }}
{{OBDtr| 0x03A | int16 |EEDDFF| 16 00 | 22 | animation type (from [[XML:StNA|StNA]]) }}
{{OBDtr| 0x03C | int16 |C5FF8A| 16 00 | 22 | aiming type }}
{{OBDtr| 0x03E | int16 |C5FF8A| 00 00 | 0 | from state }}
{{OBDtr| 0x040 | int16 |C0C0C0| 07 00 | 7 | to state }}
{{OBDtr| 0x042 | int16 |FF0080| 50 00 | 80 | number of frames (animations are locked to 60 fps) }}
{{OBDtr| 0x044 | bitset16 |FFFFA6| 00 02 | 0x0200 <nowiki>=</nowiki> COM| variant (same as PC's 0x170) }}
{{OBDtr| 0x046 | char[2] |FFFFA6| AD DE | dead | "varient end"; ignored by the engine }}
{{OBDtr| 0x048 | uint16 |71FFB8| 00 00 | 0 | atomic start }}
{{OBDtr| 0x04A | uint16 |71FFB8| FF FF | 65535 | atomic end }}
{{OBDtr| 0x04C | uint8 |FFAA82| 00 | 0 | unknown }}
{{OBDtr| 0x04D | uint8 |FFAA82| 01 | 1 | number of elements in the shortcut part }}
{{OBDtr| 0x04E | uint8 |00D900| 02 | 2 | number of elements in the footstep part }}
{{OBDtr| 0x04F | uint8 |C0C0C0| 13 | 19 | number of body parts? }}
{{OBDtr| 0x050 | char[16] |CACAFF| AD DE | dead | unused (not part of the template) }}
|}
At the time of writing, some of the above data is merely an informed guess (not thoroughly confirmed), and the nature of 0x036 (int16?) and 0x04C (uint8?) needs to be clarified more particularly. If 0x036 is always zero, then maybe 0x034 is stored as an int32. We also need to locate "end/maximal interpolation" and possibly other remaining fields from the PC data format, or establish that they are missing from the TRAM/TREX representation of animations on PS2.

The TREX file has all the combat-relevant stuff as well as some stuff that isn't necessary combat-related (e.g., vocalizations, turning angle, moving direction).

The block between 0x008 and 0x0F0 is exactly the extent block between 0x058 and 0x140 in the PC TRAM. After that come the other 6 .raw links that were stripped from the reduced TRAM, the impact particle name, and the two direct TRAM links, which accounts for all the data up to 0x150 in the PC TRAM. Some data fields from the end of PC's TRAM are confirmed to be missing on PS2 (e.g., the frame rate is implied to be 60 Hz), but some of the correspondence is still not documented or thoroughly confirmed.
{|cellpadding=3 cellspacing=0 style="line-height:13px"
{{HexRow|0x000|
|01|45|06|00|01|00|00|00|8D|87|CF|41|DE|E9|1A|40|
|FF|FF|FF|FF|FF|FF|FF|FF|B0|B0|B0|B0|B0|B0|B0|B0|
|00|00|00|00|FF|FF|FF|FF|C3|C3|C3|C3|C3|C3|C3|C3|
|00|00|00|00|00|00|00|00|D4|D4|D4|D4|D4|D4|D4|D4|
|ºEºººººº ÏAÞéº@
}}
{{HexRow|0x010|
|95|34|D3|41|8D|87|CF|41|8D|87|CF|41|8D|87|CF|41|
|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|
|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|
|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|
| 4ÓA ÏA ÏA ÏA
}}
{{HexRow|0x020|
|8D|87|CF|41|9D|E4|11|41|14|BA|04|41|6B|77|D4|40|
|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|
|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|
|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|
| ÏAºººººººººººº
}}
{{HexRow|0x030|
|50|5A|B3|40|74|4B|9C|40|DF|37|87|40|70|75|84|40|
|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|
|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|
|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|
|ºººººººººººººººº
}}
{{HexRow|0x040|
|8E|ED|6A|40|16|40|5F|40|16|40|5F|40|BF|CD|45|40|
|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|
|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|
|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|
|ºººººººººººººººº
}}
{{HexRow|0x050|
|34|2B|49|40|34|2B|49|40|34|2B|49|40|5A|D8|6D|40|
|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|
|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|
|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|
|ºººººººººººººººº
}}
{{HexRow|0x0060|
|5A|D8|6D|40|5A|D8|6D|40|8F|D9|96|40|8F|D9|96|40|
|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|
|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|
|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|
|ºººººººººººººººº
}}
{{HexRow|0x070|
|B7|7B|AB|40|F0|81|BF|40|98|95|E3|40|98|95|E3|40|
|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|
|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|
|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|
|ºººººººººººººººº
}}
{{HexRow|0x080|
|98|95|E3|40|98|95|E3|40|98|95|E3|40|98|95|E3|40|
|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|
|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|
|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|
|ºººººººººººººººº
}}
{{HexRow|0x090|
|ED|E7|14|41|D4|2E|9E|41|8F|FB|CC|41|8D|87|CF|41|
|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|B0|
|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|C3|
|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|D4|
|ºººººººººººººººº
}}
{{HexRow|0x0A0|
|8D|87|CF|41|05|00|00|00|00|00|00|BF|1E|85|6B|BF|
|B0|B0|B0|B0|E7|E7|FF|FF|64|64|64|64|64|64|64|64|
|C3|C3|C3|C3|CE|CE|DD|DD|AA|AA|AA|AA|AA|AA|AA|AA|
|D4|D4|D4|D4|A5|A5|DD|DD|AA|AA|AA|AA|AA|AA|AA|AA|
|ºººººººººººººººº
}}
{{HexRow|0x0B0|
|19|47|0C|41|EB|51|F0|40|D7|A3|14|41|0A|D7|3B|41|
|64|64|64|64|64|64|64|64|64|64|64|64|64|64|64|64|
|AA|AA|AA|AA|AA|AA|AA|AA|AA|AA|AA|AA|AA|AA|AA|AA|
|AA|AA|AA|AA|AA|AA|AA|AA|AA|AA|AA|AA|AA|AA|AA|AA|
|ºººººººººººººººº
}}
{{HexRow|0x0C0|
|5E|93|BF|40|2F|00|01|16|85|EB|51|BF|E1|7A|7C|C1|
|64|64|64|64|EB|EB|8C|FF|F0|F0|F0|F0|F0|F0|F0|F0|
|AA|AA|AA|AA|EB|EB|8C|00|F0|F0|F0|F0|F0|F0|F0|F0|
|AA|AA|AA|AA|EB|EB|CC|C8|96|96|96|96|96|96|96|96|
|ºººººººººººººººº
}}
{{HexRow|0x0D0|
|69|61|BF|40|70|3D|22|41|47|E1|3A|40|33|33|DB|40|
|F0|F0|F0|F0|F0|F0|F0|F0|F0|F0|F0|F0|F0|F0|F0|F0|
|F0|F0|F0|F0|F0|F0|F0|F0|F0|F0|F0|F0|F0|F0|F0|F0|
|96|96|96|96|96|96|96|96|96|96|96|96|96|96|96|96|
|ºººººººººººººººº
}}
{{HexRow|0x0E0|
|F7|C0|2E|3E|00|00|00|00|18|00|00|00|60|F3|0F|00|
|F0|F0|F0|F0|00|00|00|00|00|00|00|00|C8|C8|C8|C8|
|F0|F0|F0|F0|C8|C8|C8|C8|C8|C8|C8|C8|00|00|00|00|
|96|96|96|96|64|64|64|64|FF|FF|FF|FF|40|40|40|40|
|ºººººººººººººººº
}}
{{HexRow|0x0F0|
|E0|F2|0F|00|00|00|00|00|A0|F2|0F|00|00|00|00|00|
|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|
|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|
|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|C8|
|ºººººººººººººººº
}}
{{HexRow|0x100|
|00|F3|0F|00|00|00|00|00|6B|6F|6E|66|6C|61|73|68|
|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|FF|
|FF|FF|FF|FF|FF|FF|FF|FF|CD|CD|CD|CD|CD|CD|CD|CD|
|C8|C8|C8|C8|C8|C8|C8|C8|96|96|96|96|96|96|96|96|
|ººººººººkonflash
}}
{{HexRow|0x110|
|31|00|AD|DE|AD|DE|AD|DE|00|00|00|00|00|00|00|00|
|FF|FF|FF|FF|FF|FF|FF|FF|C8|C8|C8|C8|C8|C8|C8|C8|
|CD|CD|CD|CD|CD|CD|CD|CD|FF|FF|FF|FF|FF|FF|FF|FF|
|96|96|96|96|96|96|96|96|FF|FF|FF|FF|FF|FF|FF|FF|
|1ººººººººººººººº
}}
{{HexRow|0x120|
|00|00|00|00|00|00|00|00|00|00|00|00|00|00|12|00|
|FF|FF|FF|FF|00|00|00|00|FF|FF|FF|FF|C8|C8|C8|C8|
|C8|C8|C8|C8|96|96|96|96|80|80|80|80|C8|C8|C8|C8|
|00|00|00|00|C8|C8|C8|C8|C0|C0|C0|C0|64|64|64|64|
|ºººººººººººººººº
}}
{{HexRow|0x130|
|FF|FF|0A|00|06|00|02|00|01|04|01|1C|AD|DE|AD|DE|
|80|80|80|80|C8|C8|80|80|FF|00|FF|FF|CA|CA|CA|CA|
|40|40|40|40|7C|7C|80|80|AA|D9|22|22|CA|CA|CA|CA|
|40|40|40|40|64|64|80|80|82|00|FF|FF|FF|FF|FF|FF|
|ºººººººººººººººº
}}
|}

{{Table}}
{{OBDth}}
{{OBDtr| 0x000 | res_id |FF0000| 01 49 07 00 | 1532 | 01865-KONCOMpunch_heavy.TREX }}
{{OBDtr| 0x004 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtrBK|Extent info}}
{{OBDtr| 0x008 | float |B0C3D4| 8D 87 CF 41 | 25.941187 | max horizontal extent of the attack }}
{{OBDtr| 0x00C | float |B0C3D4| DE E9 1A 40 | 2.420524 | min Y of the attack }}
{{OBDtr| 0x010 | float |B0C3D4| 95 34 D3 41 | 26.400675 | max Y of the attack }}
{{OBDtr| 0x014 | float |B0C3D4| 8D 87 CF 41 | 25.941187 | max horizontal extent at 0° (front) }}
{{OBDtr| ... | ... |B0C3D4| ... | ... | ... }}
{{OBDtr| 0x0A0 | float |B0C3D4| 8D 87 CF 41 | 25.941187 | max horizontal extent at 350° }}
{{OBDtrBK|First extent info - information about the first extent in the extent part}}
{{OBDtr| 0x0A4 | int16 |E7CEA5| 05 00 | 5 | frame; -1 if the attack part does not exist }}
{{OBDtr| 0x0A6 | int8 |FFDDDD| 00 | 0 | attack index; always 0 }}
{{OBDtr| 0x0A7 | int8 |FFDDDD| 00 | 0 | attack frame offset; always 0 }}
{{OBDtr| 0x0A8 | float |64AAAA| 00 00 00 BF | -0.500000 | x location of the pelvis }}
{{OBDtr| 0x0AC | float |64AAAA| 1E 85 6B BF | -0.920000 | z location of the pelvis }}
{{OBDtr| 0x0B0 | float |64AAAA| 19 47 0C 41 | 8.767358 | y location of the pelvis }}
{{OBDtr| 0x0B4 | float |64AAAA| EB 51 F0 40 | 7.510000 | extent length }}
{{OBDtr| 0x0B8 | float |64AAAA| D7 A3 14 41 | 9.290000 | extent min Y }}
{{OBDtr| 0x0BC | float |64AAAA| 0A D7 3B 41 | 11.740000 | extent max Y }}
{{OBDtr| 0x0C0 | float |64AAAA| 5E 93 BF 40 | 5.986739 | extent angle (in radians) }}
{{OBDtrBK|Farthest extent info - information about the farthest reaching extent in the extent part }}
{{OBDtr| 0x0C4 | int16 |EBEBEB| 2F 00 | 47 | frame; -1 if there is no attack part of if the animation is for a throw target/victim ("_tgt") }}
{{OBDtr| 0x0C6 | int8 |8C8CCC| 01 | 1 | attack index to which the max extent belongs }}
{{OBDtr| 0x0C7 | int8 |FF00C8| 16 | 22 | attack frame offset from the attack with index 0 }}
{{OBDtr| 0x0C8 | float |F0F096| 85 EB 51 BF | -1.850000 | x location of the pelvis }}
{{OBDtr| 0x0CC | float |F0F096| E1 7A 7C C1 | -3.900000 | z location of the pelvis }}
{{OBDtr| 0x0D0 | float |F0F096| 69 61 BF 40 | 16.874636 | y location of the pelvis }}
{{OBDtr| 0x0D4 | float |F0F096| 70 3D 22 41 | 10.510000 | extent length }}
{{OBDtr| 0x0D8 | float |F0F096| 47 E1 3A 40 | 8.860000 | extent min Y }}
{{OBDtr| 0x0DC | float |F0F096| 33 33 DB 40 | 18.460000 | extent max Y }}
{{OBDtr| 0x0E0 | float |F0F096| F7 C0 2E 3E | 0.055320 | extent angle }}
{{OBDtrBK|End max extent info }}
{{OBDtr| 0x0E4 | int32 |00C864| 00 00 00 00 | 0 | alternative move direction; used only when the previous move direction field is 0, that means never }}
{{OBDtr| 0x0E8 | int32 |00C8FF| 18 00 00 00 | 24 | number of elements in the extent part }}
{{OBDtr| 0x0EC | offset |C80040| 60 F3 0F 00 | 0x000FF360 | raw file offset of the [[OBD:TRAM/raw0x13C|extent part]] }}
{{OBDtrBK|End extent info}}
{{OBDtr| 0x0F0 | offset |FFFFC8| E0 F2 0F 00 | 0x000FF2E0 | raw file offset of the [[OBD:TRAM/raw0x1C|motion blur part]] }}
{{OBDtr| 0x0F4 | offset |FFFFC8| 00 00 00 00 | unused | raw file offset of the [[OBD:TRAM/raw0x24|throw data]] }}
{{OBDtr| 0x0F8 | offset |FFFFC8| A0 F2 0F 00 | 0x000FF2A0 | raw file offset of the [[OBD:TRAM/raw0x14|attack part]] }}
{{OBDtr| 0x0FC | offset |FFFFC8| 00 00 00 00 | unused | raw file offset of the [[OBD:TRAM/raw0x18|damage part]] (used only by "_tgt" animations (throw targets/victims) }}
{{OBDtr| 0x100 | offset |FFFFC8| 00 F3 0F 00 | 0x000F0F00 | raw file offset of the [[OBD:TRAM/raw0x2C|particle data]] (trails, dust, etc.) }}
{{OBDtr| 0x104 | offset |FFFFC8| 00 00 00 00 | unused | raw file offset of the [[OBD:TRAM/raw0x38|sound data]] }}
{{OBDtr2|0x108 | char[16] |FFCD96| konflash1 | impact particle name (reference to 01018-.[[OBD:ONIA|ONIA]], which is called up in the [[OBD:ONCC|ONCC]] file) }}
{{OBDtr| 0x118 | link |C8FFFF| 00 00 00 00 | unused | direct animation 0 (link to a TRAM file) }}
{{OBDtr| 0x11C | link |C8FFFF| 00 00 00 00 | unused | direct animation 1 (link to a TRAM file) }}
{{OBDtr| 0x120 | float |FFC800| 00 00 00 00 | 0.000000 | final rotation in radians (for anims that make you turn) }}
{{OBDtr| 0x124 | int32 |0096C8| 00 00 00 00 | 0 | number of elements in the sound part }}
{{OBDtr| 0x128 | int32 |FF80C0| 00 00 00 00 | 0 | unknown; runtime pointer to the sound? }}
{{OBDtr| 0x12C | uint16 |C8C864| 00 00 | 0 | hard pause in game ticks (1/60 seconds) }}
{{OBDtr| 0x12E | uint16 |C8C864| 12 00 | 18 | soft pause in game ticks (1/60 seconds) }}
{{OBDtr| 0x130 | uint16 |804040| FF FF | 65535 | action frame }}
{{OBDtr| 0x132 | uint16 |804040| 0A 00 | 10 | first level where the animation is available }}
{{OBDtr| 0x134 | uint16 |C87C64| 06 00 | 6 <nowiki>=</nowiki> superpunch | vocalization type (-1 if unused) }}
{{OBDtr| 0x136 | uint8 |808080| 02 | 2 | number of elements in the attack part }}
{{OBDtr| 0x137 | uint8 |808080| 00 | 0 | number of elements in the take damage part }}
{{OBDtr| 0x138 | uint8 |FFAA82| 01 | 1 | number of elements in the motion blur part }}
{{OBDtr| 0x139 | uint8 |00D900| 04 | 4 | number of elements in the particle part }}
{{OBDtr| 0x13A | uint8 |FF22FF| 01 | 1 | first "invulnerable" frame }}
{{OBDtr| 0x13B | uint8 |FF22FF| 1C | 28 | last "invulnerable" frame }}
{{OBDtr| 0x13C | char[4] |CACAFF| AD DE | dead | unused (not part of the template) }}
|}
At the time of writing, some of the above data is merely an informed guess (not thoroughly confirmed), and the nature of 0x128 (int32?) needs to be clarified more particularly. We also need to locate "end/maximal interpolation" and possibly other remaining fields from the PC data format, or establish that they are missing from the TRAM/TREX representation of animations on PS2.

{{OBD_File_Footer | type=TRAM | prev=TRAC | next=TRAS | name=Totoro Animation Sequence | family=Character}}

{{OBD}}

MediaWiki:Unusedimagestext-categorizedimgisused

2026-04-16T18:36:20Z

Iritscen: rewrite for clarity; added link to message page

While this page would normally list "unused" images, if $wgCountCategorizedImagesAsUsed is set to true (as it is for our wiki) then categorized images are considered to be used even if they are not referenced from any page. Because we categorize all of our uploaded images, this page should be empty.

Click [[MediaWiki:Unusedimagestext-categorizedimgisused|here]] to edit this message.

OBD:TXMP

2026-04-16T18:29:45Z

Iritscen: removed one last reference to wrong row order

{{OBD_File_Header | type=TXMP | prev=TXMB | next=TxtC | name=Texture Map | family=General | align=center}}

TXMP is the only known instance type that is interpreted differently by the three kinds of Oni engines on the three platforms (Windows, Mac and PS2).

The difference between the format used in v1.0 of the engine (Windows retail) and v1.1 (Windows demo, Mac, [[OniX]]) is minor, at least from the point of view of disk storage (the structural difference is limited to runtime fields grouped at the end of the instance, which is why they haven't been documented or implemented in OniSplit). A more obvious difference is that v1.0 TXMPs store their pixel data in the .raw file and v1.1 TXMPs use the .sep file, but as far as the .dat is concerned this merely amounts to using a different data pointer field within the TXMP structure. Thus, even though the template checksums for v1.0 and v1.1 are different, both formats can easily be described together.

The PS2 implementation is significantly different from the other two, in that it systematically uses indexed colors: instead of color being stored in the pixel data itself, each pixel is merely an index into a custom 256-color palette. This format is detailed under {{SectionLink||PS2 implementation}}.

==Windows/Mac implementation==
[[Image:txmp_all.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x00 | res_id |FF0000| 01 1F 00 00 | 31 | 00031-rl_1.TXMP }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr2|0x08 | char[128]|FFC8C8| rl_1 | name of the texture; unused }}
{{OBDtr| 0x88 | int32 |FFFFC8| 00 10 00 00 | 0x1000 | options; possible option flags (from left to right):
:0x01 - has mipmaps
:0x04 - U wrapping disabled
:0x08 - V wrapping disabled
:0x10 - ignored
:0x40 - animation order: play back to back (frames 0 to n then n-1 to 0)
:0x80 - animation order: play in random order
:0x100 - animation time: add local (particle) time (see below)
:0x200 - has environment map texture
:0x400 - additive alpha blending
:0x1000 - little-endian data
:0x4000 - animation time: ignore game time (see below)
:0x8000 - effect: blue shield
:0x10000 - effect: invisibility
:0x20000 - effect: Daodan shield}}
{{OBDtr| 0x8C | int16 |C8FFC8| 80 00 | 128 | width of the image in pixels }}
{{OBDtr| 0x8E | int16 |C8FFC8| 80 00 | 128 | height of the image in pixels }}
{{OBDtr| 0x90 | int32 |C8FFFF| 09 00 00 00 | 9 | texture format; see below for list of available formats.
:0 - ARGB4444, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Four 4-bit channels, with bitmasks 0x000F (Blue), 0x00F0 (Green), 0x0F00 (Red) and 0xF000 (Alpha).
:1 - RGB555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels, with bitmasks 0x001F (Blue), 0x03E0 (Green) and 0x7C00 (Red).
:::N.B. The high bit (0x8000) is unused, but the convention is to always set it to 1.
:2 - ARGB1555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels with bitmasks 0x001F (Blue), 0x03E0 (Green) and 0x7C00 (Red), 1-bit alpha (0x8000).
:3 (never used in vanilla TXMPs)<ref>[[TSFT]] implicitly uses I8 for storing its glyphs in the PC versions, at least in most languages (the Chinese version has its own font storage system), but TSFT doesn't use TXMP to store its pixel data so it doesn't count as a use of this TXMP format type.</ref> - I8, 8 bits/pixel, stored as a single byte. Monochrome "intensity" (256 levels of gray).
:4 (never used in vanilla TXMPs) - I1, 8 ''pixels/byte''. Monochrome "intensity" (black-or-white).
:5 (never used in vanilla TXMPs) - A8, 8 bits/pixel, stored as a single byte. Standalone alpha (256 levels of opacity).
:6 (never used in vanilla TXMPs) - A4I4, 8 bits/pixel, stored as a single byte. Intensity (bit mask 0x0F), alpha (0xF0).
:7 (never used in vanilla TXMPs<ref>Storage format 7 was jointly used by OniSplit, Daodan DLL and the Intel Mac build to allow for 32-bit textures with transparency - most importantly experimental lightmaps, see [[Lightmapping levels|HERE]]. However, the actual storage format used in this case was RGBA_Bytes (type 11), and type 7 was used by mistake.</ref>) - ARGB8888, 32 bits/pixel (stored as a little-endian int32, swaps to big-endian at runtime on a PowerPC Mac)
::Four 8-bit channels, with bitmasks 0x000000FF (Blue), 0x0000FF00 (Green), 0x00FF0000 (Red) and 0xFF000000 (Alpha).
:8 - RGB888, 32 bits/pixel (stored as a little-endian int32, swaps to big-endian at runtime on Mac)
::Three 8-bit channels, with bitmasks 0x000000FF (Blue), 0x0000FF00 (Green) and 0x00FF0000 (Red).
:::N.B. The high byte (0xFF000000) is unused, but the convention is to always set it to 0x00.
:9 - S3TC/DXT1, RGB565 compressed 4 times ([https://wikis.khronos.org/opengl/S3_Texture_Compression GL_COMPRESSED_RGB_S3TC_DXT1_EXT] OpenGL texture format)
:10 (never used in vanilla TXMPs) - RGB_Bytes, 24 bits/pixel, stored as 3 consecutive bytes: first Red, then Green, then Blue.
::N.B. Unlike for RGB888 (type 8), the storage is compact, with no unused alpha bit.
:11 (never used in vanilla TXMPs<ref>Storage format 11 (RGBA_Bytes) was effectively implemented by OniSplit to allow for 32-bit textures with transparency - most importantly experimental lightmaps, see [[Lightmapping levels|HERE]]. However, it was mislabeled as type 7 (ARGB8888) by OniSplit, Daodan DLL and the Intel Mac build, which resulted in byte swapping and the requirement of authoring Windows and Mac versions of TXMPs.</ref>) - RGBA_Bytes, 32 bits/pixel, stored as 4 consecutive bytes: first Red, then Green, then Blue, then Alpha.
:12 (never used in vanilla TXMPs) - RGBA5551, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels with bitmasks 0x003E (Blue), 0x07C0 (Green) and 0xF800 (Red), 1-bit alpha (0x0001).
:13 (never used in vanilla TXMPs) - RGBA4444, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Four 4-bit channels, with bitmasks 0x00F0 (Blue), 0x0F00 (Green), 0xF000 (Red) and 0x000F (Alpha).
:14 (never used in vanilla TXMPs) - RGB565, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Two 5-bit channels with bitmasks 0x001F (Blue) and 0xF800 (Red), 6-bit Green channel (0x07E0).
:15 (never used in vanilla TXMPs) - ABGR1555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels with bitmasks 0x001F (Red), 0x03E0 (Green) and 0x7C00 (Blue), 1-bit alpha (0x8000).
}}
{{OBDtr| 0x94 | link |FFC8FF| 00 00 00 00 | unused | link to a [[OBD:TXAN|TXAN]] file; used if this texture is animated }}
{{OBDtr| 0x98 | link |FFC800| 00 00 00 00 | unused | link to a TXMP file that contain the environment map }}
{{OBDtr| 0x9C | offset |C800C8| 20 00 00 00 |00 00 00 20| offset of pixel data in the raw file (v1.0 engine only) }}
{{OBDtr| 0xA0 | offset |C87C64| 00 00 00 00 | unused | offset of pixel data in the separate file (v1.1 engine only) }}
{{OBDtr| 0xA4 | char[12] |B0C3D4| AD DE | dead | The layout of these 12 bytes is different for the v1.0 and v1.1 versions (i.e. Windows retail vs. Windows demo and Mac):
*For a v1.1 TXMP, the four bytes at 0xA4-A7 are "00 00 00 00" instead of "AD DE AD DE", and correspond to a "material type" attributed at runtime (from [[TMBD]]), which is then used for impact/breakability lookup. The Windows retail TXMPs apparently have no such "material type" field.
*The fields at 0xA8-AF (for v1.1) or 0xA4-AB (for v1.0) are used only at runtime (and somehow obfuscated by "0xDEAD" when written to disk). Judging by the Windows demo and Mac engine, we can assume they are the same in both engines, and serve for rendering optimization (there is a texture name pointer, a "dirty" flag stored as a byte and 3 extra bytes used as flags).
*For Windows retail, the four bytes at 0xAC-AF are completely unused (not part of the template).
Since runtime fields are grouped at the end, v1.0 and v1.1 TXMPs are treated by OniSplit under the same template, merely switching between the .raw and .sep links and blanking out everything past 0xA4.
}}
{{OBDtr| 0xB0 | char[16] |B0C3D4| AD DE | dead | padding bytes (not part of TXMP) }}
|}

===Effect options===
The "blue shield", "invisibility" and "Daodan shield" options tell the engine to vary the texture's Gouraud shading with certain preset colors that vary with time.

{| class="wikitable"
!Flag name
!Texture with flag
!Used for
|-
|"blue shield"
|TXMPSHIELD
|force shield
|-
|"invisibility"
|TXMPINVIS
|phase cloak
|-
|"Daodan shield"
|TXMPDAODAN_SHIELD
|red boss shield and [[supershield]]
|}

In the vanilla game data, these flags are only used by the above-named textures. The engine also calls upon these textures by hardcoded name in order to create a character's shield or phase cloak effect.

===Animation time===
When using animated textures the image to display is selected using the game time and animation speed. For textures that are used by particles the local (particle) time can be used either to replace or offset the game time.

===Pixel byte storage order===
As noted above under each format description, the bytes of multibyte texture formats are generally stored "backwards" compared to their names, so if a format is named "RGBA"-something then its bytes will be in ABGR order on disk. This convention was established in the Windows world where PCs were little-endian and loading the bytes AA BB GG RR into a 32-bit int in memory would place them in the correct order, 0xRRGGBBAA. Macintoshes, being big-endian at the time, expected the data to be stored in reverse order and thus Oni would perform a byte swap on most of these types when it loaded them into memory to ensure that they ended up as 0xRRGGBBAA in memory. The sole exceptions to this little-endian storage rule among Oni's supported texture formats are RGB_Bytes and RGBA_Bytes, which actually store their bytes in the stated order, RGB and RGBA respectively. However these formats were never used by any textures in Oni.

===Pixel scanline storage order===
Pixels are stored in row-major order, meaning that the pixels are stored in rows and then columns, as opposed to the other way around. These rows are stored in ''top-to-bottom'' order, contrary to what was documented on this wiki for a long time. In the case of the DXT1 storage format, the row-major, left-to-right, top-to-bottom order applies to the 4x4 blocks composing the image, and also inside each 4x4 block for the storage of 2-bit pixels. In the case of the I1 format (multiple pixels per byte), the row-major, left-to-right, top-to-bottom order applies to the 1-bit pixels composing the image.

==PS2 implementation==
The PS2 TXMP layout is similar to PC, with notable differences in the last few bytes due to Rockstar moving to a PS2-standard 32-bit indexed color ("CLUT") system for optimization purposes. Here are the high-level differences:
*There are 4 extra bytes of storage as compared to a v1.1 TXMP (which is already 4 bytes larger than a v1.0 TXMP).
*The extra 4 bytes come from a palette index (int32) inserted at 0x90 before the pixel format (which is pushed down to 0x94 along with everything else that follows).
*Two new pixel formats were added, and are the only formats used on PS2: type 16 for opaque textures (indexed 32-bit RGB with ignored alpha byte), and type 17 for transparent textures (indexed 32-bit RGBA).
*The pixel data (color indices) can be stored either in the .raw file (pointer field at 0xA0) or in the .sep file (pointer at 0xA4).

Here is how the end of TXMPrl_1 looks in level3_Final.dat of the English retail PS2 version.
{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x90 | int32 |C8FFC8| 56 00 00 00 | 86 | index of the 256-color palette used by this texture (starts at 0x15800 in level3_palette.pal) }}
{{OBDtr| 0x94 | int32 |C8FFFF| 10 00 00 00 | 16 | pixel format 16 (indexed 32-bit RGB with inactive alpha) }}
{{OBDtr| 0x98 | link |FFC8FF| 00 00 00 00 | 0 | link to a [[OBD:TXAN|TXAN]] file; used if this texture is animated }}
{{OBDtr| 0x9C | link |FFC800| 00 00 00 00 | 0 | link to a TXMP file that contains the environment map }}
{{OBDtr| 0xA0 | offset |C800C8| C0 05 00 00 |00 00 05 C0| offset of pixel data in the .raw file }}
{{OBDtr| 0xA4 | offset |C87C64| 00 00 00 00 | 0 | offset of pixel data in the .sep file }}
{{OBDtr| 0xA8 | int32 |B0C3D4| 00 00 00 00 | 0 | always 0; presumably the same "material type" (set at runtime) as for Windows demo and Mac }}
{{OBDtr| 0xAC | char[4] |B0C3D4| AD DE AD DE | dead | presumably the same texture name pointer (set at runtime) as for Windows demo and Mac }}
{{OBDtr| 0xB0 | char[4] |B0C3D4| AD DE AD DE | dead | presumably the same rendering optimization flags (runtime) as for Windows demo and Mac }}
{{OBDtr| 0xB4 | char[12] |B0C3D4| AD DE | dead | completely unused bytes (not part of the template) }}
|}

===Palette file format===
*Palettes are stored per-level in level#_palette.pal files in a pal/ subdirectory of GameDataFolder, corresponding to how .raw and .sep files are stored in raw/ and sep/ subdirectories.
*Each level#_palette.pal file contains between 85 and 179 palettes, not counting the first palette (index 0) at the start of each .pal file which is always blank.

===Palette format===
*Valid palette indices start at 1 because of palette 0 always being empty.
*Each color in a palette entry is 4 bytes, stored on disk in RGBA order (byte 0 = red, byte 1 = green, byte 2 = blue, byte 3 = alpha). This is the same layout as RGB_Bytes (type 10) and RGBA_Bytes (type 11), not the reversed BGRA order used by most of the other texture formats.
*Each palette consists of 256 32-bit color slots and thus takes up 1024 bytes. If a palette does not use all 256 entries then the palette is closed out with a series of {0x00, 0x00, 0x00, 0x80} entries.
*Each pixel in the .raw or .sep data is stored as a 1-byte index into the image's chosen color palette.

===Palette CLUT swizzle===
:The PS2 Graphics Synthesizer (GS) stores CLUT entries in a scrambled order due to its hardware cache line layout. Within every 32-entry block of the palette, entries 8–15 and 16–23 are swapped relative to their logical positions. Software reading the palette must undo this before using it as a palette index.

===Ignored alpha byte for type 16===
:The fourth byte would represent alpha, but in RGB888 it is merely a padding byte, always set to 0x80.

===Alpha scaling for type 17===
:The PS2 GS uses a half-range alpha where 0x00 = fully transparent and 0x80 = fully opaque (values above 0x80 are technically possible but indicate "source alpha contribution > 1" in GS blending, which doesn't arise in Oni).

===Alternating use of .raw or .sep storage===
Unlike the Win/Mac game data (where pixel data is stored exclusively in .raw or exclusively in .sep for all TXMPs), PS2 TXMPs use .raw and .sep storage alternatingly, depending on the TXMP. The engine apparently uses the .sep pointer if there is no .raw pointer (or vice versa).

Examples of textures using .sep storage are: all [[:Category:Fly-in_portraits|fly-in portraits]]; all [[:Category:Splashscreens|splashscreen]] components; some illustrations in Konoko's [[Data Comlink]] (namely, [[:File:TXMPLevel02move.png|combat move illustrations]] and [[:File:TXMPhypo.png|item illustrations]]; objectives and weapon illustrations use .raw storage).

Environment/character/particle TXMPs seem to be using .raw storage consistently (not checked beyond level1_Final). As a notable anomaly, .sep storage is used for the following three textures (console screens) in level0_Final: _CON_SAVEGAME (main TXMP only; the animation frames use .raw storage), _CON_SAVEGAME_USED, _CON_USED.

==Oni's internal storage types==
Some of Oni's 18 types of image storage are elaborated on below in order to illustrate exactly how they work. The "Mem view" column shows the bytes in big-endian format and the "Disk view" column shows the bytes as they are actually stored in little-endian order. For example, bytes in memory shown as 0xFC00 are stored as "00 FC" on disk.

===ARGB4444 (type 0)===
*A 16-bit field is used to store 4 color channels (4 bits each, values from 0 to 15).
*Bit masks are 0x000F for Blue, 0x00F0 for Green, 0x0F00 for Red, 0xF000 for Alpha.
*Stored as big-endian in TXMP (first the AAAARRRR byte, then the GGGGBBBB byte).
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 1 (high) <code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>A A A A R R R R</code>||<code>G G G G B B B B</code>
|-
!colspan=3| Bit values for primary colors (fully opaque)
!Mem view
!Disk view
|-
|Black||<code>1 1 1 1 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!F0 00!!00 F0
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF!!FF FF
|-
|Red||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!FF 00!!00 FF
|-
|Green||<code>1 1 1 1 0 0 0 0</code>||<code>1 1 1 1 0 0 0 0</code>
!F0 F0!!F0 F0
|-
|Blue||<code>1 1 1 1 0 0 0 0</code>||<code>0 0 0 0 1 1 1 1</code>
!F0 0F!!0F F0
|-
|Cyan||<code>1 1 1 1 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!F0 FF!!FF F0
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 1 1 1 1</code>
!FF 0F!!0F FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 0 0 0 0</code>
!FF F0!!F0 FF
|}

===RGB555 (type 1)===
*A 16-bit field is used to store 3 color channels (5 bits each, values from 0 to 31).
*Bit masks are 0x001F for Blue, 0x03E0 for Green, 0x7C00 for Red.
*The high bit (0x8000) is unused, but is always set to 1 by convention.
*Stored in little-endian order in TXMP.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 1 (high) <code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>X R R R R R G G</code>||<code>G G G B B B B B</code>
|-
!colspan=3| Bit values for primary colors
!Mem view
!Disk view
|-
|Black||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!80 00!!00 80
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF!!FF FF
|-
|Red||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FC 00!!00 FC
|-
|Green||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!83 E0!!E0 83
|-
|Blue||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!80 1F!!1F 80
|-
|Cyan||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!83 FF!!FF 83
|-
|Magenta||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!FC 1F!!1F FC
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!FF E0!!E0 FF
|}

===ARGB1555 (type 2)===
*A 16-bit field is used to store 3 color channels (5 bits each, values from 0 to 31) and one 1-bit channel.
*Bit masks are 0x001F for Blue, 0x03E0 for Green, 0x7C00 for Red, and 0x8000 for Alpha.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 1 (high) <code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>A R R R R R G G</code>||<code>G G G B B B B B</code>
|-
!colspan=3| Bit values for primary colors (opaque)
!Mem view
!Disk view
|-
|Black||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!80 00!!00 80
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF!!FF FF
|-
|Red||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FC 00!!00 FC
|-
|Green||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!83 E0!!E0 83
|-
|Blue||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!80 1F!!1F 80
|-
|Cyan||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!83 FF!!FF 83
|-
|Magenta||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!FC 1F!!1F FC
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!FF E0!!E0 FF
|}

===A4I4 (type 6)===
*An 8-bit field is used to store an intensity and an alpha (4 bits each, values from 0 to 15).
*Bit masks are 0x0F for Intensity, 0xF0 for Alpha.
*Endianness is irrelevant for single-byte storage.
{|border=1 cellpadding=3 cellspacing=0
!Bits
!<code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>A A A A I I I I</code>
|-
!colspan=2|Examples of bit values
!Mem view
|-
|Black, opaque||<code>1 1 1 1 0 0 0 0</code>
!F0
|-
|White, opaque||<code>1 1 1 1 1 1 1 1</code>
!FF
|-
|Black, transparent||<code>0 0 0 0 0 0 0 0</code>
!00
|-
|White, transparent||<code>0 0 0 0 1 1 1 1</code>
!0F
|}

===ARGB8888 (type 7)===
*A 32-bit field is used to store 4 color channels (8 bits each, values from 0 to 255).
*Bit masks are 0x000000FF for Blue, 0x0000FF00 for Green, 0x00FF0000 for Red, 0xFF000000 for Alpha.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 3 (highest) <code>7 6 5 4 3 2 1 0</code>
!Byte 2 (higher) <code>7 6 5 4 3 2 1 0</code>
!Byte 1 (high) <code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>A A A A A A A A</code>||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>
|-
!colspan=5| Bit values for primary colors (fully opaque)
!Mem view
!Disk view
|-
|Black||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FF 00 00 00!!00 00 00 FF
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF FF FF!!FF FF FF FF
|-
|Red||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FF FF 00 00!!00 00 FF FF
|-
|Green||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!FF 00 FF 00!!00 FF 00 FF
|-
|Blue||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 00 FF!!FF 00 00 FF
|-
|Cyan||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 FF FF!!FF FF 00 FF
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF 00 FF!!FF 00 FF FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!FF FF FF 00!!00 FF FF FF
|}

===RGB888 (type 8)===
*A 32-bit field is used to store 3 color channels (8 bits each, values from 0 to 255).
*Bit masks are 0x000000FF for Blue, 0x0000FF00 for Green, 0x00FF0000 for Red.
*The high byte (0xFF000000) is unused, but is always set to 00 by convention.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 3 (highest) <code>7 6 5 4 3 2 1 0</code>
!Byte 2 (higher) <code>7 6 5 4 3 2 1 0</code>
!Byte 1 (high) <code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>X X X X X X X X</code>||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>
|-
!colspan=5| Bit values for primary colors
!Mem view
!Disk view
|-
|Black||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!00 00 00 00!!00 00 00 00
|-
|White||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF FF FF!!FF FF FF 00
|-
|Red||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!00 FF 00 00!!00 00 FF 00
|-
|Green||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!00 00 FF 00!!00 FF 00 00
|-
|Blue||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 00 FF!!FF 00 00 00
|-
|Cyan||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 FF FF!!FF FF 00 00
|-
|Magenta||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF 00 FF!!FF 00 FF 00
|-
|Yellow||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!00 FF FF 00!!00 FF FF 00
|}

===RGB_Bytes (type 10)===
*Three consecutive 8-bit fields are used to store 3 color channels (8 bits each, values from 0 to 255).
*Each channel has its own byte, and there is no "unused" byte (the bytes are packed 3 by 3).
*Endianness is irrelevant when storing as a sequence of bytes.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 0 (red) <code>7 6 5 4 3 2 1 0</code>
!Byte 1 (green) <code>7 6 5 4 3 2 1 0</code>
!Byte 2 (blue) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>
|-
!colspan=4|Bit values for primary colors
!Mem view
|-
|Black||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!00 00 00
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF FF
|-
|Red||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FF 00 00
|-
|Green||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!00 FF 00
|-
|Blue||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 FF
|-
|Cyan||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF FF
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!FF FF 00
|}

===RGBA_Bytes (type 11)===
*Four consecutive 8-bit fields are used to store 4 color channels (8 bits each, values from 0 to 255).
*Each channel has its own byte. Endianness is irrelevant when storing as a sequence of bytes.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 0 (red) <code>7 6 5 4 3 2 1 0</code>
!Byte 1 (green) <code>7 6 5 4 3 2 1 0</code>
!Byte 2 (blue) <code>7 6 5 4 3 2 1 0</code>
!Byte 3 (alpha) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>||<code>A A A A A A A A</code>
|-
!colspan=5| Bit values for primary colors (fully opaque)
!Mem view
|-
|Black||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 00 FF
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF FF FF
|-
|Red||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 00 FF
|-
|Green||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF 00 FF
|-
|Blue||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 FF FF
|-
|Cyan||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF FF FF
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 FF FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF 00 FF
|}

==Notes==
<references/>

{{OBD_File_Footer | type=TXMP | prev=TXMB | next=TxtC | name=Texture Map | family=General}}

{{OBD}}

OBD:TXMP

2026-04-16T18:27:53Z

Iritscen: how is it possible that the wiki was wrong about this major fact, accompanied by a wrong illustration, for twenty years? I don't know, but I'm fixing it now

{{OBD_File_Header | type=TXMP | prev=TXMB | next=TxtC | name=Texture Map | family=General | align=center}}

TXMP is the only known instance type that is interpreted differently by the three kinds of Oni engines on the three platforms (Windows, Mac and PS2).

The difference between the format used in v1.0 of the engine (Windows retail) and v1.1 (Windows demo, Mac, [[OniX]]) is minor, at least from the point of view of disk storage (the structural difference is limited to runtime fields grouped at the end of the instance, which is why they haven't been documented or implemented in OniSplit). A more obvious difference is that v1.0 TXMPs store their pixel data in the .raw file and v1.1 TXMPs use the .sep file, but as far as the .dat is concerned this merely amounts to using a different data pointer field within the TXMP structure. Thus, even though the template checksums for v1.0 and v1.1 are different, both formats can easily be described together.

The PS2 implementation is significantly different from the other two, in that it systematically uses indexed colors: instead of color being stored in the pixel data itself, each pixel is merely an index into a custom 256-color palette. This format is detailed under {{SectionLink||PS2 implementation}}.

==Windows/Mac implementation==
[[Image:txmp_all.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x00 | res_id |FF0000| 01 1F 00 00 | 31 | 00031-rl_1.TXMP }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr2|0x08 | char[128]|FFC8C8| rl_1 | name of the texture; unused }}
{{OBDtr| 0x88 | int32 |FFFFC8| 00 10 00 00 | 0x1000 | options; possible option flags (from left to right):
:0x01 - has mipmaps
:0x04 - U wrapping disabled
:0x08 - V wrapping disabled
:0x10 - ignored
:0x40 - animation order: play back to back (frames 0 to n then n-1 to 0)
:0x80 - animation order: play in random order
:0x100 - animation time: add local (particle) time (see below)
:0x200 - has environment map texture
:0x400 - additive alpha blending
:0x1000 - little-endian data
:0x4000 - animation time: ignore game time (see below)
:0x8000 - effect: blue shield
:0x10000 - effect: invisibility
:0x20000 - effect: Daodan shield}}
{{OBDtr| 0x8C | int16 |C8FFC8| 80 00 | 128 | width of the image in pixels }}
{{OBDtr| 0x8E | int16 |C8FFC8| 80 00 | 128 | height of the image in pixels }}
{{OBDtr| 0x90 | int32 |C8FFFF| 09 00 00 00 | 9 | texture format; see below for list of available formats.
:0 - ARGB4444, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Four 4-bit channels, with bitmasks 0x000F (Blue), 0x00F0 (Green), 0x0F00 (Red) and 0xF000 (Alpha).
:1 - RGB555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels, with bitmasks 0x001F (Blue), 0x03E0 (Green) and 0x7C00 (Red).
:::N.B. The high bit (0x8000) is unused, but the convention is to always set it to 1.
:2 - ARGB1555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels with bitmasks 0x001F (Blue), 0x03E0 (Green) and 0x7C00 (Red), 1-bit alpha (0x8000).
:3 (never used in vanilla TXMPs)<ref>[[TSFT]] implicitly uses I8 for storing its glyphs in the PC versions, at least in most languages (the Chinese version has its own font storage system), but TSFT doesn't use TXMP to store its pixel data so it doesn't count as a use of this TXMP format type.</ref> - I8, 8 bits/pixel, stored as a single byte. Monochrome "intensity" (256 levels of gray).
:4 (never used in vanilla TXMPs) - I1, 8 pixels/byte. Pixel rows, bottom to top. Monochrome "intensity" (black-or-white).
:5 (never used in vanilla TXMPs) - A8, 8 bits/pixel, stored as a single byte. Standalone alpha (256 levels of opacity).
:6 (never used in vanilla TXMPs) - A4I4, 8 bits/pixel, stored as a single byte. Intensity (bit mask 0x0F), alpha (0xF0).
:7 (never used in vanilla TXMPs<ref>Storage format 7 was jointly used by OniSplit, Daodan DLL and the Intel Mac build to allow for 32-bit textures with transparency - most importantly experimental lightmaps, see [[Lightmapping levels|HERE]]. However, the actual storage format used in this case was RGBA_Bytes (type 11), and type 7 was used by mistake.</ref>) - ARGB8888, 32 bits/pixel (stored as a little-endian int32, swaps to big-endian at runtime on a PowerPC Mac)
::Four 8-bit channels, with bitmasks 0x000000FF (Blue), 0x0000FF00 (Green), 0x00FF0000 (Red) and 0xFF000000 (Alpha).
:8 - RGB888, 32 bits/pixel (stored as a little-endian int32, swaps to big-endian at runtime on Mac)
::Three 8-bit channels, with bitmasks 0x000000FF (Blue), 0x0000FF00 (Green) and 0x00FF0000 (Red).
:::N.B. The high byte (0xFF000000) is unused, but the convention is to always set it to 0x00.
:9 - S3TC/DXT1, RGB565 compressed 4 times ([https://wikis.khronos.org/opengl/S3_Texture_Compression GL_COMPRESSED_RGB_S3TC_DXT1_EXT] OpenGL texture format)
:10 (never used in vanilla TXMPs) - RGB_Bytes, 24 bits/pixel, stored as 3 consecutive bytes: first Red, then Green, then Blue.
::N.B. Unlike for RGB888 (type 8), the storage is compact, with no unused alpha bit.
:11 (never used in vanilla TXMPs<ref>Storage format 11 (RGBA_Bytes) was effectively implemented by OniSplit to allow for 32-bit textures with transparency - most importantly experimental lightmaps, see [[Lightmapping levels|HERE]]. However, it was mislabeled as type 7 (ARGB8888) by OniSplit, Daodan DLL and the Intel Mac build, which resulted in byte swapping and the requirement of authoring Windows and Mac versions of TXMPs.</ref>) - RGBA_Bytes, 32 bits/pixel, stored as 4 consecutive bytes: first Red, then Green, then Blue, then Alpha.
:12 (never used in vanilla TXMPs) - RGBA5551, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels with bitmasks 0x003E (Blue), 0x07C0 (Green) and 0xF800 (Red), 1-bit alpha (0x0001).
:13 (never used in vanilla TXMPs) - RGBA4444, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Four 4-bit channels, with bitmasks 0x00F0 (Blue), 0x0F00 (Green), 0xF000 (Red) and 0x000F (Alpha).
:14 (never used in vanilla TXMPs) - RGB565, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Two 5-bit channels with bitmasks 0x001F (Blue) and 0xF800 (Red), 6-bit Green channel (0x07E0).
:15 (never used in vanilla TXMPs) - ABGR1555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels with bitmasks 0x001F (Red), 0x03E0 (Green) and 0x7C00 (Blue), 1-bit alpha (0x8000).
}}
{{OBDtr| 0x94 | link |FFC8FF| 00 00 00 00 | unused | link to a [[OBD:TXAN|TXAN]] file; used if this texture is animated }}
{{OBDtr| 0x98 | link |FFC800| 00 00 00 00 | unused | link to a TXMP file that contain the environment map }}
{{OBDtr| 0x9C | offset |C800C8| 20 00 00 00 |00 00 00 20| offset of pixel data in the raw file (v1.0 engine only) }}
{{OBDtr| 0xA0 | offset |C87C64| 00 00 00 00 | unused | offset of pixel data in the separate file (v1.1 engine only) }}
{{OBDtr| 0xA4 | char[12] |B0C3D4| AD DE | dead | The layout of these 12 bytes is different for the v1.0 and v1.1 versions (i.e. Windows retail vs. Windows demo and Mac):
*For a v1.1 TXMP, the four bytes at 0xA4-A7 are "00 00 00 00" instead of "AD DE AD DE", and correspond to a "material type" attributed at runtime (from [[TMBD]]), which is then used for impact/breakability lookup. The Windows retail TXMPs apparently have no such "material type" field.
*The fields at 0xA8-AF (for v1.1) or 0xA4-AB (for v1.0) are used only at runtime (and somehow obfuscated by "0xDEAD" when written to disk). Judging by the Windows demo and Mac engine, we can assume they are the same in both engines, and serve for rendering optimization (there is a texture name pointer, a "dirty" flag stored as a byte and 3 extra bytes used as flags).
*For Windows retail, the four bytes at 0xAC-AF are completely unused (not part of the template).
Since runtime fields are grouped at the end, v1.0 and v1.1 TXMPs are treated by OniSplit under the same template, merely switching between the .raw and .sep links and blanking out everything past 0xA4.
}}
{{OBDtr| 0xB0 | char[16] |B0C3D4| AD DE | dead | padding bytes (not part of TXMP) }}
|}

===Effect options===
The "blue shield", "invisibility" and "Daodan shield" options tell the engine to vary the texture's Gouraud shading with certain preset colors that vary with time.

{| class="wikitable"
!Flag name
!Texture with flag
!Used for
|-
|"blue shield"
|TXMPSHIELD
|force shield
|-
|"invisibility"
|TXMPINVIS
|phase cloak
|-
|"Daodan shield"
|TXMPDAODAN_SHIELD
|red boss shield and [[supershield]]
|}

In the vanilla game data, these flags are only used by the above-named textures. The engine also calls upon these textures by hardcoded name in order to create a character's shield or phase cloak effect.

===Animation time===
When using animated textures the image to display is selected using the game time and animation speed. For textures that are used by particles the local (particle) time can be used either to replace or offset the game time.

===Pixel byte storage order===
As noted above under each format description, the bytes of multibyte texture formats are generally stored "backwards" compared to their names, so if a format is named "RGBA"-something then its bytes will be in ABGR order on disk. This convention was established in the Windows world where PCs were little-endian and loading the bytes AA BB GG RR into a 32-bit int in memory would place them in the correct order, 0xRRGGBBAA. Macintoshes, being big-endian at the time, expected the data to be stored in reverse order and thus Oni would perform a byte swap on most of these types when it loaded them into memory to ensure that they ended up as 0xRRGGBBAA in memory. The sole exceptions to this little-endian storage rule among Oni's supported texture formats are RGB_Bytes and RGBA_Bytes, which actually store their bytes in the stated order, RGB and RGBA respectively. However these formats were never used by any textures in Oni.

===Pixel scanline storage order===
Pixels are stored in row-major order, meaning that the pixels are stored in rows and then columns, as opposed to the other way around. These rows are stored in ''top-to-bottom'' order, contrary to what was documented on this wiki for a long time. In the case of the DXT1 storage format, the row-major, left-to-right, top-to-bottom order applies to the 4x4 blocks composing the image, and also inside each 4x4 block for the storage of 2-bit pixels. In the case of the I1 format (multiple pixels per byte), the row-major, left-to-right, top-to-bottom order applies to the 1-bit pixels composing the image.

==PS2 implementation==
The PS2 TXMP layout is similar to PC, with notable differences in the last few bytes due to Rockstar moving to a PS2-standard 32-bit indexed color ("CLUT") system for optimization purposes. Here are the high-level differences:
*There are 4 extra bytes of storage as compared to a v1.1 TXMP (which is already 4 bytes larger than a v1.0 TXMP).
*The extra 4 bytes come from a palette index (int32) inserted at 0x90 before the pixel format (which is pushed down to 0x94 along with everything else that follows).
*Two new pixel formats were added, and are the only formats used on PS2: type 16 for opaque textures (indexed 32-bit RGB with ignored alpha byte), and type 17 for transparent textures (indexed 32-bit RGBA).
*The pixel data (color indices) can be stored either in the .raw file (pointer field at 0xA0) or in the .sep file (pointer at 0xA4).

Here is how the end of TXMPrl_1 looks in level3_Final.dat of the English retail PS2 version.
{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x90 | int32 |C8FFC8| 56 00 00 00 | 86 | index of the 256-color palette used by this texture (starts at 0x15800 in level3_palette.pal) }}
{{OBDtr| 0x94 | int32 |C8FFFF| 10 00 00 00 | 16 | pixel format 16 (indexed 32-bit RGB with inactive alpha) }}
{{OBDtr| 0x98 | link |FFC8FF| 00 00 00 00 | 0 | link to a [[OBD:TXAN|TXAN]] file; used if this texture is animated }}
{{OBDtr| 0x9C | link |FFC800| 00 00 00 00 | 0 | link to a TXMP file that contains the environment map }}
{{OBDtr| 0xA0 | offset |C800C8| C0 05 00 00 |00 00 05 C0| offset of pixel data in the .raw file }}
{{OBDtr| 0xA4 | offset |C87C64| 00 00 00 00 | 0 | offset of pixel data in the .sep file }}
{{OBDtr| 0xA8 | int32 |B0C3D4| 00 00 00 00 | 0 | always 0; presumably the same "material type" (set at runtime) as for Windows demo and Mac }}
{{OBDtr| 0xAC | char[4] |B0C3D4| AD DE AD DE | dead | presumably the same texture name pointer (set at runtime) as for Windows demo and Mac }}
{{OBDtr| 0xB0 | char[4] |B0C3D4| AD DE AD DE | dead | presumably the same rendering optimization flags (runtime) as for Windows demo and Mac }}
{{OBDtr| 0xB4 | char[12] |B0C3D4| AD DE | dead | completely unused bytes (not part of the template) }}
|}

===Palette file format===
*Palettes are stored per-level in level#_palette.pal files in a pal/ subdirectory of GameDataFolder, corresponding to how .raw and .sep files are stored in raw/ and sep/ subdirectories.
*Each level#_palette.pal file contains between 85 and 179 palettes, not counting the first palette (index 0) at the start of each .pal file which is always blank.

===Palette format===
*Valid palette indices start at 1 because of palette 0 always being empty.
*Each color in a palette entry is 4 bytes, stored on disk in RGBA order (byte 0 = red, byte 1 = green, byte 2 = blue, byte 3 = alpha). This is the same layout as RGB_Bytes (type 10) and RGBA_Bytes (type 11), not the reversed BGRA order used by most of the other texture formats.
*Each palette consists of 256 32-bit color slots and thus takes up 1024 bytes. If a palette does not use all 256 entries then the palette is closed out with a series of {0x00, 0x00, 0x00, 0x80} entries.
*Each pixel in the .raw or .sep data is stored as a 1-byte index into the image's chosen color palette.

===Palette CLUT swizzle===
:The PS2 Graphics Synthesizer (GS) stores CLUT entries in a scrambled order due to its hardware cache line layout. Within every 32-entry block of the palette, entries 8–15 and 16–23 are swapped relative to their logical positions. Software reading the palette must undo this before using it as a palette index.

===Ignored alpha byte for type 16===
:The fourth byte would represent alpha, but in RGB888 it is merely a padding byte, always set to 0x80.

===Alpha scaling for type 17===
:The PS2 GS uses a half-range alpha where 0x00 = fully transparent and 0x80 = fully opaque (values above 0x80 are technically possible but indicate "source alpha contribution > 1" in GS blending, which doesn't arise in Oni).

===Alternating use of .raw or .sep storage===
Unlike the Win/Mac game data (where pixel data is stored exclusively in .raw or exclusively in .sep for all TXMPs), PS2 TXMPs use .raw and .sep storage alternatingly, depending on the TXMP. The engine apparently uses the .sep pointer if there is no .raw pointer (or vice versa).

Examples of textures using .sep storage are: all [[:Category:Fly-in_portraits|fly-in portraits]]; all [[:Category:Splashscreens|splashscreen]] components; some illustrations in Konoko's [[Data Comlink]] (namely, [[:File:TXMPLevel02move.png|combat move illustrations]] and [[:File:TXMPhypo.png|item illustrations]]; objectives and weapon illustrations use .raw storage).

Environment/character/particle TXMPs seem to be using .raw storage consistently (not checked beyond level1_Final). As a notable anomaly, .sep storage is used for the following three textures (console screens) in level0_Final: _CON_SAVEGAME (main TXMP only; the animation frames use .raw storage), _CON_SAVEGAME_USED, _CON_USED.

==Oni's internal storage types==
Some of Oni's 18 types of image storage are elaborated on below in order to illustrate exactly how they work. The "Mem view" column shows the bytes in big-endian format and the "Disk view" column shows the bytes as they are actually stored in little-endian order. For example, bytes in memory shown as 0xFC00 are stored as "00 FC" on disk.

===ARGB4444 (type 0)===
*A 16-bit field is used to store 4 color channels (4 bits each, values from 0 to 15).
*Bit masks are 0x000F for Blue, 0x00F0 for Green, 0x0F00 for Red, 0xF000 for Alpha.
*Stored as big-endian in TXMP (first the AAAARRRR byte, then the GGGGBBBB byte).
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 1 (high) <code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>A A A A R R R R</code>||<code>G G G G B B B B</code>
|-
!colspan=3| Bit values for primary colors (fully opaque)
!Mem view
!Disk view
|-
|Black||<code>1 1 1 1 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!F0 00!!00 F0
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF!!FF FF
|-
|Red||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!FF 00!!00 FF
|-
|Green||<code>1 1 1 1 0 0 0 0</code>||<code>1 1 1 1 0 0 0 0</code>
!F0 F0!!F0 F0
|-
|Blue||<code>1 1 1 1 0 0 0 0</code>||<code>0 0 0 0 1 1 1 1</code>
!F0 0F!!0F F0
|-
|Cyan||<code>1 1 1 1 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!F0 FF!!FF F0
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 1 1 1 1</code>
!FF 0F!!0F FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 0 0 0 0</code>
!FF F0!!F0 FF
|}

===RGB555 (type 1)===
*A 16-bit field is used to store 3 color channels (5 bits each, values from 0 to 31).
*Bit masks are 0x001F for Blue, 0x03E0 for Green, 0x7C00 for Red.
*The high bit (0x8000) is unused, but is always set to 1 by convention.
*Stored in little-endian order in TXMP.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 1 (high) <code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>X R R R R R G G</code>||<code>G G G B B B B B</code>
|-
!colspan=3| Bit values for primary colors
!Mem view
!Disk view
|-
|Black||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!80 00!!00 80
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF!!FF FF
|-
|Red||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FC 00!!00 FC
|-
|Green||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!83 E0!!E0 83
|-
|Blue||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!80 1F!!1F 80
|-
|Cyan||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!83 FF!!FF 83
|-
|Magenta||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!FC 1F!!1F FC
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!FF E0!!E0 FF
|}

===ARGB1555 (type 2)===
*A 16-bit field is used to store 3 color channels (5 bits each, values from 0 to 31) and one 1-bit channel.
*Bit masks are 0x001F for Blue, 0x03E0 for Green, 0x7C00 for Red, and 0x8000 for Alpha.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 1 (high) <code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>A R R R R R G G</code>||<code>G G G B B B B B</code>
|-
!colspan=3| Bit values for primary colors (opaque)
!Mem view
!Disk view
|-
|Black||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!80 00!!00 80
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF!!FF FF
|-
|Red||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FC 00!!00 FC
|-
|Green||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!83 E0!!E0 83
|-
|Blue||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!80 1F!!1F 80
|-
|Cyan||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!83 FF!!FF 83
|-
|Magenta||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!FC 1F!!1F FC
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!FF E0!!E0 FF
|}

===A4I4 (type 6)===
*An 8-bit field is used to store an intensity and an alpha (4 bits each, values from 0 to 15).
*Bit masks are 0x0F for Intensity, 0xF0 for Alpha.
*Endianness is irrelevant for single-byte storage.
{|border=1 cellpadding=3 cellspacing=0
!Bits
!<code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>A A A A I I I I</code>
|-
!colspan=2|Examples of bit values
!Mem view
|-
|Black, opaque||<code>1 1 1 1 0 0 0 0</code>
!F0
|-
|White, opaque||<code>1 1 1 1 1 1 1 1</code>
!FF
|-
|Black, transparent||<code>0 0 0 0 0 0 0 0</code>
!00
|-
|White, transparent||<code>0 0 0 0 1 1 1 1</code>
!0F
|}

===ARGB8888 (type 7)===
*A 32-bit field is used to store 4 color channels (8 bits each, values from 0 to 255).
*Bit masks are 0x000000FF for Blue, 0x0000FF00 for Green, 0x00FF0000 for Red, 0xFF000000 for Alpha.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 3 (highest) <code>7 6 5 4 3 2 1 0</code>
!Byte 2 (higher) <code>7 6 5 4 3 2 1 0</code>
!Byte 1 (high) <code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>A A A A A A A A</code>||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>
|-
!colspan=5| Bit values for primary colors (fully opaque)
!Mem view
!Disk view
|-
|Black||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FF 00 00 00!!00 00 00 FF
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF FF FF!!FF FF FF FF
|-
|Red||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FF FF 00 00!!00 00 FF FF
|-
|Green||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!FF 00 FF 00!!00 FF 00 FF
|-
|Blue||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 00 FF!!FF 00 00 FF
|-
|Cyan||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 FF FF!!FF FF 00 FF
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF 00 FF!!FF 00 FF FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!FF FF FF 00!!00 FF FF FF
|}

===RGB888 (type 8)===
*A 32-bit field is used to store 3 color channels (8 bits each, values from 0 to 255).
*Bit masks are 0x000000FF for Blue, 0x0000FF00 for Green, 0x00FF0000 for Red.
*The high byte (0xFF000000) is unused, but is always set to 00 by convention.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 3 (highest) <code>7 6 5 4 3 2 1 0</code>
!Byte 2 (higher) <code>7 6 5 4 3 2 1 0</code>
!Byte 1 (high) <code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>X X X X X X X X</code>||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>
|-
!colspan=5| Bit values for primary colors
!Mem view
!Disk view
|-
|Black||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!00 00 00 00!!00 00 00 00
|-
|White||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF FF FF!!FF FF FF 00
|-
|Red||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!00 FF 00 00!!00 00 FF 00
|-
|Green||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!00 00 FF 00!!00 FF 00 00
|-
|Blue||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 00 FF!!FF 00 00 00
|-
|Cyan||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 FF FF!!FF FF 00 00
|-
|Magenta||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF 00 FF!!FF 00 FF 00
|-
|Yellow||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!00 FF FF 00!!00 FF FF 00
|}

===RGB_Bytes (type 10)===
*Three consecutive 8-bit fields are used to store 3 color channels (8 bits each, values from 0 to 255).
*Each channel has its own byte, and there is no "unused" byte (the bytes are packed 3 by 3).
*Endianness is irrelevant when storing as a sequence of bytes.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 0 (red) <code>7 6 5 4 3 2 1 0</code>
!Byte 1 (green) <code>7 6 5 4 3 2 1 0</code>
!Byte 2 (blue) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>
|-
!colspan=4|Bit values for primary colors
!Mem view
|-
|Black||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!00 00 00
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF FF
|-
|Red||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FF 00 00
|-
|Green||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!00 FF 00
|-
|Blue||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 FF
|-
|Cyan||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF FF
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!FF FF 00
|}

===RGBA_Bytes (type 11)===
*Four consecutive 8-bit fields are used to store 4 color channels (8 bits each, values from 0 to 255).
*Each channel has its own byte. Endianness is irrelevant when storing as a sequence of bytes.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 0 (red) <code>7 6 5 4 3 2 1 0</code>
!Byte 1 (green) <code>7 6 5 4 3 2 1 0</code>
!Byte 2 (blue) <code>7 6 5 4 3 2 1 0</code>
!Byte 3 (alpha) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>||<code>A A A A A A A A</code>
|-
!colspan=5| Bit values for primary colors (fully opaque)
!Mem view
|-
|Black||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 00 FF
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF FF FF
|-
|Red||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 00 FF
|-
|Green||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF 00 FF
|-
|Blue||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 FF FF
|-
|Cyan||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF FF FF
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 FF FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF 00 FF
|}

==Notes==
<references/>

{{OBD_File_Footer | type=TXMP | prev=TXMB | next=TxtC | name=Texture Map | family=General}}

{{OBD}}

Marathon

2026-04-14T19:29:32Z

Iritscen: broke page into distinct sections for old and new Marathon, added image for NuMa

Marathon is a series of first-person shooter games started by Bungie. Now that the new Marathon has been released, the old games are sold under the name Classic Marathon, Classic Marathon 2 and Classic Marathon Infinity.

==Classic series (1994–1996)==
[[Image:Marathon - Defend THIS!.jpg|right|400px]]
The original Marathon was released for Macintosh in 1994 and was preferred by Mac gamers as a more sophisticated alternative to the PC hit DOOM. As with the [[Myth]] series, Bungie made the first two games ('''Marathon''' and '''Marathon 2: Durandal''') and then another studio made the third ('''Marathon Infinity'''). Unlike Myth's third game, the third Marathon game stayed close to the previous games' roots because Marathon Infinity was created by [[wp:Double Aught|Double Aught]], a short-lived studio spun off from Bungie which was co-founded by Marathon's lead writer, Greg Kirkpatrick.

Bungie is known for cross-referencing their games, and indeed there are multiple references to Classic Marathon in [[Oni]], documented in the [[Easter eggs]] article.

Unlike Oni with its [[Multiplayer|canceled multiplayer]], Marathon shipped in 1994 with a very popular multiplayer feature (LAN-only). Bungie also supported the modding community with helpful information on the file formats; they eventually released the development tools Forge and Anvil alongside Marathon Infinity.

In 1999, the Marathon 2 engine was open-sourced by Bungie. This code was used by fans to produce Aleph One, a unified engine which runs the scenarios for Marathon, Marathon 2, and Marathon Infinity as well as fan-made scenarios. The original LAN networking was improved and extended to be Internet-capable. In 2005, the Marathon Trilogy was made freeware by Bungie, so anyone can download it legally and play it on modern computers with the Aleph One engine (see links below).

;Community links
:[https://alephone.lhowon.org/ Lhowon.org] (serves the Trilogy, the standalone Aleph One engine, and links to the Aleph One source code)
:[https://marathon.bungie.org/ Marathon.Bungie.Org] (home of the Marathon Story Forums and Story Page)
:[https://simplici7y.com/ Simplici7y] (mod repository)
:[https://pfhorums.com/ Pfhorums] (community forum)
:[https://metaserver.lhowon.org/ Lhowon.org metaserver] (for Internet matchmaking)

;Marathon (1994) on Bungie.net (archived)
:[https://web.archive.org/web/20140421231244/http://halo.bungie.net/inside/history.aspx?link=juggernougat Bungie History: Marathon]
:[https://web.archive.org/web/20130501113706/http://halo.bungie.net/projects/marathon/asset_thumb_viewer.aspx?at=59&cc=33 Picture galleries]

;Marathon on Wikipedia
:The Marathon games are documented extensively on Wikipedia; you can start with the [[wp:Marathon (series)|"Marathon series" article]], but there are specific articles for each game as well.

==Extraction shooter (2026)==
[[Image:Marathon (2026) - NuCal.jpg|right|400px]]
Unlike Oni and Myth, the rights to the Marathon [[wp:Intellectual property|IP]] never left Bungie's hands. Bungie announced in May 2023 that they were returning to the IP with a new extraction shooter set on/around Tau Ceti, the location of the original game. The game released in March 2026. A major Oni reference occurs in the form of the AI agent named ONI – see {{SectionLink|Easter eggs|Marathon (2026)}}.

:[https://www.youtube.com/watch?v=ckI_m8bbXfw Official Announce Trailer - YouTube]
:[https://www.marathonthegame.com/ Official Site]
:[https://www.youtube.com/watch?v=fvbEnWLRo1s Reveal Cinematic Short - YouTube]

[[Category:Real World]]

File:Marathon (2026) - NuCal.jpg

2026-04-14T19:28:23Z

Iritscen: Category:Other video game images

== Summary ==
[[Category:Other video game images]]

File:Marathon (2026) - ONI.jpg

2026-04-14T19:06:52Z

Iritscen: Iritscen moved page File:Marathon (2025) - ONI.jpg to File:Marathon (2026) - ONI.jpg without leaving a redirect: who could have foreseen the game being delayed?

== Summary ==
[[Category:Other video game images]]

Easter eggs

2026-04-14T19:06:00Z

Iritscen: wording tweak to emphasize the importance of ONI in Marathon (2026)

An Easter egg is a secret message placed in a game by a developer. Typically Easter eggs speak to the audience directly, make an inside joke, or contain vanity messages such as hidden credits. [[Oni]] contains a few in-jokes and a lot of references to other Bungie games, as is common for Bungie.
{{TOClimit|3}}
==References hidden in Oni==
{{Anchor|OMM}}
===Old Man Murray and fake Sean Connery===
[[Image:Penny_Arcade_-_EvilCorp.jpg|thumb|250px|right|Not an Easter egg, but very apropos: a [[wp:Penny Arcade|Penny Arcade]] comic about crates and Oni.]]
Old Man Murray was a gaming blog with feisty criticism of the industry; its writers would later work on [[wp:Psychonauts|Psychonauts]] and the [[wp:Portal (series)|Portal games]]. In [https://www.oldmanmurray.com/features/39.html one of their most famous articles], they suggested that the ultimate quality of a game could be judged by a single measurement called "Start to Crate": the amount of time from the start of the game until the first crate (or barrel, etc.) is sighted. The smaller the time, the worse the game, as the use of crates to adorn a level demonstrates that the developers have run out of ideas.
{|align=left
|[[Image:TheDayIsMine crate.png]]
|}
Oni's first level is a warehouse and it is literally ''full'' of crates, barrels and containers. You can see a stack of crates right from where you start the level (there are also crates in the training course, but not in the first room). On one of the first crates you see in the Warehouse, there's a self-deprecating label saying "-OMM- TTC 1.1" or, in other words, "-Old Man Murray- Time To Crate 1.1 seconds"; a pretty bad score, needless to say.

Underneath this is written "THE DAY IS MINE!!" While Oni players will see this as a reference to the cheat code for activating [[Developer Mode]], it should be noted that the "thedayismine" cheat was never intended to be published or present in the shipped game, so there was little point in writing the cheat code (with spacing and punctuation) on a crate. Most proximately, this crate's text should be seen as a reference to Saturday Night Live's [[wp:Celebrity Jeopardy! (Saturday Night Live)|Celebrity Jeopardy!]], a popular recurring comedy sketch in the late 1990s. In it, the character "Sean Connery" frequently says, "The day is mine!" The cheat code "thedayismine" is merely another manifestation of the same quote, which must have become an office in-joke. (A second reference to Celebrity Jeopardy! is found below under {{SectionLink||Febtober Striker}}.)
{{clearall}}

===Marathon (1994)===
The [[Marathon]] trilogy began and ended before Oni's release; it was a major source of new Bungie fans in their first decade, before the release of Halo.

====Marathon symbol====
The first Oni trailer featured [[wp:Marathon (1994 video game)|Marathon]] symbols {{Hover|on the crates|image=1998 trailer 73.png}}. In-game, the Marathon symbol can be seen on the hull of the [[TCTF]] computer [[Damocles]] in [[{{C6}}]] and [[{{C13}}]] (see texture TXMPTC_SHCOMP2 as well as [[:Image:Damocles 1.jpg|this concept art]]). Fans certainly did not miss this, so Harry brought it up in [http://oni.bungie.org/special/part1/alex.html his interview with Alex Okita]:

:;Harry: Who did the first Oni trailer? The one yanked from the web rather often.
:;Alex: I did the direction for it, Steve [Abeyta] and Chris [Hughes] did all the animation.
:;Harry: And the crate with the Marathon logos. A nice touch...You made Hamish [Sinclair] really paranoid with that one...
:;Alex: (grinning) That was our goal.
:;Harry: That's why that picture of Damocles has a small Marathon logo on it, huh?
:;Alex: Yeah (laughs) It kicks up some dust.
:;Harry: Any significance to the name?
:;Alex: It's kind of [a] cool name.
:;Harry: It's not gonna drop on your head or anything...
:;Alex: No, heh. Although it is kind of neat; it's a giant supercomputer which has all these cables going through the ceiling.

====Wave Motion Cannon====
[[Image:TXMPbarab gun.png|right]]
A weapon called "Wave Motion Cannon" was seemingly [https://marathon.bungie.org/story/weapons.html cut from Marathon]. As we know, the [[Wave Motion Cannon]] is the biggest weapon in Oni and the only one with two firing modes. The Marathon weapon in turn references the primary weapon of the titular ship in the [[anime]] "Space Battleship Yamato".

====Frog blast the vent core!====
[[Comm Trooper]]s can say "Okay, okay, ''don't'' frog blast the vent core!" as a taunt, but only very rarely (the odds are 4%). This is a reference not just to Marathon's assimilated BOBs but to the fact that they share a voice actor, Doug Zartman. The inhabitants of the UESC ''Marathon'' (who are called BOBs because they were "Born On Board") have been partially replaced with "assimilated" versions, or "simulacrums". The assimilated BOBs are intended to blend in with the normal ones until they can get close enough to the player to detonate themselves. The big giveaway that they are not normal is the odd phrases they sometimes shout – the most famous of which is "Frog blast the vent core!"

Zartman describes the inspiration for the quote in the Marathon Scrapbook:
{{Quote|The idea was that some of the assimilated Bobs become insane from their conversion and run around yelling nonsense. Alex [Seropian] said to me ‘say something random’, and that phrase tumbled from my lips. Totally spontaneous. While I could have sat down and thought up something more random than that, it worked out well, since it sounds close enough to a real sentence that it kept people guessing and generated some fascinating (and totally wrong) discussion about what the phrase was and its meaning. One popular theory was ‘God bless the Marine Corps!’, which was a fair guess, but still wrong.}}

It was very popular to say this in the text chat of a networked Bungie game or on IRC; the sheer randomness of this phrase means it can be used at any time.

Zartman also recorded the Easter egg line "She's everywhere!" for the Comm Trooper; this is a reference to the BOB line "They're everywhere!" (referring to the invading aliens). It was not connected to any [[OSBD]] and thus cannot play in-game, but it can be heard in the bonus track at the end of [[Music/CD#End Titles|End Titles]] on the OST CD.

====Rampancy====
The word [[wikt:rampant|rampant]] had existed before Bungie, but the specific concept of "[[wp:Marathon (series)#Rampancy|rampancy]]", referring to an AI that goes out of control and acts with free will, was coined and subsequently developed by the Marathon team (this concept was revisited by 343 Industries for Halo 4). The three/four stages of a rampant AI are Melancholia, Anger, Jealousy, and Metastability. An egotistical level of self-awareness accompanies the development of the AI's personality. The tirades of the [[Deadly Brain]] (only seen in the subtitles) are a reference to this, as shown by Shinatama's statement, "Clearly, it's gone rampant." However, a rampancy in Marathon takes place when an AI is exposed to large amounts of data for a long enough period of time. Here, the Deadly Brain is a disembodied human brain, and it is essentially just going crazy because Konoko "decoupled its core logic" (how exactly does one do that to a human brain, anyway?).

===Myth===
The second [[Myth]] game was Bungie's most recent release before Oni in 2001, and about as popular as the Marathon series.

====Balor====
Forklifts in the Warehouse are labeled "BALOR", and Balor is the name of a Celtic god, but it is also the name taken by the incarnation of "the Leveler" in Myth.
:'''''From [[wp:Special:PermanentLink/245212356|an old version]] of Wikipedia's Balor article:'''''
:Balor is the name Connacht the Wolf adopts when he becomes the new Leveler in the Myth computer game series. During the seventeenth year of the Great War, he interrogated the hero Alric, who was previously captured by one of Balor's six Fallen Lords (The Deceiver). During the interrogatory Alric learned by chance that the Fallen Lords were bound to Balor. Near the end of the war, Alric and the Legion went to Rhi'anon, Balor's fortress, and to enrage Balor planted the Myrkridian standard they had found inside the Tain. During the Last Battle, Alric immobilized Balor with the aid of the Eblis Stone, thus allowing the barbarians of the Legion to behead the warlord. In the end, Balor's head was thrown into the Great Devoid, ending his life and his sway over the surviving Fallen.

====Surly Dwarf====
The dwarf unit of Myth, voiced by Bob O'Donnell, is sometimes referred to as the Surly Dwarf. He is loosely referenced by the writing on the side of Konoko's motorcycle which mentions "Surly Performance Forks" (forks are the front suspension for a motorcycle).

====Soundtrack====
A number of ambient themes from '''Myth: The Fallen Lords''' and '''Myth II: Soulblighter''' were reprised in Oni:
*'''Heart of the Stone''' (from Myth, reprised in Myth II as '''Gonen's Bridge''')
*'''Smiths of Muirthemne''' (from Myth)
*'''A Traitor's Grave''' (from Myth)
*'''The Deceiver''' (from Myth II)

See [[Music/Myth]] for details.

==References to Oni in other works==
===Halo===
====ONI====
[[Image:Halo's ONI.png|right]]
Oni doesn't refer to Halo unless you count the [[Oni matrix]] naming Cortana, but [[wp:Halo (franchise)|Halo]] features an entity called [https://www.halopedia.org/Office_of_Naval_Intelligence ONI]. Pronounced in-game like the word "oni", ONI stands for Office of Naval Intelligence. A military intelligence service by this name [[wp:Office of Naval Intelligence|actually exists]]: it's the United States' oldest continuously operating intelligence service (est. 1882).

There has been a lot of speculation around Halo's ONI, most of which you can see on the [http://halostory.bungie.org/oni.html Halo Story Page]. A specific entry which draws the parallel between Halo's ONI, the [[Oni (myth)|Japanese myth of the oni]], and Bungie's "Oni" is [http://halostory.bungie.org/newssearch.html?newsitem=695 HERE].

====The demon====
After Master Chief's exploits in Halo CE where he singlehandedly turns the tide of battle and destroys an entire Halo installation, he becomes known to the Covenant as "the demon". It's difficult to find any discussion of whether this was a deliberate reference to the word "oni" but it's hard to believe it's a coincidence. Few people have noticed this possible reference, and Bungie devs do not seem to have discussed it in any interviews.

===Big Strike Bowling===
Although this is more than an Easter egg, it needs to be mentioned here simply for its unexpectedness – not to mention that it's the only game besides Oni in which Konoko appears. [[Big Strike Bowling]], an obscure game from the end of the PS1's life cycle, contained unlockable characters, and the most expensive of them was Konoko. The only other character from an outside game IP was Max Payne.

===Marathon (2026)===
[[Image:Marathon (2026) - ONI.jpg|256px|right]]
Bungie still hasn't forgotten about Oni. In Bungie's new Marathon, you control a cybernetic "runner" who can take contracts from various factions. One of these factions, a corporation named CyberAcme, uses an AI agent called ONI to interact with runners. When a player starts the game, ONI is responsible for overseeing the player's onboarding and introduction to other factions; in-world, this is referred to as a "reorientation" where the digitized consciousness of a runner is installed into a newly manufactured body. Like Halo's ONI, this AI's name is pronounced as the word "oni", not as separate letters. She is voiced by Donnla Hughes. ONI's appearances so far are:
*[https://www.youtube.com/watch?v=fvbEnWLRo1s Marathon | Reveal Cinematic Short]. Here ONI handles the "grounding exercises" for respawned runners – see 2:43, 4:00, 8:03 for ONI's appearances.
*[https://www.youtube.com/watch?v=N4Jv5H3_yAo Marathon | Alpha Intro Cinematic]. You can hear ONI say her own name at 1:27.
*[https://www.youtube.com/watch?v=Sw_PdO-W9bY Bungie’s Marathon – ONI Intro & CyberAcme AI Intro]. ONI introduces herself here and guides the player's reorientation.

==Developer cameos==
===Name drops===
[[Image:RT_BILLBRD2.jpg|right]]
The poster for "mr.b's dance troupe", appearing in [[Rooftops]], can be seen at right. It names three members of the team: Dave Dunn, Steve Abeyta and Chris Lee. "Mr. B" may possibly be referring to Brent Pease, who was Project Lead through the end of 1999.

The [[:Image:No 1 Chris Hughes GLASSMBO.jpg|impact texture]] for the Mercury Bow contains the name of Chris Hughes, one of the texture artists. His name is also preserved in the Hughes Death Adder SMG, the standard weapon for Syndicate Strikers.

Konoko's service pistol is the Campbell Equalizer Mk4, and the name "Campbell" can be found in a few places connected to Bungie: the Campbell/LeBel family members mentioned in the [[Quotes/Credits|credits]], the city of Campbell, CA (arguably the true location of [[Bungie West]], not San Jose), and [[Steve Campbell]], founder of Bungie.org and Oni Central.

A couple consoles starting [[Quotes/Consoles#Extraordinary security measures|HERE]] contain emails written between "P[eter] Tamte" and "D[avid] Joost".

Michael Evans is likely being given a cameo in [[Quotes/Consoles#Evans|the Evans console]].

Michael Wu's name is used for the Wucraft transport plane in [[Quotes/Diary#CHAPTER_05_._HOT_PURSUIT|this diary entry]].

The name of Bungie itself is found (very faintly) on the side of Konoko's motorcycle above the reference to the {{SectionLink||Surly Dwarf}}.

===Voice appearances===
Several one-line NPCs are likely voiced by Bungie staffers, such as the "particularly suave scientist" of Chapter 6, but we usually can't identify who they were. One that has been identified is the scientist who's [[Quotes/Speech#Really really misc|just trying to hide]], which was recognized by Marty O'Donnell as his own voice when asked in 2024. The Deadly Brain's non-verbal vocals sound like Hardy LeBel.

==Secrets and jokes==
There are quite a few semi-hidden items and characters in Oni. The items hidden in corners of the levels (called "[http://carnage.bungie.org/oniforum/oni.forum.pl?read=20168 Wu goodies]" by Bungie West) generally don't qualify as Easter eggs as most of them can be uncovered by carefully exploring the level.

===Forklift Striker===
However a special mention goes to the secret [[Striker]] in [[{{C1}}]]. If you pass the first door, then take the stairs to the top floor, and jump onto the cabin of the forklift, a Striker will appear (see [https://www.youtube.com/watch?v=iU4T1Qpu-8U this video]). When killed, he drops 3 items (hypo spray, phase cloak, force shield). The phase cloak and the force shield are otherwise not encountered before [[{{C3}}]], and the secret Striker comes before the first Striker you see normally (after you find [[Chung]]). The very improbable encounter and its extraordinary reward distinguish this secret Striker as Oni's most complex Easter egg.

===Febtober Striker===
A trigger volume in [[{{C2}}]] has the name "febtober", which is a second reference (after [[#OMM|-OMM- TTC 1.1]]) to the Celebrity Jeopardy! sketches on Saturday Night Live. In one sketch, "Sean Connery" guesses that the month of the year starting with "Feb" is "Febtober". Any possible additional in-joke at Bungie concerning this "month" is unknown. Triggering "febtober", which is done by jumping off the walkway with the turret at the end, spawns a Striker with a plasma rifle who patrols the corridor near the turbines seen in the [[:Image:CHAPTER_02_._ENGINES_OF_EVIL.png|level's splashscreen]].

===Happy Bomber===
Normally [[Mad Bomber]]s have a neutral facial expression, but at the medium LOD (level of detail) in the character geometry, the texture coordinates are different from the other LODs and the bomber appears to be smiling:
[[Image:Bipolar Bomber.jpg|thumb|250px|center]]

===The day after===
In {{C3}}, there's [[Quotes/Consoles#The_day_after|this safety-related console]] right before the acid room:
{{:Quotes/Consoles/level 3d}}
Nothing happens if you don't read the console.

===Cleam air===
[[Image:TXMPPOSTER4.png|right]]
An in-game poster found in [[{{C4}}]] depicts cartoon children frolicking in a city while wearing heavy-duty masks. The caption reads "CLEAM AIR HAPPY".

The in-joke behind this misspelling of "clean" as "cleam" just so happens to have a public explanation at the 16'45" mark in [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day2_big.mov this video tour] of Bungie West, when Dave Dunn points to a [[wp:My Neighbor Totoro|My Neighbor Totoro]] poster on the wall of their office with this [[wikt:Engrish|Engrish]] text at its bottom: "CLEAM AIR OF THEIR NEW HOME".

===VI-AG crane===
Besides "Balor" being written on the cranes as discussed above, the final crane in {{C1}} with an arm (the one Konoko uses to stop the Syndicate truck) says on one side of its arm "VI-AG" and the other side reads "KEEP IT UP".

===Hugh Jass===
The truck Konoko steals in {{C14}} reads "Hugh Jas Truckin' Lines". One 's' is used here, and two in the Credits where "Hugh Jass" is thanked.

==Unused resources and features==
Though not Easter eggs, resources that were never used in the final game can sometimes be found by looking through the level scripts and game data. For instance, a music theme called "[[Music/Ingame#The Hunt|The Hunt]]" was placed in [[{{C13}}]] but was supposed to play in [[{{C12}}]], and additional characters can be spawned for the boss battle in [[{{C14}}]]. A more famous example is [https://www.youtube.com/watch?v=dszw2vmlmzw an undressing animation] for Konoko that was intended to be used in [http://carnage.bungie.org/oniforum/oni.forum.pl?read=14686 a cut feature] where Konoko could go undercover by changing into different clothes. More unused animations are listed [[XML:TRAM#List of unused animations|HERE]]. Lastly, some sound effects for the [[Iron Demon]] can be found in the global resources.

As mentioned at the top of the article, a reference to Developer Mode (the cheat code '''thedayismine''') is found on a crate label in {{C1}}, along with an Old Man Murray reference. Developer Mode was believed to be absent from the retail game builds, but was [[History of Oni modding/The tale of Dev Mode|eventually unlocked]] in 2006.

Some features of the engine were not fully utilized by the game. In one case, a feature was even obscured by a bug: the AI knew how to dodge gunfire but was not looking at the right axes to reliably do this. This was fixed by Neo in a patch made with the [[Daodan DLL]], resulting in much smarter behavior by AIs under fire.

[[Category:Added value]]

OniGalore:About

2026-04-13T18:27:11Z

Iritscen: added descrip. of wiki's contents

__NOTOC__
{{PoliciesSidebox}}
===Who We Are===
OniGalore is a wiki (a freely editable website) run by the [[Oni]] fan community. The software used by OniGalore is [[mw:MediaWiki|MediaWiki]], the same software that Wikipedia runs on. For an overview of how wikis work, see the [[wp:Wiki|Wiki]] article on Wikipedia.

The editing of OniGalore is currently limited to registered users in order to prevent spam. If you request an account, you will need to wait for it to be approved before you can start editing.

===What OniGalore Contains===
The founding purpose of the wiki was actually technical documentation: the fans who were reverse-engineering the format of the game data needed a place they could collaborate. Over time, fan fiction and fan art were added in large amounts, and project pages for mods and modding tools were created. Eventually we even got around to documenting the game itself from a player standpoint (years after the wiki was started :-), though there's still work to do there.

===How To Help===
If you're interested in contributing to the wiki and haven't edited one before, then you should start by reading [[Help:Editing]]. Then check out the [[OniGalore:Current events|Current events]] page for suggestions on where your help will be most valuable.

Unlike on Wikipedia, we only have [[OniGalore:Dos and don'ts|a few "do"s and "don't"s]] concerning style. Mistakes can always be fixed/undone, but try to experiment in your userspace or on [[:Category:Test pages|a test page]], and ask an experienced editor if you're not sure about something.

Cleaning up a messy area on the wiki typically requires good knowledge of the topic you're trying to document. If you don't feel competent, you can always try and nag someone knowledgeable into doing the job :-)

===How To Customize OniGalore===
If you have an account on OniGalore then you have a lot of control over the appearance of the wiki. You can start by looking through your [[Special:Preferences|preferences]]. Note the "Appearance" tab. Not only can you select an alternate skin here, but you'll notice red links for each skin called Custom CSS and Custom JavaScript. You can use those pages to create personal modifications to the appearance or behavior of that skin (these only work when you are logged in). Many examples can be found by looking [https://en.wikipedia.org/w/index.php?search=vector+2022.js&search=vector+2022.js&title=Special%3ASearch&profile=advanced&fulltext=1&ns2=1 here] at custom CSS/JS pages that Wikipedia users have made for Vector 2022, the current skin in use on both Wikipedia and OniGalore. We have some customizations on OniGalore for the Vector skin (no longer in use) which you can find [https://wiki.oni2.net/w/index.php?title=Special%3ASearch&redirs=1&search=vector.css&fulltext=Search&ns2=1&title=Special%3ASearch&advanced=1&fulltext=Advanced+search here].

[[Category:Policies and documentation]]

Validate External Links/Exceptions

2026-04-13T15:23:50Z

Iritscen:

If the Validate External Links script is mis-reporting certain external links as issues when they actually work fine or when the link has to be presented that way for a specific reason, add them here in order to exempt them from ValExtLinks' reports. The list is sorted by wiki page name for convenience. Each line supports four comma-separated fields, the first three required:
#The response code that ValExtLinks should expect. For NG and RD links, this should be the exact HTTP response code or the 'curl' result code, whichever applies. You can also put "IW" or "EI" here to exempt a warning about an interwiki or external internal link.
#The recurring "problem" link. Place a '*' as a wildcard at the end of a URL to match multiple links.
#The wiki page that this link is appearing on. Use the proper page name, i.e. underscores where the displayed name has spaces. To exempt this link from Val's report regardless of what page it appears on, put a '*' here.
#(optional) A comment explaining the exception. The only requirements are that the comment be separated from the previous field by a space and that you don't use any commas. The "--"s used below are only for human readability.

<pre>
BEGIN LIST
403,https://dotnet.microsoft.com/en-us/download/dotnet-framework,*
403,https://dev.epicgames.com/*,*
403,https://*.blender.org/*,*
403,https://*.fandom.com/*,*
403,https://*.gamespot.com/*,*
403,https://www.rnd.de/*,*
403,https://wikis.khronos.org/opengl/History_of_OpenGL,AE:ONK/EXE
403,https://www.gamefront.com/games/jedi-knight-iii/file/major-kusanagi,AE_talk:BGI
403,https://www.java.com/en/download/,Anniversary_Edition
403,https://binarygroup.com/,BGI
403,https://x.com/craigmullins3/status/1920384911292207363,Category:Art_by_Craig_Mullins
403,https://x.com/mehvechan,Category:Art_by_Lorraine_Reyes
403,https://x.com/Quantum_Sheep/status/1473397180535029760,Category:Oni_(WAP)_game_images
403,https://www.artstation.com/artwork/D9d2o,Duality
403,https://www.artstation.com/artwork/Jl8YXa,Duality
403,https://www.artstation.com/artwork/4bNKW4,Duality
403,https://www.artstation.com/artwork/l9g5V,Duality
301,http://translate.google.com/#en%7Cja%7CChrysalis,File:Daodan_Chrysalis_in_Chinese.png
403,https://www.artstation.com/artwork/4bNKW4,File:Duality_concept_art_-_BioCorp_VR_avatar.jpg
EI,https://wiki.oni2.net/Special:ListFiles?limit=500&ilsearch=Fallen,File:Fallen_Enemies.jpg -- EI link is necessary because this special page can't take these parameters when linked to internally
403,https://www.fab.com/listings/a1fe637c-ef4d-45de-9a21-9a377d06dee1,File:KatiaVersusKonokoFront.png
403,https://x.com/mehvechan/status/556178295612391425,File:Lorraine_Reyes_with_Konoko_Fully_Armed_standup.jpg
000-92,https://www.adobe.com/products/catalog.html#category=3d-ar,Fuse
000-92,https://helpx.adobe.com/beta/fuse/faq.html,Fuse
404,https://www.autodesk.com/products/fbx/overview,Importing_character_models
000-92,https://www.adobe.com/creativecloud/plans.html,Media_creation_with_artificial_intelligence
EI,http://wiki.oni2.net/Main_Page,MediaWiki:Vector -- necessary EI link to demonstrate circular arrow
EI,http://wiki.oni2.net/Main_Page,MediaWiki:Vector-2022 -- necessary EI link to demonstrate circular arrow
404,https://www.autodesk.com/products/softimage/overview,Mod_Tool
403,https://www.guru3d.com/download/rtss-rivatuner-statistics-server-download,Mouse_control_issues
403,https://www.vgmpf.com/Wiki/index.php?title=Brian_Salter,Music
403,https://www.supreme-network.com/midis/browse/O/3494-oni/13574-konoko-chase,Music/Fanmade
403,https://wikis.khronos.org/opengl/S3_Texture_Compression,OBD:TXMP
403,https://www.sec.gov/Archives/edgar/data/946581/0000891554-00-000145.txt,Oni
403,https://www.sec.gov/Archives/edgar/data/946581/000112528202003845/b320556.htm,Oni
403,https://www.artelino.com/articles/japanese_mythology.asp,Oni_(myth)
403,https://pcsx2.net/,Oni_(PlayStation_2)
000-28,https://mega.nz/#!x9oHxaLZ!-bOo-wwdj1fh925DYv1Qc6ErDSRl2HEgtWC-i2FtxtY,Oni_2_(Angel_Studios) -- Mega doesn't seem to like 'curl'
403,https://pcsx2.net/,Oni_2_(Angel_Studios)/Running
000-28,https://www.echeat.com/free-essay/Symbolism-in-Fahrenheit-451-by-Ray-Bradbury-29746.aspx,Oni2:Phoenix
403,https://www.telegraph.co.uk/news/newstopics/howaboutthat/3328480/Otto-the-octopus-wrecks-havoc.html,Oni2:Slaves_of_War/Neo-Biology
403,https://featuredcreature.com/from-dangerous-fluff-to-bunny-stuff/,Oni2:Slaves_of_War/Neo-Biology
403,http://www.conoserver.org/,Oni2:Slaves_of_War/Neo-Biology
403,https://www.cracked.com/article_19988_the-5-most-nightmarish-worms-planet.html,Oni2:Slaves_of_War/Neo-Biology
403,https://www.cracked.com/article_20078_5-weird-directions-human-evolution-could-have-taken.html,Oni2:Slaves_of_War/Neo-Biology
403,https://www.treehugger.com/rare-interspecies-play-observed-between-dolphins-and-whales-4857038,Oni2:Slaves_of_War/Neo-Biology
403,https://www.viator.com/tours/Rio-de-Janeiro/Niteroi-City-Tour-and-Contemporary-Art-Museum-Admission/d712-8753P7,Oni2:Slaves_of_War/Settings
403,https://www.cracked.com/article_17562_5-horrifying-apocalyptic-scenarios-that-have-already-happened.html,Oni2:Slaves_of_War/Settings
403,https://www.cracked.com/article_19678_6-abandoned-places-that-will-make-awesome-supervillain-lairs.html,Oni2:Slaves_of_War/Settings
403,https://www.peninsula.com/en/newsroom/hong-kong,Oni2:Slaves_of_War/Settings
403,https://www.nexusmods.com/games/oni,OniGalore:Community_portal
302,http://www.gnu.org/copyleft/fdl.html,OniGalore:Copyrights
403,https://www.sfgate.com/entertainment/article/WOMEN-WARRIORS-Forget-Lara-Croft-the-new-3240096.php,Press_coverage
403,https://x.com/robinalexander_/status/1872960359696376127,Restless_Souls/Glossary/Artifacts
000-92,https://www.washingtonpost.com/news/wonk/wp/2015/08/27/trump-the-bible-means-a-lot-to-me-but-i-dont-want-to-get-into-specifics/,Restless_Souls/Glossary/Artifacts
403,https://x.com/elonmusk/status/1882406209187409976,Restless_Souls/Glossary/Artifacts
403,https://www.president.gov.ua/documents/6792022-44249,Restless_Souls/Glossary/Artifacts
302,https://www.golem.de/news/kritik-an-nasa-musk-will-direkt-zum-mars-fliegen-2501-192128.html,Restless_Souls/Glossary/Artifacts
403,https://www.axios.com/2025/01/23/elon-musk-nazi-joke-adl,Restless_Souls/Glossary/Artifacts
403,https://www.axios.com/2022/05/02/mark-esper-book-trump-protesters,Restless_Souls/Glossary/Artifacts
302,https://www.golem.de/news/kuenstliche-intelligenz-grok-3-veraergert-maga-anhaenger-2505-195906.html,Restless_Souls/Glossary/Artifacts
403,https://www.luzernerzeitung.ch/kultur/debatte-das-ende-des-westens-ist-da-was-heisst-das-fuer-die-schweiz-und-europa-ld.2751339,Restless_Souls/Glossary/Artifacts
403,https://www.ndtv.com/world-news/transgender-vs-transgenic-mice-row-over-donald-trumps-animal-experiments-claim-7867258,Restless_Souls/Glossary/Artifacts
000-92,https://www.washingtonpost.com/archive/politics/1997/04/24/russia-china-sign-new-friendship-pact/896539b8-c583-44f2-8a73-095cbad1e784/,Restless_Souls/Glossary/Artifacts
403,https://www.economist.com/by-invitation/2022/03/11/john-mearsheimer-on-why-the-west-is-principally-responsible-for-the-ukrainian-crisis,Restless_Souls/Glossary/Artifacts
403,https://www.nytimes.com/2025/09/18/us/politics/trump-fcc-licenses.html,Restless_Souls/Glossary/Artifacts
000-92,https://www.washingtonpost.com/national-security/2025/09/18/trump-taiwan-arms-sales-military-aid/,Restless_Souls/Glossary/Artifacts
403,https://x.com/LAGovJeffLandry/status/2002950029494124986,Restless_Souls/Glossary/Artifacts
302,https://www.derstandard.de/story/3000000301573/putin-gab-sich-bei-seiner-jahrespressekonferenz-wieder-einmal-volksnah,Restless_Souls/Glossary/Artifacts
403,https://www.politico.com/news/2025/06/02/pentagon-greenland-northern-command-00381223,Restless_Souls/Glossary/Artifacts
303,https://link.springer.com/article/10.1007/s41748-026-01073-y,Restless_Souls/Glossary/Artifacts
302,https://www.golem.de/news/abschreckungspolitik-taiwan-will-tsmc-fabriken-nicht-von-usa-bombardieren-lassen-2305-174057.html,Restless_Souls/Glossary/de
000-92,https://www.washingtonpost.com/archive/politics/1997/04/24/russia-china-sign-new-friendship-pact/896539b8-c583-44f2-8a73-095cbad1e784/,Restless_Souls/Glossary/de
403,https://www.economist.com/by-invitation/2022/03/11/john-mearsheimer-on-why-the-west-is-principally-responsible-for-the-ukrainian-crisis,Restless_Souls/Glossary/de
403,https://acronyms.thefreedictionary.com/uwl,Restless_Souls/Reconstruction
403,https://acronyms.thefreedictionary.com/uwl,Restless_Souls/Reconstruction/Gapfilling
403,https://acronyms.thefreedictionary.com/SSOB,Restless_Souls/Reconstruction
403,https://acronyms.thefreedictionary.com/SSOB,Restless_Souls/Reconstruction/Gapfilling
000-92,https://www.washingtonpost.com/national-security/2025/08/31/trump-gaza-plan-riviera-relocation/,Restless_Souls/Research/Artifacts
403,https://x.com/MEMRIReports/status/1721097018062606708,Restless_Souls/Research/Artifacts
403,https://x.com/MedvedevRussiaE/status/1821967864947220777,Restless_Souls/Research/Artifacts
403,https://www.nytimes.com/2024/07/24/world/middleeast/gaza-war-hepatitis-polio.html,Restless_Souls/Research/Artifacts
403,https://www.researchgate.net/publication/262485473_The_Russia-China_Security_Partnership_in_the_Asia-Pacific_Region_Conjectural_and_Structural_Dimensions,Restless_Souls/Summary
403,https://www.forbes.com/sites/wadeshepard/2019/10/03/what-china-is-really-up-to-in-africa/,Restless_Souls/Summary
404,https://idw-online.de/de/attachmentdata8851.pdf,Restless_Souls/Technology
403,https://www.unrealengine.com/en-US,Restless_Souls/Wishlist
301,https://www.bungie.net/,Rights
403,https://tsdr.uspto.gov/caseviewer/assignments?caseId=75570211&docIndex=1&searchprefix=sn#docIndex=1,Rights
403,https://acronyms.thefreedictionary.com/WPS,Talk:Hasegawa
403,https://www.ixbt.com/video2/tech_ss2.shtml,Talk:Oni_Model_Extractor
301,https://www.welt.de/debatte/kommentare/plus246585502/Niedergang-Deutschland-zeigt-der-Welt-wie-man-es-nicht-macht.html,Talk:Restless_Souls/Summary
302,https://www.derstandard.at/story/3000000190426/der-nahostkonflikt-in-oesterreichs-klassenzimmer,Talk:Restless_Souls/Summary
303,https://www.bmjv.de/DE/themen/menschenrechte/menschenrechte_node.html,Talk:Restless_Souls/Summary
403,https://www.researchgate.net/figure/S-curves-for-the-established-and-disruptive-technology-Performance_fig2_4899992,Talk:Restless_Souls/Technology
302,https://de.statista.com/statistik/daten/studie/1208627/umfrage/ausbreitung-von-corona-mutationen-in-deutschland/,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/haeufiger-als-andere-modelle-chatgpt-sabotiert-bei-tests-eigene-abschaltung-2505-196561.html,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/microsoft-studie-diese-berufe-veraendert-ki-am-staerksten-2508-198747.html,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/neue-ki-architektur-was-ist-baby-dragon-hatchling-2510-201047.html,Talk:Restless_Souls/Technology
403,https://www.forbes.com/sites/mattnovak/2023/04/11/elon-musk-working-on-ai-at-twitter-despite-calling-for-6-month-pause-report/,Talk:Restless_Souls/Technology
403,https://www.forbes.com/sites/ronschmelzer/2025/10/09/samsung-ai-research-team-builds-a-tiny-model-with-big-powe/,Talk:Restless_Souls/Technology
302,https://www.derstandard.de/story/3000000302571/neuralink-will-gehirn-chips-in-serie-fertigen-operationen-bald-automatisiert,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/claude-opus-4-6-ki-findet-ueber-500-zero-day-luecken-in-open-source-software-2602-205139.html,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/soziales-netzwerk-moltbook-entpuppt-sich-als-ki-trugbild-2602-205141.html,Talk:Restless_Souls/Technology
403,https://medium.com/@aloy.banerjee30/infinite-context-length-in-llms-the-next-big-advantage-in-ai-2550e9e6ce9b,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/hackerbot-claw-ki-agent-kapert-softwareprojekte-auf-github-2603-205990.html,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/unkontrollierbares-fehlverhalten-ki-agenten-werden-zu-immer-groesserem-insider-risiko-2603-206491.html,Talk:Restless_Souls/Technology
403,https://www.unrealengine.com/en-US/blog/a-first-look-at-unreal-engine-5,Talk:UnrealOni
404,https://www.autodesk.com/products/fbx/overview,Template:AutodeskFBX
000-92,https://www.adobe.com/creativecloud/plans.html,Template:Photoshop
403,https://www.sec.gov/Archives/edgar/data/946581/0000891554-00-000145.txt,Timeline_of_development
403,https://www.sec.gov/Archives/edgar/data/946581/000112528202003845/b320556.htm,Timeline_of_development
403,https://www.fab.com/listings/ef9651a4-fb55-4866-a2d9-1b38b028f9c7,UnrealOni/ALS
403,https://www.fab.com/listings/ef9651a4-fb55-4866-a2d9-1b38b028f9c7,UnrealOni/Tutorials
403,https://www.fab.com/listings/a1fe637c-ef4d-45de-9a21-9a377d06dee1,User:Geyser/CharacterTutorialMakeHumanToUE4
EI,https://wiki.oni2.net/Special:AllMessages?prefix=&filter=modified&lang=en&limit=50,User:Iritscen/WikiMods -- EI link is necessary
302,https://m.facebook.com/groups/186656799756?refid=27,User:Samer
403,https://www.speedrun.com/oni,Videos
403,https://www.computerhope.com/jargon/w/wildcard.htm,XmlTools
END LIST
</pre>

[[Category:Wiki Support]]

Restless Souls/Wishlist

2026-04-13T15:14:38Z

Iritscen: link fix

The main page for [[UnrealOni|'''UnrealOni''' can be found HERE]].

==Oni 2 game==
===Engine===
If we had a real option to create an Oni 2 with modern engine I would root for Unreal Engine 4.

It works on PC and Macs and it is free for non-commercial projects.

There's a big community, documentation and tutorials.

If the demo is going to be extended it would be better to work with original/free content from begin with, sparing us IP concerns. Old content is meant as placeholders.

It supports weapon and h2h combat. Of course Oni's unique fighting style would have be re-written. But everything else should be supported by the engine. Particle, trigger volumes, wide environments, details characters. What else could you wish for?

===Features===
Besides new levels, characters and story... How about new gameplay elements? Since the Daodan is an core element of the story it would be shame not to make use of it. It would add a strategical component and adds to the replay value.

Since the bio aspects would be hard to reinvent for a spiritual successor, one might more concentrate on good 'ol nanotech. "Omega days"? "Iron demons?"

====Primary Daodan traits====
* Healing (stopping a heavy bleeding and recovery speed)
* Power (stronger attacks, throwing or using heavy objects and enemies as weapons (e.g. using a skriker as Nunchaku with maxed out power))
* Speed (faster attacks, running, reflexes (dodging, counters))
* Adapting (mutation speed (biological computing by means of "Oni cluster" cells))
* Mechanical resistance (adaptions to pressure and kinetic damage (e.g. graphene enhanced cells))
* Physical resistance (VDG, plasma, phase stream projectors (electric isolation))
* Chemical resistance (acid, poison (lead bullets, mercury bow bullets))
* Biological resistance (screamer cells, infections by untreated wounds)
* Thermal resistance (extreme heat - fire, extreme coldness)
* Nuclear resistance (depleted uranium ammunition and surviving contaminated areas)

Basically you can "tank up" against weapons and don't need to worry about ammo.

To keep balance you could add more dangerous weapons as the game progresses.

====Secondary Daodan traits====
The Daodan is not almighty. It has certain weaknesses you should watch out for.

* Your Daodan abilities depend on Daodan biomass which means you can either unlock new abilities or enhance existing ones. And there's a limit to your abilities, because your cell count is limited.
* There should be one or two "ultimates" in Imago stage that depend on your evolution.
* Your number of Daodan cells depend on taken damage and recovery that happen in the last level.
* But too much damage can cause too high growth rates (temporary sudden pain and fever resulting in moments of reduced vision, shooting accuracy, "getting blocked" rate) or it simply kills you because you exceeded the maximal healing capacity of the daodan.
* Sytropin can help you in lowering growth rates. Be aware of increasing drug resistance as the game progresses.
* Reverting an existing mutation takes more "work" than establishing a new one. Basically your course of action is directed evolution.

====Improved movement set and h2h====
* prone mode
* sneaking at walls and through vent channels
* throw foes over obstacles
* extend h2h with Parkour elements (e.g. wall jump connectable to a flying knee)
* use pickable objects as weapons (either throwable or usable as a club)
* ledge grab (not a must-have)
* swimming (not a must-have)

====Miscellaneous====
* controllable drones, robots, mechs, vehicles
* dynamic lighting, wearable lights (flash lights) for dark environments
* temperature affects characters (not a must-have)
* emotions affects characters (not a must-have, rage enhances Daodan powers to a limited degree)

==Oni 2 game tech demo with Unreal Engine 4==
[[Image:UE4_appetizer.jpg|400px|right|thumb]]

===Goal===
There is big skepticism inside the community whether an Oni-like game can be accomplished with the Unreal 4 engine.

Therefore I seek to create a technical demo to proof feasibility of such project.

The availability of XML documentation for Oni 1 seem to have speeded up mod creation so I will pursue a similar route for this project. The documentation written here in the process shall serve as measure to lower the learning curve of other modders (or then programmers / content creators).

Since EdT joined I feel very confident that a community-based Oni 2 is possible. --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 23:37, 20 February 2018 (CET)

===Stuff that is probably coverd by the tech demo===
Everyone could pickup one of these points and investigate how to implement it.

If successful that person would write down a mini-tutorial here on OniGalore so others could see progress and learn from the documentation to perhaps pickup the next, somewhat more complex point.

There could be project files on a cloud drive as long as there aren't too many people involved (otherwise a SVN). New files could be uploaded into a revision folder. Users could test the changes and then update the project in the cloud.

:V - video
:T - tutorial
:D - documentation

Features the demo should include:
* two levels (to test normal level load routine and level streaming [https://dev.epicgames.com/documentation/en-us/unreal-engine/level-streaming-how-tos?application_version=4.27 (T)])
* skydome [https://www.youtube.com/results?search_query=ue4+skybox (V)]
* lightning
* main menu
** So far I failed to add background music. This gave rise to the idea of having an own level for the main menu where you can spawn ambient music. Muro or another character could be previewed with their current movement set and equipment. Shooting the camera would make the game quit. This will be useful when the enemy takes over this HQ AI and he needs to ''shut it down''. "Mission failed." "Screw you!" Pressing the "V" key would allow you to go into your training room or HQ testing new moves or doing investments.
* HUD ("circular" health bar, item slots)
** [https://web.archive.org/web/20181006203834/https://wiki.unrealengine.com/Unreal_Motion_Graphics_(UMG)_UI_-_Inventory_Tutorial_Playlist (T)]
* background music [https://dev.epicgames.com/documentation/en-us/unreal-engine/WorkingWithMedia/Audio/?application_version=4.27 (D)] [https://dev.epicgames.com/documentation/en-us/unreal-engine/playing-animations-and-sounds?application_version=4.27 (T)] [https://www.youtube.com/results?search_query=ue4+background+music (V)]
* save game state
* read game state
* text pages for diary, etc.
* fbx import of old objects
** static
** pushable
** animated
* animated objects with collision box to stand on
* objects that can be thrown
* CJBO equivalents (characters, console, door, trigger (laser), trigger volume, ...)
* compass (objective)
* LSI
* FBX import and usage of old characters
*: ...
*: [https://www.youtube.com/watch?v=7vtdJeRscAQ adding animations (V)]
** combining character parts to one model
** rigging the model
*** minimum TRAC-TRAM integration I (walk cycle and idle)
*** prone mode
* keyboard and mouse controls
* functional animations
** character h2h (force-sensitive) (a.k.a physical animation component)
**:<nowiki>https://www.youtube.com/watch?v=2AapLKCntvc (V)</nowiki (dead link)
** character h2h
**:[https://www.youtube.com/watch?v=2QakhD03d9M (V)]
** hit reaction
**:<nowiki>https://www.youtube.com/watch?v=f9z7N50wu7s (V)</nowiki> (dead link)
**:<nowiki>https://www.youtube.com/watch?v=3lPSKA0hpdc (V)</nowiki> (dead link)
** minimum TRAC-TRAM integration II (combat idle, punch, kick, block, half-damage, unblockable, super)
** minimum TRAC-TRAM integration III (throws)
** minimum TRAC-TRAM integration IV (throwable objects)
** overlay animations
*** aiming
*** holstering
*** h2h weapons
** ledge climbing
**:[https://www.youtube.com/watch?v=4yjcwZLQqlE (V)]
**:[https://www.youtube.com/watch?v=H2xqW7lKkyw (V)]
**:[https://www.youtube.com/watch?v=H2xqW7lKkyw (V)]
**:[https://www.youtube.com/watch?v=fLLKgc0LDqc (V)]
**:[https://www.youtube.com/watch?v=ABgcv21uivU (V)]
** cover
**:[https://www.youtube.com/watch?v=TzL7YDEPej0 (V)]
**:[https://www.youtube.com/watch?v=efKH9ugTzLM (V)]
**:[https://www.youtube.com/watch?v=-oGDDIbvQ1c (V)]
** cover (AI)
**:<nowiki>https://www.youtube.com/watch?v=nh30nt0wSjs (V)</nowiki> (dead link)
* healing by hypo and level areas
* particle (attachable to env, weap, char)
** weather (rain, snow, wind, dust, lightning)
* two weapons
* ammo type: ballistic ammo
* ammo type: energy cell
* AI
** patrol paths and pathfinding
** recreation of basic ONCC properties (incl. shooting inaccuracy)
** spawn AI
**: [https://www.youtube.com/watch?v=hVdNji_TtXw (V)]
* h2h-specific animations
** startle
** stun
** knockdown
** blowup
** got hit animation
*** got hit animation (CBPM-specific)
** throws mechanics
** follow me command, stop command
** alarm behavior
* CBPM-specific bullet hit behavior
* add effects via ONIE-TMBD-MTRL mini complex
* driving a truck
* BSL equivalent ("Blueprint")
* team support (easy methods to make project contributions)
* levels of difficulty
** Easy: -20%? health for foes
** Normal
** Hard: +20%? health for foes, foe class upgrade?
** Extreme: shorter reaction times of AI ("killmequick")
::: powerups on the ground can be destroyed quite easily by projectiles or heavy h2h attacks
:::: ammo -> blast damage and fire
:::: cell -> blast damage and stun effect
:::: hypo -> little blast damage and a cloud of healing gas
:::: shield -> major blast damage
:::: invis -> blinding
:::: LSI -> mission failed ?
** YOLO: Extreme mode plus when player dies he cannot reload that savegame. He has to restart at level 1.
** YOLO +: YOLO plus the games has never been played before. first play after installation. This is a secrete achievement.

Besides from what all should be tested and made, here's a groundwork tutorial: [https://dev.epicgames.com/documentation/en-us/unreal-engine/third-person-template?application_version=4.27 Blueprint 3rd Person Game]

It touches pretty much stuff in those 4 hours: getting a character into a level, setting him up as player, the controls, animations cycles, animation blending, animation overlay and attaching physics

You could probably split this thing into three parts: learning the basics, adding stuff from the long feature list (those not already covered by the basics), and tweaking animations controls to behave like Oni 1

===Practice notes===
Now then if you want to try this do the following.

# For content creation you maybe want to use [[Blender]] since it is free and available for PC, Mac and Linux.
# Install Visual Studio 2017 Community (to write C++ later)
# Register at https://www.unrealengine.com/en-US, while logged in you can download the installer from the upper right corner. (Blue button "DOWNLOAD".)
# Start Installer and download Unreal Engine 4.17.1 (It will be about 6 GB. It extracts to 17 GB.)
# Learn viewport navigation from the yellow flashing blue hat icon.
# Then continue with the videos of the [https://dev.epicgames.com/documentation/en-us/unreal-engine/third-person-template?application_version=4.27 3rd Person Game tutorials.]

===Tutorial summary: 3rd Person Game===
Incomplete notes...

It seems like there aren't scripts anymore. Blueprint is Visual scripting, you are working with visualized functions, objects, etc. It's more what you can do with the C++ code which also gets compiled.

FBX can contain data for TRBS, TRIA, TRAC, multiple TRAM, materials, textures.

;Video ?
:Blend Parameter now on the left side.

Keybinding (equivalent to key_config.txt)

Input to move binding (equivalent to StNA)

Support for Keyboard, Mouse (and inverted control), Gamepads and touch

Player camera settings editable (distance holder named "Spring Arm")

;Animations
:Animation cycles (TRAM - shortcuts)
:Transition rules (similar to those in TRAM headers <FromState>, <ToState>)
:Blend Space is an heavily enhanced version of <Interpolation>
::The animation gets adapted in length AND rotation values. When properly used, transition are nothing less than perfect.

;Video 8
:Anim Preview Editor is on the right now
:Event Graph: right-click for context menu to add missing "Try Get Pawn Owner"

;Video 12
:Character Blueprint is sort of an ONCC. They aren't exactly equal.
:: It misses seeing, hearing, weapon skills and more. It has settings for jump, "air control", LOD, shadow, few CHAR events, collision box, tags, ONIE related stuff

EventGraph -> Component -> Mesh -> e.g. Get Material Index

[...]

===Selected knowledge===
Whenever you edited a Blueprint: compile (F7) and save (Ctrl + S).

====Code management====
In order to sort things and avoid code duplication I'm trying to spit things for now the following way:

* game related code such as a level loading function and menu references goes to the '''Game Instance'''
* level related code such as a Slash Screen function goes to the '''Level blueprint'''
* player related code such as keyboard inputs go to a custom '''Player Controller''' (changeable in the Game Mode)
* AI related code goes to the '''ONCC component blueprint'''

====Game instance====
When we store information in an game instance it won't disappear after loading the next level.

Let's say there is a menu button or hotkey in a pause menu widget to disable hint texts.

Using variables in a widget is a dead end. They are destroyed as soon as we close the widget.

We could save our choice of showing the hint text in the level blueprint but as soon as we proceed to the next level the hint text would be shown again.

So, we go up in the hierarchy and store the information in the game instance.

To make the information really persistent (between game starts or when loading a save game) all we would need to do is saving the information from the game instance to a save game.

====Main func====
[[Image:UE4_Level_Blueprint_Event_BeginPlay_as_main_func_replacement.png|400px|right|thumb]]
Equivalent to Oni's main func can be found / created in the "Level Blueprint".

Blueprints > Open Level Bluprints

Right-click to open context menu. Search for and add node "Event BeginPlay"

At this point it's empty.

Maybe for testing or learning purposes add another node: "Play Sound 2D".

Change its Sound source to a Sound Cue you made.

Connect the nodes Event BeginPlay with Play Sound 2D.

=====Blueprints=====
You can copy-paste blueprints and share them with others in plain text.

Example of an exit function. (In the actual game use Escape key to exit.)
<pre>
Begin Object Class=/Script/BlueprintGraph.K2Node_InputKey Name="K2Node_InputKey_0"
InputKey=Escape
NodePosX=864
NodePosY=-832
NodeGuid=99076AC847F4C36E70B54AA78927F135
CustomProperties Pin (PinId=92DEBC9A43D657DB995617849A0B7927,PinName="Pressed",Direction="EGPD_Output",PinType.PinCategory="exec",PinType.PinSubCategory="",PinType.PinSubCategoryObject=None,PinType.PinSubCategoryMemberReference=(),PinType.PinValueType=(),PinType.ContainerType=None,PinType.bIsMap=False,PinType.bIsSet=False,PinType.bIsArray=False,PinType.bIsReference=False,PinType.bIsConst=False,PinType.bIsWeakPointer=False,LinkedTo=(K2Node_CallFunction_44 BC9E715842362EDD413EF8A39B14F625,),PersistentGuid=00000000000000000000000000000000,bHidden=False,bNotConnectable=False,bDefaultValueIsReadOnly=False,bDefaultValueIsIgnored=False,bAdvancedView=False,bOrphanedPin=False,)
CustomProperties Pin (PinId=3CDB2A9D40427A0CCFDABF8F090CE41F,PinName="Released",Direction="EGPD_Output",PinType.PinCategory="exec",PinType.PinSubCategory="",PinType.PinSubCategoryObject=None,PinType.PinSubCategoryMemberReference=(),PinType.PinValueType=(),PinType.ContainerType=None,PinType.bIsMap=False,PinType.bIsSet=False,PinType.bIsArray=False,PinType.bIsReference=False,PinType.bIsConst=False,PinType.bIsWeakPointer=False,PersistentGuid=00000000000000000000000000000000,bHidden=False,bNotConnectable=False,bDefaultValueIsReadOnly=False,bDefaultValueIsIgnored=False,bAdvancedView=False,bOrphanedPin=False,)
CustomProperties Pin (PinId=02AB461F46584F140257A5BC03E90865,PinName="Key",Direction="EGPD_Output",PinType.PinCategory="struct",PinType.PinSubCategory="",PinType.PinSubCategoryObject=ScriptStruct'/Script/InputCore.Key',PinType.PinSubCategoryMemberReference=(),PinType.PinValueType=(),PinType.ContainerType=None,PinType.bIsMap=False,PinType.bIsSet=False,PinType.bIsArray=False,PinType.bIsReference=False,PinType.bIsConst=False,PinType.bIsWeakPointer=False,PersistentGuid=00000000000000000000000000000000,bHidden=False,bNotConnectable=False,bDefaultValueIsReadOnly=False,bDefaultValueIsIgnored=False,bAdvancedView=False,bOrphanedPin=False,)
End Object
Begin Object Class=/Script/BlueprintGraph.K2Node_CallFunction Name="K2Node_CallFunction_44"
FunctionReference=(MemberParent=Class'/Script/Engine.KismetSystemLibrary',MemberName="QuitGame")
NodePosX=992
NodePosY=-832
NodeGuid=F926936F4422AC469B38B3B6EBAB12BE
CustomProperties Pin (PinId=BC9E715842362EDD413EF8A39B14F625,PinName="execute",PinToolTip="\nExec",PinType.PinCategory="exec",PinType.PinSubCategory="",PinType.PinSubCategoryObject=None,PinType.PinSubCategoryMemberReference=(),PinType.PinValueType=(),PinType.ContainerType=None,PinType.bIsMap=False,PinType.bIsSet=False,PinType.bIsArray=False,PinType.bIsReference=False,PinType.bIsConst=False,PinType.bIsWeakPointer=False,LinkedTo=(K2Node_InputKey_0 92DEBC9A43D657DB995617849A0B7927,),PersistentGuid=00000000000000000000000000000000,bHidden=False,bNotConnectable=False,bDefaultValueIsReadOnly=False,bDefaultValueIsIgnored=False,bAdvancedView=False,bOrphanedPin=False,)
CustomProperties Pin (PinId=308342D741456EB59283E7A1B0C7183D,PinName="then",PinToolTip="\nExec",Direction="EGPD_Output",PinType.PinCategory="exec",PinType.PinSubCategory="",PinType.PinSubCategoryObject=None,PinType.PinSubCategoryMemberReference=(),PinType.PinValueType=(),PinType.ContainerType=None,PinType.bIsMap=False,PinType.bIsSet=False,PinType.bIsArray=False,PinType.bIsReference=False,PinType.bIsConst=False,PinType.bIsWeakPointer=False,PersistentGuid=00000000000000000000000000000000,bHidden=False,bNotConnectable=False,bDefaultValueIsReadOnly=False,bDefaultValueIsIgnored=False,bAdvancedView=False,bOrphanedPin=False,)
CustomProperties Pin (PinId=2EF7797B47E79A543E0AEAB9F7914F98,PinName="self",PinFriendlyName=NSLOCTEXT("K2Node", "Target", "Target"),PinToolTip="Target\nKismet System Library Object Reference",PinType.PinCategory="object",PinType.PinSubCategory="",PinType.PinSubCategoryObject=Class'/Script/Engine.KismetSystemLibrary',PinType.PinSubCategoryMemberReference=(),PinType.PinValueType=(),PinType.ContainerType=None,PinType.bIsMap=False,PinType.bIsSet=False,PinType.bIsArray=False,PinType.bIsReference=False,PinType.bIsConst=False,PinType.bIsWeakPointer=False,DefaultObject="/Script/Engine.Default__KismetSystemLibrary",PersistentGuid=00000000000000000000000000000000,bHidden=True,bNotConnectable=False,bDefaultValueIsReadOnly=False,bDefaultValueIsIgnored=False,bAdvancedView=False,bOrphanedPin=False,)
CustomProperties Pin (PinId=E5668388474ABD86D0C505AE22C65ECB,PinName="WorldContextObject",PinToolTip="World Context Object\nObject Object Reference",PinType.PinCategory="object",PinType.PinSubCategory="",PinType.PinSubCategoryObject=Class'/Script/CoreUObject.Object',PinType.PinSubCategoryMemberReference=(),PinType.PinValueType=(),PinType.ContainerType=None,PinType.bIsMap=False,PinType.bIsSet=False,PinType.bIsArray=False,PinType.bIsReference=False,PinType.bIsConst=False,PinType.bIsWeakPointer=False,PersistentGuid=00000000000000000000000000000000,bHidden=True,bNotConnectable=False,bDefaultValueIsReadOnly=False,bDefaultValueIsIgnored=False,bAdvancedView=False,bOrphanedPin=False,)
CustomProperties Pin (PinId=8E90ECF5471A7E7EA51527B95CA238F9,PinName="SpecificPlayer",PinToolTip="Specific Player\nPlayer Controller Object Reference\n\nThe specific player to quit the game. If not specified, player 0 will quit.",PinType.PinCategory="object",PinType.PinSubCategory="",PinType.PinSubCategoryObject=Class'/Script/Engine.PlayerController',PinType.PinSubCategoryMemberReference=(),PinType.PinValueType=(),PinType.ContainerType=None,PinType.bIsMap=False,PinType.bIsSet=False,PinType.bIsArray=False,PinType.bIsReference=False,PinType.bIsConst=False,PinType.bIsWeakPointer=False,PersistentGuid=00000000000000000000000000000000,bHidden=False,bNotConnectable=False,bDefaultValueIsReadOnly=False,bDefaultValueIsIgnored=False,bAdvancedView=False,bOrphanedPin=False,)
CustomProperties Pin (PinId=FDCA728E4AFA5A2ABEA52A88B5B79FEA,PinName="QuitPreference",PinToolTip="Quit Preference\nEQuitPreference Enum",PinType.PinCategory="byte",PinType.PinSubCategory="",PinType.PinSubCategoryObject=Enum'/Script/Engine.EQuitPreference',PinType.PinSubCategoryMemberReference=(),PinType.PinValueType=(),PinType.ContainerType=None,PinType.bIsMap=False,PinType.bIsSet=False,PinType.bIsArray=False,PinType.bIsReference=False,PinType.bIsConst=False,PinType.bIsWeakPointer=False,DefaultValue="Quit",PersistentGuid=00000000000000000000000000000000,bHidden=False,bNotConnectable=False,bDefaultValueIsReadOnly=False,bDefaultValueIsIgnored=False,bAdvancedView=False,bOrphanedPin=False,)
End Object
Begin Object Class=/Script/UnrealEd.EdGraphNode_Comment Name="EdGraphNode_Comment_7"
NodePosX=816
NodePosY=-880
NodeWidth=490
NodeHeight=230
NodeComment="Exit"
NodeGuid=92DC2D0B492925CE0957EB865A535520
End Object
</pre>

====Cameras====
=====Third Person View=====
Right after testing the vanilla Third Person Character template in UE you will notice that the camera can be fully moved around the player character.

In Oni the orbiting is limited. IMO this added to Oni's unique vibe. Hand-to-hand combat felt more realistic because you can't really see behind your back.
[[Image:UE4_Oni-like_Third_Person_View.png|400px|right|thumb]]

;Part I
To reproduce the same behavior you have to silent the mouse controls on some conditions.

In theory the core function would hold these parts:
# check for camera's rotation relative to the character (if rotation exceeds limits the input gets nullified)
# check for left turn mouse rotation to get out of camera's right side maximum
# check for right turn mouse rotation to get out of camera's left side maximum

In practice I tweaked the facing value so that is always below 180 degrees (e.g. -270 becomes 90). That way following code only needs the later 2 of 3 checks.

<nowiki>https://1drv.ms/t/s!Asn4fV_yvODigUAfQ-spWYnvi1pV</nowiki> (dead link)

;Part II
During the BeginPlay Event you can set nodes to limit the camera pitch (up and down movement).

<nowiki>https://1drv.ms/t/s!Asn4fV_yvODigT8xJ35jXaxFlD35</nowiki> (dead link)

;Part III
Oni's second unique feature of its Third Person View is the look mode. It shifts the mouse rotation control from the body to the head.

By that you can look to the side while keep running forward.

;Part IV
The limited mouse controls feel clumsy as long as the character can turn around by pressing the "walk backwards" key.

We need changes so that the character actually walks backwards and does NOT turn around.

====Music====
Sound files extracted with OniSplit aren't compatible, you have to convert them to 16-bit PCM wav again. Audacity works well for that.

The OSBD properties can be recreated by turning the sound into a cue and then adding BluePrint logic to it.

UE4 is unable to seamlessly loop sound parts which is a requirement for playing permutations. However, almost every Oni modder imports complete soundtracks, so it's not that much of a loss.

[[Image:UE4_SoundCue.png|400px|right|thumb]]
Example:

Import two wav files to the content browser. Right-click one to "Create Cue". Double-click that created Cue.

Add "Wave Player", "Enveloper", "Random", and "Looping" nodes.

Set a wave file for each new Wave Player.

Select all and press "C" to group them in a comment. That way you better remember what it does and can move the stuff around all at once.

====Meshes====
[[Image:UE4_StaticOniMesh.png|400px|right|thumb]]
Since '''OniSplit outputs 3D meshes mostly as Collada (DAE)''' - and few as Wavefront (OBJ) - you cannot transfer objects from Oni to UE4 directly.

'''Creating FBX'''

You either need the '''[https://aps.autodesk.com/developer/overview/fbx-converter-archives FBX converter]''' or [[Blender]] to convert the Collada to FBX file format.

=====Reimports (Furniture)=====
The CJBO files include a furniture file. But this can be mostly garbage - or empty. Instead the furniture is baked into AKEV. The meshes have flags which allow OniSplit to extract these objects again.

Onisplit -extract:dae level1_Final level1_Final/AKEV*.oni

In the past this created a bunch of DAE files:
EnvWarehouse_bnv.dae
EnvWarehouse_cons.dae
EnvWarehouse_door.dae
EnvWarehouse_furn.dae
EnvWarehouse_env.dae
EnvWarehouse_env_markers.dae
EnvWarehouse_script_X.dae
EnvWarehouse_trig.dae
other.dae

At some point _furn might be extracted as part of _env. The cause for this is unknown.

'''Importing FBX'''

The scaling of OniSplit DAE files is too small. '''Use a factor of 10 to fix it.''' If we wanted to do a mass-import we would need a tool or a Blender script that alters the DAE (XML) data in advance. (Or maybe some python magic for the UE4 editor can help here too.)

Warehouse boxes from level 1 (and others objects) do only have 5 sides. Writing a macro for XSI/Blender COULD possibly add a 6th side automatically.

'''Placing individual furniture assets into levels'''

After dragging the assets into the level we need to reposition them all to 0, 0, 0 as the pivot point is used inside the FBX to save their relative position the level.

'''Optional: Asset library'''

Besides re-imports of furniture, objects could be added to a new asset library. For the later case [https://www.youtube.com/watch?v=N1h5mMviSKs resetting the pivot point of meshes (V)] can be useful.

'''Object instances'''

If we would import an entire furniture file to UE4 it would create the objects as they are: for each object one mesh. That is inefficient as many objects are simply duplicates, although textures and materials are created only once.

To bypass this inefficiency scripting is needed.
U_freight_wht_long_7412
U_freight_wht_long_7413

Ending numbers such as "_7412" seem to be the CJBO id. (See [[XML:AKEV#AGQG|AGQG <ObjectId>]])

For example a script would export the furniture "U_freight_wht_long" and save the position of all instances to a text file. UE4 would need the import the FBX once and read that text file to place them all in the level. The problem is that rotations are all reset to 0. It might be possible to define some kind of reference and read the first vertex of each object, reading the different rotation and saving this to the text file as well.

A text file (txt/csv/json/xml) might store this data:
<asset name="U_freight_wht_long" cjboId="7412" pos="x,y,z" rot="x,y,z" />
<asset name="U_freight_wht_long" cjboId="7413" pos="x,y,z" rot="x,y,z" />

If we import a level 1 '''furniture file as it is''', it creates 366 meshes, 66 textures/materials, resulting in a total '''498 "uassets" 45 MB''' in disc space. The process takes all cores to get the job done, first import, about one or two minutes on a modern CPU.

'''Some possibilities of preparing FURN'''

{| class="wikitable"
|-
! Method !! Notes
|-
| XSI scripting || considered "deprecated" by community
|-
| Standalone python || splitting DAE (mostly XML)
|-
| Blender scripting || -
|-
| UE4 editor scripting || importing XML/CSV list for instances of meshes
|}

'''Adding door locklight particle to assets?'''

Some objects such as door locklight are meant to have particles. Oni happened to store some particle in '''ONLV''', however the door locklight have been moved to the '''CJBO particle collection'''. That's something to keep in mind. If we want to add particle to the static meshes we would need to turn them into full-fledged blueprint assets.

ONLVlab.xml (locklight particle example)
<ENVP id="6">
<Particles>
<ENVPParticle>
<Class>locklight</Class>
<Tag>lock1_locklight01</Tag>
<Transform>-1 -4.559326E-08 -1.34529964E-05 1.34529973E-05 -2.03512554E-05 -1 4.53194744E-08 -1 2.03512554E-05 643.527 13.0480433 -275.8361</Transform>
<DecalScale>1 1</DecalScale>
<Flags></Flags>
</ENVPParticle>

'''Green collision boxes'''

Although the green collision boxes are imported with transparency they are not completely invisible. We could either:
* remove the collision box (scripting)
** then tick checkbox in FBX import dialog "Auto Generate Collision"
* modify the texture "_marker_barrier"
* modify the material "MaterialLibrary__marker_barrier"
** change Opacity from Texture Sample to a scalar or vector 3 node (0,0,0 for black = fully transparent)

Since in Oni the '''green collision box is meant for characters how do we deal with particle collisions?'''

=====Custom collision boxes=====
In an 3D editor create collision objects and name it beginning with "UCX_". Save objects and collision objects together in one FBX file.

On import, uncheck "Auto Generate Collision".

:https://www.youtube.com/watch?v=YxVFChB3oxY

=====Reimports (AKEV core geometry)=====
'''IIRC, Edt said you need to carefully pick the options while importing''' core geometry as rooms with otherwise open doors can be blocked for character locomotion.

For destructive environment / Chaos system a modular core geometry might be better. However, this would require scripting again to split geometries apart.

In XSI we can relative easily see where an object has "polygon clusters" and associated textures. (Select a polygon cluster in wireframe mode while having an Image panel open.)

Whether this can be an alternative to Edt's workflow only major '''testing''' can show whereby the geometry is extracted as usual...

Onisplit -extract:dae level1_Final level1_Final/AKEV*.oni

... and loaded into an 3D editor ...

EnvWarehouse_env.dae

A rough splitting could be done by looping over the polygon clusters

' XSI (VBS) scripting
for each n in selection(0).activeprimitive.geometry.clusters
logmessage (n.name)
next

Loop content:
' basic test with Polygon75 instead of n.name
SelectObj "world.polymsh.cls.Polygon75"
SelectMembers "world.polymsh.cls.Polygon75"
' poly arg can be blank, in that case active selection is taken
' ExtractFromComponents "ExtractPolygonsOp", "world.poly[12653-12730]", "polymsh_extracted", , siPersistentOperation, siKeepGenOpInputs
ExtractFromComponents "ExtractPolygonsOp", , "polymsh_extracted", , siPersistentOperation, siKeepGenOpInputs

After the level has been broken down into pieces it could be save as DAE and then converted to FBX.

'''Baked-in furniture'''

At unknown constellation OniSplit outputs the "_env" file with furniture from level one (Syndicate Warehouse). This needs double-checking. Is a newer OniSplit or .NET/Windows 10 version to blame?

====Sockets====
You can't socket static meshes. Set them to be "movable".

For now each socket will need its own bool variable to keep track whether it is in use or not.

Problem: when we use this node "get overlapping actors" then also actors stored in sockets will be counted. We would need to subtract the ones from the others. To differentiate the items we could check for a new variable "UsedInSocket". If the number is higher than -1 we can subtract it from the overlapping items because we already have this one collected.

====Powerups====
Tested in 4.18

If powerups don't spam the area they should fall to the ground after use. They should be throwable and kickable to attract the attention of foes.

Maybe there should be a weight penalty to motivate h2h combat. As less items you carry around as faster, powerful and agile you are. Reminded to Ultra saiyan vs Super saiyan?

'''Done stuff'''
* All powerup "glowtex" textures has been recreated in higher resolution.
* Pickup '''materials use emissive color''' to be actual "glowtex".
* Pickup event executes a '''preflight''' to check for valid objects. For example it will determine whether your pickup slots for hypos are all full or not. In a second step only one of the valid pickups is added to the inventory.
* Slots in the character skeleton will be used for further experiments. Pickups will be stored in belt and chest pockets. (Short one-hand weapons (e.g. pistols) are going to be holstered at the legs while rifles are put on the back.)
* Powerups in sockets are scaled down and their glowtex becomes disabled.

'''Possible improvements'''
* If powerups use the same names for their inner components (TV, glowtex plane, item mesh) then the code could maybe be simplified with an "interface blueprint" which take some inputs and gives them to all powerups that are bound to that interface. That would be useful when adding more items and weapons.

=====Glowtex functionality=====
In Powerup BP: Custom event with boolean input parameter

Other nodes:
:Set Visibility (New Visibility) (target: glowtex Plane object)
:Static Mesh Component-> AddLocalOffset
:Powerup Item -> Add local Rotation, Set World Scale 3D

======Swappable Glowtex======
In order to indicate ammo state of weapon a dynamic material can be used.

<gallery>
Image:DynamicMaterial_GlowTex.png|right-click texture node to turn it into a parameterized node
Image:DynamicMaterial_TextureSwapping_GlowTex.png|code to changed texture at runtime
Image:DynamicMaterial_GlowTex_InGame.png|ingame result
</gallery>

=====Hyposprays=====
'''Object creation'''

In this attempt the glow texture was applied to a plane that is attached to the hypo mesh. Right now the actual hypo mesh is just a placeholder made of a cuboid with green ellipses. The transparency seemed to make it darker than expected so I added some input to the material's emissive color. See gallery below.

<gallery>
Image:M_HypoGlow_docu.png|hypo material blueprint
Image:Hypo_Blueprint.png|hypo object blueprint
Image:Hypos_InGame.jpg|ingame result
</gallery>

'''Functionality implementation'''

In the following there is code that let's you pickup Hyposprays (1 + 2) and use them to regain health (3 + 4).

Caution: This script is different from the others as the pickup key press event is located in the level blueprint. Normally key press events are found in the character blueprint. We will probably want to change that in a future version though I don't know how yet. --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 21:03, 16 December 2017 (CET)

If you add a trigger volume to your hypospray object it will act like a new collision box. This can be used to adds some tolerance to the pickup distance. Otherwise the character has to be not just really close but to actually overlap the object.

<gallery>
Image:UE4_Pickup_Hypo.png|Press key to pickup hypo (Code: <nowiki>https://1drv.ms/t/s!Asn4fV_yvODigUSQY6R4bhXJqRFi</nowiki>, dead link)
Image:UE4_Add_Hypo_to_inventory.png|Adds hypo to inventory (Code: <nowiki>https://1drv.ms/t/s!Asn4fV_yvODigUFiFR2WCYIsvnl0</nowiki>, dead link)
Image:UE4_Apply_Hypo.png|Press key to apply hypo (Code: <nowiki>https://1drv.ms/t/s!Asn4fV_yvODigUPgtVd9c21Szk68</nowiki>, dead link)
Image:UE4_Add_Hypo_Health.png|Increases health via hypo (Code: <nowiki>https://1drv.ms/t/s!Asn4fV_yvODigUIEKdkZj6rFdo1o</nowiki>, dead link)
</gallery>

Youtube: <nowiki>https://youtu.be/y4sxRP-GrVQ</nowiki> Oni UE4 Test #2 - picking up hyposprays and using them (dead link)

'''Todo'''
* new hypo object mesh
* pickup animations (kneel and take, take, "roll-take")
* condition to prevent pickup with certain animations
* new sounds ("cannot pickup more", "usage")
* health bar interaction
** flashing animation
** start red health area with a higher health value
** improve code where HypoRegenerationRate adds in to avoid rounding errors

====HUD====

=====Health bar=====
Tested in 4.18

Observation from Oni 1 vanilla health bar. If base health is 200 points...

* remaining health is flashing at 60 points every 2s one time
* remaining health is flashing at 1 point every 1s two times
* critical health sound loop at 39 points (minimum sound volume)
* critical health sound loop at 1 point (max. sound volume)
* health drain animation from 200 to 1 health points takes 5s
* health gain animation speed is determined by [[XML:ONCC#.3CInventoryConstants.3E|HypoRegenerationRate in ONCC]]
* overpower health gain animation has an overpower sound of an approximate volume of 75% while overpower sound is played at 100% volume once overpower gain ended and drops again

'''Health calculation'''

An applied hypo gives you points equal to your full normal health health. At this point of time these points should be considered a "potential" because they aren't multiplied yet with hypo factors and can increase or decrease by additional healing and damage events.

As long as you regenerate normal health you regenerate from your potential multiplied by 0.25 (Oni 1 default).

As soon as you reach overhealth you multiply one point of potential by 1 (Oni 1 default).

Let's say your maximum health is 1000 and with overhealth you are at 2000.

Taking 2 hypos at health 750 will regenerate you 250 points of normal health and then - because reaching overhealth - you get another 1000 points. So taking 2 hypos at 750 health points will let you reach 2000.

A calculation with "potential" give you the advantage to stack hypos more easily.

'''Color mapping'''

[[Image:DynamicHealthBarMaterial.png|300px|right|thumb|health bar material where color, shape and progress merge]]
[[Image:HealthBarColorZoneControl.png|300px|right|thumb|integrating a color zone on the health bar]]

UE4's progress bar has a fixed range of 0 to 1. In order to realize overpower values (float 1.0 to 2.0) we have to scale everything down to fit into a 0 to 100 percentage range.

If we think of the different colors as milestones on a road whereby each milestone is named red, yellow and so on then each two stones span their own area of interpolated colors. So for UE4's "Lerp (LineraColor)" we would will need several alpha ranges, always float values from 0 to 1.

'''Health mapping'''

Health and overhealth points have different densities which results in different grow speeds on the artwork.

To recreate a similar behavior we can let the normals health points fill the health bar with a speed of 1.5 while overpower is the sum of normal health * 1.5 plus health over 100% * 0.5. Since the health bar isn't a full circle we tweaking the second factor to about 0.44.

'''Animations'''

* Anywhere from 0 to 20% health the bar is flashing to indicate damage.
* While regenerating the health bar is slowly increasing while a transparent area indicates how much the regeneration will be. That zone is color-interpolated on current health.
* Taken damage is indicated by instantly dropped health while a transparent area is ''melting'' to the new health value.

So, both - present and past/future health - use animations.

To deal with the transparent areas it might be the easiest to add another object to the health bar. In total we have then three: a frame texture, a "future/past health" material, and a "present health" material.

How to increase values over time? It looks like "timeline" don't have inputs for start and end time and timers don't work in character BP. Even loops are problematic: if they contain a delay node it is simply ignored. The solution seems to be a custom event. Once triggered it will increase or decrease the health value and call itself again if the certain conditions are still true. The animation seem smooth enough with a 0.1 second delay.

'''Health bar recreation'''

There are two options to create a mask: a computed texture (vector) or a real texture designed in a image editor.

For color changes we would need a dynamic material in any case.

In the following sub section there are the required steps to achieve a health display meter.

======Texture======
Basically the mask (shape) of the health display meter.

This will be used as a node inside the material.

[...]

======Material======
Create Material Blueprint, Set output node to Material Domain: User interface (!), create a constant 4 Vector, right-click to turn it into a Parameter and name it Color, connect to output node

======Widget======
* Right-click in assets folder to create a new widget (User Interface > Widget Blueprint).
* Place an image into your Designer. This is going to be the health display meter.
* Under Appearance choose your Material.

Turning the Material in a dynamic one and setting initial color... Create variable of type "Material Instance Dynamic", create 2 vector variables (rgb red, rgb green, use 0 to 1 range). Then in In your widget goto Graph and add these nodes to your Construct and Custom event...

* Construct event -> Get HealthImage, Get Dynamic Material, set Dynamic Material variable, Get Player Character, Cast to ThirdPersonCharacter, Target MaxHealth, Set Progress (call function)

* Custom event -> Set Progress (with a float input), Get Dynamic Material, Set Vector Parameter Value (Parameter name ("Color") from your material), add lerp(linearColor) to SVPV node, add vector color variables to lerp node (here we can add more logic to recreate [[XML:ONGS#The_health_display_meter|ONGS' <Color> tags]])

Displaying the widget to screen and creating a reference ...
* In your Character BP create or add these to the BeginPlay event node:
** Get Player Controller, Create Widget (your health bar widget), Add to Viewport, set output Create Widget to a public variable (object) (use search to find widget)

Setting progress on the HUD... In Character PB ...
* event ..., get widget object variable, Set Progress (Target: var, Input: Health Percentage)

[...]

====Tables and structures====
* Data tables are created based on previously defined structures. So these two file types are best seen as a tandem to get things done.
* Structures can be made to provide default values so that new tables will have those after creation. This might be suitable for new ONCC.
* Structures can be nested.
** Wtih version 4.25, the editor and engine might need a few restarts before an new structure is usable by an older one.
** With version 4.26, this bug doesn't seem to appear anymore.
* '''Tables can be exported to csv and json''' whereby json would be the more human readable form for complex, nested structures.
** Exporting and examining tables help you understand how to programmatically create such structured tables.
* Tables can be imported by using the import button or drag and drop.
* Tables can be reimported by rightclicking then Reimport (remembers file location) or Reimport With New File.
** Reimports (converting raw data files to assets) can be done with python and probably other methods.

====Widgets====
[[Image:ue4_open_close_a_menu_widget.jpg|400px|right|thumb|For testing purposes H key is used to show the pause menu. F1 will let the Unreal Editor switch wireframe mode.]]

Any key can be used to open a menu. But when the game gets paused too then pressing the same key again cannot close the menu.

You need to set the key's property "Execute when Paused" to true.

Also, in theory a "Flipflop" node would work but has proven unreliable. Instead, a reference to the menu instead, an "Is Visible" and a "Branch" (if) node will do the trick. Additionally, an Is Valid node is placed to catch an error when the reference is used for the very first time.

We can capture the mouse within the game application if we place an "Set Input Mode Game And UI" node with "Lock Always" option.

=====Button and section images=====
[[Image:ue4PauseMenuButtonsDisabled.jpg|400px|right|thumb]]
'''Styles'''

Buttons have 4 styles: Normal, Hovered, Pressed, Disabled.

For now lets use only 2 textures: one for Normal, one for Hovered and Pressed.

The Disabled style just uses a tint color on the Normal texture with an RGBA of 000000FF.

Buttons can be disabled via Set Is Enabled (Target is Widget). You can get button references from the Graph window.

[[Image:ue4PauseMenuButtonsDisabledInGame.jpg|400px|right|thumb]]

'''Scaling'''

When you place a Grid Panel into the widget you can define columns and rows. Buttons and other elements can adapt to their given space.

You probably want to set button texture property Draw As to Image.

For standalone images Draw As Border can be used if the image is big enough. This will work like Oni's [[XML:PSpc]] where only specific sections of the image are scaled.

For extreme different resolutions we might need to bind different textures so Draw As Border won't produce empty spaces in the center.

=====Text pages=====
For now I see 3 major flaws with text items:
* no richtext support (you are limited to one font color, unless you use a C++ plugin)
* text warping is not accurately working
* space for an image has to be planned in advance

'''Text vs text box'''

Because of the multiline feature I rushed to use a text box for static text.

Reminder: While "Text" is for static text, "Text box" is for letting the user type his own text.

It turns out the font color of "Text box" cannot be changed at runtime and a simple "Text" object does also has the multi-line feature.

'''Dynamic text content'''

We can either use
: A) the "Set Text" node with a reference to the object or
: B) bind the object to a text variable or function, making the code a bit shorter

// ------------------------------------ move this to Pause Menu section at a later time

When you insert text you have to compile (F7) before you see the result.

Text pages can be grouped in the Designer with a Widget Switcher. However, each text should have an Overlay as parent so they aren't all shown simultaneously.

-- WidgetSwitcher (master section, e.g. for "Main content")
+-- WidgetSwitcher (section, e.g. for powerup items)
+-- Overlay
+-- Text (e.g. hypospray text)
+-- Image (e.g. hypospray icon)
-- WidgetSwitcher (master section, e.g. for "hint text")
+-- WidgetSwitcher (section, e.g. for powerup item hints)
+-- Overlay
+-- Text (e.g. hypospray hint text)

Count direct children of '''W'''idget'''S'''witcher by using the its reference connected to a Get Num Widget node.

It's possibly a good idea to count all sections during the construction event and save the results in an array via Make Array node.

In theory we could create many copies of Overlay nodes. But doing so and future update would mean more work than necessary. Instead a single overlay with its children can be do the job by assigning data to them from a '''data table'''.

Variables that track active pages are destroyed as the widget is closed. If we want to resume reading after reopening a menu the variable values should have been copied to somewhere else. If we put them into character variable then we can easily restore those values even after a level loading.

// ---------------------------------------------------------------------------------------------------------------------

=====Bulk import=====
HTF do I? Import a CSV File into a Data Table ( UE4 )
* https://www.youtube.com/watch?v=nMy6H1o1zO0

Summary:
* if you need a free spreadsheet program [https://www.libreoffice.org/download/ you can download Calc, it is part of LibreOffice], or use Google Sheets
* '''create a csv''' file with the first cell of first column (A1) being empty and the other lower cells (A2, A3, ...) to be unique in name
* Calc: save file, check "edit filter settings", save csv with comma as field delimiter
* in ue4 goto "Add New" > Blueprints > '''Structure'''
* open that ''Struct'' and add for all columns (except for A) a variable, assign a type for each
* be sure Struct's variables have the same name as the csv column headers
* import the csv and assign the Struc to it
* data tabes can be updated by reimporting the csv

[[Image:DPgeDataTable.png|400px|right|thumb|CSV file for the data table to import. ''LevelNumber'' makes it possible to ''bookmark'' pages for levels.]]

Example:

for now diary (DPge) will have this structure
* levelNumber = Integer
* pageNumber = Integer
* isLearnedMove = Integer
* caption = String
* image = Texture 2D
* diaryText = String

Stuff that might be useful later...
* https://dev.epicgames.com/documentation/en-us/unreal-engine/BlueprintAPI/Utilities/Text/FindStringTableIDandKeyfromText?application_version=4.27
* https://dev.epicgames.com/documentation/en-us/unreal-engine/BlueprintAPI/Utilities/Text/MakeTextfromStringTable_Advanced/?application_version=4.27
* https://forums.unrealengine.com/t/how-to-localise-with-string-tables-in-blueprints-only-project/395329

Importing data tables is cool but unfortunately I haven't see a way to create text and image fields programmatically to the editor. --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 22:52, 11 February 2018 (CET)

Then again maybe this will do: https://www.youtube.com/watch?v=e8MPDnVX1h4

If not I will try to just use one text field for diaryText, etc.

If textures aren't found in the data table, open them once from the asset browser. It seems there's a bug which prevents new textures from being registered properly until they were accessed for the first time.

=====Pause menu=====
======Objective pages======
Objective pages are level specific.

Optional small image.

Main and hint section holds green text (todo) and red text (done).

======Item pages======
Main section: Small image plus orange text.
* Image
* Name .............. Function
* Text

Hint section: orange text.

======Weapon pages======
Main section: Small image plus orange text.
* Image
* Attribute .......... value
* Text

Hint section: orange text.

======Diary page======
Diary pages are global -- in a manner that the latest date would get you all other diary pages as well.

Sub types:
* "New move" page: main window for orange caption and a big image. Explanation in the hint section, white text.
* "Regular diary" page: main section only, white text.

======Help page======
Green text for main section and explanation. Hint section not shown.
"Controls"
Action .............. Mouse/Key

And explanation overlaying the UI.

====Animations====
=====Key binding=====
Every key can be used in blueprints. In order to allow key remapping by the player keys should be mapped in the setting instead of using detecting their real key stroke.

Goto Project Settings > Engine > Input.

Name your action or axis, then bind a key to it.

=====Interaction=====
Requirements: typically a variable in the Character BP. For example you can set "IsPickingUp?" to true with a "Q" button "Pressed" action and setting it to false with the "Released" action.

Then in Character Animation BP > '''EventGraph''' there should be a "Event Blueprint Update Animation". There you retrieve "IsPickingUp?" and save it in a local variable. You can retrieve variables from other blueprints by getting the object holding them, passing it to a cast node, pulling a wire out of the right side and search for it in the popping up context menu.

Then in Character Animation BP > Anim Graph > Default State Machine you pull out from Idle/Run a wire and create a new state.

In the transition rule for '''Idle to Pickup''' create two nodes: The local variable IsPickingUp and the "Result - Can Enter Transition".

In the transition rule for '''Pickup to Idle''' create three nodes: The local variable IsPickingUp, a boolean "NOT" and the "Result - Can Enter Transition".

Now the character plays the animation as long as you press the key. If you want to play the full animation just by pressing the button firmly you have to use a slightly different setup. Use these three nodes instead: '''"Time Remaining (ratio)"'''(''Animation name''), float > float node, Result node.

The float 0 to 1 means how much of the animation will play before it is aborted if the key wasn't longer pressed. In this case, the lower check float the more of the animation is played. Use a number greater than 0 like 0.001

To disable other input you have to create another variable in the Character BP with is also retrieved in the Character Animation BP by casting.

In this example it was named "Movement Allowed". The event that sets and resets the variable was created in the Animation.

Every animation can have Notifies events. Right-click notifies track to add a new custom notify.

====Normal maps====
Can be created in Photoshop (3D) and Blender.

====BSL equivalents====
=====print=====

Level Blueprint, right-click to search for
"Keyboard Event V", add that node, drag the "Pressed" slot to the backgound to create another node: "Print String". Compile. Close.

Play Level, hit "V". "Hello" appears on the screen.

Use you imagination: This could be used to toggle visibility of developer stuff.
In connection with a HUD you could create the equivalent of "chr_debug_characters = 1"

====Cooking the game====
On Windows, run the game editor with administration rights.

Then go: File > Package Project > Windows > Windows (64-bit).

Choose an output folder.

You can now play the game.

:https://forums.unrealengine.com/t/how-do-i-create-a-exe-of-my-game/282120

====Exit the game====
Create two nodes in level blueprints: "input keyboard escape" and "quit game". Connect the execution slots.



[[Category:Oni 2]]

Talk:Main Page/Archive1

2026-04-13T15:13:28Z

Iritscen: link fix

__TOC__
==Diversification of Names==
The list under Names includes varying entities. The Imago suggests splitting into: Characters, Groups, and Objects, allowing Added Value a separate listing. So proposes the Imago. [[User:Imago|Imago]] 04:31, 29 July 2008 (CEST)
:I liked your idea, and have implemented it with a couple changes: the Names page wasn't worth breaking up into even smaller pages for Characters, Groups, and Objects, and we wouldn't have multiple links on the Main page all going to one other page, so I simply changed the wording of the link on the Main page to be more descriptive.
:I did add a link to Added value, which indeed, should have been there all along. I'm just not sure what to do with the Trivia. Does that belong in Added value? I wonder what geyser's thoughts on that are. Was the [[Trivia]] page always going to be its own thing? Is "added value" supposed to refer only to further thoughts on Oni, which would rule out the Trivia page? Or should Trivia just be rolled into the other pages? I think at least some of it is totally redundant. --[[User:Iritscen|Iritscen]] 18:32, 29 July 2008 (CEST)

==Standerds==
:Mayhap we should set some standerds for article creation/modification. For one, NO m-rated language.[[User:The Deadly Brain|The Deadly Brain]] 19:18, 25 May 2007 (CEST)

:I beg to disagree. Clean language is not an option.
:The best we can do is blank out certain characters.
:So I hope you're all right with s##t and f##k etc.
:Peace
::[[User:Geyser|geyser]] 22:16, 25 May 2007 (CEST)
:In any case, such a rule would have to be motivated.
:Are ''you'' offended, or do you want to protect others?
::[[User:Geyser|geyser]] 22:16, 25 May 2007 (CEST)
:BTW, there ''are'' stand'''a'''rds in terms of spelling ^^
::[[User:Geyser|geyser]] 22:16, 25 May 2007 (CEST)
:I know for a fact children younger then ten visit this site.
::[[User:The Deadly Brain|The Deadly Brain]] 23:22, 25 May 2007 (CEST)
:#Do you mean from {{OCF}}? (we're not indexed on Google yet)
:#All clear. But it's as I said. "Bleeping" at most.
:You can be the bleeper-in-chief if you want ^^
::[[User:Geyser|geyser]] 00:59, 26 May 2007 (CEST)

----

==Expansion==
it could use a bit of enlarging... and detailing... this site ain't a direct-copy of the game (even though it might seem so ;P), so... :)
[[User:EgonFreeman|EgonFreeman]] 1:33, 9 Jun 2006 (CEST)
:Well, feel free to contribute... that's how it works. All the detailing and enlarging is done by me ATM, but it's not supposed to stay that way...
:I know there are things like chapter summaries and character profiles missing, but... there are other priorities, including Oni-related ones :)
:I may be trimming the Main Page soon (it's a bit confusing at the moment). More images, less text. Links to namespaces and such.
:[[User:Geyser|geyser]] 02:30, 14 Jun 2006 (CEST)

==Proposal for New Main Page ([[User:Iritscen/MainPageProposal]])==
:Sorry, geyser, I should have discussed it first, but I thought, it's better to show than to tell, and if you didn't like it, you could revert... also, I copied because I didn't want to make you move things back if you wanted to revert (and because some things were getting moved to separate pages, not just moved together)...
:anyway, it sounds like you prefer the main items to be the only items on the front page, and each links to its own page, right? "Making of", "Basic", etc. are the only level that shows here. Is that right?
::[[User:Iritscen|Iritscen]] 17:27, 16 January 2008 (CET)
#You could totally have "shown" here in the talk page, or (better) in your user namespace, with only a link to that new page design here, like: [[User:Iritscen/Main Page]]
#That's right. The main page should be a "portal to portals" with most of the details moved to those other portals. What we have now is something resembling a "site map".
:We'll see about reverting. The wiki is important, but I will sorta have to focus on modding this week, so I'm not sure I'll have the right inspiration to help you guys.
:As for the splitting stuff off to separate pages, please let's not have too much of that. Mini-pages actually make the wiki harder to browse and more annoying to read.
::[[User:Geyser|geyser]] 17:40, 16 January 2008 (CET)
Okay, what if the main page looks as it does now (but maybe a nicer arrangement of the titles), and then each of those links to some fairly large pages -- no mini-pages. If you don't like that, I will revert to original Main Page and go do something with the Images section... future changes will indeed be previewed in my namespace. Sorry, I forgot my wiki etiquette. --[[User:Iritscen|Iritscen]] 17:47, 16 January 2008 (CET)

@Iritscen: That sucks. Would you please change that back and use a playground first as geyser had suggested it above? [[User:Ssg|Ssg]] 18:21, 16 January 2008 (CET)

:Well, since you asked nicely, sure, I'll do that. --[[User:Iritscen|Iritscen]] 18:22, 16 January 2008 (CET)

Thank you. (Wow, now that was really a fast response. :-) I've nothing against a new main page, but it's not a good choice to replace a full working site with an "under construction" one. [[User:Ssg|Ssg]] 18:38, 16 January 2008 (CET)
:You're right, I was expecting a quick reply from geyser, but it seems he's moved on to something else. When he responded I was going to start fixing things up. You just happened to come along in the meantime. As he's pointed out, I should be doing things like that in my namespace; see User:Iritscen/MainPageProposal from now on.
:Anyway, we should still get a sense of what kind of page people want. A very simple one with groups like "Making Of", "Basic Info", etc., or can we have subgroups like in the Proposal? --[[User:Iritscen|Iritscen]] 18:55, 16 January 2008 (CET)

Oh... I'm sorry. Didn't know that it was already in work. However, your new main page looks good. IMO you can replace the main page.

One suggestion: Add an equals sign to every group and subgroup. F.e.: <nowiki>=Help= to ==Help==</nowiki>. IMO it looks better, because the page has not so much dividing lines. [[User:Ssg|Ssg]] 11:20, 17 January 2008 (CET)

:Okay, I did that, and agree it looks better. But Ssg, geyser does not agree that the page should be so long, which is why I want to arrive at a consensus before replacing what's on the Main Page. I think the page can be that long, but maybe he thinks it's unwieldy or intimidating.

:Also, I am trying to add this code at the top of the page:

:<nowiki><center><div style="font-size=162%;">Welcome to OniGalore, the wiki for all things Oni.</div>
:[[Special:Statistics|{{NUMBEROFARTICLES}}]] articles in total</center></nowiki>

:Two problems: 1. It does not change the font-size! and 2. The article count looks wrong. Look at the statistics page. There's a bajillion pages and it says only 90 are probably "real content". Is that true? --[[User:Iritscen|Iritscen]] 16:14, 17 January 2008 (CET)

Replace the equals sign between "font-size" and "162%" with a colon:

<center><div style="font-size:162%;">Welcome to OniGalore, the wiki for all things Oni.</div>
:[[Special:Statistics|{{NUMBEROFARTICLES}}]] articles in total</center>

The "90 articles" is right, I guess. IMO Wiki takes a namepsace as one article. So f.e. the whole OBD sites are only one article. Well, that's what I think. I've no idea, if that's right or not.

I like the long main page, because it contains all information I need. I don't have to search for something and I don't have to guess where something could be located. Nevertheless, to shorten it I would move the external links to a seperate site, because that's a topic that can run up to a lot of entries. The link to the "External Links" can be placed in the "Further Content" section. [[User:Ssg|Ssg]] 18:57, 17 January 2008 (CET)

:THANK YOU. That was driving me crazy; I think our wiki's syntax is a little different from Wikipedia, or else I'm just confused. But the tags work now, and that's what matters. I agree with your input on the External Links (it's not really appropriate to have external links on a wiki's front page, now that I think about it), and am adjusting accordingly. --[[User:Iritscen|Iritscen]] 19:45, 17 January 2008 (CET)

::It is probably because wikipedia is updated :P...OniWiki is ollllddd [[User:Gumby|Gumby]]

==Vote for New Main Page==
Please add your opinion below. All in favor of the page at User:Iritscen/MainPageProposal write '''For''' and optionally give a comment. Otherwise write '''Against''' and please explain why. Remember to sign! We need to get this matter settled so I can move on to other things on the wiki and stop glancing at the talk page looking for changes.

'''For'''. But I ''am'' a biased party :-3 --[[User:Iritscen|Iritscen]] 16:15, 28 January 2008 (CET)

'''For'''. The new page is hawt [[User:Gumby|Gumby]] 08:42, 30 January 2008 (CET)

'''For'''. I like it :) [[User:Tyr|Tyr]] 16:57, 30 January 2008 (CET)

'''Err'''. How is it different from the old one? [[User:Geyser|geyser]] 16:26, 31 January 2008 (CET)
::Stuff got moved around, and a new intro, methinks
::<nowiki>http://wiki.oni2.net/w/index.php?title=User%3AIritscen%2FMainPageProposal&diff=7480&oldid=7479</nowiki> if it helps :P [[User:Gumby|Gumby]] 20:03, 1 February 2008 (CET)

'''For'''. Maybe we should move the "help" section to the 2nd or 4th position, so that the "basic content" is followed directly by the "further content". That makes more sense, IMO. [[User:Ssg|Ssg]] 14:37, 2 February 2008 (CET)

;Kkk.
:K guys, looks like long silences attract spam. What do you think about a 3-column layout such as [[User:Geyser/Main|THIS]]?
:Of course, you could add items to every list, but I'd rather keep them short and redirecting elsewhere.
:If I don't have a reply by the end of the weekend, I'll make [[User:Geyser/Main|this]] the new main page, fa fa fa fa fa! ^_^
:The old one (or maybe Iritscen's revisited version) will be moved to "Main Page/Site map" or something.

'''Mmh'''... not bad either. If we use this, you should add a "valign=top" so that the entries of the last row are always on top. [[User:Ssg|Ssg]] 19:07, 2 February 2008 (CET)

;Hmm...
:Added the valign thing. Needless to say, you're welcome to fancify the colors, reshuffle the lists etc... at any time.
:That page also relies on 4 pages that don't exist yet: "ONi", "ONi for fans", "ONi for players" and "ONi for modders"...
::[[User:Geyser|geyser]] 00:32, 3 February 2008 (CET)
;Oh...
:Oh indeed. As for that spam we're getting, it's not clear whom we owe this new source of comfort.
:We were never indexed on Google, so it must be a problem of linking here from one place too many.
:Did someone add a link to the wiki from a site hosted on a public server, or something like that?
:Interestingly, the IPs are very specific, with a single set of spam per IP. That's a "good " thing.
:If we keep getting more of that, we will probably restrict editing access to registered users.
::[[User:Geyser|geyser]] 00:32, 3 February 2008 (CET)
:OK, who do we know in Odessa, Ukraine? ^_^

I've added a lot of "Links". [[User:Ssg|Ssg]] 01:08, 3 February 2008 (CET)

Why not to [[OniGalore:Community_Portal]]? [[User:Geyser|geyser]] 01:44, 3 February 2008 (CET)

Oh... forgot about this site. (There is no link to it on the main page.) Sorry. Nonetheless, I prefer the name "links". So I would suggest to close the "community_portal" page and use the "links" page.
*To your main page proposal: Why are the entries of the 1st and 2nd rows links? ("ONi", "ONi for fans", "ONi for players" and "ONi for modders") Do we need these? What's your idea for the content of these?
*To the colouring offer: Believe it or not, but the colour you've chosen looks good to me. :-) [[User:Ssg|Ssg]] 15:02, 3 February 2008 (CET)

;Crap.
:It's getting flooded in here. Will definitely clean this up after setting up the new Main Page layout.
:There are nice links to "Community portal" and "Current events" in the wiki's main navigation box...
:These pages are there by default, which is why I'm using them rather than pages called "Links" etc.
:So, closing [[OniGalore:Community_Portal]] is not an option, but we can make "Links" redirect there.
:I strongly object to an "exhaustive" collection of links (the "links to programs", for example)...
:Such lists are useless to newcomers, and only serve as bookmarks to people who know where to look.
:If a program is worth linking to, develop on it, either on its own page, or in "Programs" or such.
*"ONi" and the other three are supposed to be portals in article form (with sentences and lists).
:They would describe the main fields of interest and provide links to more detailed "articles".
:Simply put, they are expanded, verbose versions of the mini-lists in the Main Page portal.
*Heh, I'm just using [[Template:Table]], so the color is yours. I thought of livening it up.
:(you know, with different colors for the columns, a background picture, some mini-thumbs)
::[[User:Geyser|geyser]] 18:10, 3 February 2008 (CET)
----
;To a public server?
:Could be almost every fan site which isn't on oni2.net. (Links which I set to the wiki: a more or less dead webspace*, a private wiki*, a privat forum**). Or do you mean link from a public server? Maybe it works that way too. (I've a link on animexx.onlinewelten.com** to my oni2.net webspace which is linked to the OG.)
:<nowiki>*</nowiki> - not indexed by google <nowiki>**</nowiki> - indexed by google, but restricted area excluded for logged in members
:However, it seems like a silly bot which attacks only the "Talk:Main Page". So why not set it under protection?
::[[User:Paradox-01|Paradox-01]] 14:46, 3 February 2008 (CET)
:Yes, I meant "from" (sorry about the "typo").
:I enabled protection for this page.
:You have to log in to edit it now.
::[[User:Geyser|geyser]] 22:58, 3 February 2008 (CET)
;For/against...
:Well, I think both pages are better than the old. But I trend to geyser's because it's more compact.
::[[User:Paradox-01|Paradox-01]] 14:46, 3 February 2008 (CET)

----
===Vote Canceled===
:At the risk of sounding bitchy... you guys really got off track here. You're talking about spam (where?), and portals, and forgetting to sign so I have no idea who's saying what. Now geyser has introduced a new main page in the middle of the vote, so the vote has been totally derailed. This means everyone's vote is now obsolete, because it may or may not have been made after seeing geyser's new page. *sigh* If we're going to try this democratic thing properly, we need everyone to please vote again in the next section. It's not my fault. --[[User:Iritscen|Iritscen]] 18:44, 4 February 2008 (CET)

:I'm sorry I spoiled your vote (perhaps intentionally: I'm a dictator after all, albeit an enlightened one). Note, however, that every single person either signed or logged in.
:You could thus always get an idea of who's talking, with a quick look at the history. BTW, the recent spam would also appear there, as it was plaguing this very page.
:You shouldn't overestimate the democratic aspects of wikis. Just because Wikipedia does things a certain way doesn't mean we should mimic them: not at all...
:All those encyclopedic standards, for example, are completely irrelevant to a project wiki, which should just be decently informative to its supposed visitors, period.
:I also think it's quite appropriate not to enforce scholarly objectivity in the articles. As long as "personal essays" and occasional wacky stuff do their job, let them be.
:Bring in organization if you like, but spare us the tedious bits. In other words: take the "fun" out of "functionality", and I might buy myself some extra guts, my [[friend]] ^_^
::[[User:Geyser|geyser]] 23:09, 4 February 2008 (CET) 
::Perhaps you noticed my bringing in a template, huh? :-) Don't worry, I am not going to be a wiki-Nazi who insists on WP-style writing everywhere. I am all for some whimsicality in this wiki. But at the start, it seems to me that the wiki was basically your baby, and while I don't want to take it away from you (not that I could, Mr. Admin!), if we don't open it up for others to contribute, it can't represent the community as a whole. But if an article is written in 1st person, then it naturally makes anyone else hesitant to touch it, so they can't contribute. That was the purpose behind the template.
::I'm sure you won't mind others taking some of the burden off your shoulders and helping you finish up the wiki; I just want to assure you that that's really my only goal in everything I do here. I also don't intend to put every single thing up to a vote; it's just that the Main Page is an important matter and I think we need input on what design would be most user-friendly. --[[User:Iritscen|Iritscen]] 15:28, 5 February 2008 (CET)

==2nd Vote For New Main Page==
Please vote for the old (current) [[Main_Page]], or for my [[User:Iritscen/MainPageProposal|proposal]], or for geyser's [[User:Geyser/Main|proposal]]. I guess it will save time to just say '''OP''' for the original (current) page, '''IP''' for Iritscen's Page, or '''GP''' for Geyser's Page. --[[User:Iritscen|Iritscen]] 18:44, 4 February 2008 (CET)

;IP.
:I do appreciate geyser's new page, but I think the formatting is not really proper wiki-style. True, it's our wiki and it can look however we want it to. I just prefer a vertical layout to a horizontal layout. Also, the comments on each item in GP are a bit untidy and make it look cluttered because they broaden the overall table.
::[[User:Iritscen|Iritscen]] 18:44, 4 February 2008 (CET)
;GP.
:(I don't think either Iritscen or I are in a position to vote, but his critique deserves a response)
:No comment on your preferences, but IMO a home page should offer an overview within a page or two.
:Optimally, the user doesn't need to scroll at all to start navigating (more or less my suggestion).
:As for "proper wiki-style", you should have a 2nd look at Main Pages elsewhere... anywhere.
:They are typically very small: either tight paragraphs or tables, directing to only a few pages.
:Finally, my table spans the whole page: the comments wrap around instead of "broadening it up".
:Also note that the comments don't wrap at all unless your horizontal resolution is 800 or lower.
:I wouldn't say the table looks cluttered on a 1024x768 monitor, which is quite something.
:If by "untidy" you meant the wacky randomness of some comments, it's an intended feature.
:Of course I can't claim to be a master of silly jokes à la Bungie (nor do I want to).
:But the wiki can be made more appealing/intriguing if it's spiced up by such things.
::[[User:Geyser|geyser]] 23:26, 4 February 2008 (CET)
::I'm not going to keep critiquing your page and start sounding like a politician doing attack ads; the vote isn't up to us, anyway; but just to be clear, you are right that your table is wiki-like. But the advantage of my vertical approach is that the Table of Contents is used to jump to wherever you want. You also don't have to categorize yourself first when trying to find a link ("Am I a fan, a player, or a modder?"). You just look for the subject you want to read about in the TOC and click it.
::And it's okay to be a little silly, but the comments in parentheses are basically explaining what each link is, which looks like clutter to me. If the links are not explanatory enough for a newbie, than you and I are doing something wrong and the links/pages need to be named better. --[[User:Iritscen|Iritscen]] 15:42, 5 February 2008 (CET)

;?P.
:Ooh... I can't decide. Both are good. Seems that we have to wait for some more opinions...
::[[User:Ssg|Ssg]] 12:34, 5 February 2008 (CET)

----
===Vote Canceled===
Okay, let's forget this whole thing ever happened. --[[User:Iritscen|Iritscen]] 19:30, 6 February 2008 (CET)

==Beyond the vote==
:@geyser: The table doesn't look good in 1440x900. I suggest either to put the table into another table or to put the content of the last row into separate tables and center these. Also I don't like the look of the part above the table (introduction, welcome pic). That should be polished somehow.
::[[User:Ssg|Ssg]] 12:34, 5 February 2008 (CET)
:As for both layouts being good, my suggestion was to keep them both. Iritscen's can go either below the table or on a separate page (like a site map).
:As for the looks in 1440x900, I'm not sure what you mean. If you object to the lists being flushed left in wide table columns, then I kinda disagree.
:If you embed the lists into centered sub-tables, the width of those will depend on the content, so it will be different for the three columns. Ugly.
:IMO, left-aligned lists are OK and anything else will look worse. Might be wrong. Anyway, you are free to polish anything you feel like polishing.
::[[User:Geyser|geyser]] 14:39, 5 February 2008 (CET)

My vote goes neither to Geyser's nor to Iritscen's proposal. What we have here is not a choice between two alternatives. We rather need a blending of both.
Iritscen organized the main topics way better than Geyser. However Geyser's layout is absolutely more user friendly... even a lazy person like me is allowed to spot everything that's worth of interest at a first glance.
Somebody just grab Geyser's layout script, and figure out a way to put in the bottom table all the topics as Iriscen said. Also, Iritscen you may think of a better welcome message for the page header. The note about the search function is annoyingly obvious, just delete it. And remove that bloody drawing of mine! Bring back Lorraine's art or just leave no pictures, it will look fine as well.
::[[User:Guido|guido]] 13.15, 6 February 2008 (CET)
:What do you mean by the "bottom table"? I'm curious.
:"A better welcome message"... yeah, I ripped that thing off wholesale from Wikipedia, I'm not defending it. I'll see if I can think of something better.
:"The note about the search function"... yeah, it's a little patronizing, I thought the same thing.
:"Remove that bloody drawing of mine"... I really like it, but perhaps a piece of "canon" art is called for on the Main Page. I'll browse through our Images gallery for something of Lorraine's.
::[[User:Iritscen|Iritscen]] 15:21, 6 February 2008 (CET)
:Guido and ssg both have really weird ways to refer to those three lists: "bottom table", "last row"... for sake's sake, it's the actual table, guys!
:Welcome messages are hard to get right, which is why no one seems willing to take the responsibility of actually sitting down and writing them. ^_^
:I know for a fact that many people are unaware/oblivious of the direct-hit a.k.a. "Go" feature. I explained that in some more detail. Enjoy.
:Guido, your drawing is staying. It's up to you to remove or replace it, but as far as I'm concerned I'd only take the thumb-frame away.
:Apart from being just plain nice, it makes us stand apart from all those who don't know better than to recycle Lorraine's art forever.
:BTW, the opportunity to liven up the wiki with contextual illustrations still holds. Help yourself to the image gallery, everybody.
::[[User:Geyser|geyser]] 18:18, 6 February 2008 (CET)
:About the comments in brackets. When they are humorous rather than informative, and don't contain hyperlinks, we can replace them with hoverboxes, like this: [[Iron Demon|Iron Demon]]
:There are plenty of other ways to improve "my" table, but I woundn't cram all of Iritscen's "site map" into it because: 1) it will never encompass the variety of the wiki's content; 2) in the attempt to do so, it will grow larger and larger, so that "even a lazy person like [Guido] is able to spot everything that's worth of interest at a first glance" will no longer be true.
::[[User:Geyser|geyser]] 18:18, 6 February 2008 (CET)
::Okay, I will implement the hover boxes. That seems like a good compromise. --[[User:Iritscen|Iritscen]] 19:11, 6 February 2008 (CET)
:::Hoverboxes added. I also removed some lower levels of hierarchy (or should I say arboresence?) in the Main Page because that kind of detail is unnecessary (that's what my Main Page, er, Site Map is for!) --[[User:Iritscen|Iritscen]] 19:32, 6 February 2008 (CET)

==On The New Main Page==
Well, this is it. We've just witnessed a mental breakdown. Someone call the men in white coats for geyser. --[[User:Iritscen|Iritscen]] 17:43, 6 February 2008 (CET)
:Also, am I the only one who has a big problem with "ONi"? I suppose if I weren't lazy I would change it to "Oni" myself and get in a revert war with geyser, but instead I'm being diplomatic by asking for other people's opinions. --[[User:Iritscen|Iritscen]] 18:27, 6 February 2008 (CET)
::And so it begins...luckily for me, I won't have access to the forum for a few days. geyser, I apologize, but I am hardheaded :P[[User:Gumby|Gumby]] 20:02, 6 February 2008 (CET)

That chibi Shinatama is cute. Just wanted to say that. --[[User:Iritscen|Iritscen]] 17:14, 12 February 2008 (CET)

Okay, here's a more constructive comment. I propose that we (by which I mean geyser, since he's the expert in tables) make a second table below "Oni" for "After Oni..." where we can put the items in See Also. It seems disorganized to have a little section like that after a big table. The second table could bring those items out in more detail (specifically, breaking out "Oni 2" to be a little more specific). Just an idea. --[[User:Iritscen|Iritscen]] 17:25, 12 February 2008 (CET)

:Well, as far as I'm concerned, the Main Page is functional enough as it is
:(however, I still can't forgive how you replaced Upgrades with Daodan DLL).
:If you think about "Oni 2" in terms of "added value", it is not "after" Oni.
:And the projects under "See also" are really miscellaneous curiosities ATM.
:When Konoko Payne goes beyond the proof-of-concept stage, I'll reconsider.
::[[User:Geyser|geyser]] 23:00, 25 February 2008 (CET)

==Chibi Image==

Why is it all pink when I see it on the main page, but all colorful when I click on the image?
:--Gumby
:Me too. Gumby, what browser you're using. I've mozilla firefox.
:Same effect for an image by Iritscen. Please check [[:Image:Iritscen_-_PKV_01_-_Front-On_Konoko_%28F-PS%29.png|THIS]] and confirm the error.
::--[[User:Paradox-01|Paradox-01]] 21:15, 25 February 2008 (CET)
Being colorblind, it's hard for me to see that Shinatama is "all pink" on the main page, but she doesn't look nearly as good as on the image page: [[Image:Rina - Chibi Shinatama Final.png]]. Even aside from the color thing, she might need to be sized down in a proper graphics app like Photoshop rather than leaving the scaling to the wiki. --[[User:Iritscen|Iritscen]] 21:38, 25 February 2008 (CET)
::Perfect, Gumby! Nicely fixed. --[[User:Iritscen|Iritscen]] 21:40, 25 February 2008 (CET)
:It is ''not'' a perfect fix, it's a dirty hack around a flaw in the outdated MediaWiki engine.
:I asked Alloc to update the engine and I'd rather if you had some patience until he does so.
:Sigh. I'll leave the resized PNG for now, but eventually I'll revert to the one I uploaded.
:Wikipedia scales PNG nicely, so there's no reason why our wiki shouldn't. Just be patient.
::[[User:Geyser|geyser]] 23:00, 25 February 2008 (CET)
:"dirty hack"? Pshaw, that took a lot of work...like...copying the image...and uploading the image :P I understand the want for the PNG to work properly though. I once asked Alloc about the wiki's age and there was some reason he didn't want to upgrade it...probably too much work...xD. I wanted to have support for lowercase titles, but the wiki is too old :P. And, I use IE7 at school. Let me check using Opera (Wii browser) for the glitch...
::[[User:Gumby|Gumby]]
:I have Opera, and the glitch is there. Moreover, you have to realize that the scaling glitch is server-side.
:It's the wiki's engine that generates the scaled versions of the images, when processing wiki text into HTML.
:It's those automatically generated images that are wrong, and they'll be wrong no matter what the browser...
:Upgrading the wiki means quite a lot of work for the admin, and a downtime, too. Dunno when that'll happen.
::[[User:Geyser|geyser]] 06:06, 27 February 2008 (CET)
:Yeah, I know, it doesn't hurt to check though...:D
::[[User:Gumby|Gumby]]
==Talking Heads Xplode==
:The wiki now scales PNG properly, however previously generated thumbs may need to be purged (the easiest way is to reupload the image).
::[[User:Geyser|geyser]] 12:45, 2 June 2008 (CEST)
:Now that the PNG scaling problem is fixed we can re-upload all of the talking head images as PNG right? The JPEG artifacts look really bad, especially when scaled. I'd be glad to help.
::[[User:RossyMiles|rossy]] 11:46, 3 June 2008 (CEST)
:Great. Let us know if you have problems exporting them from Oni. As for the naming convention, please use [[:Image:TXMPSHINlistening.png]] etc. It's also best to add the category tags <nowiki>[[Category:Portraits]][[Category:In-game art]]</nowiki> to the upload summary. After you're done, we'll delete "Images/In-Game/Talking_Heads".
:Maybe "Portraits" (or "Small portraits") is not the best pick, but "Talking heads" is pretty bad as well. Oni calls them "cinematics", even more counter-intuitively. They're "insets" and "popups" (or "fly-ins") to me, so maybe the least confusing category would be something like "Cutscene pop-ups" or "Inset portraits".
:If we don't want to stress the function of those images in Oni, then "Small portraits" is probably good enough. If we want to stress that they're backing up the voice-overs, maybe I'd use "Voice-over art" ([[Voice actors|deliberately confusing]], sorta).
:Off topic: I didn't bother to give you feedback on your user page, since you apparently got in touch with SFeLi. As for Daodan discussion, you've probably spotted [[Daodan DLL]] by now.
::[[User:Geyser|geyser]] 14:31, 3 June 2008 (CEST)
==Welcome statements==
:I removed this from the top of the Main Page because I thought it was redundant, feel free to reinject it in the main text somehow.
<center>''This wiki is a community-wide effort. If you're a new or returning Oni fan, perhaps you can take the time to [[OniGalore:Current events|contribute]] towards making this wiki more complete.''</center>
:Whatever you do, make sure that Shinatama doesn't interfere with the table on 1600x#### or wider. Move the haiku around if you have to.
::[[User:Geyser|geyser]] 12:45, 2 June 2008 (CEST)

==Main Page Image==
Does anyone know how to randomize in the wiki parser language? Or else how to get the current date? I'd like to switch up the image on the right of the Main Page from time to time. It's very nice, but it's also very very cute, and Oni is not accurately summed up by Chibi Shinatama. We should at least put in a darker image from time to time, and vary the subject (Mukade, Konoko, Griffin, etc.). But I don't want to have to change the image manually. If we can set up a template that looks at, say, the day of the week, or picks a random number, we can have the image change itself from a pool of candidate images that we would set up. --[[User:Iritscen|Iritscen]] 18:09, 1 August 2008 (CEST)
:1) Let's have a look at the pool, first; 2) It's less procrastinatory to do it manually, really; 3) Actually, pretty much anything is less procrastinatory than this ^_^ --[[User:Geyser|geyser]] 18:19, 1 August 2008 (CEST)
::1. I don't have a pool, I just had a thought and then posted it. But the pool would be mostly Guido stuff, certainly. Not fan art in general. No more than seven handpicked images, cream of the crop and all that.
::2. Yes and no. Who feels like changing the page every week or whatever? I don't. Plus that generates unnecessary edits. I love automation, and getting technology to work for me, not the other way around.
::3. We can afford to procrastinate this, it's hardly a big issue. Seriously, I just wanted to throw my thoughts out there, and see if anyone had an answer to my question(s) (I've done some research, but I haven't found anything). We'll get around to doing something when we get around to doing it. No rush (unlike the other umpteen things I am working on). --[[User:Iritscen|Iritscen]] 18:27, 1 August 2008 (CEST)
:::I see no image, and the haiku is smashed to the right, in a thin column. Making it only a simple poem :) [[User:Gumby|Gumby]] 04:13, 3 August 2008 (CEST)
::::Which image is up? Griffin's? It looks fine for me. Can you take a screenshot of the problem, please? --[[User:Iritscen|Iritscen]] 13:50, 3 August 2008 (CEST)
:::::"Gumby: I see no image - Iritscen: Which image is up?" Duuuuuuuh, priceless.
:::::"Griffin's?" Griffin's was yesterday. Today's treat is ominous ragged Konoko.
:::::"It looks fine for me." Blame your browser's cache for showing you Griffin.
::::::[[User:Geyser|geyser]] 16:02, 3 August 2008 (CEST)
:::::::Well, bite me. I hit Refresh on the page and it still showed me Griffin. That seemed wrong, hence my question to Gumby as to who he was seeing. And now I Refreshed again and see scary smiling Konoko, but the haiku is still fine. Since I didn't change the layout of the page at all, only varied the image, I am justifiably confused about what problem Gumby could be having as long as he's not looking at my MainPageTest. --[[User:Iritscen|Iritscen]] 17:48, 3 August 2008 (CEST)
:::::::Okay, looks like you did do something to fix it, I guess. I never saw the problem, so I don't know. But thanks, I suppose. God, you piss me off so much sometimes, though, geyser. --[[User:Iritscen|Iritscen]] 17:51, 3 August 2008 (CEST)
::::::::'''hence my question to Gumby as to who he was seeing''' he said "I see no image", re:duh... '''That seemed wrong'''... but you sounded like everything was "fine for you". '''looks like you did do something to fix it'''... yeah, turned out the fancy variable is zero-based. --[[User:Geyser|geyser]] 18:09, 3 August 2008 (CEST)
:::::::::'''reasons I'm an idiot'''... Damn. I need more sleep. --[[User:Iritscen|Iritscen]] 20:26, 3 August 2008 (CEST)

==On The New New Main Page==
Well, I don't understand why it has to be fiddled with. I strongly feel that two large blocks of tabled text such as we have now, preceded by technical mumbo-jumbo, are not more "inviting" than the light, airy feel we had with the previous introduction text. I thought we had finally reached a Good Place with the Main Page when I slimmed down your unnecessary explanations. --[[User:Iritscen|Iritscen]] 04:04, 8 October 2008 (CEST)

:I plead guilty on the mumbo-jumbo: I thought of it as intriguing. It's a reference to Chung's datapad, the icon of which (OniGalore's old icon) is shown in the upper-right corner, and leads people straight to {{C|1}}. Somehow I've always wanted the main page to be somewhat fancy, with the welcome message set in some kind of atmosphere: in this case, Oni's cyberpunk in general and data terminals in particular. Maybe a screenshot of Konoko reading our welcome message from Chung's datapad would be more immersive. Or maybe it would suck.
:As for my unnecessary explanations, I hoped they would encourage scripters from OCF to contribute to BSL documentation. If we think this isn't going to happen, then you can remove the whole NOTE ON THE "GO" FEATURE block (to the general public it may look like an insult to intelligence, yes). Keep the table, though, as it solves the overlap issue permanently; if you want airiness, you can have something like this (note I trimmed the first block significantly).
::[[User:Geyser|geyser]] 05:16, 8 October 2008 (CEST)
{|width=100%
|
{|align=center
|
{|align=center
{|align=center
|
Welcome to Oni Galore, a [[wikipedia:Wiki|wiki]] dedicated to the video game '''[[Oni]]''' from [[Bungie West]] (PC/Mac/PS2, 2001/01). 
Below is a portal to the most popular/current/relevant resources. For the rest, there's search and [[wikipedia:Serendipity|serendipity]]... 
For further information about the community, have a look at our [[OniGalore:Community Portal|community portal]] and at {{OCF}}. 
If you'd like to contribute to this wiki, check out the [[OniGalore:Current events|Current events]] as well as our [[Help:Contents|Help]] section. Enjoy your stay.
|}
|}
|
{|align=center
|+'''''Friend or enemy, thank you for your interest in Oni Galore.
|{{Dailyimage}}
|}
|}

{{Table}}
!TABLE
|}

It's quite helpful when you explain your thought processes like this, it allows me to find common ground. For instance, I think the idea of an "atmosphere" for the Main Page is an interesting one. I kind of feel like we could only achieve that with something more radically graphical and more unified. In other words, if this is ugly, which I think we all agree on:
ENCRYPT SEQUENCE TmeC119-67
Manifest 12A-694-v contains a number of fragile items. Note the follo....
<TCTF UNIVERSAL DECRYPT RUNNING...DATA FOUND. DISPLAYING...>

Then this is less ugly, but still not pretty, and it's also distracting: 
ENCRYPT SEQUENCE TmeC119-67 
Manifest 12A-694-v contains a number of fragile items. Note the follo.... 
<TCTF UNIVERSAL DECRYPT RUNNING...DATA FOUND. DISPLAYING...>

This is more immersive: 
(I deleted this one day because it was ugly. --[[User:Iritscen|Iritscen]] 23:01, 17 July 2010 (UTC))

So, in other words, making some of the text into graphics allows us the freedom to use different fonts and more complex table-like structures (for instance, making the whole page feel like a datapad display; the above image doesn't really convey that, of course, it's just a quick and dirty sample). An overall structure would encompass the welcome text, the navigation table, and the picture of the day, all into one. Right now another problem on the Main Page is that there are two boxes and then a picture which feels tacked on to one side.

So maybe we can try out some different designs and post mock-ups here of our ideas.

As far as the Go/Search note, I just don't feel that the Main Page is a place to solicit editors to perform a certain task like setting up BSL redirects, even if they do kick butt. The thing is, I already tried to draw some people over to the wiki by posting on the forum a while back, and ultimately, even if it had a small effect, it wasn't much. I don't think we're ever going to see mass participation by community members in the wiki; it will probably always be more or less the ones who are already active (plus a few more if the community grows as we hopefully get more attention). And since you acknowledge that to readers of the wiki it is condscending to explain what "Go" and "Search" mean, I think we know what has to happen to that blurb.

P.S.: How did you trim the first block that is posted above? It's identical to what's on the current Main Page.... --[[User:Iritscen|Iritscen]] 16:20, 8 October 2008 (CEST)

:"Making the whole page feel like a datapad display" is what I suggested up there. Text doesn't have to be photoshopped, because bold Arial or Tahoma already looks OK, and there are some more common font families we can use; so there can be graphics in the background, with typeset text on top of it. However, I don't feel we should spend too much time on designing something as fancy as [http://guido.oni2.net/index.%20guido.oni2.net.jpg this] or whatever could have been the new design of OniCentral. I actually planned a compact, datapad-like design for geyser.oni2.net at first, based on [https://www.issendai.com/ THIS] but with a black/blue theme similar to Oni's Load Game dialog. And I could port it here. But I doubt we can make such an "atmospheric" thing work well within an otherwise plain frame (the default layout of the wiki is black on white and it's not going anywhere). Screen width VS resolution of the immersive screenshot or artwork would be one issue, visual clash between the "welcome" and the table would be another, and with the picture of the day next to a graphically enhanced text, people won't know where to look first and what to look for, sorta. So probably it's better to stick with my "airy" suggestion up there. A minimal block of text, and the haiku/POTD as the only artful/atmospheric element. As for the block of text, it's the same as on the current Main Page, yes, but it's shorter and more tidy than the ''previous'' revision. --[[User:Geyser|geyser]] 17:13, 8 October 2008 (CEST)
::Just to be clear, I was suggesting a look that would include the table at the bottom as well as the picture, in other words not looking strictly like the in-game datapad, but based on the look of Oni's interface and technology.
::But as you said, it wouldn't jive with the overall plain "theme" of the Main Page, and in any case, it could be considered jarring to go from a fancy page like that to plain black on white everywhere else on the wiki. So I'm willing to let this idea go.
::P.S.: Still meaning to write individual haiku for the PotDs, just haven't been in the poetic mood yet. --[[User:Iritscen|Iritscen]] 20:17, 8 October 2008 (CEST)
==Cherry picking==
::
:P.S: ... and what about replacing "serendipity" with "cherry picking"? I think it would be more intuitive. [User:Guido|Guido]] 10:00, 26 October 2008 (CEST)
::Well, the meaning of "[[wikipedia:Cherry_picking|cherry picking]]" was ''really'' not intuitive to ''me'', so I had to look it up. And it's still not clear to me what exactly it means as applied to this wiki (biased sample? WTF?) or why it's more appropriate than "[[wikipedia:Serendipity|serendipity]]". Eventually I meant to replace this with a link to the [[OniGalore_talk:General_disclaimer]], which would be a sort of condensed site map. --[[User:Geyser|geyser]] 11:10, 26 October 2008 (CET)
:::It's true that I don't think "cherry picking" is the right phrase to replace "serendipity", but the more important question is what "serendipity" is supposed to mean in the first place. You should be aware that, as fond as you are of "serendipity", geyser, I can confidently say that a lot of native English speakers do not know its meaning, and those who do, like myself, are still at a loss as to what it means when used here. When I first saw that the word was a link, I assumed it would link to [[Special:Random]], not a dictionary definition of the word that still gives it no context....
:::"'''a link to the [[OniGalore_talk:General_disclaimer]]'''" o.O ...Come again, geyser? --[[User:Iritscen|Iritscen]] 17:57, 26 October 2008 (CET)
:Clicking "Random page" has less to do with serendipity than following intrawiki links. The idea is that beyond a certain amount of cross-linking, the wiki virtually "navigates itself", and allows casual/curious readers to end up in unexpected places, through a set of more or less loose associations with what they were initially interested in. Maybe I'm the only one who reads wikis like this (starting with Wikipedia) and enjoys it... Anyway, "serendipity" in the context of our wiki (casual navigation powered by intralinks) is not meant to be self-explanatory right now. The actual thing that's supposed to be featured on the main page is the disclaimer: I used to link to it without the serendipity label, and I will re:link to it eventually, probably without calling it serendipity either. Thus thee serendipity thing is just a placeholder, or at least you can think of it that way. Of course, you can decide to kill that initiative (and delete the disclaimer while you're at it), but I wouldn't do that, or if I did, I'd expect unexpected retribution. My advice is to ignore everything you can ignore, and I'll do my best to ignore bureau-cats and other uncyclopedic spam that is only funny to certain people while on certain drugs --[[User:Geyser|geyser]] 22:04, 26 October 2008 (CET)
::<sigh>Because the Disclaimers page is ''so'' much funnier to ''such'' a larger audience :rolleyes:. The fact that you use the words "uncyclopedic spam" simply blows my mind when you were just talking about [[OniGalore:General disclaimer|this]] page in the same breath. Anyway, what I was trying to ask above was, How is the Disclaimers page in any way connected with your concept of browsing the wiki by serendipity? And don't get jumpy, I never said I was thinking of killing any initiative, I don't attack what I can't even begin to understand :-3. --[[User:Iritscen|Iritscen]] 01:39, 27 October 2008 (CET)
:::Quite simply, a list of ill side effects is a nice place to start browsing; every ill side effect linking to an article, ideally. Seen that way, the disclaimer has the potential of becoming a condensed site map (and I already told you that). Not in the present form, of course (remember that I was young and stupid when I stole SOW's disclaimer, so comparing your own silliness with it is not to your advantage), but as outlined in the footer and on the talk page (which I also linked to, for Mukade's sake). My own brainstorming and Gumby's should give you an idea of what's cooking. Just don't tell me we have to explain the meaning of every single item, because we all have better things to do right now. --[[User:Geyser|geyser]] 02:16, 27 October 2008 (CET)
::::Okay, now I get it, at least as much as I'm going to get it, I suppose. But if you think this plan was in any way clear before your last post, hate to tell ya, but it wasn't; don't act like you explained anything on the Disclaimers talk page, it's an incomprehensible list of gibberish right now. Whatever, have fun with it.
::::P.S.: By injecting humor into official wiki pages such as [[OniGalore:Policy|Policy]], I am *trying* to preserve fun while adding functionality, sorry if you don't see it that way, but I daresay most people will; heck, even Wikipedia has [[wikipedia:WP:BEANS|joke pages]] as part of their system of policy articles. --[[User:Iritscen|Iritscen]] 02:28, 27 October 2008 (CET)
:::::The functionality added by those official pages is nil, and the humor is IMO fairly tasteless, so in a way it's "worse than nothing". You know as well as I do that there's more than enough places on the web that cultivate that kind of humor; no need to develop it here as if our wiki was Yet Another Weak Hu--[[User:Iritscen|Iritscen]] 04:27, 27 October 2008 (CET)mor Site. If you can relate your humor to Bungie or Oni, that will already be more creative, if not better (I mean, since Bungie humor is already not very tasteful, either make the weak s##t part of the Bungie strain or leave it out). That's just my opinion of course, you're a big boy and I wouldn't want to tell you how to run an Oni wiki. ''<-- NOT ASKING FOR A FORMAL POLICY, OF COURSE; JUST TRYING TO APPEAL TO COMMON SENSE: THE WIKI IS NEITHER A SELF-INDULGENT BLOG NOR A PORTAL TO UNCYCLOPEDIA; SO LET'S AT LEAST TRY TO KEEP THE CRAP OUT
:::::"don't act like you explained anything on the Disclaimers talk page, it's an incomprehensible list of gibberish right now" Let's not play dumb and dumber, please. Care to go and read it again? Here's what it says at the bottom: ''<-- OOPS! MISTAKING THE DISCLAIMER FOR THE TALK PAGE WAS A VERY BAD IDEA''
::::::''The above masterpiece was outrageousy stolen (by me, [[User:Geyser|geyser]]) from [https://www.swo.com/ Science of War and Oppression]. '''I am looking forward to making [[OniGalore talk:General disclaimer|a more Oni-oriented variant]] (you're welcome if you want to help)''', but for now it's [https://www.swo.com/disclaimer.shtml SWO's original version], with a few original entries by myself. No, I don't have permission to redistribute their disclaimer. I'll try to keep it clean :)''
:::::You have had the ample opportunity to check out SWO's original disclaimer (incomprehensible list of gibberish? ''riiiiiiight'' ''<-- OOPS! SAME MISTAKE AS ABOVE, LOOKING AT THE WRONG PAGE''), as well as the talk related to ours, and the recent contributions by Gumby and myself have made the initiative all the more explicit. Sorry if you didn't get the picture, but I didn't want to insult your intelligence. ''<-- THAT ONE STILL HOLDS, I GUESS. I MEAN, GUMBY GOT THE IDEA ALL BY HIMSELF AND EVEN ADDED THE FIRST HYPERLINK...''
::::::[[User:Geyser|geyser]] 03:27, 27 October 2008 (CET)
:::::::Non-Oni-related humor... is that what's been burning your biscuits all this time about my jokes? Sorry, I didn't think we had a Bungie-only humor rule here. Let's try not to be so insular and snobbish, 'kay? Let's also try not to be insulting, although it's too late for that today -- having an Editing Policy page, a Copyrights page, or any page defining user rights and roles is a ''hell'' of a lot more useful than your original Disclaimers page. And I certainly read that note at the bottom a while back... how on Earth do you think that wording conveys your plans to make a Site Map out of random Oni phrases on a ''Disclaimer'' page? The longer you continue this back-and-forth, the more ridiculous you look. --[[User:Iritscen|Iritscen]] 03:35, 27 October 2008 (CET)
:::::::P.S.: In response to your point about not making the wiki a portal to other crap, I don't plan on doing regularly what I did with the Editing Policy page. But to clarify what I meant above in case you missed it, I don't think we need to be insular as a community, where anything that's not Oni or generally Bungie-related is automatically "crap". I specifically put a note in my Talk page about how a community can go too far in that direction and become a barricaded fortress of in-jokes that only the community elite actually understand. I prefer a more approachable take on humor, personally. But I will try to keep the external links to a bare minimum. --[[User:Iritscen|Iritscen]] 04:27, 27 October 2008 (CET)

:::::::stop bitching or my ninjas will come and find you! [[User:guido|guido]] 18:47, 27 October 2008 (CET)
::::::::Guido, nice of you to watch over us, but don't let it become your only hobby. Also, you're always late, so your assassins probably suck at catching up with their targets, too ^_^ --[[User:Geyser|geyser]] 21:09, 27 October 2008 (CET)

[[Category:Contents]]

Localizations

2026-04-11T23:20:45Z

Iritscen: added a subheading, forced the TOC on, moved a paragraph, and removed some of the editorialization around which dubs are better

{{Hatnote|For a list of the different physical releases of Oni, see [[Releases]]. For a technical examination of the localizations, see [[OBD:Localization]].}}
__TOC__
[[Image:Mac (ES) CD-ROM.jpg|300px|right|thumb|Oni in Castilian Spanish for the Mac.]]
After being developed by [[Bungie West]] in the United States, where the canonical English version was developed, [[Oni]] was translated into several other languages for worldwide distribution.

==Products==
The following languages received full localizations, encompassing the game packaging, the manual, in-game text and in-game voice acting:
*Russian
*French
*Italian
*German
*Spanish
*Japanese

One language received a text-only translation, including translated subtitles, but the voice acting was left in English:
*Chinese

Other languages, perhaps ones with smaller markets, received box-and-manual translations where the game itself was left in the original English:
*Hungarian
*Polish
*Portuguese (Brazilian)
*Slovak

There are almost certainly more languages which received these box-and-manual translations, but they have been poorly documented. If you have evidence of one not mentioned here, please let us know.

Out of the [[seven]] versions of the game that were dubbed, fans have shown the most interest in the Japanese version since Oni is, after all, descended from the world of [[anime]]. The voiceover was done with care, and Konoko was played by well-known voice actress Kotono Mitsuishi (read [[wp:Kotono Mitsuishi|her filmography]] to see her famous credits).

==Releases==
These localizations were then used in multiple physical releases in different territories, as documented at [[Releases]], sometimes including multiple languages on the disc which could be selected during installation. The releases were sometimes made for all three platforms: Windows, Macintosh and PlayStation 2. But sometimes they were only made for Windows, or only Windows and PS2, in territories where Macs were not common.

==Errors==
The localization process was not, of course, without its mishaps. Translators sometimes failed to understand the nature or context of what they were translating. Sometimes the localization office translated and released files that were [[European Mac releases|not meant for release at all]].

A small collection of known errors:
* The Slovakian translators called the [[wp:Hoplite|Hoplite]] Class (blue Strikers) the "[[Slovak game manual#Pages 16-17|Hopping Class]]".
* Spanish translators referred to Griffin as a veterinarian when translating the line "Where's Griffin's pet doctor today?".
* Whoever created the [[OBD:Text encoding#European|European character set]] for Oni didn't know what a Spanish question mark looked like, as seen below.
* Buka's Russian translation probably doesn't have more errors than other translations, but we have a lot more Russian fans to tell us about them ^_^
** In the Deadly Brain scene, instead of telling Konoko, "Turn off those breakers...Fast!", Shinatama tells her, "Disconnect those hackers...Fast!"
** [[Quotes/Speech#Way out|This helpful NPC]] in [[Regional State]] implies that you'll be traveling together when he says "Underground passage, it'll lead us to the command offices."
** The "pet doctor" line which confused the Spanish translators refers to Griffin as "lovely" in this dub.
** The translators apparently had some confusion about the factions in the game and labeled the final mission "TCTF Mountain Compound" on their translated splashscreen (however the Load Game screen gets it right).

No doubt many more delightful [[wikt:gaffe|gaffes]] and [[wikt:false friend|false friends]] await any players who possess both an English copy and a translated copy of Oni and want to take the time to compare them.

{| style="margin-left:auto; margin-right:auto; width:525px;"
|-
|[[Image:Spanish Mac - mystery question mark in SUBT.png|512px]]
|-
|In Spanish Oni's subtitles, all questions begin with [[OBD:Text encoding#European|a novel question mark]] that no Spanish speaker has ever seen. Ending question marks are followed by a period, as are some sentences that already end with periods. As for the quality of the translated dialogue… above, Kerr asks Griffin, "Why do you send her inside?" instead of "What are you sending her into?"
|}

[[Category:Oni history]]

Installation

2026-04-11T21:38:20Z

Iritscen: wording

{{UpdatedForOniX|1.0.0}}
This page will guide you in obtaining, installing and running Oni on practically any computer.

==Obtaining==
===Demo===
You can get the Windows demo [http://mods.oni2.net/node/335 HERE] and the Mac demo [http://mods.oni2.net/node/334 HERE]. They have been repackaged for modern computers, and include all three demo levels.

===Retail===
The game is no longer available to purchase new, but is often for sale secondhand on sites like eBay and Amazon. Make sure you know which platform you're purchasing the game for, as sometimes the game is not carefully labeled by the seller. Unless you're specifically looking for the PlayStation 2 port for some reason, make sure you're buying Oni for Windows or Oni for Mac OS, as those are considered the best versions of the game, and only Windows/Mac Oni is supported by the community and can be modded (note: Mac Oni does not run in macOS 10.15 Catalina or newer due to the loss of 32-bit support, though a 64-bit port is expected eventually).

==Installing==
After installing retail Oni on a modern OS, you will need to install a patch of some kind to run it. The repackaged demos (linked above) come with the needed patches (but note again that Oni currently will not run on Macs in macOS 10.15+).

After following the instructions below to install a retail copy of the game, see {{SectionLink||Patches}}, then check out the [[Troubleshooting]] page if you still encounter problems.

===Windows===
:''The installer on the CD sometimes experiences issues in Windows 10/11; see {{SectionLink|Troubleshooting|Installer}} for how to install Oni manually if you run into a problem, but give the installer a try first.''
When the Oni CD is inserted, the installation will automatically start with the following steps:
*Language selection (maybe): If you have a multilingual version of Oni, you'll be asked to choose the language first.
*Installation process itself: The usual stuff (software license agreement, installation folder selection...).
*Prompt to install DirectX/OpenGL: '''Skip this''', as the version of DirectX or OpenGL provided with Oni is ''very'' old.

A shortcut to Oni is automatically generated and placed on your desktop.

===Mac===
The installer requires Mac OS 9 to run, but you can simply open the CD and drag the "Oni ƒ" folder to the desired place on your hard drive. It's recommended that you then rename the folder to simply "Oni". See the {{SectionLink||Patches}} to get the right version of the Oni game application for your system. If Oni still does not run properly, see [[Troubleshooting]].

===Linux===
Oni was not developed for Linux, but for unofficial support with installing and patching Oni via Wine, see [[Playing in Linux]].

==Post-installation notes==
All of Oni's files will be found in '''C:\Program Files\Oni''' on Windows, and '''wherever you dragged the folder to''' on the Mac. The name of the folder does not have to be "Oni" and the Oni application can be renamed, too, but it is not recommended (some community tools expect the app to be called by its original name). Look at [[Oni (folder)|this page]] for a listing of the files you should have and a description of what they do.

===Windows===
#Oni does not create any important registry entries (just [[Talk:Installation#Registry redux|this one]] for uninstallation purposes). An installation of Oni consists entirely of the "Oni" folder; this makes it easy to back up Oni before experimenting with it.
#The save-game file persist.dat, as well as key_config.txt and Oni's log files, will not be saved next to Oni.exe if you are not running the game as an administrator. See {{SectionLink|Oni (folder)|Warning for non-admins}} to learn more.
#Retail versions of Oni sometimes check for the installation CD, but the original U.S. distribution did not. If you run into a CD check, you can get rid of it by using the Oni.exe that is installed automatically by the [[AE]] (directly downloadable [[Customizing#CD check|here]]) or by using [[OniX]]. Otherwise you need to have either the Oni CD-ROM in the drive or any mounted volume with the same as the CD-ROM.
#If Oni.exe is opened by double-clicking it or its shortcut, it first looks for GameDataFolder (which we call "the GDF") in the same directory as itself. If Oni.exe is launched from the command line, it first looks for the GDF in the current command line directory, and if it's called by a .bat it looks in the location of the .bat that called it. Wherever it starts looking, Oni will also look for a folder in that directory called "OniEngine" and look inside there too for a GameDataFolder. If neither location contains the GDF, Oni progressively checks the parent directories, all the way up to C:\ if necessary, looking for the GDF (or an OniEngine folder with the GDF inside) at each level. OniX behaves the same except that it never looks for OniEngine.

===Mac===
#The Mac app never checks for the Oni disc in the CD-ROM drive.
#When opened, the app first looks for the GameDataFolder in the same directory as itself. If the GDF is not found there, it continues to look in each parent directory up to the root of the hard drive. Unlike in Windows, the app never looks for an OniEngine folder.

==Patches==
Retail Oni will not usually run on modern computers without a patched game application. For the sake of historical completeness, below is a table of Oni's compatibility with every version of Windows and the Mac OS going back to the minimum required OS that was listed for Oni when it launched in 2001. If you still encounter problems after following these directions, see the [[Troubleshooting]] page.

{|class="wikitable" style="margin-left:auto; margin-right:auto;"
|+Windows
!Version
!width=300px|Oni.exe
!width=300px|OniX.exe
|-
|Windows 95, 98, 2000, ME
|The {{Hover|vanilla|text=The original unmodded game}} version of Oni.exe should work out of the box.
|The ''legacy'' build of [[OniX|OniX.exe]] will also work (however the game data conversion script only runs in Windows 2000 or later).
|-
|Windows XP, Vista, 7
|A crashing bug began to manifest in Oni.exe around the time of XP. It is fixed by installing the [[Daodan DLL]] or by installing the [[Anniversary Edition]] modding framework, which includes the DLL.
|The ''legacy'' build of OniX.exe will work without issue.
|-
|Windows 8
|As above, install the Daodan DLL or the AE. Starting with Win8, however, you may experience mouse-pointing issues, which requires turning off display scaling for Oni (instructions [[Mouse control issues#Camera|HERE]]).
|The ''legacy'' build of OniX.exe will work without issue.
|-
|Windows 10, 11
|As above, install the Daodan DLL or the AE, and turn off display scaling if you have mouse issues.
|The ''modern'' build of OniX.exe is designed to work on Windows 10 and 11.
|}

{|class="wikitable" style="margin-left:auto; margin-right:auto;"
|+Macintosh
!Version
!width=530px|Notes
|-
|Mac OS 8.6–9.x
|The original version of Oni should work out of the box.
|-
|Mac OS X 10.0–10.6
|Use the community-patched version of The Omni Group's Mac OS X port found [[OMNI|HERE]].
|-
|Mac OS X 10.7–macOS 10.14
|Use Feral Interactive's Intel Mac port found [[FERAL|HERE]].
|-
|macOS 10.15+
|32-bit apps are no longer supported, so you must boot in macOS 10.14 or below to play Oni.
|}

==Customization==
For information on customizing the controls and making other changes to Oni's settings, see [[Customizing]].

==Mods==
The community has produced a number of mods. You can browse the mods on the [http://mods.oni2.net Mod Depot], but you might just want to start at the [[Anniversary Edition]] page since mods are generally installed through the Anniversary Edition's Installer.

The central introduction to making your own mods is found [[Introduction to modding|HERE]].

[[Category:Oni Support]]

OBD:ONCC

2026-04-09T01:39:22Z

Iritscen: fixed hex transcription error

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

[[Image:oncc_a.gif]]

==Air settings==
{{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
:The fields 0x008 and 0x01C 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 the gravity setting at 0x00C and the actual "fall timer" is the jump timer at 0x01E.

;Jump 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 settings==
{{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 settings (unused)==
These fields were deprecated at some point in Oni's development and do nothing.
{{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 settings==
These fields were deprecated at some point in Oni's development and do nothing.
{{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 settings==
These fields were deprecated at some point in Oni's development and do nothing.
{{Table}}
{{OBDth}}
{{OBDtr| 0x05C | float |FFFFC8| 00 00 A0 40 | 5.000000 | "distance XZ"; unused (always 5) }}
{{OBDtr| 0x060 | float |FFFFC8| 00 00 80 3F | 1.000000 | "distance Y"; unused (always 1) }}
|}

==Inventory settings==
{{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 settings==
Squares of the distance from the camera at which each LOD kicks in; see {{SectionLink|XML:ONCC|<LODConstants>}} for an explanation of this table, and {{SectionLink|Graphics|LOD}} for the full calculation on which LOD to use.
{{Table}}
{{OBDth}}
{{OBDtr| 0x068 | float |C8FFFF| 00 10 3D 48 |193600.000000| min. distance for super-low LOD; always 440² }}
{{OBDtr| 0x06C | float |C8FFFF| 00 10 3D 47 | 48400.000000| min. distance for low LOD; always 220² }}
{{OBDtr| 0x070 | float |C8FFFF| 00 10 3D 46 | 12100.000000| min. distance for medium LOD; always 110² }}
{{OBDtr| 0x074 | float |C8FFFF| 00 00 00 00 | 0.000000| min. distance for high LOD; always 0 }}
{{OBDtr| 0x078 | float |C8FFFF| 00 00 00 00 | 0.000000| min. distance for super-high LOD; always 0 }}
|}

==Hurt sound settings==
The numbers below cannot be understood without some elaboration. 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 of playing a pain sound if char. has not been hurt before (always 35) }}
{{OBDtr| 0x07E | uint16 |FFC8FF| 5A 00 | 90 | maximum % chance of playing a pain sound if char. has not been hurt before (always 90) }}
{{OBDtr| 0x080 | uint16 |FFC8FF| 0F 00 | 15 | damage threshold; used to calculate a percentage chance of pain sound between min % and max % (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 settings==
{{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 except for ninjabots, ninjas and super_ninja, which use 2.0 }}
{{OBDtr| 0x130 | uint16 |64AAAA| 06 00 | 6 | minimum number of frames AI can remain dazed (in fallen position) when it is knocked down }}
{{OBDtr| 0x132 | uint16 |64AAAA| 18 00 | 24 | maximum number of frames AI can remain dazed (in fallen position) when it is knocked down (actual number used is picked randomly from the range {min ... max}) }}
{{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 - running weapon pickup enabled; bit not used; only 0x2A8 is used for the running pickup chance

;AI rotation speed factor
:A rotation speed of 1 is roughly one 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==
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 {{SectionLink||Vision field}} 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.

==Body settings==
{{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 | 0 | runtime: flag meaning that modifier type has been set by looking up modifier name and impact types have been set by looking up impact names; runtime only }}
{{OBDtr| 0x441 | uint8 |C5FF8A| 00 | 0 | padding }}
{{OBDtr| 0x442 | uint16 |C5FF8A| 00 00 | 0 | runtime: modifier type }}
{{OBDtr2|0x444 | char[16] |C0C0C0| Light | modifier name, used to look up modifier type }}
{{OBDtrBK|1=Array of 15 impact elements: first element }}
{{OBDtr2|0x454 | char[128]|FF0080| Footstep_Walk | impact name, used to look up impact type (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 | 65536 | runtime: impact type (comes from 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 | name of particle spawned on death; 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 | "feet bits"; 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 F7 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 | whether character is lefthanded (true for Ninjas, Ninjabots, Comguys) }}
{{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) }}
|}

;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}}

XML:TRSC

2026-04-08T00:59:34Z

Iritscen: wording

{{XML_File_Header | prev=TRMA | type=TRSC | next=TSFF | name=(Aiming) Screen Collection}}

==General information==
*TRSCs can be global (level0_Final.dat) or local (level''X''_Final.dat). The commonly used ones, '''TRSCcomguy_screens''', '''TRSCkonoko_screens''' and '''TRSCstriker_screens''', are global whereas the rest are found in the levels where the characters appear who use them: '''TRSCmuro_screens''', '''TRSCninja_screens''', '''TRSCred_screens''' and '''TRSCtanker_screens'''.
*TRSCs are lists of all the aiming screens ([[XML:TRAS|TRAS]]) that can be applied to a character, based on their current animation state.
*Each [[XML:ONCC|ONCC]] links to one TRSC.

==Example==
TRSCkonoko_screens:
<?xml version="1.0" encoding="utf-8"?>
<Oni>
<TRSC id="0">
<AimingScreens>
<Link>TRASKONPISaim_screen_run</Link>
<Link>TRASKONPISaim_screen_ss_lt</Link>
<Link>TRASKONPISaim_screen_ss_rt</Link>
<Link>TRASKONPISaim_screen_crouch</Link>
<Link>TRASKONPISaim_screen_stand</Link>
<Link>TRASKONOKOaim_screen_stand</Link>
<Link>TRASKONOKOaim_screen_crouch</Link>
<Link>TRASKONRIFaim_screen_stand</Link>
<Link>TRASKONRIFaim_screen_crouch</Link>
<Link>TRASSTRRIFaim_screen_crouch_r</Link>
<Link>TRASKONRIFaim_screen_run</Link>
<Link>TRASSTRPISaim_screen_crouch_r</Link>
<Link>TRASKONCOMaim_screen_stand</Link>
</AimingScreens>
</TRSC>
</Oni>

TRSCs have a variable number of aiming screens in them; as few as 11 (TRSCninja_screens) and as many as 14 (TRSCstriker_screens). What happens if a character's animation state is not covered by any TRAS?

{{XML}}

XML:File types

2026-04-08T00:58:52Z

Iritscen: wording

{{Hatnote|See [[Introduction to modding]] if you are new to modding.}}
{{XML Home}}
Following is an overview of each of the 65 significant data types (45 basic, 16 OBJC, and 4 BINA) and 43 sub-types that they rely on.

{|style="border:1px solid #AAA; float:left"
|width="250px" style="text-align:center;"|'''Legend'''
|-
|Documentation status:
:[[Image:Aqua Dot-Green.png]] Available
:[[Image:Aqua Dot-Yellow.png]] Incomplete
:[[Image:Aqua Dot-Red.png]] Unavailable, see [[OBD:File types|OBD docs]] if you wish to mod the file type
|-
|Location:
:vanilla: An un-modded retail copy of Oni
:AE: The [[AE]] reorganizes some data
:global: File(s) found in level0_Final
:local: File(s) may be in level[1-19]_Final
:both: File(s) may be in either place
|}

{|style="border:1px solid #AAA; margin-left:275px"
|colspan="4" style="text-align:center; max-width:950px"|'''Jump Table'''
|-
|style="vertical-align:top; border:1px solid #AAA; border-width:0px 0px 0px 0px; padding-right:20px"|
'''A-B''' • [[#AKEV|ABNA]], [[#AKEV|AGQC]], [[#AKEV|AGQG]], [[#AKEV|AGQR]], [[#AISA|AISA]], [[#AKEV|AKAA]], [[#AKEV|AKBA]], [[#AKEV|AKBP]], [[#AKEV|AKEV]], [[#AKEV|AKOT]], [[#AKEV|AKVA]], '''[[#BINA|BINA]]'''

|style="vertical-align:top; border:1px solid #AAA; border-width:0px 0px 0px 0px; padding-right:20px"|
'''C-E''' • [[#ONCC|CBPI]], [[#ONCC|CBPM]], [[#BINA/OBJC/CHAR|CHAR]], [[#BINA/OBJC/CMBT|CMBT]], [[#CONS|CONS]], [[#BINA/OBJC/CONS|CONS '''(OBJC)''']], [[#ONLV|CRSA]], [[#DOOR|DOOR]], [[#BINA/OBJC/DOOR|DOOR '''(OBJC)''']], [[#DPge|DPge]], [[#ONLV|ENVP]]

|style="vertical-align:top; border:1px solid #AAA; border-width:0px 0px 0px 0px; padding-right:20px"|
'''F-K''' • [[#FILM|FILM]], [[#BINA/OBJC/FLAG|FLAG]], [[#BINA/OBJC/FURN|FURN]], [[#HPge|HPge]], [[#IDXA|IDXA]], [[#IGHH|IGHH]], [[#IGPA|IGPA]], [[#IGPG|IGPG]], [[#IGSA|IGSA]], [[#IGSt|IGSt]], [[#Impt|Impt]], [[#IPge|IPge]], [[#DPge|KeyI]]

|style="vertical-align:top; border:1px solid #AAA; border-width:0px 0px 0px 0px"|
'''M-N''' • [[#OBAN|M3GA]], [[#M3GM|M3GM]], [[#BINA/OBJC/MELE|MELE]], [[#Mtrl|Mtrl]], [[#BINA/OBJC/NEUT|NEUT]]

|-

|style="vertical-align:top; border:1px solid #AAA; border-width:0px 0px 0px 0px; padding-right:20px"|
'''O''' • [[#OBAN|OBAN]], '''[[#BINA/OBJC|OBJC]]''', [[#OBAN|OBOA]], [[#OFGA|OFGA]], [[#ONCC|ONCC]], [[#ONCC|ONCP]], [[#ONCV|ONCV]], [[#ONGS|ONGS]], [[#ONCC|ONIA]], [[#BINA/ONIE|ONIE]], [[#ONLD|ONLD]], [[#ONLV|ONLV]], [[#ONLV|ONOA]], [[#ONSK|ONSK]], [[#ONVL|ONVL]], [[#ONWC|ONWC]], [[#OPge|OPge]], [[#SNDD|OSBD]], [[#AKEV|OTIT]], [[#AKEV|OTLF]]

|style="vertical-align:top; border:1px solid #AAA; border-width:0px 0px 0px 0px; padding-right:20px"|
'''P-S''' • [[#BINA/PAR3|PAR3]], [[#BINA/OBJC/PART|PART]], [[#BINA/OBJC/PATR|PATR]], [[#AKEV|PLEA]], [[#PNTA|PNTA]], [[#PSpc|PSpc]], [[#PSpL|PSpL]], [[#PSUI|PSUI]], [[#BINA/OBJC/PWRU|PWRU]], [[#AKEV|QTNA]], [[#BINA/SABD|SABD]], [[#SNDD|SNDD]], [[#BINA/OBJC/SNDG|SNDG]], [[#StNA|StNA]], [[#SUBT|SUBT]]

|style="vertical-align:top; border:1px solid #AAA; border-width:0px 0px 0px 0px; padding-right:20px"|
'''T''' • [[#BINA/TMBD|TMBD]], [[#TRAC|TRAC]], [[#TRAM|TRAM]], [[#TRAS|TRAS]], [[#TRBS|TRBS]], [[#TRBS|TRCM]], [[#TRBS|TRGA]], [[#TRGE|TRGE]], [[#BINA/OBJC/TRGV|TRGV]], [[#TRBS|TRIA]], [[#TRIG|TRIG]], [[#BINA/OBJC/TRIG|TRIG '''(OBJC)''']], [[#TRMA|TRMA]], [[#TRSC|TRSC]], [[#TRBS|TRTA]], [[#TSFF|TSFF]], [[#TSFF|TSFL]], [[#TSFF|TSFT]], [[#TSFF|TSGA]], [[#TURR|TURR]], [[#BINA/OBJC/TURR|TURR '''(OBJC)''']], [[#TXMP|TXAN]], [[#TXCA|TXCA]], [[#AKEV|TXMA]], [[#TXMB|TXMB]], [[#TXMP|TXMP]], [[#TxtC|TxtC]]

|style="vertical-align:top; border:1px solid #AAA; border-width:0px 0px 0px 0px"|
'''V-W''' • [[#M3GM|VCRA]], [[#BINA/OBJC/WEAP|WEAP]], [[#WMCL|WMCL]], [[#WMDD|WMDD]], [[#WMM|WMM_]], [[#WMM|WMMB]], [[#WPge|WPge]]
|}

{|width="100%" style="background-color:#F9F9F9; border:1px solid #AAA"
!width="10px" style="text-align:left; vertical-align:center; background-color:#EEEEEE"|Tag
!style="text-align:left; vertical-align:center; background-color:#EEEEEE"|[[Image:Aqua Dot-Grey.png]]
!width="250px" style="text-align:left; vertical-align:center; background-color:#EEEEEE"|Name
!width="200px" style="text-align:left; vertical-align:center; background-color:#EEEEEE"|File name(s)
!width="125px" style="text-align:left; vertical-align:bottom; background-color:#EEEEEE"|Location (vanilla)
!style="text-align:left; vertical-align:bottom; background-color:#EEEEEE"|Location (AE)
{{XMLtype|AISA|AI Character Setup Array
|yes
|AISAlevel##_scripts
|local
|local
|This file type was probably in the process of being replaced by [[#BINA/OBJC/CHAR|CHAR]] when Oni shipped, but it is still used for a few cutscene characters.}}
{{XMLtype|AKEV|Akira Environment
|some
|AKEV...
|local
|local
|It's the 3D level model. Many subtypes are used for the actual 3D data -- ABNA, AGDB, AGQG, AGQC, AGQR, AKAA, AKBA, AKBP, AKDA, AKOT (which in turn uses OTIT, OTLF, and QTNA), AKVA, IDXA, PLEA, PNTA, TXCA, and TXMA; these types do not have separate XML documentation because they export as a part of AKEV. Some of these types are also used by [[#M3GM|M3GM]]. AKEV exports as a Collada (.dae) file, meant to be edited in a 3D modeler like [[Blender]].}}
{{XMLtype|CONS|Console
|some
|CONSconsole...
|global
|global
|There are only three of these models for the consoles used in all of Oni, as documented in [[Data console]], though the picture ([[#TXMP|TXMP]]) displayed on a specific console varies.}}
{{XMLtype|DOOR|Door
|yes
|DOOR...
|global
|global
|There are 48 types of doors, defined globally for use in the levels.}}
{{XMLtype|DPge|Diary Page
|yes
|DPgelev_##_pg_##
|global
|global
|As seen in the Diary tab of the Data Comlink. The actual text is in a linked IGPG (see [[#OPge|OPge]] for more info; also used by [[#HPge|HPge]], [[#IPge|IPge]], and [[#WPge|WPge]]). The diary page is used for both diary-style entries and move pages, which are both unlocked when reaching the level number contained in this data. When being used as a move page, the sequence of actions that produce the move can be conveyed with the use of icons ([[#TXMP|TXMP]]s provided by KeyI), however this functionality is unused in Oni's existing data.}}
{{XMLtype|FILM|Film
|yes
|FILM...
|local
|local
|A record of a character's movements, created by a developer recording his gameplay, and played back in cutscenes to make an AI perform complex actions. During playback, AIs have no AI. ^_^}}
{{XMLtype|HPge|Help Page
|yes
|HPgehelp_pg_01
|global
|global
|The Help tab of the Data Comlink labels the in-game UI and reminds the player of the controls (but only the default bindings, regardless of what the player is actually using...). The actual text is in a linked IGPG (also used by [[#DPge|DPge]], [[#OPge|OPge]], [[#IPge|IPge]], and [[#WPge|WPge]]).}}
{{XMLtype|IDXA|Index Array
|yes
| --
|both
|both
|This is just a disambiguation page which points to the higher-level types that use IDXA (AKEV, ONLV, M3GM), because IDXAs do not get exported as standalone files by OniSplit.}}
{{XMLtype|IGHH|IGUI HUD Help
|yes
|IGHHhud_help_info
|global
|global
|The Help tab of the Data Comlink labels the in-game UI using the text found here and the overlay textures it links to. (IGUI is "In-Game User Interface".)}}
{{XMLtype|IGPA|IGUI Page Array
|yes
| --
|both
|both
|This is just a disambiguation page which points to the higher-level types that use IGPA (DPge, HPge, IPge, OPge, WPge, TxtC), because IGPAs do not get exported as standalone files by OniSplit.}}
{{XMLtype|IGPG|IGUI Page
|yes
| --
|both
|both
|This is just a disambiguation page which points to the higher-level types that use IGPG (DPge, HPge, IPge, OPge, WPge, TxtC), because IGPGs do not get exported as standalone files by OniSplit.}}
{{XMLtype|IGSA|IGUI String Array
|yes
| --
|both
|both
|This is just a disambiguation page which points to the higher-level types that use IGSA (DPge, HPge, IPge, OPge, WPge, TxtC), because IGSAs do not get exported as standalone files by OniSplit.}}
{{XMLtype|IGSt|IGUI String
|yes
| --
|both
|both
|This is just a disambiguation page which points to the higher-level types that use IGSt (DPge, HPge, IPge, OPge, WPge, TxtC), because IGSts do not get exported as standalone files by OniSplit.}}
{{XMLtype|Impt|Impact
|yes
|Impt...
|global
|global
|This file is used to build up a hierarchy of impacts. See [[#BINA/ONIE|BINA/ONIE]] for more information.}}
{{XMLtype|IPge|Item Page
|yes
|IPge...
|local
|local
|As items are picked up, their Item Pages are displayed on the Items tab of the Data Comlink. The actual text and image is found in a linked IGPG (see [[#OPge|OPge]] for more info; also used by [[#DPge|DPge]], [[#HPge|HPge]], and [[#WPge|WPge]]).}}
{{XMLtype|M3GM|Geometry
|yes
|M3GM...
|both
|both (more are global)
|A basic unit of 3D geometry used by anything that can have a physical shape, such as character models ([[#TRBS|TRBS]]), consoles ([[#CONS|CONS]]), animated objects ([[#OBAN|OBAN]]) and particles ([[#BINA/PAR3|PAR3]]). The building blocks of the geometry are the types IDXA, PNTA, TXCA and VCRA (these are all exported under M3GM so do not have separate XML documentation), and the texture is provided by [[#TXMP|TXMP]].}}
{{XMLtype|Mtrl|Material
|yes
|Mtrl...
|global
|global
|These files are used to build up a hierarchy of materials. See [[#BINA/ONIE|BINA/ONIE]] for more information.}}
{{XMLtype|OBAN|Object Animation
|yes
|OBAN...
|both
|both
|Yes, this is used to animate objects, but also characters and cutscene cameras. Uses OBOA (also used by [[#ONLV|ONLV]]) to store the physics settings, and the OBOA in turn uses an M3GA, which is an array of [[#M3GM|M3GMs]], to store the actual geometry.}}
{{XMLtype|OFGA|Object Furniture Geometry Array
|yes
|OFGA...
|N/A
|N/A
|Used to import objects with no functions. (Doors, consoles, etc. get imported as [[#BINA/OBJC|object lists]]. See [[XML:ONLV]] for more information.)}}
{{XMLtype|ONCC|Oni Character Class
|yes
|ONCC...
|local
|global
|This is where a class of character (Konoko, Striker, etc.) is assigned its weapon skill, behavior ID, vision radius, jumping height, sounds, 3D model ([[#TRBS|TRBS]]), animation collection ([[#TRAC|TRAC]]), textures ([[#TRMA|TRMA]]), and much more. The XML file contains also the character's body part material (CBPM), body part impacts (CBPI), and particles for animations (ONCP and ONIA), so these types are also documented on this page.}}
{{XMLtype|ONCV|Oni Character Variant
|yes
|ONCV...
|global
|global
|Used to create a pool of characters from which an AI can be randomly spawned, in order to create a natural variation in appearance. A flag in a [[#BINA/OBJC/CHAR|CHAR]] determines which variant the character falls under. It can be also used to upgrade characters on the Hard difficulty level, also determined by a flag in the CHAR.}}
{{XMLtype|ONGS|Oni Game Settings
|yes
|ONGSgame_settings
|global
|global
|Here you can modify the game's health bar, hypo spray strength, [[Difficulty modes|game difficulty]], autoprompts (text messages when picking up a new kind of item), etc.}}
{{XMLtype|ONLD|Oni Game Level Descriptor
|yes
|ONLDlevel_##
|global
|global
|Contains a level's number, the number of the next level, and the level's name as it appears on the Load Game screen.}}
{{XMLtype|ONLV|Oni Game Level
|yes
|ONLV...
|local
|local
|The top of the hierarchy when it comes to level data. Holds the name of the BSL folder with the scripts for this level, links to the environmental model ([[#AKEV|AKEV]]), animated objects ([[#OBAN|OBOA]]), skybox ([[#ONSK|ONSK]]) and AIs to spawn (well, the ones in [[#AISA|AISA]]; the ones in [[#BINA/OBJC/CHAR|CHAR]] need no link from here), and more. These type links as well as the corpse array (CRSA), environmental particles (ENVP), and gunk data (ONOA, which uses IDXA) will be exported together in XML. ONLV also links to six obsolete types which will not be exported: AITR, OBDC, ONFA, ONMA, [[XML:ONSA|ONSA]] and ONTA.}}
{{XMLtype|ONSK|Oni Sky Class
|yes
|ONSK...
|local
|global
|It's essentially a box of textures that surrounds the level, so you will need five images for the top, north, east, south and west. The bottom has no image.}}
{{XMLtype|ONVL|Oni Variant List
|yes
|ONVLvariant_list
|global
|global
|It's used to randomize characters' appearances in conjunction with [[#ONCV|ONCV]].}}
{{XMLtype|ONWC|Oni Weapon Class
|yes
|ONWCw...
|global
|global
|Describes a weapon's primary and secondary firing mode and more, and links to its particles ([[#BINA/PAR3|PAR3]]), its 3D model ([[#M3GM|M3GM]]) and textures ([[#TXMP|TXMP]]).}}
{{XMLtype|OPge|Objective Page
|yes
|OPgelevel_##
|local
|local
|This is the wrapping type for the text that appears in the Objective tab of the Data Comlink. The actual text is found by following the objective page's link to an IGPA (also used by [[#TxtC|TxtC]]), which is an array of IGPGs (also used by [[#DPge|DPge]], [[#HPge|HPge]], [[#IPge|IPge]], and [[#WPge|WPge]]) which contain links to arrays of text strings (IGSA, which point to the individual strings, IGSt, which link to the font family, [[#WMDD|TSFF]]) and links to [[#TXMP|TXMPs]] for illustrations.}}
{{XMLtype|PNTA|3D Point Array
|yes
| --
|both
|both
|This is just a disambiguation page which points to the higher-level types that use PNTA (AKEV, M3GM), because PNTAs do not get exported as standalone files by OniSplit.}}
{{XMLtype|PSpc|Part Specification
|yes
|PSpc...
|both
|both
|Specifies coordinates in a certain [[#TXMP|TXMP]] which contains a collection of UI elements. The coordinates are used to cut out specific elements for use in drawing the windows in the game.}}
{{XMLtype|PSpL|Part Specification List
|yes
|PSpLpartspec_list
|global
|global
|Links to the [[#PSpc|PSpc]] used for the plain-color background of a particular UI (the in-game UI uses black and the out-game UI uses transparency).}}
{{XMLtype|PSUI|Part Specification UI
|yes
|PSUIpsui_...
|global
|global
|Specifies the [[#PSpc|PSpcs]] used to paint a certain style of UI. There are only two of these files in Oni, and only PSUIpsui_oniUI is actually used.}}
{{XMLtype|SNDD|Sound Data
|yes
|SNDD...
|local
|global
|These are all the sounds and music tracks that Oni can play.}}
{{XMLtype|StNA|String Array
|yes
|StNA...
|global
|global
|StNA files are obsolete. However, on this XML page you'll find collections of flags used by [[#TRAM|TRAMs]].}}
{{XMLtype|SUBT|Subtitle Array
|yes
|SUBT...
|global
|global
|An array of strings used for subtitles in Oni. This is just here for informational purposes, because subtitle files are extracted to TXT files, not XML.}}
{{XMLtype|TRAC|Totoro Animation Collection
|yes
|TRAC...
|both
|global
|Used to build a hierarchy of moves ([[#TRAM|TRAMs]]) which form a weighted moveset in combination with any parent TRACs a character's TRAC inherits from.}}
{{XMLtype|TRAM|Totoro Animation Sequence
|some
|TRAM...
|both
|global
|The core 3D animation data for character moves. Exports to Collada (.dae) + XML. The XML file contains the animation's Oni-specific flags, links to particles, and so on.}}
{{XMLtype|TRAS|Totoro Aiming Screen
|yes
|TRAS...
|both
|global
|The pose keyframes defined here are interpolated and overlaid on characters when they aim with weapons.}}
{{XMLtype|TRBS|Totoro Body Set
|yes
|TRBS...
|local
|global
|The metadata for the 3D model of a character. Character classes ([[#ONCC|ONCCs]]) link to these. The 3D data can be imported/exported as Collada (.dae) files, but using the ONCC for this might be preferable so that you get all related character data in XML on the side. The structure of the body at each individual detail level is found in the linked TRCM, which links to TRGA for the geometry of each body part, to TRTA for the relative location of each body part, and to TRIA for the hierarchical relationship of the body parts.}}
{{XMLtype|TRGE|Trigger Emitter
|yes
|TRGEtrigger_emitter_0
|global
|global
|This file links to the one 3D model ([[#M3GM|M3GM]]) used for all laser triggers. Used by [[#TRIG|TRIG]].}}
{{XMLtype|TRIG|Trigger
|some
|TRIG...
|global
|global
|A laser trigger class.}}
{{XMLtype|TRMA|Texture Map Array
|yes
|TRMA...
|local
|global
|The list of textures used for each [[XML:TRBS#Standard_TRIA_hierarchy|body part]] of a certain character.}}
{{XMLtype|TRSC|(Aiming) Screen Collection
|yes
|TRSC...
|both
|global
|Essentially just links to the [[#TRAS|TRAS]] (aiming screen) of a character.}}
{{XMLtype|TSFF|Font Family
|yes
|TSFFTahoma
|global
|global
|Oni's single font family, Tahoma, which in turn links to font language settings (TSFL) and the font data itself (TSFT, which links to TSGA for the coordinates of each letter in the TSFT data).}}
{{XMLtype|TURR|Turret
|yes
|TURR...
|global
|global
|A class of turret. The actual 3D geometry is in a linked [[#M3GM|M3GM]].}}
{{XMLtype|TXCA|Texture Coordinate Array
|yes
| --
|both
|both
|This is just a disambiguation page which points to the higher-level types that use TXCA (AKEV, M3GM), because TXCAs do not get exported as standalone files by OniSplit.}}
{{XMLtype|TXMB|Texture Map Big
|yes
|TXMB...
|both
|both
|A series of [[#TXMP|TXMPs]] to join in order to display a splashscreen, like the Main Menu background and the level intro/win/loss screens.}}
{{XMLtype|TXMP|Texture Map
|yes
|TXMP...
|both
|global except for textures used by specific levels
|This type covers all images in Oni (except the ones larger than 256x256, which are built with [[#TXMB|TXMB]]). When a texture is animated, it will have a link to TXAN, which simply contains metadata about the animation; the actual image data is still in the TXMP.}}
{{XMLtype|TxtC|Text Console
|yes
|TxtClevel_...
|local
|local
|The source of the text for a given console. The actual text is found by following the link to an IGPA (also used by [[#OPge|OPge]]), which is an array of IGPG (also used by [[#DPge|DPge]], [[#HPge|HPge]], [[#IPge|IPge]], and [[#WPge|WPge]]) that contains the actual text.}}
{{XMLtype|WMCL|Window Manager Cursor List
|yes
|WMCLcursor_list
|global
|global
|Simply links to the [[#PSpc|PSpc]] which links to the image used for the mouse pointer that appears in Oni.}}
{{XMLtype|WMDD|Window Manager Dialog Data
|yes
|WMDD...
|global
|global
|Describes the layout of UI screens like the Main Menu. Uses [[#WMM|WMM_]] for pop-up menus, and links to the desired font family (TSFF, also used by [[#OPge|IGPG]]). Because Oni's UI is partially hardcoded, adding new buttons would require engine modding.}}
{{XMLtype|WMM|Window Manager Menu
|yes
|WMM...
|global
|global
|Dropdown menus used in [[#WMDD|WMDDs]]. Most of the WMM_s and the sole WMMB in Oni (a menu bar that uses WMM_ for its menus) are development relics.|display=WMM_}}
{{XMLtype|position=bottom|WPge|Weapon Page
|yes
|WPgew...
|global
|global
|This is the source for the text and images that appear in the Weapons tab of the Data Comlink. The actual text and image is found in a linked IGPG (see [[#OPge|OPge]] for more info; also used by [[#DPge|DPge]], [[#HPge|HPge]], and [[#WPge|WPge]]).}}
|}

==BINA==
{|width="100%" style="background-color:#F9F9F9; border:1px solid #AAA"
!width="10px" align="left" style="background-color:#EEEEEE"|Tag
!align="left" style="background-color:#EEEEEE"|[[Image:Aqua Dot-Grey.png]]
!width="250px" align="left" style="background-color:#EEEEEE"|Name
!width="200px" align="left" style="background-color:#EEEEEE"|File name(s)
!width="125px" align="left" style="background-color:#EEEEEE"|Location (vanilla)
!align="left" style="background-color:#EEEEEE"|Location (AE)
{{XMLtype|BINA/ONIE|ImpactEffects
|some
|BINAEINOimpact_effects
|global
|global
|A list of all impact effects which can happen in the game; this includes weapon particles, hand-to-hand combat, and footsteps. The impact effect is selected according the type of impact ([[#Impt|Impt]]) and the material ([[#Mtrl|Mtrl]]) which is hit.}}
{{XMLtype|BINA/PAR3|Particles
|some
|BINA3RAP...
|global
|global
|A type of particle which can be spawned in the game, used by weapons to deal damage, used for lens flares, etc. The list of the specific particles spawned in a certain level is a [[#BINA/OBJC/PART|PART]].}}
{{XMLtype|BINA/SABD|SoundAnims
|some
|BINADBAS...
|global
|global
|A list of the sounds to be played for an animation type. There is one of these for each character variant ([[#ONCV|ONCV]]).}}
{{XMLtype|position=bottom|BINA/TMBD|TextureMaterials
|yes
|BINADBMTTextureMaterials
|global
|global
|A list of the materials ([[#Mtrl|Mtrl]]) assigned to each texture map ([[#TXMP|TXMP]]). Used by [[#BINA/ONIE|ONIE]].}}
|}

==BINA/OBJC==
{|width="100%" style="background-color:#F9F9F9; border:1px solid #AAA"
!width="10px" align="left" style="background-color:#EEEEEE"|Tag
!align="left" style="background-color:#EEEEEE"|[[Image:Aqua Dot-Grey.png]]
!width="250px" align="left" style="background-color:#EEEEEE"|Name
!width="200px" align="left" style="background-color:#EEEEEE"|File name(s)
!width="125px" align="left" style="background-color:#EEEEEE"|Location (vanilla)
!align="left" style="background-color:#EEEEEE"|Location (AE)
{{XMLtype|BINA/OBJC/CHAR|Character
|some
|BINACJBOCharacter
|local
|local
|List of characters in a specific level, containing their position, script function names, weapon, ammunition, items, team, melee ID, etc.}}
{{XMLtype|BINA/OBJC/CMBT|Combat
|some
|BINACJBOCombat
|global
|global
|List of combat profiles for global use, containing conditions that govern the AI's melee, weapon combat, and retreat behavior, based on factors like distance and the enemy's reactions.}}
{{XMLtype|BINA/OBJC/CONS|Console
|yes
|BINACJBOConsole
|local
|local
|List of consoles in a specific level, containing their position, script name (ID), screen images, and script function names. Consoles are used to open doors, trigger alarms, or provide information.}}
{{XMLtype|BINA/OBJC/DOOR|Door
|yes
|BINACJBODoor
|local
|local
|List of doors in a specific level, containing their conditions for when a door opens (e.g., is the action key required?), and what events are triggered when the door is opened.}}
{{XMLtype|BINA/OBJC/FLAG|Flag
|yes
|BINACJBOFlag
|local
|local
|List of flags in a specific level, containing their position. Flags are used by level scripts and patrol paths.}}
{{XMLtype|BINA/OBJC/FURN|Furniture
|yes
|BINACJBOFurniture
|local
|local
|List of pieces of furniture in a specific level. This file type can be used to import level objects.}}
{{XMLtype|BINA/OBJC/MELE|Melee Profile
|some
|BINACJBOMelee Profile
|global
|global
|List of melee profiles for global use. A melee profile contains a simple program that determines how the AI uses its combat moves.}}
{{XMLtype|BINA/OBJC/NEUT|Neutral
|yes
|BINACJBONeutral
|local
|local
|List of neutral character behaviors in a specific level. Every character has a melee, combat and neutral behavior ID. It determines whether a non-player character (NPC) talks to you and whether they give you a power-up.}}
{{XMLtype|BINA/OBJC/PART|Particle
|yes
|BINACJBOParticle
|local
|local
|List of particles in a specific level, containing their position, script name and scaling.}}
{{XMLtype|BINA/OBJC/PATR|Patrol Path
|yes
|BINACJBOPatrol Path
|local
|local
|List of patrol paths in a specific level, containing an ID which is used by [[#BINA/OBJC/CHAR|CHAR]] and the scripting command "ai2_dopath".}}
{{XMLtype|BINA/OBJC/PWRU|PowerUp
|yes
|BINACJBOPowerUp
|local
|local
|List of power-ups (such as ammo, force shields and hypo sprays) in a specific level which are spawned at level load, containing their position.}}
{{XMLtype|BINA/OBJC/SNDG|Sound
|yes
|BINACJBOSound
|local
|local
|List of sound groups in a specific level. Sound groups are the invisible spheres which contain ambient sounds. If you get close to a machine and you hear a sound, that's because of a sound group.}}
{{XMLtype|BINA/OBJC/TRGV|Trigger Volume
|yes
|BINACJBOTrigger Volume
|local
|local
|List of trigger volumes in a specific level. They are invisible areas which trigger functions in a script when entered.}}
{{XMLtype|BINA/OBJC/TRIG|Trigger
|yes
|BINAJCBOTrigger
|local
|local
|List of laser triggers in a specific level. There are several forms of triggers, and they can trigger not only turrets ([[#TURR|TURR]]), but also script functions in the level.}}
{{XMLtype|BINA/OBJC/TURR|Turret
|yes
|BINACJBOTurret
|local
|local
|List of turrets in a specific level. Note that their pods are part of the level geometry. Spawn one manually and it might be located somewhere in the air. Determines their head's position, the weapon inside the turret head, and the team ID to target.}}
{{XMLtype|position=bottom|BINA/OBJC/WEAP|Weapon
|yes
|BINACJBOWeapon
|local
|local
|List of weapons in a specific level, determining their spawn location at level load.}}
|}

[[Category:XML data docs]]

OBD:TRSC

2026-04-08T00:58:13Z

Iritscen: wording

{{OBD_File_Header | type=TRSC | prev=TRMA | next=TRTA | name=(Aiming) Screen Collection | family=Character | align=center}}

Some of the TRSC files are 0 byte files. This means that Oni will take the information out of the TRSC files of level 0. Below is an example of a TRSC file in level 0.

[[Image:trsc_a.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x00 | res_id |FF0000| 01 CE 09 00 | 2510 | 02510-konoko_screens.TRSC }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr| 0x08 | char[22] |00FF00| AD DE | dead | unused }}
{{OBDtr| 0x1E | int16 |00FFFF| 0D 00 | 13 | array size }}
{{OBDtrBK}}
{{OBDtr| 0x00 | link |FFC8C8| 01 C1 09 00 | 2497 | link to 02497-KONPISaim_screen_run.[[OBD:TRAS|TRAS]] }}
|}

{{OBD_File_Footer | type=TRSC | prev=TRMA | next=TRTA | name=(Aiming) Screen Collection | family=Character}}

{{OBD}}

Oni (folder)

2026-04-06T17:06:09Z

Iritscen: tweaked table until I got everything to fit on a row of a single line height; added trivia about the Windows installer that I learned recently; stopped using Th template

{{UpdatedForOniX|1.0.0}}
This is a browseable representation of an '''[[Oni]]''' installation's file hierarchy under Windows and macOS. You can use it to verify that you have all the needed files; it can also educate you on the details of what each file does and how Oni finds its game data. Click on a folder's name to go down to that level of the hierarchy; click on a file's name to read more about that file.

==Installation location==
The default location for this folder in Windows is '''C:\Program Files (x86)\Oni\''' – it was originally '''C:\Program Files\Oni\''' on 32-bit systems, but modern Windows has a hack for old program installers which changes Oni's installer to point to the x86 folder by default. The Russian localization's installer adds another level with the publisher's name: '''C:\Program Files (x86)\Buka\Oni\'''.

There is no default location on Macs because modern Macs cannot run the installer on the CD-ROM, and so users must drag the "Oni ƒ" folder manually to their hard drive.

==Warning for non-admins==
If you are not logged into Windows as an administrator, Oni will save persist.dat, debugger.txt, key_config.txt and startup.txt in '''C:\Users\<username>\AppData\Local\VirtualStore\Program Files\Oni\'''. This does not apply to an installation of the [[AE]] or a manual installation of Oni. Right-clicking Oni.exe and choosing "Run as administrator" will cause Oni to save the aforementioned files in the Oni folder itself. However this will mean you have two save-game files, with either one being written to depending on whether you run Oni as admin or not.

==Directory==
{| border="1" cellpadding="5" cellspacing="0" style="margin-left:auto; margin-right:auto;"
!Legend
|-
|<center>[[Image:Aqua Dot-Red.png]] = needed to run Oni; [[Image:Aqua Dot-Yellow.png]] = created by Oni; [[Image:Aqua Dot-Blue.png]] = unneeded files</center>
|}

Your initial Oni installation will probably have all the red and blue files. For files marked with yellow, Oni may not have seen a need to create them yet (follow that file name's link for more info).

{| border="1" cellpadding="5" cellspacing="0" style="margin-left:auto; margin-right:auto;"
!
!width=100px|Windows
!width=85px|macOS
!width=180px|[[OniX]]
!width=585px|Description
|-bgcolor="#E9E9E9"
!colspan="5"|Folders
|-
|[[Image:Aqua Dot-Red.png]]
|colspan="2"|<center>[[Oni (folder)/GameDataFolder|GameDataFolder]]</center>
|<center>GameDataFolderX</center>
|A subfolder with movies, scripts and binary resources
|-bgcolor="#E9E9E9"
!colspan="5"|Files
|-
|[[Image:Aqua Dot-Red.png]]
|<center>binkw32.dll</center>
|bgcolor=lightgray|
|<center>bink-ffplay.exe<ref>Name of the player in the OniX build for modern Windows. The player for the legacy OniX build is called binkplay.exe.</ref></center>
|Allows Oni to play Bink movies; [[Daodan DLL]] also poses as binkw32.dll
|-
|[[Image:Aqua Dot-Yellow.png]]
|colspan="3"|<center>[[Oni (folder)/debugger.txt|debugger.txt]]</center>
|Error log; created first time that an error occurs while running Oni
|-
|[[Image:Aqua Dot-Yellow.png]]
|colspan="3"|<center>[[Oni (folder)/key_config.txt|key_config.txt]]</center>
|Key configuration file; if it's missing, Oni will generate a fresh copy
|-
|[[Image:Aqua Dot-Yellow.png]]
|colspan="3"|<center>[[XML:CRSA|lvl_*_*_corpse.dat]]</center>
|[[Developer Mode]] corpse file; created by BSL command [[make_corpse]]
|-
|[[Image:Aqua Dot-Blue.png]]
|<center>[[Oni (folder)/license.txt|license.txt]]</center>
|bgcolor=lightgray|
|bgcolor=lightgray|
|Software license and warranty agreement
|-
|[[Image:Aqua Dot-Red.png]]
|<center>Oni.exe</center>
|<center>[[History of Mac Oni|Oni(.app)]]</center>
|<center>OniX.exe</center>
|The game application
|-
|[[Image:Aqua Dot-Blue.png]]
|<center>ONI.url</center>
|bgcolor=lightgray|
|bgcolor=lightgray|
|Points to <nowiki>http://oni.bungie.com</nowiki> (defunct)
|-
|[[Image:Aqua Dot-Yellow.png]]
|colspan="3"|<center>[[Oni (folder)/persist.dat|persist.dat]]</center>
|Save-game file; created by Oni on first run
|-
|[[Image:Aqua Dot-Blue.png]]
|<center>[[Oni (folder)/readme.txt|readme.txt]]</center>
|<center>{{FontSize|95|[[Oni (folder)/Oni ReadMe|Oni ReadMe]]}}</center>
|<center>OniX read-me.pdf</center>
|Read-me file
|-
|[[Image:Aqua Dot-Blue.png]]
|<center>RegisterOni.url</center>
|bgcolor=lightgray|
|bgcolor=lightgray|
|Points to {{FontSize|85|<nowiki>http://www.godgames.com/main.php?section=support&page=registration</nowiki>}} (defunct)
|-
|[[Image:Aqua Dot-Yellow.png]]
|colspan="3"|<center>[[XML:FILM|saved_film*.dat]]</center>
|Developer Mode film; created by recording a film with F9 and F10
|-
|[[Image:Aqua Dot-Yellow.png]]
|colspan="3"|<center>screen_shot*.bmp</center>
|Screenshots taken with the [[Customizing/Binding#screenshot|screenshot key]] or with the Ctrl+Shift+L Dev Mode hotkey
|-
|[[Image:Aqua Dot-Yellow.png]]
|colspan="3"|<center>[[BSL|script_commands.txt]]</center>
|List of [[BSL]] commands & variables; created by BSL command [[dump_docs]]
|-
|[[Image:Aqua Dot-Yellow.png]]
|colspan="3"|<center>script_debug.txt</center>
|Log of BSL functions called during gameplay; dumped if Oni is run with [[Customizing#Command-line arguments|-debugfiles]]
|-
|[[Image:Aqua Dot-Yellow.png]]
|colspan="3"|<center>[[Oni (folder)/startup.txt|startup.txt]]</center>
|Event log; overwritten every time Oni is run
|-
|[[Image:Aqua Dot-Blue.png]]
|<center>Uninst.isu</center>
|bgcolor=lightgray|
|bgcolor=lightgray|
|(or "Uninstal.log") Record used by Windows to uninstall Oni
|}

[[Category:Game directory map]]

Introduction to modding

2026-04-06T00:50:25Z

Iritscen: moved Engine terminology link to more logical place; linked to Oni (folder)/GameDataFolder instead of Oni (folder)

{{integrate|The tutorials are called "Creating the Lair" and "Adding character classes".|plural=yes}}
This page provides an introduction to modding that does not assume that you have prior modding experience or knowledge of the Oni engine. Links to more technical parts of the wiki are interspersed below or can be accessed directly from the wiki's Main Page.
{{TOClimit}}
==What is modding?==
[[Image:No easy button.png|150px|right]]
Modifying, or "modding", a game is generally easier than creating one, because you might only be changing some of the game's existing elements, or creating a limited amount of new data. Nevertheless, modding can be an intimidating field to get into. Our community does not have the polished modding tools of the big engines like Unreal (but we're getting better). You should have a [[wikt:DIY|DIY]] personality and a high tolerance for technical details. We do not yet have any modding solutions with a big red button that says "easy".

Modding your first game is always the hardest, but after that you can more easily pick up new ones. If you take things one step at a time, you can learn a lot from Oni about how to make games in general; in fact, many game developers started out as modders. Additionally, there are lots of different ways for someone to mod; whether your interest is in coding, art, sound, 3D modeling, or general game design, there's something for you to do, and collaborating with others to divide the work according to your abilities can lead to a memorable, rewarding creative experience.

* Go to the {{OMD}} to see what kinds of mods are available, or;
* Install the [[Anniversary Edition]] to try out the mods, or;
* Continue reading to get an overview of the game engine.

==What engine does Oni run on?==
Oni runs on a custom engine that could be built for Windows, the Macintosh and the PlayStation 2 (disc-based console games are not easily modded, so we don't support modding for the PS2 version of Oni). The engine consists of various subsystems, some of which have colorful animé-related names like Akira (environment), Motoko (graphics) and Totoro (animation).

Unfortunately, the game was rushed to completion during a change of ownership, and it was not possible for the developers to release any tools or information to aid the fans in modding. Thus, fans had to explore the wild jungle of the raw game data and create modding tools through reverse-engineering. It took over seven years to unlock most of the game's secrets, but we can now mod almost all types of data effectively, allowing us to create entirely new levels and characters.

Altogether, we have identified over 100 types of resources (often called "file types" on this wiki and "tags" in many other game modding communities) in the data, however we only directly edit about half of these. It may sound intimidating at first, but depending on the kind of modding you want to do, you might be able to start working with only a little knowledge of the engine.

* Go to [[Oni]] for the full story on Oni's development, or;
* Go to [[History of Oni modding]] to read about the community's accomplishments up until now, or;
* Go to [[Engine terminology]] to learn about versions of the engine and its subsystems, or;
* Continue reading to learn about the game data files.

==How is the game data structured?==
A game can be compared to a theater play: in both cases, you have stages, scripts, actors, and music. A level is built so that when the player performs certain actions or reaches certain locations on the '''stage''', further events are set in motion according to the '''script'''. The player interacts with [[wp:Artificial intelligence in video games|AI]] '''actors''' along the way. '''Music''' will often play dynamically behind all this, changing along with the flow of events.

In Oni's case, the stages, actors and music (and other sounds) are all packed together into files inside GameDataFolder/ that end in ".dat", ".raw", and, on Macs, ".sep". The level0_Final files provide global resources for all levels, and when you load a Chapter, an additional set of data files provide the level-specific resources for that Chapter (e.g. level12_Final for Chapter 10). The scripts are stored in separate plain-text files ending in ".bsl" inside GameDataFolder/IGMD/. The player's progress is stored in persist.dat next to the Oni application.

* Go to [[Oni (folder)/GameDataFolder]] to see how the data files correspond to the game's levels, or;
* Go to [[Game data terminology]] to learn the community's terms for the game data, or;
* Continue reading to learn the general process of modding.

==What is the workflow for modding?==
The general order of events in creating a mod is (1) unpacking the resources you wish to edit, (2) editing them, and (3) re-packing them as Oni level data. You can rely on the Anniversary Edition Installer to re-pack your data; you simply create the mod package in the format that the AEI requires. If you are only creating a script mod, then you don't need to unpack any data, but you'll still need to know how to place your script(s) in a mod package.

===Data unpacking===
The game data cannot be edited easily until our tools convert it into something more modder-friendly. You will usually start by using OniSplit to break level data files (those .dat/.raw(/.sep) files) into their component resources, which are saved as .oni files. Then you will need to convert those resources into something editable. The editable format you arrive at will depend on the kind of data you're editing. It might be plain text, XML, PNG, Collada, WAV, etc. The editors which you'll use on this data will be third-party programs suited for each file format.

===Third-party tools===
If you are scripting, you might need nothing more than a text editor. For editing textures, you might only need a free bitmap editor. For creating levels or characters, you'll need a full 3D modeling package. Since Oni doesn't have modern 3D graphics, you won't need to know as much about modeling/texturing as you would with a modern game, and there are free modelers available. Our recommendations for tools will be found under the subsections of "Modding resources" below.

===Community tools===
Besides OniSplit, two of the key fan-made tools are Vago and XmlTools. Vago is a GUI for OniSplit which is much more user-friendly than using OniSplit on the command line. [[XmlTools]] is a technical tool that few modders need to use, but it allows the creation of patches (partial changes to a single resource which can stack on top of each other). Both tools can be installed from within the AE Installer. Once installed, they are found in AE/Tools/ alongside OniSplit.

===Mod creation===
To see how mods normally look and how they're distributed and installed, you should download the [[Anniversary Edition]] and install some mods. You can then look at the packages that have been downloaded to AE/AEInstaller/packages/.

* Go to [[OniSplit]]'s page to learn how to unpack and reassemble the game data, or;
* Go to [[Vago]]'s page to learn how to use this OniSplit GUI, or;
* Go to [[Making a mod package]] to learn how to assemble a mod, or;
* Continue reading to learn about the types of modding you can perform.

==Which resources should I be modding?==
Oni assembles its game world from the scripts in the IGMD folder, the game data in the .dat/.raw(/.sep) files in GameDataFolder, and [[persist.dat]]. It's easy to read the BSL scripts since they're plain-text, but how do you find the resource in the game data that you want to edit? Look under "Modding resources" below for a link to the XML database, which explains the function and location of each resource type.

===Editing scripts===
The easiest kind of modding is scripting. Scripts are written in a unique language called BSL and stored as plain-text files with the suffix .bsl in sub-folders inside GameDataFolder/IGMD/. Scripts take a lifeless level and spawn characters in it, give it a logical flow of events, drive the cutscenes, make the AIs perform certain roles, and alter the level's appearance.

Scripting is the easiest way to mod because you can modify BSL files using a text editor. It's quick and easy to see the results of your work (just reload the level), and you have lots of accessible examples to learn from. That being said, scripts sometimes reference game resources in technical ways, so you will have to learn how certain data types work in order to script effectively.

* Go to the [[BSL]] namespace to start learning about scripting, or;
* Continue reading to learn what's involved with editing binary resources.

===Modding resources===
Broadly speaking, Oni's resources can be broken down as: '''environments''' (architecture, triggers, furniture), '''characters''' (class data, instance lists, 3D models), '''weapons''' (ditto), '''text''' (diary pages, objectives, subtitles), and '''sound''' (music, voice-overs, and sound effects). However, new levels do not require all this data to be made from scratch. You might decide to re-use a level or some of its resources, or make a new level populated with existing characters, etc.

* Go to the [[XML]] namespace to get a simple introduction to the types of game data and learn the (relatively) user-friendly XML modding technique, or;
* Go to the [[OBD]] namespace to learn more technical details about the game data, or;
* Continue reading to start down the path to modding specific kinds of resources.

====Environments====
Levels are usually built in [[SketchUp tutorials and tips|SketchUp]]. The open-source 3D modeler [[Blender]] can be used for levels, objects, characters and animations. Formerly we preferred to do that work in the discontinued [[Mod Tool]], but the community's support for Blender has continued to improve and it is now our modeler of choice.

* Tutorial: [[Creating a level]]
* Tutorial: [[Authoring custom camera animations]]

====Textures====
Modders have their own preferred bitmap editors for changing/creating textures. On one end of the scale are expensive programs such as Photoshop, and on the other end are free editors like [https://www.gimp.org/ Gimp] and [https://www.getpaint.net/ Paint.NET].

Textures always have dimensions of "power of 2": typically 32, 64, 128 or 256 pixels on a side. [[FERAL|Mac Oni]] supports a maximum of 1024x1024 textures. Windows Oni (with [[Daodan DLL|fan patch]]) supports textures up to 512x512.

These textures can be static, animated, transparent or have a reflection map (usually used for armor). Splashscreens (chapter start screens), win-level and lose-level screens are actually composite images made up of smaller textures due to Oni's limitation in texture size.

* Tutorial: [[Modifying textures]]

====Characters====
[[Image:Female stun.jpg|right|300px]]
Characters in Oni are built with a 19-part skeleton. This skeleton is the same for all humanoid characters and simply tells Oni how the individual parts with their own geometry and textures are assembled. You cannot really compare this with the modern game industry's use of the term "skeleton".

A character's attributes are defined by their character class file which links also to the animation list that defines their moveset. The high modularity of character data allows Oni to share many resources between characters (especially animation collections and particles).

* Tutorial: [[Importing character models]]
* Tutorial: [[OBD talk:TRAM|Tweaking an individual animation]]
* Tutorial: [[XML:Adding spawnable characters|Adding spawnable characters to a level]]

====Weapons====
* Tutorial: [[Importing weapon models]]

====Text====
The text-based resource types are fairly easy to edit as long as you don't get confused by the IDs which they use to link to each other. The main textual resources are the pages you can view in the [[Data Comlink]] and the consoles you read in-game. The textual resource types are listed here: {{SectionLink|OBD:File types/Interface|List}}.

====Sound and music====
Instructions on importing sounds, and links to conversion tools, can be found [[XML:SNDD|HERE]].

==Need some inspiration?==
To get ideas, play some existing mods (which you can install with the [[AE]]), or look at the pages below.
* [[Modding brainstorms]]
* [[Review criticisms]]
* [[Animation ideas]]

[[Category:Modding tutorials]]

Oni (folder)/GameDataFolder

2026-04-06T00:47:13Z

Iritscen: moved one note to IGMD; added notes on the movies and on the level numbering gaps; removed all that unnecessary bold, what an eyesore

'''GameDataFolder''' (commonly called "GDF") is a subfolder of the main Oni folder. It holds the following:
*Oni's game data, in binary format (see [[OBD]] for more info)
*the level logic, in plain-text (in the IGMD subfolder; see [[BSL]] for more info)
*the intro and outro animated sequences, in the Bink video format

First we show the purpose of each file in this folder – but don't miss our helpful notes below this directory listing.

==Directory listing==
You should have all the files below in your GameDataFolder, though the movie files are optional (see note at bottom). The "PS2" column shows the numbers assigned to each file name on disc; the .raw and .sep file for each level are in subdirectories titled 20/ and 21/. Beside each set of level files, we list the subfolders of IGMD which hold the corresponding level logic. '''SPOILER WARNING''': The "Chapter" column links to summaries and analyses of Oni's storyline.

{| class="wikitable" style="margin-left:auto; margin-right:auto;"
|-
|colspan="3" align="center"|'''File name'''
|rowspan="2" align="center"|'''Level logic folder'''
|rowspan="2" align="center"|'''[[Chapters|Chapter]]'''
|rowspan="2" align="center"|'''Location (seen in Load Game dialog)'''
|-
|align="center"|'''Windows'''
|align="center"|'''Mac'''
|align="center"|'''PS2'''
|-
|colspan="2"|<center>[[IGMD|IGMD/]]</center>
|valign=top|1
| <center>--</center>
|colspan=2 align=center|Contains all level logic
|-
|colspan="2"|<center>[[:Category:Intro sequence|intro.bik]]</center>
|valign=top|2
| <center>--</center>
|colspan=2 align=center|Movie plays when Oni is launched
|-
|valign=top|level0_Final.dat level0_Final.raw
|level0_Final.dat level0_Final.raw level0_Final.sep
|3 20/1 21/1
|[[IGMD/global]]
|colspan=2 align=center|Used in all Chapters (see notes below on "level0_Final" and "IGMD/global")
|-
|valign=top|level1_Final.dat level1_Final.raw
|level1_Final.dat level1_Final.raw level1_Final.sep
|11 20/9 21/9
|[[IGMD/EnvWarehouse]]
|{{C|0|0: COMBAT TRAINING}} {{C|1|1: TRIAL RUN}}
|TCTF Training Syndicate Warehouse
|-
|valign=top|level2_Final.dat level2_Final.raw
|level2_Final.dat level2_Final.raw level2_Final.sep
|12 20/10 21/10
|[[IGMD/manplant]]
|{{C|2|2: ENGINES OF EVIL}}
|Manufacturing Plant
|-
|valign=top|level3_Final.dat level3_Final.raw
|level3_Final.dat level3_Final.raw level3_Final.sep
|13 20/11 21/11
|[[IGMD/lab]]
|{{C|3|3: PUZZLE PIECES}}
|Bio-Research Lab
|-
|valign=top|level4_Final.dat level4_Final.raw
|level4_Final.dat level4_Final.raw level4_Final.sep
|14 20/12 21/12
|[[IGMD/Airport]]
|{{C|4|4: TIGER BY THE TAIL}}
|Airport Assault
|-
|valign=top|level6_Final.dat level6_Final.raw
|level6_Final.dat level6_Final.raw level6_Final.sep
|15 20/13 21/13
|[[IGMD/Airport_III]]
|{{C|5|5: HOT PURSUIT}}
|Airport Cargo Hangars
|-
|valign=top|level8_Final.dat level8_Final.raw
|level8_Final.dat level8_Final.raw level8_Final.sep
|16 20/14 21/14
|[[IGMD/tctf]]
|{{C|6|6: COUNTERATTACK}}
|TCTF Regional HQ
|-
|valign=top|level9_Final.dat level9_Final.raw
|level9_Final.dat level9_Final.raw level9_Final.sep
|17 20/15 21/15
|[[IGMD/power]]
|{{C|7|7: A FRIEND IN NEED}}
|Atmospheric Conversion Center (exterior)
|-
|valign=top|level10_Final.dat level10_Final.raw
|level10_Final.dat level10_Final.raw level10_Final.sep
|4 20/2 21/2
|[[IGMD/power_II]]
|{{C|8|8: AN INNOCENT LIFE}}
|Atmospheric Conversion Center (interior)
|-
|valign=top|level11_Final.dat level11_Final.raw
|level11_Final.dat level11_Final.raw level11_Final.sep
|5 20/3 21/3
|[[IGMD/state]]
|{{C|9|9: TRUTH AND CONSEQUENCES}}
|Regional State Building
|-
|valign=top|level12_Final.dat level12_Final.raw
|level12_Final.dat level12_Final.raw level12_Final.sep
|6 20/4 21/4
|[[IGMD/roof]]
|{{C|10|10: CAT AND MOUSE}}
|Rooftops
|-
|valign=top|level13_Final.dat level13_Final.raw
|level13_Final.dat level13_Final.raw level13_Final.sep
|7 20/5 21/5
|[[IGMD/dream_lab]]
|{{C|11|11: DREAM DIVER}}
|Doctor Hasegawa's Lab
|-
|valign=top|level14_Final.dat level14_Final.raw
|level14_Final.dat level14_Final.raw level14_Final.sep
|8 20/6 21/6
|[[IGMD/neuro]]
|{{C|12|12: SINS OF THE FATHER}}
|TCTF Science Prison
|-
|valign=top|level18_Final.dat level18_Final.raw
|level18_Final.dat level18_Final.raw level18_Final.sep
|9 20/7 21/7
|[[IGMD/tctf_ii]]
|{{C|13|13: PHOENIX RISING}}
|TCTF Regional HQ (redux)
|-
|valign=top|level19_Final.dat level19_Final.raw
|level19_Final.dat level19_Final.raw level19_Final.sep
|10 20/8 21/8
|[[IGMD/compound]]
|{{C|14|14: DAWN OF THE CHRYSALIS}}
|Syndicate Mountain Compound
|-
|colspan="2"|<center>[[:Category:Outro sequence|outro.bik]]</center>
|18
| <center>--</center>
|colspan=2 align=center|Movie plays when Oni is beaten
|}

==Notes==
==="Missing" levels===
Players in 2001 were puzzled when they first installed Oni and looked inside GameDataFolder to find that there were strange gaps in the file numbering: specifically there's no level5, level7, level15, level16 or level17. There isn't something wrong with your installation: the game's content was reshuffled late in development and Bungie West apparently felt it would be too dangerous or disruptive to re-number the level files. The existing files tell a complete story from Chapter 1 to Chapter 14.

===level0_Final===
The level 0 data is only loaded once, when Oni starts.

===intro.bik, outro.bik===
*The movie files are not needed for Oni to run. You can thus rename or remove intro.bik to avoid the need to click through the movie.

*When the game is beaten and outro finishes playing, the game will quit. Sometimes players think that the game has crashed, but this is by design. Note that if you remove outro.bik, Oni will quit immediately after beating the game.

*A bug currently exists where the ending movie plays only its sound, with the screen remaining black. You will have to play outro.bik by double-clicking it if you want to watch it. See next point.

*Epic Games Tools, the makers of the Bink video format, offer [https://www.radgametools.com/bnkdown.htm standalone apps] for all platforms if you want to watch the .bik files on their own. However ffmpeg also understands the Bink format, meaning that you can use [https://www.videolan.org/vlc/ VLC] or another ffmpeg-based client to watch the movies.

===How Oni finds its GameDataFolder===
In Windows, Oni's engine first looks in the [[wp:Working directory|working directory]] (aka "."). If ".\GameDataFolder" is missing, Oni tries parent folders all the way up to the root (e.g., it looks for "C:\Program Files\Oni\GameDataFolder", then "C:\Program Files\GameDataFolder", then "C:\GameDataFolder"). As a last resort, it looks for ".\OniEngine\GameDataFolder" the same way.

The Mac Oni app follows the same search pattern for GameDataFolder/, but does not look for OniEngine/GameDataFolder/.

[[Category:Game directory map]]

Oni (folder)/GameDataFolder/IGMD

2026-04-06T00:45:03Z

Iritscen: moved note about global/ here from Oni (folder)/GameDataFolder; tweaked some links

'''IGMD''' is a subfolder of GameDataFolder, where the level logic is defined, chapter by chapter. If the contents of this folder are missing or corrupt, nothing interesting will ever happen :-) If you think your folder has been corrupted, download a .zip file of the unmodified files for your platform: [http://geyser.oni2.net/OSL/IGMD/IGMD_PC.zip Windows], [http://geyser.oni2.net/OSL/IGMD/IGMD_Mac.zip Mac].

'''Notes on this folder'''
*The scripts in the subfolders of IGMD are plain-text files with a .bsl extension, written in [[BSL|BFW Scripting Language]].
*[[IGMD/global]] is not present by default, but if it is created, the functions in any scripts placed inside it will be accessible from all levels; however, the Windows demo engine ignores the global/ folder.
*Oni treats the level folder names as case-insensitive, so you can rename "EnvWarehouse" to "eNvwArEhOuSe" and you'll still be able to play Chapter 1.
*The Mac and Windows scripts are identical except for minor differences in '''tctf_ii_cutscene.bsl''' and '''tctf2.bsl''' for the boss battle of Chapter 13, shown at {{SectionLink|Windows Oni vs. Mac Oni|Level logic}}.
*The folders only present in the Euro Mac and PS2 IGMDs are development relics which do not correspond to chapters of the game; there are no level#_Final.dat/.raw(/.sep) files for them and so the script folders are never looked up by the engine. See [[Pre-beta content#Cut levels|HERE]] for an overview of the cut levels.
*The PS2's script folders 12/ (EnvWarehouse/) and 15/ (manplant/) each contain a "test" subfolder which is a backup of the unmodified scripts. The scripts in the main folder for each level are typically modified from the PC version in minor ways, documented on [[Oni (PlayStation 2)]].

{| class="wikitable sortable" style="margin-left:auto; margin-right:auto;"
!Standard Win/ Mac release
!European Mac non-English
!Japanese Win/Mac
!Play- Station 2
!Chapter
!Location (seen in Load Game dialog)
|-
|bgcolor=lightgray|
|'''[[Oni (folder)/GameDataFolder/IGMD/global|global/]]'''
|bgcolor=lightgray|
|13/
|colspan=2|Loads for all levels
|-
|'''[[Oni (folder)/GameDataFolder/IGMD/EnvWarehouse|EnvWarehouse/]]'''
|EnvWarehouse/
|EnvWarehouse/
|12/
|data-sort-value="00"|{{C|0|0: COMBAT TRAINING}} {{C|1|1: TRIAL RUN}}
|valign=bottom|TCTF Training Syndicate Warehouse
|-
|'''[[Oni (folder)/GameDataFolder/IGMD/manplant|manplant/]]'''
|manplant/
|MANPLANT/
|15/
|data-sort-value="02"|{{C|2|2: ENGINES OF EVIL}}
|Manufacturing Plant
|-
|'''[[Oni (folder)/GameDataFolder/IGMD/lab|lab/]]'''
|lab/
|LAB/
|14/
|data-sort-value="03"|{{C|3|3: PUZZLE PIECES}}
|Bio-Research Lab
|-
|'''[[Oni (folder)/GameDataFolder/IGMD/Airport|Airport/]]'''
|Airport/
|Airport/
|data-sort-value="01/"|1/
|data-sort-value="04"|{{C|4|4: TIGER BY THE TAIL}}
|Airport Assault
|-
|bgcolor=lightgray|
|Airport_II/
|bgcolor=lightgray|
|data-sort-value="02/"|2/
|(cut)
|Airport Part Deux
|-
|'''[[Oni (folder)/GameDataFolder/IGMD/Airport_III|Airport_III/]]'''
|Airport_III/
|Airport_III/
|data-sort-value="03/"|3/
|data-sort-value="05"|{{C|5|5: HOT PURSUIT}}
|Airport Cargo Hangars
|-
|'''[[Oni (folder)/GameDataFolder/IGMD/tctf|tctf/]]'''
|tctf/
|TCTF/
|23/
|data-sort-value="06"|{{C|6|6: COUNTERATTACK}}
|TCTF Regional HQ
|-
|'''[[Oni (folder)/GameDataFolder/IGMD/power|power/]]'''
|power/
|POWER/
|18/
|data-sort-value="07"|{{C|7|7: A FRIEND IN NEED}}
|Atmospheric Conversion Center (exterior)
|-
|'''[[Oni (folder)/GameDataFolder/IGMD/power_II|power_II/]]'''
|power_II/
|power_II/
|19/
|data-sort-value="08"|{{C|8|8: AN INNOCENT LIFE}}
|Atmospheric Conversion Center (interior)
|-
|'''[[Oni (folder)/GameDataFolder/IGMD/state|state/]]'''
|state/
|STATE/
|22/
|data-sort-value="09"|{{C|9|9: TRUTH AND CONSEQUENCES}}
|Regional State Building
|-
|'''[[Oni (folder)/GameDataFolder/IGMD/roof|roof/]]'''
|roof/
|ROOF/
|20/
|{{C|10|10: CAT AND MOUSE}}
|Rooftops
|-
|'''[[Oni (folder)/GameDataFolder/IGMD/dream_lab|dream_lab/]]'''
|dream_lab/
|dream_lab/
|11/
|{{C|11|11: DREAM DIVER}}
|Doctor Hasegawa's Lab
|-
|'''[[Oni (folder)/GameDataFolder/IGMD/neuro|neuro/]]'''
|neuro/
|NEURO/
|16/
|{{C|12|12: SINS OF THE FATHER}}
|TCTF Science Prison
|-
|bgcolor=lightgray|
|BGI/
|bgcolor=lightgray|
|16/
|(cut)
|BGI HQ
|-
|'''[[Oni (folder)/GameDataFolder/IGMD/tctf_ii|tctf_ii/]]'''
|tctf_ii
|TCTF_II
|24/
|{{C|13|13: PHOENIX RISING}}
|TCTF Regional HQ (redux)
|-
|'''[[Oni (folder)/GameDataFolder/IGMD/compound|compound/]]'''
|compound/
|COMPOUND/
|data-sort-value="08/"|8/
|{{C|14|14: DAWN OF THE CHRYSALIS}}
|Syndicate Mountain Compound
|-
|bgcolor=lightgray|
|aop/
|bgcolor=lightgray|
|data-sort-value="04/"|4/
|(multiplayer)
|The Arena of Pain
|-
|bgcolor=lightgray|
|CZ/
|bgcolor=lightgray|
|data-sort-value="09/"|9/
|(multiplayer)
|Crossing Zone
|-
|bgcolor=lightgray|
|pit/
|bgcolor=lightgray|
|17/
|(multiplayer)
|Pit
|-
|bgcolor=lightgray|
|CZ_II/
|bgcolor=lightgray|
|10/
|(multiplayer)
|Crossing Zone Too
|-
|bgcolor=lightgray|
|cap/
|bgcolor=lightgray|
|data-sort-value="07/"|7/
|(multiplayer)
|Capture
|-
|bgcolor=lightgray|
|ats/
|bgcolor=lightgray|
|data-sort-value="05/"|5/
|(development)
|AlexTestSite
|-
|bgcolor=lightgray|
|SR/
|bgcolor=lightgray|
|21/
|(development)
|FiringRange
|}

[[Category:Game directory map]]

OBD:Oni Binary Data

2026-04-06T00:21:28Z

Iritscen: hatnote wording

[[Image:OBD.png|right]]
{{Hatnote|If you are a beginner to modding, you should read [[Introduction to modding]] first.}}
The '''OBD''' namespace is devoted to documenting Oni's binary data (.dat/.raw[/.sep] files) as reverse-engineered by dedicated members of the fan community. Needless to say, this is a highly technical area of the wiki, and knowledge of topics such as [[wp:Hexadecimal|hexadecimal]], [[wp:Pointer (computer programming)|pointers]], and [[wp:Endianness|endianness]] is a prerequisite. Everything about the game's file formats is intended to be documented here, but the core of the Oni Binary Database is the information on resource types ("File types" in the directory below). Note that the [[XML|XML namespace]] documents the resource types in a way which is more modding-oriented and modder-friendly.

This database's information has been used by modders in such [[:Category:Modding projects|projects]] as:
*The [[Anniversary Edition|Anniversary Edition]]
*[[AE:ONK|Oni ni Kanabo]]
*The [[AE:BIP|Binary Improvement Project]]
*[[OniFly]]

The knowledge documented here was also used to develop [[:Category:Modding tools|modding tools]] such as:
*[[OniSplit]]
*[[OniUnPacker|OniUnPacker]]
*[[OME|Oni Model Extractor]]
*[[ONI-Trainer|Oni Trainer]]

==Knowledge base==
{| class="wikitable"
|-
|[[OBD:Instance file format|Instance file format]]
|About .dat files
|-
|[[OBD:Raw and separate file formats|Raw/separate file format]]
|About .raw & .sep files
|-
|[[OBD:Persist.dat|persist.dat]]
|The save-game file
|-
|[[OBD:File types|File types]]
|Resource types such as ONCC, TRAM, etc.
|-
|[[OBD:Data types|Data types]]
|The format of the integers, floats, etc. in the resources
|-
|[[OBD:Globalization|Globalization]]
|Duplication and false duplicates in the resources
|-
|[[OBD:Localization|Localizations]]
|Considerations and pitfalls for localizers
|-
|[[OBD:Releases|Releases]]
|Database of each release's level file sizes
|-
|[[OBD:Text encoding|Text encoding]]
|Variant text encodings found in localizations
|-
|[[OBD:Oni2AS|Oni 2 game data]]
|About the [[Oni2AS|Angel Studios dev build]]
|}

===External Links===
*[http://ssg.oni2.net ssg's Oni Stuff]
:Oni Stuff is the original database of Oni's resource types, source for much of this wiki's OBD. It also contains information which has never been ported to the wiki such as flag locations and data on every character spawned in each level.

{{OBD}}

OniSplit

2026-04-06T00:19:28Z

Iritscen: tweaked lede wording and some of the typesetting

{{integrate|See {{SectionLink||Levels}}.}}
{{Hatnote|Before reading this page, it's a good idea to be familiar with basic Oni [[game data terminology]].}}
'''OniSplit''', written by [[User talk:Neo|Neo]], is an integral part of the [[Anniversary Edition]] and an essential modding tool on its own. It is a command line tool which can import and export almost all kinds of game data from the Windows and Mac versions of Oni, including textures, sounds, 3D models and animations, and level geometry. Its name comes from its original purpose, which was breaking Oni's level data files into individual resources. Soon the ability to convert those resources into and from editable standard file formats was added. OniSplit incorporates the knowledge documented at the [[OBD|Oni Binary Database]], and is currently the community's main modding tool.

:''Subpages:'' [[/Change_log|Change log]] (past versions), [[/WIP|WIP notes]] (upcoming versions)

==Getting it==
===Download links===
* Latest release of OniSplit: [http://mods.oni2.net/node/38 v0.9.99.2] ([https://websvn.illy.bz/browse/Oni2/OniSplit/ source code])
* The current GUI for OniSplit is [[Vago (tool)|Vago]]. '''You should try the GUI to see if it does what you need before working with OniSplit on the command line.'''

===Requirements===
*Windows: [https://dotnet.microsoft.com/en-us/download/dotnet-framework .NET framework]
*macOS: [https://www.mono-project.com/download/stable/ Mono framework]

==Workflow==
OniSplit is used in up to four different stages when modding:
{|
|rowspan="2"|'''OUT'''
|''Exporting'' - using the <tt>-export</tt> command, a [[Dat|level data file]] is broken into its component resources, .oni files.
|-
|style="border-style: solid; border-width: 0 0 1px 0"|''Extracting'' - using the <tt>-extract</tt> commands, .oni files are converted to standard-format files that can be edited in various third-party programs.
|-
|rowspan="2"|<center>'''IN'''</center>
|''Creating'' - using the <tt>-create</tt> commands, standard-format files are converted into .oni files.
|-
|''Importing'' - using the <tt>-import</tt> command, a folder of .oni files is combined into a level data file.
|}

Note that "extracting" refers to a conversion from one format to another, but "exporting" only refers to the creation of .oni files from a .dat file. When exporting, no conversion or re-formatting is taking place; the data is simply being copied out of a .dat (any connected binary data in .raw/.sep files will be concatenated to the data from the .dat when making the .oni).

==Beginner's tips==
{{Divhide|show=yes|For users new to the command line or to OniSplit}}
In Windows, there are several options through which you can use OniSplit - out of which it is recommended to get Vago and CMDer:
* [[Vago (tool)|Vago]] is a GUI for OniSplit which allows you to handle all general conversions, save your sessions as project files, input manual commands if needed, and more. The two downsides of it is that it doesn't support Blender yet, forcing the users input commands manually, which in turn are not stored upon ending the session.
* Command Prompt (cmd.exe). Windows' default command line interpreter; it's a very simple application that does not preserve a history of your commands from session to session.
* [https://cmder.app/ CMDer] is an excellent alternative to cmd.exe. It adds a context menu option to open the command line with the current directory set to the folder you right-click in, and it also stores your recently used commands after ending the session.

On Macs, the command line is accessed through /Applications/Utilities/Terminal.app (press Command-Space and type "terminal" to get there faster).

===OniSplit syntax===
The basic syntax is:
{|
|-
|'''Windows'''||<tt>OniSplit.exe -create:trbs C:\Games\Oni\SomeFolder -normals C:\Games\Oni\Modding\TRBSMyNewChar.dae</tt>
|-
|'''Mac'''||<tt>mono OniSplit.exe -create:trbs /Games/Oni/SomeFolder -normals /Games/Oni/Modding/TRBSMyNewChar.dae</tt>
|}

Here's how it breaks down:
{|
! style="width:130px"|
|- valign="top"
|'''Invocation'''
|Windows can refer to the program directly, but Macs use Mono to run the .NET app; note also that if OniSplit.exe is not in the Command Prompt/Terminal's current directory, you must provide the full path to it or set the path variable.
|-
|'''Option'''||The command.
|- valign="top"
|'''Path to folder'''||Whether destination or source, the path which is a folder comes first. Use the full path to the folder (starting from "C:\", or "/" on Macs).
|-
|'''Option flags'''||The flags that can optionally go with this command, separated by spaces.
|- valign="top"
|'''Path to file'''||Whether destination or source, the path of the file comes second. Use the full path to the file (starting from "C:\", or "/" on Macs). One exception to this parameter being a file is when using <tt>-create</tt> to make a level, in which case this is where you supply the source folder.
|}

===CLI tips===
*Command line interfaces (CLI) usually supply an auto-complete feature to save on typing. If you've typed enough of a file/folder name to identify it, press the Tab key and the rest should fill in. In Windows, you may not get the right path name autocompleted on the first try if there are multiple possible autocompletions based on the names in that directory, so keep pressing Tab to cycle through all possibilities. On Macs, if you have not typed enough of the name to narrow it down to a single autocompletion, you will hear an error sound. Double-tap Tab to see a list of possible autocompletions, then keep typing until you have narrowed it down to one of those and then hit Tab to fill in the rest of its name.

*Note that you can also drag files/folders into the window and the path will magically appear; in cases where you don't need to use a wildcard, this is the fastest way to build an OniSplit command.

===Wildcards===
Wildcards can be used to supply patterns to CLI programs. The wildcard is simply the <tt>*</tt> character. For instance:
OniSplit.exe -export:TRAM* <destination> <source .dat>
will export all the TRAMs in the source .dat into the destination folder. Using "TRAMKON*" would export all of Konoko's animations.

===Spaces in paths===
Command line interfaces (CLI) do not recognize spaces as a possible part of a path name because spaces are what separate the terms in your commands. The best course of action is to not use paths with spaces in their names! But if you must, you can use quotes to tell the CLI that a certain string is a single path:

'''C:\Games\Oni\>'''OniSplit.exe -list "My Mod Folder\level5_Final.dat"

This works in the Mac Terminal too, but you can also use the escape character, <tt>\</tt>. Also, other characters like <tt>(</tt> need to be escaped as well if you do not use quotes:

'''MyMac%''' mono OniSplit.exe -list My\ Mods\ $In\ Progress$/level5_Final.dat

But as mentioned, the best practice is to not use any characters besides the alphabet and numbers. It makes your life simpler, and if you ask for help on the forum with a command, no one wants to have to read your long path with lots of spaces or escaped characters in it ;-)

===Reading the commands below===
*The following commands should be complete, but the current list can be obtained by calling OniSplit with the <tt>-help</tt> option. You should also use <tt>-version</tt> to make sure you're using the latest version, the number of which is given in the "Download links" section above.

*Sample usages are given after certain commands. These are in DOS style, so if you are on a Mac, simply flip the <tt>\</tt>s to <tt>/</tt>s and make "C:\" into a leading "/".

*Optional flags are listed in square brackets simply to indicate that they're optional; don't enter the brackets when typing a command.

Note that only the .dat file from a level's data files is mentioned. The .raw and .sep files will be accessed by OniSplit as necessary when working with the .dat file that you gave the name of.
{{Divhide|end}}

==Commands==
===Conversion between .dat and .oni===
{|
! style="width:430px"|
|-
|<code>-list <file name></code>||Lists the named resources contained in a .dat (see [[OBD:File types/Naming|HERE]] for info on unnamed resources)
|-
|<code>-export <destination directory> <dat file></code>||Breaks .dat file into .oni files
|-
|<code>-export:<pattern> <destination directory> <dat file></code>||Exports named resource (wildcards also allowed) from .dat file
|- valign="top"
|<code>-import <source directory> <new dat file></code>||Compiles level files from source directory using the name you supply for the .dat file; tries to get target file format from source SNDD, but it's better to use the :sep or :nosep variants below
|-
|colspan="2"|To create level5_Final.dat/.raw[/.sep] from the files in MyNewLevel\: {{BSLcode|OniSplit.exe -import C:\Oni\MyNewLevel\ C:\Oni\GameDataFolder\level5_Final.dat}}
|-
|<code>-import:sep <source directory> <new dat file></code>||Imports target file (.dat) from source directory; uses .dat/.raw/.sep format (Mac retail and Windows demo)
|-
|<code>-import:nosep <source directory> <new dat file></code>||Imports target file (.dat) from source directory; uses .dat/.raw format (Windows retail)
|}
:Note that <tt>-import</tt> will search subdirectories too. If you find having hundreds or thousand of files .oni in one directory to be unmanageable you can always group them in subdirectories any way you like. The only exception is that a subdirectory named "noimport" or "_noimport" is always ignored.

===Management of .oni files===
Sometimes you want to move some .oni files out of a larger folder of .onis. You could do this manually, but OniSpit knows which files depend on others. It will also look for those dependencies in subfolders beneath the level of the file you supply the name of. The filename field supports wildcards. This is mostly used by the [[AE]] Installer rather than modders themselves.
{|
|<code>-deps <oni file></code>||Displays a list of .oni files that the specified .oni file depends on
|-
|<code>-copy <destination directory> <oni file></code>||Copies .oni file and its dependencies; skips file if it already exists at destination
|-
|<code>-move <destination directory> <oni file></code>||Moves an .oni file and its dependencies; skips file if it already exists at destination
|-
|<code>-move:overwrite <destination directory> <oni file></code>||Moves an .oni file and its dependencies; overwrites any existing .oni files
|-
|<code>-move:delete <destination directory> <oni file></code>||Moves an .oni file and its dependencies; doesn't overwrite; deletes source files
|}

===Conversion between .oni/.dat and 3rd party formats===
====Textures====
Unless mentioned otherwise, source filenames support wildcards. See [[Modifying textures|HERE]] for a detailed tutorial. The <tt>-extract</tt> commands can work with .oni files (a single file or several files if you use the wildcard), or rip all the TXMPs from a .dat file.
{|
|<code>-extract:dds <destination directory> <dat/oni file></code>||Extracts all textures (TXMP) from a Oni .dat/.oni file into DDS files
|-
|<code>-extract:tga <destination directory> <dat/oni file></code>||Extracts all textures (TXMP) from a Oni .dat/.oni file into TGA files
|-
|<code>-extract:png <destination directory> <dat/oni file></code>||Extracts all textures (TXMP) from a Oni .dat/.oni file into PNG files
|-
|<code>-create:txmp <destination directory> [-genmipmaps] [-nouwrap] [-novwrap] <nowiki>[-format:bgr32|bgra32|bgr555|bgra5551|bgra4444|dxt1]</nowiki> [-envmap:texture_name] <image file></code>
|valign=top|Creates .oni file from image file (PNG, TGA, or DDS)
|}

====Models====
[[M3GM]]s, [[ONWC]]s, [[ONCC]]s can be exported to the Wavefront .obj and COLLADA .dae formats. For details see [[Importing character models]] and [[Importing weapon models]]. The generic <tt>-extract</tt> commands can work with .oni files (a single file, or several files if you use the wildcard), or rip all the TXMP from a .dat file. TRBS and ONCC support additional <tt>-noanim</tt> and <tt>-anim</tt> options for <tt>-extract:dae</tt>; see [[Importing character models]] for details. Imported geometry must only contain triangles.
{|
! style="width:540px"|
|- valign="top"
|<code>-extract:obj <destination directory> <dat/oni file></code>||Extracts 3D data in .oni file (or all M3GM, ONWC and ONCC instances in a .dat) into Wavefront OBJ files
|- valign="top"
|<code>-extract:dae <destination directory> [-noanim] <dat/oni file></code>||Extracts 3D data in .oni file (or all M3GM, ONWC and ONCC instances in a .dat) into Collada DAE files
|-
|<code>-create:m3gm <destination directory> [-tex:texture_name] <OBJ file></code>||Creates a M3GM .oni from an .obj file
|-
|<code>-create:trbs <destination directory> [-cel] [-normals] <DAE file></code>||Creates a TRBS .oni from a .dae file
|}

Note on -noanim parameter: Normally OniSplit exports the character with an idle animation. If you use -noanim the character is exported in "I" pose, also the pelvis has the coordinates x=0, y=0, z=0.

====Levels====
OniSplit can convert AKEV files (level geometry) and the associated file types to and from DAE format:
{|
|<code>-extract:dae <destination directory> <AKEV.oni file></code>||Extracts 3D data in AKEV and related resources from dependencies into Collada file
|}

The next two steps are used on a folder in which you have placed the DAE and XML-formatted instances of the required files, as well as textures in TGA format. See [https://web.archive.org/web/20201127180431/http://oni.bungie.org/forum/viewtopic.php?id=1515 HERE] for details.
{|
|- valign="top"
|<code>-create <destination directory> [-genmipmaps] [-format:dxt1] <source directory></code>||Converts all AKEV and related instances to .oni files
|- valign="top"
|<code>-import:nosep <source directory> <target file name>.dat</code>||The standard command for creating .dat/.raw files from .oni files (remember to use the import:sep option on Mac!)
|}

====Sounds====
The sounds in Windows Oni are stored in WAV format, and on Macs are stored in AIFF format. This also means creating each of your SNDD files in both formats in order to work on both platforms.
{|
|<code>-extract:wav <destination directory> <dat/oni file></code>||Rips sound data from an SNDD .oni file (or all SNDDs from a .dat) as .wav files
|-
|<code>-extract:aif <destination directory> <dat/oni file></code>||Rips sound data from an SNDD .oni file (or all SNDDs from a .dat) as .aif files
|}

====Text====
{|
|<code>-extract:txt <destination directory> <dat/oni file></code>||Rips text data from a SUBT .oni file (or all SUBTs from a .dat) as .txt files
|-
|<code>-create:subt <destination directory> <TXT file></code>||Creates a SUBT .oni file from a .txt file
|}

====XML====
One of the latest features is conversion of .oni files to and from an XML file, or an XML metafile and related 3rd-party format files. XML files are easier to read and edit.
::Currently XML export/import is limited to files that do not have raw/sep parts. 2-way conversion is known to work for [[BINA]], [[CONS]], [[DOOR]], [[DPge]], [[FILM]], [[HPge]], [[IGHH]], [[IPge]], [[M3GM]], [[OBAN]], [[ONCC]], [[ONCV]], [[ONLD]], [[ONLV]], [[ONGS]], [[ONSK]], [[ONVL]], [[ONWC]], [[OPge]], [[OSBD]], [[PSpc]], [[PSpL]], [[PSUI]], [[TRAC]], [[TRAM]], [[TRIG]], [[TRGE]], [[TRMA]], [[TRSC]], [[TXMB]], [[TXMP]], [[WMCL]], [[WMDD]], [[WMM_]], [[WPge]].
:::For detailed examples and tutorials, see [[XML|HERE]]
{|
|<code>-extract:xml <destination directory> <oni file></code>||Extracts .oni file and all related resources to XML files and 3rd-party formats
|-
|<code>-create <destination directory> <XML file></code>||Creates an .oni file from an XML file
|}

====Blender support====
[[Blender]] by default has a number of issues with Oni's assets, however, OniSplit allows exporting them to Blender-readable files with the <tt>{{nbhy}}blender</tt> flag.

For more detailed information on how to use the <tt>-blender</tt> flag, please see {{SectionLink|Importing character models|Blender-specific OniSplit information}}.

[[Category:Completed modding tools]][[Category:Bi-platform modding tools]][[Category:Modding tutorials]]

Engine terminology

2026-04-06T00:10:08Z

Iritscen: added lede and linked to companion article; added names of other subsystems

{{UpdatedForOniX|1.0.0}}
Here is a high-level view of the different versions of the Oni engine and a brief introduction to some of the subsystems in the engine. Also see [[Game data terminology]] to learn more about the game data files.

==Engine versions==
There are three versions of Oni's engine found in released versions of the game. They are referred to interchangeably by various names.
;Windows retail, Windows, PC, v1.0
This version of the engine can be identified as '''v1.0''' from [[Oni (folder)/readme.txt|its read-me]] but is often referred to as the "Windows" or "PC" engine. This version of the engine was used for all localized Windows releases translated into non-English languages as well.

;Mac, Windows demo, v1.1
This version was used for Mac retail and demo releases and can be identified as '''v1.1''' from [[Oni (folder)/Oni ReadMe|the Mac read-me]], and underwent another month of development after v1.0. It was also used for the Windows demo, but is sometimes referred to as the "Mac" engine for simplicity.  Its most obvious difference is the addition of .sep files to the GameDataFolder, but some templates were changed as well.

;PS2
This version was created by Rockstar North for the PlayStation 2 port. It also uses .sep files but makes additional changes to templates. It went through another 3 weeks to a month of development after the Mac version was completed and could possibly be thought of as v1.2, but is probably best understood as a fork of the v1.1 engine made for PS2 compatibility.

==Subsystems==
The engine consists of various subsystems, some of which have colorful animé-related names and some of which have boring descriptive names. If an article is devoted to documenting more of that subsystem, it will be linked.

;AI2
The second iteration of the code for driving the [[AI|AIs]] (NPCs).

;Akira
The [[Graphics|environment]] code, responsible for holding the game world in memory. Named for the 1988 film [[wp:Akira (1988 film)|Akira]].

;BFW
A layer rather than a subsystem: stands for "BungieFrameWork". This is the lower layer of the game engine, consisting of generalized cross-platform engine code. The upper layer is simply called "Oni" and contains specializations needed to implement Oni's gameplay logic.

;BSL
Standing for "BFW Scripting Language", this is the subsystem responsible for running Oni's [[BSL|scripting language]].

;Motoko
The renderer code, responsible for drawing Oni's [[graphics]]. Named for the main character of the 1995 film [[Ghost in the Shell]].

;Totoro
The code for Oni's 3D [[Animation|animation system]]. Named for the 1988 film [[wp:My Neighbor Totoro|My Neighbor Totoro]].

;''Et cetera''
There are various other subsystems that we essentially never talk about, such as LocalInput, WindowManager, SoundSystem2 and TemplateManager.

[[Category:Engine docs]]

AE:Plugins

2026-04-06T00:00:15Z

Iritscen: no need for this link

{{fmbox
| text = This method of modding was made obsolete by the [[AE]]'s introduction in 2009 of modular modding; many of the mods below are available from within the AE Installer.
}}

==Overview==
Plugins are .dat/.raw(/.sep) files that do not conform to the "level#_Final" naming convention. The "level ID" field at the beginning of every instance in a .dat file stores a hashed difference between "_Final" and the suffix of the plugin. Instance files can only be used by Oni under the name specified at the time of their creation.

The retail versions of Oni do not accept plugins as valid "level files", however, this has been fixed for all major versions of Oni as of May 2008. It is thus possible to generate (with OniSplit) and use (with patched Oni engines) a variety of plugins both for "level 0" and for "chapter" levels. Note, though, that just because a feature is new doesn't mean it's as revolutionary/user-friendly/recommendable as you'd like it to be. There's about the same amount of science to making ''and'' using plugins as there is to [[OBD]] and [[BSL]].

Below is an overview of the basic functionality of plugins, and a few words of wisdom as for the philosophy.

Oni loads instance files in a certain order. On NTFS partitions of Windows and in macOS that order will be ASCII-based (case-sensitive, "B" before "a", etc). On Windows 98 and such the order is more random and depends on dates of creation. As for what happens to the ''instances'' in the files being loaded, there is no such thing as "overriding" - more like the first instance registered with a certain name being the only one accessible by that name. Instances without raw parts typically follow the intuitive rule "plugin loaded first - instance registered first". For things like [[OBJC]], the order is reversed, i.e., in order to "override" a level's OBJC you have make sure that the overriding plugin's name comes ''after'' level2_Final or whatever you're "overriding" (so, e.g., level2_OBJC). Finally, some instance types are stored dynamically in an array, so: 1) if you have, e.g., several instance files containing [[ONCC]]s, they will all end up in the "shapeshifter" array (first the ones from the first loaded instance file, ordered by name, then the ones from the second instance file, also ordered by name, etc); 2) If two of those instance file have an ONCC with the same name, both of them be loaded, at their respective places in the array: both will be accessible with F8 and by ID, but only the one loaded first will be accessible by name.

Now busting a few opinions about how plugins are much cooler than user-side use of OniSplit, shell scripts and delta patches. Of course the fact that you can "just" put the plugin in your [[GameDataFolder]] and play makes it look like it's user-friendlier than OniSplit and somehow "empowers dummies" to access modded content without the need for complicated installation routines (with or without a GUI). However, ''one'' thing plugins are ''definitely not'' is ''foolproof''. They are not "just files" that you put into your GameDataFolder "and see what happens" (and then whine about crashes). They all have their compatibility issues, that imply thorough testing and public release notes. Both the modder and the user should be just as careful when working with plugins as when rebuilding "_Final" levels. One should also be careful not to expect too much from plugins in the big scheme of things.

To create a plugin version of the [[AE|Edition]], for example, is a naive wish. A key feature of the Edition is the "globalization" of virtually every character, sound and texture in Oni. Distributing such a plugin in ready-to-use form would amount to distributing a large part of Oni's content for free, which is ''very'' "legally challenged". Also, the download sizes would reach a few hundred megabytes. Last but not least, such a "global" plugin would be redundant of the un-globalized content in the end user's "chapter levels", so: 1) Oni will take up more space on the user's HDD; 2) Oni will load redundant instances simultaneously (thus, in every level, there would be a range of globalized [[ONCC]] from the plugin and then the ONCC originally present in that level), possibly resulting in overflow.

Another issue is that a modder has to provide both a "sep" and a "no-sep" version of every plugin if he wants users of all platforms to enjoy his stuff. Considering all of the above, plugins are not likely to be used on a systematic basis for anything but "100% new" content, and in the scope of projects like the Edition, they hardly make any sense at all, because OniSplit is irreplaceable when it comes to globalization.

Also, plugins suffer from a major limitation on the Mac because of how the engine only allows for 16 instance files to be present in GameDataFolder: that means that if the original 15 .dat files are preserved, only ''one'' plugin is allowed at a time (historically, this used to be level0_Tools). In the absence of a fix, an obvious workaround is to group Oni's chapters into "acts", and launch Oni with one "act" at a time.

One thing plugins ''are'' useful for is testing new content during development. It takes OniSplit much faster to build a small plugin than a chapter level, let alone level0 with full globalization. Note, however, that while working with "hot" file buffers during a modding session, OniSplit can generate a 500-MB level0_Final.dat in about 30 seconds; rebuilding levels ''after a long break'' takes considerably longer.

The only thing you should be careful about when working with such plugins is dependencies. Typically your plugin will be all the smaller as it uses global content, but whoever you give that plugin to should be aware of the globalized resources involved. Otherwise you'll get pointless crash reports all the time just because you assumed people would only use your plugin in tandem with the Edition, etc.

==Examples==
The plugins provided below are for testing purposes only. Apart from "Babel", virtually no plugins should be distributed in the long run, especially those with original game content. Most of the plugins will be generated user-side with xdelta and OniSplit.
===level 0 modules===
The content of level 0 can easily be split into modules like level0_Characters, level0_Music, level0_Speech, level0_Weapons, level0_Levels, etc. The modules are much smaller than a single level0_Final, so they are faster to navigate and to mod. However, when defining such a partition, it's important to come up with a sensible layout early on: this, and the Mac limitation, makes it tricky to design an "official" set of modules to be used by the [[AE|Edition]].
===Babel===
:http://geyser.oni2.net/edition/plugins/level0_Babel.zip
;Description
:Includes a plugin for the PC version. Adds russian versions of menu items, subtitles, text consoles, diary/objective pages and item/weapon descriptions.
;Limitation
:Requires an engine fix (available for PC in the latest Daodan, pending for the Mac) that increases the buffer size for font textures. Without the fix, the original level0_Final will fail to load completely, and out-of-game UI will be screwed up. Things that don't quite work are diary pages and level-specific item descriptions.
===BGI===
:http://geyser.oni2.net/edition/plugins/level0_BGI.zip <- UPDATED 02:52, 28 August 2008 (CEST)
;Description
:Includes a plugin for both PC and Mac. Adds a set of [[AE:BGI|BGI]] troopers and executives with various fighting styles and a set of new weapons (ballistics only, nothing fancy). Does not replace any existing [[ONCC]] or [[ONWC]].
;Limitation
:Only works correctly for a retail version of Oni, with globalized [[TRAC]] and [[TRMA]]. Otherwise, misses [[TXMP]]SUPER_REFLECT (Mukade's env-map texture) and/or various TRAC, some of them not available in the demo. Missing TRAC cause memory corruption.

===HD Griffin===
:http://geyser.oni2.net/edition/plugins/level0_Characters.zip
;Description
:Includes a plugin for both PC and Mac. Replaces the BlackOps Griffin. The new Griffin has a tentative HD head (4 times as many faces) and fights like a Tanker (more so if you update the MELE link in [[CHAR]]).
;Limitation
:Works correctly for a retail version with globalized TRAC and TRMA. Otherwise, misses TRACTanker_animations and BlackOps Griffin's TRMA. Missing TRAC cause memory corruption.

===Shinatama Too===
:http://geyser.oni2.net/edition/plugins/level0_Shin2.zip
;Description
:Includes a plugin for both PC and Mac. Adds new character: a Shinatama who fights like Konoko and no longer hovers above the ground (the TRBS was scaled up and compensated with a body factor in the ONCC). The textures have been color-swapped (meant as placeholders for a more original combat outfit).
;Limitation
:Works for any version, with or without the Edition. Indeed, Konoko's TRAC is global and everything else (TRBS, TRMA, TXMP) is included in the plugin.

===Level 2 CHAR===
:http://geyser.oni2.net/edition/plugins/level2_OBJC.zip
;Description
:Includes a plugin for both PC and Mac. Slightly modifies the [[CHAR]] for {{C|2}}: Barabas takes part in the initial ambush, and Muro appears later on.
;Limitation
:Works with any version of Oni, as long as Chapter 2 is available.
===Dashing===
:http://geyser.oni2.net/edition/plugins/level0_Animations.zip
;Description
:Includes a plugin for both PC and Mac. Makes all males, Ninja and Furies able to dash. Preserves running animations for Konoko. Provides TRAMai_kon_animations to be used by Evil Konoko, female civilians, etc.
;Limitations
:Works best with globalized TRAM. Otherwise, Elites, Ninjas and Furies won't be able to fight. This is typically a thing that will not stay a plugin forever, and is provided purely for testing purposes.

===Camera===
:http://geyser.oni2.net/edition/plugins/level0_Camera.zip
;Description
:Includes a plugin for PC retail only ([[make_corpse]] doesn't work for OMNI or PC demo; and if you have a Mac beta, plugin-loading hasn't been fixed for you anyway). Provides a character class for [[authoring custom camera animations]], complete with a set of animations and an aiming screen. Supposed to be used in conjunction with the manual camera and '''make_corpse''': position camera, make corpse, copy pelvis matrix from corpse to OBAN.
;Limitations
:None. Works with or without edition/globalization. Without make_corpse it is of little use though, except as an experimental hovering turret... just export/import if you're interested in toying with that.

[[Category:Obsolete AE mods]]

OBD:Oni Binary Data

2026-04-05T23:57:58Z

Iritscen: doesn't make sense to link to this terminology page from here, only the Introduction to modding page

[[Image:OBD.png|right]]
{{Hatnote|If you want an introduction to modding for beginners, you should read [[Introduction to modding]].}}
The '''OBD''' namespace is devoted to documenting Oni's binary data (.dat/.raw[/.sep] files) as reverse-engineered by dedicated members of the fan community. Needless to say, this is a highly technical area of the wiki, and knowledge of topics such as [[wp:Hexadecimal|hexadecimal]], [[wp:Pointer (computer programming)|pointers]], and [[wp:Endianness|endianness]] is a prerequisite. Everything about the game's file formats is intended to be documented here, but the core of the Oni Binary Database is the information on resource types ("File types" in the directory below). Note that the [[XML|XML namespace]] documents the resource types in a way which is more modding-oriented and modder-friendly.

This database's information has been used by modders in such [[:Category:Modding projects|projects]] as:
*The [[Anniversary Edition|Anniversary Edition]]
*[[AE:ONK|Oni ni Kanabo]]
*The [[AE:BIP|Binary Improvement Project]]
*[[OniFly]]

The knowledge documented here was also used to develop [[:Category:Modding tools|modding tools]] such as:
*[[OniSplit]]
*[[OniUnPacker|OniUnPacker]]
*[[OME|Oni Model Extractor]]
*[[ONI-Trainer|Oni Trainer]]

==Knowledge base==
{| class="wikitable"
|-
|[[OBD:Instance file format|Instance file format]]
|About .dat files
|-
|[[OBD:Raw and separate file formats|Raw/separate file format]]
|About .raw & .sep files
|-
|[[OBD:Persist.dat|persist.dat]]
|The save-game file
|-
|[[OBD:File types|File types]]
|Resource types such as ONCC, TRAM, etc.
|-
|[[OBD:Data types|Data types]]
|The format of the integers, floats, etc. in the resources
|-
|[[OBD:Globalization|Globalization]]
|Duplication and false duplicates in the resources
|-
|[[OBD:Localization|Localizations]]
|Considerations and pitfalls for localizers
|-
|[[OBD:Releases|Releases]]
|Database of each release's level file sizes
|-
|[[OBD:Text encoding|Text encoding]]
|Variant text encodings found in localizations
|-
|[[OBD:Oni2AS|Oni 2 game data]]
|About the [[Oni2AS|Angel Studios dev build]]
|}

===External Links===
*[http://ssg.oni2.net ssg's Oni Stuff]
:Oni Stuff is the original database of Oni's resource types, source for much of this wiki's OBD. It also contains information which has never been ported to the wiki such as flag locations and data on every character spawned in each level.

{{OBD}}

Talk:OniSplit

2026-04-05T23:50:15Z

Iritscen: reporting a pretty important bug, 18 years late

Talk page archives: [[/Archive1|#1]]

==Textures are darkened when extracted from formats with sub-8-bit channels==
When OniSplit reads the game's textures in any format with <8-bit channel sizes, namely ARGB4444, RGB555 and ARGB1555, and expands the 4- or 5-bit R, G or B channel to 8 bits in response to the {{nbhy}}extract command, it is simply zero-padding the lower bits which results in an overall darkening of the image. The clearest way to see this is with TXMPDAODAN_SHIELD in level0, where all the pixel data in the original RGB555 format says "FF FF". That's meant to be pure white, right? Well when OniSplit extracts this to PNG, etc., it converts the value 11111 found in each channel to 11111000 or 0xF8, resulting in pixels of the color {248, 248, 248} which is a noticeably off-white color. No texture will be able to contain a brighter color than that using OniSplit's math where 11111 << 3 = 11111000. Looking at a histogram of any extracted texture should bear this out, but it's also something the naked eye can see pretty easily if there's bright colors in the image and you have an accurate reference version of the image being extracted. Apparently the community has been missing this ~3% darkening all these years?

Standard practice in this situation is to use "bit replication" where the most significant bits are copied into the space left behind when a value is left-shifted, e.g. a 5-bit channel value 00101 becomes 00101001, not 00101000. This approach properly spreads out the resulting colors across the entire 0-255 range, allowing the 2-byte pixel value FF FF to become pure white while also preserving 00 00 as pure black. There is another scaling algorithm which is even more accurate but slower.

I believe that any new/edited textures passed in through OniSplit will also experience slight darkening, but only if they are converted to one of the above formats with <8-bit channels. Extracted textures that were darkened by being converted to PNG, etc. will regain their brightness when imported back in with {{nbhy}}create because e.g. 11111000 simply goes back to 11111, and this will be displayed by Oni as full-white on a 32-bit display. This may be why no one noticed the issue before now, but probably the key reason is that modders prefer to create every texture in RGB888. But if a user imports an image using the {{nbhy}}format option to create the TXMP.oni in ARGB4444, RGB555 or ARGB1555, it looks like OniSplit will convert it with a downward bias: 0-7 → 0, 8-15 → 1, and finally 248-255 → 31 because it is simply performing a ">> 3" on the number. This is known to darken the image, so the standard practice is to use "rounded scaling" to create a center bias, which I won't detail here. Just wanted to make a note that if someone is fixing the 4-/5-bit → 8-bit conversion math for OniSplit, the math for converting 8-bit → 4-/5-bit should be looked at as well. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 23:50, 5 April 2026 (UTC)

==Smaller version steps possible==
AssemblyInfo.cs
//overwrite product version with 5 possible numbers
[assembly: AssemblyInformationalVersion("0.9.99.0.1")]

Utils.cs
#if NETCORE
version = typeof(Utils).GetTypeInfo().Assembly.GetName().Version.ToString();
#else
//version = typeof(Utils).Assembly.GetName().Version.ToString();
Assembly assembly = Assembly.GetExecutingAssembly();
FileVersionInfo fileVersionInfo = FileVersionInfo.GetVersionInfo(assembly.Location);
version = fileVersionInfo.ProductVersion;
#endif

OniSplit -version
0.9.99.0.1

--[[User:Paradox-01|Paradox-01]] 09:58, 14 November 2023

==Page improvement==
Shouldn't there be an animation section which includes the options -anim-body, -anim-merge and -blender? --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 00:24, 16 May 2022 (CEST)
:Yes, it's odd that -anim-body and -anim-merge are not documented here, someone should do something about that. <s>-blender arguably does not exist yet (it's in geyser's upcoming 1.0 release and is mentioned on the [[OniSplit/WIP]] page).</s> My bad, -blender was added in 0.9.99.2. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 01:05, 16 May 2022 (CEST)

==If OniSplit refuses to be used==
delete file at AE/Tools/OniSplit.exe.config --[[User:Paradox-01|Paradox-01]] 18:00, 28 June 2020

==OniSplit version control - getting there...==
The SVN version of OniSplit is currently labeled 0.9.99 (same as the source received from Neo), and at this point it is different from the non-synced 0.9.99.2 that I distributed through EdT.
*"0.9.99" has only two commits (44.1 kHz SNDD export - affecting only electric spark sounds - and other minor SNDD fixes and features);
*0.9.99.2 has a few fixes to 0.9.99 (adjustment to XML parsing rules) and new functionality for Blender import/export of animations; also some new bugs, apparently.
To restore some order, I am going to merge my 0.9.99.2 fixes to SVN, then address the known bugs, and push the version number to 0.9.99.3 - and use SVN-synced development from then onwards.

I am ''not'' going to create a branch for my fixes/improvements, except maybe when it comes to adding something big, like C# FBX support. If you object to this, speak now. --[[User:Geyser|geyser]] ([[User talk:Geyser|talk]]) 00:09, 29 May 2020 (CEST)

List of bugfixes and improvements planned for 0.9.99.3 (feel free to add to the list if I forgot something)
*some running/walking anims end up upside-down after reimported into Oni
*-extract:dae -noanim -blender used on a TRBS, make sure the output .dae file has a TRBS prefix
*stairs_markers.dae not imported properly? (and more generally secondary/auxiliary .dae files not imported for levels?)
*TRAM export: support writing of sparse keyframe data (as in Oni), as opposed to writing rotations for ''every'' frame (interpolated)
*maybe allow the export of named TRCM (without material)
*TGA transparency bug? (not-yet-confirmed as a bug; supposedly happens only for SketchUp-made levels; see below)
*various SNDD glitches (inconsistent handling of ADPCM headers)

----
When will you update the repo? --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 16:40, 13 April 2023 (CEST)

I couldn't import FILM via '''xml master file for level import''' with current Onisplit compiled from svn. A possible fix is to change <code>ReadElementContentAsString</code> to <code>ReadContentAsString</code>.
...
<Films>
<Import>films/BomberKonRun02.xml</Import>
</Films>
...

FilmImporter.cs
...
private void ReadFilms(XmlReader xml, string basePath)
...
//string filePath = Path.Combine(basePath, xml.ReadElementContentAsString());
string filePath = Path.Combine(basePath, xml.ReadContentAsString());

:[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 12:59, 14 November 2023 (CET)

==TGA Transparency bug==
I extracted HQ_DOUBLED_GLASS as TGA format from vanilla Level8_Final with the OniSplit command -extract:tga. The file was opened in Photoshop and the alpha channel was visible.
I then added that texture to Sketchup and applied it in a test level, it appeared transparent in Sketchup. I used the command -create:level to create a level in Oni. In the game Oni, the texture appeared opaque not transparent. When, the file TXMPHQ_DOUBLED_GLASS.oni was extracted from the test level as TGA, the alpha channel was gone or opaque.

Even if the following code was added to the textures.xml file, the texture still appeared opaque in game.

<Texture Name="HQ_DOUBLED_GLASS">
<GunkFlags>Transparent TwoSided</GunkFlags>
<Format>RGBA</Format>
<Image>images/HQ_DOUBLED_GLASS.tga</Image>
</Texture>

However, if HQ_DOUBLED_GLASS.tga is converted to PNG format with alpha channel, and then the PNG file is used in Sketchup, then the texture will be transparent in game.

This occurs using OniSplit version 0.9.96.0 and previous versions, tested to version 0.9.90.0. (EDIT: Transparency loss is observed for all glass textures, not just HQ_DOUBLED_GLASS.)

[[User:EdT|EdT]] 15:03, 14 May 2020 (PDST)

When you described the issue to me in PM, I didn't notice/understand the key part about applying the texture in SketchUp and then using -create:level on SketchUp's output. I thought we were talking about a simple TXMP roundtrip through TGA. Can you confirm that the texture's alpha goes opaque (or disappears) if you use -extract:tga on TXMPHQ_DOUBLED_GLASS.oni, and then immediately reimport it either with '''-create''' (either from XML with extra flags or from TGA)? --[[User:Geyser|geyser]] ([[User talk:Geyser|talk]]) 11:44, 15 May 2020 (CEST)

Regarding the TXMP roundtrip, after extracting TXMPHQ_DOUBLED_GLASS.oni as TGA, I used the command -create:txmp -format:bgra32 -large -genmipmaps, the resulting file had the alpha channel. To confirm, I replaced the file TXMPHQ_DOUBLED_GLASS.oni from the -create:level with the one from -create:txmp in the test level and it was transparent.
[[User:EdT|EdT]] 12:35, 15 May 2020 (PDST)

This looks like an issue with the SketchUp pipeline, rather than with OniSplit, since it is only '''-create:level''' that generates a non-transparent texture, and '''-create:txmp''' actually works fine. Can you: a) provide (in PM) the level data that you are using '''-create:level''' on (supposedly a .dae file, some texture files, and some XMLs)? b) provide an example of a level that imports with transparent glass as expected (supposedly a level that didn't come from SketchUp). Thanks. --[[User:Geyser|geyser]] ([[User talk:Geyser|talk]]) 16:46, 16 May 2020 (CEST)

==Sound export bug==
As discussed on Discord there's a sound export bug for SNDDzap*.oni

One might record the sounds in OBS and compare it with the exported ones to generate further hints on what went wrong. --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 13:29, 21 July 2019 (CEST)

#The zap sounds are randomized in an OSBD group, so recording them from the game in some identifiable way would require some extra work (custom OSBD). It's much easier to ask Mac folks for AIFF versions of those sounds. ''And actually, there are [[seven]] zap sounds in the PC demo as well.''
#OniSplit slaps a 22.05 kHz header on those files, although they're 44.1kHz and have a perfectly good 44.1kHz header in Oni. Not sure why they're getting a 22.05kHz header. Perhaps Neo got confused by the sloppy documentation of the [[OBD:SNDD/wav|WAV header]], which until my edit gave the same hex listing for the three WAV header types. Either that, or he just assumes the sample rate to be 22.05kHz by default and doesn't update it from the actual file. Will check in the code. ''Actually yeah, he just does as if all the sounds were 22.05kHz.''
#Besides SNDDzap*.oni, there is one other 44.1kHz sound in PC Oni, SNDDap_hit_shld.aif; which suffers from the same export problem, although it's less noticeable.
#Apparently 22.05 kHz stereo sounds are correctly exported as stereo, it's just 44.1 kHz mono files that get a wrong WAV header.
#Will be fixing this in the latest "nightly" OniSplit (haven't yet decided on a version numbering and source control scheme).
#:[[User:Geyser|geyser]] ([[User talk:Geyser|talk]]) 07:15, 25 March 2020

[[Category:Completed modding tools]][[Category:Bi-platform modding tools]]

Game data terminology

2026-04-05T21:29:50Z

Iritscen: added lede, improved some wording, mentioned that .oni files do contain subordinate types of the main instance being exported

{{OBD Home}}
{{UpdatedForOniX|1.0.0}}
A brief introduction to game data-related terms that you will need to know when learning to mod. Also see [[Engine terminology]] to learn more about the engine itself.

;Binary data
A collective term for all of the game data that Oni runs on. It is mostly distributed among the level data files; though some additional data is found in persist.dat, the term "binary data" tends to refer only to the level data files. Not to be confused with "binary", which refers to a compiled application.

;Level data files
The data for each level is found in a pair of files in Windows retail Oni's [[GameDataFolder]] ending in ".dat" and ".raw". On Macs and in the Windows demo, a file type ending in ".sep" is also used. [[OniX]] also expects .dat/.raw/.sep files, so the app's installer converts the user's game data to the .dat/.raw/.sep format.

;Instance file
Any .dat file in GameDataFolder. [[Instance file]]s are the main type of level data file, in the sense that Oni reads the instance file first when loading a level, and this file serves as an index that allows it to find resources which are packed into the other types of level data files.

;.dat file
".dat" is a generic suffix originally used by Oni for all kinds of data, with file names such as level0_Final.dat, [[persist.dat]], and developer-related files such as saved_film*.dat, level_*_corpse.dat, etc. The proper, specific name for the .dat files containing level data is "instance file". That being said, ".dat" has only been used by the community historically to refer to instance files, so you can reasonably assume that's what is meant when you see the suffix by itself. On occasion, ".dat" also refers to the complete set of level data files, .dat/.raw[/.sep].

;Instance, resource, file
The use of these terms can be confusing. An instance is often called a file on this wiki, but an instance is not the same as an instance file ending in .dat. An instance is an individual resource such as a texture. They are sometimes called files because they are distinct pieces of data stored and cataloged in a "file system" composed of a set of .dat/.raw[/.sep] files. In at least some cases they were indeed actual, separate files on the developer's computer before being packed into the level data files.

When OniSplit is used to split level data files into individual files for each resource, in effect it is creating thousands of "single-instance instance files" ending in .oni, at which point "instance", "resource", "file", and "instance file" become basically synonymous.

;Raw file, .raw
;Separate file, .sep
During development, these types of level data files were eventually created as companions to instance files. The kinds of resources stored in these files are generally those with larger amounts of data, like textures and sounds.

Raw files are found in all versions of Oni, whereas separate files, in vanilla Oni installations, only occur in Mac Oni and in the Windows demo. As mentioned earlier, when using OniX, Windows retail installations will also use .sep files because that is the level file format that the engine expects. When separate files are present, raw files are much smaller because several resource types have their data stored in the separate file instead.

Raw and separate files have no file header and are simple blobs of data; this is because the instance file serves as the table of contents for them. The only structural rules about raw/separate files are that (1) all data parts are stored 32 byte-aligned and (2) the first 32 bytes of the file are always zero. When a level is loaded into memory, the offsets given for raw/separate data in various resources are converted to pointers to the actual data in the raw/separate files. You can learn the format of raw/separate files [[Raw|HERE]].

;Template, file type, tag
A template represents a type of resource identified by a four-character code (e.g. "SUBT" for subtitle files); this kind of identifier is generically called a "tag", so modding communities often use the term "tag" to refer to a resource type as a whole. However, just as instances are often called files on this wiki, templates are often called file types here. All templates are listed on the [[OBD:File types|File types]] page.

;.oni
Generated by [[OniSplit]], these files are structurally similar to .dat files except that they only contain a single instance, or one parent instance and various supporting instances if the supporting instances could be considered components of the parent instance; for instance an exported M3GM (a 3D model) will contain all of its 3D data even though this data is held in many small instances of several other templates such as PNTA and VCRA. And unlike how .dat files offload some data to .raw and .sep files, in a .oni file any of the data that might have been contained by the .raw/.sep files is simply appended at the end of the .oni file.

[[Category:Engine docs]]

Validate External Links/Exceptions

2026-04-05T21:04:55Z

Iritscen:

If the Validate External Links script is mis-reporting certain external links as issues when they actually work fine or when the link has to be presented that way for a specific reason, add them here in order to exempt them from ValExtLinks' reports. The list is sorted by wiki page name for convenience. Each line supports four comma-separated fields, the first three required:
#The response code that ValExtLinks should expect. For NG and RD links, this should be the exact HTTP response code or the 'curl' result code, whichever applies. You can also put "IW" or "EI" here to exempt a warning about an interwiki or external internal link.
#The recurring "problem" link. Place a '*' as a wildcard at the end of a URL to match multiple links.
#The wiki page that this link is appearing on. Use the proper page name, i.e. underscores where the displayed name has spaces. To exempt this link from Val's report regardless of what page it appears on, put a '*' here.
#(optional) A comment explaining the exception. The only requirements are that the comment be separated from the previous field by a space and that you don't use any commas. The "--"s used below are only for human readability.

<pre>
BEGIN LIST
403,https://dotnet.microsoft.com/en-us/download/dotnet-framework,*
403,https://dev.epicgames.com/*,*
403,https://*.blender.org/*,*
403,https://*.fandom.com/*,*
403,https://*.gamespot.com/*,*
403,https://wikis.khronos.org/opengl/History_of_OpenGL,AE:ONK/EXE
403,https://www.gamefront.com/games/jedi-knight-iii/file/major-kusanagi,AE_talk:BGI
403,https://www.java.com/en/download/,Anniversary_Edition
403,https://binarygroup.com/,BGI
403,https://x.com/craigmullins3/status/1920384911292207363,Category:Art_by_Craig_Mullins
403,https://x.com/mehvechan,Category:Art_by_Lorraine_Reyes
403,https://x.com/Quantum_Sheep/status/1473397180535029760,Category:Oni_(WAP)_game_images
403,https://www.artstation.com/artwork/D9d2o,Duality
403,https://www.artstation.com/artwork/Jl8YXa,Duality
403,https://www.artstation.com/artwork/4bNKW4,Duality
403,https://www.artstation.com/artwork/l9g5V,Duality
301,http://translate.google.com/#en%7Cja%7CChrysalis,File:Daodan_Chrysalis_in_Chinese.png
403,https://www.artstation.com/artwork/4bNKW4,File:Duality_concept_art_-_BioCorp_VR_avatar.jpg
EI,https://wiki.oni2.net/Special:ListFiles?limit=500&ilsearch=Fallen,File:Fallen_Enemies.jpg -- EI link is necessary because this special page can't take these parameters when linked to internally
403,https://www.fab.com/listings/a1fe637c-ef4d-45de-9a21-9a377d06dee1,File:KatiaVersusKonokoFront.png
403,https://x.com/mehvechan/status/556178295612391425,File:Lorraine_Reyes_with_Konoko_Fully_Armed_standup.jpg
000-92,https://www.adobe.com/products/catalog.html#category=3d-ar,Fuse
000-92,https://helpx.adobe.com/beta/fuse/faq.html,Fuse
404,https://www.autodesk.com/products/fbx/overview,Importing_character_models
000-92,https://www.adobe.com/creativecloud/plans.html,Media_creation_with_artificial_intelligence
EI,http://wiki.oni2.net/Main_Page,MediaWiki:Vector -- necessary EI link to demonstrate circular arrow
EI,http://wiki.oni2.net/Main_Page,MediaWiki:Vector-2022 -- necessary EI link to demonstrate circular arrow
404,https://www.autodesk.com/products/softimage/overview,Mod_Tool
403,https://www.guru3d.com/download/rtss-rivatuner-statistics-server-download,Mouse_control_issues
403,https://www.vgmpf.com/Wiki/index.php?title=Brian_Salter,Music
403,https://www.supreme-network.com/midis/browse/O/3494-oni/13574-konoko-chase,Music/Fanmade
403,https://wikis.khronos.org/opengl/S3_Texture_Compression,OBD:TXMP
403,https://www.sec.gov/Archives/edgar/data/946581/0000891554-00-000145.txt,Oni
403,https://www.sec.gov/Archives/edgar/data/946581/000112528202003845/b320556.htm,Oni
403,https://www.artelino.com/articles/japanese_mythology.asp,Oni_(myth)
403,https://pcsx2.net/,Oni_(PlayStation_2)
000-28,https://mega.nz/#!x9oHxaLZ!-bOo-wwdj1fh925DYv1Qc6ErDSRl2HEgtWC-i2FtxtY,Oni_2_(Angel_Studios) -- Mega doesn't seem to like 'curl'
403,https://pcsx2.net/,Oni_2_(Angel_Studios)/Running
000-28,https://www.echeat.com/free-essay/Symbolism-in-Fahrenheit-451-by-Ray-Bradbury-29746.aspx,Oni2:Phoenix
403,https://www.telegraph.co.uk/news/newstopics/howaboutthat/3328480/Otto-the-octopus-wrecks-havoc.html,Oni2:Slaves_of_War/Neo-Biology
403,https://featuredcreature.com/from-dangerous-fluff-to-bunny-stuff/,Oni2:Slaves_of_War/Neo-Biology
403,http://www.conoserver.org/,Oni2:Slaves_of_War/Neo-Biology
403,https://www.cracked.com/article_19988_the-5-most-nightmarish-worms-planet.html,Oni2:Slaves_of_War/Neo-Biology
403,https://www.cracked.com/article_20078_5-weird-directions-human-evolution-could-have-taken.html,Oni2:Slaves_of_War/Neo-Biology
403,https://www.treehugger.com/rare-interspecies-play-observed-between-dolphins-and-whales-4857038,Oni2:Slaves_of_War/Neo-Biology
403,https://www.viator.com/tours/Rio-de-Janeiro/Niteroi-City-Tour-and-Contemporary-Art-Museum-Admission/d712-8753P7,Oni2:Slaves_of_War/Settings
403,https://www.cracked.com/article_17562_5-horrifying-apocalyptic-scenarios-that-have-already-happened.html,Oni2:Slaves_of_War/Settings
403,https://www.cracked.com/article_19678_6-abandoned-places-that-will-make-awesome-supervillain-lairs.html,Oni2:Slaves_of_War/Settings
403,https://www.peninsula.com/en/newsroom/hong-kong,Oni2:Slaves_of_War/Settings
403,https://www.nexusmods.com/games/oni,OniGalore:Community_portal
302,http://www.gnu.org/copyleft/fdl.html,OniGalore:Copyrights
403,https://www.sfgate.com/entertainment/article/WOMEN-WARRIORS-Forget-Lara-Croft-the-new-3240096.php,Press_coverage
403,https://x.com/robinalexander_/status/1872960359696376127,Restless_Souls/Glossary/Artifacts
000-92,https://www.washingtonpost.com/news/wonk/wp/2015/08/27/trump-the-bible-means-a-lot-to-me-but-i-dont-want-to-get-into-specifics/,Restless_Souls/Glossary/Artifacts
403,https://x.com/elonmusk/status/1882406209187409976,Restless_Souls/Glossary/Artifacts
403,https://www.president.gov.ua/documents/6792022-44249,Restless_Souls/Glossary/Artifacts
302,https://www.golem.de/news/kritik-an-nasa-musk-will-direkt-zum-mars-fliegen-2501-192128.html,Restless_Souls/Glossary/Artifacts
403,https://www.axios.com/2025/01/23/elon-musk-nazi-joke-adl,Restless_Souls/Glossary/Artifacts
403,https://www.axios.com/2022/05/02/mark-esper-book-trump-protesters,Restless_Souls/Glossary/Artifacts
302,https://www.golem.de/news/kuenstliche-intelligenz-grok-3-veraergert-maga-anhaenger-2505-195906.html,Restless_Souls/Glossary/Artifacts
403,https://www.luzernerzeitung.ch/kultur/debatte-das-ende-des-westens-ist-da-was-heisst-das-fuer-die-schweiz-und-europa-ld.2751339,Restless_Souls/Glossary/Artifacts
403,https://www.ndtv.com/world-news/transgender-vs-transgenic-mice-row-over-donald-trumps-animal-experiments-claim-7867258,Restless_Souls/Glossary/Artifacts
000-92,https://www.washingtonpost.com/archive/politics/1997/04/24/russia-china-sign-new-friendship-pact/896539b8-c583-44f2-8a73-095cbad1e784/,Restless_Souls/Glossary/Artifacts
403,https://www.economist.com/by-invitation/2022/03/11/john-mearsheimer-on-why-the-west-is-principally-responsible-for-the-ukrainian-crisis,Restless_Souls/Glossary/Artifacts
403,https://www.nytimes.com/2025/09/18/us/politics/trump-fcc-licenses.html,Restless_Souls/Glossary/Artifacts
000-92,https://www.washingtonpost.com/national-security/2025/09/18/trump-taiwan-arms-sales-military-aid/,Restless_Souls/Glossary/Artifacts
403,https://x.com/LAGovJeffLandry/status/2002950029494124986,Restless_Souls/Glossary/Artifacts
302,https://www.derstandard.de/story/3000000301573/putin-gab-sich-bei-seiner-jahrespressekonferenz-wieder-einmal-volksnah,Restless_Souls/Glossary/Artifacts
403,https://www.politico.com/news/2025/06/02/pentagon-greenland-northern-command-00381223,Restless_Souls/Glossary/Artifacts
303,https://link.springer.com/article/10.1007/s41748-026-01073-y,Restless_Souls/Glossary/Artifacts
302,https://www.golem.de/news/abschreckungspolitik-taiwan-will-tsmc-fabriken-nicht-von-usa-bombardieren-lassen-2305-174057.html,Restless_Souls/Glossary/de
000-92,https://www.washingtonpost.com/archive/politics/1997/04/24/russia-china-sign-new-friendship-pact/896539b8-c583-44f2-8a73-095cbad1e784/,Restless_Souls/Glossary/de
403,https://www.economist.com/by-invitation/2022/03/11/john-mearsheimer-on-why-the-west-is-principally-responsible-for-the-ukrainian-crisis,Restless_Souls/Glossary/de
403,https://acronyms.thefreedictionary.com/uwl,Restless_Souls/Reconstruction
403,https://acronyms.thefreedictionary.com/uwl,Restless_Souls/Reconstruction/Gapfilling
403,https://acronyms.thefreedictionary.com/SSOB,Restless_Souls/Reconstruction
403,https://acronyms.thefreedictionary.com/SSOB,Restless_Souls/Reconstruction/Gapfilling
000-92,https://www.washingtonpost.com/national-security/2025/08/31/trump-gaza-plan-riviera-relocation/,Restless_Souls/Research/Artifacts
403,https://x.com/MEMRIReports/status/1721097018062606708,Restless_Souls/Research/Artifacts
403,https://x.com/MedvedevRussiaE/status/1821967864947220777,Restless_Souls/Research/Artifacts
403,https://www.nytimes.com/2024/07/24/world/middleeast/gaza-war-hepatitis-polio.html,Restless_Souls/Research/Artifacts
403,https://www.researchgate.net/publication/262485473_The_Russia-China_Security_Partnership_in_the_Asia-Pacific_Region_Conjectural_and_Structural_Dimensions,Restless_Souls/Summary
403,https://www.forbes.com/sites/wadeshepard/2019/10/03/what-china-is-really-up-to-in-africa/,Restless_Souls/Summary
404,https://idw-online.de/de/attachmentdata8851.pdf,Restless_Souls/Technology
403,https://www.unrealengine.com/en-US,Restless_Souls/Wishlist
301,https://www.bungie.net/,Rights
403,https://tsdr.uspto.gov/caseviewer/assignments?caseId=75570211&docIndex=1&searchprefix=sn#docIndex=1,Rights
403,https://acronyms.thefreedictionary.com/WPS,Talk:Hasegawa
403,https://www.ixbt.com/video2/tech_ss2.shtml,Talk:Oni_Model_Extractor
301,https://www.welt.de/debatte/kommentare/plus246585502/Niedergang-Deutschland-zeigt-der-Welt-wie-man-es-nicht-macht.html,Talk:Restless_Souls/Summary
302,https://www.derstandard.at/story/3000000190426/der-nahostkonflikt-in-oesterreichs-klassenzimmer,Talk:Restless_Souls/Summary
303,https://www.bmjv.de/DE/themen/menschenrechte/menschenrechte_node.html,Talk:Restless_Souls/Summary
403,https://www.researchgate.net/figure/S-curves-for-the-established-and-disruptive-technology-Performance_fig2_4899992,Talk:Restless_Souls/Technology
302,https://de.statista.com/statistik/daten/studie/1208627/umfrage/ausbreitung-von-corona-mutationen-in-deutschland/,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/haeufiger-als-andere-modelle-chatgpt-sabotiert-bei-tests-eigene-abschaltung-2505-196561.html,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/microsoft-studie-diese-berufe-veraendert-ki-am-staerksten-2508-198747.html,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/neue-ki-architektur-was-ist-baby-dragon-hatchling-2510-201047.html,Talk:Restless_Souls/Technology
403,https://www.forbes.com/sites/mattnovak/2023/04/11/elon-musk-working-on-ai-at-twitter-despite-calling-for-6-month-pause-report/,Talk:Restless_Souls/Technology
403,https://www.forbes.com/sites/ronschmelzer/2025/10/09/samsung-ai-research-team-builds-a-tiny-model-with-big-powe/,Talk:Restless_Souls/Technology
302,https://www.derstandard.de/story/3000000302571/neuralink-will-gehirn-chips-in-serie-fertigen-operationen-bald-automatisiert,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/claude-opus-4-6-ki-findet-ueber-500-zero-day-luecken-in-open-source-software-2602-205139.html,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/soziales-netzwerk-moltbook-entpuppt-sich-als-ki-trugbild-2602-205141.html,Talk:Restless_Souls/Technology
403,https://medium.com/@aloy.banerjee30/infinite-context-length-in-llms-the-next-big-advantage-in-ai-2550e9e6ce9b,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/hackerbot-claw-ki-agent-kapert-softwareprojekte-auf-github-2603-205990.html,Talk:Restless_Souls/Technology
302,https://www.golem.de/news/unkontrollierbares-fehlverhalten-ki-agenten-werden-zu-immer-groesserem-insider-risiko-2603-206491.html,Talk:Restless_Souls/Technology
403,https://www.unrealengine.com/en-US/blog/a-first-look-at-unreal-engine-5,Talk:UnrealOni
404,https://www.autodesk.com/products/fbx/overview,Template:AutodeskFBX
000-92,https://www.adobe.com/creativecloud/plans.html,Template:Photoshop
403,https://www.sec.gov/Archives/edgar/data/946581/0000891554-00-000145.txt,Timeline_of_development
403,https://www.sec.gov/Archives/edgar/data/946581/000112528202003845/b320556.htm,Timeline_of_development
403,https://www.fab.com/listings/ef9651a4-fb55-4866-a2d9-1b38b028f9c7,UnrealOni/ALS
403,https://www.fab.com/listings/ef9651a4-fb55-4866-a2d9-1b38b028f9c7,UnrealOni/Tutorials
403,https://www.fab.com/listings/a1fe637c-ef4d-45de-9a21-9a377d06dee1,User:Geyser/CharacterTutorialMakeHumanToUE4
EI,https://wiki.oni2.net/Special:AllMessages?prefix=&filter=modified&lang=en&limit=50,User:Iritscen/WikiMods -- EI link is necessary
302,https://m.facebook.com/groups/186656799756?refid=27,User:Samer
403,https://www.speedrun.com/oni,Videos
403,https://www.computerhope.com/jargon/w/wildcard.htm,XmlTools
END LIST
</pre>

[[Category:Wiki Support]]

OniUnPacker/source

2026-04-05T20:54:07Z

Iritscen: link fixes

{|align=right
|[[Image:OBD.png]]
|}
== OniUnPacker source code information ==

=== Source folder ===

The source folder contains the following files:
* \DataAccess
*: Units for accessing different kinds of containers
** .\ConnectionManager.pas
*: Handles Connections and keeps track of DataAccess-instances
** .\DataAccess.pas
*: (Virtual) Base class for access to data containers
** .\Access_OniArchive.pas
*: Access to Oni's archives (.dat in conjunction with .raw and .sep)
** .\Access_OUP_ADB.pas
*: Access to OUP's databases (AbsoluteDatabase)

* \FileClasses
*: BLA - DESCRIPTION NEEDED

* \Global
*: Globally used Units (functions, data, typedefs ...)
** .\Data.pas
*: Contains global constants, variables
** .\DatLinks.pas
*: Generates .dat-linkById-lists for each filetype
** .\DatStructureLoader.pas
*: Loads structure-definition files
** .\Exporters.pas
*: Handles exporting of .dat/.raw-content (including converters)
** .\Functions.pas
*: Common functions like en-/decoding of data
** .\Img_DDSTypes.pas
*: DDS-header-definitions used by OniImageClass
** .\OniImgClass.pas
*: Loading/saving/converting of Oni's texture-data
** .\RawList.pas
*: Generates lists of .raw-contents for files
** .\TypeDefs.pas
*: Definition of globally used types

* \Helper
*: Small helpful forms
** .\LevelDB.dfm/.pas
*: Converts OniArchives to OUP-DBs and vice versa
** .\ValueEdit.dfm/.pas
*: Input form for editing variable contents
** .\WhatLinksHere.dfm/.pas
*: Shows links to (only supported in DBs) / from a file

* \icons
*: Contains icons used in the gui

* \ImportedStuff
*: Units written by others
** .\FolderBrowser.pas
*: Select a folder as you do in any normal windows application.
** .\FTypeReg.pas
*: Set/Get registered file types
** .\OneInst.pas
*: Makes sure that only one instance of OUP can be run at a time

* \Tools
*: Contains the basic tools in OUP like Preview, BinEdit ...
** .\Template.dfm/.pas
*: Template-form used for most tools
** .\BinEdit.dfm/.pas
*: HexEditor for .dat-files with StructureViewer
** .\RawEdit.dfm/.pas
*: HexEditor for .raw-contents
** .\Extractor.dfm/.pas
*: Mass file extractor
** .\Preview.dfm/.pas
*: Preview window (only supports TXMP, TXMB, TXAN, PSpc atm)
** .\TxmpReplace.dfm/.pas
*: Replaces TXMP images by image files

* \ExtraIcos.res
*: Contains the icons used in the gui

* \Main.dfm/.pas
*: Main window of OUP

* \OniUnPacker.bdsproj
*: Delphi project file

* \OniUnPacker.dpr
*: Main unit

* \OniUnPacker.res
*: Program icon

* \Settings.dfm/.pas
*: Settings formular

Note: Files which have a .dfm version besides the .pas version are units with forms (windows). Files which that are only there as a .pas are code only, sometimes global functions, some are global classes.

=== Used third party components ===

*[https://web.archive.org/web/20070217204248/http://www.soft-gems.net/VirtualTreeview/ Virtual TreeView]: Used in binary editors. Really powerful tree view component. (Used v4.4.3, but any newer version should work too). License: Open source (MPL/GPL).
*[https://web.archive.org/web/20250725025140/https://www.componentace.com/bde_replacement_database_delphi_absolute_database.htm Absolute Database]: Used for storing level data for OUP. SQL database. You just have to give them your eMail address so they can send you an unlock key, you won't get any spam or newsletters. If you don't want to give them your normal address you can use a spam address like you can get at [https://www.spamgourmet.com/index.pl spamgourmet]. License: Free for personal use.
*[https://web.archive.org/web/20071012140913/http://www.mirkes.de/de/delphi/vcls/hexedit.php MPHexEditor]: Hex component for binary editors. License: Freeware with source.
*[https://chrilly.net/crossedit.rar CrossEdit]: Input component with value validation. Original code from [https://web.archive.org/web/20160804060817/https://www.torry.net/vcl/edits/diffedits/crossedit.zip here]. License: Freeware with source.
*[https://chrilly.net/twrapgrid.rar WrapGrid]: Used the code from [http://web.archive.org/web/20191108032711/http://www.mindspring.com/~cityzoo/tips/wrapgrid.txt here] and enhanced it for my special purposes. Needed additions are the column colorings, cell hints and images in cells. License: Couldn't find one. Suppose open source.
*[https://jrsoftware.org/tb2k.php Toolbar2000]: Toolbar component. License: Freeware with source.
*[https://www.mitec.cz/Downloads/MDITab.zip]: MDI Tabbar component. License: Freeware with source.
*[https://imaginglib.sourceforge.io/ ImagingLib]: Image-handling library. License: MPL/LGPL.

[[Category:Outdated modding tools]][[Category:Windows-only modding tools]]

OBD:TXMP

2026-04-05T19:35:04Z

Iritscen: added detail on effects options and PS2 palette format; added section on pixel byte storage order; made formal subsections out of informal subsections

{{OBD_File_Header | type=TXMP | prev=TXMB | next=TxtC | name=Texture Map | family=General | align=center}}

TXMP is the only known instance type that is interpreted differently by the three kinds of Oni engines on the three platforms (Windows, Mac and PS2).

The difference between the format used in v1.0 of the engine (Windows retail) and v1.1 (Windows demo, Mac, [[OniX]]) is minor, at least from the point of view of disk storage (the structural difference is limited to runtime fields grouped at the end of the instance, which is why they haven't been documented or implemented in OniSplit). A more obvious difference is that v1.0 TXMPs store their pixel data in the .raw file and v1.1 TXMPs use the .sep file, but as far as the .dat is concerned this merely amounts to using a different data pointer field within the TXMP structure. Thus, even though the template checksums for v1.0 and v1.1 are different, both formats can easily be described together.

The PS2 implementation is significantly different from the other two, in that it systematically uses indexed colors: instead of color being stored in the pixel data itself, each pixel is merely an index into a custom 256-color palette. This format is detailed under {{SectionLink||PS2 implementation}}.

==Windows/Mac implementation==
[[Image:txmp_all.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x00 | res_id |FF0000| 01 1F 00 00 | 31 | 00031-rl_1.TXMP }}
{{OBDtr| 0x04 | lev_id |FFFF00| 01 00 00 06 | 3 | level 3 }}
{{OBDtr2|0x08 | char[128]|FFC8C8| rl_1 | name of the texture; unused }}
{{OBDtr| 0x88 | int32 |FFFFC8| 00 10 00 00 | 0x1000 | options; possible option flags (from left to right):
:0x01 - has mipmaps
:0x04 - U wrapping disabled
:0x08 - V wrapping disabled
:0x10 - ignored
:0x40 - animation order: play back to back (frames 0 to n then n-1 to 0)
:0x80 - animation order: play in random order
:0x100 - animation time: add local (particle) time (see below)
:0x200 - has environment map texture
:0x400 - additive alpha blending
:0x1000 - little-endian data
:0x4000 - animation time: ignore game time (see below)
:0x8000 - effect: blue shield
:0x10000 - effect: invisibility
:0x20000 - effect: Daodan shield}}
{{OBDtr| 0x8C | int16 |C8FFC8| 80 00 | 128 | width of the image in pixels }}
{{OBDtr| 0x8E | int16 |C8FFC8| 80 00 | 128 | height of the image in pixels }}
{{OBDtr| 0x90 | int32 |C8FFFF| 09 00 00 00 | 9 | texture format; see below for list of available formats.
:0 - ARGB4444, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Four 4-bit channels, with bitmasks 0x000F (Blue), 0x00F0 (Green), 0x0F00 (Red) and 0xF000 (Alpha).
:1 - RGB555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels, with bitmasks 0x001F (Blue), 0x03E0 (Green) and 0x7C00 (Red).
:::N.B. The high bit (0x8000) is unused, but the convention is to always set it to 1.
:2 - ARGB1555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels with bitmasks 0x001F (Blue), 0x03E0 (Green) and 0x7C00 (Red), 1-bit alpha (0x8000).
:3 (never used in vanilla TXMPs)<ref>[[TSFT]] implicitly uses I8 for storing its glyphs in the PC versions, at least in most languages (the Chinese version has its own font storage system), but TSFT doesn't use TXMP to store its pixel data so it doesn't count as a use of this TXMP format type.</ref> - I8, 8 bits/pixel, stored as a single byte. Monochrome "intensity" (256 levels of gray).
:4 (never used in vanilla TXMPs) - I1, 8 pixels/byte. Pixel rows, bottom to top. Monochrome "intensity" (black-or-white).
:5 (never used in vanilla TXMPs) - A8, 8 bits/pixel, stored as a single byte. Standalone alpha (256 levels of opacity).
:6 (never used in vanilla TXMPs) - A4I4, 8 bits/pixel, stored as a single byte. Intensity (bit mask 0x0F), alpha (0xF0).
:7 (never used in vanilla TXMPs<ref>Storage format 7 was jointly used by OniSplit, Daodan DLL and the Intel Mac build to allow for 32-bit textures with transparency - most importantly experimental lightmaps, see [[Lightmapping levels|HERE]]. However, the actual storage format used in this case was RGBA_Bytes (type 11), and type 7 was used by mistake.</ref>) - ARGB8888, 32 bits/pixel (stored as a little-endian int32, swaps to big-endian at runtime on a PowerPC Mac)
::Four 8-bit channels, with bitmasks 0x000000FF (Blue), 0x0000FF00 (Green), 0x00FF0000 (Red) and 0xFF000000 (Alpha).
:8 - RGB888, 32 bits/pixel (stored as a little-endian int32, swaps to big-endian at runtime on Mac)
::Three 8-bit channels, with bitmasks 0x000000FF (Blue), 0x0000FF00 (Green) and 0x00FF0000 (Red).
:::N.B. The high byte (0xFF000000) is unused, but the convention is to always set it to 0x00.
:9 - S3TC/DXT1, RGB565 compressed 4 times ([https://wikis.khronos.org/opengl/S3_Texture_Compression GL_COMPRESSED_RGB_S3TC_DXT1_EXT] OpenGL texture format)
:10 (never used in vanilla TXMPs) - RGB_Bytes, 24 bits/pixel, stored as 3 consecutive bytes: first Red, then Green, then Blue.
::N.B. Unlike for RGB888 (type 8), the storage is compact, with no unused alpha bit.
:11 (never used in vanilla TXMPs<ref>Storage format 11 (RGBA_Bytes) was effectively implemented by OniSplit to allow for 32-bit textures with transparency - most importantly experimental lightmaps, see [[Lightmapping levels|HERE]]. However, it was mislabeled as type 7 (ARGB8888) by OniSplit, Daodan DLL and the Intel Mac build, which resulted in byte swapping and the requirement of authoring Windows and Mac versions of TXMPs.</ref>) - RGBA_Bytes, 32 bits/pixel, stored as 4 consecutive bytes: first Red, then Green, then Blue, then Alpha.
:12 (never used in vanilla TXMPs) - RGBA5551, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels with bitmasks 0x003E (Blue), 0x07C0 (Green) and 0xF800 (Red), 1-bit alpha (0x0001).
:13 (never used in vanilla TXMPs) - RGBA4444, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Four 4-bit channels, with bitmasks 0x00F0 (Blue), 0x0F00 (Green), 0xF000 (Red) and 0x000F (Alpha).
:14 (never used in vanilla TXMPs) - RGB565, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Two 5-bit channels with bitmasks 0x001F (Blue) and 0xF800 (Red), 6-bit Green channel (0x07E0).
:15 (never used in vanilla TXMPs) - ABGR1555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels with bitmasks 0x001F (Red), 0x03E0 (Green) and 0x7C00 (Blue), 1-bit alpha (0x8000).
}}
{{OBDtr| 0x94 | link |FFC8FF| 00 00 00 00 | unused | link to a [[OBD:TXAN|TXAN]] file; used if this texture is animated }}
{{OBDtr| 0x98 | link |FFC800| 00 00 00 00 | unused | link to a TXMP file that contain the environment map }}
{{OBDtr| 0x9C | offset |C800C8| 20 00 00 00 |00 00 00 20| offset of pixel data in the raw file (v1.0 engine only) }}
{{OBDtr| 0xA0 | offset |C87C64| 00 00 00 00 | unused | offset of pixel data in the separate file (v1.1 engine only) }}
{{OBDtr| 0xA4 | char[12] |B0C3D4| AD DE | dead | The layout of these 12 bytes is different for the v1.0 and v1.1 versions (i.e. Windows retail vs. Windows demo and Mac):
*For a v1.1 TXMP, the four bytes at 0xA4-A7 are "00 00 00 00" instead of "AD DE AD DE", and correspond to a "material type" attributed at runtime (from [[TMBD]]), which is then used for impact/breakability lookup. The Windows retail TXMPs apparently have no such "material type" field.
*The fields at 0xA8-AF (for v1.1) or 0xA4-AB (for v1.0) are used only at runtime (and somehow obfuscated by "0xDEAD" when written to disk). Judging by the Windows demo and Mac engine, we can assume they are the same in both engines, and serve for rendering optimization (there is a texture name pointer, a "dirty" flag stored as a byte and 3 extra bytes used as flags).
*For Windows retail, the four bytes at 0xAC-AF are completely unused (not part of the template).
Since runtime fields are grouped at the end, v1.0 and v1.1 TXMPs are treated by OniSplit under the same template, merely switching between the .raw and .sep links and blanking out everything past 0xA4.
}}
{{OBDtr| 0xB0 | char[16] |B0C3D4| AD DE | dead | padding bytes (not part of TXMP) }}
|}

===Effect options===
The "blue shield", "invisibility" and "Daodan shield" options tell the engine to vary the texture's Gouraud shading with certain preset colors that vary with time.

{| class="wikitable"
!Flag name
!Texture with flag
!Used for
|-
|"blue shield"
|TXMPSHIELD
|force shield
|-
|"invisibility"
|TXMPINVIS
|phase cloak
|-
|"Daodan shield"
|TXMPDAODAN_SHIELD
|red boss shield and [[supershield]]
|}

In the vanilla game data, these flags are only used by the above-named textures. The engine also calls upon these textures by hardcoded name in order to create a character's shield or phase cloak effect.

===Animation time===
When using animated textures the image to display is selected using the game time and animation speed. For textures that are used by particles the local (particle) time can be used either to replace or offset the game time.

===Pixel byte storage order===
As noted above under each format description, the bytes of multibyte texture formats are generally stored "backwards" compared to their names, so if a format is named "RGBA"-something then its bytes will be in ABGR order on disk. This convention was established in the Windows world where PCs were little-endian and loading the bytes AA BB GG RR into a 32-bit int in memory would place them in the correct order, 0xRRGGBBAA. Macintoshes, being big-endian at the time, expected the data to be stored in reverse order and thus Oni would perform a byte swap on most of these types when it loaded them into memory to ensure that they ended up as 0xRRGGBBAA in memory. The sole exceptions to this little-endian storage rule among Oni's supported texture formats are RGB_Bytes and RGBA_Bytes, which actually store their bytes in the stated order, RGB and RGBA respectively. However these formats were never used by any textures in Oni.

===Pixel storage order===
Pixels are stored in row-major order, meaning that all the pixels forming a scanline (image row) are grouped together (stored in left-to right order); the rows are stored in bottom-to-top order (see illustration below). In the case of the DXT1 storage format, the row-major, left-to-right, bottom-to-top order applies to the 4x4 blocks composing the image, and also inside each 4x4 block for the storage of 2-bit pixels. In the case of the I1 format (several pixels per byte), the row-major, left-to-right, bottom-to-top order applies to the 1-bit pixels composing the image.
{|border=0
|+Pixel arrangement
!how it's stored
! 
!how you'll see it
|-
|[[Image:txmp_ex1.gif]]
| 
|[[Image:txmp_ex2.gif]]
|}

==PS2 implementation==
The PS2 TXMP layout is similar to PC, with notable differences in the last few bytes due to Rockstar moving to a PS2-standard 32-bit indexed color ("CLUT") system for optimization purposes. Here are the high-level differences:
*There are 4 extra bytes of storage as compared to a v1.1 TXMP (which is already 4 bytes larger than a v1.0 TXMP).
*The extra 4 bytes come from a palette index (int32) inserted at 0x90 before the pixel format (which is pushed down to 0x94 along with everything else that follows).
*Two new pixel formats were added, and are the only formats used on PS2: type 16 for opaque textures (indexed 32-bit RGB with ignored alpha byte), and type 17 for transparent textures (indexed 32-bit RGBA).
*The pixel data (color indices) can be stored either in the .raw file (pointer field at 0xA0) or in the .sep file (pointer at 0xA4).

Here is how the end of TXMPrl_1 looks in level3_Final.dat of the English retail PS2 version.
{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x90 | int32 |C8FFC8| 56 00 00 00 | 86 | index of the 256-color palette used by this texture (starts at 0x15800 in level3_palette.pal) }}
{{OBDtr| 0x94 | int32 |C8FFFF| 10 00 00 00 | 16 | pixel format 16 (indexed 32-bit RGB with inactive alpha) }}
{{OBDtr| 0x98 | link |FFC8FF| 00 00 00 00 | 0 | link to a [[OBD:TXAN|TXAN]] file; used if this texture is animated }}
{{OBDtr| 0x9C | link |FFC800| 00 00 00 00 | 0 | link to a TXMP file that contains the environment map }}
{{OBDtr| 0xA0 | offset |C800C8| C0 05 00 00 |00 00 05 C0| offset of pixel data in the .raw file }}
{{OBDtr| 0xA4 | offset |C87C64| 00 00 00 00 | 0 | offset of pixel data in the .sep file }}
{{OBDtr| 0xA8 | int32 |B0C3D4| 00 00 00 00 | 0 | always 0; presumably the same "material type" (set at runtime) as for Windows demo and Mac }}
{{OBDtr| 0xAC | char[4] |B0C3D4| AD DE AD DE | dead | presumably the same texture name pointer (set at runtime) as for Windows demo and Mac }}
{{OBDtr| 0xB0 | char[4] |B0C3D4| AD DE AD DE | dead | presumably the same rendering optimization flags (runtime) as for Windows demo and Mac }}
{{OBDtr| 0xB4 | char[12] |B0C3D4| AD DE | dead | completely unused bytes (not part of the template) }}
|}

===Palette file format===
*Palettes are stored per-level in level#_palette.pal files in a pal/ subdirectory of GameDataFolder, corresponding to how .raw and .sep files are stored in raw/ and sep/ subdirectories.
*Each level#_palette.pal file contains between 85 and 179 palettes, not counting the first palette (index 0) at the start of each .pal file which is always blank.

===Palette format===
*Valid palette indices start at 1 because of palette 0 always being empty.
*Each color in a palette entry is 4 bytes, stored on disk in RGBA order (byte 0 = red, byte 1 = green, byte 2 = blue, byte 3 = alpha). This is the same layout as RGB_Bytes (type 10) and RGBA_Bytes (type 11), not the reversed BGRA order used by most of the other texture formats.
*Each palette consists of 256 32-bit color slots and thus takes up 1024 bytes. If a palette does not use all 256 entries then the palette is closed out with a series of {0x00, 0x00, 0x00, 0x80} entries.
*Each pixel in the .raw or .sep data is stored as a 1-byte index into the image's chosen color palette.

===Palette CLUT swizzle===
:The PS2 Graphics Synthesizer (GS) stores CLUT entries in a scrambled order due to its hardware cache line layout. Within every 32-entry block of the palette, entries 8–15 and 16–23 are swapped relative to their logical positions. Software reading the palette must undo this before using it as a palette index.

===Ignored alpha byte for type 16===
:The fourth byte would represent alpha, but in RGB888 it is merely a padding byte, always set to 0x80.

===Alpha scaling for type 17===
:The PS2 GS uses a half-range alpha where 0x00 = fully transparent and 0x80 = fully opaque (values above 0x80 are technically possible but indicate "source alpha contribution > 1" in GS blending, which doesn't arise in Oni).

===Alternating use of .raw or .sep storage===
Unlike the Win/Mac game data (where pixel data is stored exclusively in .raw or exclusively in .sep for all TXMPs), PS2 TXMPs use .raw and .sep storage alternatingly, depending on the TXMP. The engine apparently uses the .sep pointer if there is no .raw pointer (or vice versa).

Examples of textures using .sep storage are: all [[:Category:Fly-in_portraits|fly-in portraits]]; all [[:Category:Splashscreens|splashscreen]] components; some illustrations in Konoko's [[Data Comlink]] (namely, [[:File:TXMPLevel02move.png|combat move illustrations]] and [[:File:TXMPhypo.png|item illustrations]]; objectives and weapon illustrations use .raw storage).

Environment/character/particle TXMPs seem to be using .raw storage consistently (not checked beyond level1_Final). As a notable anomaly, .sep storage is used for the following three textures (console screens) in level0_Final: _CON_SAVEGAME (main TXMP only; the animation frames use .raw storage), _CON_SAVEGAME_USED, _CON_USED.

==Oni's internal storage types==
Some of Oni's 18 types of image storage are elaborated on below in order to illustrate exactly how they work. The "Mem view" column shows the bytes in big-endian format and the "Disk view" column shows the bytes as they are actually stored in little-endian order. For example, bytes in memory shown as 0xFC00 are stored as "00 FC" on disk.

===ARGB4444 (type 0)===
*A 16-bit field is used to store 4 color channels (4 bits each, values from 0 to 15).
*Bit masks are 0x000F for Blue, 0x00F0 for Green, 0x0F00 for Red, 0xF000 for Alpha.
*Stored as big-endian in TXMP (first the AAAARRRR byte, then the GGGGBBBB byte).
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 1 (high) <code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>A A A A R R R R</code>||<code>G G G G B B B B</code>
|-
!colspan=3| Bit values for primary colors (fully opaque)
!Mem view
!Disk view
|-
|Black||<code>1 1 1 1 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!F0 00!!00 F0
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF!!FF FF
|-
|Red||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!FF 00!!00 FF
|-
|Green||<code>1 1 1 1 0 0 0 0</code>||<code>1 1 1 1 0 0 0 0</code>
!F0 F0!!F0 F0
|-
|Blue||<code>1 1 1 1 0 0 0 0</code>||<code>0 0 0 0 1 1 1 1</code>
!F0 0F!!0F F0
|-
|Cyan||<code>1 1 1 1 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!F0 FF!!FF F0
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 1 1 1 1</code>
!FF 0F!!0F FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 0 0 0 0</code>
!FF F0!!F0 FF
|}

===RGB555 (type 1)===
*A 16-bit field is used to store 3 color channels (5 bits each, values from 0 to 31).
*Bit masks are 0x001F for Blue, 0x03E0 for Green, 0x7C00 for Red.
*The high bit (0x8000) is unused, but is always set to 1 by convention.
*Stored in little-endian order in TXMP.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 1 (high) <code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>X R R R R R G G</code>||<code>G G G B B B B B</code>
|-
!colspan=3| Bit values for primary colors
!Mem view
!Disk view
|-
|Black||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!80 00!!00 80
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF!!FF FF
|-
|Red||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FC 00!!00 FC
|-
|Green||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!83 E0!!E0 83
|-
|Blue||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!80 1F!!1F 80
|-
|Cyan||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!83 FF!!FF 83
|-
|Magenta||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!FC 1F!!1F FC
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!FF E0!!E0 FF
|}

===ARGB1555 (type 2)===
*A 16-bit field is used to store 3 color channels (5 bits each, values from 0 to 31) and one 1-bit channel.
*Bit masks are 0x001F for Blue, 0x03E0 for Green, 0x7C00 for Red, and 0x8000 for Alpha.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 1 (high) <code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>A R R R R R G G</code>||<code>G G G B B B B B</code>
|-
!colspan=3| Bit values for primary colors (opaque)
!Mem view
!Disk view
|-
|Black||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!80 00!!00 80
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF!!FF FF
|-
|Red||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FC 00!!00 FC
|-
|Green||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!83 E0!!E0 83
|-
|Blue||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!80 1F!!1F 80
|-
|Cyan||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!83 FF!!FF 83
|-
|Magenta||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!FC 1F!!1F FC
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!FF E0!!E0 FF
|}

===A4I4 (type 6)===
*An 8-bit field is used to store an intensity and an alpha (4 bits each, values from 0 to 15).
*Bit masks are 0x0F for Intensity, 0xF0 for Alpha.
*Endianness is irrelevant for single-byte storage.
{|border=1 cellpadding=3 cellspacing=0
!Bits
!<code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>A A A A I I I I</code>
|-
!colspan=2|Examples of bit values
!Mem view
|-
|Black, opaque||<code>1 1 1 1 0 0 0 0</code>
!F0
|-
|White, opaque||<code>1 1 1 1 1 1 1 1</code>
!FF
|-
|Black, transparent||<code>0 0 0 0 0 0 0 0</code>
!00
|-
|White, transparent||<code>0 0 0 0 1 1 1 1</code>
!0F
|}

===ARGB8888 (type 7)===
*A 32-bit field is used to store 4 color channels (8 bits each, values from 0 to 255).
*Bit masks are 0x000000FF for Blue, 0x0000FF00 for Green, 0x00FF0000 for Red, 0xFF000000 for Alpha.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 3 (highest) <code>7 6 5 4 3 2 1 0</code>
!Byte 2 (higher) <code>7 6 5 4 3 2 1 0</code>
!Byte 1 (high) <code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>A A A A A A A A</code>||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>
|-
!colspan=5| Bit values for primary colors (fully opaque)
!Mem view
!Disk view
|-
|Black||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FF 00 00 00!!00 00 00 FF
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF FF FF!!FF FF FF FF
|-
|Red||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FF FF 00 00!!00 00 FF FF
|-
|Green||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!FF 00 FF 00!!00 FF 00 FF
|-
|Blue||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 00 FF!!FF 00 00 FF
|-
|Cyan||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 FF FF!!FF FF 00 FF
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF 00 FF!!FF 00 FF FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!FF FF FF 00!!00 FF FF FF
|}

===RGB888 (type 8)===
*A 32-bit field is used to store 3 color channels (8 bits each, values from 0 to 255).
*Bit masks are 0x000000FF for Blue, 0x0000FF00 for Green, 0x00FF0000 for Red.
*The high byte (0xFF000000) is unused, but is always set to 00 by convention.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 3 (highest) <code>7 6 5 4 3 2 1 0</code>
!Byte 2 (higher) <code>7 6 5 4 3 2 1 0</code>
!Byte 1 (high) <code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>X X X X X X X X</code>||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>
|-
!colspan=5| Bit values for primary colors
!Mem view
!Disk view
|-
|Black||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!00 00 00 00!!00 00 00 00
|-
|White||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF FF FF!!FF FF FF 00
|-
|Red||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!00 FF 00 00!!00 00 FF 00
|-
|Green||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!00 00 FF 00!!00 FF 00 00
|-
|Blue||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 00 FF!!FF 00 00 00
|-
|Cyan||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 FF FF!!FF FF 00 00
|-
|Magenta||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF 00 FF!!FF 00 FF 00
|-
|Yellow||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!00 FF FF 00!!00 FF FF 00
|}

===RGB_Bytes (type 10)===
*Three consecutive 8-bit fields are used to store 3 color channels (8 bits each, values from 0 to 255).
*Each channel has its own byte, and there is no "unused" byte (the bytes are packed 3 by 3).
*Endianness is irrelevant when storing as a sequence of bytes.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 0 (red) <code>7 6 5 4 3 2 1 0</code>
!Byte 1 (green) <code>7 6 5 4 3 2 1 0</code>
!Byte 2 (blue) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>
|-
!colspan=4|Bit values for primary colors
!Mem view
|-
|Black||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!00 00 00
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF FF
|-
|Red||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FF 00 00
|-
|Green||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!00 FF 00
|-
|Blue||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 FF
|-
|Cyan||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF FF
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!FF FF 00
|}

===RGBA_Bytes (type 11)===
*Four consecutive 8-bit fields are used to store 4 color channels (8 bits each, values from 0 to 255).
*Each channel has its own byte. Endianness is irrelevant when storing as a sequence of bytes.
{|border=1 cellpadding=3 cellspacing=0
! Bits
!Byte 0 (red) <code>7 6 5 4 3 2 1 0</code>
!Byte 1 (green) <code>7 6 5 4 3 2 1 0</code>
!Byte 2 (blue) <code>7 6 5 4 3 2 1 0</code>
!Byte 3 (alpha) <code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>||<code>A A A A A A A A</code>
|-
!colspan=5| Bit values for primary colors (fully opaque)
!Mem view
|-
|Black||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 00 FF
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF FF FF
|-
|Red||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 00 FF
|-
|Green||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF 00 FF
|-
|Blue||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 FF FF
|-
|Cyan||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF FF FF
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 FF FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF 00 FF
|}

==Notes==
<references/>

{{OBD_File_Footer | type=TXMP | prev=TXMB | next=TxtC | name=Texture Map | family=General}}

{{OBD}}