resourcepack-d.go is seemingly a binary file and not a golang file?

[LunarN0v4]

Describe the bug A clear and concise description of what the bug is, and optionally what server it occurs on.
The file "resourcepack-d.go" in subcommands/resourcepack-d is a binary file and not a golang file, but according to build.py, it's needed for building with pack support.

To Reproduce Steps to reproduce the behavior: This is relevant to the Git repo, no steps are needed for reproduction.

Expected behavior A clear and concise description of what you expected to happen.
I expected golang code, but found a binary file.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• Irrelevant

Additional context Add any other context about the problem here. Irrelevant

attach packets.log.gpg (not always necessary) this file can be helpful for debugging without having to connect to the server. it can be created by running with -extra-debug [e.g. bedrocktool.exe -extra-debug worlds -address play.mojang.com ] be sure to only attach the .gpg file which is not publicly readable.

[limeaxolotl]

Also experiencing this issue, but by looking at it it looks as though it's actually encrypted, with gitcrypt. I assume it's encrypted because of it breaking minecraft's encryption, and so this prevents mojang from going after olebeck? Just a guess.

[LunarN0v4]

Also experiencing this issue, but by looking at it it looks as though it's actually encrypted, with gitcrypt. I assume it's encrypted because of it breaking minecraft's encryption, and so this prevents mojang from going after olebeck? Just a guess.

possibly, but im not sure why, resource packs are stored locally on the device anyways, so it shouldnt be a problem

[limeaxolotl]

When stored locally they're often encrypted, since servers do that to protect their assets.

[LunarN0v4]

When stored locally they're often encrypted, since servers do that to protect their assets.

fair point, fair point