TrueCraft VS sdk

There was TrueCraft that attempts to reimplement Beta 1.7.3 but it has been abandoned for a few years now.

You might find this project interesting: TrueCraft (The physics are really janky in my experience unfortunately.)

Calling the ability of third party launchers to launch Minecraft a feature of Minecraft seems odd. I imagine you could make a launcher for pretty much any game for Windows (or many Linux-based operating systems)). I don't think that makes game launchers illegal in general though, but it does mean that launchers are not necessarily legal in all cases (i.e. if the launcher does something illegal, like circumvent DRM). I don't know how to tell if a launcher is circumventing DRM by for example lying to the Minecraft client to trick it into allowing play, other than by examining the source code of the launcher and/or Minecraft and I don't have time to do that (plus I'd like to be able to freely contribute to projects like TrueCraft).

You might be interested in TrueCraft, or other third-party clients/servers, or perhaps MineClone (not a re-implementation, but just a similar game). All of these are incomplete I think, for now.

That said, if you want to go back to when Minecraft was simple, you might be interested in TrueCraft (It's not very playable IMO, but it is interesting.).

Well, I guess I am sort of repeating things I don't fully understand. I've never actually read the source code of Minecraft, because I want to be allowed to contribute to re-implementations like TrueCraft, for example (even though currently, I don't really have the skills to do that).

There was TrueCraft which was a clean room implement of Minecraft beta 1.7.3 in C#.

Your comment intrigued me so I did a little bit of digging.

> I remember Drew DeVault (sircmpwn) used to have a big scary warning saying if I have looked at the official minecraft code, I should not contribute to truecraft (now archived I believe).

The repository is indeed archived, but is still available on GitHub. It was changed in 2015 [0]. The older notice is as you recall:

> Pull requests will be rejected from authors who have read any decompiled official Minecraft code.

The current notice [1] adds some other ways the formerly rejected developers could get involved:

> If you are a developer, you have two paths. If you have not read the Minecraft source code, you are what we call a "clean dev", and you should stay that way. If you have read the source code, you are what we call a "dirty dev", and the way you can contribute is different. If you are a clean dev, you're welcome to contribute to this repository by adding features and functionality from Minecraft Beta 1.7.3, fixing bugs, refactoring, etc - the usual. Send pull requests with your work.

> If you are a dirty dev, you are more limited in how you can help. You can work on projects that are related to TrueCraft, but not on TrueCraft itself. Direct contributions that you can participate in includes the website and the artwork. You can also work on things like helping to build a community by spreading the word, participating in IRC or the subreddit, etc. You may also work on reverse engineering Minecraft to provide documentation for clean devs to use - see reverse engineering guidelines on the wiki for details on how you can do this. Under no circumstances may you ever share any code with a clean dev, decompiled or otherwise.

[0] https://github.com/ddevault/TrueCraft#get-involved

[1] https://github.com/ddevault/TrueCraft/commit/fcfd3886746fd1f...

[DllImport("libc")] private static extern uint geteuid(); public bool IsCurrentProcessElevated() { if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows)) { // https://github.com/dotnet/sdk/blob/v6.0.100/src/Cli/dotnet/Installer/Windows/WindowsUtils.cs#L38 using var identity = WindowsIdentity.GetCurrent(); var principal = new WindowsPrincipal(identity); return principal.IsInRole(WindowsBuiltInRole.Administrator); } // https://github.com/dotnet/maintenance-packages/blob/62823150914410d43a3fd9de246d882f2a21d5ef/src/Common/tests/TestUtilities/System/PlatformDetection.Unix.cs#L58 // 0 is the ID of the root user return geteuid() == 0; }

> There's definitely things they tried to improve on that... weren't really improvements. The way "assemblies" are matched in .NET is much more sophisticated- the goal there was to try to kill DLL hell. It evolved into the Global Assembly Cache, which is sort of the Windows Registry of DLLs. Not a huge fan of those bits.

The Global Assembly Cache did not make the jump to the modern .NET (Core). There was the thing called `dotnet store`, but it’s broken since .NET 6: https://github.com/dotnet/sdk/issues/24752

The assembly redirection hell has also been greatly reduced there.

I do the same.

I have a small write-up here: https://chrlschn.dev/blog/2023/10/end-to-end-type-safety-wit...

You get end-to-end type safety (even better once you connect it to EF Core since you get it all ways to your DB).

With this setup with hot-reload (currently broken in .NET 8 [0]), productivity is really, really good. Like tRPC but with one of the most powerful ORMs out there right now.

[0] https://github.com/dotnet/sdk/issues/36918

Noticed an open issue just now.

You're thinking of https://github.com/dotnet/sdk/issues/22247

That's a twisted and wrong narrative

Unity like refers to a Editor driven approach

Unity became popular with its moonscript language (javascript like), they then ditched it to focus on C#, but what propelled unity to what it is today is the Editor driven approach, not c#, not DOTS

They are forced to transpile C# to C++ via IL2CPP as a result to target consoles/mobiles

C# is a disease when it comes to console/mobile support

It's a substantial dependency, quite heavy

And you are not free of unity like fuck ups, it's a microsoft language after all:

https://github.com/dotnet/sdk/issues/22247

And let's not forget when they changed the license of their debugger overnight to prevent people from using it in their products (jetbrains for example)

And them deprecating open source tooling to a proprietary/closed one for vscode (c# devkit)

Let's be careful when we recommend evil as an alternative to evil ;)

The script can be found at the end of the thread here https://github.com/dotnet/sdk/issues/8742

Another difference you might be surprised by is that the .NET tooling by default collects various data from your system and sends it to Microsoft [1]. If you want to avoid this (and still want to use .NET) you'll have to make sure that the environment variable DOTNET_CLI_TELEMETRY_OPTOUT is set in all contexts before touching anything.

[1] https://github.com/dotnet/sdk/issues/6145

SDK Pull Request

Pretty sure the final file referenced here https://github.com/dotnet/sdk/issues/8742 is the one I am thinking of.