DOCS: moved more documentation over to the mkdocs portal
parent
390ad0bd1b
commit
92b3339536
|
@ -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)
|
||||
|
|
|
@ -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.
|
||||
|
|
@ -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.
|
|
@ -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.
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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`
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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) {
|
||||
[...]
|
||||
});
|
||||
```
|
Loading…
Reference in New Issue