Fixing grub error about unsigned kernel in Ubuntu

Just a quick note in case someone else runs into the same issue as me: I have a machine running Ubuntu 18.04 (LTS), and in order to get some of the hardware working, I used ukuu to upgrade the kernel from the Ubuntu versions (4.15.0.xx.xx) to an upstream version (4.18.20).

At first this caused me no problems, but after a while, I started to run into the following message when trying to update packages:

Cannot upgrade Secure Boot enforcement policy due to unsigned kernels

Your system has UEFI Secure Boot enabled in firmware, and the following kernels present on your system are unsigned:

4.18.20-041820-generic

These kernels cannot be verified under Secure Boot. To ensure your system remains bootable, GRUB will not be upgraded on your disk until these kernels are removed or replaced with signed kernels.

What seems to be happening is that newer versions of grub enforce more secure booting policies, which is a good thing. The problem is that the upstream kernels aren’t signed with Ubuntu’s trusted keys.

When I googled for this problem the suggestions seemed to be disabling UEFI secure booting in the BIOS, or removing the kernels. Removing the kernels would break some of my hardware, and I didn’t want to disable the secure boot setting because I sometimes boot the machine to Windows and I really don’t want any malware inserting itself secretly into the Windows boot process (I don’t want this on Linux either, but any malware that has root permissions on my Linux boot has already won).

After I realised what I needed to actually google for, I found this Ubuntu blog article which explains how to create a machine owner key (MOK), set up Ubuntu to trust it, and sign things with it. I followed the steps described starting with “Certificates in shim” to generate and enrol a certificate. (You may be able to use update-secureboot-policy directly to create and enrol the certificate, but I didn’t discover that until I got to the end of the blog article, so I haven’t tried that way.)

It’s worth noting as you read that article that you do not want to include “1.3.6.1.4.1.2312.16.1.2” in the extendedKeyUsage of your certificate or you’ll only be able to sign kernel modules and not kernel themselves.

I then used sbsign as described in the article to sign /boot/vmlinuz-4.18.20-041820-generic. I moved the original to a different directory for safekeeping and replaced it with the signed version. (Keeping both versions side by side in /boot/ is a bad idea because grub will see both and still complain about having an unsigned one there.)

I then did two final steps:

sudo dpkg-reconfigure grub-pc

This causes grub to rebuild its menus. This is probably not strictly necessary because I didn’t actually add any new kernels to /boot/, but I thought it was worth running to make sure there weren’t any errors.

sudo dpkg --configure grub-efi-amd64-signed

This fixes the installation of the package that was broken. If all goes according to plan, it should no longer show an error.

Posted in midlength | Tagged , , , , | Comments Off on Fixing grub error about unsigned kernel in Ubuntu

Trosnoth Development Priority: Simple Server Deployment

Earlier this year, a volunteer on Übertweak tried to use Trosnoth on camp, but couldn’t work out how to run and configure a Trosnoth server. In the current version of Trosnoth, the server is not shipped in any easy-to-use bundle; instead, you must run the Trosnoth server from the source code. This effectively means that you need an expert present to run a Trosnoth server. If the person on camp with the motivation to run Trosnoth does not have the required expertise, it doesn’t work.

I consider this to be a major failure in Trosnoth. Trosnoth was created many years ago for use on Übertweak. If it can’t be easily used on camp, this is a problem.

Over the weekend, we released Trosnoth 1.13.0. This was a huge milestone, incorporating many months of work and completely overhauling some Trosnoth internals.

In January, I listed some upcoming Trosnoth development priorities, and said that I hadn’t yet decided on the importance of each priority. That has now changed. Now that version 1.13.0 is released, all other development priorities are on hold until we’ve fixed this shortcoming. The aim of the next release is to make it really easy to install, configure and run your own Trosnoth server, so that people can play Trosnoth at LANs or on camps without any specific technical knowledge.

Posted in short | Tagged , , | Comments Off on Trosnoth Development Priority: Simple Server Deployment

Trosnoth in 2018 and Beyond

