Today we are going hands on with two powerful Godot plugins, Waterways and Heightmap Terrain for Godot. Both are open source add-ons that work in Godot 3.2.x and both are hosted on GitHub. In the video below we showcase using easy add-on and show how they work well together.

Waterways

Formally known as WaterGenGodot on GitHub, Waterways enables you to quickly create rivers using spline controls. You have full control over the path the river follows, the look of the water and even have fine tuned control over the foam generated by collisions with other objects in the scene.

Heightmap Terrain

This add-on adds terrain creation tools to Godot. Either import and existing heightmap or create your own from scratch. You get full sculpting tools for raising and lower terrain, simulating erosion, etc. You also get tools for painting the texture layer on your newly created terrain. You also get the ability to export as a mesh or heightmap for use in other applications or engines.

Getting Started Tutorial

Installing the plugins is a straight forward exercise. Clone each project from GitHub to a directory of choice. You can get the git url on GitHub here:

Assuming you have a git client installed, from a command line run the command git clone then the copied url. For example:

git clone https://github.com/Arnklit/WaterGenGodot.git

Now in your Godot project (or create one if you dont have one already), create a folder called addons then copy the addons directory from the two just cloned projects. In your project you now simply need to enable each addon. In Godot go to Project->Project Settings menu. Now switch to the Plugins tab and make sure both are enabled:

Now you’re ready to go! Be sure to check the video below to see both Water Ways & Heightmap Terrain for Godot add-ons in action.

As Covid-19 affected our personal and working lives, 2020 was a year of unimaginable change. Microsoft on the Issues covered topics including cybersecurity, digital skills accessibility and more, and the pandemic influenced many of the stories we brought you.

As we say goodbye to 2020, here’s a look at some of this year’s most read stories, from the Puget Sound region and beyond.

Data, supplies, community: How Microsoft is supporting efforts to combat Covid-19

Family, friends and co-workers around the world are facing the effects of the Covid-19 pandemic. Managing response efforts requires the cooperation of every sector of society. Back in March, we offered this resource to communities, non-profits and government officials.

Everyone should have access to digital skills. New grants aim to help

Microsoft’s skills initiative hopes to help 25 million people around the world secure digital skills. In June, Microsoft made a public commitment to be more inclusive as an employer and to extend Microsoft’s support and outreach programs in Black and African American communities. As part of this, Microsoft’s community skills program will provide financial grants and tech enablement to community-based non-profits reaching 5 million unemployed workers who need it most.

This is a look at i.c.stars, a rigorous, tech-focused program that provides young adults from low-income communities with the tools to develop the technical and leadership skills needed for a career in technology, a field that continues to lack diversity and be in high demand.

What is ElectionGuard?

Every election year, millions of Americans are eligible to cast their ballots to elect officials ranging from members of school boards to the President of the United States. Those millions of voters need to be confident that the democratic process is carried out without interference.

However, in recent years, technology designed to help elections run smoothly has been targeted by those seeking to influence, subvert or sabotage democracy. Microsoft has been working with governments, NGOs, academics and industry on the Defending Democracy Program. One of the components is ElectionGuard, explored in this article.

An inside look at the global battle with botnets

In March, a small team at Microsoft dismantled Necurs, one of the world’s largest botnets. It was a project that was eight years in the making, and involved coordinated legal and technical action from 35 countries. Botnets are highly sophisticated, acting as a unified threat and often run by well-resourced operators. Tracking them down and preventing them from carrying out further infections and attacks is a complex task that takes coordination across geographies and organizations. This article explored the battle with botnets around the world.

Understanding accessibility through ABCs

At Microsoft, we focus on the maxim of “nothing about us, without us” in order to create technology for people with and without disabilities. Creating and developing technologies for everybody to use involves embracing diversity and an inclusive culture in Microsoft’s own workforce.

The main obstacle to inclusion and diversity is the lack of awareness. As a starting point to educate and share, we shared our ABCs of Accessibility, from A to Z.

How AI is helping map the world’s most vulnerable places

There are places in the world that have not been mapped in detail. In the event of a natural disaster that can be a problem, as rescue teams try to understand where their help might be needed. The Humanitarian OpenStreetMap Team, or HOT, is working with Microsoft’s AI for Humanitarian Action program and Bing to combine satellite mapping, machine learning and an army of volunteers to create detailed and potentially life-saving maps. This story looks at the work HOT is doing, particularly across Africa, and explains how these maps are part of the effort to contain Ebola.

