This Week In Veloren 14

This week, we take a look at the new asset storage system and the current state of the 0.2.0 milestone. Lots of neat art this week as well!

Thanks to this week's contributors to the main repo, @Pfau, @AngelOnFira, @imbris, @robojumper, and @Yeedo!

Programming

Asset Storage System Change

This week, the project changed from using Git Submodules to Git Large File Storage (LFS). There were many reasons for this, primarily that Git Submodules required a lot of support for people wanting to contribute for the first time.

The way Git Submodule works is that it is essentially another repo inside the main Veloren one. This way, the art assets can be put in their own repo. A problem with this is every time the asset repo is updated, the main repo also has to be updated with information about the latest commit on the asset repo. On top of this, extra commands have to be used to download the submodule, and sometimes these can break.

The original reason that we needed to switch to an asset storage system in the first place is that the main repo was getting cluttered with PNG files. Each of these files was part of the Git history, and so every time someone would clone the repo, they would have to clone the code and the image files.

However, even after the PNG files were deleted from the main repo, they still had to be downloaded. This is because the way that Git calculates what the current files are is based upon the full history of the repo. Every time a PNG file is changed, Git would store the old copy and the new copy in the history.

The new solution we are moving to is Git LFS. This method allows us to work naturally with one repo, and simply tell Git which files should be stored differently. What this means is that any time a file of a certain type (PNG, VOX, TTF, WAV, OGG) is encountered in the repo, it is uploaded to LFS. These files must only be downloaded once when cloning, even if there are multiple versions of them.

This solution should provide all of the functionality we need in regards to storing assets, but without as many issues.

The next step on this course is to look into Git BFG, which will allow us to re-write history on the repo so that we can remove the PNG images. Since this is something that will mess up every branch that is being worked on, we are waiting until the code freeze at the end of 0.2.0 to do this.

Current state of 0.2.0

Now that it is May, the deadline for 0.2.0 is approaching quick. As you can see in the burndown chart, we have been decreasing at some points, but generally looking at an upwards trend. This is because as we add more functionality, we see more that needs to be done, and we add more issues.

This weekend, a group of the core contributors will be meeting to discuss what tasks should get done for 0.2.0, and what should be bumped to 0.3.0. Once these tasks get shifted, then the chart should start to look more achievable.

Take a look here for more details on the milestone.

Recap

This week, there has been a lot of work that ha

@desttinghim has taken up the task of the audio system, which is being worked on from scratch. @Yeedo got their work on the help window merged.

@Zesterer has locked himself away to work on an entirely new networking protocol that implements the benefits of TCP but without the excess and unneeded overhead. He has also improved compression on networked messages, which will allow for easier terrain information sending in the future. Here is an explanation of the system by @Zesterer

So effectively, there are 4 layers to the system

1. Ordering
2. Fragmentation
3. Reliability
4. Checksum

You can choose to use any combination of those layers in the configuration of 256 independent "streams". Except for the first one, that's mandatory due to network limitations. The message descends through the layers, picking up various networking guarantees as it goes.

The first layer, ordering, makes guarantees about the order that packets may appear in relative to the stream they were sent down.

The second layer, fragmentation, splits the message up into smaller chunks called "fragments". This is needed because UDP has a pretty tiny maximum message size: too tiny for chunk data.

The third layer, reliability, manages ACKs and ensures that messages always reach their destination and does so in a very low-latency manner that I'm actually quite proud of.

The fourth layer applies a checksum to the entire packet and ensures that only packets that have correct checksums are received on each side.

@Zesterer has also worked on terrain gradients and FXAA.

@Slipped has been working on character jumping.

@imbris has done some debugging on the FPS drop due to thread spawning. They have also been working with @Timo and @Pfau on the asset system.

Something else that @Timo has been working on is cleaning the UI code. The hud right now is over 2000 lines of code, which makes it extremely difficult to work with. This will be changed, with the files becoming much more modular. Each file will have its own purpose, such as map.rs, and skillbar.rs. From @Timo,

"Each file will contain one main struct that is a custom conrod widget (impl Widget for Map). When some piece of information needs to be shared with the rest of the hud (like when show_debug is toggled in the settings) the structs update method will return an Event that says what happened. This is also useful when closing windows because they can emit Event::Close and the hud will not render it anymore"

Veloren Code Challenge III v2

We've had very few responses to last week's challenge on our reddit, so we're going to leave this challenge up for another week!

Knowing that you have very little time to spare, you run down to a plot of farmland that has been prepared for you. This land has been tilled to prepare for normal crops, but the three beans that you have should be planted in the most fertile soil.

Art by @Pfau