OniGalore

User talk:Geyser: Difference between revisions

User page Discussion

User talk:Geyser (view source)

Revision as of 19:41, 30 January 2007

19,971 bytes removed ,  30 January 2007
m
moved everything OBD-related away
(fiexd spelling)
m (moved everything OBD-related away)
Line 1: Line 1:
*M3GM talk/info moved to [[OBD_talk:M3GM]]
*Overlay TRAM talk/info moved to [[OBD_talk:TRAM/raw0x34]] (page name subject to change)
*General OBD talk moved to [[OBD_talk:Oni Binary Data]] for further sorting
**that includes adding stuff to DAT, static object IDs, the Fight of the Century, all that... ^^
*Pathfinding & Co  moved to [[OBD_talk:AKVA]]
----
:Hey Geyser
:Hey Geyser
:I sent you an email last week, perhaps you didn't get it.
:I sent you an email last week, perhaps you didn't get it.
Line 481: Line 487:
:Motoko is already there, sorta. "askaninja" sounds weird.
:Motoko is already there, sorta. "askaninja" sounds weird.
::[[User:Geyser|geyser]] 21:20, 25 December 2006 (CET)
::[[User:Geyser|geyser]] 21:20, 25 December 2006 (CET)
----
==Pathfinding etc==
:Hi Geyser,
:Do you know where the data for the pathfinding grid is stored?
:I am asking because I am fed up with AIs being permanently stucked in walls or doors,
::because of missing red aka "STOP" pathfinding tiles. Thank you in advance
::[[User:Loser|Loser]] 13:49, 27 December 2006 (CET)
----
:I've been looking for the grids for some time, without much success.
:BNVs are almost certainly related to pathfinding, and maybe the BSP trees, too.
:But I have no clear picture right now, and no time to investigate.
:(BTW, when I have a clear picture of anything, I document it pretty soon ;) )
:See [[OBD:BINA/TMBD]] for texture-material assignments. You can make anything breakable by gunfire/combos now.
:Also, it's pretty easy to fix the stupid curbs (sidewalks etc) so that you don't have to jump over them.
:Or to reveal the hidden doors in the warehouse. But here we come to the pathfinding issue again.
:Pierre has asked several unanswered questions on the forum, one of them about the blocking algorithm for AI.
:Could you describe the effect of the blocking parameters known to you [[OBD:BINA/OBJC/MELE|HERE]]? Thank you.
::(for my part, I've looked into a few TRAM-related things concerning melee: SABD, attack RAW-chunks...)
:As for your semi-question [[OBD:BINA/OBJC/CMBT|HERE]]:
::it seems that both *Run For Alarm* behavior and *Run To Alarm* If no gun events are bugged in the same way and are defunct.
::Or there are missing labels "this is alarm console, you silly AI" in console files.
::I don't know and I think we can live without that.
::Or do you think about something else???
:I have absolutely no idea what you're talking about...
:Don't assume I've been hacking the same things as you.
::[[User:Geyser|geyser]] 17:42, 27 December 2006 (CET)
----
:Update on pathfinding grids.
:I'm almost certain everything you need is in the [[OBD:AKVA|AKVA]].
:Running around after doing '''chr_show_bnv=1''' and '''ai2_chump'''
::strongly suggests that there's one BNV per grid and vice versa.
:Various "big" parameters of the grid will be in th DAT,
::and the tiles I'd expect to be in the RAW.
:Good hunting. And be sure to update the related pages if you're lucky.
::[[User:Geyser|geyser]] 19:24, 27 December 2006 (CET)
----
AKVA & pathfinding:
:<strike>MY left arm is raised into the air under 45°--> and two fingers up</strike>. Geyser, you are '''GENIUS'''!!!! THANK YOU VERY MUCH!!!
--[[User:Loser|Loser]] 05:10, 29 December 2006 (CET)
:Doing dubious gestures with your arms and fingers isn't the best way to thank me...
:Please tell us all you know about melee profiles: specifically, blocking parameters.
:You could also tell me more on those "Run For/To Alarm If Whatever" behaviors...
:But I suppose you're too busy hacking pathfinding grids right now... ^^
:Happy New Year
::[[User:Geyser|geyser]] 21:22, 29 December 2006 (CET)
----
:Ok ok DON'T FROGBLAST the Loser's core!!! aka I apologize for my salute...
:Of course I am hacking pathfinding grid like some maniac now and my opinion on ONI's *AI stucking in everything* is more and more sharper. It seems that 3/4 of the whole AI stucking problem is simply undone and not enough tested pathfinding grid. I did some experiments and results are very promising (AI does't stuck in the door or on staircase when chasing you), so we will see and maybe I will release pathfinding patch for level 1 via Oni UnPacker. BTW there are some relicts of earlier layout of obstacles still visible in the grid ^_^
:About those alarm features:
:First, we have "Run For Alarm" CMBT behavior. When you assign it to some distance and let AI notice you and be in that distance, AI will simply freeze and don't move. If AI has weapon, it will fire at you, but not moving with exception of weapon dodge event. IMO this behavior is only half-functional. But problem is that if AI is in *run for alarm* state (by ai2_doalarm for example) it needs '''console to run to'''. You can try a little experiment: tell AI to use console that is behind locked door. AI will ignore that command and act as usual with its behaviors. But what if BEHAVIOR is to use console behind locked door??? AI will freeze. With "Run For Alarm" it is similar, only there aren't any locked door but IMO there are missing (or I hope only disabled) labels *FOR ALL AIs: '''this''' is Alarm console* in console bina data. So...what console we are running to, if there isn't any but it is setted as behavior??? We will freeze ^_^. But I think this behavior was abandoned somewhere in alpha version because there is missing quite important "What should I do, if there is no labeled console in "Alarm console search distance"???
:Second, there is "Run to Alarm" event that belong to "If no gun" slot. So after AI ,which is armed, deplete all its ammo, it should run for alarm. My opinion is similar to that one above, only with exception that there is "What should I do, if there is no labeled console in "Alarm console search distance"??? Answer is in this case "act as usual". Or this whole thing is defunct and ignored, but I don't think so even if I don't have any evidence for that.
:Third, happy New Year 2007 and may the almighty God bless you !!!
:--[[User:Loser|Loser]] 19:22, 31 December 2006 (CET)
----
==Adding files to DAT==
:Hi Geyser,
:Can you tell me please how I can add file to level.dat structure???
:I have figured that I have to add something at the beginning of the file and at the end of the file.
:But Oni still BLAMs. Can you tell me what is needed???
:Or, can you tell me( or us, if possible) how can I import files into dat structure via OUP?
:Thank you in advance
::;Loser
:Hi. I suggest you to try and have a little patience or something. ^^
:Oni modding (especially BINA) is modular, so why can't you deliver a few more quality BINAs?
:Whatever you are up to, any modular modification will come in handy when you release something big.
:I understand you're a bit like me: figure out something, have a little fun, move on...
:But that's not very rewarding. For you, maybe, but not for "us"... Oh well.
:ssg has tried adding files to a DAT before you, and failed. Have a look [http://www6.fh-eberswalde.de/user/dkriesch/onistuff/subfold/datfile/datfile.htm HERE] if you haven't already...
:There's a lot of stuff to take care of, and it's definitely not something you should do manually.
::(not that it's impossible, but even if you manage to do it, it will be of no ''general'' use)
:Alloc's OUP is ''almost'' there: a little while ago it was able to pack together whole level archives.
:There seems to be a bug somewhere that causes incorrect packing of the textures, and can cause Blams, too.
:You could get the latest version and help us figure out where exactly the repacking goes wrong...
:So "I'm sorry. I can't help you now. No one can." ^^
::[[User:Geyser|geyser]] 17:09, 12 January 2007 (CET)
----
<i>"ssg has tried adding files to a DAT before you, and failed."</i>
:
Only 50% correct. I've failed to add a character to the level0.dat file, because Oni wants all  named files in the dat-head/part2 in alphabetical order. First according to the file extension and then according to the file name. I didn't know that, when I've added the new character, so Oni crashed.
:
But it's not a problem to add unnamed files to dat file. F.e. I've added all WMDD's of the level0_tools.dat to the level0_final.dat without problems.
:
PS: I've read that you've fixed the Mac enter-key bug. And you (and Loser?) figured out the pathfindig grid data. Wow. I'm impressed.
:
Btw, what does BNV stand for? IMO V = volume, because it is one. But B and N. Any ideas?  Perhaps B = binary?
:
PPS: Remember the hidden doors of level 1? The gunk quads in front and behind door 11 (~ door position: -320 0 -450) are 18454 and 18455. If you open the AGQG file of level 1 with OUP and open these packages and change the last bytes from 00 00 10 02 FF FF FF FF to 02 00 10 02 FF FF FF FF, you can make the wall invisible (maybe you can hide it with env_show; I haven't tested that). Unfortunately you can't pass the door, because there's still another invisible wall. But I don't know the ID of it. (Package 31789 has the same points as package 18455, so I've changed it too, but no luck. I couldn't pass the door even though.) Plus the door has no doorframe, so it hangs in the air.
:
PPPS: The Blue Box "Mac exe" contains some more debug messages than the "PC exe". Maybe you can hand over the level0_tools + level0_final + the "Mac exe" to EdT. Perhaps he can enable the level0_tools files (because there's no message to skip it). Btw, the readme of the Blue Box Oni says, that it is version 1.1 . Maybe we should check, if there are other version out there.
:
PPPPS: To SNDG (from BINA/Sound): Imo : It stands for Sound Geometry and not Sound Group.  amb.OSBD and imp.OSBD are called up first. These link to grp.OSBD and this to a SNDD file. Imo SNDG doesn't call up the grp.OSBD directly.
:
PPPPPS: Gosh, it's snowing like hell outside. The first snow this year.
:
<p align=right>[[User:Ssg|Ssg]] 09:29, 25 January 2007 (CET)</p>
----
:Why, hi there ssg, long time no see ^^
::"snowing like hell" = LOL
:First off, a little rant: try to be more careful with the "done" label on Oni Stuff
::(how can you say M3GM is "done" when you have no idea how the VCRA and IDXA are interpreted in that specific case?)
:Oh, and another rant, about bitsets: once and for all, ''there is NO "0" bit''
:Now a question: where were we with the rehaul of OBD pages?
::One thing to consider is that wikibooks (PDF dumps of whole namespaces) can't include images.
:::So converting hex screenshots to tables seems worthwhile indeed.
:I don't care too much about initials (BNV, SNDG, all that...). As for BNV, N (or NV) could stand for Navigation. B could stand for Bungie ^^
:If you want to talk about specific files (e.g., SNDG), I'd recommend to use their respective talk pages. Why ''here'', dammit?
:And if you want to fix something that's obviously wrong (like that "sound group" thing), just go ahead ( !!! ).
:The BBBB (Big Blue Box Beta) is indeed interesting (particularly because of how it doesn't ignore the Tools),
::but it's not as unASM-friendly as OMNI's port (which is basically a debug build: all functions and globak vars are ''named''...)
:AFAIK, SFeLi is concentrating on that one (OMNI's) but he ''could'' give the BBBB a try. Keep looking for other vers, sure.
:Nameless DAT importing... How useful is this, actually? Aren't nameless files always part of a named file's hierarchy?
::Extra WMDDs is about where it ends, right? (OK, one can add lots of TXANs and animation TXMPs, but no ONCCs, definitely)
:I'll have a look at the hidden doors in level1. Fixing them is all the more appealing as now we can fix the BNVs, too...
::Thanks for the two IDs: they're a good start. I'll try to cath'em all (when I get some free time, heh).
:::Collision is probably defined separately from the visible geometry (in the AGQC rather than in the AGQG).
:Unfortunately, '''env_show''' only works for "objects" (static bike, van, truck, etc). Same for '''env_texswap'''...
::[[User:Geyser|geyser]] 15:37, 26 January 2007 (CET)
----
M3GM contains only links, so it's done. (I don't look to the hierarchy.)
:
VCRA and IDXA ==> [http://www6.fh-eberswalde.de/user/dkriesch/oni/werte.htm Any ideas?]
:
0 bit: It's just an info, that nothing happens when you write 0. ("once and for all" ==> Don't be so rough.)
:
"Now a question: where were we with the rehaul of OBD pages?" Dunno. I've stopped it. First you say I can do what I want, and when I do what I want, you say I have to hold on.
:
<p align=right>[[User:Ssg|Ssg]] 16:36, 26 January 2007 (CET)</p>
----
:I thought we were at a point where we were no longer offended by "roughness" ^^
::The "0 bit" info is misleading. All the bits in a bitset are cumulative
:::(and if they're all OFF, of course you get 0 = "nothing")
::But ''you'' make it seem like the only valid ("possible") values are 0, 1, 2, 4, 8, etc.
:::(which is what is misleading: the only options are 1, 2, 4, 8, etc; each one of those options is either ON or OFF)
::In other words, your list gives "everything OFF" too much of a special status. It's... yes, misleading.
:IDXA and VCRA (and PNTA, even) are generic: they get interpreted in different ways depending on where they're linked to ''from''.
:In particular, the parsing of the first IDXA is non-trivial and highly specific (see the source for Pierre's OniRip).
::(when you say "That's clear.", could you be more precise? are you sure you understand what face goes where and why?)
:Actually, the high bit denotes, ''in this specific case'', the first vertex of a "strip": they're ''not'' triangles.
::(and in other cases, the high bit will mean something completely different)
:Knowledge about IDXA etc should be detailed specifically to the resources that link to them: for example, the M3GM.
::Look at your [http://www6.fh-eberswalde.de/user/dkriesch/oni/werte.htm werte.htm] again. See how all the generic sub-resources of an M3GM are connected? They simply don't make the same sense when considered out of the M3GM's context...
:That's why I say M3GM is not "done": because [http://www6.fh-eberswalde.de/user/dkriesch/oni/werte.htm THIS] is missing knowledge relative to ''M3GM'', ''not'' VCRA or IDXA...
::Sometimes the hierarchy is crucial, i.e., you have to consider a file together with its children/parents.
:I'm surprised your page doesn't include a listing of the TXCA. How can you be sure it's irrelevant? (ah, OK, it's parallel to the PNTA...)
::As for the first VCRA: they are vertex normals (basically, averages of the face normals for the adjacent faces). Normalized.
:::Oni (OpenGL) uses them for [http://en.wikipedia.org/wiki/Gouraud_shading Gouraud shading].
:As I told you above, the first IDXA lists triangles not one by one but as strips.
::The second IDXA then groups the triangles (sub-elements of the strips) into bigger faces.
:::The second VCRA refer to those big faces, which can be quads or even more complex groups.
:I'm not sure why so many entries are necessary for the PNTA and the first VCRA. To fix vertex lighting?
::Gouraud will only look nice for rather smooth objects, such as a head; err, for Konoko's head, actually, it's rather ugly
:::And it's totally unadapted for box-shaped objects, which are ''supposed'' to appear square, not smooth.
:I'd expect there to be a flag somewhere that turns Gouraud on and off.
::If there's none, then vertex shading will indeed have to be "fixed" for angular geometry.
:::Which means more PNTA and VCRA for a door than "needed" for a smooth "cube"... Almost stupid.
:Having a little look at that (and at [http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation quaternions], too)...
:Before you resume your update of the OBD pages, could you give me a list of field types you'll be putting in there? Maybe we should discuss those a little bit. That was what I suggested when I "told you to stop". A exhaustive list of data types will be useful for OUP, too (new struct def format, patching engine...).
:Another thing was our disagreement as for whether OBD table rows should be templated.
::Templates have an advantage: alignment and other cell attributes can be set globally in a nice-looking way. Only actually ''informative'' data needs to be entered on the "client" page.
::Templates have a drawback: unlike table rows, everything has to be on the same line (although one can hack around this, see [[Template:HexRow]])
:I also need your opinion (''again'', yes) on the templated tables (rather than GIFs) for the hex screenshots.
::They're more mirror- and wikibook-friendly.
:What do you think?
::[[User:Geyser|geyser]] 17:22, 26 January 2007 (CET)
==M3GM and overlay anims==
:Update. Last night I figured out both the M3GM&Co and the overlay anims. Happy ^^
:I'll be organizing that in the appropriate pages when I get some time.
:This is just a "public notepad".
::[[User:Geyser|geyser]] 00:33, 28 January 2007 (CET)
===M3GM===
:Most of the stuff is as ssg says [http://www6.fh-eberswalde.de/user/dkriesch/oni/werte.htm HERE].
:*PNTA, TXCA, first VCRA: vertex map (XYZ, UV, vertex normals). Vertex normals used for Gouraud shading.
:*Second VCRA: face normals, for flat shading (not sure the engine ever switches from Gouraud to flat) and specular effects.
:*First IDXA: polygon strips. Vertices are listed this way:
0-2-4-6-...-2n
  \|\|\|\...\|
  1-3-5-...-2n-1
::the positively oriented face are (0,1,2), (1,3,2), (2,3,4), (3,5,4) etc
::AFAIK, strips always have an odd number of triangles (and vertices).
::Strips refer to vertex IDs (those in the PNTA/TXCA/VCRA1). The first vertex of a strip is flagged with a high bit.
:*Second IDXA: normal groups. The triangles (listed in the order in which they appear in strips) are assigned to a face normal (VCRA2).
::[[User:Geyser|geyser]] 00:33, 28 January 2007 (CET)
===Overlay TRAM===
:Overlay anims use quaternions rather than quantized Euler angles to define rotations.
::That's because an aiming overlay uses a lot of interpolation (and quaternions are better at it).
:They all behave the same way except the '''*_arc.TRAM'''. Those are coupled to the TRAS.
::For an '''*_arc.TRAM''', the frames don't correspond to different moments in time, but to sectors of the aiming screen.
:Basically, such a TRAM holds, e.g., nine positions:
:*aiming high and to the right
:*aiming high
:*aiming high and to the left
:*aiming to the right
:*aiming straight ahead
:*aiming to the left
:*aiming low and to the right
:*aiming low
:*aiming low and to the left
:The TRAC specifies what maximum deviation of the aiming vector the extreme frames correspond to.
::A generic aiming direction in interpolated using that grid.
:There are 15 keyframes for RIF aiming screens (an extra column of 3 on the left and on the right)
:There are 6 keyframes for the prone PIS aiming screen (no bottom row, i.e., you can't aim down)
:The "used parts" and "replace parts" are bitsets that define for which bones the quaternions will indeed be read.
:For the aiming screen TRAMs, there are no "replace parts", and the "used parts" vary a lot:
:*For STRIKEstand_fire_arc.TRAM, only the head turns around, so the used part bitset is 0x00040000
:*For KONCOMstand_fire_arc.TRAM, almost every bone is affected by the aiming direction
:For the other overlay TRAMs, the "used parts" are 0x00010000 (chest), and the "replace parts" vary.
::[[User:Geyser|geyser]] 00:33, 28 January 2007 (CET)
----
M3GM: Again, they contain only links, so it's done. I know that there're different IDXA and VCRA files, so they are not done, because there is still no differentiation between the different files.
Bitset: As the name say, it's a bitset. So it's IMO not misleading.
door example: I don't agree with you, that they are "strips". Biturn says, that they're triangles and you have to read the first IDXA in this way:
http://www6.fh-eberswalde.de/user/dkriesch/oni/doorcode.gif
grey = high bit, red = same as the first column, yellow = same as the first row column but first and second value switched
If you read it step by step (I used Rhino3D), you get this:
http://www6.fh-eberswalde.de/user/dkriesch/oni/door.gif
The sceond IDXA contains the normal for every triangle. And IMO the normals aren't used for shading, but for the textures, to say to the texture: look with your front side to the same direction as the normal.
I only don't understand why ther're 16 points and normals for them.
OBD: You wanna discuss again? You have some questions again? I'm sorry, but IMO that are rethorical questions. IMO you only accept the answers, you want to hear.
So I'm not interested in to discuss it any longer.
What about this: I update the missing files in my way (when I have time). And after that you can alter them in your way (f.e. images as hex).
Something else: Level 1 Training, last room, where have to shoot the glass with the pistol. The first fixture on the left side. The lowest glass. You can hide it with "env_show 3003 0"
But the AGQG package ID is 3058 (I've checked it, I can alter the glass, if I alter that package). So where does Oni get the Information that the glass has the env_ID 3003? It's not in the OBOA file. And I couldn't find the 3003 in another file.
Retrieved from "https://wiki.oni2.net/Special:MobileDiff/4852"