AI editing tool for Spring games, primarily developed for nota.

Public boards

Board: i1qLOk6V

20. 3. 2017 - MILESTONE III
21. 11. 2016 - MILESTONE I
15. 5. 2017 - FINAL MILESTONE IV
23. 1. 2017 - MILESTONE II
Done 90.62 %

Release 2017-06-02


  • better UI (dialogs)
  • prompt asking users to save modifications if they would lose them
  • bug fixes

User documentation:

Release 2017-05-15


  • improved visuals of BtCreator
  • working dialogs for new, load, save etc.
  • improved project functionality
  • added Reference node functionality
  • improved debugging functionality
  • and many additional small changes


Release 2017-04-24


  • Toolkit usable to have multiple projects
  • prototype of load/save dialogs
  • Numerous changes and bugfixes


Release 2017-04-03

  • Fixed additional bugs.
  • Better breakpoint functionality
  • Ability to pan in BtCreator
  • Backend improvements
  • locking


Release 2017-03-20


  • numerous bugs fixed
  • new Sensors from Petr


Release 2017-03-06


  • Tree inputs are now assigned through BtController
  • Tree inputs are editable through the Root node in BtCreator
  • MoveOptim command has improved pathfinding
  • Reset button is present in BtController which resets the tree
  • Treenode combobox parameter type implemented
  • First attemtp to document lua script commands


Release 2017-02-20


  • every behaviour in BtBehaviours folder now can be assigned through the nota ui buttons / requires beta version 170214 of nota
  • sensor calls are now cached, so in one tick only one sensor call is made
  • using of widgets should be safer / only one widget(component) should crash instead of whole system


Release 2017-02-06


  • fast and usable hex-builders behaviour (with 200 armpws and 10 armfarks ticks were under 20ms - the time spent in our AI)
  • analyze of input parameters, as first step to reference node feature


Release 2017-01-23


  • example behaviours included (going, random-move, circling, mex-builder)
  • roles autoassignment implemented (with prototype implemntation in BtCreator)
  • BtCreator is now hidden from user by default
  • Lua script command finished
  • Sensors share environment with context variables


Release 2017-01-09


  • Sensors were added
  • Expression node with lua expression, which can contain sensor call (but still not context call)
  • two sensors included: flipSensor and groupExtents
  • every lua command now have its own treenode, lua commands now can have arbitrary parameters


Release 2016-12-19


  • new behaviour random-move, which introduces context variables. Currently they can be used only from lua script command.
  • new behaviour triple-reporter, which just echoes assigned units ids. Introduces labels/roles, which are determined right now by number of children in a parallel Switch node(role names are generated as Role1, Role2, etc)
  • BtController is constantly improving, deleting of assigned tree instance is done by middle mouse click. On instance change assigned units are selected. And next to role assignment button there is a label with the number of assigned units.


Release 2016-12-05

Main features

  • It is possible to run multiple instances of the behaviors
  • Have new portable release package


Release 2016-11-21

The first release of BETS, capable of evaluating a single tree, designing a tree, assigning the tree to a group of units and viewing the states of individual nodes during execution.


For additional information on usage, see manual doc

