Open jdrueckert opened 2 years ago
I just noticed that it might be related to https://github.com/MovingBlocks/Terasology/pull/4768. I checked out develop before that PR (and did no other changes in my workspace) and saw that the placement is correct there:
Not entirely sure how exactly the changes in that PR can lead to this bug, maybe @skaldarnar or @pollend have an idea?
I'm not sure this is a consistent issue...
One of the wells has in-game position (-173, 10, -712), while the other is at (-166, 11, -708). Could it be possible that we have some rounding issues with odd numbers, as one of the name tags is perfectly centered, while the other has an offset just along one axis?
The screenshot was taken with these changes active locally (but the change does not seem to make a difference...)
diff --git a/engine/src/main/java/org/terasology/engine/rendering/logic/FloatingTextRenderer.java b/engine/src/main/java/org/terasology/engine/rendering/logic/FloatingTextRenderer.java
index 965e924b9..a35c0440e 100644
--- a/engine/src/main/java/org/terasology/engine/rendering/logic/FloatingTextRenderer.java
+++ b/engine/src/main/java/org/terasology/engine/rendering/logic/FloatingTextRenderer.java
@@ -122,7 +122,7 @@ private void render(Iterable<EntityRef> floatingTextEntities) {
.m01(0.0f).m11(1.0f).m21(0.0f)
.m02(0.0f).m12(0.0f).m22(1.0f);
modelView.scale(scale, -scale, scale);
- modelView.translate(-textWidth / 2.0f, 0.0f, 0.0f);
+ modelView.translate(-textWidth / 2.0f, 0.0f, -textWidth / 2.0f);
for (Map.Entry<Material, Mesh> meshMapEntry : meshMap.entrySet()) {
Mesh mesh = meshMapEntry.getValue();
Wells are one of the buildings generated in a city in Metal Renegades. They have a tag indicating how much water is still left in them. Some recent change in our code base seems to have had some negative impact on that tag in the sense that it's no longer placed in the center of the well right above the water but diagonally from that next to / in one of the well roof posts:
I don't think that just changing the placement logic of the tag is a reasonable fix here, as the placement changed without the code being changed, so we'd be fixing symptoms only. Ideally, we should find out, why the placement is wrong now without the code being changed aka which other part of our code base (likely something in engine) was changed to this effect and fix that.