The past year has been a good year for Trosnoth. Over this time, we have:

  • migrated Trosnoth to Python 3
  • made several UI improvements, including adding indicator lights around orbs, showing the short names of friendly players on the minimap, and adding a respawn gauge to all ghosts
  • adjusted the costs of items based on observed usage
  • added a way for players to select their preferred scenario for the next match, along with a bunch of new scenarios including Elephant King, Orb Chase and Cat Among Pigeons
  • updated the server to keep track of some statistics across multiple matches in a tournament
  • made huge improvements to the momentum-based physics that was released in late 2017: we overhauled the collision detection to use separating axis theorem which eliminates the possibility of falling through walls; we also made improvements to how grappling hook works (these are yet to be released)
  • as part of the grappling hook changes, given players the ability to hold on to roof surfaces, and shoot while holding onto walls and roof
  • made bots feel a bit more fair—they have a short simulated reaction time, but they’re still a challenge to defeat
  • fixed a bunch of bugs
  • made other minor changes and improvements in response to player feedback
  • made fair progress towards bots using the updated momentum-based physics

Trosnoth League

In 2018 a small number of players formed a Trosnoth League. Once a month we scheduled time to play Trosnoth competitively online. The internet causes some frustrations that aren’t experienced on a LAN (chiefly of the, ‘I hit you on my screen!’ variety). But our experiences showed us that internet Trosnoth is still a lot of fun!

One of the fun things we did during Trosnoth League was to play Human vs. Machines matches. These matches were often very tense matches. Over the course of the year, 8 HvM matches were won by the humans, compared to 6 won by machines.

Trosnoth League also provided regular opportunity for player feedback—we often played with an alpha or beta Trosnoth version and solicited feedback. This resulted in us fixing a number of minor annoyances for players, and adding a number of low-effort medium-payoff features to the game. For instance, we added a visual indicator for ninjas to see how close they can get to enemy orbs before being seen, and we made it possible to remap the right mouse button (previously only keyboard keys could be remapped).

If you’re interested in joining in Trosnoth League in 2019, please fill out this survey, and also send an email to the trosnoth-players Google group to ask us how to join in.

Project Participation

In 2017, three people contributed code to Trosnoth. In 2018, there was only me. This 67% drop isn’t a concern in itself, but it does serve to illustrate how the project operates at the moment: I’m the main code contributor, and other contributors offer a bit of code every so often as they’re motivated an able. Maybe this is ok for a working game like Trosnoth, but I’d still love more regular contributors. We’ve actually never been great at attracting new coders to Trosnoth. Almost all of the occasional contributors were contributors 8 to 10 years ago when the project was still getting off the ground. If you’re a coder and you’re interested in helping out with Trosnoth, please get in touch! I’ll be as helpful and encouraging as I can!

The previous paragraph may sound like doom and gloom, but having no new coders doesn’t mean I’m the only one involved in the project. Trosnoth League has been a great source of ideas and suggestions, and has also resulted in one or two people contributing to future artwork and design of Trosnoth, which I find exciting! And there are still 5–10 people who help me decide on project priorities when I do spend time on Trosnoth.

I always welcome new contributors to Trosnoth, but right at the moment we don’t have any regular contributors with particular expertise in game graphics, and it would also be really cool to have someone who could put together video tutorials or a Let’s Play. Please get in touch if you’d like to be involved! You can connect with us on the trosnoth-dev Google Group.

Trosnoth repository history over the past 5 years (number of commits)

Releases and Artist in Residence Grant

2018 saw three Trosnoth releases in January, April and May. This means that there has been no new release in over six months. The man thing that’s been holding up the release of Trosnoth 1.13.0 is the bot pathfinding: I’d like the bots and humans to be using the same physics, but that can’t happen until the pathfinding is working. I keep thinking that I’ve almost finished updating the pathfinding code only to find that there’s more to do.

One huge motivator to work on the bot pathfinding was when I was named as the Pygame Artist in Residence in October. During October I wrote a bunch of Trosnoth-related blog posts, but I also spent significant time working on bot pathfinding. (I did a time-lapse video of my work too!)

The Artist in Residence program also came with a small grant of money. I spent some of it obtaining a Windows code signing certificate and related hardware, so future releases of Trosnoth should actually be signed!

What Next: Server Deployment, New Levels, Chrome, and Synchronisation

