Games Planet

FGD_planet

RSS feed aggregator for FOSS games.

ZeroK: Zero-K v1.8.9.1 – Control Cleanup and Idle Improvement

A few tweaks to help new players ballooned into several major efforts aimed at improving the new player experience. As is often the case, I couldn’t add a piece of UI without making it extra smart and configurable, so the result is a cleaner and more powerful interface for everyone. Once you see the cleaner command panel you won’t want to go back to the full messy version, although you may want to go into the settings to unhide your favourite advanced unit states.

In other news I (GoogleFrog, writing this) have a Patreon. It is new, since the last release, and the aim is to free up a bit more time to support Zero-K.

The map above is a new version of Twin Lakes Park by TheMooseIsLoose.

Idle Behaviour

Idle units now give up and return to their old location if they move too far while chasing enemies (previously they could be baited across the whole map). This can be disabled by setting a unit to Roam. Raiders and riots are also a bit smarter about how they react to enemies while idle.

  • Idle raiders move to stay out of range when approached by riots or most other raiders.
  • Idle riots perform similar behaviour against skirmishers and against riots with greater range.
  • Units that have been pushed back in this manner only move a short distance. When pushed too far they will turn and attack.

While some attempt was made to generate good chase and push distances, there are around 1002 unit matchups so the configuration is a little rough. Expect tweaks and improvements in future patches.

Also, drones now return to their host if they stray too far away.

Command Panel

The command panel has a simple mode so as to not overwhelm new players with esoteric commands. I liked it so much that I added configuration options, to give even those that was a few more commands a nice clean panel.

  • Replaced the icons for Repeat, Movestate and Firestate.
  • Command and state position/ordering is now stable and consistent.
  • Simple mode has slightly larger state toggles, large enough to show hotkeys. The old size can be enabled under Settings/HUD Panels/Command Panel (with Simple Settings disabled).
  • Dual-toggle Hold Fire and Hold Position states replace Movestate and Firestate by default. Under the hood they toggle Hold Fire/Fire At Will and Hold Position/Maneuver. The full triple-toggle states can be enabled under Settings/Interface/Commands.
  • Added the hotkey ‘H’ to toggle movestate.
  • Approximately one third of the states and command are now hidden by default. The visibility of each command or state can be toggled under Settings/Interface/Commands.
  • The position and order of the commands/states cannot be configured ingame. This requires a local configuration file found here.

Camera Controls

Many games have save/recall camera hotkeys, and it is an easy enough widget to write, so there was no reason not to add it.

  • Added bindable camera save/recall position hotkeys, and more control over alerts and transition times. These can be bound under Hotkeys/Camera/Camera Position Hotkeys.
  • Added the option to remove most advanced features from Combo Overhead/Free Camera, which can be enabled and configured under Settings/Camera with Simple Settings disabled. It can now be made to ignore shift, ctrl or alt, and can be permanent set to a particular tilt.

First Game Guide

There is now an interactive ingame guide that appears in your first non-campaign game. It is enabled by default to catch those who might need it. Experienced players can simply disable it with the X, and it can be enabled via Help.

Additional Improvements

  • Added Scalpel to Fencer unit AI.
  • In the lobby, watching a game or playing singleplayer no longer removes you from matchmaking queues.
  • Command queue transparency can be configured in the main menu under Settings -> Game.
  • The main menu settings menu now informs people that most settings only take effect upon entering the next game.
  • Improved metal and energy image extended economy tooltips.
  • Area Mex now queues one Solar with ctrl held, two with alt, and four with ctrl+alt. Previously it would queue four with ctrl.
  • Missile Silo no longer repeatably fires with repeat enabled. This frees up repeat to be used to loop the build queue. An attack command may be repeated by issuing it with ctrl held.
  • Added an experimental overlay that summarises visible reclaim. It can be enabled with ‘Toggle Field Summary’ under Settings/Interface/Reclaim Highlight (with Simple Settings disabled).
  • Added selection hotkey settings for Swift, Thunderbird and Athena. They can be set under Hotkeys/Selection.
  • Improved a few tooltips so that they are more descriptive. Move suggests line move. Reclaim/Repair suggests area reclaim/repair.
  • Added more icons for the menu entries.

Fixes

  • Fixed command tooltips defaulting to those set by the engine instead of being overridden.
  • Added startboxes for Supreme Crossing.
  • Fixed terraform height presets being unable to make walls around structures with ctrl held.
  • Terraform structure height no longer lets you try to make land-only structures underwater.
  • Fix factory plate UI on unit transfer within team.
  • Added Construction Plates to the cheat sheet unit spawner.
  • Fixed Merlin firing issues with save/load and improved walk animation.
  • Removed Misc Priority from units with shields that do not drain energy.
  • Optimised the defence range indicator.
  • Optimised the metal spot visualiser.
  • Fixed a performance issue in a piece of code that was meant to be disabled.
  • Fixed a bug with Zenith.
  • Fixed some incorrectly displayed rank icons in the extended player list.
  • Removed Dante lookahead as it seems to interact poorly with multiple weapons.
  • Dual wielding commanders now prefer to aim with their shorter ranged weapon.
  • Fixed a chicken spire error caused by there being no burrows.
  • Fixed a minor bug with AFK sharing.
  • Fixed Gauss localisation.
