User talk:Neo
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.
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.
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)?
--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.
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.
Oh boy, were Mono developers lazy or not... :)
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.
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.
Hey Neo, do you have any idea what the flag "Boss" does?
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.
Hello again. I am thinking of writing the Windows GUI for Onisplit. What scripting language would you suggest I write it in?
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.
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.
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. rossy 12:55, 23 June 2008 (CEST)
Why would I want to open binary files? O_o. For detecting the type of .oni file I give it? I have not worked with AutoIt3 before, but it doesn't look too hard, and I'm sure my conglamerated knowledge of random scripting languages will help me...
Gumby 16:57, 23 June 2008 (CEST)
http://gumby701.googlepages.com/gui.exe
Look, its a GUI! That doesn't do anything...
...and needs properly aligned and formatted...:D
Gumby 02:23, 24 June 2008 (CEST)
One more beta for OBJC: Beta 5.
Fixed character flags and added move type names and parameters names to melee (instead of numbers and Param0, Param1 etc.).
This makes reading the melee much easier. I wish I had some time to play around with making a new melee profile.
Is this a bug or just an error in the original code. In the NINJA_Easy profile I found this technique:
<Technique> <Name>Back Kick</Name> <Flags /> <Weight>40</Weight> <Offset_0660>10</Offset_0660> <RepeatDelay>0</RepeatDelay> <Moves> <Position Type="CloseBack" MinRunInDist="0" MaxRunInDist="10" ToleranceRange="4.5" /> <Attack Type="PB" /> </Moves> </Technique>
Even though it says Back Kick, the attack is Punch Back.
The wiki has some pages about various melee profiles and it contains the same thing: OBD:BINA/OBJC/MELE/NINJA. So either it is just a mistake in the melee profile or the move type wiki tables are wrong, I'll have to check with the executable.
Hey. I got a bit of the Windows GUI done. It wasn't too hard...and tell me if the icons arent there (either for the explorer icon, or the one in the top right corner)
http://gumby.oni2.net/GUI/LevelRecombine.exe
Yes, the icons are OK. But is it supposed to do anything? That recombine button appears to have no effect.
I was looking at the attack moves on this page: http://wiki.oni2.net/OBD:BINA/OBJC/MELE/MoveList And I gave one a try, Attack Move #28 KF KF, but got an error in OniSplit.
Edit: Cleaning up.
EdT 03:56, 30 June 2008 (CEST)
It's KF_KF, I cannot have spaces in those names.
Thanks, now do you think the names of the moves on the MoveList page should match the ones in OniSplit? For example on the MoveList page it has Throw-P Behind Disarm but OniSplit has it as P_BehindDisarm. There are many differences between the MoveList and OniSplit syntax.
I'm sure others will have the same issue as they start modifying the melee profile.
EdT 16:16, 30 June 2008 (CEST)
Well, spaces and - are not allowed in there. As for the Throw- prefix I just removed because it's kind of dumb to write <Throw Type="Throw_P_BehindDisarn".../>.
The best I can do is to make sure that space is consistenly converted to _ so instead of RunLeft you get Run_Left which is closer to that table.
I think we should change the syntax on the wiki to match OniSplit. Like for example change the wiki entry Throw-P Behind Disarm to P_BehindDisarm. The reason for this is when we want to modify the melee profile, we will look at the wiki and use the syntax there and put it in OniSplit, then we get errors. But if the wiki has the syntax the OniSplit will use, that will eliminate the problem.
Is there a way to get the moves syntax from OniSplit? Then I can start updating the wiki.
EdT 22:48, 30 June 2008 (CEST)
I added a "-help enums" option which dumps a list with all enums and flags used in XML files. Since otherwise it seems to work fine I dropped the "beta" label.
Feel free to update the wiki if you want but I'd say to leave it like it is. The wiki is about Oni internals, not about OniSplit.
Thanks for the -help enums. I found a difference between the wiki movelist and the OniSplit enums.
Wiki: Attack#43 KKP and Attack#51 HK, OniSplit does not have them. Thus the wiki has a total of 83 attacks and OniSplit has 81 attacks.
I was in the process of making a movelist page for OniSplit users.
EdT 01:59, 2 July 2008 (CEST)
Oops. Fixed: OniSplit 0.9.19
I had an interesting idea today. If the only difference between a .dat file and a .oni file is that in a .oni file the .raw entries and .sep entries are stored at the end of the file, it might be possible to write a small engine hack which allows Oni to load .oni files directly as level plugins. The problem is, I'm not sure whether it would be useful or possible yet.
rossy 12:56, 2 July 2008 (CEST)
Well, in theory it is possible but: - we may need to add the raw/sep parts at the end of existing .dat files too because supporting both styles of loading raw/sep is more difficult to implement - what about Mac? I may as well rewrite all the .dat loader and replace the original one by means of vtuneapi.dll/daodan but I don't know how new code can be loaded on Macs.