This PR replaces our current NPC AI with a [behavior tree system](https://en.wikipedia.org/wiki/Behavior_tree_(artificial_intelligence,_robotics_and_control)). Behavior trees are a common way of creating AI in which you place nodes in a tree structure to define what actions an AI should take. AI controllers defined a list of /datum/ai_planning_subtree types in behavior_nodes. Each subtree was a self-contained unit that could call queue_behavior() to fire off /datum/ai_behavior actions. The controller iterated subtrees in order, each one deciding independently whether to queue something and deciding whether the next subtree would run. This has a few issues: 1. There's no real structure; you are just defining a list of things to try in order. 2. There was a loooot of subtrees that were basically the same as another but with some slight modification 3. It was hard to understand. Controllers now define a single json file describing a tree of nodes. The tree is composed of structural composites: Sequence - do A, then B, then C (and so on) Selector - try A, if it fails try B, then C (and so on) Parallel - run A and B simultaneously, with configurable failure/success policies and or looping behavior Subplan - loop a child continiously Along that we also have "Decorators". These are nodes that basically check a condition (E.g.; do we have a combat target). These decorators can be used to gate behavior and are re-useable across behavior trees. They also have a concept known as "Observers". Which lets them cancel lower priority behavior in case their condition changes (Which we check whenever a signal fires that fits that specific decorator). This makes the AI much more responsive to change in environment. For behaviors, we still use the ai_behavior datums. These are the actual behaviors such as "Move to X", "Attack X". The only major change is that these can no longer sleep() since they now run in the ai_controller. Lastly, we now also have subtrees, except now they are essentially pieces of behavior tree that can be re-used, or even overriden at runtime or as a variable. Allowing for making modular AI made out of several smaller trees. You can set variables on these nodes directly via the extension (see below), which should reduce the need to make subtypes of behaviors by a lot. All of these vars are saved on the JSON and will be applied at runtime. If you are using subtrees, you can also assign "bindings" to these variables, which will allow instances of the subtree to override those variables. Since a tree structure with variables becomes hard to parse in a JSON, I've made a VSCode extension to edit these JSONs: https://marketplace.visualstudio.com/items?itemName=BehaviorTreeG.behaviortreeg https://github.com/CabinetOnFire/BehaviorTreeG <img width="1795" height="1268" alt="image" src="https://github.com/user-attachments/assets/56aa2f0b-3cf9-449f-bca4-8281fca82db6" /> This extension allows you to edit the behavior tree JSONs, and browse through all the behaviors/decorators/subtrees we have If you'd like more info on how to build these AI check out the learn_ai.md. I will also make a tutorial to go over more depth on what the system offers because I kind of suck at doing technical write-ups. Targetting has been changed to. I've made a new acquire_targets behavior that takes a target_source (what am I targetting) and targetting_strategy (what does the candidate need to fulfill to be considered a target). This allows us to make composites targetting combinations to reduce the amount of specific find_and_set esque behaviors we had before. Not everything is ported to this system but that would be a longer term goal. I've added a new build_bt script that converts all the behavior tree JSONs into compiled versions. Why is this needed? Because I wanted to keep using defines in behavior trees, so we need a way to convert this into literal values before we send it to DM. This script runs on compile and should also run in CI (If I didn't fuck that up!). This saves to a new build/ folder. I've ported every single AI in the game to this system (except raptors, Kobsa is working on those so should be in soon!), so I do expect some bugs to come out of this. But I also fixed some issues that have probably been in the game for a long time such as: - Fixed penguins being unable to fish - Fixed bileworms not being able to devour people - Fixes goldgrubs not grubbing gold (they could not mine!) - Lizards actually eat food they find Either way, I'd reccomend a long TM on this. 1. (Hopefully) a better development experience for making AI 2. Less copy-paste for behaviors, we should be able to re-use more pieces to make behavior 3. Behavior trees is a more common pattern in making AI, so it should be easier to find resources to find out how to do things. 🆑 CabinetOnFire, Iamgoofball, SmartKar, Ben10omintrix refactor: Replaces our AI system with behavior trees, porting all datum/ai to it /🆑 I will add this PR with more details down the line. I think I got the big picture but its a big PR, so sorry if I missed something important. --------- Co-authored-by: Iamgoofball <iamgoofball@gmail.com> Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com> Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
tgui
Introduction
tgui is a robust user interface framework of /tg/station.
tgui is very different from most UIs you will encounter in BYOND programming. It is heavily reliant on Javascript and web technologies as opposed to DM. If you are familiar with NanoUI (a library which can be found on almost every other SS13 codebase), tgui should be fairly easy to pick up.
Learn tgui
People come to tgui from different backgrounds and with different learning styles. Whether you prefer a more theoretical or a practical approach, we hope you’ll find this section helpful.
Practical Tutorial
If you are completely new to frontend and prefer to learn by doing, start with our practical tutorial.
Guides
This project uses React. Take your time to read the guide:
If you were already familiar with an older, Ractive-based tgui and want to translate concepts between old and new tgui, read this interface conversion guide.
Other Documentation
- Component Reference - UI building blocks
- Tgui Core - The component library for tgui.
- Using TGUI and Byond API for custom HTML popups
- Chat Embedded Components
- Writing Tests
Pre-requisites
If you are using the tooling provided in this repo, everything is included! Feel free to skip this step.
However, if you want finer control over the installation or build process, you will need these:
Usage
Via provided cmd scripts (Windows):
bin/tgui-build- Build tgui in production mode and run a full suite of code checks.bin/tgui-dev- Launch a development server.bin/tgui-dev --reload- Reload byond cache once.bin/tgui-dev --debug- Run server with debug logging enabled.
To open a CMD or PowerShell window in any open folder, right click while holding Shift on any free space in the folder, then click on either
Open command window hereorOpen PowerShell window here.
Via Juke Build (cross-platform(No)):
tools/build/build.sh tgui- Build tgui in production mode.tools/build/build.sh tgui-dev- Build tgui in production mode.tools/build/build.sh tgui-dev --reload- Reload byond cache once.tools/build/build.sh tgui-dev --debug- Run server with debug logging enabled.
tools/build/build.sh tgui-lint- Show (and auto-fix) problems with the code.tools/build/build.sh tgui-test- Run unit and integration tests.tools/build/build.sh tgui-analyze- Run a bundle analyzer.tools/build/build.sh tgui-clean- Clean up tgui folder.
With Juke Build, you can run multiple targets together, e.g.:
tools/build/build.sh tgui tgui-lint tgui-tsc tgui-test
Via Bun (cross-platform):
Run bun install once to install tgui dependencies.
bun tgui:build- Build tgui in production mode.bun tgui:build [options]- Build tgui with custom webpack options.
bun tgui:dev- Launch a development server.bun tgui:dev --reload- Reload byond cache once.bun tgui:dev --debug- Run server with debug logging enabled.
bun tgui:lint- Show (and auto-fix) problems with the code.bun tgui:tsc- Check code with TypeScript compiler.bun tgui:test- Run unit and integration tests.bun tgui:analyze- Run a bundle analyzer.bun tgfont:build- Build icon fonts.
Important Memo
Remember to always run a full build of tgui before submitting a PR, because it comes with the full suite of CI checks, and runs much faster on your computer than on GitHub servers. It will save you some time and possibly a few broken commits! Address the issues that are reported by the tooling as much as possible, because maintainers will beat you with a ruler and force you to address them anyway (unless it's a false positive or something unfixable).
Troubleshooting
Development server isn't attaching to the game
Make sure that you have a tgui window open before you run the dev server. Then, once it's running, you may need to press F5 to refresh the page.
Development server is crashing
Make sure path to your working directory does not contain spaces, special unicode characters, exclamation marks or any other special symbols. If so, move codebase to a location which does not contain these characters.
Development server doesn't find my BYOND cache!
This happens if your Documents folder in Windows has a custom location, for
example in E:\Libraries\Documents. Development server tries its best to find
this non-standard location (searches for a Windows Registry key), but it can
fail. You have to run the dev server with an additional environmental variable,
with a full path to BYOND cache.
BYOND_CACHE="E:/Libraries/Documents/BYOND/cache"
Webpack errors out with some cryptic messages!
Example:
No template for dependency: PureExpressionDependency
Webpack stores its cache on disk since tgui 4.3, and it is very sensitive to build configuration. So if you update webpack, or share the same cache directory between development and production build, it will start hallucinating.
To fix this kind of problem, run bin/tgui --clean and try again.
Dev Server Tools
When developing with tgui-dev-server, you will have access to certain
development only features.
Debug Logs. When running server via bin/tgui --dev --debug, server will
print debug logs and time spent on rendering. Use this information to optimize
your code, and try to keep re-renders below 16ms.
Kitchen Sink. Press F12 or click the green bug to open the KitchenSink
interface. This interface is a playground to test various tgui components.
Layout Debugger. Press F11 to toggle the layout debugger. It will show
outlines of all tgui elements, which makes it easy to understand how everything
comes together, and can reveal certain layout bugs which are not normally
visible.
Browser Developer Tools
WebView2 is chromium based, so you can access the dev tools much easier than its predecessor. Simply go to debug tab in your stat panel and click "Allow Browser Inspection". You can then f12 to open the standard chrome dev tools.
Project Structure
/packages- Each folder here represents a self-contained Bun module./packages/common- Helper functions that are used throughout all packages./packages/tgui/index.ts- Application entry point./packages/tgui/interfaces- Actual in-game interfaces./packages/tgui/layouts- Root level UI components, that affect the final look and feel of the browser window. These hold various window elements, like the titlebar and resize handlers, and control the UI theme./packages/tgui/routes.ts- This is where tgui decides which interface to pull and render./packages/tgui/styles/main.scss- CSS entry point./packages/tgui/styles/functions.scss- Useful SASS functions. Stuff likelighten,darken,luminanceare defined here./packages/tgui/styles/atomic- Atomic CSS classes. These are very simple, tiny, reusable CSS classes which you can use and combine to change appearance of your elements. Keep them small./packages/tgui/styles/interfaces- Custom stylesheets for your interfaces. Add stylesheets here if you really need a fine control over your UI styles./packages/tgui/styles/layouts- Layout-related styles./packages/tgui/styles/themes- Contains themes that you can use in tgui. Each theme must be registered in/packages/tgui/index.tsfile.
License
Source code is covered by /tg/station's parent license - AGPL-3.0 (see the main README), unless otherwise indicated.
Some files are annotated with a copyright header, which explicitly states the copyright holder and license of the file. Most of the core tgui source code is available under the MIT license.
The Authors retain all copyright to their respective work here submitted.