Dev Console


  • TAB to autocomplete or list possible completions
  • up/down to cycle through command history
  • history remembered even after shutting down Spring
  • in a listing of an object, the "{...}" are clickable and cause the object to be outputted as well
  • all slots of _G and WG are available within the console environment (e.g. our BtUtils lives in WG.BtUtils, but you don't need to write WG)

Special functions

  • clear() -- clear the window and history
  • write( o ) -- write the object to the console
  • spawn(Units.[name], [number]) -- spawn units at mouse, console automatically enables cheats

BtEvaluator as custom AI


I wrote new Skirmish C++ AI for Spring(BtEvaluator), created a Visual Studio 2013 solution, which can build it and copies it to the Nota. I also wrote a Widget BtEvaluationLoader, which in its Initialize() function adds BtEvaluator to current player, so both of them are in control. And I imlemented message passing between BtEvaluationLoader and BtEvaluator both directions. Everything is on separate branch -

Setup guide: (for Spring 103 and Nota 1.90r)

  • follow
  • in short install cmake, git, mingw(i686 4.8.5 -, java sdk, clone develop branch of spring source(I used this commit 98e397983e676b8df7baeff1a71f03d16013bcd4), clone mingwlibs and make sure you can generate mingw makefiles for spring using cmake (create "build/" directory under the spring repository root to use as the build target path for CMake).
  • build Cpp-AIWrapper (mingw32-make -j4 Cpp-AIWrapper), thats the last step of building, nothing else is needed built for new AI!
  • now clone branch BtEvaluator from to directory spring_src/AI/Skirmish
  • run CMake again to generate mingw makefiles for the BtEvaluator as well - if you click on configure in CMake again you should see all tha AIs for which makefiles will be generated
  • in BtEvaluator/BtEvaluator/ find SpringPaths.props open it and edit both SPRINGDATA_DIR(Nota/SpringData for new lobby) and SPRING_SOURCE_DIR to point to the corresponding directories.
  • now you should be able to build it (using the VS solution file), after build it copies generated dll to nota springdata directory, make sure to use the Release version.
  • now you need to make symbolic link to BtEvaluatorLoader.lua widget from LuaUI/Widgets, this way git tracks the file. (or if you dont want to edit it just copy it)

Now when you start new game from new notaLobby(no other steps are needed), you should see in infolog
- "BtEvaluator took control of your team." at the start
- every gameframe AI prints "Skirmish AI: BtEvaluator Update event. "
- and one button on the bottom of screen from the widget -> which sends message to AI, and AI responds. (you can see that on attached screen)

Possible issues:

  • no target for NMake/DLL was not found -- the makefile was not properly generated, run CMake

  • Access Violation when loading NOTA map -- can be caused by compiling under Debug, so compile under Release

Additional info:




restrict operations with graph on rooted tree-graphs only

As an AI developer I expect that any graph i create in a widget-BT-editor will be rooted tree. There will be logic rules applied in interface which will prevent me from construction of the graphs which are not rooted trees.

This implies:

  • making visual oriented edges - :exclamation: currently edges are not oriented (<~there can be just one edge between nodes) + representation in file orders edge source/target just by ID size
  • functionality for the rooted tree validation


  • continues from save + load
  • it forces the team to make at least raw basic decision about the tree representation (JSON, YML, XML, Lua...?) and use some simple representation of the node-types and edges
  • rise some questions about topology of the trees

Acceptance criteria

  • I can construct the tree as it was possible in save + load with features described below
  • Each edge is visually identifying its orientation
  • I can construct only rooted tree-graphs (e.g. making edge is not allowed, visual feedback is not necessary)
  • Saving/serialization produces hierarchical reproduction of the tree
  • If there are multiple root-nodes => there are multiple trees in one file, its is not problem in scope of this task

save + load

As an AI developer I would expect there is some save and load button.

Those two buttons represents the basic ability to manipulate with trees and it is vital functional slice of the whole system.


  • continues from How the Tree Creator looks like
  • it forces the team to make at least raw basic decision about the tree representation (JSON, YML, XML, Lua...?) and use some simple representation of the node-types and edges
  • it raises the crucial question where/from the behaviors are loaded - where we store them in the folder structure, if we plan to construct some set of trees / packages
  • it also (partly) raises the question how two trees are connected together

Acceptance criteria

  • I can construct the tree as it was possible in How the Tree Creator looks like
  • i can click on the save button and tree is saved, scope of saving:

    • node types
    • edges
    • name of file we save is hardcoded (its only prove of the concept!)
  • I can click on the load button and tree is loaded from some predefined location, scope of loading

    • no need to select the file to load, name of file is hardcoded
    • im able to perform save -> load sequence and the loaded tree is equivalent to the saved one
  • Ill make sure the syntax is robust on repository system merges - e.g. each node has unique ID, do we split the topologic info (x, z, sizeX, sizeZ) from node or we keep it with node, etc.

Multiple instances of trees in tabs of BtController

Current state

  • it is possible to create more instances
  • show tree button refreshes/shows the BtCreator of tree in active tab
  • assign units sends message to BtEvaluator with current tree

How the Tree Creator looks like

Nahled na klikani stromu v Chili, na levo je NodePool, ze ktereho se tahaji nody doprava a tam se spojuji klikanim na ty kulaty panely. Jedna se o jednu tridu TreeNode pridanou do Chili.