Continue Reading →

This Week In Veloren 85

This week, we have a new art blog by @Pfau. @xMAC94x goes into detail on how we
measure networking statistics.

– AngelOnFira, TWiV Editor

Contributor Work

Thanks to this week’s contributors, @xMAC94, @Sharp, @tylerlowrey, @Imbris,
@Slipped, @TheThirdSpartan, and @mttmartin42!

@Pfau is back at the Veloren art blogs! You can check out No. 7
here. @Capucho is still
trudging through the magic that in WGPU. @Awkor has been doing work on an
inventory autosort proof of concept. @James is Working on new hotbar skill for
the axe and a new m2 for the hammer (moving current m2 to the hotbar). @Sam is
working on a sword overhaul.

@Songtronix wrote a discord bot (@Veloren) to control his testing server. It
includes:

  • Switching branches easily
  • Querying the status of the server (updating, compiling) at any time
  • Downloading the database
  • Viewing server settings

Retouch of a repeating crossbow by @AlbinoAxolotl

Improved Server Metrics To Improve Server Performance by @xMAC94x

The first step of optimizing Veloren’s server code is to know what runs the
slowest. If we were to optimize less impactful areas, they wouldn’t impact the
end-user as much. We are using Prometheus metrics to gather data in real-time
from our main server.

With some recent additions, we are now able to get the following metrics:

  • Chunks requested from the server: every time a client asks for a chunk we
    will see how the server reacts. We can see if it need to compute the chunk or
    if it can just send a chunk which is already loaded because another player is
    already there.
  • Chunk generation: when a chunk needs to be generated it is queued. This
    metrics will help us to see if this queue is getting bigger over time or if it
    remains at a healthy size.
  • Active players: players online is now split into players connected and
    disconnected. This makes it easy to detect single events and even lets us
    detect when a client joins in the same time other leaves. The online players
    will be calculated with the difference. For disconnect, we now also track the
    event (i.e. Gracefully Close, Timeout, Network error). Though currently, under
    some conditions a network error is thrown for what is actually a graceful
    close.
  • State timings: Even deeper look at our engine’s State timings. Before we
    only had a total time for our entire state. Now we can get the state timings
    based on each subsystem. It shows that physics likely needs the next
    optimisation.

Theory Of Continuous Prometheus Metrics

Metrics are generated every tick, but are actually only polled by the Prometheus
server every 2 seconds. This means we only get a metric for every 60th tick.
There are now multiple ways to handle this, especially in relation to timing
data. Until now, we have always exported the last tick’s timing. This meant we
got 100% accurate timings on 1 out of 60 ticks, and no timing information on the
remaining 59 ticks. We just had to assume that all the other 59 ticks are
probably the same as this one tick. But we have no way of knowing if the tick we
received was part of the 95th percentile, meaning much faster or slower than the
rest. This information is important, as super slow ticks are the ones that cause
lag.

Another way to tackle this problem is by summing up the timings. We can still
poll the data every 2 seconds (60 ticks). So we get the total time spend for our
all of these ticks, but aggregated together. However, just take the average and
assume each tick was just 1/60 of that value. Or if there is a slow tick and 59
fast ticks, there is no way of knowing.

A Steppesman’s recurve bow by @AlbinoAxolotl

For this case, Prometheus has histograms. They provide buckets for different
time ranges, lets say <1ms, 1-5ms, 5-10ms, >10ms. With Histograms, each tick
will increase a number in its corresponding bucket. So if we have a super fast
tick, it will increase the number in the <1ms bucket. if we have a super slow
tick we increase the number in >10ms. We will be using a combination of BOTH.
summing up all ticks AND histograms in the future to detect the average time we
spend in a certain part of our code as well as make sure, that we don’t have any
spikes causing lags.

Altogether, these new techniques will allow us to get much better telemetry
about the outliers. Often it’s hard to make networking work well purely from
what seems to be best in theory. Veloren’s application is unique in many ways,
and so we will have to keep striving to analyze how it runs from the data.

Deer by the river. See you next week!

Support our devs!

Veloren Open Collective

Continue Reading →

ZeroK: GoogleFrog has a Patreon

Since receiving intermittent nudges from a few people, I now have a Patreon page. The primary goal is to gain more time to develop Zero-K, however I don’t want support to simply go towards “business as usual”. If people support me then I should spent at least some of my extra time on tasks that are important but not necessarily the most exciting. To this end, I have decided to put more of a focus on testing and reviewing contributions from the community. A contributor who receives faster and better feedback is more likely to fall deeper into development, strengthening the project. If you like and can support this goal, or just want to support me doing Zero-K development, then I’d appreciate it.

Here is the page: https://www.patreon.com/googlefrog

Continue Reading →