BETS

Changes:

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

User documentation: https://docs.google.com/document/d/1wJ1WWtNH_XNLivms9EcdUt7n7sX4YlKkHuAab9a_Zio/edit

Changes

• 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

Download

Changes:

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

Download

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

Download

Changes

• numerous bugs fixed
• new Sensors from Petr

Download

Changes:

• 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

DOWNLOAD

Changes:

• 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

DOWNLOAD

Changes:

• 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

DOWNLOAD

Changes:

• 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

DOWNLOAD

Changes:

• 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

DOWNLOAD

New:

• 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.

DOWNLOAD

Main features

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

DOWNLOAD

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.

DOWNLOAD

For additional information on usage, see manual doc

Usage

• 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

Description

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 - https://github.com/MartinFrancu/BETS/tree/BtEvaluator

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

• follow https://springrts.com/wiki/Building_Spring_on_Windows
• in short install cmake, git, mingw(i686 4.8.5 - https://sourceforge.net/projects/mingw-w64/?source=typ_redirect), 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 https://github.com/MartinFrancu/BETS/tree/BtEvaluator 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:

• https://springrts.com/wiki/AI:CppTestAI
• https://springrts.com/wiki/AI:Development:Lang:Cpp
• https://springrts.com/phpbb/viewtopic.php?f=15&t=26298

Related:

17-ovladani-hrac-ai-zaroven

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

Motivation

• 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

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.

Motivation

• 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.

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

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.