DOCS: moved more documentation over to the mkdocs portal

master
Martin Gerhardy 2020-12-01 00:11:20 +01:00
parent 390ad0bd1b
commit 92b3339536
12 changed files with 120 additions and 80 deletions

View File

@ -2,3 +2,7 @@
This application allows you to connect to a running gameserver and inspect and change the state of
every single ai controlled entity.
![image](https://raw.githubusercontent.com/wiki/mgerhardy/engine/images/aidebug-connect.png)
![image](https://raw.githubusercontent.com/wiki/mgerhardy/engine/images/aidebug-debug.png)

View File

@ -1,4 +1,16 @@
# Hot reloading
# Animations
There is a [test application](TestAnimation.md) that is able to play all of the supported animations and to test them during development..
## LUA
You can write your animations in lua scripts - but keep in mind that this is of course not as fast as writing them in C++ - you should only use this during development for faster round trip times.
Besides writing the animations in lua, the skeleton properties are stored in lua.
## Hot reloading
*(This is for the C++ code)*
For debug builds, the animations are linked into a shared object that is loaded into the `AnimationSystem` class. This feature is __not__ active for release builds.

View File

@ -1,4 +1,4 @@
# Purpose
# Attributes
The attrib module manages containers with attributes that can be attached to any item or entity in the world.
@ -7,9 +7,9 @@ Attributes are things like speed, strength, intelligence (see the network defini
The attributes are then calculated by the different containers an entity has assigned (via equipment, or directly
to the character). The absolute values are summed up, and then the percentage modifiers are added on top.
If you e.g. get a debuff or debuff this is just applying a container to your entity. The values are communicated
If you e.g. get a buff or debuff this is just applying a container to your entity. The values are communicated
to the client and some are also broadcasted to other clients that are seeing you.
# LUA
## LUA
The containers are defined in lua scripts. See the attribute files that are coming with the tests, or with the server.

View File

@ -1,7 +1,5 @@
# Network layer
## General
The network layer is based on udp (enet) and shared between client and server.
It uses flatbuffers to generate C++ classes from fbs files that defines the protocol.
@ -19,3 +17,12 @@ part of the protocol to always have them in sync with each other.
* [server] performs auth
* [auth failed] => [server] sends `AuthFailed` message
* [auth successful] => [server] sends Seed [server] broadcasts to visible `UserSpawn`
## CVar replication
There are cvars that are replicated to all players on a server. The flag for this is `CV_REPLICATE`. If the server changes a value of such a cvar, the change
is automatically transfered to all connected clients. This cvar value is also initially for each new connection to ensure that the server and the client share
the same values for these cvars.
User related cvars that are broadcasted to other players are marked with `CV_BROADCAST`. These values are also submitted to any other player that can see the
entity.

View File

@ -1,6 +1,65 @@
# Databasetool
# Persistence layer
## Table descriptions for the databasetool
## General
This module manages the persistence layer and provides drivers to talk to the database. Currently the only driver implemented is for postgresql.
The main class for doing database interaction is the `DBHandler`.
In order to generate models that represent the tables, you can use the `databasetool` to generate the models from metadata files.
A more high level class to manage updates is the `PersistenceMgr`. It collects dirty-marked models and performs a mass-delta-update via prepared statements. You should use this for e.g. player updates.
It's always a good idea to check out the unit tests to get an idea of the functionality of those classes.
## DBHandler
You have to create the models with the `tbl` file and generate C++ classes with the `databasetool` (see existing `tables.tbl` file CMake integrations. Usually you put your classes into the C++ namespace
`db`. Once you have those models, you can use the generated getters and setters to prepare the model. This can now get send over to the `DBHandler`. There are methods to insert, update, count, delete
or select particular entries from tables via the model values.
Copying the Model class instance is no problem, it's fast. The stuff that is copied is only 32bytes at the moment.
### Create (and update) table
```cpp
_dbHandler->createOrUpdateTable(db::EventModel());
```
The persistence layer has automatic upgrading and downgrading support for your tables. By defining them in a `.tbl` file, the system is able to generate the needed `ALTER` statements to get to your desired state.
Workflow to update a table:
- Edit the `tbl` file
- Run your build
- Run the application
- The table, constraint, sequence... is updated to the state that is defined in your code. This allows you to go back and forth in your commits to test things. ***But keep in mind that removing a column from a table can lead to data loss. Because re-adding it, doesn't remember the previous values of course.***
### Select by condition
```cpp
_dbHandler->select(db::EventModel(), persistence::DBConditionOne(), [this] (db::EventModel&& model) {
[...]
});
```
### Multiple search conditions
```cpp
const db::DBConditionTestModelEmail emailCond("a@b.c");
const db::DBConditionTestModelName nameCond("Foo Bar");
_dbHandler->select(db::TestModel(), persistence::DBConditionMultiple(true, {&emailCond, &nameCond})), [this] (db::TestModel&& model) {
[...]
});
```
## PersistenceMgr
This class is responsible to submit chunks for accumulated database updates. If you e.g. collect an item and soon after collect another one, this class will sum the items up and only generate one sql statement, instead of two.
## Databasetool
### Table descriptions for the databasetool
The databasetool binary will generate model files for the
table definitions given in `*.tbl` files. You can specify the fields,
@ -20,7 +79,7 @@ are put into.
The generated models can be used with the `DBHandler` from the `persistence` module.
## Example
### Example
If no classname is specified, the table name will be used with `Model` as postfix.
@ -54,39 +113,39 @@ table <TABLENAME> {
}
```
## table
### table
A definition starts with `table <TABLENAME>`. The body is enclosed by `{` and `}`.
### classname
#### classname
This can be used to override the auto generated class name. The auto generated class name is generated from the table name converted to UpperCamelCase. This converts a table name like `my_table` to `MyTable` or `mytable` to `Mytable`.
### namespace
#### namespace
You specify a namespace in your table definition that is called `mynamespace`. The table is called `MyTable`. The resulting c++ class will live in `mynamespace::db::MyTable`. If you omit the namespace setting in your table definition, the class will live in `db::MyTable`.
### schema
#### schema
Specifies the schema name that should be used for the table.
### field
#### field
A field describes a table column, the name, the type and so on. This block is enclosed by `{` and `}`.
#### default
##### default
The default value for the field.
#### length
##### length
Specifies the optional length of the field.
#### notnull
##### notnull
If this is specified, the field may not be null.
#### operator
##### operator
The operator is taken into account when you execute an insert or
update statement and hit a unique key violation.
@ -97,17 +156,17 @@ you will hit a key violation and thus perform the insert or update with
the operator specified. The default operator is `set`. See a full list
of valid operators below.
##### Valid operators
###### Valid operators
* `set`
* `add`
* `subtract`
#### lowercase
##### lowercase
Convert a string value to lowercase before entering it into the database. This may not be set for `password` types of course.
#### type
##### type
Valid field types
@ -122,13 +181,13 @@ Valid field types
* `byte`
* `blob`
### constraints
#### constraints
Here you can specify foreign key constraints, auto increment values and so on. This block is enclosed by `{` and `}`.
See the example above for a list of supported constraints.
## Other notable features
### Other notable features
* Timestamps are handled in UTC.
* When using `int` or `short` as a field type, there is also a setter configured that accepts enums.

View File

@ -1,4 +1,4 @@
# Animation test tool
# testanimation
The test application can cycle through all animations and entity types. It helps to visualize
the skeletal animation states of the entities in the game.

View File

@ -1,7 +1,5 @@
# Traze
## About
This is a voxel based representation of the traze game available at [traze.iteratec.de](https://traze.iteratec.de).
It uses mqtt for communication. The lib that is used for this is [mosquitto](https://github.com/eclipse/mosquitto).
@ -12,7 +10,7 @@ to move your bike, you are joined.
![image](https://raw.githubusercontent.com/wiki/mgerhardy/engine/images/traze.png)
## TODO
# TODO
* add scoreboard menu
* player explosions

View File

@ -4,6 +4,10 @@ Convert voxel volume formats between each other or export to obj or ply.
[Supported voxel formats](../Formats.md)
![image](https://raw.githubusercontent.com/wiki/mgerhardy/engine/images/voxconvert-export-to-obj.png)
![image](https://raw.githubusercontent.com/wiki/mgerhardy/engine/images/voxconvert-export-obj.png)
## Usage
`./vengi-voxconvert --merge --scale infile outfile`

View File

@ -2,6 +2,8 @@
This is an opensource, cross platform voxel volume editor.
You can load and save a lot of different [voxel formats](../Formats.md).
![image](https://raw.githubusercontent.com/wiki/mgerhardy/engine/images/dwarf-in-editor.jpeg)
![image](https://raw.githubusercontent.com/wiki/mgerhardy/engine/images/voxedit-custom-shader.png)

View File

@ -40,4 +40,11 @@ nav:
- Shader integration: ShaderTool.md
- Compute Shader integration: ComputeShaderTool.md
- Persistence: Persistence.md
- Animations: Animations.md
- Attributes: Attributes.md
- Network: Network.md
- AI development: AIRemoteDebugger.md
- Test applications:
- TestAnimation: TestAnimation.md
- Traze: Traze.md
- VisualTests.md

View File

@ -1,6 +1,5 @@
local c_halfPi = math.pi/ 2.0
local toolOrientation = boneutil.rotateYZ(math.rad(-90.0), math.rad(110.0))
local vec3_one = vec3.new(1.0, 1.0, 1.0)
function swim(animTime, velocity, skeleton, skeletonAttr)
local timeFactor = skeletonAttr.runTimeFactor

View File

@ -1,52 +0,0 @@
# Persistence layer
## Purpose
This module manages the persistence layer and provides drivers to talk to the database. Currently the only driver implemented is for postgresql.
The main class for doing database interaction is the `DBHandler`.
In order to generate models that represent the tables, you can use the `databasetool` to generate the models from metadata files.
A more high level class to manage updates is the `PersistenceMgr`. It collects dirty-marked models and performs a mass-delta-update via prepared statements. You should use this for e.g. player updates.
It's always a good idea to check out the unit tests to get an idea of the functionality of those classes.
## Usage DBHandler
You have to create the models that are usually put into the namespace `db`. Once you have those models, you can use the generated getters and setters to prepare the model. This can now get send over to the `DBHandler`. There are methods to insert, update, delete or select particular entries from tables via the model values.
Copying the Model class instance is no problem, it's fast. The stuff that is copied is only 32bytes at the moment.
### Create (and update) table
```cpp
_dbHandler->createOrUpdateTable(db::EventModel());
```
The persistence layer has automatic upgrading and downgrading support for your tables. By defining them in a `.tbl` file, the system is able to generate the needed `ALTER` statements to get to your desired state.
Workflow to update a table:
- Edit the `tbl` file
- Run your build
- Run the application
- The table, constraint, sequence... is updated to the state that is defined in your code. This allows you to go back and forth in your commits to test things. ***But keep in mind that removing a column from a table can lead to data loss. Because re-adding it, doesn't remember the previous values of course.***
### Select by condition
```cpp
_dbHandler->select(db::EventModel(), persistence::DBConditionOne(), [this] (db::EventModel&& model) {
[...]
});
```
### Multiple search conditions
```cpp
const db::DBConditionTestModelEmail emailCond("a@b.c");
const db::DBConditionTestModelName nameCond("Foo Bar");
_dbHandler->select(db::TestModel(), persistence::DBConditionMultiple(true, {&emailCond, &nameCond})), [this] (db::TestModel&& model) {
[...]
});
```