XML:ONLV

ONLV : Oni Game Level	XML modding tips See HERE to start learning about XML modding. See HERE if you are searching for information on how to handle object coordinates. See HERE for some typical modding errors and their causes.
XML ONLD << Other file types >> ONSK switch to OBD page

ONLV and AKEV should not be extracted as XML unless it is for the purpose of trouble shooting or research. The extracted XMLs cannot be used for level creation.

If you want to create a new level check out the corresponding tutorial.

ONLV

XML tag	Content type	Description
<ONLV id="...">	integer	ONLV's instance number. Should be 0.
<Name>	char[64]	Name of BSL folder. Save game slot and level number are defined inside ONLD.
<Environment>	link	Link to AKEV via file name (AKEVname, don't use file suffix .oni) Level geometry.
<Objects>	link	Link to OBOA via instance number (#N). The OBOA instance holds doors, animated objects (usually for cutscenes) and pushable objects (which are not used the original game due to unfinished physics code).
<SkyBox>	link	Link to ONSK via file name (ONSKname, don't use file suffix .oni) This is the skybox.
<Characters>	link	Link to AISA via file name (AISAname, don't use file suffix .oni) This "AI Setup Array" is an alternative character list. BINACHAR is more powerful.
<ObjectQuadMap>	link	Link to ONOA via instance number (#N). This "Object Array" holds functional objects – doors, furniture, turrets, triggers and consoles. In addition, it appears that the engine only searches for door-type objects.
<Particles>	link	Link to ENVP via instance number (#N). These "Environment Particle" are traditionally only used for door lock lights and particles used by OFGAs.
<Corpses>	link	Link to CRSA via instance number (#N). This is a "Corpse Array". It's used to spawn dead characters such as Chung in Chapter 1.

OBOA

Used for movable/moving objects.

XML tag	Content type	Description
<OBOA id="...">	integer	Instance ID. Should be 1.
<Objects>	-	Array of <OBOAObject> tags.
<OBOAObject>	-	There are always 32 empty objects plus those that are actually used
<Geometry>	"#" + integer	Link to M3GA instance. Doors have two separate models: an animated and a static one. If this <Geometry> links to a door, it will be the animated model.
<Animation>	link	OBANname.
<Particle>	# + integer	Link to ENVP instance. There can be multiple ENVP instances – one for a lock light and others for additional particles.
<Flags>	flags	None InUse NoCollision (any effect? no collision is default behavior) NoGravity FaceCollision (for doors)
<DoorGunkId>	int32	The index of the door frame GQ (only used for door objects)
<DoorId>	int32	Only used for doors; in the case of double doors, both doors have the same ID and they are flagged as "InUse FaceCollision"
<PhysicsType>	flags	None Static Linear (pushable object) Animated (animated via OBAN) Newton (same as Linear)
<ScriptId>	int32	Scripting ID; used by BSL function obj_create; "65535" means not used.
<Position>	vector	Float x3. Not used for animated objects.
<Rotation>	quaternion	Float x4. Not used for animated objects.
<Scale>	float	Not used for animated objects.
<Transform>	matrix	Float 3*3 + 3 more floats for the X Y Z position of the object. For more information on the matrix, see OBD:CRSA. Used for animated objects.
<Name>	char[64]	Name of the object; informational only.

ONOA

Used by static objects (imported by object list).

XML tag	Content type	Description
<ONOA id="...">	integer	Instance ID.
<Elements>	-	This is an int32 array for the <ONOAElement> tags.
<ONOAElement>	-
<ObjectId>	integer	Object ID and type to which this quad belongs (see AKEV's AGQG for details). Actual object IDs can also be found in BINA/OBJC/####.
<QuadList>	"#" + integer	Link to IDXA instance. Each object has its own IDXA instance.

Where do the links go to again?

ONOA <ObjectId> -> AKEV AGQG -> BINA/OBJC/#### by type and ID
ONOA <QuadList> -> ONOA IDXA -> AKEV AGQG by order

ENVP

XML tag	Content type	Description
<ENVP id="...">	integer	Instance ID.
<Particles>	-	This is an int16 array for the <ENVPParticle> tags. If there's not going to be any contents, you put <Particles /> here.
<ENVPParticle>	-
<Class>	char[64]	BINA3RAPfile.oni (don't use file prefix/suffix).
<Tag>	char[48]	Particle's scripting name for BSL commands; see OFGA for more information on name composition.
<Transform>	matrix	Float 3*3 + 3 more floats for the X Y Z position of the particle. For more information on the matrix, see OBD:CRSA.
<DecalScale>	int32, int32	X Y
<Flags>	flag	None NotInitiallyCreated

CRSA

XML tag	Content type	Description
<CRSA id="...">	integer	Instance ID.
<FixedCount>	integer	The array capacity of <Corpses> is larger than the number of "fixed"/"used" corpses in order to allow the engine to store new corpses at runtime. "Fixed" means that those corpses are never overwritten/deleted at runtime – all new corpses are stored after the "fixed" ones. This means that "fixed" <= "used" <= "capacity".
<UsedCount>	integer
<Corpses>	-	This is an int32 array for the <CRSACorpse> tags. By default, Oni wants 20 slots for corpses. Unused corpses have their matrix and bounding box filled with zeroes.
<CRSACorpse>	-	New corpses can be made with the BSL command make_corpse filename and some hex-editing. The pose of the corpse is taken from the player character. The contents of the files thus created can then be inserted as elements in a level's CRSA.
<CharacterClass>	link	ONCCname
<Transforms>	-	There are 19 <Matrix4x3> for each <Transforms> (which represents a body part).
<Matrix4x3>	matrix	Float 3x3 + float x3 for the last 3 values (X Y Z position). For more information about the matrix, see OBD:CRSA.
<BoundingBox>	-	Bounding box of the whole corpse.
<Min>	float x3
<Max>	float x3

M3GA

There can be one M3GA instance per animated object. Animated meshes of doors are embedded in ONLV. All other animated meshes are stored outside it as M3GM files.

XML tag	Content type	Description
<M3GA id="...">	integer	Instance ID.
<Geometries>	-	This is an int32 array for the <Link> tags.
<Link>	link	#N (instance number) (for non-door) M3GMname (for door) It can happen that you see here references to DAE files. This happens when the ONLV was created with some older OniSplit version (like 0.9.86.0) and if the ONLV was converted to xml in absence of the resources used by M3GA.

M3GM

Read about them here HERE. Note that M3GMs have their own component instances: PNTA, VCRA (x2), TXCA, IDXA (x2). Doors store their animated model in ONLV, while the static model comes from BINACJBODOOR.oni, which also links to M3GM files.

IDXA

XML tag	Content type	Description
<IDXA id="...">	integer	Instance ID.
<Indices>	-	This is an Int32 array for the <Int32> tags.
<Int32>	int32	From ONOA to AGQG elements Link to <AGQGQuad>s in AGQG by order. (The array in AGQG starts with 0, so for example <Int32>6</Int32> would link to the 7th <AGQGQuad>.) From M3GM to PNTA elements Read more HERE. From M3GM to VCRA elements Read more HERE.

Level files hierarchy

(un)colored cell = file

striped cell = embedded instance

ONLV
	AKEV
		PNTA
		PLEA
		TXCA
		AGQG
		AGQR
		AGQC
		AGQC
		AGDB
		TXMA
			TXMP
		AKVA
		AKBA
		IDXA
		AKBP
		ABNA
		AKOT
			OTIT
			OTLF
			QTNA
			IDXA
		AKAA
		AKDA
	OBOA
		M3GA
			M3GM
				PNTA
				VCRA
				TXCA
				IDXA
				TXMP
		OBAN
		ENVP
	ONMA
	ONFA
	ONTA
	ONSK
		TXMP
	AISA
		ONCC
		ONWC
	AITR
	ONSA
	OBDC
		M3GM
			PNTA
			VCRA
			TXCA
			IDXA
			TXMP
	ONOA
		IDXA
	ENVP
	CRSA
		ONCC