User Tools

Site Tools


besiege:modding:example-guides:wardrum

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
besiege:modding:example-guides:wardrum [2018/07/10 16:55]
spaar [Defining the block]
besiege:modding:example-guides:wardrum [2018/07/16 17:12] (current)
spaar
Line 11: Line 11:
 ===== Creating the basic structure ===== ===== Creating the basic structure =====
  
-We're going to start by creating a ''​WarDrum''​ directory inside ​the ''​Mods''​ directory ​in ''​Besiege_Data''​.+Start by opening ​the in-game console and executing ​''​createmod WarDrum''​.
  
-Inside that, the following ​''​Mod.xml'' ​skeleton ​file is needed:+This will create a ''​Besiege_Data/​Mods/​WarDrum Project/​WarDrum/''​ directory with a ''​Mod.xml''​ file inside it, the mod manifest. 
 + 
 +Open that file and insert some appropriate values for the mod:
  
 <code xml> <code xml>
Line 67: Line 69:
 Now to the interesting part: Defining the properties of our block. Now to the interesting part: Defining the properties of our block.
  
-Firstadd a reference to it to the manifest:+Go in-game againand execute ''​createblock WarDrum "War Drum"''​ in the console.
  
-<code xml> +This will create a ''​WarDrum.xml''​ file and reference it from the mod manifest automatically
-<​Mod>​ +Open up the file and set the appropriate values:
-    ... +
-    <​Blocks>​ +
-        <Block path="​Drum.xml" /> +
-    </​Blocks>​ +
-..+
-</​Mod>​ +
-</​code>​ +
- +
-Now add the basic structure to the Drum.xml file:+
  
 <code xml> <code xml>
Line 242: Line 235:
 The mod can now be loaded and the block should appear in-game correctly. However, it won't do anything yet, which doesn'​t make for a very interesting block. The mod can now be loaded and the block should appear in-game correctly. However, it won't do anything yet, which doesn'​t make for a very interesting block.
  
-We'll need to set up something that allows us to write custom code for the game, as described in [[..:​Code|Custom Code]], ​for example a Visual Studio project with the appropriate references.+We'll need to set up something that allows us to write custom code for the game, as described in [[..:​Code|Custom Code]], the easiest way of doing so is to use the ''​createassembly''​ console command.
  
-With that set up, first add the assembly to the mod manifest: +Example command''​createassembly WarDrum compiled WarDrum "Mods.WarDrum"​''​.
- +
-<code xml> +
-<​Mod>​ +
-    ​... +
-    <​Assemblies>​ +
-        <​Assembly path="WarDrum.dll" ​/> +
-    </​Assemblies>​ +
-    ... +
-</​Mod>​ +
-</​code>​+
  
 That'​ll cause the assembly to be recognized by the mod loader. Now, specify the class that will serve as behaviour for the block in ''​Drum.xml'':​ That'​ll cause the assembly to be recognized by the mod loader. Now, specify the class that will serve as behaviour for the block in ''​Drum.xml'':​
Line 261: Line 244:
 <​Block>​ <​Block>​
     ...     ...
-    <​Script>​WarDrum</​Script>​+    <​Script>​Mods.WarDrum.WarDrum</​Script>​
     ...     ...
 </​Blocks>​ </​Blocks>​
 </​code>​ </​code>​
- 
-The name specified could also include a namespace to make the code more organized, but we won't do that here since there aren't any other classes. 
  
 Now, here's the actual code. Some of it is omitted for brevity. The code is explained using comments, especially where it relates directly to the mod loader. Now, here's the actual code. Some of it is omitted for brevity. The code is explained using comments, especially where it relates directly to the mod loader.
Line 276: Line 257:
 using UnityEngine;​ using UnityEngine;​
  
 +namespace Mods.WarDrum {
 // BlockScript is the base-class for all behaviours of blocks. // BlockScript is the base-class for all behaviours of blocks.
 public class WarDrum : BlockScript { public class WarDrum : BlockScript {
Line 317: Line 299:
  
     // Called every frame while simulating.     // Called every frame while simulating.
-    public override void SimulateUpdate() {+    public override void SimulateUpdateLocalPhysics() {
         // These properties are defined in BlockScript         // These properties are defined in BlockScript
         if (!HasBurnedOut && !IsDestroyed) {         if (!HasBurnedOut && !IsDestroyed) {
Line 348: Line 330:
             DisplayShockWave();​             DisplayShockWave();​
     }     }
 +}
 } }
 </​code>​ </​code>​
Line 357: Line 340:
 So the first thing to ensure, is that all of the code handling user input, physics and so on is only executed on the instance running the current simulation. So the first thing to ensure, is that all of the code handling user input, physics and so on is only executed on the instance running the current simulation.
  
-We're in luck though, BlockScript ​ensures ​that methods like ''​OnSimulateStart'',​ ''​SimulateUpdate'',​ etc are only called ​on the correct ​instance ​in multiplayer(There are also ''​Client'' ​variants of these in case you do need to execute some code on all machines.)+We're in luck though, BlockScript ​provides some methods ​that only execute ​on the instance ​running the simulation, e.g. ''​SimulateUpdateLocalPhysics''​.
  
 So, we're not doing anything we shouldn'​t be doing right now. However this also means that the visual effects of striking the drum, as well as the sound, only happen on the instance running simulation right now, that's not what we want! We're going to have to transmit these effects to other player manually. So, we're not doing anything we shouldn'​t be doing right now. However this also means that the visual effects of striking the drum, as well as the sound, only happen on the instance running simulation right now, that's not what we want! We're going to have to transmit these effects to other player manually.
besiege/modding/example-guides/wardrum.txt · Last modified: 2018/07/16 17:12 by spaar