The bad tutorial at least has some narrative justification. It's just a filter for people who are already useful as shock troops with minimal training.

Not only does the bad tutorial have an in-universe justification; the ways in which it is bad are actually significant to the worldbuilding in multiple ways.

The missing information also encourages positive interactions among the community - newer players are expected to be missing lots of key information, so teaching them is a natural and encouraged element of gameplay.

I stopped playing the game awhile ago, but the tutorial always struck me as really clever.

I also think that the tutorial would be tedious if it went through too much of the mechanics. They show you the basics, the rest you pick up through trial and error.

aye. give me the 3 minute tutorial, not the 37 minute tutorial.

i want to play the game, like now, and i'll read the forums after i figure out that i'm missing something imporant

The tutorial is just fine - here's a gun, here's how you shoot it, here's how you call reinforcements, now go kill some bugs!

The only wrong thing I've been throwing is the SOS Beacon instead of a Reinforce, which is just annoying, and not just once. It makes the game public if it was friends-only and gives it priority in the quick play queue. So that can't be it.

The dialing adds friction to tense situations, which is okay as a mechanic.

Just accidentally smashed some teammates with an eagle napalm instead of eagle smoke before I saw this.

Almost certainly this occurred on a Rapid Acquisition Mission on K.

The game logic is also weird. It seems like they started with at attempt at a realistic combat simulator which then had lots of unrealistic mechanics added on top in an attempt to wrangle it into an enjoyable game.

As an example for overly realistic physics, projectile damage is affected by projectile velocity, which is affected by weapon velocity. IIRC, at some point whether you were able to destroy some target in two shots of a Quasar Cannon or three shots depended on if you were walking backwards while you were firing, or not.

> depended on if you were walking backwards while you were firing

That sounds like a bug, not an intentional game design choice about the game logic, and definitely unrelated to realism vs not realism. Having either of those as goals would lead to "yeah, bullet velocity goes up when you go backwards" being an intentional mechanic.

To be clear, walking backwards (away from the target) reduced your bullet velocity relative to the target, reducing the damage you were doing and leading to you needing more shots.

And to be extra clear, either way, neither options makes me believe it was an intentional design choice.

Systems-driven gameplay is an intentional design choice all unto itself

Sure, but that doesn't mean every consequence of that choice is suddenly intentional as well.

It may not be intentional, but it sounds like it's a fun, emergent gameplay mechanic. How much fun have people had with physics and silliness with Valve's Source engine, which was one of the earlier full physics games? Or going back further, "surf" maps in e.g. Unreal Tournament or CS that abused the movement physics to create a movement puzzle (which, arguably, led to some of the movement mechanics in Titanfall).

> but it sounds like it's a fun, emergent gameplay mechanic

That you do less damage if you do a certain movement sounds like fun, emergent gameplay? That's not how I understand either of those terms, but of course, every player likes different things.

Surf maps in CS is actually a good example of an engine bug leading to game designers intentionally use it to design new experience, with the keyword being "intentional" since those map makers actually use that bug intentionally. For me that feels very different from engine bugs that don't add any mechanic, and instead just makes the normal game harder.

Which codegen backend the building compiler uses is independent of which codegen backend(s) the built compiler uses.

Similarly, you can build Clang using itself or using GCC. The resulting compiler should behave the same and produce the same machine code, even if its own machine code is somewhat different.

The produced binaries could still have artifacts from the original compiler in them, e.g. if "compiler built-in" libraries or standard libraries were compiled with the original compiler.

Both GCC and rustc use a multi-stage build process where the new compiler builds itself again, so you reach an idempotent state where no artifacts from the original compiler are left.

The "about" does a lot of heavy lifting in this example. Dividing 10,000,000_10 by the number of grains that fit into one universe doesn't change it much. The 10,000,000 would get smaller somewhere in the deep depths of the decimal fraction.

Different access rules, I guess. Or maybe they wanted some separation from the existing org so the custom automation has no chance of doing collateral damage.

MSYS2 is basically Cygwin with Pacman for package management, plus several other environments with either GCC or Clang and different Windows-Native C and C++ runtimes.

It's nice, but not perfect. It inherits a lot of problems from Cygwin. File access is still slow (as mentioned in other threads) and symlinks don't behave right (by default making a symlink creates a deep copy of the target, and even NTFS symlinks need to know whether the target is a file or a directory; either way you cannot create a symlink when the target is missing, and this causes rsync to fail, for example.)

MSYS2's strength is as an environment for compiling cross-platform apps for Windows, and I would recommend WSL2 for anything else.

Agreed that it's good for building native Windows software and there are better options for other use cases. When recommending–praising MSYS2 I sometimes forget that the only time I use Windows is to build software for use by other folks who actively run Windows as their desktop/laptop OS.

Re: "Cygwin…plus several other environments[+]", the second paragraph of MSYS2's home page summarizes it pretty well:

   Despite some of these central parts [Bash and cli tools] being based on Cygwin, the main focus of MSYS2 is to provide a build environment for native Windows software and the Cygwin-using parts are kept at a minimum.

[+] https://www.msys2.org/docs/environments/

Pretty much. AFAIK you're waiting for Windows Defender and other hooks to run.

I think the implication was that they're pointers to objects that own resources (like containing FILE handles) and need to be "freed" with a custom function, not just "free".

    void my_thing_free(MyThing *thing) {
        fclose(thing->file);
        free(thing);
    }

assuming an associated "my_thing_new" that only returns a valid pointer when both the allocation and the fopen succeeded.

No, it also covers the data. As long as you don't delete the rollback subvolume, all the original data should still be there, uncorrupted.

Even if you disable copy-on-write, as long as the rollback subvolume is there to lay claim to the old data, it's considered immutable and any modification will still have to copy it.

I understood it as "it doesn't touch/ignore the data". But I guess we mean the same thing.

You are right. All of the old files will be in areas btrfs should consider used. So it should correctly restore the state from before the migration. Thanks!