Project Structure: Development vs Release

[!WARNING] This part of the documentation is only lightly maintained. Content may be out of date or may have been partially generated by AI and could therefore contain errors.

Two Different Structures

The project has two completely different folder structures:

Development structure (for working) → Source code, tests, docs
Release structure (for users) → Compiled EXEs, finished config

[!WARNING] You MUST always use the correct structure for the situation. Wrong paths = errors!

Development Structure (for Development)

Streaming_Tool/                 ← Root (this is where you work)
├── src/                        ← SOURCE CODE
│   ├── python/                 ← Python files
│   ├── plugins/                ← Plugin source code
│   └── core/                   ← Core modules
├── defaults/                   ← Template files
│   ├── config.default.yaml     ← Config template
│   ├── actions.mca             ← Command template
│   └── ...
├── docs/                       ← Documentation (here!)
├── build.ps1                   ← Build script
├── build/                      ← Build intermediates
│   └── cache/                  ← Cached EXEs
└── tests/                      ← Unit tests

Release Structure (What Users Get)

build/release/                  ← READY TO RUN
├── core/                       ← Compiled EXEs
│   ├── app.exe                 ← Main program
│   ├── update.exe              ← Updater
│   └── runtime/                ← .NET Runtime
├── config/                     ← User settings
│   ├── config.default.yaml     ← Template (do not edit!)
│   └── config.yaml             ← User copies this!
├── data/                       ← Persistent data
│   ├── plugin_state.json       ← State storage
│   └── logs/                   ← Error logs
├── plugins/                    ← Finished plugin EXEs
│   ├── deathcounter.exe
│   ├── timer.exe
│   └── ...
├── version.txt                 ← Version & Updater version
├── README.md                   ← Info for users
└── LICENSE                     ← License

Important Differences

Aspect	Development	Release
Path in code	`src/python/`	`./` (EXE runs from release root)
Load config	`defaults/config.yaml`	`config/config.yaml`
Save data	PROJECT_ROOT/data	`./data/` (relative to EXE)
Logs	`.../logs/`	`./data/logs/`
Generated by	(you write)	`build.ps1` generates

Critical Rules

☑ Always use release paths in code (as soon as it is deployed)
☑ Config NEVER in the source code (always relative ./config/)
☑ Data persists across updates (./data/ is not deleted)
☑ Develop docs in the dev folder (docs/dev-book-de/src/)
☑ After changes: test build.ps1 (checks paths)

→ Back to Appendix

[!WARNING] Make sure that for file paths and other file-related operations, you always use the release structure. The development structure differs significantly from the release structure. If you accidentally use paths from the development structure, this can lead to errors because files in the release are located elsewhere or are structured differently.

Pay particular attention to the following points:

Always use the paths from the release structure in code, scripts, and documentation when referring to the finished project.

Do not rely on development files being present in the release.

For new files or folders, check whether they are correctly included in the release by build.ps1.

When changing configurations or runtime data, think carefully about whether they belong in config/, data/, core/, or runtime/.

Always test the build after making changes so that no missing paths or broken references are overlooked.

Make sure updates do not overwrite important data, especially in the data/ and config/ directories.

Development Structure

The development structure contains everything needed to build the project.

.
├── assets
│   └── gifts_picture
├── build
│   ├── exe_cache
│   └── release
├── build.ps1
├── defaults
│   ├── actions.mca
│   ├── config.default.yaml
│   ├── config.yaml
│   ├── configServerAPI.yml
│   ├── DelayedTNTconfig.yml
│   ├── gifts.json
│   ├── http_actions.txt
│   └── pack.mcmeta
├── docs
│   └── dev-book
├── LICENSE
├── README.md
├── src
│   └── python
├── static
│   └── css
├── templates
│   ├── db.html
│   └── index.html
├── tests
├── tools
│   ├── DelayedTNT.jar
│   ├── Java
│   ├── MinecraftServerAPI-1.21.x.jar
│   └── server.jar
└── upload.ps1

`assets/`

This is where the project's visual resources are located. The subfolder gifts_picture/ contains images for the gifts.

`build/`

This folder is used by the build process. It does not contain any development logic — only intermediate results and the finished output.

exe_cache/ stores EXE files so they don't have to be regenerated every time.
release/ is the destination folder for the finished project.
Hash files can also be found there. They tell the program whether it needs to build a new EXE or whether it can be copied from the exe_cache folder.

`build.ps1`

The build script is the central engine of the project. It collects the individual components, processes them, and creates the finished version.

