Custom Maid 3D2/Modding/Plugins - Revision history

Idris: Idris moved page Custom Maid 3D 2/Modding/Plugins to Custom Maid 3D2/Modding/Plugins: KISS usually uses "3D2" instead of "3D_2"

2021-11-29T16:04:54Z

Idris moved page Custom Maid 3D 2/Modding/Plugins to Custom Maid 3D2/Modding/Plugins: KISS usually uses "3D2" instead of "3D_2"

2016-01-03T11:05:03Z

Added links to an up-to-date guide

2015-08-12T18:30:44Z

‎Summary

2015-08-12T16:21:25Z

‎Injecting the methods

2015-08-12T16:20:26Z

2015-08-12T15:59:40Z

Fixed some typos, updated documentation for ReiPatcherPlus

2015-08-07T16:01:27Z

‎Patching phase

2015-08-07T15:57:39Z

‎Manipulating INI files

2015-08-07T15:52:39Z

‎Writing the plug-in DLL: Altered the name of the section to find it easily

2015-08-07T15:51:31Z

‎Writing the plug-in DLL: Fixed the name of MonoBehaviour class

← Older revision		Revision as of 11:05, 3 January 2016
Line 1:		Line 1:
		+	{{msgbox
		+	\|border=#ddd
		+	\|background=#ddd
		+	\|textcolor=#000
		+	\|message='''''This article is out of date and contains information that might be obsolete. You can find a newer guide for ReiPatcher [http://umaiumeunion.github.io/guides_reipatcher/01_preface.html here] and for UnityInjector [http://umaiumeunion.github.io/guides_unityinjector/01_preface.html here].'''''.
		+	}}
		+
	{{Custom Maid 3D 2}}		{{Custom Maid 3D 2}}

		+	<includeonly>[[Category:Stubs]]</includeonly>
		+	<noinclude>[[Category:Article_management_templates]]</noinclude>
	Since Custom Maid 3D 2 was made using Unity Engine and scripted with .NET, it is possible to manipulate game's behaviour using .NET and some tools to inject code into game's own DLLs.		Since Custom Maid 3D 2 was made using Unity Engine and scripted with .NET, it is possible to manipulate game's behaviour using .NET and some tools to inject code into game's own DLLs.

@@ Line 731: / Line 731: @@
+  }
 </code>
 == ReiPatcherPlus: methods overview ==

@@ Line 1,040: / Line 1,040: @@
 Most of the time setting code offset to 0 will be sufficient for plug-ins. However, if one wants to place the hook at a certain place, refer to the previous sections on how to decompile the .NET code. Most of the decompilers come with IL decompilers bundled (like ILSpy), which allows to inspect pure IL instructions to find the perfect attachment point.
-Note as well that <code>AttachMethod</code> will always add its own CIL instructions '''before''' the specified code offset! That is done to prevent the developers to insert method hooks after the <code>ret</code> instruction that is always present as a last IL instruction in every method. Any code insterted after the said instruction is simply neglected by the machine.
 ==== Examples ====

@@ Line 1,012: / Line 1,012: @@
 The exact definitions and parameter descriptions are below:
 <code>
-  void AttachMethod(MethodHook hook, int codeOffset, InjectDirection dir);
+  void AttachMethod(MethodHook hook, int codeOffset);
   void AttachMethod(MethodDefinition target,
                     MethodDefinition hook,
                     int codeOffset,
                     MethodFeatures features,
                     params FieldDefinition[] memberReferences);
 </code>
@@ Line 1,035: / Line 1,034: @@
 |-
 | <code>codeOffset</code> || An index value of an IL instruction in the target method from which to begin injection. If set to negative, will begin counting from the last instruction of the target method, where -1 is being the last instruction.
 |}
@@ Line 1,043: / Line 1,040: @@
 Most of the time setting code offset to 0 will be sufficient for plug-ins. However, if one wants to place the hook at a certain place, refer to the previous sections on how to decompile the .NET code. Most of the decompilers come with IL decompilers bundled (like ILSpy), which allows to inspect pure IL instructions to find the perfect attachment point.
 ==== Examples ====

@@ Line 358: / Line 358: @@
 === Patching phase ===
 Having done all the checks, it is time to finally patch the assembly, which is done in <code>Patch(PatcherArguments args)</code> method.<br/>
 All in all, injecting our <code>OnClickHook(UIButton hook)</code> requires the following steps:
 # Get assembly's module, which is the property <code>args.Assembly.MainModule</code>, and use its <code>GetType(string fullName)</code> method to acquire the type definition for <code>UIButton</code>.

← Older revision	Revision as of 16:04, 29 November 2021
(No difference)

@@ Line 504: / Line 504: @@
+  {
       // Preferences is an instance of ExIni.IniFile that is defined in PluginBase.
-      // If no INI file is found, UnityInjector will create a one automatically.
+      // If no INI file is found, UnityInjector will create one automatically.
       // That is why we don't need to perform any checks.
       // This command will attempt to find a key "ToggleKey" in section "Key_Mappings".
@@ Line 534: / Line 534: @@
+  }
 </code>
 === Adding the event handler ===

@@ Line 438: / Line 438: @@
 </code>
-== Writing the plug-in DLL ==
+== Writing the plug-in DLL (using UnityInjector) ==
 Finally, by using UnityInjector one can affect game's logic and objects using Unity's own scripting API.<br/>
 It is important to notice that although UnityInjector relies on ReiPatcher to be installed, both are completely standalone tools in plug-in development.

@@ Line 443: / Line 443: @@
 It is possible to create plug-ins that are only installed by ReiPatcher, plug-ins that act as Unity's game objects loaded on-the-fly with UnityInjector, or plug-ins that take advantage of both tools to create versatile and diverse additions into Unity Engine games.
-As mentioned, UnityInjector plug-ins are not patched into the game. Instead, they are loaded dynamically and added to the game as custom <code>MonoBehavior</code>s.
+As mentioned, UnityInjector plug-ins are not patched into the game. Instead, they are loaded dynamically and added to the game as custom <code>MonoBehaviour</code>s.
 In other words, UnityInjector allows to insert custom scripts into the game.