Once I finally finish the bot path-finding, there are a few different ideas that I’d like to work on. I haven’t yet prioritised these, so I can’t tell you which one is coming soon. But here are four things somewhere in the pipeline at present:

  1. Simpler server deployment: I want to make it really easy to install, configure and run your own Trosnoth server, so that people can play Trosnoth at LANs even without specific technical knowledge.
  2. New levels: And not just new levels, but a restructure of how levels work so that there are coherent rooms such as a control centre, cargo bay, living quarters, recreation areas, and so on.
  3. HTML and CSS UI elements: I’d like to experiment with using Chromium Embedded Framework for some Trosnoth UI elements. This wouldn’t be used to render the game itself, but for menus and some parts of the heads-up display. One potential advantage of this approach is that it allows people who know HTML and CSS to tweak the UI without forcing them to learn how Python and pygame work. This also might simplify things if we ever move to using Panda3D for rendering: the HTML/CSS parts wouldn’t need to be rewritten to make the shift.
  4. Speed/smoothness/synchronisation improvements: At the moment Trosnoth has a very workable process for synchronising the game state between the server and clients. But I’d like to generalise what Trosnoth does into a separate library. This will allow for more automated testing of the synchronisation code, and more consistency and robustness. This will also make it easier to reason about the code when making improvements to how the game handles internet latency smoothly.

With the current level of time I spend on Trosnoth, I don’t expect to complete more than one (or at most two) of these four things in 2019, but that gives you an idea of where things are heading at the moment.


Posted in long | Tagged , , , , , | Comments Off on Trosnoth in 2018 and Beyond

Timelapse Trosnoth Development Video

Sometimes an artist in residence program has a closing exhibition. In October 2018 I was pygame.org’s virtual artist in residence. As a kind of closing exhibition for this artist residency, I’ve put together a time-lapse video of most of my Trosnoth development during October.

If you want to actually be able to read any of the text on the screen you’ll probably need to watch it in 1080p.

Enjoy!

 

Posted in short | Tagged , , , , , , , , | Comments Off on Timelapse Trosnoth Development Video

Platformer Physics and Trosnoth

Reminder: in October 2018, I’m pygame.org’s artist in residence. You can ask me questions about Trosnoth, support me in my Trosnoth development, and follow this blog for articles about Trosnoth and what I’m working on.

Intro to platformer physics

Trosnoth is essentially a platform game. Sure, it’s not a traditional, one-player platform game where the main goal is to avoid obstacles and get to the end of the level. But it’s still a 2D side-view side-scroller with platforms and obstacles, so it counts as a platformer in my books.

Platform games have unusual physics. You might think, ‘Can’t you just use real-world physics with maybe a lower gravitational constant?’ But the answer is a resounding, ‘No’. As it turns out, it’s really hard to jump with agility between platforms or dodge bullets in mid-air in real life. The main aim of platformer physics is to feel responsive, not to be realistic.

In this article, I’ll briefly outline the steps in Trosnoth’s player physics calculations. I’ll go into some detail, but because October is nearly over and I said I’d write four blog articles this month, I’ll gloss over a few of the finer details.

How Trosnoth calculates collisions

An important part of game physics is calculating collisions between solid things. In the case of player movement, the important collisions to detect are between players and obstacles (walls, roofs, platforms and floors). Some games store the map as a grid of tiles, but Trosnoth’s approach is to store obstacles as polygons. Each player has an elliptical collision solid, and we calculate collisions using separating axis theorem.1

You may not think you needed to know that, but the following outline assumes you already know we’re using polygons instead of tiles.

Step 1: is the player on the ground?

The first step in Trosnoth’s physics calculations is to work out if the player is touching the ground. Trosnoth’s approach is to ask, ‘If the player moved downwards by a very small amount, would it hit something?’ If the answer is yes, then the player is on the ground.

Side note: one-way platforms

Trosnoth’s approach to one-way platforms is this: if the player is pressing the down key, then one-way platforms are completely intangible to that player. So if the player would otherwise be standing on a one-way platform, but they are holding the down key, then that player is not considered to be on the ground.

Step 2: jumping and dropping

The second step is to check if the player is trying to jump, or to drop from a wall or roof. These checks only apply if the player is on the ground or is hanging from a wall or roof. Dropping is quite straightforward: if the player is pressing the down key, or whichever of the left or right keys which would move the player away from the wall or roof, then the player drops.

Jumping is slightly more involved. If the player is allowed to jump and is pressing the jump key, then their vertical velocity is set to a fixed upward value. That’s the straightforward bit. But we also have two short timers that apply to jumping.

Firstly, there’s a brief window of time after a player has dropped from a roof or wall during which they are still allowed to initiate a jump. This window exists to account for cases where a player is hanging onto a wall and tries to press sideways and jump, but actually presses the sideways key just before the jump key. Without this window, the player would fall from the wall, then because they are in the air the jump key would do nothing. But this window makes the game behave as if they pressed the keys together.

