Use a new subdomain ipv4.cosinegaming.com, which contains the same IP
but only IPv4, so that godot will not try to use IPv6, which it cannot
do (it fails Error #2).

See https://github.com/godotengine/godot/issues/18275 for details on
that godot bug.

If a player looks at you or a wall you built, you gain charge, and steal
it from them!

Then, building walls now costs 15 charge.

Infinite loop in start_game caused by set_info setting the wrong peer's
info. Making the RPC more explicit about who we're setting resolves
this.

One problem remains: start_game behaves the same whether a game has
started or not.

Can't test because I haven't added the "start game" button back yet.

But not all bugs. Only errors. We're taking this a step at a time.

lobby.gd had gotten big, bloated, ugly, and hard to read. It needed a
refactor. The first thing I did is split up the *GUI* into the logical
steps it should be. So the new flow is:

 - Start the game
 - Click "Quick Play"
 - Matchmaking begins on my dedicated server

 - Start the game
 - Click "Custom Game"
 - *Only now* am I presented with server / client options

 - Start the game
 - Click "Singleplayer"
 - Singleplayer

NOW, and only now, and NO MATTER WHAT PATH I TAKE, I am taken to the
*lobby*, which now is where I:
 - Choose my name
 - Choose hero
 - See list of players
 - Get my team assigned
 - Anything else that I might like to put in
The point here is that this has *nothing* to do with handshaking /
matchmaking / etc! This is just part of the game! At this point I have
*already been connected* to the server. I've already been aquainted with
my other players. The game has begun.

I put the things that don't belong in any of these flows in
networking.gd, a sort of model-view sorta thing. All of these flows use
some sort of networking thing like `init_server` that tbh should be
*completely* abstracted from the UI.

It's totally a WIP!!! Above is the IDEA, but below is what I've actually
*done*:
 - Made the scenes, made a passable UI for each one that at least
 indicates ~what they'll do
 - Made the corresponding scripts, and split up the lobby script into
 ABOUT where I think it'll end up, but no promises
It still errors all over the place, and it's nowhere near properly
organized. PLUS, I'd also like to rewrite a lot of the code / rename
things as part of the initial refactor goal of making me able to
actually think about networking.

The problem I just encountered is that I have to tell the players who
are currently skirmishing that they have a game. This means either:
 1. Telling the skirmish server to move them
 2. Keeping a connection with players
 3. Running the skirmish server on the matchmaker!
Three sounds nice because the matchmaker is sitting on this godot
instance, it might as well do something with it, right? But it's
essentially equivalent to 1, it just doesn't have to think about
networking because they're the same instance. So moving from 3 to 1 if I
realize it's a bad idea is easy, but 2 becomes pretty entrenched.

You're making some pretty big decisions here, take it slow.

i.e., it still doesn't actually do any matchmaking. But it runs the
actual server without errors.

Nice! I love this balance tweak! And it can be changed depending on how
strong we want it to be.