User talk:Iritscen: Difference between revisions

Revision as of 18:51, 2 June 2008

Hacking Multiplayer

Who here was involved with that effort to hack multiplayer into Oni?

Memory search: Alloc, Kumo, typhen (leader) and me.

Programs: typhen (Onyx/OnyxPatcher), neonew (OniHook)

How was the multiplayer actually supposed to get implemented into Oni?

Overwrite the memory at runtime.

How much was accomplished?

Some memory findings (pointers, player/enemy values, ...). (All?) results are stored here (Used program: TSearch).

What were the obstacles?

Working in the memory in general

Find the pointers (because the pointer position varies from OS to OS and from level to level).

Time (as usual).

typhen stopped his efforts on the project in August of 2005 for real life (girlfriend).

Ssg 00:25, 15 February 2008 (CET)

Kumo contributed some pseudonetcode in C++ that was supposed to interface with Onyx.

Alloc's OniTrainer implemented most of the gathered knowledge as the project went.

(OniTrainer had no network component, but it was a good tool for experimentation.)

The problem with TSearching was with all the big dynamically allocated structures.

It was a rather crazy idea to figure out those structures without disassembling...

I think the project started in April/May 2005, so it spanned the summer of 2005.

neonew's OniHook was totally independent of Onyx, so it's another project, sorta.

I'm not sure whether neonew disassembled Oni's engine in order to do the hooking.

A fair amount of Oni's engine has been disassembled since, by both SFeLi and Neo.

The structures responsible for the "game state" and "character state" are known.

geyser 02:04, 15 February 2008 (CET)

Some history:

typhen came up with the project in December of 2004. The first steps in the memory were made with RAMCheat. In January of 2005 typhen found the (great) program TSearch and the real memory search began. In April of 2005 geyser joined the Oni community and two or three weeks later the Ikonboard-based Oni forum crashed. (Because of too many verbose postings by him. :p *just kidding* ;-)

Unfortunately Harry never made this forum available as an archive.

Ssg 11:57, 15 February 2008 (CET)

The crash in April 2005 was supposedly due to me posting over a bad connection, which corrupted the database.

My impression is that the actual project started in May 2005 and thus is largely covered on the after-crash forum.

That's where you can see typhen and Kumo exchanging pseudonetcode, typhen and me talking about sync philosophy...

geyser 12:22, 15 February 2008 (CET)

Thanks for the info, guys. And sorry for being something of a jerk yesterday, geyser. Now, you said that the structures for game state and character state are now known -- are you referring to runtime variables? I don't see where those are documented in the wiki, unless this sort of page covers that information. Is that whole structure just loaded into memory to be worked with at runtime, and do we know where in memory to look for it, or is that where the process became difficult, due to that whole "dynamically allocated" structure that you mentioned? --Iritscen 16:42, 15 February 2008 (CET)

"And sorry for being something of a jerk yesterday, geyser." Sigh. I just don't understand why you avoid gathering first-hand knowledge.

Since you have that much free time, why not really come to terms with the object you want to provide accurate documentation for? Sigh.

I must say you still post and edit a wee bit too compulsively (a hyperactive kind of hyperdedication), and with not enough second sight.

Sure, the wiki needs regular editors, but you pretty much "jumped on it like an oversexed hippo" (C) Bungie. Hope it'll wear off somehow.

^_^

The disassembled engine is only documented in private databases, and we do not plan to publish those in any foreseeable future.

The "game state" is a huge chunk of data holding various runtime variables and structured objects (other, big chunks of data).

In particular, the game state structure holds a dynamically allocated array of character objects, each with a character state.

The character state holds various runtime variables specific to a given character, much more than the static game content.

Dynamical allocation means that the space required for the structures is not part of the EXE; it's requested at runtime.

Depending on the history prior to the allocation, the dynamically allocated space may end up at a different location.

The ONCC has little to do with "character state". In fact, the character state holds a mere link to the current ONCC.

geyser 15:43, 16 February 2008 (CET)

General Editing Talk

Chapters and added value

Flipping through the stuff as I updated the page layout, I was really impressed with the quality of some of the "added value".

