Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

breaking things #11

Merged

Conversation

machinesmith42
Copy link
Owner

No description provided.

jellysquid3 and others added 13 commits March 20, 2021 18:13
The mod's version string now includes extra information about the sources used
to build the mod. If available, it will include the checked out revision in Git
and whether or not the source tree was dirty. If no information about the build
can be determined, the identifier "unknown" will be used.

This is being done because too many players, against our recommendation, are
downloading CI artifacts or compiling the mod themselves for daily use, and
are unable to provide any information about where the build came from when they
inevitably ask for technical support. Not having this information available to us
makes it impossible to diagnose issues over time and creates significant burden.

In the future, this information will be presented in the F3 screen.
The vast majority of support tickets come from players compiling
the mod JDK 9+ and trying to run it on the runtime the Minecraft
launcher provides (typically JRE 8).
This is a better solution than failing when JDK 9+ is used, and
means that people do not have to swap around their JAVA_HOME.

For users of SDKMAN and other similar package managers, Gradle
can automatically pick up local toolchain installations and
re-use them.
Gradle will still download an AOJ build if none suitable are available.
…610)

In `pushChunkDrawParams` the need to grow the buffer is determined by comparing the write offset to the `capacity`
field. But after the buffer had been grown, the `capacity` field had been left unchanged, thereby triggering another
grow on each call to `pushChunkDrawParams`, quickly running out of memory.
This mirrors vanilla behavior (see `PalettedContainer.get(index)`).

Fixes #565
The `writeEnd` variable used to be set relative to the write pointer, not relative start of the buffer.
This resulted in a `writeEnd` value which was far too large, allowing the buffer to overflow beyond its allocated space
and into random memory, corrupting everything in its way with all the unpredictable doom one would expect from that.
@machinesmith42 machinesmith42 merged commit 9c8ee10 into machinesmith42:compat_next_1_16_4 Apr 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants