doc: Add helicopter guide, fix broken link

docs/docs/draft-types/data.md

@@ -5,4 +5,4 @@ Data drafts have the type of `data`.
 Data drafts are useful for storing extra data as serialized JSON content is kept in memory.
 
 ## Attributes
-::: inherit-h2 Attributes draft-types/.draft.md
+::: inherit-h2 Attributes draft-types/.base.md

docs/docs/guides/compositions.md

@@ -141,7 +141,7 @@ Since version 1.10.62 you can also include bus stops in your compositions. Lines
 {"id": "$busstop00", "x":1, "y":0, "level":0}
 ```
 
-## Tool
+## Composition creation tool
 To make building up a composition easier there's a tool to convert a selected rectangle from a city to corresponding json code. It's part of the **Plugin Creator Tools** that you may find in the Plugin Store (you may find it via search function or listed in Categories->Tools).
 
 Once you have installed the tool(s) you can select it from the toolbar. After that mark the area you want to create a json composition code for. The code will be copied into your clipboard then. This may look like:

docs/docs/guides/external-translations.md

@@ -1,7 +1,7 @@
 # External translations
 
 An easy way to provide translations for your plugins is given by
-[inline translations](plugin-inline-translations.md).
+[inline translations](inline-translations.md).
 However, these can be hard to maintain if you want to collaborate on translations
 for larger projects.
 So the idea here is to separate translations into separate files that contain nothing else than translations.
@@ -44,7 +44,7 @@ What you can do instead is to have the sole definitions in one file (e.g. main.j
 ]
 ```
 
-which makes your code a bit cleaner :teach 
+which makes your code a bit cleaner.
 
 Translations can be put in separate files e.g. like (let's call it translations.json)
 ```json
@@ -75,7 +75,7 @@ depending on placement, "_title" or "_text" appended.
 This structure allows you to even split up the translations for different languages into different files, e.g. into translations.json and translations_de.json.
 Also note that for translations there's no specific order to obey. The objects you translate don't have to be already defined.
 
-You can access translations from Lua using the
+This method also allows you to access translations from Lua using the
 [`TheoTown.translate`](https://doc.theotown.com/modules/TheoTown.html#translate) function:
 ```lua
 print(TheoTown.translate('draft_mypark00_title'))

docs/docs/guides/helicopters.md

@@ -0,0 +1,64 @@
+# Helicopters
+
+![](../assets/guides/helicopters/preview.png){: style="width:100%;"}
+
+Game allows you to define custom helicopters. Their definition is quite simple as everything you need are frames for the heli. For example these:
+
+![](../assets/guides/helicopters/heli.png)
+
+Each has a size of 38x18. The helicopter definition looks now like:
+```json
+{
+  "id": "$my_heli00",
+  "type": "helicopter",
+  "frames": [
+    // 4 frames for the helicopter, handle defined the pivot point
+    {"bmp": "heli.png", "w": 38, "h": 18, "count": 4, "handle x": 18, "handle y": 16}
+  ], 
+  "animation": [{"id": "$rotor00", "x": 0, "y": -10}]
+}
+```
+
+Notice how it uses a predefined animation called "$rotor00". It just contains 8 frames, 4 for slow rotation, 4 for fast rotation. In most cases you won't need to come up with your own rotor frames.
+
+For reference it's defined like so:
+```json
+{
+  "id": "$rotor00",
+  "type": "animation",
+  "frames": [
+    {"x": 360, "y":526, "w": 38, "h": 9, "count": 4, "handle x": 18, "handle y": 5},
+    {"x": 360, "y":512, "w": 38, "h": 13, "count": 4, "handle x": 18, "handle y": 6}
+  ]
+}
+```
+
+For the helicopter spawner let's define a decoration tile:
+
+![](../assets/guides/helicopters/heliport.png)
+
+Its code contains the helicopter spawner:
+```json
+{
+  "id": "$heliplaza00",
+  "type": "decoration",
+  "width": 1,
+  "height": 1,
+  "frames": [{"bmp": "heliport.png"}],
+  "build height": 0,  // Ensure correct building height so that helicopter will start at right height (zero = ground level)
+  // Helicopter spawner object
+  "helicopter spawner": {  
+    "id": "$my_heli00", // ID of the helicopter to spawn
+    "radius": 16        // Radius where they helicopter will fly randomly. Is 16 by default
+  }
+}
+```
+
+!!! warning "Warning"
+    The helicopter ID provided in a helicopter spawner doesn't have to be defined yet. However, if it's still not defined when the game tries to use it, it will crash.
+
+<sub>
+This page has been adapted from
+[a topic](https://forum.theotown.com/viewtopic.php?t=5249)
+on the official TheoTown forum.
+</sub>

docs/docs/guides/index.md

@@ -1,6 +1,6 @@
 # Guides
 
-This section includes a guides on how to accomplish specific things or use specific features.
+This section includes guides on how to accomplish specific things or use specific features. The guides assume the creator is familiar with writing a simple plugin like the sample plugin.
 
 ## Places awaiting migration
 - Base documentation

docs/docs/guides/inline-translations.md

@@ -2,17 +2,17 @@
 
 !!! info "Added in version 1.5.56"
 
-Until now the only way to translate plugins was by doing it hardcoded in the project itself.
+In the old days, the only way to translate plugins was by hardcoding it in the project itself.
 That means you weren't able to provide translations for your own plugins and rather had
 to offer different variants in order to offer localization.
 
-Version 1.5.56 will solve that by introducing inline translations for plugins. The way this will work is by using a special syntax within the plugin. Let's have a look at this example from the wandering animals plugin:
+To solve that issue, TheoTown introduced inline translations for plugins. The way it works is by using a special syntax within the plugin. Let's have a look at this example from the wandering animals plugin:
 
 ```json
 "title":"Wandering animals"
 ```
 
-That's how the title definition looks right now. This notion will still work in the future, but we can append specialized translations to it by writing `[languagetag]Translation`. For example for the case of a German translation that would look like:
+That's how a regular title definition looks like. We can append specialized translations to it by writing `[languagetag]Translation`. For example for the case of a German translation that would look like:
 
 ```json
 "title":"Wandering animals[de]Streunende Tiere"
@@ -21,13 +21,13 @@ That's how the title definition looks right now. This notion will still work in
 You can append as many specialized translations as you want to.
 The game will then pick that one that's closest to the current language.
 The first case (here the English one without []) will be used as a fallback translation
-if no other translation does fit. I recommend to use English for it.
+if no other translation does fit. We recommend to use English for it.
 
-This special syntax will also work for the text attribute.
+This special syntax also works for the text attribute.
 
 Note that only languages that are supported by the game natively can be translated that way. Have a look at
 [the public translation repository](https://github.com/LobbyDivinus/theotown-translation)
-for the supported language codes right now.
+for the supported language codes.
 
 We also suggest that you save the JSON files using UTF-8 encoding to minimize issues reading non-ASCII characters.