Keep up the good work, dude. I'm sure the chapter pages will grow (just a little bit) to be brilliant appetizers for all the rest.

geyser 03:38, 18 February 2008 (CET)

"I'm sure the chapter pages will grow (just a little bit) to be brilliant appetizers for all the rest." That's what I'm hoping; I just spouted some random stuff off the top of my head as I made each chapter's Added Value section, so there's plenty of room for corrections/additional insights. --Iritscen 15:48, 19 February 2008 (CET)

Importing from Blender

This is the place where EdT tells me what was wrong with that Griffin model I gave him. :-) What did you have to do to get it imported? (I know you already told me some of this, but let's state it here to lay the groundwork for the discussion.)

--Iritscen 15:59, 2 June 2008 (CEST)

Where do I start? :-)

Here's the basic workflow I use for Blender:

Export from Oni using AE Tools, option for Blender.

Import into Blender, using Collada 1.4

The 3D model will appear in a standing position. Do not change the rotation or position of the body parts.

Make the changes.

Export from Blender, Collada 1.4, options: triangles, disable physics, current scene. (I'm doing this from memory, I do not have access to Blender at work. will correct if necessary)

Import to Oni, using AE Tools.

Things to remember:

Each body part has a center point, when exporting from Oni as Collada, these center points are at the correct location. However, if new parts are added, then the center point must be set. To set the center point, position the cursor at the correct location on the body part, you will need to adjust it on all 3 axis. Then go to the menu Object: Transform: Set to cursor. (from memory)

When replacing a body part, its important that its rotation matches the original part. (How? I don't know... never done it in Blender). Also, the name must be exactly as the one replaced. Finally, the parent/child relationship must be re-established.

What went wrong with Griffin?

It appears there is an additional object connected to the new head, which needs to be deleted. The new head needs to be named correctly, it needs to be attached to the neck (parent/child). Finally the scale/rotation needs to match the previous head.

Perhaps, since I was working with the .dae version, and not the original Blender file, I was not able to export to Collada, it kept failing on me. Not sure why...

What did I do? I used Cheetah3D. I exported ONCCgriffin_generic as Collada, used FBXConverter to convert the file to .fbx. I also converted your new model to .fbx. I then copied the new griffin head to the griffin_generic fbx file, replaced the original head, set the correct rotation and parent/child relationship. Exported it out as .fbx, converted it to .dae using FBXConverter, then imported into Oni. Also, regarding the triangles not being connected in my model, I did not Optimize the model in Cheetah3D before exporting.

EdT 20:51, 2 June 2008 (CEST)

it's important that its rotation matches the original part Conceptually, this has to do with the "center point": you have to define not only a position for it, but also a rotation, and thinking of it as a "point" can be misleading. I have no idea how Blender handles this exactly, but I'd be surprised if it was working with ill-defined frames of reference. Therefore the "center point" mentioned by Ed must have an adjustable orientation property.

What went wrong with Griffin? If that's of any help, you can let me (or Neo) try and import him any time at all. When in trouble, there's nothing wrong with asking those familiar with OniSplit and/or the COLLADA format to have a look. What kind of masochist are you? If you're scared of me, try and "use" Neo. He may not help you all the way out, but he won't bite, that's for sure.

Oh, and I'm also very confused about work on Griffin began so long ago that OniSplit had some model exporting issues, which are now a part of the model, so the model is not able to be imported as is ... No bug report at all? Just what "issues" could we be talking about? Are those assumptions, maybe? Well?

geyser 20:16, 2 June 2008 (CEST)

geyser, sorry my terminology is not correct. What I called "center point" is the point where the body part will rotate around. I used "Rotation" as the orientation of the body part in 3D space. When the rotation for all the body parts is 0 for x,y,z, then the pose of the model is the default orientation. But since the pose in Blender is a standing pose, the rotation of the body parts is not 0,0,0. So if you replaced the head, with one that had a different rotation (even though it looked the same), the head will appear wrong in Oni.

Here's the link to Iritscen's Griffin: http://www.sendspace.com/file/uesl4u Also, you can find my version of Griffin here: http://drop.io/EdT_OniFIles