Secondly, during the first few hundred milliseconds of a jump, the vertical velocity stays at a constant upward velocity unless the player releases the jump key first. This allows the player to jump to different heights depending on how long they hold the jump key for. In addition to this, when the player releases the jump key while they’re still moving upwards, their vertical velocity is set to zero. This makes the jump movement feel slightly more responsive: you let go of the jump key, and you immediately stop jumping.

Screenshot from Cosmo’s Cosmic Adventure. Source: Wikipedia

Step 3: acceleration

Trosnoth originally had very retro physics. Think Commander Keen or Cosmo’s Cosmic Adventure. If you were holding down the left or right keys, you moved left or right at a constant horizontal speed. More recently though, we’ve added momentum-based physics to the development branch. Here’s how it works:

Firstly, if a player grabs onto a wall or roof, their velocity is instantly set to zero. Apart from this, there are two possibilities:

Moving along the ground

If a player is on the ground, they’re either running, walking or slowing. They’re running if they’re holding down the left or right key and facing in the same direction. They’re walking if they’re holding down the left or right key and facing in the opposite direction. If they’re not holding the left or right key, the player is slowing.

When a player starts running, they have their velocity in the direction of the ground surface set to a particular minimum run speed. They then accelerate at a constant rate up to a maximum run speed. When a player is walking, they decelerate at a constant rate down to a minimum walk speed. When a player is slowing, they decelerate at the same rate, but decelerate all the way to zero.

Moving through the air

If a player is in the air, their acceleration is determined by whether they are pressing the left or right arrow keys. But if the player is travelling faster than a certain horizontal velocity, pressing the arrow key will not accelerate them any more in the direction they are travelling. But this is not a horizontal terminal velocity: if a player is already travelling faster than that speed (e.g., after speeding themselves up with the grappling hook) then they will not automatically have their horizontal velocity capped to that value.

After horizontal acceleration is applied, gravity is applied. This is just a constant vertical acceleration, capped at a vertical terminal velocity. If the player is moving along the ground, gravity is only applied if their grappling hook is attached somewhere.

Step 4: grappling hook

After we’ve worked out what the player’s velocity should be, we constrain that velocity to certain limits if the grappling hook is attached. In this step we basically work out how much rope is left and ensure that the player’s motion doesn’t exceed the length of the rope during this iteration.

Trosnoth’s grappling hook pulls the player in at a constant minimum rate. The player can move in more quickly than the minimum, e.g. by jumping or running towards the point where the hook is attached.

If the player’s velocity is pulling them away from the grappling hook’s pull by more than a certain amount, then the grappling hook snaps and the player is released. This check was added to make it easier to use the grappling hook to swing horizontally without having all of the player’s momentum lost by the pull of the grappling hook.

Step 5: actually applying the velocity

At this point, the player’s velocity has been calculated. The player’s motion for this iteration is then calculated by multiplying this velocity by the time interval, then we check if they would hit an obstacle. If so, we check if this collision qualifies as grabbing a wall.

To grab a wall, a player either needs to be pulling themselves in by grappling hook and be almost all the way in, or the collision needs to be with a vertical wall and the player needs to be pressing the direction key that would push them further into the wall. If the player has grabbed a wall, then that’s the end of their motion.

If the player has collided with an obstacle but the collision occurred within only a very tiny distance of the player’s original position, then we rerun the calculation once, but only consider the component of the player’s velocity that runs along the surface of the obstacle they collided with. We do this recalculation to avoid cases where a player is at the corner of two obstacles and we detect the wrong collision first.

If the player does collide with an obstacle and it doesn’t qualify as grabbing a wall, then we damp the component of the player’s velocity that is normal to the obstacle.

Step 6: adhering to the ground

If the player started this iteration on the ground, we check if projecting a ray downwards a certain distance from the player would still collide with the ground. If so, we move the player down to on top of the ground. This is to avoid the player leaving the ground (and thereby being unable to jump) with every little bump or corner on the ground.

Step 7: discretisation

As a final step, if the player is holding onto a wall or roof, or they are on the ground and completely still, we look up their rough position in a database of possible stationary positions, and move them to the position in the database. This is not at all necessary for human players, but as I wrote about last week, it’s very helpful to simplify the search space for bot path-finding. And since Trosnoth aims to be scrupulously fair, we do this for human players as well as bots.


Notes

1 We calculate collisions mostly using separating axis theorem. We use slightly different calculations for one-way platforms because they aren’t complete solid polygons.

 

Posted in long | Tagged , , , , | Comments Off on Platformer Physics and Trosnoth