Fedora CoreOS is a lightweight, secure operating system optimized for running containerized workloads. A YAML document is all you need to describe the workload you’d like to run on a Fedora CoreOS server.

This is wonderful for a single server, but how would you describe a fleet of cooperating Fedora CoreOS servers? For example, what if you wanted a set of servers running load balancers, others running a database cluster and others running a web application? How can you get them all configured and provisioned? How can you configure them to communicate with each other? This article looks at how Terraform solves this problem.

Getting started

Before you start, decide whether you need to review the basics of Fedora CoreOS. Check out this previous article on the Fedora Magazine:

Terraform is an open source tool for defining and provisioning infrastructure. Terraform defines infrastructure as code in files. It provisions infrastructure by calculating the difference between the desired state in code and observed state and applying changes to remove the difference.

HashiCorp, the company that created and maintains Terraform, offers an RPM repository to install Terraform.

sudo dnf config-manager --add-repo \ https://rpm.releases.hashicorp.com/fedor...icorp.repo

sudo dnf install terraform

To get yourself familiar with the tools, start with a simple example. You’re going to create a single Fedora CoreOS server in AWS. To follow along, you need to install awscli and have an AWS account. awscli can be installed from the Fedora repositories and configured using the aws configure command

sudo dnf install -y awscli

aws configure

Please note, AWS is a paid service. If executed correctly, participants should expect less than $1 USD in charges, but mistakes may lead to unexpected charges.

Configuring Terraform

In a new directory, create a file named config.yaml. This file will hold the contents of your Fedore CoreOS configuration. The configuration simply adds an SSH key for the core user. Modify the authorized_ssh_key section to use your own.

variant: fcos

version: 1.2.0

passwd: users: - name: core authorized_ssh_keys: - "ssh-ed25519 AAAAC3....... user@hostname"

terraform { required_providers { ct = { source = "poseidon/ct" version = "0.7.1" } aws = { source = "hashicorp/aws" version = "~> 3.0" } }

}

Terraform uses providers to control infrastructure. Here it uses the AWS provider to provision EC2 servers, but it can provision any kind of AWS infrastructure. The ct provider from Poseidon Labs stands for config transpiler. This provider will transpile Fedora CoreOS configurations into Ignition configurations. As a result, you do not need to use fcct to transpile your configurations. Now that your provider versions are specified, initialize them.

provider "aws" { region = "us-west-2"

} provider "ct" {}

The AWS region is set to us-west-2 and the ct provider requires no configuration. With the providers configured, you’re ready to define some infrastructure. Use a data source block to read the configuration.

data "ct_config" "config" { content = file("config.yaml") strict = true

}

With this data block defined, you can now access the transpiled Ignition output as data.ct_config.config.rendered. To create an EC2 server, use a resource block, and pass the Ignition output as the user_data attribute.

resource "aws_instance" "server" { ami = "ami-0699a4456969d8650" instance_type = "t3.micro" user_data = data.ct_config.config.rendered

}

This configuration hard-codes the virtual machine image (AMI) to the latest stable image of Fedora CoreOS in the us-west-2 region at time of writing. If you would like to use a different region or stream, you can discover the correct AMI on the Fedora CoreOS downloads page.

Finally, you’d like to know the public IP address of the server once it’s created. Use an output block to define the outputs to be displayed once Terraform completes its provisioning.

output "instance_ip_addr" { value = aws_instance.server.public_ip

}

Alright! You’re ready to create some infrastructure. To deploy the server simply run:

terraform init # Installs the provider dependencies

terraform apply # Displays the proposed changes and applies them

Once completed, Terraform prints the public IP address of the server, and you can SSH to the server by running ssh core@{public ip here}. Congratulations — you’ve provisioned your first Fedora CoreOS server using Terraform!

Updates and immutability

At this point you can modify the configuration in config.yaml however you like. To deploy your change simply run terraform apply again. Notice that each time you change the configuration, when you run terraform apply it destroys the server and creates a new one. This aligns well with the Fedora CoreOS philosophy: Configuration can only happen once. Want to change that configuration? Create a new server. This can feel pretty alien if you’re accustomed to provisioning your servers once and continuously re-configuring them with tools like Ansible, Puppet or Chef.

The benefit of always creating new servers is that it is significantly easier to test that newly provisioned servers will act as expected. It can be much more difficult to account for all of the possible ways in which updating a system in place may break. Tooling that adheres to this philosophy typically falls under the heading of Immutable Infrastructure. This approach to infrastructure has some of the same benefits seen in functional programming techniques, namely that mutable state is often a source of error.

Using variables

You can use Terraform input variables to parameterize your infrastructure. In the previous example, you might like to parameterize the AWS region or instance type. This would let you deploy several instances of the same configuration with differing parameters. What if you want to parameterize the Fedora CoreOS configuration? Do so using the templatefile function.

As an example, try parameterizing the username of your user. To do this, add a username variable to the main.tf file:

variable "username" { type = string description = "Fedora CoreOS user" default = "core"

}

Next, modify the config.yaml file to turn it into a template. When rendered, the ${username} will be replaced.

variant: fcos

version: 1.2.0

passwd: users: - name: ${username} authorized_ssh_keys: - "ssh-ed25519 AAAAC3....... user@hostname"

Finally, modify the data block to render the template using the templatefile function.

data "ct_config" "config" { content = templatefile( "config.yaml", { username = var.username } ) strict = true

}

To deploy with username set to jane, run terraform apply -var=”username=jane”. To verify, try to SSH into the server with ssh jane@{public ip address}.

Leveraging the dependency graph

Passing variables from Terraform into Fedora CoreOS configuration is quite useful. But you can go one step further and pass infrastructure data into the server configuration. This is where Terraform and Fedora CoreOS start to really shine.

Terraform creates a dependency graph to model the state of infrastructure and to plan updates. If the output of one resource (e.g the public IP address of a server) is passed as the input of another service (e.g the destination in a firewall rule), Terraform understands that changes in the former require recreating or modifying the later. If you pass infrastructure data into a Fedora CoreOS configuration, it will participate in the dependency graph. Updates to the inputs will trigger creation of a new server with the new configuration.

Consider a system of one load balancer and three web servers as an example.

The goal is to configure the load balancer with the IP address of each web server so that it can forward traffic to them.

Web server configuration

First, create a file web.yaml and add a simple Nginx configuration with a templated message.

variant: fcos

version: 1.2.0

systemd: units: - name: nginx.service enabled: true contents: | [Unit] Description=Nginx Web Server After=network-online.target Wants=network-online.target [Service] ExecStartPre=-/bin/podman kill nginx ExecStartPre=-/bin/podman rm nginx ExecStartPre=/bin/podman pull nginx ExecStart=/bin/podman run --name nginx -p 80:80 -v /etc/nginx/index.html:/usr/share/nginx/html/index.html:z nginx [Install] WantedBy=multi-user.target

storage: directories: - path: /etc/nginx files: - path: /etc/nginx/index.html mode: 0444 contents: inline: | <html> <h1>Hello from Server ${count}</h1> </html>

In main.tf, you can create three web servers using this template with the following blocks:

data "ct_config" "web" { count = 3 content = templatefile( "web.yaml", { count = count.index } ) strict = true

} resource "aws_instance" "web" { count = 3 ami = "ami-0699a4456969d8650" instance_type = "t3.micro" user_data = data.ct_config.web[count.index].rendered

}

Notice the use of count = 3 and the count.index variable. You can use count to make many copies of a resource. Here, it creates three configurations and three web servers. The count.index variable is used to pass the first configuration to the first web server and so on.

Load balancer configuration

The load balancer will be a basic HAProxy load balancer that forwards to each server. Place the configuration in a file named lb.yaml:

variant: fcos

version: 1.2.0

systemd: units: - name: haproxy.service enabled: true contents: | [Unit] Description=Haproxy Load Balancer After=network-online.target Wants=network-online.target [Service] ExecStartPre=-/bin/podman kill haproxy ExecStartPre=-/bin/podman rm haproxy ExecStartPre=/bin/podman pull haproxy ExecStart=/bin/podman run --name haproxy -p 80:8080 -v /etc/haproxy/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro haproxy [Install] WantedBy=multi-user.target

storage: directories: - path: /etc/haproxy files: - path: /etc/haproxy/haproxy.cfg mode: 0444 contents: inline: | global log stdout format raw local0 defaults mode tcp log global option tcplog frontend http bind *:8080 default_backend http backend http balance roundrobin

%{ for name, addr in servers ~} server ${name} ${addr}:80 check

%{ endfor ~}

The template expects a map with server names as keys and IP addresses as values. You can create that using the zipmap function. Use the ID of the web servers as keys and the public IP addresses as values.

