Differences

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

--- ai:patching_basics [2018/10/13 16:16] – [Our first patch] icke_siegen
+++ ai:patching_basics [2018/10/15 13:07] (current) – external edit 127.0.0.1
@@ Line 5: / Line 5: @@
 In the beginning - when it was just the Salvation engine - almost everything needed to be patched: the engine offered a collection of modules, each specialising in a very small task, and the operator/programmer had to combine them in a meaningful way, to acchieve what he had in mind - play a video, map an image to a structure, control some parameters. A good part of the development over the last years is that many of everydays tasks are now packed into a fancy GUI, and are available with just one click. However, if something special needs to be accomplished, or some particular thing is not (yet) available via the GUI, patching might be the way to go. And honestly, after you have made the first steps, it is pure fun (after the desperation has vanished, that is).
+Also, you can change how Ai works by changing the Stage Patch - this includes making Ai completely unresposive, disabling its outputs, etc. Taking some care, i.e. saving the project before tweaking the stage patch, is a good idea.
 ===== Where to start =====
@@ Line 19: / Line 20: @@
 ===== Patches, Ports and Modules =====
-In the very end, the stage patch you consist of just thousands of modules, all linked to other modules. However none could overlook this or handle it in a suitable way. That's why functional units are bundled together as subpatches which expose only a limited set of ports and parameters. By convention every subpatch, or patch file, is simply called patch, with the Stage Patch representing our topmost project, containing all other patches and modules (it's possible to have patches outside the Stage Patch though). And the process of patching is arranging and connecting modules.
+In the very end, the stage patch consists of just thousands of modules, all linked to other modules. However none could overlook this or handle it in a suitable way. That's why functional units are bundled together as subpatches which expose only a limited set of ports and parameters. By convention every subpatch, or patch file, is simply called patch, with the Stage Patch representing our topmost project, containing all other patches and modules (it's possible to have patches outside the Stage Patch though). And the process of patching is arranging and connecting modules.
 ==== Modules ====