Svarr

@MADLAD3718 That shimmering doesn't seem to be caused by DLSS. It seems to be dependent on the contrast to the background and it therefore applies to anything, including held items (e.g. tools). Your video actually shows that it is still happening with Upscaling turned off (see after 0:39, when the Warden starts moving again).

For some reason the rendered pixels of the current frame seem to influence the colour of the pixels at the same position in the next frame, causing some kind of smearing effect if the contrast is high enough. Though I've noticed this issue from the very beginning when I started playing (version 1.18), as I've spent a lot of time in caves where e.g. enchanted tools are set apart from the dark background clearly.

Svarr on MCPE-130070 2022-08-16T07:00:17Z

Since @Netheritedrifter doesn't seem to be active anymore, I'd be willing to take ownership of this ticket.

Svarr on MCPE-35307 2022-07-31T08:07:56Z

This seems to be fixed for me since 1.19.10 at least. I get 0-4 Ender Pearls per Enderman with Looting III. I haven't tested the other Looting levels, though.

Reply from @unknown:

This report is not about the possibility of getting 3 extra drops with looting 3. It's about the average. A min 0, max 1 + looting level loot table gives an average of 2 drops/mob with looting 3 in Java Edition and 1.25 drops/mob in Bedrock Edition.

Svarr on MCPE-130070 2022-07-31T07:56:54Z

Affects Version 1.19.20 and earlier.

@Netheritedrifter Could you please add the versions 1.18.10 - 1.19.20 to the affected versions and change the platform to 'multiple'?

Svarr on MCPE-136109 2022-06-16T20:28:12Z

Affects 1.19.0

@Daniel Ross Could you please add the versions to the Affects Version/s field of this ticket?

Svarr on MCPE-18677 2022-06-16T19:13:38Z

Affects 1.19.0 and 1.19.2

Svarr on MCPE-35307 2022-05-26T07:49:16Z

Affects 1.18.31

@GoldenHelmet's suggested solution could lead to issues very quickly, depending on the implementation of math.random(). E.g. the outer function could be called with the second parameter being smaller than the first.

Assuming the mentioned line is how it still works, the following should solve the issue:

math.random(min_drops_no_looting, max_drops_no_looting) * math.random(1, looting_level + 1)

Since we multiply the result of the normal (no looting) drop amount, we have to use a factor of at least 1. Otherwise we drastically increase the chance of the end result being 0, which is what we experience in the game.

Though, I doubt that this is the actual code that is used, since it should always result in 0 if there is no looting enchantment applied (looting_level == 0), which is not what happens in the game. Unless, of course, there is a redundancy in form of a branch for the computation with and without the enchantment.

Edit: I realised that the problem I pointed out with @GoldenHelmet's proposed solution is fixed by making the same change I suggested and wrote a quick kotlin program to check if there actually is a difference between the two lines. At 100 runs with the following parameters

looting_level = 3
min_drops_no_looting = 0
max_drops_no_looting = 1

I get the following result:

Method 1: 58 times no drops, 0.86 arithmetic average drop amount
Method 2: 54 times no drops, 0.99 arithmetic average drop amount
Method 1 (fix): 41 times no drops, 1.47 arithmetic average drop amount
Method 2 (fix): 22 times no drops, 2.11 arithmetic average drop amount

For comparison with looting level 0:

Method 1: 100 times no drops, 0.0 arithmetic average drop amount
Method 2: 100 times no drops, 0.0 arithmetic average drop amount
Method 1 (fix): 46 times no drops, 0.54 arithmetic average drop amount
Method 2 (fix): 51 times no drops, 0.49 arithmetic average drop amount

Method 1 being the presumed original code line and Method 2 the fix suggested suggested by @GoldenHelmet. The "... (fix)" lines are the corresponding ones with the change I proposed above.

~~So there seems to be a difference between both methods but that could very well just be the randomness. I'll check with a different approach next.~~

Edit #2: I looked at the extreme values each random function can return with both methods:

#1: random(minDrops, maxDrops) * random(0, lootingLevel)
#1.1: minDrops * 0
#1.2: minDrops * lootingLevel
#1.3: maxDrops * 0
#1.4: maxDrops * lootingLevel

#2: random(minDrops, maxDrops * random(0, lootingLevel))
#2.1: minDrops
#2.2: minDrops
#2.3: maxDrops * 0
#2.4: maxDrops * lootingLevel

The results for minDrops..maxDrops, lootingLevel are:

0..1, 3

#1.1: 0
#1.2: 0
#1.3: 0
#1.4: 3
#2.1: 0
#2.2: 0
#2.3: 0
#2.4: 3

0..1, 0

#1.1: 0
#1.2: 0
#1.3: 0
#1.4: 0
#2.1: 0
#2.2: 0
#2.3: 0
#2.4: 0

1..3, 3

#1.1: 0
#1.2: 3
#1.3: 0
#1.4: 9
#2.1: 1
#2.2: 1
#2.3: 0
#2.4: 9

1..3, 0

#1.1: 0
#1.2: 0
#1.3: 0
#1.4: 0
#2.1: 1
#2.2: 1
#2.3: 0
#2.4: 0

As it turns out, they behave the same, as long as minDrops is 0.

Regarding Endermen, we'd theoretically only be able to get drops with Looting III as I mentioned above. Since we do get drops without the enchantment and way less with it, I don't think that either of the two methods match the actual code in use.

Still, the version that matches the intended behaviour would be:

random(minDrops, maxDrops) * random(1, lootingLevel + 1)

or simply:

random(minDrops, maxDrops + lootingLevel)

Both would result in the correct range of possible drop amounts for Endermen (i.e. 0..4), but I'd assume that they differ in distribution (i.e. which number gets (statistically) returned how often).

Svarr on MCPE-18677 2022-05-26T05:52:37Z

This issue still persists or at least I noticed it first in version 1.18.30 on the Win10 platform and it's still happening in version 1.18.31.

I light up the area around the spawner with four flowing lava columns, much like the screenshots. Similar to Travis Painter's comment, I noticed the Blazes spawn somewhere inside the flowing lava. Maybe the light levels inside the blocks are not set properly (assuming that Blazes spawning in lava is intentional)?

I have that issue happen in all my worlds where applicable (i.e. where I have set up a spawner trap), which is:

a flat world with a spawner placed in creative mode
a world ("Winding Rivers" seed) with a naturally generated spawner.

Both exhibit the exact same behaviour.

Edit: I uploaded two videos I recorded earlier. Both showing Blazes being spawned inside lava columns.

Svarr

Assigned

Reported

Comments

Reply from @unknown: