veloren / veloren Goto Github PK

If there are any features you need (like socket send/recv splitting) just ask.

Currently the packet are just a big enum serialized as-is which limits the way we can craft packet.

For example it's hard to have packet with conditional data.

You could use an Option at the moment but :

• if things get's nested heavily it's gonna be unreadable
• if the packet contains a hundred conditional fields like the EntityUpdate will contains later (sending only changed fields), the packet will be twice the size it needs to be because of the way the serializer works with enums, and given the frequency and size of EntityUpdate, it's really bad.

A good idea would be to separate thing out like this :

• A packet struct containing the pure data
• A packet serializer/deserializer (which could use the
• A packet handler to fill/do things with the pure data

Create a API what allows server to offload/save parts of his information (per chunk) via a Storage API.
This storageapi should support multiple backends: file, sqllite, postgres later on

More details about this proposal can be found here: https://github.com/veloren/game/wiki/Architecture-And-Network-Messaging-Proposal

The new job system would:

• Allow concurrent operations to be programming in a readable, verbose, and simple way

• Provide a single 'one true' way to perform concurrent tasks across the codebase without a different implementation needing to be written for each one.

This proposal is strongly tied to the post messaging proposal [clarification needed].

Things to address:

• Does this integrate well with an ECS?

• Does this cause potential deadlocks, or not have the features necessary to implement certain parts of the codebase as they exist today?

Suggestions, comment and discussion is very welcome on this topic.

The server crate should supply nearby chunks over the network to clients on request.

On my machine (Win10). If I minimize the window and come back anytime the cursor should be ungrabbed (i.e. I press esc) the cursor seems to stay invisible.

Possibly a bug with glutin?

More information here: https://doc.rust-lang.org/std/cell/index.html

For example, we really shouldn't be doing interior mutability using an internal type like this (increased risk of deadlocks, among other issues): https://github.com/veloren/game/blob/master/voxygen/src/game.rs#L43

This should probably be part of the move towards implementing the worldgen system.

Some ideas for information that could be transmitted:

• velocity
• orientation
• animation state
• label (NPCs get names, player entities get their alias)

voxygen.log.2021-03-30.txt

This error showed up while attempting to play on a Raspberry Pi 4B 4gb using Flatpak to install it.

I got this when i try to log-in and join to server.

I have already account.

Hello,
my son has an older PC with Windows10. Installation is working fine and the airshipper is starting.
But then he always get a error-message.

His PC:

The error message:

Unfortunately, we can't see what exactly the problem is.

We tried the compatibility mode and also started it with admin privileges.
Are there any other options or is it something that the awesome Veloren team can fix?

Best thankful regards
Rumo

we need a test that simply loads all voxel files in the voxygen/vox files and tries to load them into a model.
This way Voxel Artists can know if there is any incompatibility between their uploads and the engine.

The method already exists, you just need to reuse the functions from voxygen/src/game.rs for all those files. and maybe write a test in .gitlab-ci.yaml to automatic run this

• Basic world/chunk generation
  • Client-side chunk generation
  • Minor optimisation
• Customizable key bindings
• Single cube as player model
  • We went a step further: basic player model
• Basic player movement
  • X/Y movement
  • Velocity
  • Gravity
  • Jumping
  • Proper collision system
• Simple connected/disconnected server events, including entity updates
  • Connection, disconnection
  • Chat messages
  • Realtime player / entity updates
• User interface
  • Chat interface
  • Ability to connect to server using UI
• Headless client
  • Create headless client
  • Implement backspace in headless
• Repo Management
  • evaluate whats needed for gitlab (because if we do it now we have a short buffer to test it fully productive, to revert in case it doesnt fit before 0.2.0 start)
  • code style (evaluate all of them and check if anything needs to be done here)
  • remove old files no longer needed (.old files and worldtest?)
  • fix importing headers
  • rename classes
  • squash files together (e.g. in server) or make 2 files of one (e.g. client/lib)
  • move files to correct folder
  • reduce warnings
  • remove unused dependencies
  • check if all dependencies share same version over project
  • write basic tests for smaller components
  • check comments
• have a public party at the server to cheer us up a little

As mentioned by zesterer, this function is linked to a graphics issue and needs to be fixed.

Here is a summary of my system specs using Speccy:

Operating System
Windows 7 Professional 64-bit SP1
CPU
Intel Core i5 2520M @ 2.50GHz 55 °C
Sandy Bridge 32nm Technology
RAM
4.00GB Single-Channel DDR3 @ 664MHz (9-9-9-24)
Motherboard
LENOVO 4291T27 (CPU) 51 °C
Graphics
LCD 1366x768 (1366x768@50Hz)
Intel HD Graphics 3000 (Lenovo)
Storage
298GB HITACHI HTS723232A7A364 ATA Device (SATA ) 37 °C
Optical Drives
No optical disk drives detected
Audio
Conexant 20672 SmartAudio HD

Also, this is a text file with the full system spec dump:

TOM-PC.txt

Make worldsim internally concurrent and externally concurrent (i.e: other things can still call functions on it while a world simulation update is occuring)

By splitting the world into 'metachunks' we can seriously cut down the time required to lock any one portion of the world during a world update. This should have performance improvements across the board. It's also possible to implement a lock-less data structure.

Example Conrod code: https://github.com/PistonDevelopers/conrod/blob/master/examples/all_winit_gfx.rs

The UI should be able to:

• Show player attributes

• Show incoming and outgoing chat messages

• Show a menu when pausing

Syrup::Window appears to react slowly to sending messages currently, this could be a potential issue with our implementation or the crate itself.

As of a recent commit, the client moved to a payload system for frontend wishing to add additional payloads of their own to types used inside the client. Currently, we only have a single associated type, but this is ripe for expanding to other areas of the codebase: https://github.com/veloren/game/blob/master/client/src/lib.rs#L60.

We need to think about:

• Is this a good idea?

• What implications may it have down the line?

• Is it worth expanding this to the server and other areas of the codebase?

• How many other uses does it have?

• Does it improve or hurt readability?

Entity updates should be sent to all players when a significant change is made.

All players positions shall be tracked by the Server crate.

We need an API that is accessible from the Game structure to enable/disable cursor trapping

This could use the payload system.

[More detail needed]

How am I supposed to stalk this project if I don't know what it's about?! 😜

Hey there,

thanks for this project. I would really like to play it and further develop it but I am using Arch Linux with an Intel and Nvidia gpu. I would like to manually select which gpu should be used.

Thanks for any kind of help.
IJustDev

Currently, we use 16 as the chunk size. This is hard-coded in several places (you can search through the changes on 70408ca to find them all). It should be controlled by a single static constant instead.

It would prevent avatars staying in game if the client didn't disconnect properly. It should send few "are you alive" ping packets first. I suggest timeout time 10s and sending 3 ping packets to client every 500ms later (if one succeeds don't send more).

Things that need doing:

• Rename Connection to MsgMgr
• Make MsgMgr use Conn internally
• Consider genericising Conn to allow for TCP and UDP sockets (low priority)
• Use interior mutability to avoid excessive use of Arc

https://github.com/veloren/game/blob/master/region/src/entity.rs#L18

The first three methods do not follow the naming convention for getters and setters. I suggest renaming the methods to get_pos, get_movdir, and get_lookdir.

currently packages are send directly over the Socket, however it would be good if the ClientConnection and ServerConnection have multiple socket support (TCP and UDP socket) and the ClientPackage or ServerPackage has some kind of information like reliable, fast, e.t.c which is evaluated by the Connection so that the correct socket is choosen there.
We could implement TCP, UDP, interprocess message

If the client attempts to move the player out of the ground too fast, the position reset code here https://github.com/veloren/game/blob/master/server/src/network/handlers.rs#L83 can come into play. This should be less of a problem with the new collision system, but it's probably still important to consider how we avoid this and similar problems in the future.

We need to transfer large amounts of chunk data. I envisage chunks as large as 32x32x256 blocks at ~4 bytes each, which gives us exactly 1 megabyte per chunk.

Can we handle this on the network side? Should we use some form of chunk compression? Note that erasing colour from the voxel data and generating colour variation client-side could help make the data more suitable for something like RLE.

