User talk:Neo

From OniGalore
Revision as of 09:04, 30 November 2008 by Gumby (talk | contribs)
Jump to navigation Jump to search

New OniSplit (beta) version: OniSplit v0.9.30

What's new:

  • SNDD importer
-WAV files (.wav, mono/stereo, 22.05KHz/44.1KHz, uncompressed(PCM)/compressed(MS-ADPCM)) produce SNDD files that are compatible with Oni PC retail.
-AIFC files (.aif/.aifc/.afc, mono/stereo 22.05KHz, compressed(ima4)) produce SNDD files that are compatible with Oni Mac.
Example
 OniSplit -create out_dir test.aif
 OniSplit -create out_dir test.wav


  • LOD support for creating TRBS files. This can be done by creating an xml file containing the following:
 <?xml version="1.0" encoding="utf-8"?>
 <Oni Version="0.9.29.0">
     <Instance id="0" type="TRBS">
         <Elements>
             <Link>barabus_body_1.dae</Link>
             <Link>barabus_body_2.dae</Link>
             <Link>barabus_body_3.dae</Link>
             <Link>barabus_body_4.dae</Link>
             <Link>barabus_body_5.dae</Link>
         </Elements>
     </Instance>
 </Oni>
and running the command (assuming the created xml file's name is barabus_body.xml):
 OniSplit -create out_dir barabus_body.xml
It's not strictly necessary to create 5 different geometries for each LOD. The following works just as well:
 <?xml version="1.0" encoding="utf-8"?>
 <Oni Version="0.9.29.0">
     <Instance id="0" type="TRBS">
         <Elements>
             <Link>barabus_body_1.dae</Link>
             <Link>barabus_body_2.dae</Link>
             <Link>barabus_body_2.dae</Link>
             <Link>barabus_body_2.dae</Link>
             <Link>barabus_body_3.dae</Link>
         </Elements>
     </Instance>
 </Oni>


  • An xml file can contain "links" to other xml/obj/dae files. For example you can have the following line in an ONWC xml file:
 <Geometry>pistol.obj</Geometry>
Assuming the file pistol.obj exists in the same directory an M3GM .oni file will be automatically created from it.
Relative paths work just as well:
 <Geometry>geometry/pistol.obj</Geometry>


  • The -create:subt, -create:txmp and -create:m3gm are sort of obsolete. They still work but now you can simply use '-create' (or just 'create'):
 OniSplit -create out_dir crate.dae
 OniSplit create out_dir -format:bgr555 -genmipmaps pic.tga
 OniSplit create out_dir subtitles.txt


  • Work in progress: the AKEV importer now reads Collada materials so the resulting AKEV is textured.
Sample levels:
TestLevel1 -- This level should look like this in-game: Image 1 Image 2 Image 3
TestLevel2 -- This level should look like this in-game: Image 1
A zip file contains the minimum needed to get a new level running in Oni. To "compile" a level extract it to a folder and run the following commands:
 OniSplit -create out -genmipmaps -format:dxt1 *.xml
 OniSplit -import:nosep . Oni\GameDataFolder\level1_Final.dat
(Of course, you need to change the output .dat file path to match your Oni installation path)


Neo

I did a quick update to 0.9.30 to fix a problem with relative paths handling.

Neo

Iritscen - looks like you've overlooked the 0.9.30 fix when updating OniSplit. Neo - thanks a lot, I'll try to test the new features and put them to good use.
Can someone tell me what was wrong with hexagon2.dae (unless it was just user error on the part of 'Scen?)? and what's up with using DXT1 for AKEV?
geyser 01:34, 11 November 2008 (CET)
DXT1 - well, you need to specify a texture format so you don't end up with bgr32.
Hexagon "wrongness" - not sure what exactly you are talking about. Sure, it needs to be scaled up a bit (somewhere between x20 and x40), it needs to be rotated a bit and some textures have non power of 2 sizes. Appart from that "it just works". Currently I'm investigating some "falling through the floor" problems but it appears that the problem is in OniSplit and not in Hexagon.
Neo
Well, I'm OK with bgr32, actually (and I'd be even more OK if I could use bgra32 ^_^ ) - it's not like the levels we're importing so far have hundreds of detailed textures... So the only critical flaw with hexagon was non-power-of-two texture sizes? is that really a critical flaw (as in "blam"), or did 'Scen mess up somewhere else (he's the one who reported a blam after importing hexagon2.dae; I didn't try)? About the scale - it's funny, what units is the original in, then? I thought the original was in millimeters, and hexagon2.dae in decimeters, so that it should be scaled up by 1.5 or 2, not more... 30 you say? huh. --geyser 02:00, 11 November 2008 (CET)
Well, maybe you're OK with bgr32 (or bgra32) but Oni is not :). I don't know what OpenGL exact behavior is for non power of 2 sizes (XNA throws an exception) but some (or all) hardware does not support this for texture with mipmaps.
That "blam" may have been caused by other stuff in the level that was not cleaned up. The sample levels I mentioned above are completly empty (they don't even have a splashscreen :)).
I don't know what the correct scale is but 20-40 looks nice, my first impression was like: "wow, halo 2"...
Neo
Are you sure Oni doesn't like bgr32 textures in the environment? why would that be a problem? AFAIK we can use bgr32 just fine. --geyser 13:02, 11 November 2008 (CET)
Hmm, right. I think it is actually generating bgra32 textures without the -format argument. Neo


Tested non power of 2 textures in Oni: it rounds to a power of 2 so the result has ugly black bands. Do no use such textures! :)
I found and fixed the problem with falling through the floors, and now the hexagon works fine.
In fact I'm quite impressed with it. The framerate is good, the octree visibility works well and moving around feels OK. I can even walk on some "pipes" if you know them.
In addition this thing is a very good candidate for experiments with pathfinding autogeneration due to its exclusive usage of ramps instead of stairs.
Neo
Good thing you like the hexagon despite the "wow, halo 2" impression. HERE are other models by the same (Russian) guy. All of them use ramps rather than stairs (so there you have more candidates for pathfinding autogen), but some of them are more specifically designed with FPS gameplay in mind. He released a new model last month, so I sent him another message: it would be great if we managed to contact him. --geyser 13:02, 11 November 2008 (CET)

I tried to extract the .dae from AKEVhexagon2.oni and got the following error message from OniSplit:

mono onisplit.exe -extract:dae hex3d level7_Final/AKEVhexagon2.oni 

 /level7_Final/AKEVhexagon2.oni
 /level7_Final/AGDBhexagon2.oni
 System.NullReferenceException: Object reference not set to an instance of an object
 at Oni.Imaging.Texture.Read (Oni.InstanceDescriptor txmp) [0x00000] 
 at Oni.Geometry.GeometryDaeExporter.WriteImageLibrary (Oni.InstanceDescriptor[] textures) [0x00000] 
 at Oni.Geometry.GeometryDaeExporter.WriteEnvironment (Oni.InstanceDescriptor descriptor, System.String filePath) [0x00000] 
 at Oni.Geometry.GeometryDaeExporter.ExportInstance (Oni.InstanceDescriptor descriptor) [0x00000] 
 at Oni.Exporter.ExportInstanceList (System.Collections.Generic.List`1 descriptors) [0x00000] 
 at Oni.Exporter.Export (Oni.FileManager fileManager, System.String sourceFilePath, System.String filter) [0x00000] 
 at Oni.Program.ExtractGeometry (System.String[] args) [0x00000] 
 at Oni.Program.Main (System.String[] args) [0x00000]

EdT 03:42, 12 November 2008 (CET)

I added a few characters to the hexagon level, but Oni constantly crashes within a few minutes of playing.
Video: http://edt.oni2.net/3D/hexcrash.wmv
Oni crash log: http://edt.oni2.net/3D/hexcrash.txt
EdT 02:23, 15 November 2008 (CET)
EdT, what TRAMs are you using? I don't recognize some of Barabus's moves. And that crash seems to have happened at Griffin's jumpkick (or whatever that was). Can you supply the Characters.xml you used for that? Gumby 06:48, 15 November 2008 (CET)
I'm not sure why does it crash, it appears to be texture related. Better send me your xml/dae files to see if I can reproduce.
Neo
Here are the actual .dat files for Mac and PC: http://edt.oni2.net/3D/Level7_Hex2.zip
The crash seems to be related the number of characters fighting, if there is just 2 AI fighting, they will fight for several minutes, then suddenly stop fighting, but no crash.
gumby, Barabus's new moves are from Loser's modified TRAMs AE:Combat_system
I apologize EdT, but I have to defend my work. If you mean modified attacks pack from AE:Combat_system, then-
  • Griffin does not have blue flashes in that version of TRAMs.
  • Barabus does not have special "Barabus only" moves in that version of TRAMs (refering to his modified throw)
So you probably have some of my work, but you mixed it with beta stuff of mine (Barabus's moves, I know I released such a pack, but not on AE:Combat_system page as it was unfinished) as well as with some other modifications (Griffin's blue flashes). So I don't think it is mine work causing any trouble this time ^_^.
BTW, Neo, you ROCK! --Loser 17:42, 15 November 2008 (CET)
Sorry, I have so many mods on my computer, that must have come from the Barabus jetpacking mod? But I don't know where I got the blue flashes for griffin... EdT 18:03, 15 November 2008 (CET)
The blue flashes come from overpowering a character with the Paradox's VR mod. Gumby 19:23, 15 November 2008 (CET)
Hmm. It doesn't even generate a crash report for me. The startup.txt ends in "running game...". Odd. Gumby 19:33, 15 November 2008 (CET)
Ed, you know modding isn't foolproof or bug-free, so it is never a good idea to mix "so many mods" when "pioneering". Stick to the original level0_Final, or to Loser's stable releases, and then if it works fine, you can add other mods - Very Carefully And Systematically. The example video you posted is not conclusive, but I see two possible reasons for the crash:
  1. The AI had possibly been fighting "for too long" without a pathfinding grid, endlessly attempting to find a grid until they break some kind of limit. This is unlikely because in original levels we've had huge battles in grid-less areas without a crash. Actually, to the best of my knowledge, the only crashes due to pathfinding overflow happen in places like AKEVlab at the main gate: there is a grid, but it is inconsistent with the obstacles, so the AI desperately try to pathfind through a closed gate (actually, this is one of the many glitches that set AKEVlab apart as the most mysterious level in Oni)
  2. Karen died, and then the camera looked/moved away from the dead body, which triggered the deletion of her character and the creation of a corpse. Probably some corpse-related resource is missing or corrupt. After a look at the binaries, I see that CRSA is present, but it has size and capacity 0, whereas Oni's original CRSA have capacity 20. It is easy to test whether CRSA overflow is indeed the problem: spawn an opponent, kill him, run/jump away. If this is the problem, this impies possible crashes in the original levels as well, if for some reason the number of corpses present simultaneously exceeds 20: Oni is supposed to clean them up, but may fail to do so.
geyser 20:08, 15 November 2008 (CET)
CRSA overflow seems to be the cause. I moved far away from the fight so all the characters stayed in view, Oni did not crash. But when I turned away from the characters that were killed, then Oni crashed. How do we correct the size of the CRSA for the hex level? EdT

In Level.xml... 

   <Instance id="13" type="CRSA">
       <UsedElementCount>0</UsedElementCount>
       <UsedElementCount2>0</UsedElementCount2>
       <Corpses>
       </Corpses>
   </Instance>

I'm not sure if you need to change one or both to 20. Gumby

Thanks for the info, the UsedElementCount refers to the number of corpses that are spawned ingame. For example in Level1, Chung is the only corpse, so both UsedElementCount would be set to 1. I added 20 instances of the tag <CRSACorpse> (including the rest of the code for this tag) to ONLVLevel and now Oni does not crash. EdT
Ed, please don't think of this as a "fix". Does is sound OK to you that every imported level must now have 20 superimposed Chungs floating around somewhere? It's a nasty workaround and Neo should be urged to handle the CRSA capacity properly. For example, there are no pre-spawned corpses in Rooftops, so a roundtrip of ONLVroof at this time would result in the same crash as the one you observed for the hexagon. This must be fixed, and I mean really fixed. --geyser 17:15, 16 November 2008 (CET)
Here's a dead-mole-less workaround for you: use OniSplit to pack ONLVLevel and ONLVroof into the same dummy .dat; use OUP to open that .dat and make ONLVLevel link to ONLVroof's CRSA; split the .dat again and ONLV will now have an empty CRSA with room for 20 corpses (size 0, capacity 20). --geyser 17:15, 16 November 2008 (CET)
Sigh, I'm not that stupid to have 20 chungs floating around. That was an example of the number for UsedElementCount. I added 20 blank CRSA. EdT
Yeah, sorry, that was posted in a hurry and there were quite a few false claims and hasty assumptions. The fact that OniSplit works with blank CRSAs removes the need for OUP in this case, and also allows original ONLV to roundtrip through XML. So, yeah, you've got a fix. Eventually, though, I think Neo could/should get rid of UsedElementCount2, whatever it is, and replace it with the capacity. Also, now that we know about CRSA overflow as a potential crash issue, we should keep it in mind while debugging original levels. --geyser 17:40, 16 November 2008 (CET)


Finally, is it possible to manually write pathfinding data for just that area of the level?
EdT 17:28, 15 November 2008 (CET)
Long ago I released a tool that allowed motivated people to (re)author pathfinding grids in ASCII: HERE IT IS. For simple areas, you could set up a complete BNV (AKVA) manually from scratch, and even OTLF could be updated by hand, but in this day and age no one would be crazy enough for that, not even me. Just wait until Neo implements autogeneration of pathfinding data. --geyser 20:08, 15 November 2008 (CET)


SNDD export bug

I wouldn't know about AIFC export, but exported WAV are unusable as of v0.9.30. Looks like the data rate dword (typically 0x00002B93) is written at 0x1E instead of 0x1C and the block alignment word is written at 0x22 instead of 0x20, overwriting the bits-per-sample word. Thus the block alignment is missing and the bits-per-sample are wrong. Please fix. --geyser 19:57, 16 November 2008 (CET)

Hi Neo, I apologize for bothering, but I have two questions.

1) I tried to make some trick with TRAMs, details omitted.

Subject - When character dies during some TRAM (throw), he cannot interpolate into another TRAM if there was set non-zero end interpolation.

Experiment:

  • Take KONCOMthrow_bk_k_tgt. Change its duration/number of frames to 0x69 and add end interpolation 0x10.
  • Now hurt (not kill) somebody with this backbreaker. Victim will interpolate into his fallen position.
  • next, kill him. Victim will get stuck in ending frame of KONCOMthrow_bk_k_tgt as his death position, he won't interpolate into his fallen TRAM.
  • Now remove end interpolation 0x10 (set 0x00).
  • kill victim now. When KONCOMthrow_bk_k_tgt animation ends, victim "jerks" into his fallen TRAM as his final resting position.

Is there any easy way to solve this, please? I ask because it looks like when character is dead, engine craps away its ability to interpolate. 5 seconds delay of this whould be enough. Or removing this restriction completely.

2)

Subject - Blue shield
Blue shield absorbs both damage and knockback. Is there a way how to make it absorb only damage, so character would be affected by knockback even tough he has blue shield?
I ask because then I could simulate throwing over obstacles with throws via PAR3. Now I cannot due to blue shield's knockback absorbtion.
Or is there any "cleaner" solution of throwing over obstacles (such as dynamic root height)?

Thank you for patience, --Loser 07:45, 30 November 2008 (CET)

I'll say what I can on the matter, if you don't mind. :)
@Blue Shield: Regardless of the ability to remove damage by knockback, you run into several problems:
  • Explosions would still knock you back
  • Explosions _might_ still do damage to you (I'd have to look at the asm, but from what I recall about PAR3, knockback is a type of damage. I never quite got how it worked specifically though, does it do actual damage?)
A better solution would be to somehow apply velocity to TRAMs. With velocity and the right flag (can't recall which...), the sphere tree would unstick.
Another thing: When a character goes over an edge, unsticking depends on either a time spent in the air or size of sphere (distance from ground), I can't tell which. I would hazard a guess that it has to do with time, but I'm not sure. :) If we can decrease whatever value it is, we could get what you are looking for. There is a chance it is a value in the ONCC or a constant in the engine. I'm not sure which. Gumby 10:04, 30 November 2008 (CET)
@TRAMs when characters die, they lose all ability to be animated at all. I know there exists a fix for characters losing MELE information on death (I lost it, gotta ask geyser next time he is on...), but there might also be a way to disable the disabling of animation on death. I know if you set a characters health to 0, attempt to animate it (fail), then set its health to something positive, the first thing he\she does is that animation you asked it to. So all hope is not lost. :) Then again, it might be a good thing you can't be animated after death. That could lead to some crazy bugs. :D Gumby 09:38, 30 November 2008 (CET)
Retrieved from "https://wiki.oni2.net/w/index.php?title=User_talk:Neo&oldid=13668"