User talk:Iritscen

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)