Add flatbuffers for base world state #7
Conversation
server/src/main.rs
Outdated
| #[allow(dead_code, unused_imports, clippy::redundant_field_names)] | ||
| #[path = "../target/flatbuffers/world_generated.rs"] | ||
| mod world_generated; | ||
| pub use world_generated::tankrs::{get_root_as_world, World, WorldArgs}; |
server/schema/world.fbs
Outdated
| namespace Tankrs; | ||
|
|
||
| table World { | ||
| width: uint16; |
There was a problem hiding this comment.
Please add comments for these fields (e.g. how wide the world is in number of blocks).
There was a problem hiding this comment.
Additionally, I would like us to use id number for these schemas so we can order them logically.
There was a problem hiding this comment.
Can you write an example for how an id number annotation looks?
There was a problem hiding this comment.
width: uint16 (id: 0);
However, this does look more cluttered. I don't know if the advantage of being able to logically group fields outweighs this.
server/build.rs
Outdated
|
|
||
| fn main() { | ||
| flatc_rust::run(flatc_rust::Args { | ||
| inputs: &[Path::new("schema/world.fbs")], |
There was a problem hiding this comment.
Can we glob **.fbs? That way we would not have to add to this every time we make a new flatb module.
There was a problem hiding this comment.
Good suggestion. Unfortunately the type specification is a slice of paths. We can dynamically generate a slice of paths in the future.
mingyli
force-pushed
the
ming/world-flatbuffers
branch
from
a89a7ac
to
5280e91
Compare
schema/world.fbs
Outdated
| cell_width: uint16 = 40; | ||
| cell_height: uint16 = 40; |
There was a problem hiding this comment.
This constant will be determined on the frontend.
No part of the backend should need this.
There was a problem hiding this comment.
This is not frontend. We will need these attributes in order to do projectile physics.
There was a problem hiding this comment.
-
I am under the impression that this flatbuffer will only be generated to send through the wire. Nothing that the user does not need will not be here.
-
We can do the projectile physics without a set pixel width for each cell. We will have an implicit coordinate system, mapping the coordinate system to actual pixels is only necessary to render, not do math.
There was a problem hiding this comment.
Okay, then we don't need to have an explicit grid. Our coordinate system can be smooth
|
|
||
| jobs: | ||
| flatbuffers: |
There was a problem hiding this comment.
Can you describe in the PR description why all of this is necessary?
.github/workflows/main.yml
Outdated
| @@ -66,4 +145,5 @@ jobs: | |||
| - uses: actions-rs/cargo@v1 | |||
| with: | |||
| command: clippy | |||
| args: --manifest-path=${{env.cargo-path}} -- -W clippy::all -W clippy::pedantic -D warnings | |||
| args: --manifest-path=${{env.cargo-path}} | |||
| # args: --manifest-path=${{env.cargo-path}} -- -W clippy::all -W clippy::pedantic -D warnings | |||
There was a problem hiding this comment.
I would like to keep all of these if possible.
There was a problem hiding this comment.
Unfortunately the severities must be set elsewhere. If they are specified in flags, they will lint the generated Rust code by default.
There was a problem hiding this comment.
Does this help?
There was a problem hiding this comment.
Unfortunately it does not:
|
@yizzlez PTAL |
This PR adds the base flatbuffers for use as the base world state.
Test Plan:
Run
cargo run.flatcis a tool to generate Rust code given a flatbuffers schema. In order to get this working with Github Actions, a build step must be added to installflatc.