Svarr
- Svarr
- JIRAUSER721098
- Europe/Stockholm
- Yes
- No
MCPE-18677Added Attachments:
Deleted Comment:
Still an issue as of version 1.19.0
(Also, the article, the link "Issue Guidelines" refers to, doesn't exist anymore.)
Deleted Comment:
Affects versions 1.19.21 and 1.19.22
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:
Both exhibit the exact same behaviour.
Edit: I uploaded two videos I recorded earlier. Both showing Blazes being spawned inside lava columns.
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:
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
I get the following result:
For comparison with looting level 0:
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:
The results for minDrops..maxDrops, lootingLevel are:
#1.1: 0
#1.2: 0
#1.3: 0
#1.4: 3
#2.1: 0
#2.2: 0
#2.3: 0
#2.4: 3
#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.1: 0
#1.2: 3
#1.3: 0
#1.4: 9
#2.1: 1
#2.2: 1
#2.3: 0
#2.4: 9
#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:
or simply:
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).
Affects 1.19.0 and 1.19.2
Affects 1.19.0
@Daniel Ross Could you please add the versions to the Affects Version/s field of this ticket?
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'?
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 [Mod] GoldenHelmet:
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.
Since @Netheritedrifter doesn't seem to be active anymore, I'd be willing to take ownership of this ticket.
@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.
Affects 1.19.21
@GoldenHelmet, please refer to the following excerpt of the additional information provided by @Auldrick:
Which is describing exactly what I'm not experiencing anymore.
Affects version 1.19.22
@v-magwar Yes, it is still an issue as of version 1.19.51.
This issue is duplicated by MCPE-157150.
It's still an issue as of version 1.19.51, but it's supposedly fixed in version 1.19.60.24.
Affects 1.19.51
This could be the same issue that is reported in MCPE-136109.