docs/canvasmodel-combat.md

+# Canvas model documentation
+
+[[_TOC_]]
+
+# Wiki
+
+A reminder for the different states clothing can be in.
+
+![exhib1](assets/exhib1.png)
+
+# Model options
+
+## Clothes object
+
+## Penetrator object
+
+# To Do
+
+## Clothes
+
+### Structure
+
+#### Lowerwear
+
+Lowerwear generally remains along the player's positional states: waist, thighs, knees, and ankles.
+Skirts are an exception to this rule. As they are tubular. And can be lifted up, beyond the head.
+
+##### Short skirts
+
+Mandatory states: waist, thighs, knees, and ankles.
+
+Optional states: chest and midriff.
+
+Missionary specifics:
+
+-   Front and back: all?
+-   Leg positioned: waist, thighs, knees, ankles.
+
+Doggy specifics:
+
+-   Front and back: all?
+
+##### Long skirts
+
+Mandatory states: waist, thighs, knees, and ankles.
+
+Optional states: chest and midriff.
+
+Missionary specifics:
+
+-   Front and back: all?
+-   Leg positioned: waist, thighs, knees, ankles.
+
+##### Trousers
+
+Mandatory states: waist, thighs, knees, and ankles.
+
+Optional states: None.
+
+Missionary specifics:
+
+-   Front and back: all?
+-   Leg positioned: waist, thighs, knees, ankles.
+
+##### Shorts
+
+Mandatory states: waist, thighs, knees, and ankles.
+
+Optional states: None.
+
+Missionary specifics:
+
+-   Front and back: all?
+-   Leg positioned: waist, thighs, knees, ankles.
+
+### Issues
+
+-   [ ] Shirt sprites have sleeves embedded into them, these should be moved to the sleeves of the sprites.
+
+## Penetrators
+
+Penetrator(s) need to be redesigned to rest upon the face of the PC:
+
+-   img\sex\missionary\penetrators\human\mouth-entrance.png
+-   img\sex\missionary\penetrators\human\mouth-imminent.png
+
+Penetrator(s) need to be improved so the base of the penetrator does not seem too intrusive for when other NPC shadows are over it.
+
+-   img\sex\missionary\penetrators\human\mouth-penetrated.png

game/00-framework-tools/02-version/0001-0.2.17.0.js

 /**
- * By convention, we list the migrations in a version file where the migration was introduced
+ * By convention, we list the migrations in a version file where the migration was introduced.
  *
- * This convention is a 0 padded migration number (in this case 0001), followed by the game version
+ * This convention is a 0 padded migration number (in this case 0001), followed by the game version.
  *
  * Note that this convention is loosely enforced -- we'll throw an error if you attempt to save a
- * migration from an earlier version
+ * migration from an earlier version.
  */
 Versions.register(1, (originalVersion, state) => {
 	// IMPORTANT: WHEN WE DO MIGRATION, DO NOT USE SUGARCUBE
@@ -22,8 +22,10 @@ Versions.register(1, (originalVersion, state) => {
 	// This migration is a good template. It serves as a marker for the baseline
 	// version. It will (most likely) never be executed, as the baseline migration
 	// will happen in sugarcube (unlike the other migrations)
-	return Versions.stepper(originalVersion, 1)
-		.step(() => {
+	return Versions.stepper(originalVersion, 1).step(
+		() => {
 			// this is a no-op step
-		}, { name: 'placeholder'}).shouldContinue;
-})
+		},
+		{ name: "placeholder" }
+	).shouldContinue;
+});