Merge remote-tracking branch 'origin/20.1/forge' into 19.2/forge

.github/workflows/dco.yml

@@ -0,0 +1,38 @@
+name: "DCO Assistant"
+on:
+  issue_comment:
+    types: [created]
+  pull_request_target:
+    types: [opened, closed, synchronize]
+
+permissions:
+  actions: write
+  contents: write
+  pull-requests: write
+  statuses: write
+
+jobs:
+  DCO:
+    runs-on: ubuntu-latest
+    steps:
+      - name: "DCO Assistant"
+        if: (
+              github.event.comment.body == 'recheck' || 
+              github.event.comment.body == 'I have read, and hereby affirm the entire contents of the Developer Certificate of Origin.'
+            ) || github.event_name == 'pull_request_target'
+        uses: cla-assistant/[email protected]
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          path-to-signatures: "signatures.json"
+          path-to-document: "https://github.com/embeddedt/embeddium/blob/dco/DCO.txt"
+          branch: "dco"
+          create-file-commit-message: "Create DCO signature list"
+          signed-commit-message: "Add $contributorName to the DCO signature list"
+          custom-notsigned-prcomment:
+            "Before we can merge your submission, we require that you read and affirm the contents of the 
+            [Developer Certificate of Origin](https://github.com/embeddedt/embeddium/blob/dco/DCO.txt) by adding a comment containing the below text. 
+            Otherwise, please close this PR."
+          custom-pr-sign-comment: "I have read, and hereby affirm the entire contents of the Developer Certificate of Origin."
+          custom-allsigned-prcomment: "All contributors have read and affirmed the entire contents of the Developer Certificate of Origin."
+          use-dco-flag: true

CONTRIBUTING.md

@@ -0,0 +1,60 @@
+## Contribution Guidelines
+
+### Developer Certificate of Origin
+
+We require contributors to Embeddium to acknowledge they have followed the terms of the [Developer Certificate of Origin](https://github.com/embeddedt/embeddium/blob/dco/DCO.txt) when making contributions. This is a simple mechanism for us to ensure all contributions are appropriately licensed and attributed.
+
+When you open a PR, our CI will automatically check if you have previously affirmed the DCO, and if you have not, give you a prompt to read & acknowledge it.
+
+### Code Style
+
+When contributing source code to the project, ensure that you make consistent use of our code style guidelines. These
+guidelines are based on the [Google code style guidelines for Java](https://google.github.io/styleguide/javaguide.html),
+with some minor changes, as described below.
+
+- Use 4 spaces for indentation, not tabs. Avoid lines which exceed 120 characters.
+- Avoid deeply nested conditional logic, and prefer breaking out to separate functions when possible.
+    - If you are using more than three levels of indentation, you should likely consider restructuring your code.
+    - Branches which are only exceptionally or very rarely taken should remain concise. When this is not possible,
+      prefer breaking out to a new method (where it makes sense) as this helps the compiler better optimize the code.
+- Use `this` to qualify member and field access, as it avoids some ambiguity in certain contexts.
+
+We also provide these code styles as [EditorConfig](https://editorconfig.org/) files, which most Java IDEs will
+automatically detect and make use of.
+
+#### Unsafe code
+
+There are some additional guidelines for using unsafe code in Java, which are aimed at improving code readability and
+debugging. Most developers will not need to read this section unless they are working with bindings to native libraries.
+
+- The use of unsafe operations in general should be avoided unless strictly necessary, or where there is otherwise a
+  clear performance advantage.
+    - Unsafe code is often _slower_ than safe code, since the Hotspot compiler only contains basic intrinsics and is
+      very pessimistic about optimizing such code.
+    - Array bounds checks are almost never the bottleneck of your code. But memory layout often is, and unsafe code
+      gives you explicit control over it.
+- The invariants of public methods which expose unsafe operations MUST be documented.
+    - An example of a safety invariant would be if passing a null pointer value or invalid array index to a method which
+      uses unsafe operations would cause an invalid memory access.
+    - The caller of your method should know exactly what is needed to avoid undefined or invalid behavior. 
+- The invariants of unsafe methods SHOULD be checked where possible. The use of runtime checking SHOULD be configurable
+  at application launch.
+    - The typical way to implement these checks is to keep a `private static final boolean CHECKS = /* ... */;` field in
+      the class which controls the use of runtime checking.
+    - These checks can then be wrapped within an if-statement which allows them to be skipped if runtime error checking
+      is disabled. This also allows the compiler to easily optimize them away.
+- When plain integer types are used to store pointers to memory addresses, their variables MUST be prefixed, and a 
+  comment MUST be added to indicate their underlying type.
+    - For example, the declaration `int* value;` in C code would be represented as `long pValue; // int*` in Java code.
+    - For chains of pointers, multiple prefixes should be used. For example, `char** strings;` in C code would become
+      `long ppStrings; // char**` in Java code.
+
+### Pull Requests
+
+Your pull request should include a brief description of the changes it makes and link to any open issues which it
+resolves. You should also ensure that your code is well documented where it is non-trivial, and that it follows our code
+style guidelines.
+
+If you're adding new Mixin patches to the project, please ensure that you have created appropriate entries to disable
+them in the config file. Mixins should always be self-contained and grouped into "patch sets" which are easy to isolate,
+and where that is not possible, they should be placed into the "core" package.

build.gradle

@@ -171,9 +171,7 @@ java {
 }
 
 tasks.named('jar', Jar).configure {
-	from("LICENSE") {
-		rename { "${it}_${project.archivesBaseName}"}
-	}
+	from("COPYING", "COPYING.LESSER")
 	from sourceSets.compat.output.classesDirs
 	from sourceSets.compat.output.resourcesDir
 

src/main/java/me/jellysquid/mods/sodium/client/render/pipeline/FluidRenderer.java

@@ -29,6 +29,7 @@
 import net.minecraft.tags.FluidTags;
 import net.minecraft.util.Mth;
 import net.minecraft.world.level.BlockAndTintGetter;
+import net.minecraft.world.level.block.Block;
 import net.minecraft.world.level.block.SupportType;
 import net.minecraft.world.level.block.state.BlockState;
 import net.minecraft.world.level.material.Fluid;
@@ -72,15 +73,32 @@ public FluidRenderer(LightPipelineProvider lighters, ColorBlender colorBlender)
     }
 
     private boolean isFluidOccluded(BlockAndTintGetter world, int x, int y, int z, Direction dir, Fluid fluid) {
+        // Check if the fluid adjacent to us in the given direction is the same
+        if (world.getFluidState(this.scratchPos.set(x + dir.getStepX(), y + dir.getStepY(), z + dir.getStepZ())).getType().isSame(fluid)) {
+            return true;
+        }
+
+        // Stricter than vanilla: check whether the containing block can occlude, has a sturdy face on the given side,
+        // and has a solid occlusion shape. If so, assume the fluid inside is not visible on that side.
+        // This avoids rendering the top face of water inside an upper waterlogged slab, for instance.
         BlockPos pos = this.scratchPos.set(x, y, z);
         BlockState blockState = world.getBlockState(pos);
-        BlockPos adjPos = this.scratchPos.set(x + dir.getStepX(), y + dir.getStepY(), z + dir.getStepZ());
 
-        if (blockState.canOcclude()) {
-            return world.getFluidState(adjPos).getType().isSame(fluid) || blockState.isFaceSturdy(world,pos,dir, SupportType.FULL);
-            // fluidlogged or next to water, occlude sides that are solid or the same liquid
-            }
-        return world.getFluidState(adjPos).getType().isSame(fluid);
+        if (!blockState.canOcclude() || !blockState.isFaceSturdy(world, pos, dir, SupportType.FULL)) {
+            return false;
+        }
+
+        VoxelShape sideShape = blockState.getFaceOcclusionShape(world, pos, dir);
+        if (sideShape == Shapes.block()) {
+            // The face fills the 1x1 area, so the fluid is occluded
+            return true;
+        } else if (sideShape == Shapes.empty()) {
+            // The face does not exist, so the fluid is not occluded
+            return false;
+        } else {
+            // Check if the face fills the 1x1 area
+            return Block.isShapeFullBlock(sideShape);
+        }
     }
 
     private boolean isSideExposed(BlockAndTintGetter world, int x, int y, int z, Direction dir, float height) {