Creating overlay files:
	Disassembling overlay files:

The actor table manages the actor files (overlays). It defines an actor's number, maps the actor to a virtual address, and during gameplay is used to find the overlay in ram.

xxxxxxxx yyyyyyyy aaaaaaaa bbbbbbbb
rrrrrrrr iiiiiiii nnnnnnnn vvvvcc00

This breaks down into-
x y: Start/End Virtual Rom addresses of the actor file
a b: Start/End Virtual Ram addresses of the actor file
r: Ram address of actor file (00000000 if overlay isn't loaded, or if in ROM)
i: Virtual Ram address of the start of the actor instance initialization variables, located within the file
n: Address of actor filename (Debug ROM only, value is 0 in commercial releases)
v: Allocation Type, affects how overlay is allocated. See below for values
c: Number of actor instances of this type currently loaded (ram only)
Allocation Type Values

00 performs a "low to high" address allocation (high address volatility), unloading the overlay if no instances of that actor exist
01 performs a "high to low" address allocation (low address volatility), reserving a fixed space for all overlays of this type until the scene is destructed. Only one overlay of this type can ever be loaded at once. The pointer to this space is located at Game Play + 0x1C60
02 performs a "high to low" address allocation (low address volatility), keeping the overlay in ram until the scene is destructed

Note: The record for Link's actor in rom (the first record in the table) only sets the vram address that points to the start of the variable info 

code (File)
Actor Overlay Table
Version		Offset				VRom								VRam
Debug			0F9440	00B8D440	00B90F20	801162A0	80119D80
NTSC 1.0	0D7490	00B5E490	00B61F70	800E8530	800EC010
PAL MQ		0D4480	00B5C480	00B5FF60	800E5380	800E8E60

In zoras river:	

	Based on findings, modifying the last pointer in an actor (like the skultula token)
	can lean to crashes (but not always) modifying the value it points to also leads to a crash

	We have to perform a superslide, making sure the object we pick up is not destroyed in the process
	and then pass a loading zone.
	That way we get a Stale Reference.
	We can do something simmilar with the boomerang.
	We can abuse HESS with combination of the boomerang to pick up a rupee and cross a loading trigger. (need testing, but MM does
	something like this already)
Loading/unloading actors:
	As per testing, actors do not get unloaded in hyrule field (tried grass)
	Seems like the game is keeping them loaded all the time.
	We can try to abuse this by spawning bugs,fish,slingshot seeds,bombs,bombchus,etc. and try 
	to cause an Out-of-Memory condition.
	This means however that hyrule field is not a good canditate for SRM due to a lack of methods
	to force the game to unload some actors. (we can try OOM).
	Coincidentally, there are the weird rotating enemies that can spawn more enemies, each hit during night
	spawns more of the flying rotating things. (OOM)
	Confirmed that we can trigger an OOM condition in hyrule field. Bugs and fish do the trick well enough.
	Things just stopped spawning after the 4th bug drop + fish
	\*SR = Stale Reference

	800c3ff8 - in ram in game (gz practice rom)
	80b393c8 - in RAM of n64 file
		diff: 0xa753d0
	(address values only for reference, they are slightly different each session)
	801e97d0 - current holding item

	(link actor base)
	801daa30 -> 0x801dab4c <- value of stored pointer in links actor
				+0x11c	 |
		+ 0x30 to write links rotation to DP rotation.
			halfword gets writen and its the lower part of the word.
			so 0x32 to be precise
		+ 0xb4 to rotation of DP -> links rotation? this somehow also gets written, seems to be in the same place
			This is likely related to the drawable. It updates the position in the entity and then this
			so that the drawable gets drawn where the entity actually is.
		+ 0x248 to position of DP -> links position + offset above his head?
																	something probably calculates this before its written
		0x120 - Likely a linked list of entites. Every entity seems to have
				one. Its likely related to a linked list, pointing to
				relevant tables and next entity in RAM.
				- Checked cloud modding and indeed this is a pointer
				to the next entity of the same type.
		0x13c - "self" or "this" instance pointer (like in regular classes).
				- the pointer before this one points to a table
					when the boomerang is thrown, it updates a value
					following that pointer and ends up at an entry
					into the table. This could be the entity table
					drawable table, or other table.
					They each have their own pointers and values.
				- the word after this is filled with the pointer
					of a colliding entity (like a rock) after a flag
					lower in RAM gets set to 0xf (-1)?
		0x1bc - chase target for boomerang
		0x1c0 - stored pointer of carried object
		\written likely in multiple places
	We do not have direct control over where links data is coppied.
	We can only manipulate this by loading/unloading varius actors such as fish,bugs,bombchus,etc.
	in the given area.
	Walking through another loading plane clears the reference.
	I noticed something else was being updated when the SR was held. Possible the position above links
	head, bobing up and down with his breathing animation.
		Each actor (checked only npcs) has a very obvious 'solid' or 'collision' flag that when set to 0
		lets us walk through them. When set to 1, it detects them as solid and pushes us outwards.
	Boomerang notes:
		If objects despawn they are properly disassociated from the
		boomerangs caried object pointer.
== Helper projects == - perl script wrapper around mupen64plus built-in debugger console.
	Pretty good at this point.
	Could use:
		struct parsing or searching. At least links actor and its pointers for easier bug searching.
		object ID parser/translator
	Current save state has excelent 2nd rotation write and the rest seem to be in data sections.
	We can modify 1 instruction which modifies an offset against the base register $v0 (return value
	from function)
	Savestates 3 and 7 and 6 (?) are relevant
== Entity structure ==
	Coppied from CloudModding wiki
	typedef struct {
		f32 x, y, z;
	} Coord_f;

	typedef struct {
		s16 x, y, z;
	} Rotation;

	typedef struct
			char Damage : 4;
			char Effect : 4;
		} Attack[0x20];
	} z_ActorDamageTable;

	typedef struct
		/* 0x00 */ u16      id; //Entity Id. 
		/* 0x02 */ u8       type; //Entity Type. See Below
		/* 0x03 */ u8       room; //Room number the Entity is part of. FF denotes that the Entity won't despawn on a room change
		/* 0x04 */ s32      flags; //Special flags (green arrow, etc.) over the object, or identifying the object as invisible maybe
									//safe to call these misc flags for special purposes.
		// & 0x0040 0000 = Affects Entity lighting. 0 passes current coords to 80066298 func, else pass null for coords
		// & 0x0000 1000 = ?
		// & 0x0000 0040 = ?
		/* 0x08 */ Coord_f  pos1; // Looks more like spawn position x, considering we have rotation right bellow 
										//-(older comment)-Related to collision detection routine
		/* 0x14 */ Rotation initRot; //Initial Rotation when spawned
		/* 0x1A */ u16      unk_0x1a;
		/* 0x1C */ u16      variable; //Configurable variable set by an Entity's spawn data
		/* 0x1E */ s8       objTableIndex; //index to table at Game Play + 0x117A4 
		/* 0x1F */ u8       alloc_flags; // alloc / free / realloc  lags
		//with bush it just disappears when OR'ed with 0x1000, it seems like this is some sort of integer-bit-field for flags
										//could be a free'd flag? indicating if the object is to be freed or is freed?
										//kinda just disappears from ram altogether
		/* 0x20 */ u16      soundEffect; //Plays sound effect relative to Entity's location (if within range of camera?)
		/* 0x22 */ u16      unk_0x022;
		/* 0x24 */ Coord_f  position; //Current coordinates
		/* 0x30 */ Rotation speedRot; //0x32 sets what direction the 0x68 speedXZ variable is moving the Entity
		/* 0x36 */ u16      unk_0x036; //same as 0x1A
		/* 0x38 */ Coord_f  pos3; //Related to camera
		/* 0x44 */ Rotation rot1; //0x30 rotation copied into here
		/* 0x4A */ u16      rotation_on_x_axis;
		/* 0x4C */ float    unk_0x04C; /* I know this is a float from breakpointing it */
		/* 0x50 */ Coord_f  scale; //sets x,y,z scaling fEntity. Typically, a fEntity of 0.01 is used for each axis
		/* 0x5C */ Coord_f  velocity;
		/* 0x68 */ float    speedXZ; //Always positive, stores how fast the Entity is traveling along the XZ plane
		/* 0x6C */ float    gravity; //acceleration due to gravity; value is added to Y velocity every frame
		/* 0x70 */ float    minVelocityY; //sets the lower bounds cap on velocity along the Y axis
		//struct, collision related
		/* 0x74 */ int*     wallPoly; //Wall polygon an Entity is touching
		/* 0x78 */ int*     floorPoly; //Floor polygon an Entity is over/touching
		/* 0x7C */ u8       wallPolySource; //Complex Poly Surface Source. 0x32 = Scene
		/* 0x7D */ u8       floorPolySource; //Complex Poly Surface Source. 0x32 = Scene. related to 0x80/88
		/* 0x80 */ float    unk_0x080; //floor poly height?
		/* 0x84 */ float    unk_0x084;
		/* 0x88 */ u16      unk_0x088; //unknown
		// & 0x0100 = ?
		/* 0x8A */ s16      unk_roty; //rotation y (give item, possibly next facing dir?/face toward link?)
		/* 0x8C */ float    unk_0x08C;
		/* 0x90 */ float    xzDistanceFromLink; 
		/* 0x94 */ float    yDistanceFromLink; // relative distance
		/* 8-10-2012 : Addition made by Jason777 */
		/* For Entitys which contain a damage chart (example: Stalfos)... */
		/* 0x98 */ z_EntityDamageTable* DamageChart;  /* Pointer to the Entity's Damage Chart in RAM. */
		/* 0x9C */ Coord_f  displacement; //amount to correct velocity (0x5C) by when colliding into a body
		//following 3 variables correspond to a chicken running away when hit.
		//so likely a target position for the entity to go to
		/* 0xA8 */ s16      unk_0x0A8; 
		/* 0xAA */ s16      unk_0x0AA; 
		/* 0xAC */ u16      unk_0x0AC; //unk
		/* 0xAE */ u8       mass; // Used to compute displacement, 50 is common value, 0xFF for infinite mass/unmoveable
		/* 0xAF */ u8       health; 
		/* 0xB0 */ u8       damage; //amount to decrement health by
		/* 0xB1 */ u8       damageEffect; //Stores what effect should occur when hit by a weapon
		/* 0xB2 */ u8       impactEffect; //Maybe? set on deku nut when deku nut collides with gossip stone
		/* 0xB3 */ u8       unk_0x0B3; //?
		}; //CollisionCheck common
		/* 0xB4 */ Rotation rot2; //updating this value changes an Entity's rotation immediately
		/* 0xBA */ 
		/* 0xBB */ u8       unk_0x0BB; //unknown byte?
		/* 0xBC */ float    unk_0x0BC; //Model y axis offset. Represents model space units. collision mesh related
		/* 0xC0 */ void*     drawDropShadow; //Draw function for Piece of Heart drop shadow?
		/* 0xC4 */ float    unk_0x0C4;
		/* 0xC8 */ u8       unk_0x0C8;
		}; //NTSC 1.0 initializes with 8001EC20
		/* 0xCC */ Coord_f  unk_0x0CC; //used in Link, not Deku Babas 
		/* 0xD8 */ Coord_f  unk_0x0D8; //used in Link, not Deku Babas
		/* 0xE4 */ Coord_f  unk_0x0E4; //stores result of some vector transformation involving
							// Entity xyz vector, and a matrix at Game Play + 11D60
		/* 0xF0 */ float    unk_0x0F0; //related to above
		/* 0xF4 */ float    unk_0x0F4; //unknown
		/* 0xF8 */ float    unk_0x0F8; //unknown
		/* 0xFC */ float    unk_0x0FC; //unknown
		/* 0x100 */ Coord_f Pos4; //Final Coordinates last frame (collision, NTSC 1.0 f 8002F8E0)
		/* 0x10C */ u8      unk_0x10C; //Z-Target related
		/* 0x10D */ s8      unk_0x10D; //Z-Target related
		/* 0x10E */ u16     textId; //text id to pass to link/display when interacting with an Entity (navi text, probably others)
		/* 0x110 */ s16     freezeEntity; //Used for the "Redead Freeze" attack
		/* 0x112 */ u8     unk_0x112; //Damage color effect, the higher the number the higher the color intensity, 00-1F = blue, 40-5F = red, 80-9F = white, C0-DF = white (duplicate)
		/* 0x113 */ u8     unk_0x113; //Damage color animation, goes from 01 to FF, the lower the value the faster the animation goes, crashes if 00
		/* 0x114 */ u8      unk_0x114; //Damage color effect timer, decremented toward 0 every frame
		/* 0x115 */ u8      runEntity; // Determines if Entity instance should be processed. 01 for yes, 00 for no.
		/* 0x116 */ u8      unknown; //set within a routine that deals with collision
		/* 0x117 */ u8      naviEnemyId; //sets what 0600 dialog to display when talking to navi. Default 0xFF
		/* 0x118 */ struct z_Entity* attachedA; //Interfacing Entity? 
		//e.g. Link holding chu, Chu instance stores ptr to Link instance here; 
		//     Anju having Link's ptr when giving an item;
		//     Volvagia Hole stores Volvagia Flying here
		/* 0x11C */ struct z_Entity* attachedB; //Attached to Entity (
		//e.g. Link holding chu, Link instance stores ptr to Bombchu instance here
		/* 0x120 */ struct z_Entity* Entity_prev; /* Previous z_Entity of this type */
		/* 0x124 */ struct z_Entity* Entity_next; /* Next z_Entity of this type */
		/* 0x128 */ void *Init; //Initialization Routine. Mandatory
		/* 0x12C */ void *Dest; //Entity destructor 
		/* 0x130 */ void *Main; //Main Update function, called every frame the Entity is to be updated
		/* 0x134 */ void *Draw; //Draw Routine, writes necessary display lists
		/* 0x138 */ u32 CodeEntry; //Address to source overlay file's reference in code (file)
		/* From here on, the structure and size varies for each Entity */
	} z_Entity;
	//Entitys with a poly-type collision mesh will always set this variable
	//    /* 0x13C */ s32 PolyEntityId; //Index for poly mesh

	//ActorMain, Actor Draw arguments
	//A0 = Actor Instance
	//A1 = Game Play