data "ct_config" "lb" { content = templatefile( "lb.yaml", { servers = zipmap( aws_instance.web.*.id, aws_instance.web.*.public_ip ) } ) strict = true

} resource "aws_instance" "lb" { ami = "ami-0699a4456969d8650" instance_type = "t3.micro user_data = data.ct_config.lb.rendered

}

Finally, add an output block to display the IP address of the load balancer.

output "load_balancer_ip" { value = aws_instance.lb.public_ip

}

All right! Run terraform apply and the IP address of the load balancer displays on completion. You should be able to make requests to the load balancer and get responses from each web server.

$ export LB={{load balancer IP here}}

$ curl $LB

<html> <h1>Hello from Server 0</h1>

</html>

$ curl $LB

<html> <h1>Hello from Server 1</h1>

</html>

$ curl $LB

<html> <h1>Hello from Server 2</h1>

</html>

Now you can modify the configuration of the web servers or load balancer. Any changes can be realized by running terraform apply once again. Note in particular that any change to the web server IP addresses will cause Terraform to recreate the load balancer (changing the count from 3 to 4 is a simple test). Hopefully this emphasizes that the load balancer configuration is indeed a part of the Terraform dependency graph.

Clean up

You can destroy all the infrastructure using the terraform destroy command. Simply navigate to the folder where you created main.tf and run terraform destroy.

Where next?

Code for this tutorial can be found at this GitHub repository. Feel free to play with examples and contribute more if you find something you’d love to share with the world. To learn more about all the amazing things Fedora CoreOS can do, dive into the docs or come chat with the community. To learn more about Terraform, you can rummage through the docs, checkout #terraform on freenode, or contribute on GitHub.

Developer Moss has revealed that it is bringing its 2007 shooter Raiden IV to Switch next year.

Raiden IV x Mikado Remix will arrive on April 22nd, 2021 in Japan, and will showcase new background music from various artists. These include “stages and boss tracks” which are “reborn through live performances and new arrangements.”

The artists involved include the likes of Go Sato Band, Heavy Metal Raiden, Fantom Iris, O.T.K., Soshi Hosoi, Daisuke Matsumoto (Cave), Hirokazu Koshio and Keishi Yonao. You’ll be able to switch to the original music, if you so wish.

A limited-edition version is being released in Japan which will include a soundtrack CD and a reprint of the original soundtrack CD. This will retail for 7,480 yen. The standard release will be 4,180 yen.

Here’s some PR:

New Elements for Switch – With the ability to switch between the “Mikado Remix” background music set and the “Original” background music set, as well as the “Sound Mode” and “Stage Background Music Select” functions, you can enjoy the new sounds of Raiden to your heart’s content. Additionally, the game supports vertical screen play in both table and TV modes, recreating the full arcade experience.

A Full Suite of Game Modes – “Arcade Mode,” which is a complete port of the arcade game, as well as “Additional Mode” and “Overkill Mode,” which include the stages added for console, have been perfectly reproduced. Various other game modes are also available, including “Boss Rush Mode,” a series of battles against boss weapons, and “Score Attack Mode,” where you compete for the high score on a single stage.

Online Functionality – Compete against other players on the worldwide leaderboards in “World Ranking Mode.” You can also upload your gameplay online via “Replay Publish,” allowing you to show your recorded gameplay to the world and study the gameplay of your rivals. Use the online functionality to discover a strategy all your own.

Raiden IV was first released in arcades back in June 2007, and was ported to the Xbox 360 in October the following year. A PlayStation 3 release – entitled Raiden IV: OverKill – came in May 2014. You can view the trailer for that release below.

Just in case you hadn’t yet explored the wonderous environments of Pokémon Sword and Shield‘s Galar region, Nintendo’s here with a brand new trailer which explores everything it has to offer.

Centring around the Isle of Armor and the Crown Tundra – the two areas added to the game via the DLC Expansion Pass – the video focuses on the natural landscape of these contrasting regions and the Pokémon available to see there. Oddly enough, someone’s been tasked with doing their best David Attenborough impression, which we suppose is the go-to style for any video like this.

Watch, as we examine the many wonderous Pokémon that comprise the rich tapestry of the Galar region. From a diminutive cub whose stubby arms protect it from rivals, to legendary creatures nested deep within the Crown Tundra, truly, the depths of this world are a sight to behold.

Have you checked out Pokémon Sword and Shield’s DLC yet? Did you think the two new areas added much to the overall experience? Let us know in the comments, and feel free to read our Isle of Armor and Crown Tundra reviews if you’re yet to try them out.