OniGalore - User contributions [en]

User talk:Iritscen

2014-03-27T23:02:10Z

Ssg: /* Trigger volumes */

__TOC__
'''Talk page archives''': [[/Archive1|#1]]

==Trigger volumes==
As the community achieved a lot in the past years, I wonder if it's now possible to show the trigger volumes in Oni. Is it? [[User:Ssg|Ssg]] ([[User talk:Ssg|talk]]) 23:32, 27 March 2014 (CET)
:Yes; in fact it's funny you should ask, because this ability was just added in Windows by the [[Daodan DLL]] within the last couple weeks: http://oni.bungie.org/community/forum/viewtopic.php?pid=48117#p48117. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 23:39, 27 March 2014 (CET)
::Wow, that's what I call 'right on time'. Thanks for the link. [[User:Ssg|Ssg]] ([[User talk:Ssg|talk]]) 00:02, 28 March 2014 (CET)

==Pre-beta image==
Hello,

This pre-beta image really seems bio lab to me. Didn't you agree?

[[Image:Pre-beta Vago Lab.png]]

See you. [[User:Script 10k|Script 10k]]

:Ah, you're right, that must be the pre-beta night-time version of the Lab! I've re-named it and moved it to the proper place on the page. Thanks. --[[User:Iritscen|Iritscen]] 01:31, 23 November 2009 (UTC)

==AI self-healing==
;Hi Iritscen,
:it has been a long time since I have contributed something. I don't have time (and Oni) right now, but I ask you to try this idea out. It is connected to AI2 driven characters being able to actually use hypo sprays they possess to heal themselves (like the human player).
:It could be easy as it involves only usage of BSL. However, I don't know if several things (mainly "''chr_holdkey''" command, which is core of this idea) work the way I think they work.
:'''Requirements for the experiment:'''
::- take one AI2 character whose name you know from some level you like. But this AI should be near some savepoint for easy debugging.
::- add function to the scripts of your selected level, which will be forked from your selected savepoint, where your AI2 spawns.
::- this function will contain following commands:
:::"''ai2_showhealth=1''" - I think this is clear
:::"''ai2_spawn'' name" - clear
:::"''ai2_ignore_player''=1" - to be able to experiment
:::"''chr_inv_reset'' name" - to make sure we have everything under control
:::"''chr_givepowerup'' name hypo" - now we know our AI2 char has one hypo
:::"''chr_set_health'' name 1" - to make it logical to use a hypo ^_^
:::"''chr_wait_animtype'' 0 crouch" - to be able to trigger it when you want
:::"''chr_holdkey'' name keys_hypo 10" - THIS IS IT. Key part, if I understand that command right
::- now run the selected savepoint of selected level, don't crouch, get to your AI2, which is active but ignores you as a player and has only one HP left. NOW crouch. If everything goes according to the theory, this AI2 will use its one hypo to heal itself. Obviously should be seen with "''ai2_showhealth''=1".
:- if it works, please let us (community) know. This way, we can set up smarter behavior for AI2s, where AI2s heal themselves in battle. Well, they try at least, because if they get hit, healing effect is reduced, as we know. And we cannot command AI2 to "play defensively because it used a hypo and healing is in the process". At least not the BSL way.
:- also, this could be used for some daodanized AI2 characters, where AI2s inject hypos to get into regular overpower mode.
:- I am aware of the fact that we can use "''chr_set_health''" command to do the same work. However, "''chr_set_health''" is dependent on the value it has written in, so you have to set up some mechanisms to reduce the value in "''chr_set_health''" command as AI2s health drops if we want to use it as an hypo emulation. Plus it is tied with only one AI2 character then.
:- hypo usage emulation via "''chr_holdkey''" (if it will work) is on the other hand simply used to force '''any''' AI2 char (just input its name and be sure this char has a hypo in its inventory) to take a hypo and rest is handled by engine. Simple and effective.
:--[[User:Loser|Loser]] 00:12, 17 March 2009 (UTC)

Loser, I have tried to get chr_holdkey to work for some time now. Peering at the asm, I can see that there is code there for it, but it might have been commented out in some form. It is really hard to tell. ALSO, using a hypo doesn't seem to be one of the allowable keys. They seem to be: forward, back, stepleft, stepright, crouch, jump, fire, altfire, punch, kick, action. HOWEVER, there is a different method we can use for AIs using hypos. Record Konoko using a hypo, export\import it using Onisplit, then use the from_here option in chr_playback. I would recommend using Konoko's watch animation or something of the sort to go along as a visual cue. [[User:Gumby|Gumby]]

Thank you for report, Gumby. Yes, I know about playback solution, that way of solving this problem works quite fine. Point of this BSL idea was that it requires only scripting, no files changed.
: But if we have to end up with changing files, then we can modify CHAR as well, adding trigger of the function *heal_mechanicsXX.name_of_ai2_written_here* into CHAR when character is hurt. XX represents number of the healing group. If I recall correctly, engine takes "''name_of_ai2_written_here''" as string parameter of the function *heal_mechanics*.

: About that XX - enemies have various health levels, but we can see some of them have quite similar max health levels (+/- 25 HP). So my idea is - we have groups of CHARacters, which share same version of heal_mechanicsXX function, labeled by its number (saves space). These CHARacters have similar max health levels and have exactly the same amount of hypos they can use.
:Then one very simple function for such a group can look like this:
::'''func''' '''void''' heal_mechanics01(string ''ai_name'')
::{
:: '''chr_wait_health''' (''ai_name'', value_of_approximate_half_of_max_HP_for_this_group_members)
:: '''chr_playback_block''' (''ai_name'', name_of_hypo_trigger_[[FILM]]_file, fromhere)
::}

:This function would be triggered by members of heal_mechanics01 (they have writen it in their CHAR file, under "hurt" trigger). When called, it takes name of the CHAR as a parameter and then waits until this CHAR's HP drops around 1/2 (value is set maually in the script). Then it calles hypo using FILM for this CHAR.
: Nice, isn't it? --[[User:Loser|Loser]] 18:29, 17 March 2009 (UTC)
::Yeah, thats about what I meant. :) Either method requires changing files though, because AFAIK AI aren't given hypos in the CHAR. [[User:Gumby|Gumby]] 08:24, 18 March 2009 (UTC)

Hey. When Gumby is on it, there's another worthy thing to try. Duplicating chr_poison (ai_name, damage, interval, initial_interval) and replacing the health reducing function by a health adding function. Then that could be used instead of chr_playback_block. It would not only simulate "AI Hypos" but better AI and player regeneration than chr_set_health. Smooth health increment (for player) can be done in a looped BSL function. 20:35, 17 March 2009 (UTC)

:Done that already, in ReOni. The problem lies in the fact that there isn't an easy way AFAIK to copy a function using the Daodan. The other problem is that Macs would be left out cold. [[User:Gumby|Gumby]] 08:24, 18 March 2009 (UTC)

::Hm, do I actually even need to say anything? The conversation is going well without me ^_^ I find your idea interesting, Loser, but I personally just can't focus on it at this point, or I won't be able to help Gumby with the Edition (Real Life is knocking hard on my door right now and demanding me to cut down on my Oni time). Besides, any topic beyond BSL is kinda over my head anyway :-) --[[User:Iritscen|Iritscen]] 14:35, 18 March 2009 (UTC)

:::Ran into a small problem, the character still rotates, even with "fromhere". :( [[User:Gumby|Gumby]] 19:07, 18 March 2009 (UTC)

==Newbies==
Oi who are all those never editing newbees? Are you sure they are human? --[[User:Paradox-01|Paradox-01]]

==About operators==
You said '=' is an alternate form of 'eq'. Are you sure? I was considering '=' to be used for definition and 'eq' for comparison.
[[User:Lukas Kreator|Lukas Kreator]] ([[User talk:Lukas Kreator|talk]]) 16:34, 11 November 2012 (CET)
:My bad, you're correct. '=' is the assignment operator. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 19:49, 11 November 2012 (CET)

==slowmo==
"no idea why I wrote that about slowmo"

EdT told me when making the Old China level that it was different in mac and pc. If you check the scripts you will notice that the parameter values are different for each version. Not sure how it works on mac since I don't own one. [[User:Script 10k|Script 10k]] ([[User talk:Script 10k|talk]]) 17:32, 28 April 2013 (CEST)

:Yes, I see now, that was why I wrote that. I guess I have to ask EdT about that. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 17:37, 28 April 2013 (CEST)

::The answer, I don't know. I believe that normally, slowmo works the same for both PC and Mac. However, in the old China Mod, there was a big difference. For the PC slowmo(100) lasted less than 2 seconds, on the Mac is was more like 15-20 seconds and during that time you couldn't do anything. So we changed it to slowmo(30) for the Mac, but it could simply have been my computer not able to handle all the action of the final battle. :) [[User:EdT|EdT]] ([[User talk:EdT|talk]]) 00:36, 8 May 2013 (CEST)

:::Hmm, okay. Well, I guess we'll just have to keep an eye out for a possible difference in the future (maybe it's really just tied to computer performance, as you indicated), but it probably won't crop up often since slowmo isn't used much. Thanks for the response. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 00:43, 8 May 2013 (CEST)

User talk:Iritscen

2014-03-27T22:32:47Z

Ssg: Trigger volumes visible in Oni?

__TOC__
'''Talk page archives''': [[/Archive1|#1]]

==Trigger volumes==
As the community achieved a lot in the past years, I wonder if it's now possible to show the trigger volumes in Oni. Is it? [[User:Ssg|Ssg]] ([[User talk:Ssg|talk]]) 23:32, 27 March 2014 (CET)

==Pre-beta image==
Hello,

This pre-beta image really seems bio lab to me. Didn't you agree?

[[Image:Pre-beta Vago Lab.png]]

See you. [[User:Script 10k|Script 10k]]

:Ah, you're right, that must be the pre-beta night-time version of the Lab! I've re-named it and moved it to the proper place on the page. Thanks. --[[User:Iritscen|Iritscen]] 01:31, 23 November 2009 (UTC)

==AI self-healing==
;Hi Iritscen,
:it has been a long time since I have contributed something. I don't have time (and Oni) right now, but I ask you to try this idea out. It is connected to AI2 driven characters being able to actually use hypo sprays they possess to heal themselves (like the human player).
:It could be easy as it involves only usage of BSL. However, I don't know if several things (mainly "''chr_holdkey''" command, which is core of this idea) work the way I think they work.
:'''Requirements for the experiment:'''
::- take one AI2 character whose name you know from some level you like. But this AI should be near some savepoint for easy debugging.
::- add function to the scripts of your selected level, which will be forked from your selected savepoint, where your AI2 spawns.
::- this function will contain following commands:
:::"''ai2_showhealth=1''" - I think this is clear
:::"''ai2_spawn'' name" - clear
:::"''ai2_ignore_player''=1" - to be able to experiment
:::"''chr_inv_reset'' name" - to make sure we have everything under control
:::"''chr_givepowerup'' name hypo" - now we know our AI2 char has one hypo
:::"''chr_set_health'' name 1" - to make it logical to use a hypo ^_^
:::"''chr_wait_animtype'' 0 crouch" - to be able to trigger it when you want
:::"''chr_holdkey'' name keys_hypo 10" - THIS IS IT. Key part, if I understand that command right
::- now run the selected savepoint of selected level, don't crouch, get to your AI2, which is active but ignores you as a player and has only one HP left. NOW crouch. If everything goes according to the theory, this AI2 will use its one hypo to heal itself. Obviously should be seen with "''ai2_showhealth''=1".
:- if it works, please let us (community) know. This way, we can set up smarter behavior for AI2s, where AI2s heal themselves in battle. Well, they try at least, because if they get hit, healing effect is reduced, as we know. And we cannot command AI2 to "play defensively because it used a hypo and healing is in the process". At least not the BSL way.
:- also, this could be used for some daodanized AI2 characters, where AI2s inject hypos to get into regular overpower mode.
:- I am aware of the fact that we can use "''chr_set_health''" command to do the same work. However, "''chr_set_health''" is dependent on the value it has written in, so you have to set up some mechanisms to reduce the value in "''chr_set_health''" command as AI2s health drops if we want to use it as an hypo emulation. Plus it is tied with only one AI2 character then.
:- hypo usage emulation via "''chr_holdkey''" (if it will work) is on the other hand simply used to force '''any''' AI2 char (just input its name and be sure this char has a hypo in its inventory) to take a hypo and rest is handled by engine. Simple and effective.
:--[[User:Loser|Loser]] 00:12, 17 March 2009 (UTC)

Loser, I have tried to get chr_holdkey to work for some time now. Peering at the asm, I can see that there is code there for it, but it might have been commented out in some form. It is really hard to tell. ALSO, using a hypo doesn't seem to be one of the allowable keys. They seem to be: forward, back, stepleft, stepright, crouch, jump, fire, altfire, punch, kick, action. HOWEVER, there is a different method we can use for AIs using hypos. Record Konoko using a hypo, export\import it using Onisplit, then use the from_here option in chr_playback. I would recommend using Konoko's watch animation or something of the sort to go along as a visual cue. [[User:Gumby|Gumby]]

Thank you for report, Gumby. Yes, I know about playback solution, that way of solving this problem works quite fine. Point of this BSL idea was that it requires only scripting, no files changed.
: But if we have to end up with changing files, then we can modify CHAR as well, adding trigger of the function *heal_mechanicsXX.name_of_ai2_written_here* into CHAR when character is hurt. XX represents number of the healing group. If I recall correctly, engine takes "''name_of_ai2_written_here''" as string parameter of the function *heal_mechanics*.

: About that XX - enemies have various health levels, but we can see some of them have quite similar max health levels (+/- 25 HP). So my idea is - we have groups of CHARacters, which share same version of heal_mechanicsXX function, labeled by its number (saves space). These CHARacters have similar max health levels and have exactly the same amount of hypos they can use.
:Then one very simple function for such a group can look like this:
::'''func''' '''void''' heal_mechanics01(string ''ai_name'')
::{
:: '''chr_wait_health''' (''ai_name'', value_of_approximate_half_of_max_HP_for_this_group_members)
:: '''chr_playback_block''' (''ai_name'', name_of_hypo_trigger_[[FILM]]_file, fromhere)
::}

:This function would be triggered by members of heal_mechanics01 (they have writen it in their CHAR file, under "hurt" trigger). When called, it takes name of the CHAR as a parameter and then waits until this CHAR's HP drops around 1/2 (value is set maually in the script). Then it calles hypo using FILM for this CHAR.
: Nice, isn't it? --[[User:Loser|Loser]] 18:29, 17 March 2009 (UTC)
::Yeah, thats about what I meant. :) Either method requires changing files though, because AFAIK AI aren't given hypos in the CHAR. [[User:Gumby|Gumby]] 08:24, 18 March 2009 (UTC)

Hey. When Gumby is on it, there's another worthy thing to try. Duplicating chr_poison (ai_name, damage, interval, initial_interval) and replacing the health reducing function by a health adding function. Then that could be used instead of chr_playback_block. It would not only simulate "AI Hypos" but better AI and player regeneration than chr_set_health. Smooth health increment (for player) can be done in a looped BSL function. 20:35, 17 March 2009 (UTC)

:Done that already, in ReOni. The problem lies in the fact that there isn't an easy way AFAIK to copy a function using the Daodan. The other problem is that Macs would be left out cold. [[User:Gumby|Gumby]] 08:24, 18 March 2009 (UTC)

::Hm, do I actually even need to say anything? The conversation is going well without me ^_^ I find your idea interesting, Loser, but I personally just can't focus on it at this point, or I won't be able to help Gumby with the Edition (Real Life is knocking hard on my door right now and demanding me to cut down on my Oni time). Besides, any topic beyond BSL is kinda over my head anyway :-) --[[User:Iritscen|Iritscen]] 14:35, 18 March 2009 (UTC)

:::Ran into a small problem, the character still rotates, even with "fromhere". :( [[User:Gumby|Gumby]] 19:07, 18 March 2009 (UTC)

==Newbies==
Oi who are all those never editing newbees? Are you sure they are human? --[[User:Paradox-01|Paradox-01]]

==About operators==
You said '=' is an alternate form of 'eq'. Are you sure? I was considering '=' to be used for definition and 'eq' for comparison.
[[User:Lukas Kreator|Lukas Kreator]] ([[User talk:Lukas Kreator|talk]]) 16:34, 11 November 2012 (CET)
:My bad, you're correct. '=' is the assignment operator. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 19:49, 11 November 2012 (CET)

==slowmo==
"no idea why I wrote that about slowmo"

EdT told me when making the Old China level that it was different in mac and pc. If you check the scripts you will notice that the parameter values are different for each version. Not sure how it works on mac since I don't own one. [[User:Script 10k|Script 10k]] ([[User talk:Script 10k|talk]]) 17:32, 28 April 2013 (CEST)

:Yes, I see now, that was why I wrote that. I guess I have to ask EdT about that. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 17:37, 28 April 2013 (CEST)

::The answer, I don't know. I believe that normally, slowmo works the same for both PC and Mac. However, in the old China Mod, there was a big difference. For the PC slowmo(100) lasted less than 2 seconds, on the Mac is was more like 15-20 seconds and during that time you couldn't do anything. So we changed it to slowmo(30) for the Mac, but it could simply have been my computer not able to handle all the action of the final battle. :) [[User:EdT|EdT]] ([[User talk:EdT|talk]]) 00:36, 8 May 2013 (CEST)

:::Hmm, okay. Well, I guess we'll just have to keep an eye out for a possible difference in the future (maybe it's really just tied to computer performance, as you indicated), but it probably won't crop up often since slowmo isn't used much. Thanks for the response. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 00:43, 8 May 2013 (CEST)

Talk:History of Oni modding

2014-03-27T22:19:21Z

Ssg: Oops, yor're right.

:"Then, in the fall of 2004, Ssg started a site on the newly-opened Oni2.net, a domain run by Alloc, carrying over and translating information that Ssg had originally placed on another site in his native German."

The offline version of the site was created during fall 2004. It first appeared online in January 2005 and was hosted on a German university server. The site itself was completely in English, only some notes for myself were in German.

Starting from the scratch without knowing pretty much about anything: http://ssg.oni2.net/history/oni.htm

[[User:Ssg|Ssg]] ([[User talk:Ssg|talk]]) 02:25, 27 March 2014 (CET)

:Ah, I see, thanks for the correction. I think I assumed it was originally in German because I knew the domain was a German site (and maybe some other reason which I forget now). The date of your oni2.net subdomain's start was also a guess based on when oni2.net opened. So I'll fix that part. Did you move it to Oni2.net soon after putting in on the university site? --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 02:57, 27 March 2014 (CET)
:By the way, let me know if I'm not supposed to capitalize "Ssg". That's how it is on the wiki, but in some places I see "ssg". --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 03:02, 27 March 2014 (CET)

::geyser and I started moving the data to the wiki in December 2005. In April 2008 I moved the site to oni2.net.

::ssg or Ssg: Nobody cares, least of all me. It's just an ID I picked for Oni. Other forums, other IDs.

::Something else: As fas as I know, OniTools was never ported to Windows. There is a program called OniTools.NET, but this has nothing to do with Ian Patterson's OniTools. See images below.

http://ssg.oni2.net/history/onitools_net.png

http://ssg.oni2.net/history/onitools_net_about.png

[[User:Ssg|Ssg]] ([[User talk:Ssg|talk]]) 18:06, 27 March 2014 (CET)

:Oh wow, that's interesting. I forget where I thought I read that the .NET app was a port, but they would have acknowledged on the About page if they were basing it on OniTools, so I guess I was mistaken.
:"In April 2008 I moved the site to oni2.net." Hmm, that late?! Well, [http://web.archive.org/web/20070401000000*/http://ssg.oni2.net the Archive] shows your site on oni2.net as early as Nov. 2007, but I figured that the site must have appeared on oni2.net much earlier, because I thought you moved the data from there to the wiki. You're saying that you moved it from the university domain to the wiki, and much later moved the original site over? Just want to be clear on this. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 22:27, 27 March 2014 (CET)

::Oops, yor're right. My mistake, sorry. I read the wrong row in my e-mail program. The correct date is September 2007. (On Semptember 8th, 2007, Alloc sent me an e-mail with the access data for the ssg.oni2.net account.) And yes, the data was moved from the university domain to the wiki first. 2 years later the site itself moved from the university server to the oni2.net server. (Alloc asked me in 2005 if I'm interested in moving the site to oni2.net, but I declined, because it was easier to update the data on the university server (direct access via the Explorer window, no FTP needed)) [[User:Ssg|Ssg]] ([[User talk:Ssg|talk]]) 23:19, 27 March 2014 (CET)

----

"Later, they produced more original, often epic fight scripts (e.g. OTA); finally, some ambitious modders scripted totally new objectives and mission layouts (e.g., Mariachi Bear's alternate storyline)"

OTA was did much after from the first Mariachi scripts. m_manplant (begin 2004) first ota script is from end 2005. just a note[[User:Script 10k|Script 10k]] 11:54, 4 August 2010 (UTC)

----

Not as much of a pack of lies as it could have been, but still a helluva pack of lies. A good thing this isn't linked to from anywhere but Current events, but I don't know when and if I'll be able to get the story straight. Thanks a lot, I guess -_- --[[User:Geyser|geyser]] 12:43, 13 November 2008 (CET)
:All I've done is basically embellish the first two parts and add the third part. I researched everything as much as I could and spent hours reading old OCF threads. But of course I knew there'd be ''some'' errors. I was considering adding a link to this on the Main page, but I'll hold off for now if you think this page is so dramatically erroneous. --[[User:Iritscen|iritscen]] 16:19, 13 November 2008 (CET)

There is one important thing I just realized is missing (from the original text too): talking about how Loser fixed the AI. That's something that must be addressed in the article. --[[User:Iritscen|iritscen]] 20:48, 13 November 2008 (CET)

----
Since the original namespace "Modding Oni" is being repurposed, here's the original history text that geyser wrote so he can use it as a reference to point out my egregious falsehoods.

=History=
This is a sorta historical overview of Oni modding, that also offers some insight in the basic elements of modding and into the potentials and perspectives.
==Scripting==
[[BSL]] scripts are text-based, human-readable definitions of level logic, and so they were the very first way that Oni was modded by fans. The lack of documentation was somewhat compensated by the possibility to rip the names and descriptions of the [[BSL:keywords|keywords]] and preset [[BSL:variables|variables]] and [[BSL:functions|Functions]] from the engine. Despite the popularity and relative ease of scripting, BSL tutorials and guides have remained virtually non-existent for years, so that scripters are largely self-taught. Also, BSL is perhaps the most bug-ridden piece of Oni's engine. This starts explaining why no "expert scripters" have produced a consistent "course on BSL" yet.

One could point out three popular classes of scripts: original level logic with minor changes (e.g., cloned enemies, as in The Immortality or Titan Mode); "tournaments" (epic encounters one after another and not much of a plot, like "Mountain Rally", "Tournament in Real Time"); totally new objectives and mission layouts (e.g., Mariachi Bear's alternate storyline). Those last ones are typically more elaborate, but fully original scripts are all the more prone to bugs. The first two are easier to set up, but extreme situations tend to overload the engine (as in [[Blam]]!) in ways that the scripters usually don't control.

Generally, scripts tend to suffer from lack of thorough testing and insufficient knowledge of BSL. BSL's variables and functions allow for some creative scripting (Oni Menu, [[OTA]]), but in the absence of binary modding, they are limited to the resources that an original level has to offer, which are intended for the original missions and may not be suited for much else. Then again, people often script "just for fun", with little or no commitment to debugging or support, so the limitations of BSL-only modding are easily overlooked.

For a list of the scripts produced by the community, see "Category:Scripts".

==Binary modding==
Soon enough it became clear (to some of us, at least) that scripts alone would not allow us to design radically new single-player missions. Entities like [[OBD:BINA/OBJC/TRGV|trigger volumes]] or [[OBD:BINA/OBJC/CHAR|character descriptions]], for example, were originally designed and fine-tuned in parallel with the scripts. The interplay is such that modders with 100% original ideas typically have to mod the binary resources to adapt them to their scripts. The first one to have consistently done so is [[User:Loser|Loser]], with a massively reshuffled Warehouse. Loser's Warehouse mod included a global component (modified level0_Final), level-specific binary modifications, and highly custom scripts that took full advantage of the modified binaries.

Minor binary modding had already occurred before Loser's Warehouse (thus, while compiling the [[OBD]] database, ssg had released a version of level0_Final in which all of Konoko's combos were unlocked). Still, it was the Warehouse mod which first showed the "full" potential of binary modding. It inspired a short-lived initiative called the [[AE:BIP|Binary Improvement Project]], aimed at providing upgraded binaries for all levels, not just level0_Final and level1_Final. BIP was hindered by large upload/download sizes as well as by the potential legal issues and was promptly put in standby.

An equally short-lived alternative to supplying whole levels was developed in the form of [[OUP]]-based patches and was termed Oni ni Kanabô. The modder would edit his DAT/RAW files in [[OUP]], and then release a single binary resource. This was both bandwidth- and legalese-friendly, but suffered from one major limitation: the indexation of DAT resources and the offsets of RAW data vary a lot across the available versions of Oni. Thus, resources exported with OUP were not truly standalone or portable. Also, OUP still lacked the feature or generating or importing new resources alongside existing ones.

The advent of [[OniSplit]] marked a radical improvement. OniSplit decomposes Oni's data in truly standalone and portable modules, which can be recombined, cloned, or even generated from editable objects like (re)authored textures or meshes. The .oni modules, which only link to each other by name, can be arranged as the modder sees fit and then merged into Oni-ready level files by OniSplit, which handles duplicates, exceptions etc in a rather foolproof way.

Since the .oni files are largely independent of the user's version of Oni, a modder can distribute .oni modules which the user merges into his local installation. However, when the modules correspond to slightly modified original content (and thus fall under IP protection), an alternative is to distribute so-called "deltas": patches that check the integrity of the original module on the user's side and then upgrade it to the same state as intended by the modder.

OniSplit and "delta" patches form the core of the [[Anniversary Edition]], a project scheduled for release in summer 2008.

Talk:History of Oni modding

2014-03-27T17:06:35Z

Ssg:

:"Then, in the fall of 2004, Ssg started a site on the newly-opened Oni2.net, a domain run by Alloc, carrying over and translating information that Ssg had originally placed on another site in his native German."

The offline version of the site was created during fall 2004. It first appeared online in January 2005 and was hosted on a German university server. The site itself was completely in English, only some notes for myself were in German.

Starting from the scratch without knowing pretty much about anything: http://ssg.oni2.net/history/oni.htm

[[User:Ssg|Ssg]] ([[User talk:Ssg|talk]]) 02:25, 27 March 2014 (CET)

:Ah, I see, thanks for the correction. I think I assumed it was originally in German because I knew the domain was a German site (and maybe some other reason which I forget now). The date of your oni2.net subdomain's start was also a guess based on when oni2.net opened. So I'll fix that part. Did you move it to Oni2.net soon after putting in on the university site? --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 02:57, 27 March 2014 (CET)
:By the way, let me know if I'm not supposed to capitalize "Ssg". That's how it is on the wiki, but in some places I see "ssg". --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 03:02, 27 March 2014 (CET)

::geyser and I started moving the data to the wiki in December 2005. In April 2008 I moved the site to oni2.net.

::ssg or Ssg: Nobody cares, least of all me. It's just an ID I picked for Oni. Other forums, other IDs.

::Something else: As fas as I know, OniTools was never ported to Windows. There is a program called OniTools.NET, but this has nothing to do with Ian Patterson's OniTools. See images below.

http://ssg.oni2.net/history/onitools_net.png

http://ssg.oni2.net/history/onitools_net_about.png

[[User:Ssg|Ssg]] ([[User talk:Ssg|talk]]) 18:06, 27 March 2014 (CET)

----

"Later, they produced more original, often epic fight scripts (e.g. OTA); finally, some ambitious modders scripted totally new objectives and mission layouts (e.g., Mariachi Bear's alternate storyline)"

OTA was did much after from the first Mariachi scripts. m_manplant (begin 2004) first ota script is from end 2005. just a note[[User:Script 10k|Script 10k]] 11:54, 4 August 2010 (UTC)

----

Not as much of a pack of lies as it could have been, but still a helluva pack of lies. A good thing this isn't linked to from anywhere but Current events, but I don't know when and if I'll be able to get the story straight. Thanks a lot, I guess -_- --[[User:Geyser|geyser]] 12:43, 13 November 2008 (CET)
:All I've done is basically embellish the first two parts and add the third part. I researched everything as much as I could and spent hours reading old OCF threads. But of course I knew there'd be ''some'' errors. I was considering adding a link to this on the Main page, but I'll hold off for now if you think this page is so dramatically erroneous. --[[User:Iritscen|iritscen]] 16:19, 13 November 2008 (CET)

There is one important thing I just realized is missing (from the original text too): talking about how Loser fixed the AI. That's something that must be addressed in the article. --[[User:Iritscen|iritscen]] 20:48, 13 November 2008 (CET)

----
Since the original namespace "Modding Oni" is being repurposed, here's the original history text that geyser wrote so he can use it as a reference to point out my egregious falsehoods.

=History=
This is a sorta historical overview of Oni modding, that also offers some insight in the basic elements of modding and into the potentials and perspectives.
==Scripting==
[[BSL]] scripts are text-based, human-readable definitions of level logic, and so they were the very first way that Oni was modded by fans. The lack of documentation was somewhat compensated by the possibility to rip the names and descriptions of the [[BSL:keywords|keywords]] and preset [[BSL:variables|variables]] and [[BSL:functions|Functions]] from the engine. Despite the popularity and relative ease of scripting, BSL tutorials and guides have remained virtually non-existent for years, so that scripters are largely self-taught. Also, BSL is perhaps the most bug-ridden piece of Oni's engine. This starts explaining why no "expert scripters" have produced a consistent "course on BSL" yet.

One could point out three popular classes of scripts: original level logic with minor changes (e.g., cloned enemies, as in The Immortality or Titan Mode); "tournaments" (epic encounters one after another and not much of a plot, like "Mountain Rally", "Tournament in Real Time"); totally new objectives and mission layouts (e.g., Mariachi Bear's alternate storyline). Those last ones are typically more elaborate, but fully original scripts are all the more prone to bugs. The first two are easier to set up, but extreme situations tend to overload the engine (as in [[Blam]]!) in ways that the scripters usually don't control.

Generally, scripts tend to suffer from lack of thorough testing and insufficient knowledge of BSL. BSL's variables and functions allow for some creative scripting (Oni Menu, [[OTA]]), but in the absence of binary modding, they are limited to the resources that an original level has to offer, which are intended for the original missions and may not be suited for much else. Then again, people often script "just for fun", with little or no commitment to debugging or support, so the limitations of BSL-only modding are easily overlooked.

For a list of the scripts produced by the community, see "Category:Scripts".

==Binary modding==
Soon enough it became clear (to some of us, at least) that scripts alone would not allow us to design radically new single-player missions. Entities like [[OBD:BINA/OBJC/TRGV|trigger volumes]] or [[OBD:BINA/OBJC/CHAR|character descriptions]], for example, were originally designed and fine-tuned in parallel with the scripts. The interplay is such that modders with 100% original ideas typically have to mod the binary resources to adapt them to their scripts. The first one to have consistently done so is [[User:Loser|Loser]], with a massively reshuffled Warehouse. Loser's Warehouse mod included a global component (modified level0_Final), level-specific binary modifications, and highly custom scripts that took full advantage of the modified binaries.

Minor binary modding had already occurred before Loser's Warehouse (thus, while compiling the [[OBD]] database, ssg had released a version of level0_Final in which all of Konoko's combos were unlocked). Still, it was the Warehouse mod which first showed the "full" potential of binary modding. It inspired a short-lived initiative called the [[AE:BIP|Binary Improvement Project]], aimed at providing upgraded binaries for all levels, not just level0_Final and level1_Final. BIP was hindered by large upload/download sizes as well as by the potential legal issues and was promptly put in standby.

An equally short-lived alternative to supplying whole levels was developed in the form of [[OUP]]-based patches and was termed Oni ni Kanabô. The modder would edit his DAT/RAW files in [[OUP]], and then release a single binary resource. This was both bandwidth- and legalese-friendly, but suffered from one major limitation: the indexation of DAT resources and the offsets of RAW data vary a lot across the available versions of Oni. Thus, resources exported with OUP were not truly standalone or portable. Also, OUP still lacked the feature or generating or importing new resources alongside existing ones.

The advent of [[OniSplit]] marked a radical improvement. OniSplit decomposes Oni's data in truly standalone and portable modules, which can be recombined, cloned, or even generated from editable objects like (re)authored textures or meshes. The .oni modules, which only link to each other by name, can be arranged as the modder sees fit and then merged into Oni-ready level files by OniSplit, which handles duplicates, exceptions etc in a rather foolproof way.

Since the .oni files are largely independent of the user's version of Oni, a modder can distribute .oni modules which the user merges into his local installation. However, when the modules correspond to slightly modified original content (and thus fall under IP protection), an alternative is to distribute so-called "deltas": patches that check the integrity of the original module on the user's side and then upgrade it to the same state as intended by the modder.

OniSplit and "delta" patches form the core of the [[Anniversary Edition]], a project scheduled for release in summer 2008.

Talk:History of Oni modding

2014-03-27T01:25:30Z

Ssg: added some history

<blockquote>Then, in the fall of 2004, Ssg started a site on the newly-opened Oni2.net, a domain run by Alloc, carrying over and translating information that Ssg had originally placed on another site in his native German.</blockquote>

The offline version of the site was created during fall 2004. It first appeared online in January 2005 and was hosted on a German university server. The site itself was completely in English, only some notes for myself were in German.

Starting from the scratch without knowing pretty much about anything: http://ssg.oni2.net/history/oni.htm

[[User:Ssg|Ssg]] ([[User talk:Ssg|talk]]) 02:25, 27 March 2014 (CET)

----

"Later, they produced more original, often epic fight scripts (e.g. OTA); finally, some ambitious modders scripted totally new objectives and mission layouts (e.g., Mariachi Bear's alternate storyline)"

OTA was did much after from the first Mariachi scripts. m_manplant (begin 2004) first ota script is from end 2005. just a note[[User:Script 10k|Script 10k]] 11:54, 4 August 2010 (UTC)

----

Not as much of a pack of lies as it could have been, but still a helluva pack of lies. A good thing this isn't linked to from anywhere but Current events, but I don't know when and if I'll be able to get the story straight. Thanks a lot, I guess -_- --[[User:Geyser|geyser]] 12:43, 13 November 2008 (CET)
:All I've done is basically embellish the first two parts and add the third part. I researched everything as much as I could and spent hours reading old OCF threads. But of course I knew there'd be ''some'' errors. I was considering adding a link to this on the Main page, but I'll hold off for now if you think this page is so dramatically erroneous. --[[User:Iritscen|iritscen]] 16:19, 13 November 2008 (CET)

There is one important thing I just realized is missing (from the original text too): talking about how Loser fixed the AI. That's something that must be addressed in the article. --[[User:Iritscen|iritscen]] 20:48, 13 November 2008 (CET)

----
Since the original namespace "Modding Oni" is being repurposed, here's the original history text that geyser wrote so he can use it as a reference to point out my egregious falsehoods.

=History=
This is a sorta historical overview of Oni modding, that also offers some insight in the basic elements of modding and into the potentials and perspectives.
==Scripting==
[[BSL]] scripts are text-based, human-readable definitions of level logic, and so they were the very first way that Oni was modded by fans. The lack of documentation was somewhat compensated by the possibility to rip the names and descriptions of the [[BSL:keywords|keywords]] and preset [[BSL:variables|variables]] and [[BSL:functions|Functions]] from the engine. Despite the popularity and relative ease of scripting, BSL tutorials and guides have remained virtually non-existent for years, so that scripters are largely self-taught. Also, BSL is perhaps the most bug-ridden piece of Oni's engine. This starts explaining why no "expert scripters" have produced a consistent "course on BSL" yet.

One could point out three popular classes of scripts: original level logic with minor changes (e.g., cloned enemies, as in The Immortality or Titan Mode); "tournaments" (epic encounters one after another and not much of a plot, like "Mountain Rally", "Tournament in Real Time"); totally new objectives and mission layouts (e.g., Mariachi Bear's alternate storyline). Those last ones are typically more elaborate, but fully original scripts are all the more prone to bugs. The first two are easier to set up, but extreme situations tend to overload the engine (as in [[Blam]]!) in ways that the scripters usually don't control.

Generally, scripts tend to suffer from lack of thorough testing and insufficient knowledge of BSL. BSL's variables and functions allow for some creative scripting (Oni Menu, [[OTA]]), but in the absence of binary modding, they are limited to the resources that an original level has to offer, which are intended for the original missions and may not be suited for much else. Then again, people often script "just for fun", with little or no commitment to debugging or support, so the limitations of BSL-only modding are easily overlooked.

For a list of the scripts produced by the community, see "Category:Scripts".

==Binary modding==
Soon enough it became clear (to some of us, at least) that scripts alone would not allow us to design radically new single-player missions. Entities like [[OBD:BINA/OBJC/TRGV|trigger volumes]] or [[OBD:BINA/OBJC/CHAR|character descriptions]], for example, were originally designed and fine-tuned in parallel with the scripts. The interplay is such that modders with 100% original ideas typically have to mod the binary resources to adapt them to their scripts. The first one to have consistently done so is [[User:Loser|Loser]], with a massively reshuffled Warehouse. Loser's Warehouse mod included a global component (modified level0_Final), level-specific binary modifications, and highly custom scripts that took full advantage of the modified binaries.

Minor binary modding had already occurred before Loser's Warehouse (thus, while compiling the [[OBD]] database, ssg had released a version of level0_Final in which all of Konoko's combos were unlocked). Still, it was the Warehouse mod which first showed the "full" potential of binary modding. It inspired a short-lived initiative called the [[AE:BIP|Binary Improvement Project]], aimed at providing upgraded binaries for all levels, not just level0_Final and level1_Final. BIP was hindered by large upload/download sizes as well as by the potential legal issues and was promptly put in standby.

An equally short-lived alternative to supplying whole levels was developed in the form of [[OUP]]-based patches and was termed Oni ni Kanabô. The modder would edit his DAT/RAW files in [[OUP]], and then release a single binary resource. This was both bandwidth- and legalese-friendly, but suffered from one major limitation: the indexation of DAT resources and the offsets of RAW data vary a lot across the available versions of Oni. Thus, resources exported with OUP were not truly standalone or portable. Also, OUP still lacked the feature or generating or importing new resources alongside existing ones.

The advent of [[OniSplit]] marked a radical improvement. OniSplit decomposes Oni's data in truly standalone and portable modules, which can be recombined, cloned, or even generated from editable objects like (re)authored textures or meshes. The .oni modules, which only link to each other by name, can be arranged as the modder sees fit and then merged into Oni-ready level files by OniSplit, which handles duplicates, exceptions etc in a rather foolproof way.

Since the .oni files are largely independent of the user's version of Oni, a modder can distribute .oni modules which the user merges into his local installation. However, when the modules correspond to slightly modified original content (and thus fall under IP protection), an alternative is to distribute so-called "deltas": patches that check the integrity of the original module on the user's side and then upgrade it to the same state as intended by the modder.

OniSplit and "delta" patches form the core of the [[Anniversary Edition]], a project scheduled for release in summer 2008.

OBD:BINA/PAR3

2013-08-11T21:06:09Z

Ssg: fixed broken link

{{OBD BINA Header|prev=ONIE|type=PAR3|next=SABD|name=3D Particle|onistuff=b_3d}}

The following example is the raw/sep part of '''3RAPenv_bomb_e06.BINA''' (level 0). (Another example: http://ssg.oni2.net/oni_b_3e.htm )

Particle dialogs: http://ssg.oni2.net/subfold/bluebox/3d-part.htm

==Header==
The header takes up 780 = 0x30C bytes.

[[Image:bin_r_3h.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FF0000| 33 52 41 50 | PAR3 | signature }}
{{OBDtr| 0x04 | int32 |FFFF00| 9C 06 00 00 | 1692 | length of the following 3d particle part from this position }}
{{OBDtr| 0x08 | int16 |00FF00| 9C 06 | 1692 | length again }}
{{OBDtr| 0x0A | int16 |00FF00| 12 00 | 18 | version }}
{{OBDtr| 0x0C | int32 |00FFFF| 01 20 00 00 | 0x2001 | flags1; used flags (from left to right):
:0x'''01''' 00 00 00 - decorative
:0x'''08''' 00 00 00 - use separate Y scale
:0x'''E0''' 00 00 00 - sprite/contrail mode mask (3 bits, see below for possible values)
:0x00 '''01''' 00 00 - geometry
:0x00 '''02''' 00 00 - collide with walls
:0x00 '''04''' 00 00 - collide with chars
:0x00 '''08''' 00 00 - scale to velocity
:0x00 '''10''' 00 00 - has velocity
:0x00 '''20''' 00 00 - has orientation
:0x00 '''40''' 00 00 - has position offset
:0x00 '''80''' 00 00 - has object attachment matrix
:0x00 00 '''01''' 00 - has unknown; ignored?
:0x00 00 '''02''' 00 - has decal state
:0x00 00 '''04''' 00 - has texture animation random start tick
:0x00 00 '''08''' 00 - has texture animation independent tick
:0x00 00 '''10''' 00 - has damage owner
:0x00 00 '''20''' 00 - has contrail data
:0x00 00 '''40''' 00 - has lensflare fading state
:0x00 00 '''80''' 00 - has attractor
:0x00 00 00 '''01''' - has collision cache
}}
{{OBDtr| 0x10 | int32 |00FFFF| 00 00 00 02 | 0x02000000 | flags2; used flags (from left to right):
:0x'''01''' 00 00 00 - use special tint
:0x'''02''' 00 00 00 - don't attract through walls
:0x'''08''' 00 00 00 - expire on cutscene
:0x'''10''' 00 00 00 - die on cutscene
:0x'''60''' 00 00 00 - disable level mask (2 bits, 0x00 - never disable, 0x40 - disable medium detail, 0x60 - disable low detail)
:0x00 00 '''10''' 00 - draw as sky
:0x00 00 '''20''' 00 - decal full brightness
:0x00 00 '''80''' 00 - decal
:0x00 00 00 '''01''' - initially hidden
:0x00 00 00 '''02''' - invisible
:0x00 00 00 '''04''' - fade out on edge
:0x00 00 00 '''08''' - vector
:0x00 00 00 '''10''' - lock position to link
:0x00 00 00 '''20''' - is contrail emitter
:0x00 00 00 '''40''' - lensflare
:0x00 00 00 '''80''' - one sided edge fade
}}
{{OBDtr| 0x14 | int32 |FF00FF| 00 00 00 00 | 0 | unused\runtine only }}
{{OBDtr| 0x18 | int16 |FF8000| 01 00 | 1 | number of variables }}
{{OBDtr| 0x1a | int16 |FF8000| 01 00 | 1 | number of events/actions }}
{{OBDtr| 0x1c | int16 |FF8000| 01 00 | 1 | number of emitters }}
{{OBDtr| 0x1e | int16 |FF8000| 00 01 | 256 | unknown; always the same }}
|}

Field '''0x14''':
From empiric experiments I raise a thesis this field has meaning "used physics for this particle". It corresponds with Neo's [[OBOA]] researches ( field 0x18 in [[OBOA]] ):
::0 - no pre-fabricated physics, if you want physics for this particle, create it via PAR3's actions ( see down on this site for info about actions. )
::1 - unknown, looks like it disables all physics context ( even the PAR3 action-induced one )
::2 - pre-fabricated physics type 1 - reacts on collisions, ignores gravity.
::3 - unknown, looks like it disables all physics context ( even the PAR3 action-induced one ) - maybe because this is "physics" for [[OBOA]] objects which will have [[OBAN]] animation ?
::4 - pre-fabricated physics type 2 - reacts on collisions, gravity is not ignored.

Judging from this discovery it seems possible that maybe there are more ONI file types which can have this "used physics" field. For example [[DOOR]], unknown field 0x18 ( is 0x 02|00|00|00 -> reacts on collisions, ignores gravity ). Maybe there are more files with this field ? --[[User:Loser|Loser]] 07:32, 16 August 2009 (UTC)
:So just checking: when you set this field, the particles suddenly had collisions\gravity and such? [[User:Gumby|Gumby]] 02:31, 17 August 2009 (UTC)
::Same question as Gumby. For all I know particles do not have "physics", only objects and characters have. As for other uses of this "physics type" thing: highly unlikely. I've said it before and I'll say it again: the physics system in Oni is simplistic. There's nothing that it can do more than it already does. Don't waste your time on it. [[User:Neo|Neo]]

Sprite modes:
:*0 - sprite (face camera, orient to screen)
:*1 - rotated sprite (face camera, orient to particle)
:*2 - beam (parallel, face camera)
:*3 - arrow (parallel, orient to particle)
:*4 - flat (perpendicular)
:*7 - discus (parallel, orient to particle)

Contrail modes:
:*5 - contrail (orient to particle)
:*6 - contrail (face camera)

HasX flags:
:For each HasX flags that is set space will be allocated in the particle to hold the respective value. For example:
:*"has velocity" - allocates space for the velocity vector (3 floats = 12 bytes)
:*"has orientation" - allocates space for a 3x3 matrix (9 floats = 36 bytes)
:*"has object attachment matrix" - allocates space for a pointer to an "object" transform matrix (pointer = 4 bytes)
:*"has damage owner" - allocates space for an int32 that indicates who owns the particle (typically the owner is a character or a turret)
:The creator of a particle is responsable for properly initializing these values.
:In the specific case of particle emitters the newly emitted particle can inherit these values from the emitting particle. A value is inherited if:
:*both the emitting particle and emitted particle have the coresponding HasX flag set
:*the emitter itself doesn't calculate another value (orientation, velocity etc.)

===Event groups===
Here we have 16 4-byte slots, which correspond to the following 16 particle event types :
{|border=1 cellspacing=0
|0:update||1:pulse||2:start||3:stop
|-
|4:bgfx_start||5:bgfx_stop||6:hit_wall||7:hit_char
|-
|8:lifetime||9:explode||A:brokenlink||B:create
|-
|C:die||D:newattractor||E:delay_start||F:delay_stop
|}
The ZZZZ actions in the file (ZZZZ is specified at 0x1A above) are bound to a specific event # by means of this list.

If the 4-byte slot for event # reads XX XX YY YY, where XXXX < YYYY < ZZZZ, then event # will execute all the actions whose slot is greater or equal to XXXX, and less than YYYY.
;Example:3RAPglass_shard.BINA has 10 actions, distributed between events as follows :
:(0,4)(4,4)(4,4)(4,4)(4,4)(4,4)(4,7)(7,9)(9,10)(10,10)(10,10)(10,10)(10,10)(10,10)(10,10)(10,10)
:That means :
:*actions {0,1,2,3} will be triggered by an '''update''' event
:*actions {4,5,6} will be triggered by a '''hit_wall''' event
:*actions {7,8} will be triggered by a '''hit_char''' event
:*action {9} will be triggered by a '''lifetime''' event

{{Table}}
{{OBDth}}
{{OBDtr| 0x20 | int16,int16 |FFC8C8| 00 00 01 00 | 0, 1 | action 0 (actions 0 to 1) triggered by '''update''' event }}
{{OBDtr| 0x24 | int16,int16 |FFC8C8| 01 00 01 00 | 1, 1 | no action (actions 1 to 1) triggered by '''pulse''' event }}
{{OBDtr| 0x28 | int16,int16 |FFC8C8| 01 00 01 00 | 1, 1 | no action (actions 1 to 1) triggered by '''start''' event }}
{{OBDtr| 0x2C | int16,int16 |FFC8C8| 01 00 01 00 | 1, 1 | no action (actions 1 to 1) triggered by '''stop''' event }}
{{OBDtr| 0x30 | int16,int16 |FFC8C8| 01 00 01 00 | 1, 1 | no action (actions 1 to 1) triggered by '''bgfx_start''' event }}
{{OBDtr| 0x34 | int16,int16 |FFC8C8| 01 00 01 00 | 1, 1 | no action (actions 1 to 1) triggered by '''bgfx_stop''' event }}
{{OBDtr| 0x38 | int16,int16 |FFC8C8| 01 00 01 00 | 1, 1 | no action (actions 1 to 1) triggered by '''hit_wall''' event }}
{{OBDtr| 0x3C | int16,int16 |FFC8C8| 01 00 01 00 | 1, 1 | no action (actions 1 to 1) triggered by '''hit_char''' event }}
{{OBDtr| 0x40 | int16,int16 |FFC8C8| 01 00 01 00 | 1, 1 | no action (actions 1 to 1) triggered by '''lifetime''' event }}
{{OBDtr| 0x44 | int16,int16 |FFC8C8| 01 00 01 00 | 1, 1 | no action (actions 1 to 1) triggered by '''explode''' event }}
{{OBDtr| 0x48 | int16,int16 |FFC8C8| 01 00 01 00 | 1, 1 | no action (actions 1 to 1) triggered by '''brokenlink''' event }}
{{OBDtr| 0x4C | int16,int16 |FFC8C8| 01 00 01 00 | 1, 1 | no action (actions 1 to 1) triggered by '''create''' event }}
{{OBDtr| 0x50 | int16,int16 |FFC8C8| 01 00 01 00 | 1, 1 | no action (actions 1 to 1) triggered by '''die''' event }}
{{OBDtr| 0x54 | int16,int16 |FFC8C8| 01 00 01 00 | 1, 1 | no action (actions 1 to 1) triggered by '''newattractor''' event }}
{{OBDtr| 0x58 | int16,int16 |FFC8C8| 01 00 01 00 | 1, 1 | no action (actions 1 to 1) triggered by '''delay_start''' event }}
{{OBDtr| 0x5C | int16,int16 |FFC8C8| 01 00 01 00 | 1, 1 | no action (actions 1 to 1) triggered by '''delay_stop''' event }}
|}

===Particle Properties===
{{Table}}
{{OBDth}}
{{OBDtrBK|float property Lifetime (seconds, 0 <nowiki>=</nowiki> live forever) }}
{{OBDtr| 0x60 | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0x64 | float |C8FFC8| 00 00 40 3F | 0.750000 | value }}
{{OBDtr| 0x68 | |C8FFC8| | | not used for float values }}
{{OBDtrBK|float property Collision radius }}
{{OBDtr| 0x7C | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0x80 | float |C8FFC8| 00 00 00 00 | 0.0 | value }}
{{OBDtr| 0x84 | |C8FFC8| | | not used for float values }}
{{OBDtrBK|Others}}
{{OBDtr| 0x98 | float |FFC800| 00 00 00 00 | 0.000000 | AI dodge radius }}
{{OBDtr| 0x9C | float |FFC800| 00 00 00 00 | 0.000000 | AI alert radius }}
{{OBDtr| 0xA0 | char[16] |FFC800| 00 | "" | flyby sound name }}
|}

===Particle Appearance===
{{Table}}
{{OBDth}}
{{OBDtrBK|float property Scale }}
{{OBDtr| 0xB0 | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0xB4 | float |C8FFC8| 00 00 80 3F | 1.0 | value }}
{{OBDtr| 0xB8 | |C8FFC8| | | not used for float values }}
{{OBDtrBK|float property Y Scale }}
{{OBDtr| 0xCC | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0xD0 | float |C8FFC8| 00 00 80 3F | 1.0 | value }}
{{OBDtr| 0xD4 | |C8FFC8| | | not used for float values }}
{{OBDtrBK|float property Rotation }}
{{OBDtr| 0xE8 | int32 |FFFFC8| 00 00 00 00 | 0 | value type: variable }}
{{OBDtr| 0xEC | char[16] |C8FFC8| | "rotate" | value }}
{{OBDtr| 0xFC | int32 |C8FFFF| 00 00 00 00 | | runtime: storage type }}
{{OBDtr| 0x100 | int32 |FFC8FF| 00 00 00 00 | | runtime: storage offset }}
{{OBDtrBK|float property Alpha }}
{{OBDtr| 0x104 | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0x108 | float |C8FFC8| 00 00 80 3F | 1.0 | value }}
{{OBDtr| 0x10C | |C8FFC8| | | not used for float values }}
{{OBDtrBK|Others}}
{{OBDtr| 0x120 | char[32] |C800C8| | "notfoundtex" | texture name or geometry name }}
{{OBDtrBK|float property X Offset }}
{{OBDtr| 0x140 | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0x144 | float |C8FFC8| 00 00 00 00 | 0.0 | value }}
{{OBDtr| 0x148 | |C8FFC8| | | not used for float values }}
{{OBDtrBK|float property X Shorten }}
{{OBDtr| 0x15C | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0x160 | float |C8FFC8| 00 00 00 00 | 0.0 | value }}
{{OBDtr| 0x164 | |C8FFC8| | | not used for float values }}
{{OBDtrBK|color property Tint }}
{{OBDtr| 0x178 | int32 |FFFFC8| 07 00 00 00 | 7 | value type: color }}
{{OBDtr| 0x17C | float |C8FFC8| FF FF FF FF | white | value }}
{{OBDtr| 0x180 | |C8FFC8| | | not used for color values }}
{{OBDtrBK|float property Edge Fade Min (min value used: 0, max value used: 0.95) }}
{{OBDtr| 0x194 | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0x198 | float |C8FFC8| 00 00 00 00 | 0.0 | value }}
{{OBDtr| 0x19C | |C8FFC8| | | not used for float values }}
{{OBDtrBK|float property Edge Fade Max (min value used: 0, max value used: 1) }}
{{OBDtr| 0x1B0 | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0x1B4 | float |C8FFC8| 00 00 00 3F | 0.5 | value }}
{{OBDtr| 0x1B8 | |C8FFC8| | | not used for float values }}
{{OBDtrBK|float property Max Contrail (min value used: 0, max value used: 100) }}
{{OBDtr| 0x1CC | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0x1D0 | float |C8FFC8| 00 00 00 00 | 0.0 | value }}
{{OBDtr| 0x1D4 | |C8FFC8| | | not used for float values }}
{{OBDtrBK|float property Lens Flare Distance (min value used: 0, max value used: 9000) }}
{{OBDtr| 0x1E8 | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0x1EC | float |C8FFC8| 00 00 00 00 | 0.0 | value }}
{{OBDtr| 0x1F0 | |C8FFC8| | | not used for float values }}
{{OBDtrBK|Others}}
{{OBDtr| 0x204 | int16 |C87C64| 00 00 | 0 | fade in frames }}
{{OBDtr| 0x206 | int16 |C87C64| 00 00 | 0 | fade out frames }}
{{OBDtr| 0x208 | |C87C64| 64 00 | 100 | max decals }}
{{OBDtr| 0x20A | |C87C64| 3C 00 | 60 | decal fade frames }}
{{OBDtrBK|float property Decal Wrap Angle (min value used: 20, max value used: 120) }}
{{OBDtr| 0x20C | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0x210 | float |C8FFC8| 00 00 70 42 | 60.0 | value }}
{{OBDtr| 0x214 | |C8FFC8| | | not used for float values }}
|}

===Particle Attractor===
{{Table}}
{{OBDth}}
{{OBDtr| 0x228 | int32 |B0C3D4| 00 00 00 00 | none | particle attractor type
: 0 - none
: 1 - link
: 2 - class
: 3 - tag
: 4 - characters
: 5 - hostiles
: 6 - emitted towards
: 7 - parent's attractor
: 8 - all characters }}
{{OBDtr| 0x22C | int32 |B0C3D4| 00 00 00 00 | distance | particle attractor selection
: 0 - distance
: 1 - angle }}
{{OBDtr| 0x230 | |B0C3D4| 00 00 00 00 | 0 | runtime only }}
{{OBDtr| 0x234 | char[64] |B0C3D4| 00 | "" | [[OBD:BINA/OBJC/PART|particle]] name (when attractor type is 3) or particle class name (when attractor type is 2) }}
{{OBDtrBK|float property Attractor Max Distance (min value used: 12, max value used: 2000) }}
{{OBDtr| 0x274 | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0x278 | float |C8FFC8| 00 00 16 43 | 150.0 | value }}
{{OBDtr| 0x27C | |C8FFC8| | | not used for float values }}
{{OBDtrBK|float property Attractor Max Angle (min value used: 15, max value used: 180) }}
{{OBDtr| 0x290 | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0x294 | float |C8FFC8| 00 00 F0 41 | 30.0 | value }}
{{OBDtr| 0x298 | |C8FFC8| | | not used for float values }}
{{OBDtrBK|float property Attractor Angle Select Min (min value used: 3, max value used: 180) }}
{{OBDtr| 0x2AC | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0x2B0 | float |C8FFC8| 00 00 40 40 | 3.0 | value }}
{{OBDtr| 0x2B4 | |C8FFC8| | | not used for float values }}
{{OBDtrBK|float property Attractor Angle Select Max (min value used: 20, max value used: 180) }}
{{OBDtr| 0x2C8 | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0x2CC | float |C8FFC8| 00 00 A0 41 | 20.0 | value }}
{{OBDtr| 0x2D0 | |C8FFC8| | | not used for float values }}
{{OBDtrBK|float property Attractor Angle Select Weight (min value used: 1, max value used: 100) }}
{{OBDtr| 0x2E4 | int32 |FFFFC8| 03 00 00 00 | 3 | value type: float }}
{{OBDtr| 0x2E8 | float |C8FFC8| 00 00 40 40 | 3.0 | value }}
{{OBDtr| 0x2EC | |C8FFC8| | | not used for float values }}
{{OBDtrBK|Runtime only}}
{{OBDtr| 0x300 | |E7CEA5| AC 22 81 0B | 0B 81 22 AC | runtime pointer to variables }}
{{OBDtr| 0x304 | |E7CEA5| E0 22 81 0B | 0B 81 22 E0 | runtime pointer to events/actions}}
{{OBDtr| 0x308 | |E7CEA5| 88 24 81 0B | 0B 81 24 88 | runtime pointer to emissions }}
|}

;Value types:
:0 - variable; variable name follows
:1 - none (action parameters use this to indicate an unused parameter)
:3 - float; constant; 1 float value follows
:4 - float; random; 2 float values follow (min, max)
:5 - float; bell curve; 2 float values follow (mean, stddev)
:6 - instance; instance name follows
:7 - color; constant; 1 color follows
:8 - color; random; 2 color follow (min, max)
:9 - color; bell curve; 2 color follow (mean, stddev)
:10 - int32; constant; int32 follows
:11 - time cycle; 2 float values follow (cycle length, scale)
--------

==Variables==
Every variable takes up 52=0x34 bytes. The number of variables is specified at 0x18 in the header.

For each variable space is allocated then a particle is created. Variables can be modified by some actions like "linear change", "random change" etc.

[[Image:bin_r_31.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[16] |C8FFC8| | "rotate" | name of the variable }}
{{OBDtr| 0x10 | int32 |C8FFFF| 02 00 00 00 | 2 | storage type: float }}
{{OBDtr| 0x14 | int32 |FFC8FF| 30 00 00 00 | 48 | runtime: storaget offset (incremented by the storage type size for every next variable) }}
{{OBDtrBK|Initial value }}
{{OBDtr| 0x18 | int32 |FFFFC8| 04 00 00 00 | 4 | value type: random }}
{{OBDtr| 0x1c | float |C8FFC8| 00 00 B4 C3 | -360.000000 | min value }}
{{OBDtr| 0x20 | float |C8FFC8| 00 00 B4 43 | 360.000000 | max value }}
{{OBDtr| 0x24 | |C8FFC8| | | not used for random float }}
{{OBDtr| 0x2c | |C8FFFF| | | not used for random float }}
{{OBDtr| 0x30 | |FFC8FF| | | not used for random float }}
|}

;Storage types used for variables
:0x0002 (0x02 00 00 00) - float (storage size: 4)
:0x0008 (0x08 00 00 00) - color (storage size: 4)
:0x1000 (0x00 10 00 00) - pingpong state (storage size: 4)

;Other storage types

These storage types are never used for variables. They might work but since there are no actions that can output such values it doesn't make much sense to declare variables using these types.

:0x0001 (0x01 00 00 00) - int16 (storage size: 2) (never used)
:0x0004 (0x04 00 00 00) - impact name (storage size: 16)
:0x1010 (0x10 10 00 00) - action index (storage size: 4)
:0x1020 (0x20 10 00 00) - emitter (storage size: 4)
:0x1030 (0x30 10 00 00) - blast falloff (storage size: 4)
:0x1040 (0x40 10 00 00) - coord frame (storage size: 4)
:0x1050 (0x50 10 00 00) - collision orient (storage size: 4)
:0x1060 (0x60 10 00 00) - boolean (storage size: 4)
:0x1070 (0x70 10 00 00) - ambient sound (storage size: 4) (never used)
:0x1080 (0x80 10 00 00) - impulse sound (storage size: 4) (never used)
:0x1090 (0x90 10 00 00) - impact modifier (storage size: 4)
:0x10A0 (0xA0 10 00 00) - damage type (storage size: 4)
:*0 - normal
:*1 - minor stun
:*2 - major stun
:*3 - minor knockdown
:*4 - major knockdown
:*5 - blownup
:*6 - pickup
:0x10B0 (0xB0 10 00 00) - direction (storage size: 4)
:0x2000 (0x00 20 00 00) - ambient sound name (storage size: 16)
:0x4000 (0x00 40 00 00) - impulse sound name (storage size: 16)

-------

==Actions==
Every action takes up 424=0x1A8 bytes. The number of actions is specified at 0x1A in the header.

[[Image:bin_r_32.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | int32 |FFC8C8| 22 00 00 00 | 34 | [[OBD:BINA/PAR3/Actions|Action type]]: Rotate Y }}
{{OBDtr| 0x04 | int32 |FFFFC8| 00 00 00 00 | 0 | unknown }}
{{OBDtrBK|First output paramter (reference to a variable which the action can modify) }}
{{OBDtr| 0x00 | char[16] |C8FFC8| 00 | "" | variable name, if empty this block is not used }}
{{OBDtr| 0x10 | int32 |C8FFFF| 00 00 00 00 | 0 | runtime: storage type }}
{{OBDtr| 0x14 | int32 |FFC8FF| 00 00 00 00 | 0 | runtime: storage offset }}
{{OBDtrBK|First input parameter}}
{{OBDtr| 0x00 | int32 |FFFFC8| 0A 00 00 00 | 10 | value type: int32 }}
{{OBDtr| 0x04 | int32 |C8FFC8| 01 00 00 00 | 1 | value (rotation coordinate space)}}
{{OBDtr| 0x08 | |C8FFC8| | | not used for int32 values }}
{{OBDtr| 0x14 | |C8FFFF| | | not used for int32 values }}
{{OBDtr| 0x18 | |FFC8FF| | | not used for int32 values }}
|}

----

==Emitters==
Every emitter takes up 444=0x1BC bytes. The number of emitters is specified at 0x1C in the header. Each emitter has space for 12 parameters but it appears that the last 2 are never used.

[[Image:bin_r_33.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[64] |FF0000| |"env_bomb_p09" | name of the particle to emit (3RAPenv_bomb_p09.BINA) }}
{{OBDtr| 0x40 | int32 |FFFF00| C0 92 62 00 | | runtime pointer to emitted particle class }}
{{OBDtr| 0x44 | int32 |00FF00| 47 00 00 00 | 0x47 | flags; used values:
:0x'''01''' 00 00 00 - initially on
:0x'''02''' 00 00 00 - increase particle count
:0x'''04''' 00 00 00 - turn off at treshold
:0x'''10''' 00 00 00 - emit with parent velocity
:0x'''20''' 00 00 00 - ignored?
:0x'''40''' 00 00 00 - orient to velocity
:0x'''80''' 00 00 00 - inherit tint
:0x00 '''01''' 00 00 - one per attractor
:0x00 '''02''' 00 00 - at least one
:0x00 '''04''' 00 00 - cycle attractors }}
{{OBDtr| 0x48 | int16 |00FFFF| 04 00 | 4 | turn off treshold }}
{{OBDtr| 0x4A | uint16 |00FFFF| FF FF | 65535 | emit probability (scaled by 65535) }}
{{OBDtr| 0x4C | float |FF00FF| 00 00 20 41 | 10.000000 | amount of (sprite) copies }}
{{OBDtr| 0x50 | int32 |FFC8C8| 00 00 00 00 | 0 | link to:
:0 - nothing
:1 - this particle
:2-9 - to the particle last emitted by emitter 0-7
:10 - this particle's link
}}
{{OBDtr| 0x54 | int32 |FFC8C8| 00 00 00 00 | 0 | emit rate; can use parameters 1 and 2; possible values (in dec):
:0 - continuous (emit interval)
:1 - random (min interval, max interval)
:2 - instant
:3 - distance (distance)
:4 - attractor (recharge time, check interval) }}
{{OBDtr| 0x58 | int32 |FFC8C8| 00 00 00 00 | 0 | position; can use parameters 3, 4 and 5; possible values (in dec):
:0 - point
:1 - line (radius)
:2 - circle (inner radius, outer radius)
:3 - sphere (inner radius, outer radius)
:4 - offset (x, y, z)
:5 - cylinder (height, inner radius, outer radius)
:6 - body-surface (offset radius)
:7 - body-bones (offset radius)}}
{{OBDtr| 0x5C | int32 |FFC8C8| 03 00 00 00 | 3 | direction; can use parameters 6, 7 and 8; possible values (in dec):
:0 - straight
:1 - random
:2 - cone (angle, center bias)
:3 - ring (angle, offset)
:4 - offset (x, y, z)
:5 - inaccurate (base angle, inaccuracy, center bias)
:6 - attractor}}
{{OBDtr| 0x60 | int32 |FFC8C8| 00 00 00 00 | 0 | speed; can use parameters 9 and 10; possible values (in dec):
:0 - uniform (speed)
:1 - stratified (speed 1, speed 2)}}
{{OBDtr| 0x64 | int32 |FFC8C8| 0C 00 00 00 | 12 | orientation dir; possible values (in dec):
:0 - parent +X
:1 - parent -X
:2 - parent +Y
:3 - parent -Y
:4 - parent +Z
:5 - parent -Z
:6 - world +X
:7 - world -X
:8 - world +Y
:9 - world -Y
:10 - world +Z
:11 - world -Z
:12 - velocity
:13 - reverse-velocity
:14 - towards-emitter
:15 - awayfrom-emitter}}
{{OBDtr| 0x68 | int32 |FFC8C8| 04 00 00 00 | 4 | orientation up; same possible values as for orientation dir }}
{{OBDtrBK|First emitter parameter }}
{{OBDtr| 0x00 | int32 |FFFFC8| 04 00 00 00 | 4 | value type: random float }}
{{OBDtr| 0x04 | float |C8FFC8| 00 00 00 3E | 0.125000 | attractor - recharge time min value }}
{{OBDtr| 0x08 | float |C8FFC8| 00 00 00 3F | 0.500000 | attractor - recharge time max value }}
{{OBDtr| 0x0C | |C8FFC8| | | not used for random float values }}
{{OBDtr| 0x14 | |C8FFFF| | | not used for random float values }}
{{OBDtr| 0x18 | |FFC8FF| | | not used for random float values }}
|}

;Direction type Inaccurate vs. Cone
:The Inaccurate type was designed for standard ballistic weapons which will have a cone of fire expanding out from the point of origin, therefore it works identically to the Cone type except with an additional factor, "inaccuracy". The "angle" supplied is now a base angle, which is added to by the inaccuracy setting. The "center bias" for Cone and Inaccurate emitters can be positive to pull the dispersion of particles towards the center of the vector, or negative to push them towards the edges of the cone.
:The inaccuracy setting is only used if the originating character is an AI or turret. The AI's or turret's shooting skill is looked up and multiplied by the difficulty setting's weapon inaccuracy multiplier (see [[ONGS]]), then added to the base angle. With the bias taken into account, and some randomization added by the conical dispersion function, this determines the exact trajectory of the bullet coming from the gun.

----
----
{{OBD BINA Footer|prev=ONIE|type=PAR3|next=SABD|name=3D Particle|onistuff=b_3d}}

{{OBD}}

OBD:BINA/OBJC/PATR

2010-12-06T06:37:18Z

Ssg: movement modes

{{OBD OBJC Header | align=center | type=PATR | prev=PART | next=PWRU | name=Patrol path}}

[[image:bin_r_pp.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x04 | int32 |FFFF00| B4 1F 00 00 | 8116 | size of the complete patrol path part from this postion in bytes }}
{{OBDtr| 0x08 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x0C | int32 |00FFFF| 78 00 00 00 | 120 | size of the following element in bytes }}
{{OBDtrBK}}
{{OBDtr| 0x00 | char[4] |FFC8C8| 52 54 41 50 | PATR | patrol path }}
{{OBDtr| 0x04 | int32 |FFFFC8| 6F 1A 00 00 | 6767 | old file ID }}
{{OBDtr| 0x08 | int32 |C8FFC8| 00 00 00 00 | 0 | unknown }}
{{OBDtr| 0x0C | float |C8FFFF| 08 AB 20 44 | 642.672363 | x-position of the patrol path start point }}
{{OBDtr| 0x10 | float |C8FFFF| E7 26 87 41 | 16.893995 | y-position (height) of the patrol path start point }}
{{OBDtr| 0x14 | float |C8FFFF| 6C CD BD C3 | -379.604858| z-position of the patrol path start point }}
{{OBDtr| 0x18 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the x-axis in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the y-axis in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z-axis in degrees }}
{{OBDtr2|0x24 | char[32] |FFC800| Floor1_Stk_1 | patrol path name }}
{{OBDtr| 0x44 | int32 |C800C8| 04 00 00 00 | 4 | number of path points (grey outline) }}
{{OBDtr| 0x48 | int16 |C87C64| 00 00 | 0 | patrol path ID }}
{{OBDtr| 0x4A | int16 |B0C3D4| 01 00 | 1 | "return to nearest"? }}
{{OBDtrBK|1=First path point (grey outline)}}
{{OBDtr| 0x00 | int32 |E7CEA5| 13 00 00 00 | 19 | path point type; the following types are possible (values in dec):

:00 - move to flag (short)
:01 - stop (nothing); (not used in Oni)
:02 - pause in frames (long)
:03 - look at flag (short)
:04 - look at point (float, float, float); (not used in Oni)
:05 - move and face to flag (short)
:06 - run path in a loop (nothing)
:07 - movement mode (long) - the following values are possible:

::0 - by alert level
::1 - stop
::2 - crouch
::3 - creep
::4 - walk - no aim
::5 - walk
::6 - run - no aim
::7 - run
::8 - forwards
::9 - backwards
::10 - left
::11 - right
::12 - stopped

:08 - unknown; (not used in Oni)
:09 - unknown; (not used in Oni)
:10 - move through flag (short, float) - character moves to this flag until he/she has reached the radius border of it
:11 - move through point (float, float, float, float) - character moves to this point until he/she has reached the radius border of it; (not used in Oni)
:12 - stop looking (nothing)
:13 - free facing?; used only once
:14 - glance at flag for ... frames (short + long) - character looks (rotates only the head) to the flag for the fixed time
:15 - move near flag (short + float) - character moves to this flag until he/she has reached the radius border of it
:16 - run path in a loop from block number (long) - runs the complete path once; after that it loops the path from the block number to the end (note that the block number of the first block is zero and not one)
:17 - time + rotation (short + float) - character looks/aims around for the fixed time
:18 - unkown (nothing follows)
:19 - time + flag + rotation in degrees (short + short + float) - character moves to the flag and when reached he/she looks/aims around for the fixed time
:20 - time follows (short)
:21 - patrolscript id follows (short) - function with this id is called up (f.e. id <nowiki>= 1, then called up function =</nowiki> patrolscript0001)
:22 - ignore player (byte) - 0 <nowiki>= off; 1 =</nowiki> on
:23 - flag + time + firing spread in degrees (short + short + float) - character faces to to the flag and fires his/her weapon for the fixed time

}}
{{OBDtr| 0x04 | int16 |FFDDDD| 58 02 | 600 | sleep time in 1/60 seconds }}
{{OBDtr| 0x06 | int16 |64AAAA| CB 00 | 203 | flag ID }}
{{OBDtr| 0x08 | float |EBEBEB| 00 00 A0 42 | 80.000000 | look around angle in degrees }}
|}

;Path points
:A path can have at most 64 points.

;Bluebox screenshots

http://ssg.oni2.net/subfold/bluebox/images/300_edit_paths.png

http://ssg.oni2.net/subfold/bluebox/images/301_edit_path.png

http://ssg.oni2.net/subfold/bluebox/images/302_edit_path_point.png

{{OBD OBJC Footer | type=PATR | prev=PART | next=PWRU | name=Patrol path}}

{{OBD}}

Talk:OniSplit

2009-05-05T12:02:23Z

Ssg: Thank you.

Here's is my latest on creating a modified TRBS.

I call this The Fly! lol

http://edt.oni2.net/OniSplit/flyhead.jpg

I used the head from owldreamer's Masterchief. It looked correct in Blender, but it is rotated wrong here. There is no texture map for it. Also, the texture mapping is off for the rest of the body, even though I did not make any changes.

Neo: Also can you take a look at this blender file and tell me what I did wrong:

http://edt.oni2.net/OniSplit/MasterChief.blend.zip

I imported owldreamer's Masterchief, renamed the geometries, set the parents, all the rotations were set to 0. But when importing to Oni, it was broken.

http://edt.oni2.net/OniSplit/MCbroken.jpg

I also had a question about the naming of the geometries. In Blender the names go right_thigh, left_calf and so on. But when I looked at an exported ONCC as an OBJ, they are named thigh_right, calf_left. Which is correct? Especially when naming in Blender? Also, why does Blender have the the name left_left? I looked at the naming structure from the extracted ONCCkonoko_generic.dae which was imported into Blender.

I hope you don't mind all these newbie questions.

Thanks,

EdT

First the simple problems: [http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/OniSplit_v0.9.4.zip OniSplit 0.9.4] contains:
:*fix for flipped textures
:*corrected left_left to left_thigh

Then the case of thigh_right, calf_left: these are old names, they should not show up in newly exported files anymore. I changed them to match the ones found here [[TRIA]]. In addition the old names were swpped left was right, right was left and this was fixed too when I changed them.

The rotated head: It happened to me too, not sure what I did to get it working. What I think you should try is to unparent the head, move it to origin and rotate it so that it has the same orientation as Konoko's original head (along the X axis, not the Y axis). After that you can use that "Apply Scaling/Rotation to ObData" option, reparent it to neck and translate it back in its place. I'll experiment more with this later and I'll try to make a definitive list of steps to take to do this type of thing.

The MC body: this one has a slightly different problem than the head but not totally unrelated. Note than when you select a body part the "center" point for rotations (the origin of bone's coordinate system) shows up somewhere at the bottom. Compare this with what happens when doing the same thing with an exported TRBS: that point is where the "joint" is. Currently I don't know how to move this in Blender. For head I used that ObData To Center option but this is does not always work, the joint is rarely the center of the bone.

[[User:Neo|Neo]]

I see from this discussion that from now on I should be working with newly-exported TRBS files. Unfortunately, I've already put a lot of work into Griffin in Blender, so I'll have to manually fix things like wrong part names (I do see calf_left and thigh_right in my file, for instance). From now on, I'll only work on newly-exported models. But on that note, is it better to export as OBJ or DAE? Should I be going with DAE from now on?

Also, what does it mean when OniSplit doesn't return an error (or any message at all) when I use create:trbs, but it generates a file that's only 984 bytes? Because that's what happened when I selected Disable Physics and Current Scene Only and then used OniSplit 0.9.3 on the resulting DAE file. It's like there's header info for different file types but no actual data there.

For the most part, it seems like I should wait for you two to sort the problems out before I continue trying to import. EdT is already further along than I am, even with his horror-movie-like results. :-) --[[User:Iritscen|Iritscen]] 15:45, 11 April 2008 (CEST)

Neo: Thanks for the update and the instructions.

Iritscen: Have you tried selecting all before exporting from blender? Also, couldn't you extract the TRBS for Griffin and them import the your modified head into it? Is it possible to select an object in one file (such as your modified head) and then copy and paste it into another (the new TRBS file) in Blender?

Yesterday, Macupdate had a promo on Cheetah3D for $79.00, I quickly got it. I like using Cheetah3D, its much more intuitive for me. Right now, I'm trying to fix owldreamer's Masterchief. It looked odd, many of the surface triangles were black compared to the regular ones. You can see how they looked in the Oni Spartan thread at OCF. But when I applied "flip normal" to them, they looked correct. What does flip normal do?

Anyways, once I fix all those triangles, then I'll try getting the Masterchief into Oni.

EdT

I have not tried selecting all, but I also don't have "Selection Only" checked (I don't think that's the exact name). Still, I can try selecting all first. But at least the head should have been exported, because it was definitely selected. Re copying from one file to another, I think Blender is a one-document application. Perhaps I can copy the head, then close the document and open another one, then paste the head in. It's certainly worth a try.

"What does flip normal do?"
As Wikipedia puts it, "Surface normals are commonly used in 3D computer graphics for lighting calculations". A normal is simply a calculation of a line passing through the polygon at a right angle that is best performed at the time of saving the file rather than at runtime in a game, to save CPU cycles. But which *way* is the line going through the 'gon? If it's set to go the wrong way, the polygon will be lit on the inside, not the outside (at least, the outside won't be lit), hence black polygons. As to why normals get flipped in the first place, *shrug*. --[[User:Iritscen|Iritscen]] 16:42, 11 April 2008 (CEST)

Hmm... a bunch of comments :). Let's see a couple of them:
:*Selection: you should have no trouble with selection if "Only Export Selection" options is not used. Of course, since Blender "checkboxes" differ only in colour between checked/unchecked states you may want to be carefull about what options are checked. In addtion make sure you selected the scene you want to export before exporting if you have more than one scene.
:*Copy/Paste: I have no idea how to copy/paste stuff in Blender. I wonder if it actually supports that, I have a feeling that it does not...
:*Blender - one document application: Yes, it is. But you should be able to import a file (obj, dae) in a "document".
:*Cheetah3D: no idea how it is but it's probably better than Blender, anything's better than Blender (at least in terms of user interface) :). Not sure if it has a Collada exporter/importer?

[[User:Neo|Neo]]

Just a brief update, the latest version of Onisplit works fine. I am making some progress, though working with Blender can be frustrating. I lost a few hours of work, don't know what happened. I had hoped to have the Masterchief done over the weekend, but maybe in a couple more days, when I have more time.

EdT

Didn't you say you bought Cheetah3D? Even if it cannot export Collada you may still be able to fix normals and geometry positions using it and then export the bones to OBJ and assembly and export them using Blender.
Blender only makes sense if you are willing to spend a lot of time to learn its user interface. My opinion is that it's a terrible waste of time.

[[User:Neo|Neo]]

Neo, that's about the workflow that I developed in working with the 3D models. I probably should have tried something basic, like swapping geometries from different characters, instead of trying to import the Masterchief model. But that's me. :-)

I tried a couple of approaches, first, I imported the entire Masterchief model into Cheetah3D, then positioned the parts similar to the way Blender imports the TRBS Collada files (That weird looking way that the arms and legs are rotated, though, I don't think I got the arms rotation correct) Since Cheetah3D cannot import or export Collada yet (The author says after the next FBX SDK comes out, he'll work on Collada) I have been exporting the file as .3DS. Next import into Blender, scale the model to size. Use the clear/apply scaling to obdata. Move the center point (object/transform center to cursor) to hopefully the correct position for each part, rename each part (Blender does not import the names correctly). Parent all the parts. Export the current scene with triangles, disable physics, use relative paths (is that needed?). Import into Oni... start game, select level where I imported the character. CRASH!

To isolate the cause, I then tried another approach. Import into Blender the Elite Hard TRBS Collada file created by Onisplit, then replaced a part, with the Masterchief part. Import into Oni and I would see the Elite with some Masterchief part. Next add another part and so on. This is time consuming, saving as I'm going along. Then, made another change, imported to Oni, CRASH. No problem, just delete the part and try again. But from that point on, any changes, even trying to undo the changes and go back to a point that worked, resulted in Oni crashing. That's where I lost the few hours work. Next time, as I make a change, I'll save the file in a different name.

But while, doing this process revealed some errors in the Masterchief's parts which owldreamer was able to fix.

If you see anything I'm doing wrong, or can suggest a better workflow, please let me know.

Thanks,

EdT

How many polys is the Master Chief model? --[[User:Iritscen|Iritscen]] 16:01, 14 April 2008 (CEST)

It would help if you can give me one of those TRBS.oni files that crash Oni so I can try to figure out the reason.

[[User:Neo|Neo]]

Here is the version with the Masterchief directly imported from the start. Both Blender and TRBS.oni files:
http://edt.oni2.net/3D/MCfiles.zip

According to Cheetah3D for the Masterchief model: 19 polygon objects, 2580 polygons, 2580 triangles.

This is one screenshot I got before the lost data:

http://edt.oni2.net/3D/EliteMC.jpg

EdT

A quick update until I sort things out:
:*the .oni file from MCfiles.zip is strange, it only contains the chest.
:*exporting your .blend model to Collada and then creating a TRBS out of it seems to work fine, the body is complete
:*it crashes for me after a while. More exactly it crashes when I get close to the MC (I replaced Barabus's body with the MC and I'm testing in level3). If I stay far enough it seems to be stable... really odd.

[[User:Neo|Neo]]

Have any of us exported a character and then imported them back in, without making any changes (aside from the format conversions)? In any case, it sounds like something in the rendering info (normals, bone center points, etc.) is messed-up, if Oni crashes when it's near to the model, because that's when the engine starts to calculate line-of-sight using model info, to know whether to render it or not. But I really don't know that much about how Oni's engine works. (You're sure it's not a scripted command that kicks in for Barabas that has a problem with the new model, right?) Also, at what point does the highest LOD kick in? It's been said to be pretty far away. Perhaps the crash happens when you cross that threshold?

Ed, it may not be relevant, but I'm curious as to which part you added before that crash after which the model became unuseable. Was it the pelvis?

--[[User:Iritscen|Iritscen]] 21:07, 14 April 2008 (CEST)

Yes, I have some exported/imported models, konoko_generic and tctf_swat, no problems with them.

LOD stuff: it looks like something LOD related since it crashes when you get closer but OniSplit does not currently support different LODs so it just uses the same geometry for all. Nothing really changes when it switches from one LOD to another.

The crash is caused by something that looks like memory corruption and last time I saw this it was related to high triangle count but it does not seem to be the case here, the triangle count is low enough.

Even more interesting: OniBrowser loads that "crashy" TRBS just fine. Now it's true that OniBrowser allows stuff that Oni does not allow (like more triangles) but it is also more likely to crash on bad geometric data (like bad vertex indices).

[[User:Neo|Neo]]

And one thing that I forgot about fbx/collada:

Autodesk has a converter that it is able to convert back and forth between the two. I tried the Windows version and it seem to work, hopefully the Mac version works too so you can use it to convert fbx exported from Cheetah3D.

Here it is: [http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=6839916 Autodesk FBX]. It's a bit of hassle with "registration" but it's free.

[[User:Neo|Neo]]

Neo, Can you post the working Masterchief TRBS file so I can try it on my Mac.
Here is the TRBS file again that I exported from Blender (It seems the previous one had the chest selected when exporting the TRBS file) and the crash log (May give you an idea what went wrong) : http://edt.oni2.net/3D/MC_crash.zip

I will take a look at the Autodesk converter.

EdT

I did not say mine was working completly. It crashes after a while too.

Anyway your new .oni file looks like mine and your crash log indicates that your Oni crashes in the exact same place as mine so it's not an OS X version problem or something.

[[User:Neo|Neo]]

It may be an OSX issue too, because, I'm not able to load the level at all with that TRBS file. In some versions, it crashes as the progress bar reaches around 60%, other times, the progress bar completes, but before the Intro screen appears, it crashes. So I wonder why you can use the character for a while, before crashing, but the Mac crashes right away. On another note, when I'm able to view the character, like in the screenshot above, I would also get a crash when the character got near the camera.

Iritscen: Please join us in the fun/frustration of importing 3D models into Oni. The more people are testing it out, the quicker we can provide Neo with information and feedback, that may help him with Onisplit.

EdT

Neah, I don't think it has anything to do with OSX because the stack trace in your crash report looks to damn similar to the one I get on PC. It's just that memory corruption (if that is what's happening) has different effects depending on operating system and the compiler that was used to compile the executable.

[[User:Neo|Neo]]

And we have the first dead MC in Oni! :)

geyser told me something about texture coordinates messing his OBJ viewer so I removed all texture coordinates from MasterChief and reimported and now it seems to work. At least long enough to kill BarabusMC.

[http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/Images/mcb.jpg Screenshot]

[http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/TRBSMasterChief.oni TRBSMasterChief]

I'm still getting a crash but only when moving the camera very very close to MC and it's a different place in code where it happens.

[[User:Neo|Neo]]

This is awesome! I have a fighting EliteMC. Now we need to fix his body a bit more, I noticed his left biceps is higher than the right one and his standing posture looks a little off.
Can you post the collada version of MC so I can take a look. Also, how did you remove the texture coordinates? Will that affect our ability to add more complex texture maps instead on the simple single color ones?

EdT

Here's my collada file: [http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/MasterChief.dae MasterChief].

To remove texture coordinates: select a bone and below there is a Mesh panel. Somewhere in that panel there is an UVTex field with a X button to its right. Use that button to delete the texture coordinates for the current bone. You need to do that for every bone

As for adding texture maps: the problem is that the current texture coordinates are sort of broken and Oni does not like them. Once someone fixes the coordinates it will work.

What's broken about them? Some coordinate are outside of 0..1 range and Oni does not seem to like that.

Why deleting them makes it work (and result in a somewhat coloured MC)? When no texture coordinates are present in the Collada file OniSplit uses (0,0) texture coordinate for all vertices and so the colour you see it's he colour of the texture in that point.

[[User:Neo|Neo]]

So, to recap, there's two observed issues with MC: the texture coord.s being out-of-range for Oni, which you more or less know how to prevent, and an unknown issue that causes a crash at very close range. Is that right? And how close are we talking about? Are you moving the camera with the Dev Mode camera controls? Is the camera entering the model?

--[[User:Iritscen|Iritscen]] 18:56, 15 April 2008 (CEST)

Yes, the current texture coordinates are out of range and make Oni crash. Anyway even if they weren't out of range they're still bad/useless.

Yes, it happens with devmode camera and it appears to happen only when camera enters the body though I'm not sure.

[[User:Neo|Neo]]

Ok. Where does this .oni file go? How do I import it?
Second question: How do I spawn him?

[[User:Gumby|Gumby]] 07:28, 16 April 2008 (CEST)

Gumby, perhaps the easiest way is pick a character like Barabas, look for the file ONCCbarabus.oni in the level0_Folder. Open the ONCCbarabus.oni with a hex editor. Scroll to the end of the file, you should see the text TRBSbarabus_body_high, find that file in level0_Final folder and move it to a safe place. Rename TRBSMasterChief.oni to TRBSbarabus_body_high.oni and put it in the level0_Folder and then recompile level0. Now Barabus will look like the Masterchief. You can do the same with any other character.

Of course, if you want the Masterchief to be a new character and not a replacement, then its a bit more work.

EdT

----

Neo, Is it possible for you to program OniSplit to automatically change the rotation so that when extracting and creating, the 3D model will appear in the standard 3D pose? (Standing up right, with the arms stretched out parallel to the ground).

It will make it easier for myself and others to add new character models without having to deal with rotating the pelvis, thigh, shoulder and fist from a standard 3D pose to the current TRBS extraction/creation pose.

Also, in testing the Masterchief model, it seems only the texture coordinates for the neck is out of range.

----
:Just curious, I know with OniSplit, we can export ONWC as an .obj. But now lets say, we modify that .obj, can we now import it back to Oni?
::;EdT
:Er... DeLorean, anyone? An ONWC can link to any M3GM.
::[[User:Geyser|geyser]] 11:30, 29 April 2008 (CEST)

Got it, I thought it was more complicated when I looked for a M3GM for a specific weapon by name and could not find it in the level0_Final files. There was only about 40 M3GM files listed. But using OUP, I found the mesh for the weapon. But it seems that adding weapons is something that can be done only in OUP, since you need to link to the fileid. In the files generated by Onisplit, I could not find the fileid.

EdT

----
I forgot to mention that I was able to change the appearance of the chaingun weapon, using 17 secs rifle model. Obviously, the model still needs work to get it to look right, but this is more of a proof of concept than anything. Here is the new weapon: http://edt.oni2.net/AE/w16crb.zip

EdT

----

http://ssg.oni2.net/test/os037.png

OS v0.37 extracts no files. If I use level 14 it extracts only the first ONCC file (obj, material, plus the textures). (Same problems with OS v0.30. Other versions not tested.) Where did I go wrong?

[[User:Ssg|Ssg]] 09:11, 4 May 2009 (UTC)

It's because it doesn't search the level0_Final.dat for character animations. I patched the existing 0.9.37 version, redownload it. See my talk page if you don't know the link.

[[User:Neo|Neo]]

Thank you. [[User:Ssg|Ssg]] 12:02, 5 May 2009 (UTC)

Talk:OniSplit

2009-05-04T11:06:56Z

Ssg: changed sentence construction

Talk:OniSplit

2009-05-04T09:11:49Z

Ssg: OS v0.37 doesn't extract obj

Here's is my latest on creating a modified TRBS.

I call this The Fly! lol

http://edt.oni2.net/OniSplit/flyhead.jpg

I used the head from owldreamer's Masterchief. It looked correct in Blender, but it is rotated wrong here. There is no texture map for it. Also, the texture mapping is off for the rest of the body, even though I did not make any changes.

Neo: Also can you take a look at this blender file and tell me what I did wrong:

http://edt.oni2.net/OniSplit/MasterChief.blend.zip

I imported owldreamer's Masterchief, renamed the geometries, set the parents, all the rotations were set to 0. But when importing to Oni, it was broken.

http://edt.oni2.net/OniSplit/MCbroken.jpg

I also had a question about the naming of the geometries. In Blender the names go right_thigh, left_calf and so on. But when I looked at an exported ONCC as an OBJ, they are named thigh_right, calf_left. Which is correct? Especially when naming in Blender? Also, why does Blender have the the name left_left? I looked at the naming structure from the extracted ONCCkonoko_generic.dae which was imported into Blender.

I hope you don't mind all these newbie questions.

Thanks,

EdT

First the simple problems: [http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/OniSplit_v0.9.4.zip OniSplit 0.9.4] contains:
:*fix for flipped textures
:*corrected left_left to left_thigh

Then the case of thigh_right, calf_left: these are old names, they should not show up in newly exported files anymore. I changed them to match the ones found here [[TRIA]]. In addition the old names were swpped left was right, right was left and this was fixed too when I changed them.

The rotated head: It happened to me too, not sure what I did to get it working. What I think you should try is to unparent the head, move it to origin and rotate it so that it has the same orientation as Konoko's original head (along the X axis, not the Y axis). After that you can use that "Apply Scaling/Rotation to ObData" option, reparent it to neck and translate it back in its place. I'll experiment more with this later and I'll try to make a definitive list of steps to take to do this type of thing.

The MC body: this one has a slightly different problem than the head but not totally unrelated. Note than when you select a body part the "center" point for rotations (the origin of bone's coordinate system) shows up somewhere at the bottom. Compare this with what happens when doing the same thing with an exported TRBS: that point is where the "joint" is. Currently I don't know how to move this in Blender. For head I used that ObData To Center option but this is does not always work, the joint is rarely the center of the bone.

[[User:Neo|Neo]]

I see from this discussion that from now on I should be working with newly-exported TRBS files. Unfortunately, I've already put a lot of work into Griffin in Blender, so I'll have to manually fix things like wrong part names (I do see calf_left and thigh_right in my file, for instance). From now on, I'll only work on newly-exported models. But on that note, is it better to export as OBJ or DAE? Should I be going with DAE from now on?

Also, what does it mean when OniSplit doesn't return an error (or any message at all) when I use create:trbs, but it generates a file that's only 984 bytes? Because that's what happened when I selected Disable Physics and Current Scene Only and then used OniSplit 0.9.3 on the resulting DAE file. It's like there's header info for different file types but no actual data there.

For the most part, it seems like I should wait for you two to sort the problems out before I continue trying to import. EdT is already further along than I am, even with his horror-movie-like results. :-) --[[User:Iritscen|Iritscen]] 15:45, 11 April 2008 (CEST)

Neo: Thanks for the update and the instructions.

Iritscen: Have you tried selecting all before exporting from blender? Also, couldn't you extract the TRBS for Griffin and them import the your modified head into it? Is it possible to select an object in one file (such as your modified head) and then copy and paste it into another (the new TRBS file) in Blender?

Yesterday, Macupdate had a promo on Cheetah3D for $79.00, I quickly got it. I like using Cheetah3D, its much more intuitive for me. Right now, I'm trying to fix owldreamer's Masterchief. It looked odd, many of the surface triangles were black compared to the regular ones. You can see how they looked in the Oni Spartan thread at OCF. But when I applied "flip normal" to them, they looked correct. What does flip normal do?

Anyways, once I fix all those triangles, then I'll try getting the Masterchief into Oni.

EdT

I have not tried selecting all, but I also don't have "Selection Only" checked (I don't think that's the exact name). Still, I can try selecting all first. But at least the head should have been exported, because it was definitely selected. Re copying from one file to another, I think Blender is a one-document application. Perhaps I can copy the head, then close the document and open another one, then paste the head in. It's certainly worth a try.

"What does flip normal do?"
As Wikipedia puts it, "Surface normals are commonly used in 3D computer graphics for lighting calculations". A normal is simply a calculation of a line passing through the polygon at a right angle that is best performed at the time of saving the file rather than at runtime in a game, to save CPU cycles. But which *way* is the line going through the 'gon? If it's set to go the wrong way, the polygon will be lit on the inside, not the outside (at least, the outside won't be lit), hence black polygons. As to why normals get flipped in the first place, *shrug*. --[[User:Iritscen|Iritscen]] 16:42, 11 April 2008 (CEST)

Hmm... a bunch of comments :). Let's see a couple of them:
:*Selection: you should have no trouble with selection if "Only Export Selection" options is not used. Of course, since Blender "checkboxes" differ only in colour between checked/unchecked states you may want to be carefull about what options are checked. In addtion make sure you selected the scene you want to export before exporting if you have more than one scene.
:*Copy/Paste: I have no idea how to copy/paste stuff in Blender. I wonder if it actually supports that, I have a feeling that it does not...
:*Blender - one document application: Yes, it is. But you should be able to import a file (obj, dae) in a "document".
:*Cheetah3D: no idea how it is but it's probably better than Blender, anything's better than Blender (at least in terms of user interface) :). Not sure if it has a Collada exporter/importer?

[[User:Neo|Neo]]

Just a brief update, the latest version of Onisplit works fine. I am making some progress, though working with Blender can be frustrating. I lost a few hours of work, don't know what happened. I had hoped to have the Masterchief done over the weekend, but maybe in a couple more days, when I have more time.

EdT

Didn't you say you bought Cheetah3D? Even if it cannot export Collada you may still be able to fix normals and geometry positions using it and then export the bones to OBJ and assembly and export them using Blender.
Blender only makes sense if you are willing to spend a lot of time to learn its user interface. My opinion is that it's a terrible waste of time.

[[User:Neo|Neo]]

Neo, that's about the workflow that I developed in working with the 3D models. I probably should have tried something basic, like swapping geometries from different characters, instead of trying to import the Masterchief model. But that's me. :-)

I tried a couple of approaches, first, I imported the entire Masterchief model into Cheetah3D, then positioned the parts similar to the way Blender imports the TRBS Collada files (That weird looking way that the arms and legs are rotated, though, I don't think I got the arms rotation correct) Since Cheetah3D cannot import or export Collada yet (The author says after the next FBX SDK comes out, he'll work on Collada) I have been exporting the file as .3DS. Next import into Blender, scale the model to size. Use the clear/apply scaling to obdata. Move the center point (object/transform center to cursor) to hopefully the correct position for each part, rename each part (Blender does not import the names correctly). Parent all the parts. Export the current scene with triangles, disable physics, use relative paths (is that needed?). Import into Oni... start game, select level where I imported the character. CRASH!

To isolate the cause, I then tried another approach. Import into Blender the Elite Hard TRBS Collada file created by Onisplit, then replaced a part, with the Masterchief part. Import into Oni and I would see the Elite with some Masterchief part. Next add another part and so on. This is time consuming, saving as I'm going along. Then, made another change, imported to Oni, CRASH. No problem, just delete the part and try again. But from that point on, any changes, even trying to undo the changes and go back to a point that worked, resulted in Oni crashing. That's where I lost the few hours work. Next time, as I make a change, I'll save the file in a different name.

But while, doing this process revealed some errors in the Masterchief's parts which owldreamer was able to fix.

If you see anything I'm doing wrong, or can suggest a better workflow, please let me know.

Thanks,

EdT

How many polys is the Master Chief model? --[[User:Iritscen|Iritscen]] 16:01, 14 April 2008 (CEST)

It would help if you can give me one of those TRBS.oni files that crash Oni so I can try to figure out the reason.

[[User:Neo|Neo]]

Here is the version with the Masterchief directly imported from the start. Both Blender and TRBS.oni files:
http://edt.oni2.net/3D/MCfiles.zip

According to Cheetah3D for the Masterchief model: 19 polygon objects, 2580 polygons, 2580 triangles.

This is one screenshot I got before the lost data:

http://edt.oni2.net/3D/EliteMC.jpg

EdT

A quick update until I sort things out:
:*the .oni file from MCfiles.zip is strange, it only contains the chest.
:*exporting your .blend model to Collada and then creating a TRBS out of it seems to work fine, the body is complete
:*it crashes for me after a while. More exactly it crashes when I get close to the MC (I replaced Barabus's body with the MC and I'm testing in level3). If I stay far enough it seems to be stable... really odd.

[[User:Neo|Neo]]

Have any of us exported a character and then imported them back in, without making any changes (aside from the format conversions)? In any case, it sounds like something in the rendering info (normals, bone center points, etc.) is messed-up, if Oni crashes when it's near to the model, because that's when the engine starts to calculate line-of-sight using model info, to know whether to render it or not. But I really don't know that much about how Oni's engine works. (You're sure it's not a scripted command that kicks in for Barabas that has a problem with the new model, right?) Also, at what point does the highest LOD kick in? It's been said to be pretty far away. Perhaps the crash happens when you cross that threshold?

Ed, it may not be relevant, but I'm curious as to which part you added before that crash after which the model became unuseable. Was it the pelvis?

--[[User:Iritscen|Iritscen]] 21:07, 14 April 2008 (CEST)

Yes, I have some exported/imported models, konoko_generic and tctf_swat, no problems with them.

LOD stuff: it looks like something LOD related since it crashes when you get closer but OniSplit does not currently support different LODs so it just uses the same geometry for all. Nothing really changes when it switches from one LOD to another.

The crash is caused by something that looks like memory corruption and last time I saw this it was related to high triangle count but it does not seem to be the case here, the triangle count is low enough.

Even more interesting: OniBrowser loads that "crashy" TRBS just fine. Now it's true that OniBrowser allows stuff that Oni does not allow (like more triangles) but it is also more likely to crash on bad geometric data (like bad vertex indices).

[[User:Neo|Neo]]

And one thing that I forgot about fbx/collada:

Autodesk has a converter that it is able to convert back and forth between the two. I tried the Windows version and it seem to work, hopefully the Mac version works too so you can use it to convert fbx exported from Cheetah3D.

Here it is: [http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=6839916 Autodesk FBX]. It's a bit of hassle with "registration" but it's free.

[[User:Neo|Neo]]

Neo, Can you post the working Masterchief TRBS file so I can try it on my Mac.
Here is the TRBS file again that I exported from Blender (It seems the previous one had the chest selected when exporting the TRBS file) and the crash log (May give you an idea what went wrong) : http://edt.oni2.net/3D/MC_crash.zip

I will take a look at the Autodesk converter.

EdT

I did not say mine was working completly. It crashes after a while too.

Anyway your new .oni file looks like mine and your crash log indicates that your Oni crashes in the exact same place as mine so it's not an OS X version problem or something.

[[User:Neo|Neo]]

It may be an OSX issue too, because, I'm not able to load the level at all with that TRBS file. In some versions, it crashes as the progress bar reaches around 60%, other times, the progress bar completes, but before the Intro screen appears, it crashes. So I wonder why you can use the character for a while, before crashing, but the Mac crashes right away. On another note, when I'm able to view the character, like in the screenshot above, I would also get a crash when the character got near the camera.

Iritscen: Please join us in the fun/frustration of importing 3D models into Oni. The more people are testing it out, the quicker we can provide Neo with information and feedback, that may help him with Onisplit.

EdT

Neah, I don't think it has anything to do with OSX because the stack trace in your crash report looks to damn similar to the one I get on PC. It's just that memory corruption (if that is what's happening) has different effects depending on operating system and the compiler that was used to compile the executable.

[[User:Neo|Neo]]

And we have the first dead MC in Oni! :)

geyser told me something about texture coordinates messing his OBJ viewer so I removed all texture coordinates from MasterChief and reimported and now it seems to work. At least long enough to kill BarabusMC.

[http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/Images/mcb.jpg Screenshot]

[http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/TRBSMasterChief.oni TRBSMasterChief]

I'm still getting a crash but only when moving the camera very very close to MC and it's a different place in code where it happens.

[[User:Neo|Neo]]

This is awesome! I have a fighting EliteMC. Now we need to fix his body a bit more, I noticed his left biceps is higher than the right one and his standing posture looks a little off.
Can you post the collada version of MC so I can take a look. Also, how did you remove the texture coordinates? Will that affect our ability to add more complex texture maps instead on the simple single color ones?

EdT

Here's my collada file: [http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/MasterChief.dae MasterChief].

To remove texture coordinates: select a bone and below there is a Mesh panel. Somewhere in that panel there is an UVTex field with a X button to its right. Use that button to delete the texture coordinates for the current bone. You need to do that for every bone

As for adding texture maps: the problem is that the current texture coordinates are sort of broken and Oni does not like them. Once someone fixes the coordinates it will work.

What's broken about them? Some coordinate are outside of 0..1 range and Oni does not seem to like that.

Why deleting them makes it work (and result in a somewhat coloured MC)? When no texture coordinates are present in the Collada file OniSplit uses (0,0) texture coordinate for all vertices and so the colour you see it's he colour of the texture in that point.

[[User:Neo|Neo]]

So, to recap, there's two observed issues with MC: the texture coord.s being out-of-range for Oni, which you more or less know how to prevent, and an unknown issue that causes a crash at very close range. Is that right? And how close are we talking about? Are you moving the camera with the Dev Mode camera controls? Is the camera entering the model?

--[[User:Iritscen|Iritscen]] 18:56, 15 April 2008 (CEST)

Yes, the current texture coordinates are out of range and make Oni crash. Anyway even if they weren't out of range they're still bad/useless.

Yes, it happens with devmode camera and it appears to happen only when camera enters the body though I'm not sure.

[[User:Neo|Neo]]

Ok. Where does this .oni file go? How do I import it?
Second question: How do I spawn him?

[[User:Gumby|Gumby]] 07:28, 16 April 2008 (CEST)

Gumby, perhaps the easiest way is pick a character like Barabas, look for the file ONCCbarabus.oni in the level0_Folder. Open the ONCCbarabus.oni with a hex editor. Scroll to the end of the file, you should see the text TRBSbarabus_body_high, find that file in level0_Final folder and move it to a safe place. Rename TRBSMasterChief.oni to TRBSbarabus_body_high.oni and put it in the level0_Folder and then recompile level0. Now Barabus will look like the Masterchief. You can do the same with any other character.

Of course, if you want the Masterchief to be a new character and not a replacement, then its a bit more work.

EdT

----

Neo, Is it possible for you to program OniSplit to automatically change the rotation so that when extracting and creating, the 3D model will appear in the standard 3D pose? (Standing up right, with the arms stretched out parallel to the ground).

It will make it easier for myself and others to add new character models without having to deal with rotating the pelvis, thigh, shoulder and fist from a standard 3D pose to the current TRBS extraction/creation pose.

Also, in testing the Masterchief model, it seems only the texture coordinates for the neck is out of range.

----
:Just curious, I know with OniSplit, we can export ONWC as an .obj. But now lets say, we modify that .obj, can we now import it back to Oni?
::;EdT
:Er... DeLorean, anyone? An ONWC can link to any M3GM.
::[[User:Geyser|geyser]] 11:30, 29 April 2008 (CEST)

Got it, I thought it was more complicated when I looked for a M3GM for a specific weapon by name and could not find it in the level0_Final files. There was only about 40 M3GM files listed. But using OUP, I found the mesh for the weapon. But it seems that adding weapons is something that can be done only in OUP, since you need to link to the fileid. In the files generated by Onisplit, I could not find the fileid.

EdT

----
I forgot to mention that I was able to change the appearance of the chaingun weapon, using 17 secs rifle model. Obviously, the model still needs work to get it to look right, but this is more of a proof of concept than anything. Here is the new weapon: http://edt.oni2.net/AE/w16crb.zip

EdT

----

http://ssg.oni2.net/test/os037.png

OS v0.37 extracts no files. If I use level 14 it extracts only the first ONCC file (obj, material, plus the textures). (Same problems with OS v0.30. Other versions not tested.) What did I wrong?

[[User:Ssg|Ssg]] 09:11, 4 May 2009 (UTC)

Talk:Installation

2009-04-06T08:45:56Z

Ssg:

(diff) (hist) . . ! Installation‎; 16:20 . . (-40) . . Iritscen (Talk | contribs | block) (WTF? Every program has a beta, that doesn't mean that we list it here, where people come for help in installing the *public* versions of the game)
:Acknowledged. Next time you <snip> something, be sure to provide a convincing summary right away. Everything you do is OCD by default, remember? --[[User:Geyser|geyser]] 19:07, 23 September 2008 (CEST)
::I thought "Hrm, if it's not public and there's no other support for it on the wiki... <snip>" was enough explanation. Meh, at least we came to an agreement on something, I should just be thankful and break out the party favors. --[[User:Iritscen|Iritscen]] 19:58, 23 September 2008 (CEST)

"Oni does not create any registry entries..." is that true?
I have an Oni version and it creates a registry key in "HKEY_CURRENT_USER\Software". Should someone correct this? --[[User:Lefter|Lefter]] 13:07, 3 April 2009 (UTC)
:Hmm, never heard of it doing that before. Do you have any info on which specific copy you are using? Such as the plublisher, country, or maybe a screenshot of the install screen? [[User:Gumby|Gumby]]
Maybe that's an entry Windows creates automatically for the uninstallation routine. [[User:Ssg|Ssg]] 08:45, 6 April 2009 (UTC)

User talk:Ssg

2009-01-12T18:23:12Z

Ssg: /* Skybox images */

==Skybox images==

The [http://ssg.oni2.net/test/skyhtm/sky.htm skies from Mafia] (sorry for the bad thumbnail quality) for Oni: [http://ssg.oni2.net/test/skyhtm/skyhex.zip skyhex.zip] (~10 mb)

A hex file contains the data (images flipped, mirrored and 32bit) for the raw/sep files. Copy the data of the sky you like to the end of a raw/sep file (with a hex editor) and change the raw/sep link of the sky images in the dat file (with OniUnPacker). Every image has a size of 256x256 pixels, which is a length of 40000 in hex.

For example, if the inserted hex data starts at position 0x02355500, the links have to be changed to:

:front: 0x02355500
:left: 0x02395500
:back: 0x023D5500
:right: 0x02415500
:top: 0x02455500

[[User:Ssg|Ssg]] 12:31, 24 December 2008 (CET)
:Ssg, while those look very nice, there are simpler ways of doing things nowadays. :P We could make them into actual new skys if you wanted. [[User:Gumby|Gumby]] 19:01, 24 December 2008 (CET)
:Glad to see you again, Ssg. I'd love it if you stuck around for a while. But wow, you have a lot of catching up to do when it comes to our modding abilities :-) --[[User:Iritscen|Iritscen]] 19:25, 24 December 2008 (CET) [[User:Ssg|Ssg]] 19:46, 24 December 2008 (CET)

What do you mean by "make them into actual new skys"? Put them into AE? Change them? [[User:Ssg|Ssg]] 19:25, 24 December 2008 (CET)
:Using Onisplit\AE framework, make a new ONSK. [[User:Gumby|Gumby]] 19:33, 24 December 2008 (CET)

@Gumby: Does Onisplit/AE mirror and flip the images and change them into 32 bit automatically?
No, no, and yes. But mirroring and flipping are easy to do in an image editing program. [[User:Gumby|Gumby]] 20:06, 24 December 2008 (CET)
@Iritscen: I wasn't really away. I've been following the things roughly going on at the Oni Central forum and here. So I'm not that much lost. :-) [[User:Ssg|Ssg]] 19:46, 24 December 2008 (CET)

:ssg: Can you post the actual image files? I used the thumbnails for the test sky, also, it seems the left and right are off somehow:
http://edt.oni2.net/AE/sky13.jpg

I used OniSplit to create the new ONSK file [[User:EdT|EdT]]

@EdT: I can post the image files next year. (I don't have them here at my parents.)

The thumbnails are not mirrored and flipped. [[User:Ssg|Ssg]] 21:02, 25 December 2008 (CET)

The [http://ssg.oni2.net/test/skyhtm/skybmp.zip skies] mirrored, flipped and as 24bit bmp files. (zip file, ~10 mb) [[User:Ssg|Ssg]] 09:57, 9 January 2009 (CET)

ssg: The skies look great except for the top image:

http://edt.oni2.net/AE/Airportsky13.jpg

[[User:EdT|EdT]]

:Are you sure its not just all the other images? :)

::OT: Just curious, ssg do you know asm? [[User:EdT|EdT]] 06:06, 12 January 2009 (CET)

I've no idea what's wrong with the top image. I've tested all of them on my pc and they worked great.

To OT: What do you mean by asm? ==> http://en.wikipedia.org/wiki/ASM (Whatever, I don't know any of these points.) [[User:Ssg|Ssg]] 19:23, 12 January 2009 (CET)

==Bungie TV from Macworld 2000==

I found some old Bungie TV videos from the Macworld 2000 on the net today.

Here's a [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/btv%20pamphlet/Inside.jpg pic with the content] of the vids (~300 kb)

*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/bungie_tour_100.mov Day 1] (mov file, 160 x 120, 5 min 33 sec, ~29 mb) - contains only the Bungie East tour; the rest was never part of the file (see [http://web.archive.org/web/20000817095745/www.bungie.com/btv/archive/ here]; look at the filename)
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day2_big.mov Day 2] (mov file, 160 x 120, 38 min 30 sec, ~182 mb) - best vid, trip to Bungie West (Oni headquarters) plus Steve Abeyta shows some disarm moves
*:If anyone just wants to see the short bit of in-game footage (which is supposed to show the disarm moves but inadvertently demoes the working multiplayer they'd end up cutting), I clipped it out and uploaded it [http://iritscen.oni2.net/movies/Steve%20demoes%20netplay.mov here]. --[[User:Iritscen|Iritscen]] 19:33, 24 December 2008 (CET)
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day3_large.mov Day 3] (mov file, 160 x 120, 29 min 07 sec, ~217 mb) - see content pic above, lots of blah blah plus a ingame Halo preview at the end
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day4_100.mov Day 4] (mov file, 160 x 120, 37 min 22 sec, ~277 mb) - see content pic above, very short ingame Halo preview, rest blah blah

You can also download day two, three and four in very extra low poor quality [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/ here] (first three links, 5 to 12 mb), but that's more pixel art than a video. [[User:Ssg|Ssg]] 00:10, 20 January 2008 (CET)

::Cool, look forward to watching these. --[[User:Iritscen|Iritscen]] 15:36, 5 March 2008 (CET)
::I'm going to be linking the Bungie West and East articles to the tour vids (Day 1 and Day 2), so hopefully these files will stay around for a while. Can I count on that to be the case? --[[User:Iritscen|Iritscen]] 15:01, 20 March 2008 (CET)

??? Why are you asking me that? I have no influence in the matter. [[User:Ssg|Ssg]] 00:28, 22 March 2008 (CET)
:I assumed that you uploaded them. Whose files are they? --[[User:Iritscen|Iritscen]] 15:01, 24 March 2008 (CET)

==Bluebox screenshots==
:About the BBBB screenshots you've been adding to [[BINA]]
:#It would be nice if you described how they were obtained.
:#Are you sure '''navi.TXMP''' and '''buttons.TXMP''' are appropriate?
:I'm pretty sure there is another, more plain-looking TXMP.
:Not '''g206_controls_128x64.TXMP''', but something close...
::[[User:Geyser|geyser]] 20:14, 24 September 2007 (CEST)
----
To 1:

#added WMDDs from Level0_Tools.dat to Level0_Final.dat
#replaced the dialog ID (0x108) of the [[OBD:WMDD|WMDD]] with the dialog ID of the help-window (or whatever it's called; it's the window that pops up when you press F1)

To 2:
:I'm not sure what you mean. Do you refer to the fact that some stuff in the iamges is overlapping? (If yes: Well, I never thought about that. I was too fixated on making the WMMDs visible, I guess.)

'''Edit'''

I've changed in the last part of the dat file the name psui_oniUI to psui_oniUi. After that Oni reads the psui_g206 file. The result is this:

now: http://ssg.oni2.net/subfold/bluebox/g206_306_edit_combat.jpg before: http://ssg.oni2.net/subfold/bluebox/images_org/306_edit_combat.jpg

[[User:Ssg|Ssg]] 14:59, 11 December 2007 (CET)

Short note: if there are still dialogs from tools.dat that you do not have screenshots for here you go:
http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/tools_wmdd.zip

[[User:Neo|Neo]]

Cool. Thank you. Did you managed it to "actiivate" the "Tools" files? [[User:Ssg|Ssg]] 01:19, 12 December 2007 (CET)

If by activate you mean loading tools.dat in Oni then no. (Though I converted tools.dat to PC format but Oni crashes if it finds it and I did not bother to check why). Those images were generated with my viewer.

[[User:Neo|Neo]]

Sorry for interrupting you guys a bit.
I saw the new WMMDs.. Are you going to upgrade OniSplit or OUP like Bungie's original editor tool? That would be cool. How far are you done? 
By a side note: on "dialog_character_properties.png" you can see three different shields. So, maybe the (red one) "boss shield" was editable?
:[[User:Paradox-01|Paradox-01]] 17:53, 12 December 2007 (CET)

Would it be possible for me to get a copy of Bluebox since I'm on the Mac?
[[User:EdT|EdT]]

Alloc or geyser can help, I guess. [[User:Ssg|Ssg]] 02:02, 20 January 2008 (CET)

I switched the bluebox images from the blue to the lila ones. Hope that was okay. [[User:Ssg|Ssg]] 18:07, 17 June 2008 (CEST)
:Yes, it's OK. Thanks. [[User:Neo|Neo]]

==Homing Weapons?==
Hi, Ssg. I was looking over the weapons class in the Oni binaries, and I can't find where it records that certain projectiles, like the Scram cannon's, are homing. Isn't there a bit for that? --[[User:Iritscen|Iritscen]] 19:57, 28 February 2008 (CET)
:Homing is a property of the projectile, not of the weapon class. You want to look at [[OBD:BINA/PAR3]].
::[[User:Geyser|geyser]] 23:14, 28 February 2008 (CET)
:Oh... Sorry, Iritscen, didn't see your question.
:Thanks for the answer, geyser. :-)
::[[User:Ssg|Ssg]] 23:04, 4 March 2008 (CET)
Yes, thank you. I have a neat weapon-modding idea I'd like to try. This would be my first modding attempt (we'll see if it works, I don't want to promise much, and it's a simple idea anyway). --[[User:Iritscen|Iritscen]] 15:32, 5 March 2008 (CET)

User talk:Ssg

2009-01-09T08:57:25Z

Ssg: /* Skybox images */ sky image files

==Skybox images==

The [http://ssg.oni2.net/test/skyhtm/sky.htm skies from Mafia] (sorry for the bad thumbnail quality) for Oni: [http://ssg.oni2.net/test/skyhtm/skyhex.zip skyhex.zip] (~10 mb)

A hex file contains the data (images flipped, mirrored and 32bit) for the raw/sep files. Copy the data of the sky you like to the end of a raw/sep file (with a hex editor) and change the raw/sep link of the sky images in the dat file (with OniUnPacker). Every image has a size of 256x256 pixels, which is a length of 40000 in hex.

For example, if the inserted hex data starts at position 0x02355500, the links have to be changed to:

:front: 0x02355500
:left: 0x02395500
:back: 0x023D5500
:right: 0x02415500
:top: 0x02455500

[[User:Ssg|Ssg]] 12:31, 24 December 2008 (CET)
:Ssg, while those look very nice, there are simpler ways of doing things nowadays. :P We could make them into actual new skys if you wanted. [[User:Gumby|Gumby]] 19:01, 24 December 2008 (CET)
:Glad to see you again, Ssg. I'd love it if you stuck around for a while. But wow, you have a lot of catching up to do when it comes to our modding abilities :-) --[[User:Iritscen|Iritscen]] 19:25, 24 December 2008 (CET) [[User:Ssg|Ssg]] 19:46, 24 December 2008 (CET)

What do you mean by "make them into actual new skys"? Put them into AE? Change them? [[User:Ssg|Ssg]] 19:25, 24 December 2008 (CET)
:Using Onisplit\AE framework, make a new ONSK. [[User:Gumby|Gumby]] 19:33, 24 December 2008 (CET)

@Gumby: Does Onisplit/AE mirror and flip the images and change them into 32 bit automatically?
No, no, and yes. But mirroring and flipping are easy to do in an image editing program. [[User:Gumby|Gumby]] 20:06, 24 December 2008 (CET)
@Iritscen: I wasn't really away. I've been following the things roughly going on at the Oni Central forum and here. So I'm not that much lost. :-) [[User:Ssg|Ssg]] 19:46, 24 December 2008 (CET)

:ssg: Can you post the actual image files? I used the thumbnails for the test sky, also, it seems the left and right are off somehow:
http://edt.oni2.net/AE/sky13.jpg

I used OniSplit to create the new ONSK file [[User:EdT|EdT]]

@EdT: I can post the image files next year. (I don't have them here at my parents.)

The thumbnails are not mirrored and flipped. [[User:Ssg|Ssg]] 21:02, 25 December 2008 (CET)

The [http://ssg.oni2.net/test/skyhtm/skybmp.zip skies] mirrored, flipped and as 24bit bmp files. (zip file, ~10 mb) [[User:Ssg|Ssg]] 09:57, 9 January 2009 (CET)

==Bungie TV from Macworld 2000==

I found some old Bungie TV videos from the Macworld 2000 on the net today.

Here's a [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/btv%20pamphlet/Inside.jpg pic with the content] of the vids (~300 kb)

*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/bungie_tour_100.mov Day 1] (mov file, 160 x 120, 5 min 33 sec, ~29 mb) - contains only the Bungie East tour; the rest was never part of the file (see [http://web.archive.org/web/20000817095745/www.bungie.com/btv/archive/ here]; look at the filename)
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day2_big.mov Day 2] (mov file, 160 x 120, 38 min 30 sec, ~182 mb) - best vid, trip to Bungie West (Oni headquarters) plus Steve Abeyta shows some disarm moves
*:If anyone just wants to see the short bit of in-game footage (which is supposed to show the disarm moves but inadvertently demoes the working multiplayer they'd end up cutting), I clipped it out and uploaded it [http://iritscen.oni2.net/movies/Steve%20demoes%20netplay.mov here]. --[[User:Iritscen|Iritscen]] 19:33, 24 December 2008 (CET)
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day3_large.mov Day 3] (mov file, 160 x 120, 29 min 07 sec, ~217 mb) - see content pic above, lots of blah blah plus a ingame Halo preview at the end
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day4_100.mov Day 4] (mov file, 160 x 120, 37 min 22 sec, ~277 mb) - see content pic above, very short ingame Halo preview, rest blah blah

You can also download day two, three and four in very extra low poor quality [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/ here] (first three links, 5 to 12 mb), but that's more pixel art than a video. [[User:Ssg|Ssg]] 00:10, 20 January 2008 (CET)

::Cool, look forward to watching these. --[[User:Iritscen|Iritscen]] 15:36, 5 March 2008 (CET)
::I'm going to be linking the Bungie West and East articles to the tour vids (Day 1 and Day 2), so hopefully these files will stay around for a while. Can I count on that to be the case? --[[User:Iritscen|Iritscen]] 15:01, 20 March 2008 (CET)

??? Why are you asking me that? I have no influence in the matter. [[User:Ssg|Ssg]] 00:28, 22 March 2008 (CET)
:I assumed that you uploaded them. Whose files are they? --[[User:Iritscen|Iritscen]] 15:01, 24 March 2008 (CET)

==Bluebox screenshots==
:About the BBBB screenshots you've been adding to [[BINA]]
:#It would be nice if you described how they were obtained.
:#Are you sure '''navi.TXMP''' and '''buttons.TXMP''' are appropriate?
:I'm pretty sure there is another, more plain-looking TXMP.
:Not '''g206_controls_128x64.TXMP''', but something close...
::[[User:Geyser|geyser]] 20:14, 24 September 2007 (CEST)
----
To 1:

#added WMDDs from Level0_Tools.dat to Level0_Final.dat
#replaced the dialog ID (0x108) of the [[OBD:WMDD|WMDD]] with the dialog ID of the help-window (or whatever it's called; it's the window that pops up when you press F1)

To 2:
:I'm not sure what you mean. Do you refer to the fact that some stuff in the iamges is overlapping? (If yes: Well, I never thought about that. I was too fixated on making the WMMDs visible, I guess.)

'''Edit'''

I've changed in the last part of the dat file the name psui_oniUI to psui_oniUi. After that Oni reads the psui_g206 file. The result is this:

now: http://ssg.oni2.net/subfold/bluebox/g206_306_edit_combat.jpg before: http://ssg.oni2.net/subfold/bluebox/images_org/306_edit_combat.jpg

[[User:Ssg|Ssg]] 14:59, 11 December 2007 (CET)

Short note: if there are still dialogs from tools.dat that you do not have screenshots for here you go:
http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/tools_wmdd.zip

[[User:Neo|Neo]]

Cool. Thank you. Did you managed it to "actiivate" the "Tools" files? [[User:Ssg|Ssg]] 01:19, 12 December 2007 (CET)

If by activate you mean loading tools.dat in Oni then no. (Though I converted tools.dat to PC format but Oni crashes if it finds it and I did not bother to check why). Those images were generated with my viewer.

[[User:Neo|Neo]]

Sorry for interrupting you guys a bit.
I saw the new WMMDs.. Are you going to upgrade OniSplit or OUP like Bungie's original editor tool? That would be cool. How far are you done? 
By a side note: on "dialog_character_properties.png" you can see three different shields. So, maybe the (red one) "boss shield" was editable?
:[[User:Paradox-01|Paradox-01]] 17:53, 12 December 2007 (CET)

Would it be possible for me to get a copy of Bluebox since I'm on the Mac?
[[User:EdT|EdT]]

Alloc or geyser can help, I guess. [[User:Ssg|Ssg]] 02:02, 20 January 2008 (CET)

I switched the bluebox images from the blue to the lila ones. Hope that was okay. [[User:Ssg|Ssg]] 18:07, 17 June 2008 (CEST)
:Yes, it's OK. Thanks. [[User:Neo|Neo]]

==Homing Weapons?==
Hi, Ssg. I was looking over the weapons class in the Oni binaries, and I can't find where it records that certain projectiles, like the Scram cannon's, are homing. Isn't there a bit for that? --[[User:Iritscen|Iritscen]] 19:57, 28 February 2008 (CET)
:Homing is a property of the projectile, not of the weapon class. You want to look at [[OBD:BINA/PAR3]].
::[[User:Geyser|geyser]] 23:14, 28 February 2008 (CET)
:Oh... Sorry, Iritscen, didn't see your question.
:Thanks for the answer, geyser. :-)
::[[User:Ssg|Ssg]] 23:04, 4 March 2008 (CET)
Yes, thank you. I have a neat weapon-modding idea I'd like to try. This would be my first modding attempt (we'll see if it works, I don't want to promise much, and it's a simple idea anyway). --[[User:Iritscen|Iritscen]] 15:32, 5 March 2008 (CET)

User talk:Ssg

2008-12-25T20:02:34Z

Ssg: /* Skybox images */

==Skybox images==

The [http://ssg.oni2.net/test/skyhtm/sky.htm skies from Mafia] (sorry for the bad thumbnail quality) for Oni: [http://ssg.oni2.net/test/skyhtm/skyhex.zip skyhex.zip] (~10 mb)

A hex file contains the data (images flipped, mirrored and 32bit) for the raw/sep files. Copy the data of the sky you like to the end of a raw/sep file (with a hex editor) and change the raw/sep link of the sky images in the dat file (with OniUnPacker). Every image has a size of 256x256 pixels, which is a length of 40000 in hex.

For example, if the inserted hex data starts at position 0x02355500, the links have to be changed to:

:front: 0x02355500
:left: 0x02395500
:back: 0x023D5500
:right: 0x02415500
:top: 0x02455500

[[User:Ssg|Ssg]] 12:31, 24 December 2008 (CET)
:Ssg, while those look very nice, there are simpler ways of doing things nowadays. :P We could make them into actual new skys if you wanted. [[User:Gumby|Gumby]] 19:01, 24 December 2008 (CET)
:Glad to see you again, Ssg. I'd love it if you stuck around for a while. But wow, you have a lot of catching up to do when it comes to our modding abilities :-) --[[User:Iritscen|Iritscen]] 19:25, 24 December 2008 (CET) [[User:Ssg|Ssg]] 19:46, 24 December 2008 (CET)

What do you mean by "make them into actual new skys"? Put them into AE? Change them? [[User:Ssg|Ssg]] 19:25, 24 December 2008 (CET)
:Using Onisplit\AE framework, make a new ONSK. [[User:Gumby|Gumby]] 19:33, 24 December 2008 (CET)

@Gumby: Does Onisplit/AE mirror and flip the images and change them into 32 bit automatically?
No, no, and yes. But mirroring and flipping are easy to do in an image editing program. [[User:Gumby|Gumby]] 20:06, 24 December 2008 (CET)
@Iritscen: I wasn't really away. I've been following the things roughly going on at the Oni Central forum and here. So I'm not that much lost. :-) [[User:Ssg|Ssg]] 19:46, 24 December 2008 (CET)

:ssg: Can you post the actual image files? I used the thumbnails for the test sky, also, it seems the left and right are off somehow:
http://edt.oni2.net/AE/sky13.jpg

I used OniSplit to create the new ONSK file [[User:EdT|EdT]]

@EdT: I can post the image files next year. (I don't have them here at my parents.)

The thumbnails are not mirrored and flipped. [[User:Ssg|Ssg]] 21:02, 25 December 2008 (CET)

==Bungie TV from Macworld 2000==

I found some old Bungie TV videos from the Macworld 2000 on the net today.

Here's a [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/btv%20pamphlet/Inside.jpg pic with the content] of the vids (~300 kb)

*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/bungie_tour_100.mov Day 1] (mov file, 160 x 120, 5 min 33 sec, ~29 mb) - contains only the Bungie East tour; the rest was never part of the file (see [http://web.archive.org/web/20000817095745/www.bungie.com/btv/archive/ here]; look at the filename)
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day2_big.mov Day 2] (mov file, 160 x 120, 38 min 30 sec, ~182 mb) - best vid, trip to Bungie West (Oni headquarters) plus Steve Abeyta shows some disarm moves
*:If anyone just wants to see the short bit of in-game footage (which is supposed to show the disarm moves but inadvertently demoes the working multiplayer they'd end up cutting), I clipped it out and uploaded it [http://iritscen.oni2.net/movies/Steve%20demoes%20netplay.mov here]. --[[User:Iritscen|Iritscen]] 19:33, 24 December 2008 (CET)
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day3_large.mov Day 3] (mov file, 160 x 120, 29 min 07 sec, ~217 mb) - see content pic above, lots of blah blah plus a ingame Halo preview at the end
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day4_100.mov Day 4] (mov file, 160 x 120, 37 min 22 sec, ~277 mb) - see content pic above, very short ingame Halo preview, rest blah blah

You can also download day two, three and four in very extra low poor quality [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/ here] (first three links, 5 to 12 mb), but that's more pixel art than a video. [[User:Ssg|Ssg]] 00:10, 20 January 2008 (CET)

::Cool, look forward to watching these. --[[User:Iritscen|Iritscen]] 15:36, 5 March 2008 (CET)
::I'm going to be linking the Bungie West and East articles to the tour vids (Day 1 and Day 2), so hopefully these files will stay around for a while. Can I count on that to be the case? --[[User:Iritscen|Iritscen]] 15:01, 20 March 2008 (CET)

??? Why are you asking me that? I have no influence in the matter. [[User:Ssg|Ssg]] 00:28, 22 March 2008 (CET)
:I assumed that you uploaded them. Whose files are they? --[[User:Iritscen|Iritscen]] 15:01, 24 March 2008 (CET)

==Bluebox screenshots==
:About the BBBB screenshots you've been adding to [[BINA]]
:#It would be nice if you described how they were obtained.
:#Are you sure '''navi.TXMP''' and '''buttons.TXMP''' are appropriate?
:I'm pretty sure there is another, more plain-looking TXMP.
:Not '''g206_controls_128x64.TXMP''', but something close...
::[[User:Geyser|geyser]] 20:14, 24 September 2007 (CEST)
----
To 1:

#added WMDDs from Level0_Tools.dat to Level0_Final.dat
#replaced the dialog ID (0x108) of the [[OBD:WMDD|WMDD]] with the dialog ID of the help-window (or whatever it's called; it's the window that pops up when you press F1)

To 2:
:I'm not sure what you mean. Do you refer to the fact that some stuff in the iamges is overlapping? (If yes: Well, I never thought about that. I was too fixated on making the WMMDs visible, I guess.)

'''Edit'''

I've changed in the last part of the dat file the name psui_oniUI to psui_oniUi. After that Oni reads the psui_g206 file. The result is this:

now: http://ssg.oni2.net/subfold/bluebox/g206_306_edit_combat.jpg before: http://ssg.oni2.net/subfold/bluebox/images_org/306_edit_combat.jpg

[[User:Ssg|Ssg]] 14:59, 11 December 2007 (CET)

Short note: if there are still dialogs from tools.dat that you do not have screenshots for here you go:
http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/tools_wmdd.zip

[[User:Neo|Neo]]

Cool. Thank you. Did you managed it to "actiivate" the "Tools" files? [[User:Ssg|Ssg]] 01:19, 12 December 2007 (CET)

If by activate you mean loading tools.dat in Oni then no. (Though I converted tools.dat to PC format but Oni crashes if it finds it and I did not bother to check why). Those images were generated with my viewer.

[[User:Neo|Neo]]

Sorry for interrupting you guys a bit.
I saw the new WMMDs.. Are you going to upgrade OniSplit or OUP like Bungie's original editor tool? That would be cool. How far are you done? 
By a side note: on "dialog_character_properties.png" you can see three different shields. So, maybe the (red one) "boss shield" was editable?
:[[User:Paradox-01|Paradox-01]] 17:53, 12 December 2007 (CET)

Would it be possible for me to get a copy of Bluebox since I'm on the Mac?
[[User:EdT|EdT]]

Alloc or geyser can help, I guess. [[User:Ssg|Ssg]] 02:02, 20 January 2008 (CET)

I switched the bluebox images from the blue to the lila ones. Hope that was okay. [[User:Ssg|Ssg]] 18:07, 17 June 2008 (CEST)
:Yes, it's OK. Thanks. [[User:Neo|Neo]]

==Homing Weapons?==
Hi, Ssg. I was looking over the weapons class in the Oni binaries, and I can't find where it records that certain projectiles, like the Scram cannon's, are homing. Isn't there a bit for that? --[[User:Iritscen|Iritscen]] 19:57, 28 February 2008 (CET)
:Homing is a property of the projectile, not of the weapon class. You want to look at [[OBD:BINA/PAR3]].
::[[User:Geyser|geyser]] 23:14, 28 February 2008 (CET)
:Oh... Sorry, Iritscen, didn't see your question.
:Thanks for the answer, geyser. :-)
::[[User:Ssg|Ssg]] 23:04, 4 March 2008 (CET)
Yes, thank you. I have a neat weapon-modding idea I'd like to try. This would be my first modding attempt (we'll see if it works, I don't want to promise much, and it's a simple idea anyway). --[[User:Iritscen|Iritscen]] 15:32, 5 March 2008 (CET)

User talk:Ssg

2008-12-24T18:46:11Z

Ssg: /* Skybox images */

==Skybox images==

The [http://ssg.oni2.net/test/skyhtm/sky.htm skies from Mafia] (sorry for the bad thumbnail quality) for Oni: [http://ssg.oni2.net/test/skyhtm/skyhex.zip skyhex.zip] (~10 mb)

A hex file contains the data (images flipped, mirrored and 32bit) for the raw/sep files. Copy the data of the sky you like to the end of a raw/sep file (with a hex editor) and change the raw/sep link of the sky images in the dat file (with OniUnPacker). Every image has a size of 256x256 pixels, which is a length of 40000 in hex.

For example, if the inserted hex data starts at position 0x02355500, the links have to be changed to:

:front: 0x02355500
:left: 0x02395500
:back: 0x023D5500
:right: 0x02415500
:top: 0x02455500

[[User:Ssg|Ssg]] 12:31, 24 December 2008 (CET)
:Ssg, while those look very nice, there are simpler ways of doing things nowadays. :P We could make them into actual new skys if you wanted. [[User:Gumby|Gumby]] 19:01, 24 December 2008 (CET)
:Glad to see you again, Ssg. I'd love it if you stuck around for a while. But wow, you have a lot of catching up to do when it comes to our modding abilities :-) --[[User:Iritscen|Iritscen]] 19:25, 24 December 2008 (CET) [[User:Ssg|Ssg]] 19:46, 24 December 2008 (CET)

What do you mean by "make them into actual new skys"? Put them into AE? Change them? [[User:Ssg|Ssg]] 19:25, 24 December 2008 (CET)
:Using Onisplit\AE framework, make a new ONSK. [[User:Gumby|Gumby]] 19:33, 24 December 2008 (CET)

@Gumby: Does Onisplit/AE mirror and flip the images and change them into 32 bit automatically?

@Iritscen: I wasn't really away. I've been following the things roughly going on at the Oni Central forum and here. So I'm not that much lost. :-) [[User:Ssg|Ssg]] 19:46, 24 December 2008 (CET)

==Bungie TV from Macworld 2000==

I found some old Bungie TV videos from the Macworld 2000 on the net today.

Here's a [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/btv%20pamphlet/Inside.jpg pic with the content] of the vids (~300 kb)

*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/bungie_tour_100.mov Day 1] (mov file, 160 x 120, 5 min 33 sec, ~29 mb) - contains only the Bungie East tour; the rest was never part of the file (see [http://web.archive.org/web/20000817095745/www.bungie.com/btv/archive/ here]; look at the filename)
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day2_big.mov Day 2] (mov file, 160 x 120, 38 min 30 sec, ~182 mb) - best vid, trip to Bungie West (Oni headquarters) plus Steve Abeyta shows some disarm moves
*:If anyone just wants to see the short bit of in-game footage (which is supposed to show the disarm moves but inadvertently demoes the working multiplayer they'd end up cutting), I clipped it out and uploaded it [http://iritscen.oni2.net/movies/Steve%20demoes%20netplay.mov here]. --[[User:Iritscen|Iritscen]] 19:33, 24 December 2008 (CET)
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day3_large.mov Day 3] (mov file, 160 x 120, 29 min 07 sec, ~217 mb) - see content pic above, lots of blah blah plus a ingame Halo preview at the end
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day4_100.mov Day 4] (mov file, 160 x 120, 37 min 22 sec, ~277 mb) - see content pic above, very short ingame Halo preview, rest blah blah

You can also download day two, three and four in very extra low poor quality [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/ here] (first three links, 5 to 12 mb), but that's more pixel art than a video. [[User:Ssg|Ssg]] 00:10, 20 January 2008 (CET)

::Cool, look forward to watching these. --[[User:Iritscen|Iritscen]] 15:36, 5 March 2008 (CET)
::I'm going to be linking the Bungie West and East articles to the tour vids (Day 1 and Day 2), so hopefully these files will stay around for a while. Can I count on that to be the case? --[[User:Iritscen|Iritscen]] 15:01, 20 March 2008 (CET)

??? Why are you asking me that? I have no influence in the matter. [[User:Ssg|Ssg]] 00:28, 22 March 2008 (CET)
:I assumed that you uploaded them. Whose files are they? --[[User:Iritscen|Iritscen]] 15:01, 24 March 2008 (CET)

==Bluebox screenshots==
:About the BBBB screenshots you've been adding to [[BINA]]
:#It would be nice if you described how they were obtained.
:#Are you sure '''navi.TXMP''' and '''buttons.TXMP''' are appropriate?
:I'm pretty sure there is another, more plain-looking TXMP.
:Not '''g206_controls_128x64.TXMP''', but something close...
::[[User:Geyser|geyser]] 20:14, 24 September 2007 (CEST)
----
To 1:

#added WMDDs from Level0_Tools.dat to Level0_Final.dat
#replaced the dialog ID (0x108) of the [[OBD:WMDD|WMDD]] with the dialog ID of the help-window (or whatever it's called; it's the window that pops up when you press F1)

To 2:
:I'm not sure what you mean. Do you refer to the fact that some stuff in the iamges is overlapping? (If yes: Well, I never thought about that. I was too fixated on making the WMMDs visible, I guess.)

'''Edit'''

I've changed in the last part of the dat file the name psui_oniUI to psui_oniUi. After that Oni reads the psui_g206 file. The result is this:

now: http://ssg.oni2.net/subfold/bluebox/g206_306_edit_combat.jpg before: http://ssg.oni2.net/subfold/bluebox/images_org/306_edit_combat.jpg

[[User:Ssg|Ssg]] 14:59, 11 December 2007 (CET)

Short note: if there are still dialogs from tools.dat that you do not have screenshots for here you go:
http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/tools_wmdd.zip

[[User:Neo|Neo]]

Cool. Thank you. Did you managed it to "actiivate" the "Tools" files? [[User:Ssg|Ssg]] 01:19, 12 December 2007 (CET)

If by activate you mean loading tools.dat in Oni then no. (Though I converted tools.dat to PC format but Oni crashes if it finds it and I did not bother to check why). Those images were generated with my viewer.

[[User:Neo|Neo]]

Sorry for interrupting you guys a bit.
I saw the new WMMDs.. Are you going to upgrade OniSplit or OUP like Bungie's original editor tool? That would be cool. How far are you done? 
By a side note: on "dialog_character_properties.png" you can see three different shields. So, maybe the (red one) "boss shield" was editable?
:[[User:Paradox-01|Paradox-01]] 17:53, 12 December 2007 (CET)

Would it be possible for me to get a copy of Bluebox since I'm on the Mac?
[[User:EdT|EdT]]

Alloc or geyser can help, I guess. [[User:Ssg|Ssg]] 02:02, 20 January 2008 (CET)

I switched the bluebox images from the blue to the lila ones. Hope that was okay. [[User:Ssg|Ssg]] 18:07, 17 June 2008 (CEST)
:Yes, it's OK. Thanks. [[User:Neo|Neo]]

==Homing Weapons?==
Hi, Ssg. I was looking over the weapons class in the Oni binaries, and I can't find where it records that certain projectiles, like the Scram cannon's, are homing. Isn't there a bit for that? --[[User:Iritscen|Iritscen]] 19:57, 28 February 2008 (CET)
:Homing is a property of the projectile, not of the weapon class. You want to look at [[OBD:BINA/PAR3]].
::[[User:Geyser|geyser]] 23:14, 28 February 2008 (CET)
:Oh... Sorry, Iritscen, didn't see your question.
:Thanks for the answer, geyser. :-)
::[[User:Ssg|Ssg]] 23:04, 4 March 2008 (CET)
Yes, thank you. I have a neat weapon-modding idea I'd like to try. This would be my first modding attempt (we'll see if it works, I don't want to promise much, and it's a simple idea anyway). --[[User:Iritscen|Iritscen]] 15:32, 5 March 2008 (CET)

User talk:Ssg

2008-12-24T18:25:23Z

Ssg: /* Skybox imgages */

==Skybox images==

The [http://ssg.oni2.net/test/skyhtm/sky.htm skies from Mafia] (sorry for the bad thumbnail quality) for Oni: [http://ssg.oni2.net/test/skyhtm/skyhex.zip skyhex.zip] (~10 mb)

A hex file contains the data (images flipped, mirrored and 32bit) for the raw/sep files. Copy the data of the sky you like to the end of a raw/sep file (with a hex editor) and change the raw/sep link of the sky images in the dat file (with OniUnPacker). Every image has a size of 256x256 pixels, which is a length of 40000 in hex.

For example, if the inserted hex data starts at position 0x02355500, the links have to be changed to:

:front: 0x02355500
:left: 0x02395500
:back: 0x023D5500
:right: 0x02415500
:top: 0x02455500

[[User:Ssg|Ssg]] 12:31, 24 December 2008 (CET)
:Ssg, while those look very nice, there are simpler ways of doing things nowadays. :P We could make them into actual new skys if you wanted. [[User:Gumby|Gumby]] 19:01, 24 December 2008 (CET)
:Glad to see you again, Ssg. I'd love it if you stuck around for a while. But wow, you have a lot of catching up to do when it comes to our modding abilities :-) --[[User:Iritscen|Iritscen]] 19:25, 24 December 2008 (CET)

What do you mean by "make them into actual new skys"? Put them into AE? Change them? [[User:Ssg|Ssg]] 19:25, 24 December 2008 (CET)

==Bungie TV from Macworld 2000==

I found some old Bungie TV videos from the Macworld 2000 on the net today.

Here's a [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/btv%20pamphlet/Inside.jpg pic with the content] of the vids (~300 kb)

*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/bungie_tour_100.mov Day 1] (mov file, 160 x 120, 5 min 33 sec, ~29 mb) - contains only the Bungie East tour; the rest was never part of the file (see [http://web.archive.org/web/20000817095745/www.bungie.com/btv/archive/ here]; look at the filename)
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day2_big.mov Day 2] (mov file, 160 x 120, 38 min 30 sec, ~182 mb) - best vid, trip to Bungie West (Oni headquarters) plus Steve Abeyta shows some disarm moves
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day3_large.mov Day 3] (mov file, 160 x 120, 29 min 07 sec, ~217 mb) - see content pic above, lots of blah blah plus a ingame Halo preview at the end
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day4_100.mov Day 4] (mov file, 160 x 120, 37 min 22 sec, ~277 mb) - see content pic above, very short ingame Halo preview, rest blah blah

You can also download day two, three and four in very extra low poor quality [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/ here] (first three links, 5 to 12 mb), but that's more pixel art than a video. [[User:Ssg|Ssg]] 00:10, 20 January 2008 (CET)

::Cool, look forward to watching these. --[[User:Iritscen|Iritscen]] 15:36, 5 March 2008 (CET)
::I'm going to be linking the Bungie West and East articles to the tour vids (Day 1 and Day 2), so hopefully these files will stay around for a while. Can I count on that to be the case? --[[User:Iritscen|Iritscen]] 15:01, 20 March 2008 (CET)

??? Why are you asking me that? I have no influence in the matter. [[User:Ssg|Ssg]] 00:28, 22 March 2008 (CET)
:I assumed that you uploaded them. Whose files are they? --[[User:Iritscen|Iritscen]] 15:01, 24 March 2008 (CET)

==Bluebox screenshots==
:About the BBBB screenshots you've been adding to [[BINA]]
:#It would be nice if you described how they were obtained.
:#Are you sure '''navi.TXMP''' and '''buttons.TXMP''' are appropriate?
:I'm pretty sure there is another, more plain-looking TXMP.
:Not '''g206_controls_128x64.TXMP''', but something close...
::[[User:Geyser|geyser]] 20:14, 24 September 2007 (CEST)
----
To 1:

#added WMDDs from Level0_Tools.dat to Level0_Final.dat
#replaced the dialog ID (0x108) of the [[OBD:WMDD|WMDD]] with the dialog ID of the help-window (or whatever it's called; it's the window that pops up when you press F1)

To 2:
:I'm not sure what you mean. Do you refer to the fact that some stuff in the iamges is overlapping? (If yes: Well, I never thought about that. I was too fixated on making the WMMDs visible, I guess.)

'''Edit'''

I've changed in the last part of the dat file the name psui_oniUI to psui_oniUi. After that Oni reads the psui_g206 file. The result is this:

now: http://ssg.oni2.net/subfold/bluebox/g206_306_edit_combat.jpg before: http://ssg.oni2.net/subfold/bluebox/images_org/306_edit_combat.jpg

[[User:Ssg|Ssg]] 14:59, 11 December 2007 (CET)

Short note: if there are still dialogs from tools.dat that you do not have screenshots for here you go:
http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/tools_wmdd.zip

[[User:Neo|Neo]]

Cool. Thank you. Did you managed it to "actiivate" the "Tools" files? [[User:Ssg|Ssg]] 01:19, 12 December 2007 (CET)

If by activate you mean loading tools.dat in Oni then no. (Though I converted tools.dat to PC format but Oni crashes if it finds it and I did not bother to check why). Those images were generated with my viewer.

[[User:Neo|Neo]]

Sorry for interrupting you guys a bit.
I saw the new WMMDs.. Are you going to upgrade OniSplit or OUP like Bungie's original editor tool? That would be cool. How far are you done? 
By a side note: on "dialog_character_properties.png" you can see three different shields. So, maybe the (red one) "boss shield" was editable?
:[[User:Paradox-01|Paradox-01]] 17:53, 12 December 2007 (CET)

Would it be possible for me to get a copy of Bluebox since I'm on the Mac?
[[User:EdT|EdT]]

Alloc or geyser can help, I guess. [[User:Ssg|Ssg]] 02:02, 20 January 2008 (CET)

I switched the bluebox images from the blue to the lila ones. Hope that was okay. [[User:Ssg|Ssg]] 18:07, 17 June 2008 (CEST)
:Yes, it's OK. Thanks. [[User:Neo|Neo]]

==Homing Weapons?==
Hi, Ssg. I was looking over the weapons class in the Oni binaries, and I can't find where it records that certain projectiles, like the Scram cannon's, are homing. Isn't there a bit for that? --[[User:Iritscen|Iritscen]] 19:57, 28 February 2008 (CET)
:Homing is a property of the projectile, not of the weapon class. You want to look at [[OBD:BINA/PAR3]].
::[[User:Geyser|geyser]] 23:14, 28 February 2008 (CET)
:Oh... Sorry, Iritscen, didn't see your question.
:Thanks for the answer, geyser. :-)
::[[User:Ssg|Ssg]] 23:04, 4 March 2008 (CET)
Yes, thank you. I have a neat weapon-modding idea I'd like to try. This would be my first modding attempt (we'll see if it works, I don't want to promise much, and it's a simple idea anyway). --[[User:Iritscen|Iritscen]] 15:32, 5 March 2008 (CET)

OBD:BINA/OBJC/MELE

2008-12-24T11:57:10Z

Ssg: /* ONCC lookup */ spelling

{{OBD OBJC Header | type=MELE | prev=FURN | next=NEUT | name=Melee profile | align=center|onistuff=b_me}}

===General settings===
[[image:bin_r_m1.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x04 | int32 |FFFF00| 84 75 02 00 | 161156 | size of the complete melee part from this postion in bytes }}
{{OBDtr| 0x08 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x0C | int32 |00FFFF| 28 15 00 00 | 5416 | size of the following element in bytes }}
{{OBDtrBK}}
{{OBDtr| 0x00 | char[4] |FFC8C8| 45 4C 45 4D | MELE | melee }}
{{OBDtr| 0x04 | int32 |FFFFC8| 76 02 00 00 | 630 | old file ID }}
{{OBDtr| 0x08 | int32 |C8FFC8| 00 00 00 00 | 0 | unknown }}
{{OBDtr| 0x0C | float |C8FFFF| B3 F3 2A 43 | 170.951950 | x-position of unknown }}
{{OBDtr| 0x10 | float |C8FFFF| C7 0D 71 C1 | -15.065864 | y-position (height) of unknown }}
{{OBDtr| 0x14 | float |C8FFFF| CF 29 38 42 | 46.040829 | z-position of unknown }}
{{OBDtr| 0x18 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the x-axis in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the y-axis in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z-axis in degrees }}
|}

===Profile part===
{{Table}}
{{OBDth}}
{{OBDtr| 0x24 | int32 |FFC800| 09 00 00 00 | 9 | melee ID }}
{{OBDtr2|0x28 | char[64] |C800C8| NINJA_Easy | space for notes }}
{{OBDtr2|0x68 | char[64] |C87C64| ninja_easy_1 | character class name (reference to a ninja_easy_1.[[OBD:ONCC|ONCC]] file) }}
{{OBDtr| 0xA8 | int32 |B0C3D4| 64 00 00 00 | 100 | notice in percent; how often AI registeres incoming attack; without noticing it, AI will not block or dodge }}
{{OBDtr| 0xAC | int32 |B0C3D4| 64 00 00 00 | 100 | Dodge base in percent; determines how often AI tries to dodge incoming attacks }}
{{OBDtr| 0xB0 | int32 |B0C3D4| 1E 00 00 00 | 30 | Dodge extra in percent; adds extra chance to dodge incoming attack }}
{{OBDtr| 0xB4 | int32 |B0C3D4| 05 00 00 00 | 5 | Dodge damage amount; amount of damage dealt to character (or incoming in one strong attack) for Dodge extra activation }}
{{OBDtr| 0xB8 | int32 |B0C3D4| 0F 00 00 00 | 15 | 1 vs 1 blocking skill in percent; specifies how often AI blocks incoming attack when blocking one enemy }}
{{OBDtr| 0xBC | int32 |B0C3D4| 14 00 00 00 | 20 | Group blocking skill in percent; looks like amount of possibility that AI will try to block attacks incoming from more enemies }}
{{OBDtr| 0xC0 | float |E7CEA5| 00 00 00 40 | 2.000000 | unknown; always the same ("not blocked"?) }}
{{OBDtr| 0xC4 | float |E7CEA5| 33 33 33 3F | 0.700000 | unknown ("must change stance"?) }}
{{OBDtr| 0xC8 | float |E7CEA5| 00 00 C0 3F | 1.500000 | unknown ("blocked but unblockable"?) }}
{{OBDtr| 0xCC | float |E7CEA5| 9A 99 99 3F | 1.200000 | unknown; always the same ("blocked but has stagger"?) }}
{{OBDtr| 0xD0 | float |E7CEA5| 33 33 33 3F | 0.700000 | unknown; always the same ("blocked but has blockstun"?) }}
{{OBDtr| 0xD4 | float |E7CEA5| 00 00 00 3F | 0.500000 | unknown; always the same ("blocked"?) }}
{{OBDtr| 0xD8 | float |E7CEA5| 00 00 00 40 | 2.000000 | throw danger; still unknown but it has something to do with probability of being thrown; when set very high, AI2 with this MELE is almost unthrowable }}
{{OBDtr| 0xDC | int16 |FFDDDD| 3C 00 | 60 | unknown; always the same }}
{{OBDtr| 0xDE | int16 |FFDDDD| 5A 00 | 90 | unknown }}
{{OBDtr| 0xE0 | int32 |64AAAA| 1A 00 00 00 | 26 | number of attack techniques }}
{{OBDtr| 0xE4 | int32 |64AAAA| 06 00 00 00 | 6 | number of evade/dodge techniques }}
{{OBDtr| 0xE8 | int32 |64AAAA| 07 00 00 00 | 7 | number of maneuver/position techniques (sum of all techniques <nowiki>=</nowiki> amount of elements of the technique part}}
{{OBDtr| 0xEC | int32 |64AAAA| 6D 00 00 00 | 109 | number of moves (amount of elements of the move part) }}
|}

;Techniques
:They are listed right after the profile's header. Their number is specified in the header, and their size is 88 bytes each.
;Moves
:They are listed right after the techniques. Their number is specified in the header, and their size is 16 bytes each.

===Technique part===
[[image:bin_r_m2.gif]]

{{Table}}
{{OBDth}}
{{OBDtrBK|1=First element (grey outline)}}
{{OBDtr2|0x00 | char[64] |EBEBEB| Spinning Suplex | space for notes (technique's name) }}
{{OBDtr| 0x40 | bitset32 |8C8CCC| 00 00 00 00 | 0 | flags; see below }}
{{OBDtr| 0x44 | int32 |FF00C8| 50 00 00 00 | 80 | weight; techniques with higher weight are prefered by engine, if more techniques that can be used at one moment; have same weight, engine calls them in order as they are listed in MELE }}
{{OBDtr| 0x48 | int32 |F0F096| 0A 00 00 00 | 10 | unknown }}
{{OBDtr| 0x4C | int32 |00C864| 58 02 00 00 | 600 | repeat delay in frames; after technique is used, it is ignored by engine for this time interval }}
{{OBDtr| 0x50 | int32 |00C8FF| 02 00 00 00 | 2 | number of moves used by this technique }}
{{OBDtr| 0x54 | int32 |C80040| 57 00 00 00 | 87 | position of the first move for this technique in the move part }}
|}

;Technique flags:
*00 - unknown;
*01 - Interruptible; execution of moves in this technique is interrupted (technique is taken by engine as finished) when enemy is outside range, which specified by [[OBD:BINA/OBJC/MELE/MoveList/Position|position]] move (which has to be first in the series of moves; it is the third parameter of the position moves ) or by [[OBD:BINA/OBJC/MELE/MoveList/Maneuver|maneuver]] move (again the third parameter).
*02 - unknown; maybe "Generous dir", it seems that AI2 can turn around while attacking with technique that has this flag (or correct distance if it is a maneuver). So basically, it maybe turns on homing ^_-.
--[[User:Loser|Loser]] 08:39, 22 July 2007 (CEST)

:For everybody's convenience, I've grouped the techniques with the 0x40 field set to 1 [[OBD:BINA/OBJC/MELE/Technique0x40#Bit 0x01|HERE]].
::[[User:Geyser|geyser]] 00:00, 20 November 2006 (CET)
;0x40 set to 2
:This is true for the following techniques :
:*Furies :
:**Body Surf Front
:**Running Kick
:**Running Punch
:*Ninjas :
:**Lightning Stomp
:*Strikers :
:**Jump Kick
:**Running_Kick
:**Running_Punch
:*Tankers :
:**Circle Left
:**Circle Right
:**Run/Dive-Left
:**Run/Dive-Right
:**Run/Drop Kick
:**Run/Jump Kick
:**Run/Jumpkick Back
:**Run/Jumpkick Left
:**Run/Jumpkick Right
:**Slide
:For an exhaustive listing (complete with actual classes), see [[OBD:BINA/OBJC/MELE/Technique0x40#Bit 0x02|HERE]].
:That has to be either "Fearless" or "Generous Dir" (whatever that means).
:"Somebody better investigate soon." ^^
::[[User:Geyser|geyser]] 00:00, 20 November 2006 (CET)

===Move part===
[[image:bin_r_m3.gif]]

{{Table}}
{{OBDth}}
{{OBDtrBK|1=First element (grey outline)}}
{{OBDtr| 0x00 | int32hb |FFCD96| 04 00 00 20 | 4, 32 | move id, move type

the move id belongs to the move type; [[OBD:BINA/OBJC/MELE/MoveList|these move IDs are possible]]

the move type comes as a high byte; the following types are possible (values in dec):

:00 - attack
:16 - position
:32 - maneuver
:48 - evade
:64 - throw

}}
{{OBDtr| 0x04 | float |FF80C0| CD CC 4C 3F | 0.800000 | move parameter 1 (in this case, "min" : something like the minimum duration of the "Pause") }}
{{OBDtr| 0x08 | float |D0C0AF| 00 00 00 00 | 0 | move parameter 2 (in this case, none : "Pause" only takes one parameter) }}
{{OBDtr| 0x0C | float |EEDDFF| 00 00 00 00 | 0 | move parameter 3 (in this case, none : "Pause" only takes one parameter) }}
|}

;Move types
:00 - Attack, struct array starts at 0x140A88 in the English EXE
:16 - Position, struct array starts at 0x1435B0 in the English EXE
:32 - Maneuver, struct array starts at 0x143AB0 in the English EXE
:48 - Evade, struct array starts at 0x143E30 in the English EXE
:64 - Throw, struct array starts at 0x144370 in the English EXE

===Notes===
:There are 45 melee profiles.

====ONCC lookup====
:It seems that typing different ONCC model names here allows the melee profile to use some "trademark" moves:
*all ninjas (easy, med, hard) and super_ninja_1 ONCCs allow p_p_k_k_k_k combo
:'''edit:''' ninja easy doesn't use the p_p_k_k_k_k combo. Where did you get this from? [[User:Ssg|Ssg]] 12:55, 24 December 2008 (CET)
*konoko_generic and all red (fury) classes allow p_p_k combo, kick/kick back/run kick behind/run kick throws, k_k_kfw combo
*all tanker classes allow kick/kick back/run kick behind/run kick throws
*muro and mutant_muro classes allow p_p_p_p combo.
If you know something else, feel free to complete it. The question about this "trademark" moves is: is it specified in the ONCC or somewhere else ???

====All profiles in order of appearance in the collection====
{{Table}}
|- ALIGN=CENTER BGCOLOR="#E9E9E9"
! 1 || 2 || 3 || 4 || 5
|-
|[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Easy]]||Security_Guard||TCTF_Lite||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Easy]]||COMGUY
|-
|[[OBD:BINA/OBJC/MELE/THUG|THUG_Air]]||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Medium]]||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Hard]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Easy2]]||BLACKOPS_Lite
|-
|BLACKOPS_Swat||TCTF_Swat||[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Easy]]||MADBOMBER||NINJABOT_Train1
|-
|RED_Easy||[[OBD:BINA/OBJC/MELE/TANKER|SNIPER]]||RED_Medium||KONOKO||BARABAS Rsrch D
|-
|BARABAS TCTF D||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Medium2]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Hard2]]||MURO_Dream||MURO_Final
|-
|MURO_Mutant||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Super]]||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Medium]]||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Hard]]||RED_Hard
|-
|[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Medium]]||[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Hard]]||GRIFFIN||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Mini]]||COP Male
|-
|COP Female||[[OBD:BINA/OBJC/MELE/THUG|THUG_Mfg]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Neuro]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Pow]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Wh]]
|-
|NINJABOT_Train2||[[OBD:BINA/OBJC/MELE/NINJA|NINJABOT_PowPlant]] ||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Easy]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Medium]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Hard]]
|- ALIGN=CENTER BGCOLOR="#E9E9E9"
! 41 || 42 || 43 || 44 || 45
|}

====All profiles sorted by ID====

The IDs start at 0 and increase by 1 for every next profile with the exception of the last 3, the IDs of which are 55, 56, 57 (instead of 42, 43, 44)

{{Table}}
|- ALIGN=CENTER BGCOLOR="#E9E9E9"
! 0 || 1 || 2 || 3 || 4
|-
|Security_Guard||TCTF_Lite||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Easy]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Air]]||COMGUY
|-
|[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Medium]]||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Hard]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Easy]]||RED_Easy||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Easy]]
|-
|[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Medium]]||BLACKOPS_Lite||BLACKOPS_Swat||TCTF_Swat||[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Easy]]
|-
|[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Hard]]||RED_Medium||MADBOMBER||NINJABOT_Train1||[[OBD:BINA/OBJC/MELE/TANKER|SNIPER]]
|-
|[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Medium]]||[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Hard]]||KONOKO||BARABAS Rsrch D||RED_Hard
|-
|BARABAS TCTF D||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Medium]]||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Hard]]||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Super]]||MURO_Dream
|-
|MURO_Final||MURO_Mutant||GRIFFIN||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Mini]]||COP Male
|-
|COP Female||[[OBD:BINA/OBJC/MELE/THUG|THUG_Mfg]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Neuro]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Pow]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Wh]]
|-
|NINJABOT_Train2||[[OBD:BINA/OBJC/MELE/NINJA|NINJABOT_PowPlant]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Easy2]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Medium2]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Hard2]]
|- ALIGN=CENTER BGCOLOR="#E9E9E9"
! 40 || 41 || 55 || 56 || 57
|}

==Bluebox screenshot==
http://ssg.oni2.net/subfold/bluebox/images/308_edit_melee.png

{{OBD OBJC Footer | type=MELE | prev=FURN | next=NEUT | name=Melee profile}}

OBD:BINA/OBJC/MELE

2008-12-24T11:55:25Z

Ssg: /* ONCC lookup */

{{OBD OBJC Header | type=MELE | prev=FURN | next=NEUT | name=Melee profile | align=center|onistuff=b_me}}

===General settings===
[[image:bin_r_m1.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x04 | int32 |FFFF00| 84 75 02 00 | 161156 | size of the complete melee part from this postion in bytes }}
{{OBDtr| 0x08 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x0C | int32 |00FFFF| 28 15 00 00 | 5416 | size of the following element in bytes }}
{{OBDtrBK}}
{{OBDtr| 0x00 | char[4] |FFC8C8| 45 4C 45 4D | MELE | melee }}
{{OBDtr| 0x04 | int32 |FFFFC8| 76 02 00 00 | 630 | old file ID }}
{{OBDtr| 0x08 | int32 |C8FFC8| 00 00 00 00 | 0 | unknown }}
{{OBDtr| 0x0C | float |C8FFFF| B3 F3 2A 43 | 170.951950 | x-position of unknown }}
{{OBDtr| 0x10 | float |C8FFFF| C7 0D 71 C1 | -15.065864 | y-position (height) of unknown }}
{{OBDtr| 0x14 | float |C8FFFF| CF 29 38 42 | 46.040829 | z-position of unknown }}
{{OBDtr| 0x18 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the x-axis in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the y-axis in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z-axis in degrees }}
|}

===Profile part===
{{Table}}
{{OBDth}}
{{OBDtr| 0x24 | int32 |FFC800| 09 00 00 00 | 9 | melee ID }}
{{OBDtr2|0x28 | char[64] |C800C8| NINJA_Easy | space for notes }}
{{OBDtr2|0x68 | char[64] |C87C64| ninja_easy_1 | character class name (reference to a ninja_easy_1.[[OBD:ONCC|ONCC]] file) }}
{{OBDtr| 0xA8 | int32 |B0C3D4| 64 00 00 00 | 100 | notice in percent; how often AI registeres incoming attack; without noticing it, AI will not block or dodge }}
{{OBDtr| 0xAC | int32 |B0C3D4| 64 00 00 00 | 100 | Dodge base in percent; determines how often AI tries to dodge incoming attacks }}
{{OBDtr| 0xB0 | int32 |B0C3D4| 1E 00 00 00 | 30 | Dodge extra in percent; adds extra chance to dodge incoming attack }}
{{OBDtr| 0xB4 | int32 |B0C3D4| 05 00 00 00 | 5 | Dodge damage amount; amount of damage dealt to character (or incoming in one strong attack) for Dodge extra activation }}
{{OBDtr| 0xB8 | int32 |B0C3D4| 0F 00 00 00 | 15 | 1 vs 1 blocking skill in percent; specifies how often AI blocks incoming attack when blocking one enemy }}
{{OBDtr| 0xBC | int32 |B0C3D4| 14 00 00 00 | 20 | Group blocking skill in percent; looks like amount of possibility that AI will try to block attacks incoming from more enemies }}
{{OBDtr| 0xC0 | float |E7CEA5| 00 00 00 40 | 2.000000 | unknown; always the same ("not blocked"?) }}
{{OBDtr| 0xC4 | float |E7CEA5| 33 33 33 3F | 0.700000 | unknown ("must change stance"?) }}
{{OBDtr| 0xC8 | float |E7CEA5| 00 00 C0 3F | 1.500000 | unknown ("blocked but unblockable"?) }}
{{OBDtr| 0xCC | float |E7CEA5| 9A 99 99 3F | 1.200000 | unknown; always the same ("blocked but has stagger"?) }}
{{OBDtr| 0xD0 | float |E7CEA5| 33 33 33 3F | 0.700000 | unknown; always the same ("blocked but has blockstun"?) }}
{{OBDtr| 0xD4 | float |E7CEA5| 00 00 00 3F | 0.500000 | unknown; always the same ("blocked"?) }}
{{OBDtr| 0xD8 | float |E7CEA5| 00 00 00 40 | 2.000000 | throw danger; still unknown but it has something to do with probability of being thrown; when set very high, AI2 with this MELE is almost unthrowable }}
{{OBDtr| 0xDC | int16 |FFDDDD| 3C 00 | 60 | unknown; always the same }}
{{OBDtr| 0xDE | int16 |FFDDDD| 5A 00 | 90 | unknown }}
{{OBDtr| 0xE0 | int32 |64AAAA| 1A 00 00 00 | 26 | number of attack techniques }}
{{OBDtr| 0xE4 | int32 |64AAAA| 06 00 00 00 | 6 | number of evade/dodge techniques }}
{{OBDtr| 0xE8 | int32 |64AAAA| 07 00 00 00 | 7 | number of maneuver/position techniques (sum of all techniques <nowiki>=</nowiki> amount of elements of the technique part}}
{{OBDtr| 0xEC | int32 |64AAAA| 6D 00 00 00 | 109 | number of moves (amount of elements of the move part) }}
|}

;Techniques
:They are listed right after the profile's header. Their number is specified in the header, and their size is 88 bytes each.
;Moves
:They are listed right after the techniques. Their number is specified in the header, and their size is 16 bytes each.

===Technique part===
[[image:bin_r_m2.gif]]

{{Table}}
{{OBDth}}
{{OBDtrBK|1=First element (grey outline)}}
{{OBDtr2|0x00 | char[64] |EBEBEB| Spinning Suplex | space for notes (technique's name) }}
{{OBDtr| 0x40 | bitset32 |8C8CCC| 00 00 00 00 | 0 | flags; see below }}
{{OBDtr| 0x44 | int32 |FF00C8| 50 00 00 00 | 80 | weight; techniques with higher weight are prefered by engine, if more techniques that can be used at one moment; have same weight, engine calls them in order as they are listed in MELE }}
{{OBDtr| 0x48 | int32 |F0F096| 0A 00 00 00 | 10 | unknown }}
{{OBDtr| 0x4C | int32 |00C864| 58 02 00 00 | 600 | repeat delay in frames; after technique is used, it is ignored by engine for this time interval }}
{{OBDtr| 0x50 | int32 |00C8FF| 02 00 00 00 | 2 | number of moves used by this technique }}
{{OBDtr| 0x54 | int32 |C80040| 57 00 00 00 | 87 | position of the first move for this technique in the move part }}
|}

;Technique flags:
*00 - unknown;
*01 - Interruptible; execution of moves in this technique is interrupted (technique is taken by engine as finished) when enemy is outside range, which specified by [[OBD:BINA/OBJC/MELE/MoveList/Position|position]] move (which has to be first in the series of moves; it is the third parameter of the position moves ) or by [[OBD:BINA/OBJC/MELE/MoveList/Maneuver|maneuver]] move (again the third parameter).
*02 - unknown; maybe "Generous dir", it seems that AI2 can turn around while attacking with technique that has this flag (or correct distance if it is a maneuver). So basically, it maybe turns on homing ^_-.
--[[User:Loser|Loser]] 08:39, 22 July 2007 (CEST)

:For everybody's convenience, I've grouped the techniques with the 0x40 field set to 1 [[OBD:BINA/OBJC/MELE/Technique0x40#Bit 0x01|HERE]].
::[[User:Geyser|geyser]] 00:00, 20 November 2006 (CET)
;0x40 set to 2
:This is true for the following techniques :
:*Furies :
:**Body Surf Front
:**Running Kick
:**Running Punch
:*Ninjas :
:**Lightning Stomp
:*Strikers :
:**Jump Kick
:**Running_Kick
:**Running_Punch
:*Tankers :
:**Circle Left
:**Circle Right
:**Run/Dive-Left
:**Run/Dive-Right
:**Run/Drop Kick
:**Run/Jump Kick
:**Run/Jumpkick Back
:**Run/Jumpkick Left
:**Run/Jumpkick Right
:**Slide
:For an exhaustive listing (complete with actual classes), see [[OBD:BINA/OBJC/MELE/Technique0x40#Bit 0x02|HERE]].
:That has to be either "Fearless" or "Generous Dir" (whatever that means).
:"Somebody better investigate soon." ^^
::[[User:Geyser|geyser]] 00:00, 20 November 2006 (CET)

===Move part===
[[image:bin_r_m3.gif]]

{{Table}}
{{OBDth}}
{{OBDtrBK|1=First element (grey outline)}}
{{OBDtr| 0x00 | int32hb |FFCD96| 04 00 00 20 | 4, 32 | move id, move type

the move id belongs to the move type; [[OBD:BINA/OBJC/MELE/MoveList|these move IDs are possible]]

the move type comes as a high byte; the following types are possible (values in dec):

:00 - attack
:16 - position
:32 - maneuver
:48 - evade
:64 - throw

}}
{{OBDtr| 0x04 | float |FF80C0| CD CC 4C 3F | 0.800000 | move parameter 1 (in this case, "min" : something like the minimum duration of the "Pause") }}
{{OBDtr| 0x08 | float |D0C0AF| 00 00 00 00 | 0 | move parameter 2 (in this case, none : "Pause" only takes one parameter) }}
{{OBDtr| 0x0C | float |EEDDFF| 00 00 00 00 | 0 | move parameter 3 (in this case, none : "Pause" only takes one parameter) }}
|}

;Move types
:00 - Attack, struct array starts at 0x140A88 in the English EXE
:16 - Position, struct array starts at 0x1435B0 in the English EXE
:32 - Maneuver, struct array starts at 0x143AB0 in the English EXE
:48 - Evade, struct array starts at 0x143E30 in the English EXE
:64 - Throw, struct array starts at 0x144370 in the English EXE

===Notes===
:There are 45 melee profiles.

====ONCC lookup====
:It seems that typing different ONCC model names here allows the melee profile to use some "trademark" moves:
*all ninjas (easy, med, hard) and super_ninja_1 ONCCs allow p_p_k_k_k_k combo
:'''edit:''' ninja easy doens't use the p_p_k_k_k_k combo. Where did you get this from? [[User:Ssg|Ssg]] 12:55, 24 December 2008 (CET)
*konoko_generic and all red (fury) classes allow p_p_k combo, kick/kick back/run kick behind/run kick throws, k_k_kfw combo
*all tanker classes allow kick/kick back/run kick behind/run kick throws
*muro and mutant_muro classes allow p_p_p_p combo.
If you know something else, feel free to complete it. The question about this "trademark" moves is: is it specified in the ONCC or somewhere else ???

====All profiles in order of appearance in the collection====
{{Table}}
|- ALIGN=CENTER BGCOLOR="#E9E9E9"
! 1 || 2 || 3 || 4 || 5
|-
|[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Easy]]||Security_Guard||TCTF_Lite||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Easy]]||COMGUY
|-
|[[OBD:BINA/OBJC/MELE/THUG|THUG_Air]]||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Medium]]||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Hard]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Easy2]]||BLACKOPS_Lite
|-
|BLACKOPS_Swat||TCTF_Swat||[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Easy]]||MADBOMBER||NINJABOT_Train1
|-
|RED_Easy||[[OBD:BINA/OBJC/MELE/TANKER|SNIPER]]||RED_Medium||KONOKO||BARABAS Rsrch D
|-
|BARABAS TCTF D||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Medium2]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Hard2]]||MURO_Dream||MURO_Final
|-
|MURO_Mutant||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Super]]||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Medium]]||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Hard]]||RED_Hard
|-
|[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Medium]]||[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Hard]]||GRIFFIN||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Mini]]||COP Male
|-
|COP Female||[[OBD:BINA/OBJC/MELE/THUG|THUG_Mfg]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Neuro]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Pow]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Wh]]
|-
|NINJABOT_Train2||[[OBD:BINA/OBJC/MELE/NINJA|NINJABOT_PowPlant]] ||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Easy]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Medium]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Hard]]
|- ALIGN=CENTER BGCOLOR="#E9E9E9"
! 41 || 42 || 43 || 44 || 45
|}

====All profiles sorted by ID====

The IDs start at 0 and increase by 1 for every next profile with the exception of the last 3, the IDs of which are 55, 56, 57 (instead of 42, 43, 44)

{{Table}}
|- ALIGN=CENTER BGCOLOR="#E9E9E9"
! 0 || 1 || 2 || 3 || 4
|-
|Security_Guard||TCTF_Lite||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Easy]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Air]]||COMGUY
|-
|[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Medium]]||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Hard]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Easy]]||RED_Easy||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Easy]]
|-
|[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Medium]]||BLACKOPS_Lite||BLACKOPS_Swat||TCTF_Swat||[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Easy]]
|-
|[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Hard]]||RED_Medium||MADBOMBER||NINJABOT_Train1||[[OBD:BINA/OBJC/MELE/TANKER|SNIPER]]
|-
|[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Medium]]||[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Hard]]||KONOKO||BARABAS Rsrch D||RED_Hard
|-
|BARABAS TCTF D||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Medium]]||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Hard]]||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Super]]||MURO_Dream
|-
|MURO_Final||MURO_Mutant||GRIFFIN||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Mini]]||COP Male
|-
|COP Female||[[OBD:BINA/OBJC/MELE/THUG|THUG_Mfg]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Neuro]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Pow]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Wh]]
|-
|NINJABOT_Train2||[[OBD:BINA/OBJC/MELE/NINJA|NINJABOT_PowPlant]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Easy2]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Medium2]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Hard2]]
|- ALIGN=CENTER BGCOLOR="#E9E9E9"
! 40 || 41 || 55 || 56 || 57
|}

==Bluebox screenshot==
http://ssg.oni2.net/subfold/bluebox/images/308_edit_melee.png

{{OBD OBJC Footer | type=MELE | prev=FURN | next=NEUT | name=Melee profile}}

User talk:Ssg

2008-12-24T11:31:50Z

Ssg: skybox images

==Skybox imgages==

The [http://ssg.oni2.net/test/skyhtm/sky.htm skies from Mafia] (sorry for the bad thumbnail quality) for Oni: [http://ssg.oni2.net/test/skyhtm/skyhex.zip skyhex.zip] (~10 mb)

A hex file contains the data (images flipped, mirrored and 32bit) for the raw/sep files. Copy the data of the sky you like to the end of a raw/sep file (with a hex editor) and change the raw/sep link of the sky images in the dat file (with OniUnPacker). Every image has a size of 256x256 pixels, which is a length of 40000 in hex.

For eample, if the inserted hex data starts at position 0x02355500, the links have to be changed to:

:front: 0x02355500
:left: 0x02395500
:back: 0x023D5500
:right: 0x02415500
:top: 0x02455500

[[User:Ssg|Ssg]] 12:31, 24 December 2008 (CET)

==Bungie TV from Macworld 2000==

I found some old Bungie TV videos from the Macworld 2000 on the net today.

Here's a [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/btv%20pamphlet/Inside.jpg pic with the content] of the vids (~300 kb)

*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/bungie_tour_100.mov Day 1] (mov file, 160 x 120, 5 min 33 sec, ~29 mb) - contains only the Bungie East tour; the rest was never part of the file (see [http://web.archive.org/web/20000817095745/www.bungie.com/btv/archive/ here]; look at the filename)
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day2_big.mov Day 2] (mov file, 160 x 120, 38 min 30 sec, ~182 mb) - best vid, trip to Bungie West (Oni headquarters) plus Steve Abeyta shows some disarm moves
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day3_large.mov Day 3] (mov file, 160 x 120, 29 min 07 sec, ~217 mb) - see content pic above, lots of blah blah plus a ingame Halo preview at the end
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day4_100.mov Day 4] (mov file, 160 x 120, 37 min 22 sec, ~277 mb) - see content pic above, very short ingame Halo preview, rest blah blah

You can also download day two, three and four in very extra low poor quality [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/ here] (first three links, 5 to 12 mb), but that's more pixel art than a video. [[User:Ssg|Ssg]] 00:10, 20 January 2008 (CET)

::Cool, look forward to watching these. --[[User:Iritscen|Iritscen]] 15:36, 5 March 2008 (CET)
::I'm going to be linking the Bungie West and East articles to the tour vids (Day 1 and Day 2), so hopefully these files will stay around for a while. Can I count on that to be the case? --[[User:Iritscen|Iritscen]] 15:01, 20 March 2008 (CET)

??? Why are you asking me that? I have no influence in the matter. [[User:Ssg|Ssg]] 00:28, 22 March 2008 (CET)
:I assumed that you uploaded them. Whose files are they? --[[User:Iritscen|Iritscen]] 15:01, 24 March 2008 (CET)

==Bluebox screenshots==
:About the BBBB screenshots you've been adding to [[BINA]]
:#It would be nice if you described how they were obtained.
:#Are you sure '''navi.TXMP''' and '''buttons.TXMP''' are appropriate?
:I'm pretty sure there is another, more plain-looking TXMP.
:Not '''g206_controls_128x64.TXMP''', but something close...
::[[User:Geyser|geyser]] 20:14, 24 September 2007 (CEST)
----
To 1:

#added WMDDs from Level0_Tools.dat to Level0_Final.dat
#replaced the dialog ID (0x108) of the [[OBD:WMDD|WMDD]] with the dialog ID of the help-window (or whatever it's called; it's the window that pops up when you press F1)

To 2:
:I'm not sure what you mean. Do you refer to the fact that some stuff in the iamges is overlapping? (If yes: Well, I never thought about that. I was too fixated on making the WMMDs visible, I guess.)

'''Edit'''

I've changed in the last part of the dat file the name psui_oniUI to psui_oniUi. After that Oni reads the psui_g206 file. The result is this:

now: http://ssg.oni2.net/subfold/bluebox/g206_306_edit_combat.jpg before: http://ssg.oni2.net/subfold/bluebox/images_org/306_edit_combat.jpg

[[User:Ssg|Ssg]] 14:59, 11 December 2007 (CET)

Short note: if there are still dialogs from tools.dat that you do not have screenshots for here you go:
http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/tools_wmdd.zip

[[User:Neo|Neo]]

Cool. Thank you. Did you managed it to "actiivate" the "Tools" files? [[User:Ssg|Ssg]] 01:19, 12 December 2007 (CET)

If by activate you mean loading tools.dat in Oni then no. (Though I converted tools.dat to PC format but Oni crashes if it finds it and I did not bother to check why). Those images were generated with my viewer.

[[User:Neo|Neo]]

Sorry for interrupting you guys a bit.
I saw the new WMMDs.. Are you going to upgrade OniSplit or OUP like Bungie's original editor tool? That would be cool. How far are you done? 
By a side note: on "dialog_character_properties.png" you can see three different shields. So, maybe the (red one) "boss shield" was editable?
:[[User:Paradox-01|Paradox-01]] 17:53, 12 December 2007 (CET)

Would it be possible for me to get a copy of Bluebox since I'm on the Mac?
[[User:EdT|EdT]]

Alloc or geyser can help, I guess. [[User:Ssg|Ssg]] 02:02, 20 January 2008 (CET)

I switched the bluebox images from the blue to the lila ones. Hope that was okay. [[User:Ssg|Ssg]] 18:07, 17 June 2008 (CEST)
:Yes, it's OK. Thanks. [[User:Neo|Neo]]

==Homing Weapons?==
Hi, Ssg. I was looking over the weapons class in the Oni binaries, and I can't find where it records that certain projectiles, like the Scram cannon's, are homing. Isn't there a bit for that? --[[User:Iritscen|Iritscen]] 19:57, 28 February 2008 (CET)
:Homing is a property of the projectile, not of the weapon class. You want to look at [[OBD:BINA/PAR3]].
::[[User:Geyser|geyser]] 23:14, 28 February 2008 (CET)
:Oh... Sorry, Iritscen, didn't see your question.
:Thanks for the answer, geyser. :-)
::[[User:Ssg|Ssg]] 23:04, 4 March 2008 (CET)
Yes, thank you. I have a neat weapon-modding idea I'd like to try. This would be my first modding attempt (we'll see if it works, I don't want to promise much, and it's a simple idea anyway). --[[User:Iritscen|Iritscen]] 15:32, 5 March 2008 (CET)

OBD:BINA/OBJC/CHAR

2008-07-31T15:10:12Z

Ssg: /* Dialog from level0_Tools */ changed to English images

{{OBD OBJC Header | align=center | type=CHAR | prev=WEAP | next=CMBT | name=Character}}

==File description==
===Basic setup - Apperance, weapon, position, misc spawn flags===

[[image:bin_r_ch.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x04 | int32 |FFFF00| 2C 8B 00 00 | 35628 | size of the complete collection from this postion in bytes }}
{{OBDtr| 0x08 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x0C | int32 |00FFFF| 20 02 00 00 | 544 | size of the following element in bytes }}
{{OBDtrBK}}
{{OBDtr| 0x000 | char[4] |FFC8C8| 52 41 48 43 | CHAR | character }}
{{OBDtr| 0x004 | int32 |FFFFC8| 87 19 00 00 | 6535 | old file ID }}
{{OBDtr| 0x008 | int32 |C8FFC8| 00 00 00 00 | 0 | unknwon }}
{{OBDtr| 0x00C | float |C8FFFF| A5 7D 9D 43 | 314.981597 | x-position of the character }}
{{OBDtr| 0x010 | float |C8FFFF| 00 00 D8 C1 | -27.000000 | y-position (height) of the character }}
{{OBDtr| 0x014 | float |C8FFFF| 98 09 1E 42 | 39.509368 | z-position of the character }}
{{OBDtr| 0x018 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the x-axis in degrees }}
{{OBDtr| 0x01C | float |FFC8FF| 00 00 87 43 | 270.000000 | rotation on the y-axis in degrees }}
{{OBDtr| 0x020 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z-axis in degrees }}
{{OBDtr| 0x024 | bitset32 |FFC800| 01 00 00 00 | 1, 0, 0, 0 | character options; the folowing bits are used:
:0x '''01''' 00 00 00 - player character
:0x '''02''' 00 00 00 - random skin
:0x '''04''' 00 00 00 - not prespawned
:0x '''08''' 00 00 00 - non-combatant
:0x '''10''' 00 00 00 - multi-spawnable
:0x '''20''' 00 00 00 - unknown
:0x '''40''' 00 00 00 - unkillable
:0x '''80''' 00 00 00 - superammo
:0x 00 '''01''' 00 00 - omniscient
:0x 00 '''02''' 00 00 - has LSI
:0x 00 '''04''' 00 00 - boss
:0x 00 '''08''' 00 00 - upgrade difficulty (spawns a stronger enemy if you play on medium or hard)
:0x 00 '''10''' 00 00 - no auto-drop (doesn't drop "used" shield, "used" invisibility and LSI when killed)
}}
{{OBDtr2|0x028 | char[64] |B0C3D4| konoko_generic | character class name (reference to [[OBD:ONCC|00991-konoko_generic.ONCC]]) }}
{{OBDtr2|0x068 | char[32] |E7CEA5| konoko | character name }}
{{OBDtr2|0x088 | char[64] |FFDDDD| w1_tap | weapon class name (reference to [[OBD:ONWC|03701-w1_tap.ONWC]] of level 0) }}
|}

===Script functions - Called by engine when certain things happen to a character===

{{Table}}
{{OBDth}}
{{OBDtr2|0x0C8 | char[32] |EBEBEB| unused | script function called when character is spawned }}
{{OBDtr2|0x0E8 | char[32] |8C8CCC| you_lose | script function called when character dies (health reaches 0); can work multiple times }}
{{OBDtr2|0x108 | char[32] |FF00C8| unused | script function called when character notices an enemy; works only once }}
{{OBDtr2|0x128 | char[32] |F0F096| unused | alarm function; never used in Oni, it is called when character is alarmed }}
{{OBDtr2|0x148 | char[32] |00C864| unused | script function called when character is hurt for the first time; works only once }}
{{OBDtr2|0x168 | char[32] |00C8FF| unused | script function called when character is "defeated" (health reaches 1); works only once }}
{{OBDtr2|0x188 | char[32] |C80040| unused | script function called when character runs out of ammo (reloads a weapon with the last clip/cell); works only once, and the character must have the ammo at spawn-time }}
{{OBDtr2|0x1A8 | char[32] |FFCD96| unused | nopath function, some exotic script function call ("should" be called when a character has trouble pathfinding, but isn't) }}
|}

===Less basic setup - Inventory, team, jobs, alert/pursuit===

{{Table}}
{{OBDth}}
{{OBDtr| 0x1C8 | int32 |C8C864| 00 00 00 00 | 0 | additional health (the basic health is stored in the [[OBD:ONCC|ONCC]] file of the character) }}
{{OBDtr| 0x1CC | int32 |0096C8| 00 00 00 00 | 0 | job ID; the following jobs are possible:
:0 - none
:1 - idle
:2 - guard (never used in Oni)
:3 - patrol
:4 - teambattle (never used in Oni)
}}
{{OBDtr| 0x1D0 | int16 |FF80C0| 00 00 | 0 | patrol path ID (reference to the [[OBD:BINA/OBJC/PATR|Patrol_Path.BINA]] file) }}
{{OBDtr| 0x1D2 | int16 |FF80C0| 00 00 | 0 | combat ID (reference to the [[OBD:BINA/OBJC/CMBT|Combat.BINA]] file) }}
{{OBDtr| 0x1D4 | int16 |D0C0AF| 00 00 | 0 | melee ID (reference to the [[OBD:BINA/OBJC/MELE|Melee Profile.BINA]] file) }}
{{OBDtr| 0x1D6 | int16 |D0C0AF| 00 00 | 0 | neutral ID (reference to the [[OBD:BINA/OBJC/NEUT|Neutral.BINA]] file) }}
{{OBDtr| 0x1D8 | int16 |EEDDFF| 01 00 | 1 | amount of ammo (red clips) that can be used }}
{{OBDtr| 0x1DA | int16 |EEDDFF| 00 00 | 0 | amount of ammo (red clips) that can be dropped }}
{{OBDtr| 0x1DC | int16 |C5FF8A| 00 00 | 0 | amount of energy cells (green clips) that can be used }}
{{OBDtr| 0x1DE | int16 |C5FF8A| 00 00 | 0 | amount of energy cells (green clips) that can be dropped }}
{{OBDtr| 0x1E0 | int16 |C0C0C0| 00 00 | 0 | amount of hypos that can be used }}
{{OBDtr| 0x1E2 | int16 |C0C0C0| 00 00 | 0 | amount of hypos that can be dropped }}
{{OBDtr| 0x1E4 | int16 |FF0080| 00 00 | 0 | amount of force shields that can be used }}
{{OBDtr| 0x1E6 | int16 |FF0080| 00 00 | 0 | amount of force shields that can be dropped }}
{{OBDtr| 0x1E8 | int16 |FFFFA6| 00 00 | 0 | amount of phase cloaking that can be used (60 <nowiki>=</nowiki> 1 second) }}
{{OBDtr| 0x1EA | int16 |FFFFA6| 00 00 | 0 | amount of phase cloaking that can be dropped }}

{{OBDtr| 0x1EC | int16 |71FFB8| 00 00 | 0 | unknown; always zero; used "nci"? }}
{{OBDtr| 0x1EE | int16 |71FFB8| 00 00 | 0 | unknown; always zero; dropped "nci"? }}

{{OBDtr| 0x1F0 | int32 |0000BF| 00 00 00 00 | 0 | team ID; the following teams are possible:
:0 - Konoko
:1 - TCTF
:2 - Syndicate
:3 - Neutral
:4 - SecurityGuard
:5 - RogueKonoko
:6 - Switzerland
:7 - SyndicateAccessory
}}
{{OBDtr| 0x1F4 | int32 |804040| 64 00 00 00 | 100 | ammo filling in percent }}
{{OBDtr| 0x1F8 | int32 |FF22FF| 00 00 00 00 | 0 | initial alert level; the following alert levels are possible:
:0 - lull
:1 - low
:2 - medium
:3 - high
:4 - combat
}}
{{OBDtr| 0x1FC | int32 |808080| 00 00 00 00 | 0 | minimal alert level }}
{{OBDtr| 0x200 | int32 |FFAA82| 01 00 00 00 | 1 | alert level when starting a job }}
{{OBDtr| 0x204 | int32 |00D900| 02 00 00 00 | 2 | alert level when investigating }}
{{OBDtr| 0x208 | bitset32 |CACAFF| 00 00 00 00 | 0, 0, 0, 0 | alarm groups, see below this table }}
{{OBDtr| 0x20C | int32 |F0F000| 04 00 00 00 | 4 | pursuit mode for strong awareness when alert level lull/low }}
{{OBDtr| 0x210 | int32 |E7FFCE| 01 00 00 00 | 1 | pursuit mode for weak awareness when alert level lull/low }}
{{OBDtr| 0x214 | int32 |4F7291| 04 00 00 00 | 4 | pursuit mode for strong awareness when alert level medium/high/combat }}
{{OBDtr| 0x218 | int32 |FFD6C1| 04 00 00 00 | 4 | pursuit mode for weak awareness when alert level medium/high/combat }}
{{OBDtr| 0x21C | int32 |FF5E5E| 00 00 00 00 | 0 | unknown (pm_pursue_lost?) }}
|}

;Alarm groups
:Stored as a bitset
:If bit 2^N is ON, the character will be alarmed by script command '''ai2_tripalarm(N)''' or alarm console command '''0060 NN00''' where NN is the hex for N.
:(Since the size of the alarm group field is 4 bytes, there's a maximum of 32 alarm groups, i.e. N ranges from 0 to 31)

;Pursuit modes:
:AI2 has 4 awareness modes: '''forgotten''', '''weak''', '''strong''', '''definite'''.
:Forgotten and definite are clear (either AI2 forgets about enemy or AI2 sees enemy with central vision field).
:Weak and strong are modes used when AI2 character pursues enemy. The moment AI2 char sees (with '''peripheral''' vision field) or hears enemy, it goes into pursue mode with this enemy. Strong is first, then (after timer finishes) it degrades to weak (and then to forgotten).
*At the beginning of pursuit, AI2 chars tries to move as close to the point where enemy stood (or center of dangerous sound was) as possible. AI2 character has limited '''pursuit distance''', specified in [[CMBT]] profile it is using. If source of danger (or interest?) is too far away, AI2 char moves only so far where it can move from its current location according to the pursuit distance. For movement, pursuit mode 2 (GoTo) is used. Whole pursuit behavior depends on pathfinding, no "vectors of movement" or how should I call those green lines.
:"Green lines": ai2_showpaths=1, when in MELE mode or dodging, AI2 has some short green line pointing in the direction of movement instead of regular brown pathfinding line.
*Then AI2 performs pursuit mode 4 (Look) for some specified time (which is probably hardcoded in this pursuit mode's procedure). Awareness of enemy is strong. See my note for info about possible bug in peripheral vision contact.
*After this initial Look mode ends, AI2 char starts its '''strong awareness''' pursuit mode, choice depends on alert level.
*When timer for strong awareness fades, AI2 goes to weak awareness and starts using its '''weak awareness''' pursuit mode, choice depends on alert level again. Possible pursuit modes are listed below.
NOTE

This all was tested with sound awareness as peripheral awareness seems to be broken and always calls pursuit mode '''Look''' with '''infinite timer''' (so AI2 stucks and stares in a direction forever, that is why you can escape gunner sometimes, then you peek from corner and he just stands and stares, no action).

/NOTE

;Useable values for pursuit modes:
*0 - No mode; looks like engine uses Look mode as "safe ring" from crash; maybe 0 is GoTo + Look ("starter" of AI2 pursuit mode, see above)???
*1 - '''Forget'''; works like "ai2_forget" command
*2 - '''GoTo'''; used by engine when char has to move to another place while in pursuit mode, if you set it in CHAR, it does nothing.
*3 - '''Wait'''; AI2 char keeps looking at the point where it looked before this mode started, waiting ^_^
*4 - '''Look'''; AI2 char keeps rotating whole body, looking around
*5 - '''Move'''; no effect when this value is set in CHAR, I don't have idea for what this is good if we have GoTo already. Maybe move randomly ???
*6 - '''Hunt'''; not implemented in Oni (as a few of us noticed, eh, EdT? ^_^). Looks like it is here (it has name, it does not make Oni crash etc), but main procedure is probably unfinished or what (or wrong linked)
*7 - '''Glance'''; AI2 char stands and rotates only as if player pressed "look" key ("v" by default) and tried to move the mouse. So no full-body turning, only "twisting" from extreme angle to extreme angle.
:speculations:
*9 - Find alarm?; this is interesting, becuase when you make AI2 char alarmed via "ai2_tripalarm" (or by alarm console), report will say that reason of high alert of AI2 is ''unknown: 9''. Maybe this mode means "find player, who is alarming whole place by doing his business here?"

Exe rip which contains (probably) all modes is in [[CMBT]], se near the end of the page.

--[[User:Loser|Loser]] 14:45, 31 July 2008 (CEST)

==Dialog from level0_Tools==

http://ssg.oni2.net/subfold/bluebox/images/215_character_properties2.png

Also available is the following dialog, which is redundant of [[CMBT]] and apparently predates both CHAR and [[AISA]]:


http://ssg.oni2.net/subfold/bluebox/images/211_character_properties.png

{{OBD OBJC Footer | type=CHAR | prev=WEAP | next=CMBT | name=Character}}

OBD:WMDD

2008-07-27T17:58:55Z

Ssg:

{{OBD_File_Header|align=center|type=WMDD|prev=WMCL|next=WMM_|name=WM (Window Menu) Dialog Data|family=Global}}

The image below shows the beginning of the file with the settings of the main window.

[[image:wmdd_all.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x000 | res_id |FF0000| 01 CE 09 00 | 1541 | 01541-dialog_mainmenu.WMDD }}
{{OBDtr| 0x004 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr2| 0x008| char[256]|00FF00| Main Menu | title }}
{{OBDtr| 0x108 | int16 |00FFFF| 96 00 | 150 | ID (looked up from code) }}
{{OBDtr| 0x10A | int16 |00FFFF| 00 00 | 0 | not used; always 0 }}
{{OBDtr| 0x10C | int32 |FF00FF| 01 00 00 00 | 0x01 | state; the following values are used:
:0x'''01''' 00 00 00 - visible
:0x'''02''' 00 00 00 - disabled
:0x'''04''' 00 00 00 - unknown
}}
{{OBDtr| 0x110 | int32 |FF8000| 00 00 01 00 | 0x00010000 | style; the following values are used:
:0x'''01''' 00 00 00 - draw default background
:0x'''02''' 00 00 00 - resizable window (has a thick border)
:0x'''04''' 00 00 00 - show title bar
:0x'''08''' 00 00 00 - show title (title bar required)
:0x'''10''' 00 00 00 - show close button (title bar required)
:0x'''20''' 00 00 00 - show restore button (title bar required)
:0x'''40''' 00 00 00 - show minimize button (title bar required)
:0x00 00 '''01''' 00 - center window on screen (x, y coordinates are ignore when this style is used)
}}
{{OBDtr| 0x114 | int16 |804080| 00 00 | 0 | x coordinate of the window }}
{{OBDtr| 0x116 | int16 |804080| 00 00 | 0 | y coordinate of the window }}
{{OBDtr| 0x118 | int16 |804040| 80 02 | 640 | width of the window }}
{{OBDtr| 0x11A | int16 |804040| E0 01 | 480 | height of the window }}
{{OBDtr| 0x11C | int32 |408080| 06 00 00 00 | 6 | array size }}
{{OBDtrBK}}
{{OBDtr2| 0x000 | char[256]|FFC8C8| New Game | text or:
:*TXMB/TXMP/PSpc name if class is picture
:*WMM_ name if class is popup menu
}}
{{OBDtr| 0x100 | int16 |FFFFC8| 04 00 | 4 | class; the following window classes exist in Oni (values in dec):
:1 - desktop (not used in dialogs)
:3 - box (<nowiki>=</nowiki> groupbox)
:4 - button
:5 - checkbox
:6 - dialog (not used in dialogs)
:7 - edit field
:8 - listbox
:9 - menu bar (not used in dialogs)
:10 - menu (not used in dialogs)
:11 - picture ([[OBD:TXMB|TXMB]], [[OBD:TXMP|TXMP]] or [[OBD:PSpc|PSpc]])
:12 - popup menu (<nowiki>=</nowiki> pulldown menu <nowiki>=</nowiki> drop-down menu) ([[OBD:WMM_|WMM_]])
:13 - progress bar
:14 - radio button
:16 - scrollbar (not used in dialogs)
:17 - slider
:20 - text
}}
{{OBDtr| 0x102 | int16 |C8FFC8| 64 00 | 100 | ID (looked up from code) }}
{{OBDtr| 0x104 | int32 |C8FFFF| 01 00 00 00 | 0x01 | state; the following values are used:
:0x'''01''' 00 00 00 - visible
:0x'''02''' 00 00 00 - disabled
:0x'''04''' 00 00 00 - unknown
}}
{{OBDtr| 0x108 | int32 |FFC800| 00 00 03 00 | 0x030000 | style; the dialog styles above (at 0x110) and the following control specific styles can be used here:
if box:
:0x00 00 '''02''' 00 - draw text background
:0x00 00 '''04''' 00 - draw text

if button:
:0x00 00 '''01''' 00 - draw button
:0x00 00 '''02''' 00 - draw button text
:0x00 00 '''08''' 00 - toggle button (like the ones used "in game" for help, diary etc.)
:0x00 00 '''10''' 00 - default button (the button that coresponds to the Enter key)

if checkbox:
:0x00 00 '''01''' 00 - draw label

if radiobutton:
:0x00 00 '''01''' 00 - draw label

if edit field:
:0x00 00 '''01''' 00 - number only

if listbox:
:0x00 00 '''01''' 00 - draw scrollbar
:0x00 00 '''02''' 00 - alphabetical order
:0x00 00 '''04''' 00 - unselectable
:0x00 00 '''08''' 00 - contains text (without this it contains only "custom" data)
:0x00 00 '''10''' 00 - owner draw (the owner window will draw the list items)
:0x00 00 '''20''' 00 - draw file/folder icons

if picture:
:0x00 00 '''02''' 00 - ignore the picture name; the displayed picture is set at runtime

if popup menu
:0x00 00 '''01''' 00 - use menu width; doesn't work
:0x00 00 '''02''' 00 - ignore the menu name; the menu is set at runtime

if text field:
:0x00 00 '''02''' 00 - horizontal text align <nowiki>=</nowiki> center
:0x00 00 '''04''' 00 - horizontal text align <nowiki>=</nowiki> right
:0x00 00 '''10''' 00 - vertical text align <nowiki>=</nowiki> center
:0x00 00 '''80''' 00 - owner draw (hides text)

}}
{{OBDtr| 0x10C | int16 |C87C64| 5E 01 | 350 | x coordinate (relative to the top left corner of the window) }}
{{OBDtr| 0x10E | int16 |C87C64| E6 00 | 230 | y coordinate (relative to the top left corner of the window) }}
{{OBDtr| 0x110 | int16 |B0C3D4| B4 00 | 180 | width }}
{{OBDtr| 0x112 | int16 |B0C3D4| 28 00 | 40 | height }}
{{OBDtr| 0x114 | link32 |E7CEA5| 01 02 00 00 | 2 | link to 00002-Tahoma.[[OBD:TSFF|TSFF]]}}
{{OBDtr| 0x118 | int32 |FFDDDD| 01 00 00 00 | 1 | font option; the following options are possible:
:0 - normal font
:1 - '''bold''' font
:2 - ''italic'' font
}}
{{OBDtr| 0x11C | color32 |64AAAA| 00 7F FF FF | 0, 127, 255; 255 | font color (blue, green, red); transparency }}
{{OBDtr| 0x120 | int8 |EBEBEB| 01 | 1 | ignored }}
{{OBDtr| 0x121 | int8 |EBEBEB| 00 | 0 | ignored }}
{{OBDtr| 0x122 | int16 |8C8CCC| 0A 00 | 10 | font size (height) }}
|}

;Dialog ID
:Since Oni looks dialogs up by ID, changing them arbitrarily is not recommended.
;Visible flag (0x10C)
:A hidden/disabled window can't be activated from Oni, so if you hide the main menu, you'll have to shut down Oni from the Task Manager (or make it Blam ^^).
:With "-noswitch", you can switch to other applications whenever the mouse pointer is visible in Oni.
;Item IDs (for this example)
:64 - "new game" window
:65 - "load game" window
:66 - "options" window
:67 - "quit" window
:68 - "resume" window

{{OBD_File_Footer|align=center|type=WMDD|prev=WMCL|next=WMM_|name=WM (Window Menu) Dialog Data|family=Global}}

OBD talk:WMDD

2008-07-27T17:56:44Z

Ssg: I got it.

there's is no such thing as "show background" for text fields, that 01 flag is in fact the "draw default background" window style

So why did you delete it? It changes the style as well: Left image "player name" with 0x00001100. Right image with 0x01001100.

http://ssg.oni2.net/subfold/bluebox/images/132_setup_player.png http://ssg.oni2.net/oni/tb.png

[[User:Ssg|Ssg]] 13:29, 25 July 2008 (CEST)

Because it's not control specific:

style; dialog styles and the following control specific styles can be used here:

It's already listed under dialog styles. If you want to add this flag to text field then you need to add it to picture fields too for example. And you also need to add the "resizable window" flag and pretty much all the other dialog styles to all the controls.

[[User:Neo|Neo]]

style; dialog styles and the following control specific styles can be used here:

Ahhhhh... "dialog styles" refers to the "sytle"-section above. Now I got it. Thanks. [[User:Ssg|Ssg]] 19:56, 27 July 2008 (CEST)

OBD talk:WMDD

2008-07-25T11:29:46Z

Ssg: forgot the 4 tildes for the sig

OBD talk:WMDD

2008-07-25T11:27:09Z

Ssg: New page: there's is no such thing as "show background" for text fields, that 01 flag is in fact the "draw default background" window style So why did you delete it? It changes the style as well...

OBD:WMDD

2008-07-23T10:52:12Z

Ssg: I'm not happy with "done"; @0x108: added more used values. why popup-menu? why values byte-swapped? --> confusing. why deleted last entry in text field (show background)?

{{OBD_File_Header|align=center|type=WMDD|prev=WMCL|next=WMM_|name=WM (Window Menu) Dialog Data|family=Global}}

The image below shows the beginning of the file with the settings of the main window.

[[image:wmdd_all.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x000 | res_id |FF0000| 01 CE 09 00 | 1541 | 01541-dialog_mainmenu.WMDD }}
{{OBDtr| 0x004 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr2| 0x008| char[256]|00FF00| Main Menu | title }}
{{OBDtr| 0x108 | int16 |00FFFF| 96 00 | 150 | ID (looked up from code) }}
{{OBDtr| 0x10A | int16 |00FFFF| 00 00 | 0 | not used; always 0 }}
{{OBDtr| 0x10C | int32 |FF00FF| 01 00 00 00 | 0x01 | state; the following values are used:
:0x'''01''' 00 00 00 - visible
:0x'''02''' 00 00 00 - disabled
:0x'''04''' 00 00 00 - unknown
}}
{{OBDtr| 0x110 | int32 |FF8000| 00 00 01 00 | 0x00010000 | style; the following values are used:
:0x'''01''' 00 00 00 - draw default background
:0x'''02''' 00 00 00 - resizable window (has a thick border)
:0x'''04''' 00 00 00 - show title bar
:0x'''08''' 00 00 00 - show title (title bar required)
:0x'''10''' 00 00 00 - show close button (title bar required)
:0x'''20''' 00 00 00 - show restore button (title bar required)
:0x'''40''' 00 00 00 - show minimize button (title bar required)
:0x00 00 '''01''' 00 - center window on screen (x, y coordinates are ignore when this style is used)
}}
{{OBDtr| 0x114 | int16 |804080| 00 00 | 0 | x coordinate of the window }}
{{OBDtr| 0x116 | int16 |804080| 00 00 | 0 | y coordinate of the window }}
{{OBDtr| 0x118 | int16 |804040| 80 02 | 640 | width of the window }}
{{OBDtr| 0x11A | int16 |804040| E0 01 | 480 | height of the window }}
{{OBDtr| 0x11C | int32 |408080| 06 00 00 00 | 6 | array size }}
{{OBDtrBK}}
{{OBDtr2| 0x000 | char[256]|FFC8C8| New Game | text or:
:*TXMB/TXMP/PSpc name if class is picture
:*WMM_ name if class is popup menu
}}
{{OBDtr| 0x100 | int16 |FFFFC8| 04 00 | 4 | class; the following window classes exist in Oni (values in dec):
:1 - desktop (not used in dialogs)
:3 - groupbox
:4 - button
:5 - checkbox
:6 - dialog (not used in dialogs)
:7 - edit field
:8 - listbox
:9 - menu bar (not used in dialogs)
:10 - menu (not used in dialogs)
:11 - picture ([[OBD:TXMB|TXMB]], [[OBD:TXMP|TXMP]] or [[OBD:PSpc|PSpc]])
:12 - popup menu (<nowiki>=</nowiki> pulldown menu <nowiki>=</nowiki> drop-down menu) ([[OBD:WMM_|WMM_]])
:13 - progress bar
:14 - radio button
:16 - scrollbar (not used in dialogs)
:17 - slider
:20 - text
}}
{{OBDtr| 0x102 | int16 |C8FFC8| 64 00 | 100 | ID (looked up from code) }}
{{OBDtr| 0x104 | int32 |C8FFFF| 01 00 00 00 | 0x01 | state; the following values are used:
:0x'''01''' 00 00 00 - visible
:0x'''02''' 00 00 00 - disabled
:0x'''04''' 00 00 00 - unknown
}}
{{OBDtr| 0x108 | int32 |FFC800| 00 00 03 00 | 0x030000 | style; dialog styles and the following control specific styles can be used here:
if box:
:0x00 '''02''' 00 00 - draw text background
:0x00 '''04''' 00 00 - draw text

if button:
:0x00 '''01''' 00 00 - draw button
:0x00 '''02''' 00 00 - draw button text
:0x00 '''08''' 00 00 - unknown
:0x00 '''10''' 00 00 - default button (the button that coresponds to the Enter key)

if checkbox:
:0x00 '''01''' 00 00 - draw label

if radiobutton:
:0x00 '''01''' 00 00 - draw label

if edit field:
:0x00 '''01''' 00 00 - number only

if listbox:
:0x00 '''01''' 00 00 - draw scrollbar
:0x00 '''02''' 00 00 - alphabetical order
:0x00 '''04''' 00 00 - unselectable
:0x00 '''08''' 00 00 - draw items
:0x00 '''10''' 00 00 - owner draw (the owner window will draw the list items)
:0x00 '''20''' 00 00 - unknown

if picture:
:0x00 '''02''' 00 00 - ignore the picture name; the displayed picture is set at runtime

:if popup menu
:0x00 '''01''' 00 00 - use menu width; doesn't work
:0x00 '''02''' 00 00 - ignore the menu name; the menu is set at runtime

if text field:
:0x00 '''02''' 00 00 - horizontal text align <nowiki>=</nowiki> center
:0x00 '''04''' 00 00 - horizontal text align <nowiki>=</nowiki> right
:0x00 '''10''' 00 00 - vertical text align <nowiki>=</nowiki> center
:0x00 '''80''' 00 00 - owner draw (hides text)
:0x00 00 00 '''01''' - show background

}}
{{OBDtr| 0x10C | int16 |C87C64| 5E 01 | 350 | x coordinate (relative to the top left corner of the window) }}
{{OBDtr| 0x10E | int16 |C87C64| E6 00 | 230 | y coordinate (relative to the top left corner of the window) }}
{{OBDtr| 0x110 | int16 |B0C3D4| B4 00 | 180 | width }}
{{OBDtr| 0x112 | int16 |B0C3D4| 28 00 | 40 | height }}
{{OBDtr| 0x114 | link32 |E7CEA5| 01 02 00 00 | 2 | link to 00002-Tahoma.[[OBD:TSFF|TSFF]]}}
{{OBDtr| 0x118 | int32 |FFDDDD| 01 00 00 00 | 1 | font option; the following options are possible:
:0 - normal font
:1 - '''bold''' font
:2 - ''italic'' font
}}
{{OBDtr| 0x11C | color32 |64AAAA| 00 7F FF FF | 0, 127, 255; 255 | font color (blue, green, red); transparency }}
{{OBDtr| 0x120 | int8 |EBEBEB| 01 | 1 | ignored }}
{{OBDtr| 0x121 | int8 |EBEBEB| 00 | 0 | ignored }}
{{OBDtr| 0x122 | int16 |8C8CCC| 0A 00 | 10 | font size (height) }}
|}

;Dialog ID
:Since Oni looks dialogs up by ID, changing them arbitrarily is not recommended.
;Visible flag (0x10C)
:A hidden/disabled window can't be activated from Oni, so if you hide the main menu, you'll have to shut down Oni from the Task Manager (or make it Blam ^^).
:With "-noswitch", you can switch to other applications whenever the mouse pointer is visible in Oni.
;Item IDs (for this example)
:64 - "new game" window
:65 - "load game" window
:66 - "options" window
:67 - "quit" window
:68 - "resume" window

{{OBD_File_Footer|align=center|type=WMDD|prev=WMCL|next=WMM_|name=WM (Window Menu) Dialog Data|family=Global}}

OBD:WMDD

2008-07-02T09:39:55Z

Ssg: 0x108: listbox

{{OBD_File_Header|align=center|type=WMDD|prev=WMCL|next=WMM_|name=WM (Window Menu) Dialog Data|family=Global}}

The image below shows the beginning of the file with the settings of the main window.

[[image:wmdd_all.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x000 | res_id |FF0000| 01 CE 09 00 | 1541 | 01541-dialog_mainmenu.WMDD }}
{{OBDtr| 0x004 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr2| 0x008| char[256]|00FF00| Main Menu | title }}
{{OBDtr| 0x108 | int16 |00FFFF| 96 00 | 150 | ID (looked up from code) }}
{{OBDtr| 0x10A | int16 |00FFFF| 00 00 | 0 | not used; always 0 }}
{{OBDtr| 0x10C | int32 |FF00FF| 01 00 00 00 | 0x01 | state; the following values are used:
:0x'''01''' 00 00 00 - visible
:0x'''02''' 00 00 00 - disabled
:0x'''04''' 00 00 00 - unknown
}}
{{OBDtr| 0x110 | int32 |FF8000| 00 00 01 00 | 0x00010000 | style; the following values are used:
:0x'''01''' 00 00 00 - thin light blue border around the window (somehow transparency is involved too; if you use the g206 ui and press the exit botton of the main window, a window with no background appears)
:0x'''02''' 00 00 00 - thick light lila border around the window
:0x'''04''' 00 00 00 - light lila title bar
:0x'''08''' 00 00 00 - title (title bar required)
:0x'''10''' 00 00 00 - close button visible (title bar required)
:0x'''20''' 00 00 00 - restore button visible (title bar required)
:0x'''40''' 00 00 00 - minimize button visible (title bar required)
:0x00 00 '''01''' 00 - center window on screen (x, y coordinates are ignore when this style is used)
}}
{{OBDtr| 0x114 | int16 |804080| 00 00 | 0 | x coordinate of the window }}
{{OBDtr| 0x116 | int16 |804080| 00 00 | 0 | y coordinate of the window }}
{{OBDtr| 0x118 | int16 |804040| 80 02 | 640 | width of the window }}
{{OBDtr| 0x11A | int16 |804040| E0 01 | 480 | height of the window }}
{{OBDtr| 0x11C | int32 |408080| 06 00 00 00 | 6 | array size }}
{{OBDtrBK}}
{{OBDtr2| 0x000 | char[256]|FFC8C8| New Game | text (or TXMB/TXMP name if class is 11) }}
{{OBDtr| 0x100 | int16 |FFFFC8| 04 00 | 4 | class; the following window classes exist in Oni (values in dec):
:1 - desktop (not used in dialogs)
:3 - title
:4 - button
:5 - checkbox
:6 - dialog (not used in dialogs)
:7 - edit field
:8 - listbox
:9 - menu bar (not used in dialogs)
:10 - menu (not used in dialogs)
:11 - background picture ([[OBD:TXMB|TXMB]]) or texture ([[OBD:TXMP|TXMP]])
:12 - pull-down menu
:13 - progress bar
:14 - radio button
:16 - scrollbar (not used in dialogs)
:17 - slider
:20 - text field
}}
{{OBDtr| 0x102 | int16 |C8FFC8| 64 00 | 100 | ID (looked up from code) }}
{{OBDtr| 0x104 | int32 |C8FFFF| 01 00 00 00 | 0x01 | state; the following values are used:
:0x'''01''' 00 00 00 - visible
:0x'''02''' 00 00 00 - disabled
:0x'''04''' 00 00 00 - unknown
}}
{{OBDtr| 0x108 | int32 |FFC800| 00 00 03 00 | 0x030000 | style; some known values:
:0x00 00 '''01''' 00 - show button/scrollbar/checkbox text
:0x00 00 '''02''' 00 - show button text
:0x00 00 '''04''' 00 - show title
:0x00 00 '''08''' 00 - show listbox entries
---

if button:
:0x00 00 '''01''' 00 - show button
:0x00 00 '''02''' 00 - show button text
:0x00 00 '''10''' 00 - no change in color (visible with the g206 ui, button is single-colored instead of multi-colored)

if listbox:
:0x00 00 '''01''' 00 - show scrollbar
:0x00 00 '''02''' 00 - alphabetical order
:0x00 00 '''04''' 00 - unselectable
:0x00 00 '''08''' 00 - show entries

if text field:
:0x'''01''' 00 00 00 - show background and border
:0x00 00 '''02''' 00 - horizontal text align <nowiki>=</nowiki> center
:0x00 00 '''04''' 00 - horizontal text align <nowiki>=</nowiki> right
:0x00 00 '''10''' 00 - vertical text align <nowiki>=</nowiki> center
:0x00 00 '''80''' 00 - hide text
---
:'''NOTE''': Possible values also include the ones available for the dialog style field. Style values above 0xffff have class specific meaning so the above list is not necesarilly complete (and correct).
}}
{{OBDtr| 0x10C | int16 |C87C64| 5E 01 | 350 | x coordinate (relative to the top left corner of the window) }}
{{OBDtr| 0x10E | int16 |C87C64| E6 00 | 230 | y coordinate (relative to the top left corner of the window) }}
{{OBDtr| 0x110 | int16 |B0C3D4| B4 00 | 180 | width }}
{{OBDtr| 0x112 | int16 |B0C3D4| 28 00 | 40 | height }}
{{OBDtr| 0x114 | link32 |E7CEA5| 01 02 00 00 | 2 | link to 00002-Tahoma.[[OBD:TSFF|TSFF]]}}
{{OBDtr| 0x118 | int32 |FFDDDD| 01 00 00 00 | 1 | font option; the following options are possible:
:0 - normal font
:1 - '''bold''' font
:2 - ''italic'' font
}}
{{OBDtr| 0x11C | color32 |64AAAA| 00 7F FF FF | 0, 127, 255; 255 | font color (blue, green, red); transparency }}
{{OBDtr| 0x120 | int8 |EBEBEB| 01 | 1 | ignored }}
{{OBDtr| 0x121 | int8 |EBEBEB| 00 | 0 | ignored }}
{{OBDtr| 0x122 | int16 |8C8CCC| 0A 00 | 10 | font size (height) }}
|}

;Dialog ID
:Since Oni looks dialogs up by ID, changing them arbitrarily is not recommended.
;Visible flag (0x10C)
:A hidden/disabled window can't be activated from Oni, so if you hide the main menu, you'll have to shut down Oni from the Task Manager (or make it Blam ^^).
:With "-noswitch", you can switch to other applications whenever the mouse pointer is visible in Oni.
;Item IDs (for this example)
:64 - "new game" window
:65 - "load game" window
:66 - "options" window
:67 - "quit" window
:68 - "resume" window

{{OBD_File_Footer|align=center|type=WMDD|prev=WMCL|next=WMM_|name=WM (Window Menu) Dialog Data|family=Global}}

OBD:BINA/OBJC

2008-06-30T12:47:24Z

Ssg: /* OBJC types */ added a link to the folder with all bluebox images

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

;Example file
:[[OBD:BINA/OBJC/PWRU|CJBOPowerUp.BINA]] from dunno where (level 3, probably)
;Offsets
:Offsets are given with respect to RAW part start.

http://ssg.oni2.net/images/bin_r_pu.gif

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

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

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FFC8C8| 52 52 57 50 | PWRU | object type }}
{{OBDtr| 0x04 | int32 |FFFFC8| AC 1C 00 00 | 7340 | object ID }}
{{OBDtr| 0x08 | |C8FFC8| 00 00 00 00 | 0x00 | object flags; used values:
:0x'''01''' 00 00 00 - unknown
:0x'''08''' 00 00 00 - unknown }}
{{OBDtr| 0x0C | float |C8FFFF| E8 92 77 44 | 990.254 | x-position }}
{{OBDtr| 0x10 | float |C8FFFF| 00 00 D8 41 | 27.000000 | y-position }}
{{OBDtr| 0x14 | float |C8FFFF| 71 DD 98 43 | 305.73 | z-position }}
{{OBDtr| 0x18 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the x-axis in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the y-axis in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z-axis in degrees }}
|}

----
----
==OBJC types==
A given collection can only hold objects of a specific type, which can be :
{|
|
{|{{OBDtable}}
|-bgcolor=#E9E9E9
!Type!!Long name!!Filename
|-
|[[OBD:BINA/OBJC/CHAR|CHAR]]||Character||CJBO'''Character'''.BINA
|-
|[[OBD:BINA/OBJC/CMBT|CMBT]]||Combat profile||CJBO'''Combat'''.BINA
|-
|[[OBD:BINA/OBJC/CONS|CONS]]||Console||CJBO'''Console'''.BINA
|-
|[[OBD:BINA/OBJC/DOOR|DOOR]]||Door||CJBO'''Door'''.BINA
|-
|[[OBD:BINA/OBJC/FLAG|FLAG]]||Flag||CJBO'''Flag'''.BINA
|-
|[[OBD:BINA/OBJC/FURN|FURN]]||Furniture||CJBO'''Furniture'''.BINA
|-
|[[OBD:BINA/OBJC/MELE|MELE]]||Melee profile||CJBO'''Melee Profile'''.BINA
|-
|[[OBD:BINA/OBJC/NEUT|NEUT]]||Neutral behaviour||CJBO'''Neutral'''.BINA
|-
|[[OBD:BINA/OBJC/PART|PART]]||Particle||CJBO'''Particle'''.BINA
|-
|[[OBD:BINA/OBJC/PATR|PATR]]||Patrol path||CJBO'''Patrol_Path'''.BINA
|-
|[[OBD:BINA/OBJC/PWRU|PWRU]]||Powerup||CJBO'''PowerUp'''.BINA
|-
|[[OBD:BINA/OBJC/SNDG|SNDG]]||Sound Group||CJBO'''Sound'''.BINA
|-
|[[OBD:BINA/OBJC/TRGV|TRGV]]||Trigger Volume||CJBO'''Trigger_Volume'''.BINA
|-
|[[OBD:BINA/OBJC/TRIG|TRIG]]||Trigger||CJBO'''Trigger'''.BINA
|-
|[[OBD:BINA/OBJC/TURR|TURR]]||Turret||CJBO'''Turret'''.BINA
|-
|[[OBD:BINA/OBJC/WEAP|WEAP]]||Weapon||CJBO'''Weapon'''.BINA
|}
|}
;Blue Box Beta "revelations"
:A German Mac Beta version was released as part of a compilation of old Mac games.
:The version contained extra [[OBD:WMDD|WMDD]] files, part of Oni's developer GUI.
:Supposedly it allowed developers to edit OBJC files while running the game.
:Those menus provide additional information about the structure of a few OBJC types.
:*It's available as screenshots on the respective pages.
:*Folder with all bluebox images: http://ssg.oni2.net/subfold/bluebox/images/

{{OBD BINA Footer|prev=TMBD|type=OBJC|next=ONIE|name=Object Collection}}

OBD:BINA/OBJC/CMBT

2008-06-30T12:44:03Z

Ssg: /* Dialogs from level0_Tools */ bluebox jpg to png

{{OBD OBJC Header | align=center | type=CMBT | prev=CHAR | next=CONS | name=Combat Profile}}

==File description==
===General settings===
[[image:bin_r_cb.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | 4CC |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x04 | int32 |FFFF00| B0 0D 00 00 | 35628 | length (in bytes) to end of OBJC from here }}
{{OBDtr| 0x08 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x0C | int32 |00FFFF| B4 00 00 00 | 180 | size of the following object in bytes }}
{{OBDtrBK|First object (black outline)}}
{{OBDtr| 0x00 | 4CC |FFC8C8| 54 42 4D 43 | TBMC | combat }}
{{OBDtr| 0x04 | int32 |FFFFC8| 70 01 00 00 | 368 | object ID }}
{{OBDtr| 0x08 | int32 |C8FFC8| 00 00 00 00 | 0 | object flags }}
{{OBDtr| 0x0C | float |C8FFFF| 13 55 5F C3 |-223.332321| x-position of handle }}
{{OBDtr| 0x10 | float |C8FFFF| D4 A8 8E 41 | 17.832436 | y-position of handle }}
{{OBDtr| 0x14 | float |C8FFFF| C3 05 E9 C2 |-116.511253| z-position of handle }}
{{OBDtr| 0x18 | float |FFC8FF| 00 00 00 00 | 0.000000 | x-rotation of handle in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| 00 00 00 00 | 0.000000 | y-rotation of handle in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 00 00 00 00 | 0.000000 | z-rotation of handle in degrees }}
{{OBDtr2|0x24 | char[64] |FFC800| Stand_and_Fire | name }}
{{OBDtr| 0x64 | int32 |C800C8| 00 00 00 00 | 0 | combat ID (looked up from [[OBD:BINA/OBJC/CHAR|Character.BINA]]) }}
|}

===Behavior part===
{{Table}}
{{OBDth}}
{{OBDtr| 0x68 | int32 |C87C64| 02 00 00 00 | 2 | long range behavior; the following values are possible (values in dec):

:00 - none
:01 - stare
:02 - hold and fire
:03 - firing charge
:04 - melee
:05 - Barabbas shoot
:06 - Barabbas advance
:07 - Barabbas melee
:08 - Superninja fireball
:09 - Superninja advance
:10 - Superninja melee
:11 - run for alarm (not used in Oni)
:12 - Mutant Muro melee
:13 - Muro thunderbolt
}}
{{OBDtr| 0x6C | int32 |B0C3D4| 02 00 00 00 | 2 | medium range behavior; values as above }}
{{OBDtr| 0x70 | int32 |E7CEA5| 02 00 00 00 | 2 | short range behavior (hand to hand behavior); values as above }}
{{OBDtr| 0x74 | int32 |FFDDDD| 02 00 00 00 | 2 | medium retreat behavior; values as above }}
{{OBDtr| 0x78 | int32 |64AAAA| 02 00 00 00 | 2 | long retreat behavior; values as above }}
|}

===Combat part===
{{Table}}
{{OBDth}}
{{OBDtr| 0x7C | float |EBEBEB| 00 00 F0 42 | 120.000000| long/medium range; distance of the border between long and medium ranges; you can make it visible with the script command *ai2_showcombatranges <nowiki>=</nowiki> 1* }}
{{OBDtr| 0x80 | int32 |8C8CCC| 01 00 00 00 | 1 | melee override; see below; the following values are possible:

:0 - nothing
:1 - if punched
:2 - (canceled)
:3 - short Crange
:4 - medium range
:5 - always melee
}}
{{OBDtr| 0x84 | int32 |FF00C8| 00 00 00 00 | 0 | if no gun; behavior of AI which doesn't have a gun in its hand ( but can have it holstered); the following values are possible:

:0 - melee
:1 - retreat
:2 - run to alarm
}}
{{OBDtr| 0x88 | float |F0F096| 00 00 20 42 | 40.000000 | medium/short range; distance of the border between medium and short ranges; you can make it visible with the script command *ai2_showcombatranges <nowiki>=</nowiki> 1* }}
{{OBDtr| 0x8C | float |00C864| 00 00 48 43 | 200.000000| pursuit distance; see below for info }}
|}

===Non-combatant part===
{{Table}}
{{OBDth}}
{{OBDtr| 0x90 | int32 |00C8FF| 58 02 00 00 | 600 | panic hurt (time in 1/60 seconds) }}
{{OBDtr| 0x94 | int32 |00C8FF| 84 03 00 00 | 900 | panic gunfire (time in 1/60 seconds) }}
{{OBDtr| 0x98 | int32 |00C8FF| 58 02 00 00 | 600 | panic melee (time in 1/60 seconds) }}
{{OBDtr| 0x9C | int32 |00C8FF| B0 04 00 00 | 1200 | panic sight (time in 1/60 seconds) }}
|}

===Alarm part===
{{Table}}
{{OBDth}}
{{OBDtr| 0xA0 | float |C80040| 00 00 96 43 | 300.000000| alarm search distance }}
{{OBDtr| 0xA4 | float |C80040| 00 00 A0 42 | 80.000000 | alarm enemy ignore distance }}
{{OBDtr| 0xA8 | float |FFCD96| 00 00 00 00 | 0.000000 | alarm enemy attack distance }}
{{OBDtr| 0xAC | int32 |C8C864| 1E 00 00 00 | 30 | alarm damage threshold }}
{{OBDtr| 0xB0 | int32 |C8C864| 68 01 00 00 | 360 | alarm fight timer }}
|}

These settings affect the behavior of an AI that's running for a console (e.g., script command *ai2_doalarm*).
;alarm search distance
:area around AI, where engine checks if there is some console with 40 bit (see [[OBD:BINA/OBJC/CONS|CONS]]).
;Alarm enemy ignore distance
:This one specifies an "ignore range". Enemies which are inside this range are not ignored but AI doesn't attack them.
;Alarm enemy attack distance
:Zero by default.
:This one specifies an "attack range" around an AI running for an alarm. When there is an enemy inside, AI stops running for the console and attack the enemy (if AI knows about him, of course)
:Nevertheless AI still keeps in mind that it should run for the console. So when there is no enemy inside this range and fight timer runs out, AI resumes running to the specified console.
;Fight timer
:When AI, which is running for the console, is engaged in a fight and enemy manages to disappear (either by phase-cloak or simply by hiding behind some corner), AI tries to chase him or looks for him. Alarm timer specifies how long should AI chase/look for the enemy. For chasing, timer starts when the enemy is outside *Alarm enemy attack distance*. Of course when the enemy escapes even from *Alarm enemy ignore range*, AI abandons him automatically.
;Alarm damage threshold
:Specifies how long AI, which is running for the console, remembers someone hurt it. Until this timer runs away, AI doesn't tend to use console. It only stays in fight stance near console, ready to fight. If someone hurts AI which is running for the console, then escapes and then tries to hurt it again while this timer isn't finished yet, AI remembers him and initatively attacks him the moment he steps inside *Alarm enemy attack distance*.
----
Whole alarm logic can be tripped by:
* *ai2_doalarm* command (suitable for geyser's rugby)
* *run for alarm* (0b) behavior, altough this behavior alone does NOTHING, it just turns on *alarm search distance*. If there is no console with 40 bit in reach, AI stands still and just stares.
* *run to alarm* if no gun event ( only when AI is unarmed ), again it turns on *alarm search distance*, but this time AI can do normal actions (attack, hunt) if there is no 40 bit console within reach.
* ???Find alarm??? pm_pursue action, still unknown
----
==Further info==
===About pursuit distance===
First of all, pursuit is NOT when you have been seen and now running away. If you do that, AI is in *combat* mode, not *pursue* mode. You are pursued only when you have NOT been seen by central vision field (see [[OBD:ONCC|ONCC]]). So if some enemy does sound that touches AI's sound detection sphere, or when some enemy interferes with AI's peripheral vision field, AI goes into pursue mode with him. In this mode AI uses special behavior for investigating. According to the EXE, possibilities are (dunno if it is in proper order, it is raw EXE rip):
:*Find Alarm
:*Keep Looking
:*Return To Job
:*Glance
:*Hunt - not implemented in Oni (accidentaly I have read error message in Manplant a few months ago saying that)
:*Move
:*Look
:*Wait
:*GoTo
:*Forget
What AI does while in pursuit mode depends on the last values in [[OBD:BINA/OBJC/CHAR|CHAR]]. But it is still unknown how it works. It also depends on the alert level of an AI (lull, low, med, high, combat). Pursuit mode lasts from the moment of the disturbing action until AI goes to forgotten hostilethreat for enemy action, or after one investigation loop for friendlythreat action (see [[OBD:ONCC|ONCC]] for info about ...threats).

So...what is the pursuit distance??? It is distance that is AI allowed to travel from its original location for *pursue* purposes. Set it high and AI can run through whole level if it hears or spots something. Set it low and AI will do just a few steps in a direction of disturbing action.
----
===About melee override===
First something about minimal shooting distance.It is in the [[OBD:ONWC|ONWC]] and determines closest range for AI to fire that weapon. If enemy goes closer, AI stops shooting and tends to run away until it reahes minimal shooting distance again.
Now if you set this minimal shooting distance higher than it is originally (for example try 200) you can have some fun chasing AIs as they are running away from you.

Point is that if you set melee override to some range (for example 03 - short range) and then try it, you will see that the moment you are closer than minimal shooting distance AND you are in range which enables it (short range in this example) AI will switch to melee mode instead of running away.

So you can make short range for example 200 units big and set min.shoot.dist. 100 units big and have melee override 03 -short range. AI will then shoot at you even if you are inside short range, but the moment you ecounter min.shoot.dist. it switches to melee.

How it switches back to weapon when you run away back into min.shoot.dist. is not clear. So far it happens automatically after some time. Where is timer for that??? Let us know, if you know....

--[[User:Loser|Loser]] 09:03, 29 July 2007 (CEST)

Try using ai2_report on a character, I noticed a timer next to the mode or something of that sort - Gumby :)

==Dialogs from level0_Tools==

http://ssg.oni2.net/subfold/bluebox/images/307_choose_combat.png

http://ssg.oni2.net/subfold/bluebox/images/306_edit_combat.png

{{OBD OBJC Footer | type=CMBT | prev=CHAR | next=CONS | name=Combat profile}}

OBD:BINA/SABD

2008-06-30T12:42:15Z

Ssg: Answer to SABD.

{{OBD BINA Header|align=center|prev=PAR3|type=SABD|next=TMBD|name=Sound Animations Binary Data|onistuff=b_sa}}
----
----

[[Image:Bin_r_sa.gif]]

{{Table}}
{{OBDth}}
{{OBDtr|0x00|char[4] |FF0000 | 44 42 41 53 | SABD | sound animations binary data }}
{{OBDtr|0x04|in32 |FFFF00 | 3C 0C 00 00 | 3132 | 3132 bytes is the length of the following sound animations part from this position }}

{{OBDtrBK}}
{{OBDtr|0x00|char[4] |FFC8C8 | 53 41 46 54 | TFAS | totoro family animation sound? }}
{{OBDtr|0x04|int32 |FFFFC8 | 04 00 00 00 | 4 | 4 bytes is the length of the following family part }}
{{OBDtr|0x08| |C8FFC8 | 06 00 00 00 | | unknown }}

{{OBDtrBK}}
{{OBDtr|0x00|char[4] |C8FFFF | 53 41 56 54 | TVAS | totoro variant animation sound? }}
{{OBDtr|0x04|int32 |FFC8FF | 20 00 00 00 | 32 | 32 bytes is the length of the following variant part }}
{{OBDtr|0x08|char[32]|FFC800 | | "Any" | character variant name; reference to 01666-any.[[OBD:ONCV|ONCV]] }}

{{OBDtrBK}}
{{OBDtr|0x00|char[4] |C800C8 | 53 41 53 41 | ASAS | unknown }}
{{OBDtr|0x04|int32 |C87C64 | 84 00 00 00 | 132 | 32 bytes is the length of the following ASAS part }}
{{OBDtr|0x08|int32 |B0C3D4 | 00 00 00 00 | 0 | start frame of the sound }}
{{OBDtr|0x0C|char[32]|E7CEA5 | | "Any" | modifier }}
{{OBDtr|0x2C|char[32]|FFDDDD | | "Animation" | animation type }}
{{OBDtr|0x4C|char[32]|64AAAA | | "KONOKOacid"| animation name; reference to 02465-KONOKOacid.[[OBD:TRAM|TRAM]] }}
{{OBDtr|0x6C|char[32]|EBEBEB | | "splash_bubbles"| sound name; reference to 08984-splash_bubbles.imp. }}[[OBD:OSBD|OSBD]]
|}

;NOTE
:Only the following 3 files have ASAS parts (sound assignments) in Oni:
:*'''DBASAny.BINA'''
:*'''DBASKonoko.BINA'''
:*'''DBASShinatama_Zombie.BINA'''
:All the others have only a '''TFAS''' part and a '''TVAS''' part.
:The example above is for '''DBASAny.BINA'''.
;SABD
:Could it be "Sound Assignment" rather than "Sound Animation"?
:: That name (sound animation) is somewhere in the exe file, IIRC. [[User:Ssg|Ssg]] 14:42, 30 June 2008 (CEST)

----
----
{{OBD BINA Footer|align=right|prev=PAR3|type=SABD|next=TMBD|name=Sound Animations Binary Data|onistuff=b_sa}}

OBD:BINA/ONIE

2008-06-30T12:39:30Z

Ssg: /* Dialogs from level0_Tools */ bluebox jpg to png

{{OBD BINA Header|align=center|prev=OBJC|type=ONIE|next=PAR3|name=Oni Impact Effects|onistuff=b_ie}}

----
==General table==
[[Image:Bin_r_i1.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | int32 |FF0000| 45 49 4E 4F | ONIE | Oni impact effects }}
{{OBDtr| 0x04 | int32 |FFFF00| B8 B7 00 00 | 47032 | 47032 bytes is the length of the following impact effects part from this position }}
{{OBDtr| 0x08 | int32 |00FF00| 02 00 00 00 | 2 | version }}
{{OBDtr| 0x0C | int32 |00FFFF| 5E 00 00 00 | 94 | number of impacts }}
{{OBDtr| 0x10 | int32 |FFC8C8| 1E 00 00 00 | 30 | number of materials }}
{{OBDtr| 0x14 | int32 |FFFFC8| 54 00 00 00 | 84 | number of particles }}
{{OBDtr| 0x18 | int32 |C8FFC8| 20 01 00 00 | 288 | number of sounds }}
{{OBDtr| 0x1C | int32 |C8FFFF| 69 01 00 00 | 361 | number of impact effects }}
{{OBDtr| 0x20 | int32 |FFC8FF| DF 00 00 00 | 223 | number of material indices }}
{{OBDtrBK|Impact table }}
{{OBDtr| 0x00 | char[128] |FFC800| 44 65 66... | Default | impact name (Default.[[OBD:Impt|Impt]]) }}
{{OBDtr| 0x80 | int16 |FFC800| 00 00 | 0 | unknown }}
{{OBDtr| 0x82 | int16 |FFC800| 00 00 | 0 | unknown }}
{{OBDtrBK|Material table }}
{{OBDtr| 0x00 | char[128] |FFC800| 44 65 66... | Default | material name (Default.[[OBD:Mtrl|Mtrl]]) }}
{{OBDtr| 0x80 | int16 |FFC800| 00 00 | 0 | unknown }}
{{OBDtr| 0x82 | int16 |FFC800| 00 00 | 0 | unknown }}
|}

----
==Impact lookup table==

This table has the same number of entries as the impact table.

[[Image:Bin_r_i2.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | int16 |FFC8C8| 00 00 | 0 | index into the impact table }}
{{OBDtr| 0x02 | int16 |FFFFC8| 00 00 | 0 | number of used entries in the material index table }}
{{OBDtr| 0x04 | int32 |C8FFC8| DF 00 00 00 | 223 | index of the first used entry in the material index table }}
|}

----
==Particle table==
[[Image:Bin_r_i3.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[64] |FFC8C8| 77 31 30... | w10_sni_x02| particle name (06193-3RAPw10_sni_x02.[[OBD:BINA/PAR3|BINA]]) }}
{{OBDtr| 0x40 | int32 |FFFFC8| | | runtime: pointer to particle class }}
{{OBDtr| 0x44 | int32 |C8FFC8| 00 00 00 00 | 0 | collision type; the following values are possible:
:0 - ?any?
:1 - ?heavy?
:2 - ?medium?
:3 - ?light? }}
{{OBDtr| 0x48 | int32 |C8FFFF| 05 00 00 00 | 5 | location type: the following values are possible:
:0 - ?
:1 - ?
:3 - ?
:4 - ?
:5 - ?
}}
{{OBDtr| 0x4C | |FFC8FF| 00 00 00 00 | | unknown; used only when location type is 1 or 3 }}
{{OBDtr| 0x50 | |FFC800| 00 00 00 00 | | unknown; always zero }}
|}

----
==Sound table==
[[Image:Bin_r_i4.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[32] |FFC8C8| | not used | sound name (link to an [[OBD:OSBD|OSBD]] file) }}
{{OBDtr| 0x20 | int16 |FFFFC8| CD CD | 52685 | unknown; maybe it's garbage that belongs to the sound name field above }}
{{OBDtr| 0x22 | int16 |C8FFC8| CD CD | 52685 | unknown; maybe it's garbage that belongs to the sound name field above }}
{{OBDtr| 0x24 | int32 |C8FFFF| 00 00 00 00 | | runtime: pointer to sound }}
{{OBDtr| 0x28 | int16 |FFC8FF| 01 00 | 1 | AI can hear; 0 <nowiki>=</nowiki> no, 1 <nowiki>=</nowiki> yes }}
{{OBDtr| 0x2A | int16 |FFC800| 03 00 | 3 | sound type; the following types are possible:
:0 - unimportant
:1 - interesting
:2 - danger
:3 - melee
:4 - gunfire }}
{{OBDtr| 0x2C | float |C800C8| 00 00 16 43 | 150.000000 | earshot radius }}
|}

----
==Impact effects table==
[[Image:Bin_r_i5.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | int16 |FFC8C8| 37 00 | 55 | number of the used impact of the first package of part 1 }}
{{OBDtr| 0x02 | int16 |FFFFC8| 01 00 | 1 | number of the used material of the second package of part 1 }}
{{OBDtr| 0x04 | int16 |C8FFC8| 00 00 | 0 | component; the following components are possible:
:0 - impact
:1 - damage
:2 - projectile }}
{{OBDtr| 0x06 | int16 |C8FFFF| 00 00 | 0 | modifier; the following modifiers are possible:
:0 - any
:1 - heavy
:2 - medium
:3 - light }}
{{OBDtr| 0x08 | int16 |FFC8FF| 01 00 | 1 | number of used entries from the particle table }}
{{OBDtr| 0x0A | int16 |FFC800| 00 00 | 0 | unknown; looks like garbage to me }}
{{OBDtr| 0x0C | int32 |C800C8| FF FF FF FF | -1 | index of the used entry in sound table; -1 <nowiki>=</nowiki> not used }}
{{OBDtr| 0x10 | int32 |C87C64| 53 00 00 00 | 83 | index of the first used entry in the particle table }}
|}

----
==Material index table==
[[Image:Bin_r_i6.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | int16 |FFC8C8| 01 00 | 1 | index into material table }}
{{OBDtr| 0x02 | int16 |FFFFC8| 01 00 | 1 | number of used entries in the impact effect table }}
{{OBDtr| 0x04 | int32 |C8FFC8| 54 01 00 00 | 340 | index of the first used entry in the impact effect table }}
|}

----
==Dialogs from level0_Tools==

http://ssg.oni2.net/subfold/bluebox/images/700_impact_effects.png

http://ssg.oni2.net/subfold/bluebox/images/701_impact_effect_properties.png

{{OBD BINA Footer|align=center|prev=OBJC|type=ONIE|next=PAR3|name=Oni Impact Effects|onistuff=b_ie}}

OBD:BINA/OBJC/TURR

2008-06-30T12:37:47Z

Ssg: bluebox jpg to png

{{OBD OBJC Header|align=center|type=TURR|prev=TRIG|next=WEAP|name=Turret|}}

[[Image:Bin_r_tu.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x04 | int32 |FFFF00| 14 04 00 00 | 1044 | size of the complete collection from this postion in bytes }}
{{OBDtr| 0x08 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x0C | int32 |00FFFF| 90 00 00 00 | 144 | size of the following element in bytes }}
{{OBDtrBK}}
{{OBDtr| 0x00 | char[4] |FFC8C8| 52 52 55 54 | TURR | object type: turret }}
{{OBDtr| 0x04 | int32 |FFFFC8| B8 1F 00 00 | 8120 | object ID }}
{{OBDtr| 0x08 | |C8FFC8| 09 00 00 00 | 0x09 | object flags; used values:
:0x'''01''' 00 00 00 - unknown
:0x'''08''' 00 00 00 - unknown }}
{{OBDtr| 0x0C | float |C8FFFF| 75 E1 CB C3 | -407.761383| x-position of the turret }}
{{OBDtr| 0x10 | float |C8FFFF| 00 00 94 42 | 74.000000 | y-position (height) of the turret }}
{{OBDtr| 0x14 | float |C8FFFF| B0 15 33 43 | 179.084717 | z-position of the turret }}
{{OBDtr| 0x18 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the x-axis in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| 00 00 34 43 | 180.000000 | rotation on the y-axis in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z-axis in degrees }}
{{OBDtr2| 0x24 | char[63] |FFC800| "phr_turret_wall"| link by name to global turret class (phr_turret_wall. [[OBD:TURR|TURR]]) }}
{{OBDtr| 0x63 | int16 |C800C8| 01 00 | 1 | turret ID }}
{{OBDtr| 0x65 | int16 |C87C64| 00 00 | 0 | flags; possible values:
:0x'''02''' 00 - unkown }}
{{OBDtr| 0x67 | |B0C3D4| | | ignored }}
{{OBDtr| 0x8B | int32 |FFDDDD| 01 00 00 00 | Konoko | target team bitset:
:1 - Konoko
:2 - TCTF
:4 - Syndicate
:8 - Neutral
:16 - SecurityGuard
:32 - RogueKonoko
:64 - Switzerland
:128 - SyndicateAccessory }}
{{OBDtr| 0x8F | |64AAAA| 00 | | padding }}
|}

'''Bluebox screenshot'''

http://ssg.oni2.net/subfold/bluebox/images/217_turret_properties.png

{{OBD OBJC Footer|align=center|type=TURR|prev=TRIG|next=WEAP|name=Turret}}

OBD:BINA/OBJC/TRIG

2008-06-30T12:36:35Z

Ssg: bluebox jpg to png

{{OBD OBJC Header|align=center|type=TRIG|prev=TRGV|next=TURR|name=Trigger}}

[[image:bin_r_tr.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x04 | int32 |FFFF00| DC 0A 00 00 | 2780 | size of the complete collection from this postion in bytes }}
{{OBDtr| 0x08 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x0C | int32 |00FFFF| 80 00 00 00 | 128 | size of the following element in bytes }}
{{OBDtrBK}}
{{OBDtr| 0x00 | char[4] |FFC8C8| 47 49 52 54 | TRIG | trigger }}
{{OBDtr| 0x04 | int32 |FFFFC8| 15 0F 00 00 | 3861 | old file ID? }}
{{OBDtr| 0x08 | |C8FFC8| 09 00 00 00 | | unknown }}
{{OBDtr| 0x0C | float |C8FFFF| 5E FA 03 C3 | -131.977996| x-position of the trigger }}
{{OBDtr| 0x10 | float |C8FFFF| 9A 99 82 C2 | -65.300003 | y-position (height) of the trigger }}
{{OBDtr| 0x14 | float |C8FFFF| EE FC 94 43 | 297.976013 | z-position of the trigger }}
{{OBDtr| 0x18 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the x-axis in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the y-axis in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z-axis in degrees }}
{{OBDtr| 0x24 | char[63] |FFC800| |"trigger_evilbrain" | trigger type (00701-trigger_evilbrain.[[OBD:TRIG|TRIG]] of level 0) }}
{{OBDtr| 0x63 | int16 |C800C8| CA 00 | 202 | trigger ID }}
{{OBDtr| 0x65 | |C87C64| 4C 00 | 0x4C00 | flags; used flags:
: 0x'''04''' 00 - active?
: 0x'''08''' 00 - initial active
: 0x'''10''' 00 - reverse
: 0x'''20''' 00 - pingpong
: 0x'''40''' 00 - unknown
: 0x'''80''' 00 - unknown }}
{{OBDtr| 0x67 | |B0C3D4| 00 00 FF FF | red | laser color }}
{{OBDtr| 0x6B | float |E7CEA5| 00 00 00 3F | 0.500000 | start position of the trigger in the rail; range from 0 (bottom) to 1 (top) in connection to the spawn point of the trigger (spawn point <nowiki>=</nowiki> bottom) }}
{{OBDtr| 0x6F | float |FFDDDD| 00 00 40 3F | 0.750000 | speed of the trigger; range from 0 (stop) to 2 (very fast) }}
{{OBDtr| 0x73 | int16 |64AAAA| 02 00 | 2 | trigger emitter count }}
{{OBDtr| 0x75 | int16 |EBEBEB| 00 00 | 0 | unknown; always zero (time on?) }}
{{OBDtr| 0x77 | int16 |8C8CCC| 00 00 | 0 | unknown; always zero (time off?) }}
{{OBDtr| 0x79 | int16 |FF00C8| 01 00 | 1 | 1 event block follows (the block is edged in grey) }}
{{OBDtrBK|Event Block}}
{{OBDtr| 0x00 | |F0F096| 02 00 | 2 | event type; used types:
:1 - call up function
:2 - activate turret }}
{{OBDtr| 0x02 | |00C864| 14 00 | 20 | event argument: turret id }}
{{OBDtrBK|Event Block End}}
{{OBDtr| | |00C8FF| 00 | | padding }}
|}

'''Bluebox screenshot'''

http://ssg.oni2.net/subfold/bluebox/images/216_trigger_properties.png

{{OBD OBJC Footer|align=center|type=TRIG|prev=TRGV|next=TURR|name=Trigger|onistuff=b_tr}}

OBD:BINA/OBJC/TRGV

2008-06-30T12:35:43Z

Ssg: bluebox jpg to png

{{OBD OBJC Header | align=center | type=TRGV | prev=SNDG | next=TRIG | name=Trigger Volume}}

[[image:bin_r_tv.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x000 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x004 | int32 |FFFF00| 7C 33 00 00 | 13180 | size of the complete neutral part from this postion in bytes }}
{{OBDtr| 0x008 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x00C | int32 |00FFFF| 60 01 00 00 | 352 | size of the following object in bytes }}
{{OBDtrBK|First object (grey outline}}
{{OBDtr| 0x000 | char[4] |FFC8C8| 56 47 52 54 | TRGV | trigger volume (TV) }}
{{OBDtr| 0x004 | int32 |FFFFC8| ED 1B 00 00 | 7149 | old file ID }}
{{OBDtr| 0x008 | int32 |C8FFC8| 00 00 00 00 | 0 | unknown }}
{{OBDtr| 0x00C | float |C8FFFF| 5C 47 36 44 | 729.114990 | x-position of TV }}
{{OBDtr| 0x010 | float |C8FFFF| 00 00 00 00 | 0.000000 | y-position (height) of TV }}
{{OBDtr| 0x014 | float |C8FFFF| 73 D8 C9 C3 | -403.691009| z-position of TV }}
{{OBDtr| 0x018 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the x-axis in degrees }}
{{OBDtr| 0x01C | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the y-axis in degrees }}
{{OBDtr| 0x020 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z-axis in degrees }}
{{OBDtr2|0x024 | char[63] |FFC800| trigger_volume_01 | name of TV }}
{{OBDtr2|0x063 | char[32] |C800C8| spawn_floor2_guards | "entry" function; called up when character enters the TV }}
{{OBDtr2|0x083 | char[32] |C87C64| unused | "inside" function; called while character is inside the TV }}
{{OBDtr2|0x0A3 | char[32] |B0C3D4| unused | "exit" function; called up when character leaves the TV }}
{{OBDtr| 0x0C3 | bitset |E7CEA5| 01 | 1 | teams that can fire off the TV; any combination of the following:

:0x01 - Konoko
:0x02 - TCTF
:0x04 - Syndicate
:0x08 - Neutral
:0x10 - SecurityGuard
:0x20 - RogueKonoko
:0x40 - Switzerland
:0x80 - SyndicateAccessory

}}
{{OBDtr| 0x0C4 | int24 |FFDDDD| FF FF FF | unknown | always the same; probably padding }}
{{OBDtr| 0x0C7 | float |64AAAA| 00 00 F8 41 | 31.000000 | x-dimension of the TV }}
{{OBDtr| 0x0CB | float |64AAAA| 00 00 4C 42 | 51.000000 | y-dimension of the TV }}
{{OBDtr| 0x0CF | float |64AAAA| 00 00 08 42 | 34.000000 | z-dimension of the TV }}
{{OBDtr| 0x0D3 | int32 |EBEBEB| 01 00 00 00 | 1 | trigger volume ID }}
{{OBDtr| 0x0D7 | int32 |8C8CCC| 00 00 00 00 | 0 | trigger volume ID of the parent TV, if this one is a child }}
{{OBDtr2|0x0DB | char[128]|FF00C8| unused | space for notes }}
{{OBDtr| 0x15B | int32 |F0F096| 81 00 00 00 | 0x80 + 0x01| flags; any combination of the following:
:0x01 - "entry" called only once (otherwise called every time character enters the TV)
:0x02 - "inside" called only once (otherwise called at every frame while character is in the TV)
:0x04 - "exit" called only once (otherwise called every time character leaves the TV)
:0x08 - "entry" disabled (can be enabled with '''[[trigvolume_enable]] tv_name entry 1''')
:0x10 - "inside" disabled (can be enabled with '''[[trigvolume_enable]] tv_name inside 1''')
:0x20 - "exit" disabled (can be enabled with '''[[trigvolume_enable]] tv_name exit 1''')
:0x40 - "all" disabled (master switch, can be enabled with '''[[trigvolume_enable]] tv_name all 1''')
:0x80 - additional restriction: only player characters can fire off the TV
}}
{{OBDtr| 0x15F | |00C864| 00 | 0 | padding }}
|}
;Resetting the trigger volume
:'''[[trigvolume_reset]](string tv_name)''' resets the TV to its preset state. The primary use of this is to re-enable "entry", "inside" or "exit" calls once the TV has been triggered (only necessary if the respective trigger-only-once flags are set of course). Note that some or all the TV functions are disabled at level load, you'll have to enable them manually after resetting the TV.
;"Inside" event
:This one is triggered at every frame (60 times per second) unless the trigger-only-once flag is set. Continuous triggering is typically needed for fire or gas damage.

;Bluebox screenshot

http://ssg.oni2.net/subfold/bluebox/images/212_trigger_volume_properties.png

{{OBD OBJC Footer | type=TRGV | prev=SNDG | next=TRIG | name=Trigger Volume}}

OBD:BINA/OBJC/SNDG

2008-06-30T12:35:06Z

Ssg: bluebox jpg to png

{{OBD OBJC Header | align=center | type=SNDG | prev=PWRU | next=TRGV | name=Sound Group}}

[[image:bin_r_so.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x04 | int32 |FFFF00| C8 3C 00 00 | 15560 | size of the complete sound group part from this postion in bytes }}
{{OBDtr| 0x08 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x0C | int32 |00FFFF| 68 00 00 00 | 104 | size of the following element in bytes }}
{{OBDtrBK}}
{{OBDtr| 0x00 | char[4] |FFC8C8| 47 44 4E 53 | SNDG | sound geometry }}
{{OBDtr| 0x04 | int32 |FFFFC8| 2D 23 00 00 | 9005 | old file ID }}
{{OBDtr| 0x08 | int32 |C8FFC8| 00 00 00 00 | 0 | unknown }}
{{OBDtr| 0x0C | float |C8FFFF| B6 52 7E C3 | -254.323090| x-position of the particle }}
{{OBDtr| 0x10 | float |C8FFFF| F3 14 A5 42 | 82.540916 | y-position (height) of the particle }}
{{OBDtr| 0x14 | float |C8FFFF| EB 8B DD 41 | 27.693319 | z-position of the particle }}
{{OBDtr| 0x18 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the x-axis in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the y-axis in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z-axis in degrees }}
{{OBDtr2|0x24 | char[32] |FFC800| city_amb01 | sound name (reference to 06452-city_amb01.[[OBD:OSBD/OSAm|amb.OSBD]] of level 0) }}
{{OBDtr| 0x44 | char[4] |C800C8| 45 4D 4C 56 | VLME | sound geometry type; the following types are possible:

:VLME (EMLV) - volume (axis-aligned box)
:SPHR (RHPS) - sphere

}}
{{OBDtr| 0x48 | float |C87C64| 00 50 87 C4 |-1082.500000| VLME: xmin SPHR: rmax }}
{{OBDtr| 0x4C | float |C87C64| 00 00 DC C2 | -110.000000| VLME: ymin SPHR: rmin }}
{{OBDtr| 0x50 | float |C87C64| 00 00 CA C2 | -101.000000| VLME: zmin SPHR: sound volume }}
{{OBDtr| 0x54 | float |B0C3D4| 00 50 87 44 | 1082.500000| VLME: xmax SPHR: sound pitch }}
{{OBDtr| 0x58 | float |B0C3D4| 00 00 DC 42 | 110.000000 | VLME: ymax SPHR: field not present }}
{{OBDtr| 0x5C | float |B0C3D4| 00 00 CA 42 | 101.000000 | VLME: zmax SPHR: field not present }}
{{OBDtr| 0x60 | float |FFDDDD| 00 00 80 3F | 1.000000 | VLME: sound volume SPHR: field not present }}
{{OBDtr| 0x64 | float |64AAAA| 00 00 80 3F | 1.000000 | VLME: sound pitch SPHR: field not present }}
|}

;Position and rotation
:Like for other data types, those probably correspond to handles for runtime editing.
:x, y, z are oriented the usual way (z+ = forward, x+ = left, y+ = up)
:Position is in world units (decimeters). Rotation is in degrees, trigonometric.
;Sound pitch
:Actually a playback speed multiplier. Other multipliers specified in the [[OBD:OSBD/OSGr|OSGr]].
;Radii (SPHR)
:What do they correspond to? Is the following correct?
:*r < rmin : volume = "sound volume"
:*rmin < r < rmax : volume = "sound volume" * (rmax - r)/(rmax - rmin)
:*r > rmax : volume = 0
:Please confirm. [[User:Geyser|geyser]] 15:56, 26 January 2007 (CET)

;Bluebox screenshot

http://ssg.oni2.net/subfold/bluebox/images/218_sound_properties.png

{{OBD OBJC Footer | type=SNDG | prev=PWRU | next=TRGV | name=Sound Group}}

OBD:BINA/OBJC/PATR

2008-06-30T12:34:11Z

Ssg: bluebox jpg to png

{{OBD OBJC Header | align=center | type=PATR | prev=PART | next=PWRU | name=Patrol path}}

[[image:bin_r_pp.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x04 | int32 |FFFF00| B4 1F 00 00 | 8116 | size of the complete patrol path part from this postion in bytes }}
{{OBDtr| 0x08 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x0C | int32 |00FFFF| 78 00 00 00 | 120 | size of the following element in bytes }}
{{OBDtrBK}}
{{OBDtr| 0x00 | char[4] |FFC8C8| 52 54 41 50 | PATR | patrol path }}
{{OBDtr| 0x04 | int32 |FFFFC8| 6F 1A 00 00 | 6767 | old file ID }}
{{OBDtr| 0x08 | int32 |C8FFC8| 00 00 00 00 | 0 | unknown }}
{{OBDtr| 0x0C | float |C8FFFF| 08 AB 20 44 | 642.672363 | x-position of the patrol path start point }}
{{OBDtr| 0x10 | float |C8FFFF| E7 26 87 41 | 16.893995 | y-position (height) of the patrol path start point }}
{{OBDtr| 0x14 | float |C8FFFF| 6C CD BD C3 | -379.604858| z-position of the patrol path start point }}
{{OBDtr| 0x18 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the x-axis in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the y-axis in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z-axis in degrees }}
{{OBDtr2|0x24 | char[32] |FFC800| Floor1_Stk_1 | patrol path name }}
{{OBDtr| 0x44 | int32 |C800C8| 04 00 00 00 | 4 | number of path points (grey outline) }}
{{OBDtr| 0x48 | int16 |C87C64| 00 00 | 0 | patrol path ID }}
{{OBDtr| 0x4A | int16 |B0C3D4| 01 00 | 1 | "return to nearest"? }}
{{OBDtrBK|1=First path point (grey outline)}}
{{OBDtr| 0x00 | int32 |E7CEA5| 13 00 00 00 | 19 | path point type; the following types are possible (values in dec):

:00 - move to flag (short)
:01 - stop (nothing); (not used in Oni)
:02 - pause in frames (long)
:03 - look at flag (short)
:04 - look at point (float, float, float); (not used in Oni)
:05 - move and face to flag (short)
:06 - run path in a loop (nothing)
:07 - movement mode (long) - the following movement modes are possible (Don't use other numbers. Oni will crash.):

::0 - walk in firing position
::3 - walk crouch in firing position
::4 - walk relaxed (weapon down)
::5 - walk in firing position (the same as 0)
::6 - run relaxed (weapon down)
::7 - run in firing position

:08 - unknown; (not used in Oni)
:09 - unknown; (not used in Oni)
:10 - move through flag (short, float) - character moves to this flag until he/she has reached the radius border of it
:11 - move through point (float, float, float, float) - character moves to this point until he/she has reached the radius border of it; (not used in Oni)
:12 - stop looking (nothing)
:13 - free facing?; used only once
:14 - glance at flag for ... frames (short + long) - character looks (rotates only the head) to the flag for the fixed time
:15 - move near flag (short + float) - character moves to this flag until he/she has reached the radius border of it
:16 - run path in a loop from block number (long) - runs the complete path once; after that it loops the path from the block number to the end (note that the block number of the first block is zero and not one)
:17 - time + rotation (short + float) - character looks/aims around for the fixed time
:18 - unkown (nothing follows)
:19 - time + flag + rotation in degrees (short + short + float) - character moves to the flag and when reached he/she looks/aims around for the fixed time
:20 - time follows (short)
:21 - patrolscript id follows (short) - function with this id is called up (f.e. id <nowiki>= 1, then called up function =</nowiki> patrolscript0001)
:22 - ignore player (byte) - 0 <nowiki>= off; 1 =</nowiki> on
:23 - flag + time + firing spread in degrees (short + short + float) - character faces to to the flag and fires his/her weapon for the fixed time

}}
{{OBDtr| 0x04 | int16 |FFDDDD| 58 02 | 600 | sleep time in 1/60 seconds }}
{{OBDtr| 0x06 | int16 |64AAAA| CB 00 | 203 | flag ID }}
{{OBDtr| 0x08 | float |EBEBEB| 00 00 A0 42 | 80.000000 | unknown; character roation on the y-axis in degrees? }}
|}

;Path points
:A path can have at most 64 points.

;Bluebox screenshots

http://ssg.oni2.net/subfold/bluebox/images/300_edit_paths.png

http://ssg.oni2.net/subfold/bluebox/images/301_edit_path.png

http://ssg.oni2.net/subfold/bluebox/images/302_edit_path_point.png

{{OBD OBJC Footer | type=PATR | prev=PART | next=PWRU | name=Patrol path}}

OBD:BINA/OBJC/PART

2008-06-30T12:33:14Z

Ssg: bluebox jpg to png

{{OBD OBJC Header | align=center | type=PART | prev=NEUT | next=PATR | name=Particle}}

[[image:bin_r_pa.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x04 | int32 |FFFF00| 80 C1 00 00 | 49536 | size of the complete particle part from this postion in bytes }}
{{OBDtr| 0x08 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x0C | int32 |00FFFF| A0 00 00 00 | 160 | size of the following element in bytes }}
{{OBDtrBK}}
{{OBDtr| 0x00 | char[4] |FFC8C8| 54 52 41 50 | PART | particle }}
{{OBDtr| 0x04 | int32 |FFFFC8| 47 00 00 00 | 71 | object ID }}
{{OBDtr| 0x08 | int32 |C8FFC8| 00 00 00 00 | 0 | object flags }}
{{OBDtr| 0x0C | float |C8FFFF| 14 0C 81 44 | 1032.377441| x-position of the particle }}
{{OBDtr| 0x10 | float |C8FFFF| FD BF 7E 43 | 254.749954 | y-position (height) of the particle }}
{{OBDtr| 0x14 | float |C8FFFF| 89 0A E0 C1 | -28.005144 | z-position of the particle }}
{{OBDtr| 0x18 | float |FFC8FF| 3E 19 B2 42 | 89.049301 | rotation on the x-axis in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| 45 54 DA 3F | 1.705697 | rotation on the y-axis in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z-axis in degrees }}
{{OBDtr2|0x24 | char[64] |FFC800| charge_medium | particle type (reference to 05484-3RAPcharge_medium.[[OBD:BINA/PAR3|BINA]] of level 0) }}
{{OBDtr2|0x64 | char[48] |C800C8| BomberCharge01 | particle name }}
{{OBDtr| 0x94 | int16 |C87C64| 0D 00 | 13 | flags; unknown values }}
{{OBDtr| 0x96 | float |B0C3D4| 00 00 80 3F | 1.000000 | decal x scale }}
{{OBDtr| 0x9A | float |FFDDDD| 00 00 80 3F | 1.000000 | decal y scale }}
{{OBDtr| 0x9E | |64AAAA| | | padding }}
|}

;Dialog from level0_Tools

http://ssg.oni2.net/subfold/bluebox/images/220_particle_properties.png

{{OBD OBJC Footer | type=PART | prev=NEUT | next=PATR | name=Particle}}

OBD:BINA/OBJC/NEUT

2008-06-30T12:31:12Z

Ssg: bluebox jpg to png

{{OBD OBJC Header | align=center | type=NEUT | prev=MELE | next=PART | name=Neutral behavior}}

----
[[image:bin_r_ne.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x04 | int32 |FFFF00| 18 31 00 00 | 12568 | size of the complete neutral part from this postion in bytes }}
{{OBDtr| 0x08 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x0C | int32 |00FFFF| 50 01 00 00 | 336 | size of the following object in bytes }}
{{OBDtrBK|First object (grey outline}}
{{OBDtr| 0x00 | char[4] |FFC8C8| 54 55 45 4E | NEUT | neutral }}
{{OBDtr| 0x04 | int32 |FFFFC8| 3D 07 00 00 | 1853 | old file ID }}
{{OBDtr| 0x08 | int32 |C8FFC8| 00 00 00 00 | 0 | unknown }}
{{OBDtr| 0x0C | float |C8FFFF| 84 69 12 43 | 146.412170 | x-position of the handle }}
{{OBDtr| 0x10 | float |C8FFFF| 3F 48 43 C2 | -48.820552 | y-position of the handle }}
{{OBDtr| 0x14 | float |C8FFFF| AE 71 80 44 | 1027.552490| z-position of the handle }}
{{OBDtr| 0x18 | float |FFC8FF| 00 00 00 00 | 0.000000 | x-rotation of the handle in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| 00 00 00 00 | 0.000000 | y-rotation of the handle in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 00 00 00 00 | 0.000000 | z-rotation of the handle in degrees }}
{{OBDtr2|0x24 | char[32] |FFC800| Give VDG Pistol ... | space for notes }}
{{OBDtr| 0x44 | int16 |C800C8| 02 00 | 2 | neutral ID }}
{{OBDtr| 0x46 | int16 |C87C64| 02 00 | 2 | amount of dialogue lines in array (grey outline) }}
{{OBDtr| 0x48 | bool1[32]|B0C3D4| 02 00 00 00 | 2 | interrupt flags:
:0x01 - no resume
:0x02 - no resume after give
:0x04 - uninterruptible
}}
{{OBDtr| 0x4C | float |FFDDDD| 00 00 C8 42 | 100.000000 | trigger range }}
{{OBDtr| 0x50 | float |FFDDDD| 00 00 20 42 | 40.000000 | talk range }}
{{OBDtr| 0x54 | float |FFDDDD| 00 00 48 43 | 200.000000 | follow range }}
{{OBDtr| 0x58 | float |FFDDDD| 00 00 8C 42 | 70.000000 | enemy range }}
{{OBDtr2|0x5C | char[32] |64AAAA| civfem_trigger | trigger speech (name of global civfem_trigger.[[OBD:OSBD/OSAm|amb.OSBD]]) }}
{{OBDtr2|0x7C | char[32] |EBEBEB| civfem_abort | abort speech (name of global civfem_abort.[[OBD:OSBD/OSAm|amb.OSBD]]) }}
{{OBDtr2|0x9C | char[32] |8C8CCC| civfem_enemy | enemy speech (name of global civfem_enemy.[[OBD:OSBD/OSAm|amb.OSBD]]) }}
{{OBDtr2|0xBC | char[32] |FF00C8| unused | script action to be performed after the talk }}
{{OBDtr2|0xDC | char[32] |F0F096| w6_vdg | name of global w6_vdg.[[ONWC]] (weapon) received by the player }}
{{OBDtr| 0xFC | int8 |00C864| 00 | 0 | amount of ballistic ammo received by the player }}
{{OBDtr| 0xFD | int8 |00C864| 00 | 0 | amount of energy cells received by the player }}
{{OBDtr| 0xFE | int8 |00C864| 00 | 0 | amount of hypo sprays received by the player }}
{{OBDtr| 0xFF | bool1[8] |00C864| 00 | 0 | item or items received by the player (flags):
:0x01 - force shield ON/OFF
:0x02 - phase cloak ON/OFF
:0x04 - LSI (level specific item) ON/OFF
}}
{{OBDtrBK|First dialogue line (grey outline)}}
{{OBDtr| 0x00 | int16 |00C8FF| 00 00 | 0 | animation flags:
:0x01 - is player ON/OFF
:0x02 - give items ON/OFF
:0x04 - anim once ON/OFF
:0x08 - other anim once ON/OFF
}}
{{OBDtr| 0x02 | int16 |00C8FF| 00 00 | 0 | ignored }}
{{OBDtr| 0x04 | int16 |C80040| 00 00 | 0 | anim type; the following occur in original NEUT:
:000 - None
:200 - Act_No
:201 - Act_Yes
:202 - Act_Talk
:203 - Act_Shrug
:204 - Act_Shout
}}
{{OBDtr| 0x06 | int16 |C80040| 00 00 | 0 | "other anim"? }}
{{OBDtr2|0x08 | char[32] |FFCD96| civfem_gift_weapon | speech (reference to global civfem_gift_weapon.[[OBD:OSBD/OSAm|amb.OSBD]]) }}
|}

;Is player
:Plays the specified anim type on the player rather than on the NPC. Same for "other anim"?
;Anim type
:Any non-ambiguous anim type compatible with the Standing anim state should be valid.

;Bluebox screenshot

http://ssg.oni2.net/subfold/bluebox/images/309_edit_neutral_behavior.png

----
----
{{OBD OBJC Footer | type=NEUT | prev=MELE | next=PART | name=Neutral behavior}}

OBD:BINA/OBJC/MELE

2008-06-30T12:30:22Z

Ssg: /* Bluebox screenshot */ bluebox jpg to png

{{OBD OBJC Header | type=MELE | prev=FURN | next=NEUT | name=Melee profile | align=center|onistuff=b_me}}

===General settings===
[[image:bin_r_m1.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x04 | int32 |FFFF00| 84 75 02 00 | 161156 | size of the complete melee part from this postion in bytes }}
{{OBDtr| 0x08 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x0C | int32 |00FFFF| 28 15 00 00 | 5416 | size of the following element in bytes }}
{{OBDtrBK}}
{{OBDtr| 0x00 | char[4] |FFC8C8| 45 4C 45 4D | MELE | melee }}
{{OBDtr| 0x04 | int32 |FFFFC8| 76 02 00 00 | 630 | old file ID }}
{{OBDtr| 0x08 | int32 |C8FFC8| 00 00 00 00 | 0 | unknown }}
{{OBDtr| 0x0C | float |C8FFFF| B3 F3 2A 43 | 170.951950 | x-position of unknown }}
{{OBDtr| 0x10 | float |C8FFFF| C7 0D 71 C1 | -15.065864 | y-position (height) of unknown }}
{{OBDtr| 0x14 | float |C8FFFF| CF 29 38 42 | 46.040829 | z-position of unknown }}
{{OBDtr| 0x18 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the x-axis in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the y-axis in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z-axis in degrees }}
|}

===Profile part===
{{Table}}
{{OBDth}}
{{OBDtr| 0x24 | int32 |FFC800| 09 00 00 00 | 9 | melee ID }}
{{OBDtr2|0x28 | char[64] |C800C8| NINJA_Easy | space for notes }}
{{OBDtr2|0x68 | char[64] |C87C64| ninja_easy_1 | character class name (reference to a ninja_easy_1.[[OBD:ONCC|ONCC]] file) }}
{{OBDtr| 0xA8 | int32 |B0C3D4| 64 00 00 00 | 100 | notice in percent; how often AI registeres incoming attack; without noticing it, AI will not block or dodge }}
{{OBDtr| 0xAC | int32 |B0C3D4| 64 00 00 00 | 100 | Dodge base in percent; determines how often AI tries to dodge incoming attacks }}
{{OBDtr| 0xB0 | int32 |B0C3D4| 1E 00 00 00 | 30 | Dodge extra in percent; adds extra chance to dodge incoming attack }}
{{OBDtr| 0xB4 | int32 |B0C3D4| 05 00 00 00 | 5 | Dodge damage amount; amount of damage dealt to character (or incoming in one strong attack) for Dodge extra activation }}
{{OBDtr| 0xB8 | int32 |B0C3D4| 0F 00 00 00 | 15 | 1 vs 1 blocking skill in percent; specifies how often AI blocks incoming attack when blocking one enemy }}
{{OBDtr| 0xBC | int32 |B0C3D4| 14 00 00 00 | 20 | Group blocking skill in percent; looks like amount of possibility that AI will try to block attacks incoming from more enemies }}
{{OBDtr| 0xC0 | float |E7CEA5| 00 00 00 40 | 2.000000 | unknown; always the same ("not blocked"?) }}
{{OBDtr| 0xC4 | float |E7CEA5| 33 33 33 3F | 0.700000 | unknown ("must change stance"?) }}
{{OBDtr| 0xC8 | float |E7CEA5| 00 00 C0 3F | 1.500000 | unknown ("blocked but unblockable"?) }}
{{OBDtr| 0xCC | float |E7CEA5| 9A 99 99 3F | 1.200000 | unknown; always the same ("blocked but has stagger"?) }}
{{OBDtr| 0xD0 | float |E7CEA5| 33 33 33 3F | 0.700000 | unknown; always the same ("blocked but has blockstun"?) }}
{{OBDtr| 0xD4 | float |E7CEA5| 00 00 00 3F | 0.500000 | unknown; always the same ("blocked"?) }}
{{OBDtr| 0xD8 | float |E7CEA5| 00 00 00 40 | 2.000000 | throw danger; still unknown but it has something to do with probability of being thrown; when set very high, AI2 with this MELE is almost unthrowable }}
{{OBDtr| 0xDC | int16 |FFDDDD| 3C 00 | 60 | unknown; always the same }}
{{OBDtr| 0xDE | int16 |FFDDDD| 5A 00 | 90 | unknown }}
{{OBDtr| 0xE0 | int32 |64AAAA| 1A 00 00 00 | 26 | number of attack techniques }}
{{OBDtr| 0xE4 | int32 |64AAAA| 06 00 00 00 | 6 | number of evade/dodge techniques }}
{{OBDtr| 0xE8 | int32 |64AAAA| 07 00 00 00 | 7 | number of maneuver/position techniques (sum of all techniques <nowiki>=</nowiki> amount of elements of the technique part}}
{{OBDtr| 0xEC | int32 |64AAAA| 6D 00 00 00 | 109 | number of moves (amount of elements of the move part) }}
|}

;Techniques
:They are listed right after the profile's header. Their number is specified in the header, and their size is 88 bytes each.
;Moves
:They are listed right after the techniques. Their number is specified in the header, and their size is 16 bytes each.

===Technique part===
[[image:bin_r_m2.gif]]

{{Table}}
{{OBDth}}
{{OBDtrBK|1=First element (grey outline)}}
{{OBDtr2|0x00 | char[64] |EBEBEB| Spinning Suplex | space for notes (technique's name) }}
{{OBDtr| 0x40 | bitset32 |8C8CCC| 00 00 00 00 | 0 | flags; see below }}
{{OBDtr| 0x44 | int32 |FF00C8| 50 00 00 00 | 80 | weight; techniques with higher weight are prefered by engine, if more techniques that can be used at one moment; have same weight, engine calls them in order as they are listed in MELE }}
{{OBDtr| 0x48 | int32 |F0F096| 0A 00 00 00 | 10 | unknown }}
{{OBDtr| 0x4C | int32 |00C864| 58 02 00 00 | 600 | repeat delay in frames; after technique is used, it is ignored by engine for this time interval }}
{{OBDtr| 0x50 | int32 |00C8FF| 02 00 00 00 | 2 | number of moves used by this technique }}
{{OBDtr| 0x54 | int32 |C80040| 57 00 00 00 | 87 | position of the first move for this technique in the move part }}
|}

;Technique flags:
*00 - unknown;
*01 - Interruptible; execution of moves in this technique is interrupted (technique is taken by engine as finished) when enemy is outside range, which specified by [[OBD:BINA/OBJC/MELE/MoveList/Position|position]] move (which has to be first in the series of moves; it is the third parameter of the position moves ) or by [[OBD:BINA/OBJC/MELE/MoveList/Maneuver|maneuver]] move (again the third parameter).
*02 - unknown; maybe "Generous dir", it seems that AI2 can turn around while attacking with technique that has this flag (or correct distance if it is a maneuver). So basically, it maybe turns on homing ^_-.
--[[User:Loser|Loser]] 08:39, 22 July 2007 (CEST)

:For everybody's convenience, I've grouped the techniques with the 0x40 field set to 1 [[OBD:BINA/OBJC/MELE/Technique0x40#Bit 0x01|HERE]].
::[[User:Geyser|geyser]] 00:00, 20 November 2006 (CET)
;0x40 set to 2
:This is true for the following techniques :
:*Furies :
:**Body Surf Front
:**Running Kick
:**Running Punch
:*Ninjas :
:**Lightning Stomp
:*Strikers :
:**Jump Kick
:**Running_Kick
:**Running_Punch
:*Tankers :
:**Circle Left
:**Circle Right
:**Run/Dive-Left
:**Run/Dive-Right
:**Run/Drop Kick
:**Run/Jump Kick
:**Run/Jumpkick Back
:**Run/Jumpkick Left
:**Run/Jumpkick Right
:**Slide
:For an exhaustive listing (complete with actual classes), see [[OBD:BINA/OBJC/MELE/Technique0x40#Bit 0x02|HERE]].
:That has to be either "Fearless" or "Generous Dir" (whatever that means).
:"Somebody better investigate soon." ^^
::[[User:Geyser|geyser]] 00:00, 20 November 2006 (CET)

===Move part===
[[image:bin_r_m3.gif]]

{{Table}}
{{OBDth}}
{{OBDtrBK|1=First element (grey outline)}}
{{OBDtr| 0x00 | int32hb |FFCD96| 04 00 00 20 | 4, 32 | move id, move type

the move id belongs to the move type; [[OBD:BINA/OBJC/MELE/MoveList|these move IDs are possible]]

the move type comes as a high byte; the following types are possible (values in dec):

:00 - attack
:16 - position
:32 - maneuver
:48 - evade
:64 - throw

}}
{{OBDtr| 0x04 | float |FF80C0| CD CC 4C 3F | 0.800000 | move parameter 1 (in this case, "min" : something like the minimum duration of the "Pause") }}
{{OBDtr| 0x08 | float |D0C0AF| 00 00 00 00 | 0 | move parameter 2 (in this case, none : "Pause" only takes one parameter) }}
{{OBDtr| 0x0C | float |EEDDFF| 00 00 00 00 | 0 | move parameter 3 (in this case, none : "Pause" only takes one parameter) }}
|}

;Move types
:00 - Attack, struct array starts at 0x140A88 in the English EXE
:16 - Position, struct array starts at 0x1435B0 in the English EXE
:32 - Maneuver, struct array starts at 0x143AB0 in the English EXE
:48 - Evade, struct array starts at 0x143E30 in the English EXE
:64 - Throw, struct array starts at 0x144370 in the English EXE

===Notes===
:There are 45 melee profiles.

====ONCC lookup====
:It seems that typing different ONCC model names here allows the melee profile to use some "trademark" moves:
*all ninjas (easy, med, hard) and super_ninja_1 ONCCs allow p_p_k_k_k_k combo
*konoko_generic and all red (fury) classes allow p_p_k combo, kick/kick back/run kick behind/run kick throws, k_k_kfw combo
*all tanker classes allow kick/kick back/run kick behind/run kick throws
*muro and mutant_muro classes allow p_p_p_p combo.
If you know something else, feel free to complete it. The question about this "trademark" moves is: is it specified in the ONCC or somewhere else ???

====All profiles in order of appearance in the collection====
{{Table}}
|- ALIGN=CENTER BGCOLOR="#E9E9E9"
! 1 || 2 || 3 || 4 || 5
|-
|[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Easy]]||Security_Guard||TCTF_Lite||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Easy]]||COMGUY
|-
|[[OBD:BINA/OBJC/MELE/THUG|THUG_Air]]||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Medium]]||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Hard]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Easy2]]||BLACKOPS_Lite
|-
|BLACKOPS_Swat||TCTF_Swat||[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Easy]]||MADBOMBER||NINJABOT_Train1
|-
|RED_Easy||[[OBD:BINA/OBJC/MELE/TANKER|SNIPER]]||RED_Medium||KONOKO||BARABAS Rsrch D
|-
|BARABAS TCTF D||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Medium2]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Hard2]]||MURO_Dream||MURO_Final
|-
|MURO_Mutant||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Super]]||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Medium]]||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Hard]]||RED_Hard
|-
|[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Medium]]||[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Hard]]||GRIFFIN||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Mini]]||COP Male
|-
|COP Female||[[OBD:BINA/OBJC/MELE/THUG|THUG_Mfg]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Neuro]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Pow]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Wh]]
|-
|NINJABOT_Train2||[[OBD:BINA/OBJC/MELE/NINJA|NINJABOT_PowPlant]] ||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Easy]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Medium]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Hard]]
|- ALIGN=CENTER BGCOLOR="#E9E9E9"
! 41 || 42 || 43 || 44 || 45
|}

====All profiles sorted by ID====

The IDs start at 0 and increase by 1 for every next profile with the exception of the last 3, the IDs of which are 55, 56, 57 (instead of 42, 43, 44)

{{Table}}
|- ALIGN=CENTER BGCOLOR="#E9E9E9"
! 0 || 1 || 2 || 3 || 4
|-
|Security_Guard||TCTF_Lite||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Easy]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Air]]||COMGUY
|-
|[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Medium]]||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Hard]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Easy]]||RED_Easy||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Easy]]
|-
|[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Medium]]||BLACKOPS_Lite||BLACKOPS_Swat||TCTF_Swat||[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Easy]]
|-
|[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Hard]]||RED_Medium||MADBOMBER||NINJABOT_Train1||[[OBD:BINA/OBJC/MELE/TANKER|SNIPER]]
|-
|[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Medium]]||[[OBD:BINA/OBJC/MELE/ELITE|ELITE_Hard]]||KONOKO||BARABAS Rsrch D||RED_Hard
|-
|BARABAS TCTF D||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Medium]]||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Hard]]||[[OBD:BINA/OBJC/MELE/NINJA|NINJA_Super]]||MURO_Dream
|-
|MURO_Final||MURO_Mutant||GRIFFIN||[[OBD:BINA/OBJC/MELE/STRIKER|STRIKER_Mini]]||COP Male
|-
|COP Female||[[OBD:BINA/OBJC/MELE/THUG|THUG_Mfg]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Neuro]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Pow]]||[[OBD:BINA/OBJC/MELE/THUG|THUG_Wh]]
|-
|NINJABOT_Train2||[[OBD:BINA/OBJC/MELE/NINJA|NINJABOT_PowPlant]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Easy2]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Medium2]]||[[OBD:BINA/OBJC/MELE/TANKER|TANKER_Hard2]]
|- ALIGN=CENTER BGCOLOR="#E9E9E9"
! 40 || 41 || 55 || 56 || 57
|}

==Bluebox screenshot==
http://ssg.oni2.net/subfold/bluebox/images/308_edit_melee.png

{{OBD OBJC Footer | type=MELE | prev=FURN | next=NEUT | name=Melee profile}}

OBD:BINA/OBJC/FURN

2008-06-30T12:29:43Z

Ssg: bluebox jpg to png

{{OBD OBJC Header | align=center | type=FURN | prev=FLAG | next=MELE | name=Furniture}}

[[image:bin_r_fu.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x04 | int32 |FFFF00| 60 A7 00 00 | 42848 | size of the complete furniture part from this postion in bytes }}
{{OBDtr| 0x08 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x0C | int32 |00FFFF| 74 00 00 00 | 116 | size of the following element in bytes }}
{{OBDtrBK}}
{{OBDtr| 0x00 | char[4] |FFC8C8| 4E 52 55 46 | FURN | furniture }}
{{OBDtr| 0x04 | int32 |FFFFC8| F5 0E 00 00 | 3829 | old file ID }}
{{OBDtr| 0x08 | int32 |C8FFC8| 08 00 00 00 | 8 | unknown }}
{{OBDtr| 0x0C | float |C8FFFF| 9C C4 7A C2 | -62.692001 | x-position of the furniture }}
{{OBDtr| 0x10 | float |C8FFFF| 00 00 E8 C1 | -29.000000 | y-position (height) of the furniture }}
{{OBDtr| 0x14 | float |C8FFFF| 33 B3 D8 42 | 108.349998 | z-position of the furniture }}
{{OBDtr| 0x18 | float |FFC8FF| A2 85 35 43 | 181.522003 | rotation on the x-axis in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| B0 02 B2 43 | 356.020996 | rotation on the y-axis in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 2F 1D 32 43 | 178.113998 | rotation on the z-axis in degrees }}
{{OBDtr2|0x24 | char[32] |FFC800| _tctf_bigvan | furniture type name (reference to an [[OBD:OFGA|OFGA]] file) }}
{{OBDtr2|0x44 | char[48] |C800C8| unused | locklight tag name }}
|}

;NOTE
:CJBO'''Furniture'''.OBJC files are an old development relict, because the furniture is "baked" into the level model.
:Oni still parses these files (see error txt file in your Oni folder), but you can disable them and use their RAW/SEP part in whichever way you like (e.g. to create a larger collection of characters/flags/trigvolumes/whatever).
:There ''is'' a separation between "furniture" and other parts of the environment (quads are flagged as glass/furniture/etc).
:The furniture [[OBD:OFGA|OFGA]] files aren't a part of the regular Oni files. They are stored in the unused "Level0_Tools" files, which are only inluded in Oni 1.1 (currently we only know the German "Big Blue Box" Collection for Mac that contains Oni 1.1).

;Bluebox screenshot

http://ssg.oni2.net/subfold/bluebox/images/223_furniture_properties.png

{{OBD OBJC Footer | type=FURN | prev=FLAG | next=MELE | name=Furniture}}

OBD:BINA/OBJC/FLAG

2008-06-30T12:28:56Z

Ssg: bluebox jpg to png

{{OBD OBJC Header | align=center | type=FLAG | prev=DOOR | next=FURN | name=Flag}}

[[image:bin_r_fl.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x04 | int32 |FFFF00| C8 91 00 00 | 37320 | size of the complete flag part from this postion in bytes }}
{{OBDtr| 0x08 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x0C | int32 |00FFFF| AC 00 00 00 | 172 | size of the following element in bytes }}
{{OBDtrBK}}
{{OBDtr| 0x00 | char[4] |FFC8C8| 47 41 4C 46 | FLAG | flag }}
{{OBDtr| 0x04 | int32 |FFFFC8| 34 1A 00 00 | 6708 | old file ID }}
{{OBDtr| 0x08 | int32 |C8FFC8| 00 00 00 00 | 0 | unknown }}
{{OBDtr| 0x0C | float |C8FFFF| A0 1A F0 41 | 30.013000 | x-position of the flag }}
{{OBDtr| 0x10 | float |C8FFFF| 31 08 58 C1 | -13.501999 | y-position (height) of the flag }}
{{OBDtr| 0x14 | float |C8FFFF| AA 51 C9 C3 |-402.638000 | z-position of the flag }}
{{OBDtr| 0x18 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the x-axis in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the y-axis in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z-axis in degrees }}
{{OBDtr| 0x24 | color |FFC800| 00 FF 00 FF |0, 255, 0, 255| flag color (blue, green, red); transparency }}
{{OBDtr| 0x28 | char[2] |C800C8| 58 4D | MX | flag prefix ? }}
{{OBDtr| 0x2A | int16 |C87C64| 00 00 | 0 | flag ID }}
{{OBDtr2|0x2C | char[128]|B0C3D4| unused | space for notes }}
|}

;Trimmed flag lists (scripter-friendly)
:[http://geyser.oni2.net/OBD/BINA/OBJC/FLAG HERE]

;Bluebox screenshot

http://ssg.oni2.net/subfold/bluebox/images/213_flag_properties.png

{{OBD OBJC Footer | type=FLAG | prev=DOOR | next=FURN | name=Flag}}

OBD:BINA/OBJC/DOOR

2008-06-30T12:28:32Z

Ssg: bluebox jpg to png

{{OBD OBJC Header | align=center | type=DOOR | prev=CONS | next=FLAG | name=Door}}

[[image:bin_r_do.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x00 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x04 | int32 |FFFF00| 15 19 00 00 | 14344 | size of the complete door part from this postion in bytes }}
{{OBDtr| 0x08 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x0C | int32 |00FFFF| FC 00 00 00 | 252 | size of the following element in bytes }}
{{OBDtrBK}}
{{OBDtr| 0x00 | char[4] |FFC8C8| 52 4F 4F 44 | DOOR | door }}
{{OBDtr| 0x04 | int32 |FFFFC8| 57 12 00 00 | 6421 | object ID }}
{{OBDtr| 0x08 | int32 |C8FFC8| 08 00 00 00 | 8 | object flags }}
{{OBDtr| 0x0C | float |C8FFFF| 00 00 4F 43 | 207.000000| x-position of the bottom of the door }}
{{OBDtr| 0x10 | float |C8FFFF| 00 00 D8 42 | 108.000000| y-position (height) of the bottom of the door }}
{{OBDtr| 0x14 | float |C8FFFF| 98 7F CC C3 |-408.996826| z-position of the bottom of the door }}
{{OBDtr| 0x18 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the x-axis in degrees }}
{{OBDtr| 0x1C | float |FFC8FF| 67 85 25 3D | 0.040410 | rotation on the y-axis in degrees }}
{{OBDtr| 0x20 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z-axis in degrees }}
{{OBDtr2|0x24 | char[63] |FFC800| TCdouble | door type name (reference to 00957-TCdouble.[[OBD:DOOR|DOOR]] of level 0) }}
{{OBDtr| 0x63 | int16 |C800C8| 01 00 | 1 | door ID }}
{{OBDtr| 0x65 | int16 |C87C64| 00 00 | 0 | key ID }}
{{OBDtr| 0x67 | bitset16 |B0C3D4| 15 00 | 21, 0 | door options; the following bits are possible:

:0x'''01''' 00 - door locked
:0x'''02''' 00 - unknown
:0x'''04''' 00 - unknown
:0x'''08''' 00 - unknown
:0x'''10''' 00 - require player to press '''action''' to open door
:0x'''20''' 00 - unknown
:0x'''40''' 00 - unknown
:0x'''80''' 00 - double door
:0x00 '''01''' - unknown
:0x00 '''02''' - one way door (one side locked, other side unlocked)
:0x00 '''04''' - reverse of the one way door (now the other side is locked)
:0x00 '''08''' - unknown
:0x00 '''10''' - unknown
:0x00 '''20''' - unknown
:0x00 '''40''' - unknown
:0x00 '''80''' - unknown

}}
{{OBDtr |0x69 | float |FFDDDD| 00 00 4F 43 | 207.000000 | x-position of the center of the door }}
{{OBDtr |0x6D | float |FFDDDD| 00 00 F6 42 | 123.000000 | y-position (height) of the center of the door }}
{{OBDtr |0x71 | float |FFDDDD| 98 7F CC C3 | -408.996826| z-position of the center of the door }}
{{OBDtr |0x75 | float |64AAAA| 00 00 61 44 | 900.000000 | activation radius (squared) }}
{{OBDtr2|0x79 | char[63] |EBEBEB| _DOOR_RL_FLOOR3 | first door texture (reference to 00216-_DOOR_RL_FLOOR3.[[OBD:TXMP|TXMP]]) }}
{{OBDtr2|0xA8 | char[63] |8C8CCC| unused | second door texture (reference to a [[OBD:TXMP|TXMP]] file) }}
{{OBDtr |0xE7 | int16 |8C8CCC| 00 00 | 0 | number of events (executed when the door is opened) }}
{{OBDtr |0xE9 | |8C8CCC| | | padding }}
|}

;Bluebox screenshot

http://ssg.oni2.net/subfold/bluebox/images/221_door_properties.png

{{OBD OBJC Footer | type=DOOR | prev=CONS | next=FLAG | name=Door}}

OBD:BINA/OBJC/CONS

2008-06-30T12:27:06Z

Ssg: bluebox jpg to png (+ content is now complete in English)

{{OBD OBJC Header | align=center | type=CONS | prev=CMBT | next=DOOR | name=Console}}

[[image:bin_r_co.gif]]

{{Table}}
{{OBDth}}
{{OBDtr| 0x000 | char[4] |FF0000| 43 4A 42 4F | OBJC | object collection }}
{{OBDtr| 0x004 | int32 |FFFF00| 4C 0E 00 00 | 5463 | size of the complete console part from this postion in bytes }}
{{OBDtr| 0x008 | int32 |00FF00| 27 00 00 00 | 39 | object collection version }}
{{OBDtr| 0x00C | int32 |00FFFF| 48 01 00 00 | 328 | size of the following element in bytes }}
{{OBDtrBK}}
{{OBDtr| 0x000 | char[4] |FFC8C8| 53 4E 4F 43 | CONS | console }}
{{OBDtr| 0x004 | int32 |FFFFC8| 57 12 00 00 | 5463 | old file ID }}
{{OBDtr| 0x008 | int32 |C8FFC8| 08 00 00 00 | 8 | unknown }}
{{OBDtr| 0x00C | float |C8FFFF| 71 0C 6C 44 | 944.194396| x-position of the console }}
{{OBDtr| 0x010 | float |C8FFFF| 00 00 D8 C1 | -27.000000| y-position (height) of the console }}
{{OBDtr| 0x014 | float |C8FFFF| 68 05 EB 41 | 29.377639 | z-position of the console }}
{{OBDtr| 0x018 | float |FFC8FF| 42 FD 17 38 | 0.000036 | rotation on the x-axis in degrees }}
{{OBDtr| 0x01C | float |FFC8FF| 00 00 87 43 | 270.000000| rotation on the y-axis in degrees }}
{{OBDtr| 0x020 | float |FFC8FF| 00 00 00 00 | 0.000000 | rotation on the z-axis in degrees }}
{{OBDtr2|0x024 | char[63] |FFC800| console_data | console type name (reference to 00761-console_data.[[OBD:CONS|CONS]] of level 0) }}
{{OBDtr| 0x063 | int16 |C800C8| 01 00 | 1 | console ID }}
{{OBDtr| 0x065 | bitset16 |C87C64| 08 00 | 8 | console options; the following bits are possible:

:0x00 - console deactivated
:0x01 - unknown, never used
:0x02 - unknown, never used
:0x04 - unknown, never used
:0x08 - console active at level load
:0x10 - unknown, never used
:0x20 - use punch animation (KONOKOconsole_punch.[[OBD:TRAM|TRAM]])
:0x40 - alarm console flag; AI can search for the console and use it ON ITS OWN (no scripting) when certain conditions ([[OBD:BINA/OBJC/CMBT#Alarm part|CMBT]] alarm behavior) are met
:0x80 - unknown, never used

}}
{{OBDtr2|0x067 | char[63] |B0C3D4| _con_INFO | "console deactivated" texture name (reference to 00800-_CON_INFO.[[OBD:TXMP|TXMP]] of level 0) }}
{{OBDtr2|0x0A6 | char[63] |E7CEA5| _con_INFO | "console activated" texture name (reference to 00800-_CON_INFO.[[OBD:TXMP|TXMP]] of level 0) }}
{{OBDtr2|0x0E5 | char[63] |FFDDDD| _con_INFO | "console used" texture name (reference to 00800-_CON_INFO.[[OBD:TXMP|TXMP]] of level 0) }}
{{OBDtr |0x124 | int16 |64AAAA| 01 00 | 1 | number of events }}
{{OBDtrBK|1=First event (grey outline)}}
{{OBDtr |0x126 | int16 |EBEBEB| 01 00 | 1 | event type; the following types are possible (values in dec):
:00 - nothing
:01 - script function (32 byte string)
:02 - activate turret (short)
:03 - deactivate turret (short)
:04 - activate console (short)
:05 - deactivate console (short)
:06 - activate alarm (short)
:07 - deactivate alarm (short)
:08 - activate trigger (short)
:09 - deactivate trigger (short)
:10 - lock door (short)
:11 - unlock door (short)
}}
{{OBDtr2|0x128 | char[32] |8C8CCC| level3c | event parameter; here, the name of the script function to be called when the console is used }}
|}

;Bluebox screenshot

http://ssg.oni2.net/subfold/bluebox/images/219_console_properties.png

{{OBD OBJC Footer | type=CONS | prev=CMBT | next=DOOR | name=Console }}

OBD:WMDD

2008-06-28T08:58:55Z

Ssg: added style stuff (first element: 0x108)

{{OBD_File_Header|align=center|type=WMDD|prev=WMCL|next=WMM_|name=WM (Window Menu) Dialog Data|family=Global}}

The image below shows the beginning of the file with the settings of the main window.

[[image:wmdd_all.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x000 | res_id |FF0000| 01 CE 09 00 | 1541 | 01541-dialog_mainmenu.WMDD }}
{{OBDtr| 0x004 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr2| 0x008| char[256]|00FF00| Main Menu | title }}
{{OBDtr| 0x108 | int16 |00FFFF| 96 00 | 150 | ID (looked up from code) }}
{{OBDtr| 0x10A | int16 |00FFFF| 00 00 | 0 | not used; always 0 }}
{{OBDtr| 0x10C | int32 |FF00FF| 01 00 00 00 | 0x01 | state; the following values are used:
:0x'''01''' 00 00 00 - visible
:0x'''02''' 00 00 00 - disabled
:0x'''04''' 00 00 00 - unknown
}}
{{OBDtr| 0x110 | int32 |FF8000| 00 00 01 00 | 0x00010000 | style; the following values are used:
:0x'''01''' 00 00 00 - thin light blue border around the window (somehow transparency is involved too; if you use the g206 ui and press the exit botton of the main window, a window with no background appears)
:0x'''02''' 00 00 00 - thick light lila border around the window
:0x'''04''' 00 00 00 - light lila title bar
:0x'''08''' 00 00 00 - title (title bar required)
:0x'''10''' 00 00 00 - close button visible (title bar required)
:0x'''20''' 00 00 00 - restore button visible (title bar required)
:0x'''40''' 00 00 00 - minimize button visible (title bar required)
:0x00 00 '''01''' 00 - center window on screen (x, y coordinates are ignore when this style is used)
}}
{{OBDtr| 0x114 | int16 |804080| 00 00 | 0 | x coordinate of the window }}
{{OBDtr| 0x116 | int16 |804080| 00 00 | 0 | y coordinate of the window }}
{{OBDtr| 0x118 | int16 |804040| 80 02 | 640 | width of the window }}
{{OBDtr| 0x11A | int16 |804040| E0 01 | 480 | height of the window }}
{{OBDtr| 0x11C | int32 |408080| 06 00 00 00 | 6 | array size }}
{{OBDtrBK}}
{{OBDtr2| 0x000 | char[256]|FFC8C8| New Game | text (or TXMB/TXMP name if class is 11) }}
{{OBDtr| 0x100 | int16 |FFFFC8| 04 00 | 4 | class; the following window classes exist in Oni (values in dec):
:1 - desktop (not used in dialogs)
:3 - title
:4 - button
:5 - checkbox
:6 - dialog (not used in dialogs)
:7 - edit field
:8 - listbox
:9 - menu bar (not used in dialogs)
:10 - menu (not used in dialogs)
:11 - background picture ([[OBD:TXMB|TXMB]]) or texture ([[OBD:TXMP|TXMP]])
:12 - pull-down menu
:13 - progress bar
:14 - radio button
:16 - scrollbar (not used in dialogs)
:17 - slider
:20 - text field
}}
{{OBDtr| 0x102 | int16 |C8FFC8| 64 00 | 100 | ID (looked up from code) }}
{{OBDtr| 0x104 | int32 |C8FFFF| 01 00 00 00 | 0x01 | state; the following values are used:
:0x'''01''' 00 00 00 - visible
:0x'''02''' 00 00 00 - disabled
:0x'''04''' 00 00 00 - unknown
}}
{{OBDtr| 0x108 | int32 |FFC800| 00 00 03 00 | 0x030000 | style; some known values:
:0x00 00 '''01''' 00 - show button/scrollbar/checkbox text
:0x00 00 '''02''' 00 - show button text
:0x00 00 '''04''' 00 - show title
:0x00 00 '''08''' 00 - show listbox entries
---

if button:
:0x00 00 '''01''' 00 - show button
:0x00 00 '''02''' 00 - show button text
:0x00 00 '''10''' 00 - no change in color (visible with the g206 ui, button is single-colored instead of multi-colored)

if text field:
:0x'''01''' 00 00 00 - show background and border
:0x00 00 '''02''' 00 - horizontal text align <nowiki>=</nowiki> center
:0x00 00 '''04''' 00 - horizontal text align <nowiki>=</nowiki> right
:0x00 00 '''10''' 00 - vertical text align <nowiki>=</nowiki> center
:0x00 00 '''80''' 00 - hide text
---
:'''NOTE''': Possible values also include the ones available for the dialog style field. Style values above 0xffff have class specific meaning so the above list is not necesarilly complete (and correct).
}}
{{OBDtr| 0x10C | int16 |C87C64| 5E 01 | 350 | x coordinate (relative to the top left corner of the window) }}
{{OBDtr| 0x10E | int16 |C87C64| E6 00 | 230 | y coordinate (relative to the top left corner of the window) }}
{{OBDtr| 0x110 | int16 |B0C3D4| B4 00 | 180 | width }}
{{OBDtr| 0x112 | int16 |B0C3D4| 28 00 | 40 | height }}
{{OBDtr| 0x114 | link32 |E7CEA5| 01 02 00 00 | 2 | link to 00002-Tahoma.[[OBD:TSFF|TSFF]]}}
{{OBDtr| 0x118 | int32 |FFDDDD| 01 00 00 00 | 1 | font option; the following options are possible:
:0 - normal font
:1 - '''bold''' font
:2 - ''italic'' font
}}
{{OBDtr| 0x11C | color32 |64AAAA| 00 7F FF FF | 0, 127, 255; 255 | font color (blue, green, red); transparency }}
{{OBDtr| 0x120 | int8 |EBEBEB| 01 | 1 | ignored }}
{{OBDtr| 0x121 | int8 |EBEBEB| 00 | 0 | ignored }}
{{OBDtr| 0x122 | int16 |8C8CCC| 0A 00 | 10 | font size (height) }}
|}

;Dialog ID
:Since Oni looks dialogs up by ID, changing them arbitrarily is not recommended.
;Visible flag (0x10C)
:A hidden/disabled window can't be activated from Oni, so if you hide the main menu, you'll have to shut down Oni from the Task Manager (or make it Blam ^^).
:With "-noswitch", you can switch to other applications whenever the mouse pointer is visible in Oni.
;Item IDs (for this example)
:64 - "new game" window
:65 - "load game" window
:66 - "options" window
:67 - "quit" window
:68 - "resume" window

{{OBD_File_Footer|align=center|type=WMDD|prev=WMCL|next=WMM_|name=WM (Window Menu) Dialog Data|family=Global}}

OBD:WMDD

2008-06-26T15:05:26Z

Ssg: style: 00001000 - no change in color

{{OBD_File_Header|align=center|type=WMDD|prev=WMCL|next=WMM_|name=WM (Window Menu) Dialog Data|family=Global}}

The image below shows the beginning of the file with the settings of the main window.

[[image:wmdd_all.gif]]

{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x000 | res_id |FF0000| 01 CE 09 00 | 1541 | 01541-dialog_mainmenu.WMDD }}
{{OBDtr| 0x004 | lev_id |FFFF00| 01 00 00 00 | 0 | level 0 }}
{{OBDtr2| 0x008| char[256]|00FF00| Main Menu | title }}
{{OBDtr| 0x108 | int16 |00FFFF| 96 00 | 150 | ID (looked up from code) }}
{{OBDtr| 0x10A | int16 |00FFFF| 00 00 | 0 | not used; always 0 }}
{{OBDtr| 0x10C | int32 |FF00FF| 01 00 00 00 | 0x01 | state; the following values are used:
:0x'''01''' 00 00 00 - visible
:0x'''02''' 00 00 00 - disabled
:0x'''04''' 00 00 00 - unknown
}}
{{OBDtr| 0x110 | int32 |FF8000| 00 00 01 00 | 0x00010000 | style; the following values are used:
:0x'''01''' 00 00 00 - thin light blue border around the window (somehow transparency is involved too; if you use the g206 ui and press the exit botton of the main window, a window with no background appears)
:0x'''02''' 00 00 00 - thick light lila border around the window
:0x'''04''' 00 00 00 - light lila title bar
:0x'''08''' 00 00 00 - title (title bar required)
:0x'''10''' 00 00 00 - close button visible (title bar required)
:0x'''20''' 00 00 00 - restore button visible (title bar required)
:0x'''40''' 00 00 00 - minimize button visible (title bar required)
:0x00 00 '''01''' 00 - center window on screen (x, y coordinates are ignore when this style is used)
}}
{{OBDtr| 0x114 | int16 |804080| 00 00 | 0 | x coordinate of the window }}
{{OBDtr| 0x116 | int16 |804080| 00 00 | 0 | y coordinate of the window }}
{{OBDtr| 0x118 | int16 |804040| 80 02 | 640 | width of the window }}
{{OBDtr| 0x11A | int16 |804040| E0 01 | 480 | height of the window }}
{{OBDtr| 0x11C | int32 |408080| 06 00 00 00 | 6 | array size }}
{{OBDtrBK}}
{{OBDtr2| 0x000 | char[256]|FFC8C8| New Game | text (or TXMB/TXMP name if class is 11) }}
{{OBDtr| 0x100 | int16 |FFFFC8| 04 00 | 4 | class; the following window classes exist in Oni (values in dec):
:1 - desktop (not used in dialogs)
:3 - title
:4 - button
:5 - checkbox
:6 - dialog (not used in dialogs)
:7 - edit field
:8 - listbox
:9 - menu bar (not used in dialogs)
:10 - menu (not used in dialogs)
:11 - background picture ([[OBD:TXMB|TXMB]]) or texture ([[OBD:TXMP|TXMP]])
:12 - pull-down menu
:13 - progress bar
:14 - radio button
:16 - scrollbar (not used in dialogs)
:17 - slider
:20 - text only
}}
{{OBDtr| 0x102 | int16 |C8FFC8| 64 00 | 100 | ID (looked up from code) }}
{{OBDtr| 0x104 | int32 |C8FFFF| 01 00 00 00 | 0x01 | state; the following values are used:
:0x'''01''' 00 00 00 - visible
:0x'''02''' 00 00 00 - disabled
:0x'''04''' 00 00 00 - unknown
}}
{{OBDtr| 0x108 | int32 |FFC800| 00 00 03 00 | 0x030000 | style; some used values:
:0x00 00 '''01''' 00 - show button/scrollbar/checkbox text
:0x00 00 '''02''' 00 - show button text
:0x00 00 '''04''' 00 - show title
:0x00 00 '''08''' 00 - show listbox entries
:0x00 00 '''10''' 00 - no change in color (visible with the g206 ui, f.e. button is single-colored instead of multi-colored)
:'''NOTE''': Possible values also include the ones available for the dialog style field. Style values above 0xffff have class specific meaning so the above list is not necesarilly complete (and correct).
}}
{{OBDtr| 0x10C | int16 |C87C64| 5E 01 | 350 | x coordinate (relative to the top left corner of the window) }}
{{OBDtr| 0x10E | int16 |C87C64| E6 00 | 230 | y coordinate (relative to the top left corner of the window) }}
{{OBDtr| 0x110 | int16 |B0C3D4| B4 00 | 180 | width }}
{{OBDtr| 0x112 | int16 |B0C3D4| 28 00 | 40 | height }}
{{OBDtr| 0x114 | link32 |E7CEA5| 01 02 00 00 | 2 | link to 00002-Tahoma.[[OBD:TSFF|TSFF]]}}
{{OBDtr| 0x118 | int32 |FFDDDD| 01 00 00 00 | 1 | font option; the following options are possible:
:0 - normal font
:1 - '''bold''' font
:2 - ''italic'' font
}}
{{OBDtr| 0x11C | color32 |64AAAA| 00 7F FF FF | 0, 127, 255; 255 | font color (blue, green, red); transparency }}
{{OBDtr| 0x120 | int8 |EBEBEB| 01 | 1 | ignored }}
{{OBDtr| 0x121 | int8 |EBEBEB| 00 | 0 | ignored }}
{{OBDtr| 0x122 | int16 |8C8CCC| 0A 00 | 10 | font size (height) }}
|}

;Dialog ID
:Since Oni looks dialogs up by ID, changing them arbitrarily is not recommended.
;Visible flag (0x10C)
:A hidden/disabled window can't be activated from Oni, so if you hide the main menu, you'll have to shut down Oni from the Task Manager (or make it Blam ^^).
:With "-noswitch", you can switch to other applications whenever the mouse pointer is visible in Oni.
;Item IDs (for this example)
:64 - "new game" window
:65 - "load game" window
:66 - "options" window
:67 - "quit" window
:68 - "resume" window

{{OBD_File_Footer|align=center|type=WMDD|prev=WMCL|next=WMM_|name=WM (Window Menu) Dialog Data|family=Global}}

User talk:Neo

2008-06-23T12:45:27Z

Ssg: fixed a typo

Sorry to bother you. I want to add some more characters to level 19, but I'm not sure how to write the hex number correctly, since it is 5 digits.

In the BINACJBOCharacter.oni for level 19 at offset 0x68 currently its 8CDC, I want to add 17 more CHAR data (x2464) so doing the math xDC8C + x2464 = x100F0.

What is the correct way to write x100F0 in little endian at offset 0x68?

Of course, I'll have to make a similar change for 84DC offset xC4.

It will be great once/if we're able to export/import BINACJBOCharacter.oni as .xml files!

Many thanks.

[[User:EdT|EdT]] 06:54, 20 June 2008 (CEST)

I'm not sure what's supposed to be at 0x68, maybe you mean 0x88 (where the size of the raw/sep part is)?

Anyway 0xA1B1C1D1 is stored as:
:*A1 B1 C1 D1 - big endian (bytes are stored in the same order)
:*D1 C1 B1 A1 - little endian (bytes are stored in reverse order)

So 0x100F0 aka 0x000100F0 stored as little endian is F0 00 01 00.

PS: I'm almost done with [[OBJC]] export. Hopefully I'll do the import soon too.

[[User:Neo|Neo]]

I am sorry to bother, but this can help to make h2w system look better. When character collides with wall, what REALLY collide ??? For me it seems that for char->wall collision there is some invisible bounding box. Where is this bounding box, if you know (or correct me if I am wrong). How can I change it? I ask because for me (it is my guess in next sentence, nothing proven ) it seems that this "bounding box" looks like invisible sphere which is around pelvis bone. That is why you can fall and stick your torso/head/legs into next room. Engine ignores bones in char->wall coll. Is this correct? + please answer if you know how to change it. Thanks a lot in any case

P.S.:Just a curious question, no explanation needed: I know that AI2 powered characters can push away weapons which are on ground. Can it be (from engine-possibilities point of view) that in ONI we should have movable furniture (objects which can be pushed by chars)?

--[[User:Loser|Loser]] 11:34, 20 June 2008 (CEST)

Umm... many questions, time for a brain dump :)

;Character - Wall collision

:this is always sphere tree-quad collision. You probably know that the sphere tree can be seen with "chr_debug_sphere=1". One thing to note about that sphere tree is that it always "stays up" (even when the character is fallen). That's why fallen characters pass through walls, their body gets outside the sphere when that happens.

:As for changing the radius of that sphere tree: it may be possible but it won't solve anything.

;Character - Floor collision

:characters also have a special function to detect floor collision which checks if a 3x3 quad intersects the floor. This is done to avoid "strange" sinking when the sphere's lowest point goes outside the floor. This is the probable cause why sometimes fallen characters hang on an edge (their 3x3 quad still intersects the floor) or fall of the edge even if their feet or head are still on the floor (the 3x3 quad is too small to cover the feet and head when the character is fallen).

;Particle - Wall collision

:this is always point-quad collision (the point is the position of the particle)

;Particle - Object collision (where object is anything with a physics context that supports collision: characters, [[OBOA]] objects, powerups, weapons)

:this can be sphere-obbox or sphere-sphere collision depending on what the object has (obbox or sphere tree). The radius of the particle sphere is taken from Collision Radius property of the particle class. It can be 0 and then the collision degenerates to point-obbox/point-sphere collision.

;Environment collision (general)

:The engine can only do point-quad and spheretree-quad collision detection.

;Object collision (general)

:All objects (that have a physics context) have a sphere tree attached to them and some objects created through OBOA also have an obbox.

;Moveable furniture

:Yes and no. It can be done to some extent using [[OBOA]].

:Basically an OBOA object can be pushed if it's not animated (no OBAN link) and it has "physics type" 2 or 4 (I don't know what's the difference).

:What doesn't work:
:*characters fall through objects (the character-floor collision function does not see objects)
:*since the environment only supports sphere-quad collision you tipically cannot push an object very close to the wall (unless of course the object itself is a sphere or close enough to one)
:*objects can fall but because of sphere-quad collision detection they'll get stuck somewhere above the floor
:*an object can fall on another object but a third object will fall through both of them; in general multiple object interaction is buggy
:*if I remember correctly there is 128 physics context limit. That means the number of active characters + objects + powerups and whatever else needs a physics context is limited to 128. Anyway it will very likely crawl before you reach that limit.

[[User:Neo|Neo]]

Thank you, now I understand, I need to add leading zeros to the result.
Also, a user at OCF asked if it was possible to do division and multiplication in BSL, is it possible?

I look forward to trying out the OBJC export.

[[User:EdT|EdT]]

[http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/OniSplit/OniSplit|_v0.9.18|_beta4.zip Beta4]

Oh boy, were Mono developers lazy or not... :)

[[User:Neo|Neo]]

Thank you! BINACJBOCharacter.oni works fine, now to take a look at the melee profile file...

Ed

The melee profile is much more understandable. The moves are clearly identified. So I assume, now we will be able to create a new melee profile or at the very least add new techniques to an existing profile.

Again, THANK YOU on your awesome work on OniSplit.

[[User:EdT|EdT]] 06:17, 22 June 2008 (CEST)

2 notes about melee:

:*I've yet to make move types to show up as names instead of numbers. Remebering all those is not fun.
:*The original melee files contain what appears to be orphaned moves. Since currently moves are exported as children of techniques the orphaned moves are not exported. I don't think those moves are used by the engine but if someone knows otherwise I'll see what can be done to export them too.

Other stuff:

:*The general xml export was updated to export names instead of number for several enum and flags fields. For example the class of a dialog item in [[WMDD]] was previously exported as a number but now it's a string like Button, Edit etc. Flags fields are exported as a list of names (names separated by whitespace) like in this WMDD state field:

<State>Visible Disabled</State>

This simplifies editing but currently there is now way to discover what names are available (unless you take a look at the source code :)). I'll try to make OniSplit display such a list as part of the help or something.

[[User:Neo|Neo]]

Hey Neo, do you have any idea what the flag "Boss" does?

[[User:Gumby|Gumby]] 18:02, 22 June 2008 (CEST)

Not sure. It mai be connected to ai2_boss_battle script variable. And I'm not sure those flags are 100% correct, it looks to me that Boss/NoAutoDrop/Omniscient are mixed up.

[[User:Neo|Neo]]

Hello again. I am thinking of writing the Windows GUI for Onisplit. What scripting language would you suggest I write it in?

[[User:Gumby|Gumby]] 02:55, 23 June 2008 (CEST)

Hmm... the only scripting language to do a Windows GUI that comes to mind is Tcl/Tk but you really don't want to use that :). There are Perl/Python/Ruby etc. implementations for Windows but I have no idea if they can be used to make a GUI. It's likely that you'll have to use one of the "usual" languages: C/C++/C#/VB/Java/Delphi...

Maybe I'll do a GUI one day but it's not on my priority list, I'm more interested in making importers/exporters for now.

[[User:Neo|Neo]]

the only scripting language to do a Windows GUI that comes to mind is Tcl/Tk but you really don't want to use that :)

You can also try AutoIt3: http://www.autoitscript.com/autoit3/

It's easy to create a GUI with both of them, but AutoIt3 can't work with binary files, only text files (as far as I know). And in case of tcl/tk: It's a pain to install it. I tried and failed.

[[User:Ssg|Ssg]] 11:44, 23 June 2008 (CEST)

I've worked with AutoIt3 before and I would recommend it. The GUI creation functions are both powerful and easy to use. It can work with binary files using:
FileOpen("filename", 16)
If you need any help with AutoIt post a message on my talk page.
[[User:RossyMiles|rossy]] 12:55, 23 June 2008 (CEST)

User talk:RossyMiles

2008-06-23T12:44:34Z

Ssg: AutoIt3: Read/write in binary mode at specific position?

:Congratulations on the true windowing and on the custom resolutions. A few questions from the Russians, though:
#Really, why make such a fuss about the "USB" thing? Playing Oni from a USB device never was a problem, so how can it possibly get "easier"?
#Why tell people to replace binkw32.dll even though it's a vtuneapi.dll you're building? so that it doesn't interfere with the current [[Daodan DLL]]?
#Why not call your project part of the Daodan DLL initiative, help yourself to our database, and assimilate all the features of the FASM build?
::[[User:Geyser|geyser]] 02:54, 23 May 2008 (CEST)

:Thanks, in answer to your questions:
#I called it OniUSB because the original plan was to compress the binary data and extract it when needed, thus making Oni suitable for a <256MB flash drive. I guess it may need a name change but I'm not good with names, OniUSB is the coolest name i can think of at the moment :).
#OniUSB can replace binkw32.dll or be added as vtuneapi.dll it should work equally as well with either however because OniUSB forces Oni to use binkplay.exe instead of binkw32.dll, I thought it would be more elegant to go get rid of the original binkw32.dll. Another reason I chose to use binkw32.dll is to avoid conflict with the Daodan DLL.
#I'd really like to, however I don't know anything about assembly, I would like to help with future versions if I can. I provide the source code for free on the site so you can use bits if you want.
:I was wondering if anyone knows the memory locations for screen resolutions from the Russian game engine (and the ones I've missed on the English engine), I would like to make OniUSB compatible with as many engines as possible.
:Also I plan to join the forums soon.
::[[User:RossyMiles|rossy]] 11:06, 23 May 2008 (CEST)
#You can't squeeze the original GameDataFolder into less than 300 MB. However, if you're thinking of the Edition, it's possible to have a GDF almost as small as 256 MB, ''uncompressed''. Somehow I'm comfortable enough with a 512 MB device hosting an uncompressed Edition and some extras, but of course compressing the data would make it possible to fit the Edition into 256 MB instead. The only problem is, if the GDF is never seen by the user, how easy will it be to manage plugins (level#_Whatever.dat)?
#If your project and the Daodan DLL are one and the same, then there is no conflict and you can hook/patch most of the stuff through vtuneapi.dll As for getting rid of binkw32.dll, perhaps an even more interesting feature would be to make Oni able to play back other movie formats than BINK...
#SFeLi used FASM to build the Daodan DLL at first, but he has worked on a C version as well, so in the current situation it's more like he has bits of source code for you to use rather than the other way round. Once we throw the working source at you (soon), you can add features as you see fit.
:The layout of the resolution tables in the "standard" EXE is something like this:
.text:004083AF mov [esp+114h+var_FC.wResY], dx
.text:004083B4 mov ebp, 1200
.text:004083B9 mov esi, 1080
.text:004083BE mov [esp+114h+var_FC.wResY+30h], dx
.text:004083C3 mov ebx, 16
.text:004083C8 xor eax, eax
.text:004083CA mov edi, 1920
.text:004083CF mov edx, 32
.text:004083D4 mov [esp+114h+var_FC.wResY+20h], bp
.text:004083D9 mov [esp+114h+var_FC.wResY+28h], si
.text:004083DE mov [esp+114h+var_AA], bp
.text:004083E3 mov [esp+114h+var_A2], si
.text:004083E8 mov [esp+114h+var_FC.wResX], 640
.text:004083EF mov [esp+114h+var_FC.wBPP], bx
.text:004083F4 mov [esp+114h+var_FC.wUnused], ax
.text:004083F9 mov [esp+114h+var_FC.wResX+8], 800
.text:00408400 mov [esp+114h+var_FC.wResY+8], 600
.text:00408407 mov [esp+114h+var_FC.wBPP+8], bx
.text:0040840C mov [esp+114h+var_FC.wUnused+8], ax
.text:00408411 mov [esp+114h+var_FC.wResX+10h], 1024
.text:00408418 mov [esp+114h+var_FC.wResY+10h], 768
.text:0040841F mov [esp+114h+var_FC.wBPP+10h], bx
.text:00408424 mov [esp+114h+var_FC.wUnused+10h], ax
.text:00408429 mov [esp+114h+var_FC.wResX+18h], 1152
.text:00408430 mov [esp+114h+var_FC.wResY+18h], 864
.text:00408437 mov [esp+114h+var_FC.wBPP+18h], bx
.text:0040843C mov [esp+114h+var_FC.wUnused+18h], ax
.text:00408441 mov [esp+114h+var_FC.wResX+20h], 1600
.text:00408448 mov [esp+114h+var_FC.wBPP+20h], bx
.text:0040844D mov [esp+114h+var_FC.wUnused+20h], ax
.text:00408452 mov [esp+114h+var_FC.wResX+28h], di
.text:00408457 mov [esp+114h+var_FC.wBPP+28h], bx
.text:0040845C mov [esp+114h+var_FC.wUnused+28h], ax
.text:00408461 mov [esp+114h+var_FC.wResX+30h], 640
.text:00408468 mov [esp+114h+var_FC.wBPP+30h], dx
.text:0040846D mov [esp+114h+var_FC.wUnused+30h], ax
.text:00408472 mov [esp+114h+var_FC.wResX+38h], 800
.text:00408479 mov [esp+114h+var_FC.wResY+38h], 600
.text:00408480 mov [esp+114h+var_FC.wBPP+38h], dx
.text:00408485 mov [esp+114h+var_FC.wUnused+38h], ax
.text:0040848A mov [esp+114h+var_FC.wResX+40h], 1024
.text:00408491 mov [esp+114h+var_FC.wResY+40h], 768
.text:00408498 mov [esp+114h+var_FC.wBPP+40h], dx
.text:0040849D mov [esp+114h+var_FC.wUnused+40h], ax
.text:004084A2 mov [esp+114h+var_B4], 1152
.text:004084A9 mov [esp+114h+var_B2], 864
.text:004084B0 mov [esp+114h+var_B0], dx
.text:004084B5 mov [esp+114h+var_AE], ax
.text:004084BA mov [esp+114h+var_AC], 1600
.text:004084C1 mov [esp+114h+var_A8], dx
.text:004084C6 mov [esp+114h+var_A6], ax
.text:004084CB mov [esp+114h+var_A4], di
.text:004084D0 mov [esp+114h+var_A0], dx
.text:004084D5 mov [esp+114h+var_9E], ax
.text:004084DA mov [esp+114h+var_104], eax
.text:004084DE mov [esp+114h+var_100], eax
.text:004084E2 mov ebp, ecx
.text:004084E4 lea esi, [esp+114h+var_FC]
:This is enough info to replace a resolution or two with a hard patch, but perhaps not for what you have in mind (expect more info from SFeLi). As for the Russian engine, the current intention is to stop supporting it while adding support for non-ASCII characters to the standard engine.
:I personally have been completely absent from {{OCF}} lately, and neither SFeLi or Neo ever registered there. If you don't mean to provide intensive troubleshooting and support via the forum, then there's no hurry to join ^_^
::[[User:Geyser|geyser]] 16:11, 23 May 2008 (CEST)

:Hi, I got the source code for the Daodan DLL from SFeLi. I have discontinued the OniUSB project and I'd like to help you with Daodan if I can. I've been rewriting the code in pure C and merging the OniUSB and Daodan source code. It's going well and I have made a C source file and header which might be the start of an Oni SDK. The source code and test DLL can be downloaded from http://oniusb.googlepages.com/Daodan.7z (early beta). Also, I was wondering if there was a designated place for Daodan DLL related discussion on the wiki.
::[[User:RossyMiles|rossy]] 13:20, 25 May 2008 (CEST)
---

'''AutoIt3'''

FileOpen("filename", 16)

Ohh... somehow the German help lacks the flag information - or I didn't notice it...

So... can I also tell AutoIt3 to read binary data from a specific postion and overwrite it? (F.e. jump to position 0x0040 and read/overwrite the first 4 bytes.)

[[User:Ssg|Ssg]] 14:44, 23 June 2008 (CEST)

User talk:Neo

2008-06-23T09:44:57Z

Ssg: Another scripting language: AutoIt3

Sorry to bother you. I want to add some more characters to level 19, but I'm not sure how to write the hex number correctly, since it is 5 digits.

In the BINACJBOCharacter.oni for level 19 at offset 0x68 currently its 8CDC, I want to add 17 more CHAR data (x2464) so doing the math xDC8C + x2464 = x100F0.

What is the correct way to write x100F0 in little endian at offset 0x68?

Of course, I'll have to make a similar change for 84DC offset xC4.

It will be great once/if we're able to export/import BINACJBOCharacter.oni as .xml files!

Many thanks.

[[User:EdT|EdT]] 06:54, 20 June 2008 (CEST)

I'm not sure what's supposed to be at 0x68, maybe you mean 0x88 (where the size of the raw/sep part is)?

Anyway 0xA1B1C1D1 is stored as:
:*A1 B1 C1 D1 - big endian (bytes are stored in the same order)
:*D1 C1 B1 A1 - little endian (bytes are stored in reverse order)

So 0x100F0 aka 0x000100F0 stored as little endian is F0 00 01 00.

PS: I'm almost done with [[OBJC]] export. Hopefully I'll do the import soon too.

[[User:Neo|Neo]]

I am sorry to bother, but this can help to make h2w system look better. When character collides with wall, what REALLY collide ??? For me it seems that for char->wall collision there is some invisible bounding box. Where is this bounding box, if you know (or correct me if I am wrong). How can I change it? I ask because for me (it is my guess in next sentence, nothing proven ) it seems that this "bounding box" looks like invisible sphere which is around pelvis bone. That is why you can fall and stick your torso/head/legs into next room. Engine ignores bones in char->wall coll. Is this correct? + please answer if you know how to change it. Thanks a lot in any case

P.S.:Just a curious question, no explanation needed: I know that AI2 powered characters can push away weapons which are on ground. Can it be (from engine-possibilities point of view) that in ONI we should have movable furniture (objects which can be pushed by chars)?

--[[User:Loser|Loser]] 11:34, 20 June 2008 (CEST)

Umm... many questions, time for a brain dump :)

;Character - Wall collision

:this is always sphere tree-quad collision. You probably know that the sphere tree can be seen with "chr_debug_sphere=1". One thing to note about that sphere tree is that it always "stays up" (even when the character is fallen). That's why fallen characters pass through walls, their body gets outside the sphere when that happens.

:As for changing the radius of that sphere tree: it may be possible but it won't solve anything.

;Character - Floor collision

:characters also have a special function to detect floor collision which checks if a 3x3 quad intersects the floor. This is done to avoid "strange" sinking when the sphere's lowest point goes outside the floor. This is the probable cause why sometimes fallen characters hang on an edge (their 3x3 quad still intersects the floor) or fall of the edge even if their feet or head are still on the floor (the 3x3 quad is too small to cover the feet and head when the character is fallen).

;Particle - Wall collision

:this is always point-quad collision (the point is the position of the particle)

;Particle - Object collision (where object is anything with a physics context that supports collision: characters, [[OBOA]] objects, powerups, weapons)

:this can be sphere-obbox or sphere-sphere collision depending on what the object has (obbox or sphere tree). The radius of the particle sphere is taken from Collision Radius property of the particle class. It can be 0 and then the collision degenerates to point-obbox/point-sphere collision.

;Environment collision (general)

:The engine can only do point-quad and spheretree-quad collision detection.

;Object collision (general)

:All objects (that have a physics context) have a sphere tree attached to them and some objects created through OBOA also have an obbox.

;Moveable furniture

:Yes and no. It can be done to some extent using [[OBOA]].

:Basically an OBOA object can be pushed if it's not animated (no OBAN link) and it has "physics type" 2 or 4 (I don't know what's the difference).

:What doesn't work:
:*characters fall through objects (the character-floor collision function does not see objects)
:*since the environment only supports sphere-quad collision you tipically cannot push an object very close to the wall (unless of course the object itself is a sphere or close enough to one)
:*objects can fall but because of sphere-quad collision detection they'll get stuck somewhere above the floor
:*an object can fall on another object but a third object will fall through both of them; in general multiple object interaction is buggy
:*if I remember correctly there is 128 physics context limit. That means the number of active characters + objects + powerups and whatever else needs a physics context is limited to 128. Anyway it will very likely crawl before you reach that limit.

[[User:Neo|Neo]]

Thank you, now I understand, I need to add leading zeros to the result.
Also, a user at OCF asked if it was possible to do division and multiplication in BSL, is it possible?

I look forward to trying out the OBJC export.

[[User:EdT|EdT]]

[http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/OniSplit/OniSplit|_v0.9.18|_beta4.zip Beta4]

Oh boy, were Mono developers lazy or not... :)

[[User:Neo|Neo]]

Thank you! BINACJBOCharacter.oni works fine, now to take a look at the melee profile file...

Ed

The melee profile is much more understandable. The moves are clearly identified. So I assume, now we will be able to create a new melee profile or at the very least add new techniques to an existing profile.

Again, THANK YOU on your awesome work on OniSplit.

[[User:EdT|EdT]] 06:17, 22 June 2008 (CEST)

2 notes about melee:

:*I've yet to make move types to show up as names instead of numbers. Remebering all those is not fun.
:*The original melee files contain what appears to be orphaned moves. Since currently moves are exported as children of techniques the orphaned moves are not exported. I don't think those moves are used by the engine but if someone knows otherwise I'll see what can be done to export them too.

Other stuff:

:*The general xml export was updated to export names instead of number for several enum and flags fields. For example the class of a dialog item in [[WMDD]] was previously exported as a number but now it's a string like Button, Edit etc. Flags fields are exported as a list of names (names separated by whitespace) like in this WMDD state field:

<State>Visible Disabled</State>

This simplifies editing but currently there is now way to discover what names are available (unless you take a look at the source code :)). I'll try to make OniSplit display such a list as part of the help or something.

[[User:Neo|Neo]]

Hey Neo, do you have any idea what the flag "Boss" does?

[[User:Gumby|Gumby]] 18:02, 22 June 2008 (CEST)

Not sure. It mai be connected to ai2_boss_battle script variable. And I'm not sure those flags are 100% correct, it looks to me that Boss/NoAutoDrop/Omniscient are mixed up.

[[User:Neo|Neo]]

Hello again. I am thinking of writing the Windows GUI for Onisplit. What scripting language would you suggest I write it in?

[[User:Gumby|Gumby]] 02:55, 23 June 2008 (CEST)

Hmm... the only scripting language to do a Windows GUI that comes to mind is Tcl/Tk but you really don't want to use that :). There are Perl/Python/Ruby etc. implementations for Windows but I have no idea if they can be used to make a GUI. It's likely that you'll have to use one of the "usual" languages: C/C++/C#/VB/Java/Delphi...

Maybe I'll do a GUI one day but it's not on my priority list, I'm more interested in making importers/exporters for now.

[[User:Neo|Neo]]

the only scripting language to do a Windows GUI that comes to mind is Tcl/Tk but you really don't want to use that :)

You can also try AutoIt3: http://www.autoitscript.com/autoit3/

It's easy to create a GUI with both of them, but AutoIt3 can't work with binary files, only text files (as far as I known). And in case of tcl/tk: It's a pain to install it. I tried and failed.

[[User:Ssg|Ssg]] 11:44, 23 June 2008 (CEST)

User talk:Ssg

2008-06-17T16:07:19Z

Ssg: Switched all bluebox images from the blue to the lila ones. Hope it was okay.

==Bungie TV from Macworld 2000==

I found some old Bungie TV videos from the Macworld 2000 on the net today.

Here's a [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/btv%20pamphlet/Inside.jpg pic with the content] of the vids (~300 kb)

*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/bungie_tour_100.mov Day 1] (mov file, 160 x 120, 5 min 33 sec, ~29 mb) - contains only the Bungie East tour; the rest was never part of the file (see [http://web.archive.org/web/20000817095745/www.bungie.com/btv/archive/ here]; look at the filename)
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day2_big.mov Day 2] (mov file, 160 x 120, 38 min 30 sec, ~182 mb) - best vid, trip to Bungie West (Oni headquarters) plus Steve Abeyta shows some disarm moves
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day3_large.mov Day 3] (mov file, 160 x 120, 29 min 07 sec, ~217 mb) - see content pic above, lots of blah blah plus a ingame Halo preview at the end
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day4_100.mov Day 4] (mov file, 160 x 120, 37 min 22 sec, ~277 mb) - see content pic above, very short ingame Halo preview, rest blah blah

You can also download day two, three and four in very extra low poor quality [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/ here] (first three links, 5 to 12 mb), but that's more pixel art than a video. [[User:Ssg|Ssg]] 00:10, 20 January 2008 (CET)

::Cool, look forward to watching these. --[[User:Iritscen|Iritscen]] 15:36, 5 March 2008 (CET)
::I'm going to be linking the Bungie West and East articles to the tour vids (Day 1 and Day 2), so hopefully these files will stay around for a while. Can I count on that to be the case? --[[User:Iritscen|Iritscen]] 15:01, 20 March 2008 (CET)

??? Why are you asking me that? I have no influence in the matter. [[User:Ssg|Ssg]] 00:28, 22 March 2008 (CET)
:I assumed that you uploaded them. Whose files are they? --[[User:Iritscen|Iritscen]] 15:01, 24 March 2008 (CET)

==Bluebox screenshots==
:About the BBBB screenshots you've been adding to [[BINA]]
:#It would be nice if you described how they were obtained.
:#Are you sure '''navi.TXMP''' and '''buttons.TXMP''' are appropriate?
:I'm pretty sure there is another, more plain-looking TXMP.
:Not '''g206_controls_128x64.TXMP''', but something close...
::[[User:Geyser|geyser]] 20:14, 24 September 2007 (CEST)
----
To 1:

#added WMDDs from Level0_Tools.dat to Level0_Final.dat
#replaced the dialog ID (0x108) of the [[OBD:WMDD|WMDD]] with the dialog ID of the help-window (or whatever it's called; it's the window that pops up when you press F1)

To 2:
:I'm not sure what you mean. Do you refer to the fact that some stuff in the iamges is overlapping? (If yes: Well, I never thought about that. I was too fixated on making the WMMDs visible, I guess.)

'''Edit'''

I've changed in the last part of the dat file the name psui_oniUI to psui_oniUi. After that Oni reads the psui_g206 file. The result is this:

now: http://ssg.oni2.net/subfold/bluebox/g206_306_edit_combat.jpg before: http://ssg.oni2.net/subfold/bluebox/images_org/306_edit_combat.jpg

[[User:Ssg|Ssg]] 14:59, 11 December 2007 (CET)

Short note: if there are still dialogs from tools.dat that you do not have screenshots for here you go:
http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/tools_wmdd.zip

[[User:Neo|Neo]]

Cool. Thank you. Did you managed it to "actiivate" the "Tools" files? [[User:Ssg|Ssg]] 01:19, 12 December 2007 (CET)

If by activate you mean loading tools.dat in Oni then no. (Though I converted tools.dat to PC format but Oni crashes if it finds it and I did not bother to check why). Those images were generated with my viewer.

[[User:Neo|Neo]]

Sorry for interrupting you guys a bit.
I saw the new WMMDs.. Are you going to upgrade OniSplit or OUP like Bungie's original editor tool? That would be cool. How far are you done? 
By a side note: on "dialog_character_properties.png" you can see three different shields. So, maybe the (red one) "boss shield" was editable?
:[[User:Paradox-01|Paradox-01]] 17:53, 12 December 2007 (CET)

Would it be possible for me to get a copy of Bluebox since I'm on the Mac?
[[User:EdT|EdT]]

Alloc or geyser can help, I guess. [[User:Ssg|Ssg]] 02:02, 20 January 2008 (CET)

I switched the bluebox images from the blue to the lila ones. Hope that was okay. [[User:Ssg|Ssg]] 18:07, 17 June 2008 (CEST)

==Homing Weapons?==
Hi, Ssg. I was looking over the weapons class in the Oni binaries, and I can't find where it records that certain projectiles, like the Scram cannon's, are homing. Isn't there a bit for that? --[[User:Iritscen|Iritscen]] 19:57, 28 February 2008 (CET)
:Homing is a property of the projectile, not of the weapon class. You want to look at [[OBD:BINA/PAR3]].
::[[User:Geyser|geyser]] 23:14, 28 February 2008 (CET)
:Oh... Sorry, Iritscen, didn't see your question.
:Thanks for the answer, geyser. :-)
::[[User:Ssg|Ssg]] 23:04, 4 March 2008 (CET)
Yes, thank you. I have a neat weapon-modding idea I'd like to try. This would be my first modding attempt (we'll see if it works, I don't want to promise much, and it's a simple idea anyway). --[[User:Iritscen|Iritscen]] 15:32, 5 March 2008 (CET)

OBD:Instance file format

2008-05-08T13:08:53Z

Ssg: " instance descriptors" array - flags - added: 0x08000000 - shared

All instance files begin with a 64 byte header followed by 3 "descriptor" arrays, a data table and a name table. Among other things the header contains the number of descriptors in each of the 3 arrays and the offset of the data and name tables (relative to the start of the file).

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | int64 | | 1F 27 DC 33 DF BC 03 00 | 0x0003BCDF33DC271F | PC template checksum; PC Demo and Mac files use 0x0003BCDF23C13061 instead }}
{{OBDtr| 0x08 | int32 | | 31 33 52 56 | 'VR31' | .dat version; .oni files use 'VR32' instead }}
{{OBDtr| 0x0C | int64 | | 40 00 14 00 10 00 08 00 | 0x0008001000140040 | signature }}
{{OBDtr| 0x14 | int32 | | F9 05 00 00 | 1529 | instance descriptor count }}
{{OBDtr| 0x18 | int32 | | D5 01 00 00 | 469 | name descriptor count }}
{{OBDtr| 0x1C | int32 | | 32 00 00 00 | 50 | template descriptor count }}
{{OBDtr| 0x20 | int32 | | 80 89 00 00 | 0x008980 | data table offset }}
{{OBDtr| 0x24 | int32 | | 20 6E 55 00 | 0x556E20 | data table size }}
{{OBDtr| 0x28 | int32 | | A0 F7 55 00 | 0x55F7A0 | name table offset }}
{{OBDtr| 0x2C | int32 | | 35 1D 00 00 | 0x001D35 | name table size }}
{{OBDtr| 0x30 | int32 | | 00 00 00 00 | | OniSplit only: raw table offset }}
{{OBDtr| 0x34 | int32 | | 00 00 00 00 | | OniSplit only: raw table size }}
{{OBDtr| 0x38 | int32 | | 00 00 00 00 | | unused }}
{{OBDtr| 0x3C | int32 | | 00 00 00 00 | | unused }}
|}

The "instance descriptors" array stores information about every instance contained in the file.

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | tag | | 41 53 49 41 | 'AISA' | template tag }}
{{OBDtr| 0x04 | int32 | | 08 00 00 00 | 0x0008 | data offset (relative to data table) }}
{{OBDtr| 0x08 | int32 | | 00 00 00 00 | 0x0000 | name offset (relative to name table) }}
{{OBDtr| 0x0C | int32 | | 80 01 00 00 | 0x0180 | data size }}
{{OBDtr| 0x10 | int32 | | 00 00 00 00 | 0 | flags; possible values:
:0x'''01''' 00 00 00 - unnamed
:0x'''02''' 00 00 00 - empty
:0x'''04''' 00 00 00 - never used; appears to mean "big endian" data
:0x'''08''' 00 00 00 - shared }}
|}

The "name descriptors" array stores the numbers of all named instances in alphabetically order. This allows the engine to do a binary search to faster find instances by name. It is also used when finding instances by type.

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | int32 | | 00 00 00 00 | 0 | instance number }}
{{OBDtr| 0x04 | int32 | | 00 00 00 00 | 0 | runtime: pointer to instance name }}
|}

The "template descriptor" array contains information about all templates used in the file. The template checksum is used to prevent loading of instance files that are not compatible with the current engine version.

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | int64 | | A0 6D 12 00 00 00 00 00 | 0x126DA0 | template checksum }}
{{OBDtr| 0x0C | tag | | 41 4E 42 41 | 'ABNA' | template tag }}
{{OBDtr| 0x08 | int32 | | 01 00 00 00 | 1 | number of instances that use this template }}
|}

The data table stores all the instance data. Instance ID is always stored 32 byte aligned (thus the instance specific data will always be found at an offset like 0x0008, 0x0028, 0x0148 etc.). Instance ID and file ID are not actually part of the instance data. The engine always has pointers to "instance specific data" and instance ID and file ID are accessed using negative offsets when needed (usually to find the name or template tag of an instance give a pointer to it).

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | int32 | | 01 00 00 00 | 1 | instance id }}
{{OBDtr| 0x04 | int32 | | 01 00 00 02 | 0x02000001 | file id }}
{{OBDtr| 0x08 | | | | | [[OBD:File_types|instance specific data]] }}
|}

The name table stores all the instance names as C style strings (terminated by 0).

{{Table}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | string | | 41 49 ... 00 | "AISAlevel1_scripts" | name string (0 terminated) }}
|}

;Instance (.dat) file
An instance file is a dump of engine's in memory data structures. It is acompanied by a .raw file and a .sep file (the .sep file is only used and present in the PC Demo and Mac versions of the game) which stores additional data (usually large and unstructured like texture or sound data) needed by some instance types. [[OniSplit]] generated .oni files are PC .dat files with all the data contained by the .raw/.sep files appended at the end.

;Binary (.raw, .sep) file
Binary files do not have any file header. The only rule about binary files is that all data parts are stored 32 byte aligned and the first 32 byte of the file are always 0 (reserved to represent NULL pointers). Instances store file offsets into binary files and at loaded time the offsets are converted to pointers.

;Instance file name
An instance file name has the following structure:
levelN_T.dat
where N is the level number (from 0 to 127) and T is the type of file. Known types are "Final" and "Tools". The original exe only loads "Final" files.

;Level 0 file
Level 0 file does not acually contain a level but instances shared across all levels. It is loaded first when the game starts and never unloaded. All other level files are only loaded when the coresponding level starts and unloaded when it ends.

;Instance descriptors
There are 3 types of instance descriptors:
*unnamed - they are referenced by other instances in the same file and the engine never reaches them directly
*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 - the instance data is stored in a different file and they exist only to associate an instance id with a name; when an instance references such an instance id the engine searches all the loaded files for a non empty instance with the same name

;Instance ID
The ID of an instance is computed as:
(instance_descriptor_index << 8) <nowiki>|</nowiki> 1.
The 1 allows the engine to know which IDs have already been converted to pointers (a instance pointer will always be 8 byte aligned so it can never have the bit 0 set).

;File ID
The file ID is computed from the name of the instance file. For "_Final" files the file ID is computed as:
(level_number << 25) <nowiki>|</nowiki> 1
Again the 1 allows the engine to know which file IDs have already been converted to pointers.

;Templates
An instance can have pointers to other instances but since pointers are only valid in memory they are converted to instance identifiers when the file is saved and converted back to pointers when the file is loaded into memory. To be able to do this the engine must know where pointers are and this is done using "templates". A template contains:
*a checksum of the data contained by the template (the checksum algorithm is unknown)
*a 4-letter tag used to identify the template (ABNA, ONCC, WMDD etc.)
*a short description of the data structure like "BSP Tree Node Array"
*a list of all data structure's fields and their types
*other data that appears to be unused like size of the fixed part and size of an array element for data structures that contain variable length arrays

;Absolute limits
*Max level number: 127
*Max number of instance files in GameDataFolder: 512 (PC), 16 (PC 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)

User talk:Ssg

2008-03-21T23:28:16Z

Ssg: /* Bungie TV from Macworld 2000 */ ???

==Bungie TV from Macworld 2000==

I found some old Bungie TV videos from the Macworld 2000 on the net today.

Here's a [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/btv%20pamphlet/Inside.jpg pic with the content] of the vids (~300 kb)

*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/bungie_tour_100.mov Day 1] (mov file, 160 x 120, 5 min 33 sec, ~29 mb) - contains only the Bungie East tour; the rest was never part of the file (see [http://web.archive.org/web/20000817095745/www.bungie.com/btv/archive/ here]; look at the filename)
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day2_big.mov Day 2] (mov file, 160 x 120, 38 min 30 sec, ~182 mb) - best vid, trip to Bungie West (Oni headquarters) plus Steve Abeyta shows some disarm moves
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day3_large.mov Day 3] (mov file, 160 x 120, 29 min 07 sec, ~217 mb) - see content pic above, lots of blah blah plus a ingame Halo preview at the end
*[http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/bTV_day4_100.mov Day 4] (mov file, 160 x 120, 37 min 22 sec, ~277 mb) - see content pic above, very short ingame Halo preview, rest blah blah

You can also download day two, three and four in very extra low poor quality [http://hl.udogs.net/files/Gaming/Bungie%20Related%20Movies/MWSF%202000/Bungie%20TV/MWSF%202000/ here] (first three links, 5 to 12 mb), but that's more pixel art than a video. [[User:Ssg|Ssg]] 00:10, 20 January 2008 (CET)

::Cool, look forward to watching these. --[[User:Iritscen|Iritscen]] 15:36, 5 March 2008 (CET)
::I'm going to be linking the Bungie West and East articles to the tour vids (Day 1 and Day 2), so hopefully these files will stay around for a while. Can I count on that to be the case? --[[User:Iritscen|Iritscen]] 15:01, 20 March 2008 (CET)

??? Why are you asking me that? I have no influence in the matter. [[User:Ssg|Ssg]] 00:28, 22 March 2008 (CET)

==Bluebox screenshots==
:About the BBBB screenshots you've been adding to [[BINA]]
:#It would be nice if you described how they were obtained.
:#Are you sure '''navi.TXMP''' and '''buttons.TXMP''' are appropriate?
:I'm pretty sure there is another, more plain-looking TXMP.
:Not '''g206_controls_128x64.TXMP''', but something close...
::[[User:Geyser|geyser]] 20:14, 24 September 2007 (CEST)
----
To 1:

#added WMDDs from Level0_Tools.dat to Level0_Final.dat
#replaced the dialog ID (0x108) of the [[OBD:WMDD|WMDD]] with the dialog ID of the help-window (or whatever it's called; it's the window that pops up when you press F1)

To 2:
:I'm not sure what you mean. Do you refer to the fact that some stuff in the iamges is overlapping? (If yes: Well, I never thought about that. I was too fixated on making the WMMDs visible, I guess.)

'''Edit'''

I've changed in the last part of the dat file the name psui_oniUI to psui_oniUi. After that Oni reads the psui_g206 file. The result is this:

now: http://ssg.oni2.net/subfold/bluebox/g206_306_edit_combat.jpg before: http://ssg.oni2.net/subfold/bluebox/images/306_edit_combat.jpg

[[User:Ssg|Ssg]] 14:59, 11 December 2007 (CET)

Short note: if there are still dialogs from tools.dat that you do not have screenshots for here you go:
http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/tools_wmdd.zip

[[User:Neo|Neo]]

Cool. Thank you. Did you managed it to "actiivate" the "Tools" files? [[User:Ssg|Ssg]] 01:19, 12 December 2007 (CET)

If by activate you mean loading tools.dat in Oni then no. (Though I converted tools.dat to PC format but Oni crashes if it finds it and I did not bother to check why). Those images were generated with my viewer.

[[User:Neo|Neo]]

Sorry for interrupting you guys a bit.
I saw the new WMMDs.. Are you going to upgrade OniSplit or OUP like Bungie's original editor tool? That would be cool. How far are you done? 
By a side note: on "dialog_character_properties.png" you can see three different shields. So, maybe the (red one) "boss shield" was editable?
:[[User:Paradox-01|Paradox-01]] 17:53, 12 December 2007 (CET)

Would it be possible for me to get a copy of Bluebox since I'm on the Mac?
[[User:EdT|EdT]]

Alloc or geyser can help, I guess. [[User:Ssg|Ssg]] 02:02, 20 January 2008 (CET)

==Homing Weapons?==
Hi, Ssg. I was looking over the weapons class in the Oni binaries, and I can't find where it records that certain projectiles, like the Scram cannon's, are homing. Isn't there a bit for that? --[[User:Iritscen|Iritscen]] 19:57, 28 February 2008 (CET)
:Homing is a property of the projectile, not of the weapon class. You want to look at [[OBD:BINA/PAR3]].
::[[User:Geyser|geyser]] 23:14, 28 February 2008 (CET)
:Oh... Sorry, Iritscen, didn't see your question.
:Thanks for the answer, geyser. :-)
::[[User:Ssg|Ssg]] 23:04, 4 March 2008 (CET)
Yes, thank you. I have a neat weapon-modding idea I'd like to try. This would be my first modding attempt (we'll see if it works, I don't want to promise much, and it's a simple idea anyway). --[[User:Iritscen|Iritscen]] 15:32, 5 March 2008 (CET)