If you make changes to the project, make sure to also update the build.ps1 script so that everything is built correctly. Unless, of course, you want to build manually — that's possible too.

`defaults/`

This folder contains the default files for the project. They serve as the starting point for configurations, data, and project values.

Important files include:

config.default.yaml
config.yaml
configServerAPI.yml
DelayedTNTconfig.yml
gifts.json
actions.mca
http_actions.txt
pack.mcmeta

This folder is particularly important because it defines the initial state. When the project is set up fresh, these files serve as the baseline.

`docs/`

Additional documentation, notes, and technical information can be found here.

`docs/dev-book/`

The technical documentation is located here as an mdBook project.

book/ contains the generated documentation
src/ contains the actual chapter texts

This is the written companion to the project.

`src/`

The actual source code lives here.

python/ contains the Python part of the application

This is where logic is created, modified, and extended.

`static/`

This folder contains static resources for appearance and user interface.

css/ for stylesheets and layout

Everything that can be served directly without dynamic computation belongs here.

`templates/`

This folder contains HTML templates.

index.html
db.html

These templates define the structure for pages and interfaces that are later populated with data.

`tests/`

The test area is used to verify the project's behavior. Tests, verification runs, and automated checks can be carried out here.

`tools/`

This folder contains additional tools and external dependencies.

DelayedTNT.jar
MinecraftServerAPI-1.21.x.jar
server.jar
Java/

These files and folders are important for features that rely on external components.

`LICENSE`

The license file defines the legal framework for use.

`README.md`

The README is the first point of contact for anyone who wants to understand or start the project. It provides an overview of the content, purpose, and basic usage.

`upload.ps1`

Another PowerShell script that is automatically generated by the build.ps1 file. It is used to upload the project directly to GitHub with one click.

Release Structure

After the build process, the finished project version is created in the build/release/ folder.

.
├── config
│   ├── config.default.yaml
│   └── config.yaml
├── core
│   ├── app.exe
│   ├── assets
│   ├── gifts.json
│   ├── gui.exe
│   ├── lib
│   ├── LikeGoal.exe
│   ├── mcServerAPI.exe
│   ├── Overlaytxt.exe
│   ├── PortChecker.exe
│   ├── runtime
│   ├── static
│   ├── templates
│   ├── timer.exe
│   ├── validation.exe
│   ├── WinCounter.exe
│   └── window.exe
├── data
│   ├── actions.mca
│   └── http_actions.txt
├── LICENSE
├── logs
├── README.md
├── scripts
├── server
│   ├── java
│   └── mc
├── server.exe
├── start.exe
├── update.exe
└── version.txt

`config/`

The runtime-relevant configuration files are located here.

config.default.yaml
config.yaml

This means both a default and a customized configuration are available.

`core/`

This is the heart of the finished application. The executable software and the resources needed at runtime are located here.

Included are, among others:

app.exe
gui.exe
LikeGoal.exe
mcServerAPI.exe
Overlaytxt.exe
PortChecker.exe
timer.exe
validation.exe
WinCounter.exe
window.exe

Additionally:

assets/
gifts.json
lib/
runtime/
static/
templates/

This folder bundles the actual functional core of the release. The runtime/ folder is particularly useful for data needed at runtime that is not relevant to the user.

[!CAUTION] When the program is updated, the entire core/ folder is overwritten. If you have data that should not be overwritten, use the data/ folder.

`data/`

Data needed at runtime or for certain features is stored here. Unlike the runtime/ folder, data/ is never overwritten.

actions.mca
http_actions.txt

`logs/`

The log folder stores logs and traces. This is important for tracing errors, events, and the behavior of the application.

`scripts/`

This folder contains additional scripts for the finished version. Helper functions or maintenance routines can be located here.

`server/`

Server-related components are located here.

java/
mc/

`start.exe`

The main entry point for users. Anyone launching the release typically starts here.

`update.exe`

This program handles updates. It can be used to install new versions or update existing installations.

`version.txt`

A small but important file containing the build version information. It also contains the version of the updater.

`LICENSE` and `README.md`

These files are also included in the release. This ensures that terms of use and a short introduction are always bundled.

The project is structured so that everything stays neatly organized and the individual parts can be managed well. Take your time to explore the project structure and go through the folders one by one. This will give you a quick feel for where each piece of data belongs.

The build.ps1 script is particularly important. It's your best friend because it builds everything automatically. If you had to do this manually, it would take a very long time. It's therefore worth knowing the build file well and adapting it when changes are made to the project.

Streaming Tool Dev