Assets: Bone Generation Spreadsheet Init

.gitignore

@@ -2,3 +2,4 @@
 /Game
 /Tools
 /Assets
+.~lock*

Docs/Technical/Formats/INSA.md

@@ -26,18 +26,19 @@
 		* 0x28 - Calculate data over a known range of addresses each offset by 0x24 bytes
 		* 0x20 - Calculate data by an unknown total quantity with an offset of 0x08 bytes per calculation and a bit shift by 1 to the left on the first byte to stop it
 	* The value at 0x10 is an elusive bugger; the developers read every byte of data from one bone to the next (or the end of file) until they hit "0000803f," 0x10's value, "0000803f." Even then, there's several extra steps for some models (check for duplicates, check for extra 0's, etc)
-	* Bone Generation Patterns
-		* The Shredder (Only applies to certain mob types) - the vertex data is either non-existent for the bone it applies to or spread across this single bone's memory in 4-byte chunks instead of being clustered together like most of the vertex data
-		* Most other patterns start with this offset structure for the first three occurrences (each being offset from the last occurrence by a set amount)
-			* 0x10 - From the INSA header
-			* 0x14 - From the first to the 4-byte section right before the calculation chain starts (0x28)
-			* 0x1308 - From the second occurrence; this is the one where the other patterns show up
+	* Bone Generation Patterns - See accompanying Bone-Generation-Table spreadsheet for specifics on these patterns
+		* The Shredder - the vertex data is either non-existent for the bone it applies to or spread across this single bone's memory in 4-byte chunks instead of being clustered together like most of the others
 		* The 7-11 - This pattern has only been seen one time so far and may have been a human error on my part; the name comes from it having an offset of 0x24 from the third occurence and being a possible inconvenience (similar to how the next pattern was handled)
 		* The 33C - This pattern is more prominant but also problematic; 0x33c offset from the third occurence can mean these things:
 			* if it occurs on its own, it can be a direct offset to the start of the vertex data section
 			* it can be inside of the vertex data section as somewhere close to the center of the memory region
 			* (need to test further) it can mean other patterns were applied and act as a second indicator of the pattern used
-		* The OC - (needs more testing) this pattern is similar to The 7-11 except it has two offsets used in a set pattern (0x1c and 0x10 with a 0x0c offset between the two); it's also one that has variation on the pattern thrown in at seemingly random points to break up the pattern a bit
+		* The OC - Named after its pattern of alternating 0x10 and 0x1c offsets; often found after other patterns but also can function similarly to any other pattern that uses either of its shared offsets
+		* The Shizu Shuffle - Expect possible chaos in the mix; these can have varied patterns and be fully nonexistent if combined with an augmentation
+		* The Standard - Expect to find a large block of vertex data immediately after the third instance of 0x10's value
+		* The VAP Data Shuffle - Similar to The Standard except expect to find Animation Data Mixed in with the Vertex Data
+		* 3x10 to The Standard - Augmented variation of The Standard; expect to jump 0x30 (3 times 0x10 offset to get to Vertex Data)
+		* 3x10 to The VAP Data Shuffle - Same augmentation but for the VAP Data Shuffle
 * Structure:
 	* 0x0c - The Shredder Pattern is in effect if both this and 0x20 are not 0 and have the same value
 	* 0x10 - This 4-byte value leads to the vertex data; see the notes above