Note that not everybody has a decent internet connection. This needs to be acceptably quick on anything as slow as 500 Kilobits/s, I'd say.

The new collision system needs to be extensible (to allow further modification to player mechanics in the future). Among other things, it needs to:

• Perfectly resolve voxel collisions from all angles and at all velocities (up to a reasonable level)

• Allow CubeWorld-like "jumping" up steps

• Prevent jitters/glitching and other visually displeasing behaviour

• Be able to detect player states such as "on ground", "up against wall", "touching a ceiling", etc.

As an initial implementation, I was thinking of taking the collision system from a recent game engine of mine, seen here: https://www.youtube.com/watch?v=-XlgEY9RcSk. Annoyingly, it can require quite a lot of collision tests to resolve a collision though.

Does anybody have any thoughts?

I was trying to test the project on my machine (Windows 10) but I have some issues when running a "cargo run" on server-cli (I have the same problem with voxygen tho):

I have no idea what's exactly is happening, all I know is that I installed Rust from the README.md link, same for the SFML library (with https://github.com/jeremyletang/rust-sfml/wiki/How-to-use-rust-sfml-on-Windows). All deps are correctly downloading, but compiling doesn't work.

Im cant join the Veloren server. I get this message only trying to connect to the server. Singleplayer works fine. No errors. Im using Flatpak. Mar 30 12:39:02.878 WARN veloren_client: Server is running 5ccbfba8[2021-03-30], you are running c8e191e1[2021-03-29], versions might be incompatible! Mar 30 12:39:04.370 INFO veloren_common_sys::plugin: Searching "/app/share/veloren/assets/plugins" for plugins... Mar 30 12:39:04.370 ERROR veloren_common_sys::state: Failed to read plugins from assets e=Io(Os { code: 2, kind: NotFound, message: "No such file or directory" }) Mar 30 12:39:04.370 INFO veloren_common_sys::state: Error occurred when loading plugins. Running without plugins instead. Mar 30 12:39:05.331 ERROR veloren_voxygen::menu::char_selection: [char_selection] Failed to tick the client err=StreamErr(Deserialize(Custom("invalid value: integer 1130889216, expected variant index 0 <= i < 15"))) Mar 30 12:39:05.354 INFO network{p=tqg69B}::remote{p=UbQ5z6}:recv: veloren_network::participant: protocol failed, shutting down channel e=Closed cid=0 Mar 30 12:39:05.366 INFO network{p=tqg69B}:network{p=tqg69B}:remote{p=UbQ5z6}: veloren_network::api: Participant already has been shutdown gracefully Mar 30 12:39:05.368 WARN network{p=tqg69B}: veloren_network::api: Runtime seems to be dropped already e=Sender { inner: Some(Inner { state: State { is_complete: false, is_closed: false, is_rx_task_set: false, is_tx_task_set: false } }) }

Further understanding is required on font renderering vs texture rendering and 2D texture rendering.

Commands will come in under ClientPacket::SendCommand and should be dispatched in a manner that handlers can be written for each command and extended by modders in the future.

Commands will need access to a set API from the server which will need to include the player and perhaps the world.

The server crate should generate new chunks as players approach that region of the world.

This will also involve refactoring the crate to use the Error type internally.

Visit https://gitlab.com/veloren/veloren/issues to report an issue.

This should be implemented server-side and is dependent on #57 being resolved.

As mentionned in the discord chat today :

Mac os : Catalina 10.15.7

Terminal msg when changing to unsupported cloud setting : [INFO] [Veloren] Nov 07 22:42:29.524 WARN gfx_device_gl::shade: Log: WARNING: Could not find fragment shader output 'Target2' to match FragDataBinding request.

Black screen description :

Happening from the character selection window to the ingame.
Everything is black as if it was night but it isn't. bag items maps windows or chat show normally.

The texture and environement is showing normally when changing the cloud setting to "low" or "none".

Hey i know that you have Gitlab for issues but is it used for pull requests too?
I prefer GitHub pull requests but i need to know