Ryan Leach
- ryan_the_leach
- ryan_the_leach
- Australia/Adelaide
- Yes
- No
MC-54263
I suspect its intended. allowing you to peak out under the mask.
The BlockPattern class is incorrectly matching blocks that arn't being placed by the player.
Instead of using a block iterator of bounds involving the maximum dimension of the BlockPattern, the BlockPattern class should be iterating over the inverted offsets of the BlockPattern.
In the screenshots provided, if you replace the red wool block with a witherskull the wither will be detected and spawned, even though the pattern matched was not comprised of the block the player placed.
The BlockPattern class is incorrectly matching blocks that arn't being placed by the player.
In
stead of using a block iterator ofbounds involving the maximum dimension of the BlockPattern, the BlockPattern class should be iterating over the inverted offsetsof theBlockPattern.In
the screenshots provided, if you replace the red wool block with a witherskull the wither will be detected and spawned, even though the pattern matched was not comprisedof theblockthe player placed.Problem:
The BlockPattern class is incorrectly matching blocks that arn't including the block being placed by the player.
Proof:
In the screenshots provided, if you replace the red wool block with a witherskull the wither will be detected and spawned, even though the pattern matched was not comprised of the block the player placed.
Possible Fix:
Instead of using a block iterator iterating over all blocks in a cube (of size 3 for the wither as it is the max(width,height,depth) the BlockPattern class should be iterating over the inverted offsets of the BlockPattern. (e.g. translateOffset(position, forwards, up, -i, -j, -k))
(an optimization is to skip Predicates.alwaysTrue() wildcards as they are effectively "who cares what is placed here")
There is a second bug that I am having troubles replicating, but involves modded minecraft where as the above is reproducible in vanilla.
The second issue is involved with asymmetrical block patterns.
Problem:
The BlockPattern class is incorrectly matching blocks that arn't including the block being placed by the player.
Proof:
In the screenshots provided, if you replace the red wool block with a witherskull the wither will be detected and spawned, even though the pattern matched was not comprised of the block the player placed.
Possible Fix:
Instead of using a block iterator iterating over all blocks in a cube (of size 3 for the wither as it is the max(width,height,depth) the BlockPattern class should be iterating over the inverted offsets of the BlockPattern. (e.g. translateOffset(position, f
orwards, up, -i, -j, -k))(an optimization is to skip Predicates.alwaysTrue() wildcards as they are effectively "who cares what is placed here")
There is a second bug that I am having troubles replicating, but involves modded minecraft where as the above is reproducible in vanilla.
The second issue is involved with asymmetrical block patterns.
Problem:
The BlockPattern class is incorrectly matching blocks that arn't including the block being placed by the player.
Proof:
In the screenshots provided, if you replace the red wool block with a witherskull the wither will be detected and spawned, even though the pattern matched was not comprised of the block the player placed.
Possible Fix:
Instead of using a block iterator iterating over all blocks in a cube (of size 3 for the wither as it is the max(width,height,depth) the BlockPattern class should be iterating over the inverted offsets of the BlockPattern. (e.g. translateOffset(position, face1, face2, -i, -j, -k))
(an optimization is to skip Predicates.alwaysTrue() wildcards as they are effectively "who cares what is placed here")
There is a second bug that I am having troubles replicating, but involves modded minecraft where as the above is reproducible in vanilla.
The second issue is involved with asymmetrical block patterns.
Problem:
The BlockPattern class is incorrectly matching blocks that arn't including the block being placed by the player.
Proof:
In the screenshots provided, if you replace the red wool block with a witherskull the wither will be detected and spawned, even though the pattern matched was not comprised of the block the player placed.
Possible Fix:
Instead of using a block iterator iterating over all blocks in a cube (of size 3 for the wither as it is the max(width,height,depth) the BlockPattern class should be iterating over the inverted offsets of the BlockPattern. (e.g. translateOffset(position, face1, face2, -i, -j, -k))
(an optimization is to skip Predicates.alwaysTrue()
wildcards as they are effectively "who cares what is placed here")There is a second bug that I am having troubles replicating, but involves modded minecraft where as the above is reproducible in vanilla.
The second issue is involved with asymmetrical block patterns.
Problem:
The BlockPattern class is incorrectly matching blocks that arn't including the block being placed by the player.
Proof:
In the screenshots provided, if you replace the red wool block with a witherskull the wither will be detected and spawned, even though the pattern matched was not comprised of the block the player placed.
Possible Fix:
Instead of using a block iterator iterating over all blocks in a cube (of size 3 for the wither as it is the max(width,height,depth) the BlockPattern class should be iterating over the inverted offsets of the BlockPattern. (e.g. translateOffset(position, face1, face2, -i, -j, -k))
(an optimization is to skip Predicates.alwaysTrue() and or unplaceable blocks).
There is a second bug that I am having troubles replicating, but involves modded minecraft where as the above is reproducible in vanilla.
The second issue is involved with asymmetrical block patterns.
**Edit: ** Also effects the clay creeper face needed to respawn the dragon.
Problem:
The BlockPattern class is incorrectly matching blocks that arn't including the block being placed by the player.
Proof:
In the screenshots provided, if you replace the red wool block with a witherskull the wither will be detected and spawned, even though the pattern matched was not comprised of the block the player placed.
Possible Fix:
Instead of using a block iterator iterating over all blocks in a cube (of size 3 for the wither as it is the max(width,height,depth) the BlockPattern class should be iterating over the inverted offsets of the BlockPattern. (e.g. translateOffset(position, face1, face2, -i, -j, -k))
(an optimization is to skip Predicates.alwaysTrue() and or unplaceable blocks).
There is a second bug that I am having troubles replicating, but involves modded minecraft where as the above is reproducible in vanilla.
The second issue is involved with asymmetrical block patterns.
Nether stars (dropped by withers) currently despawn after 10 minutes.
I would have expected them to despawn after 5 minutes, or else never despawn at all / be invulnerable.
This may be works as intended, but if so the MCP names are incorrect.
Nether stars (dropped by withers) currently despawn after 10 minutes.
I would have expected them to despawn after 5 minutes, or else never despawn at all / be invulnerable.
This may be works as intended, but if so the MCP names are incorrect.
Edit:
Reproduction steps.
1. Kill a wither.
2. watch the nether star drop.
3. drop a stone block nearby.
4. note the stone block despawning.
5. Note that 5 minutes after the stone block despawns, the nether star despawns.
![[Mod] SPGoding](../../../data/avatars/users/44622.png){kind=small}
I couldn't reproduce this on 1.18 with either Forced Unicode On or Off.
Ryan Leach, could you please test if this is an issue on vanilla 1.18 without any mods?
>[Mod] Tails added a comment - 06/Feb/13 5:27 AM
>Fixed by adding the abbility for Dispensers to shoot downwards.
Meaning, the current behavior is as intended, and that you should update your map, rotating the dispensers.
No. its because the same rendering code for blocks is being used for the beacon.
the diamond block in the centre either needs to be rendered manually, or the code for rendering blocks needs a way to override whether it renders sides of blocks against solid blocks.
> This problem is now fixed for craftbukkit.
This is not bukkits JIRA, a fix in craftbukkit does not necessarily mean it has been fixed for vanilla.
Quick and Dirty method of mobspawning witherskeletons that would fix this issue.
on random tick, attempt spawn wither skeleton if room available, and block underneath is netherrackbrick in the nether.
with some crowd control checking, or say, anything else that they would want.
This would allow for, farming of wither skeletons using player made farms (possibly bad)
but fix the spawning of wither skeletons for maps made with any version of the map generation, even custom ones.
The other fix, would be to create nether "biomes" which are copies of the default nether settings that the withers could spawn in, and generate these around the fortresses on map generation.
this would at least allow versatile admins, to run a script over their nether, to re-enable wither skeleton spawning around nether fortresses.
Confirmed? shouldn't it be invalid as its intended behaviour?
I got this error, no Exception shown in console.
Was a white-listed vanilla server.
There was considerable tick lag at the time, the player was surrounded by farm animals so may relate to a high entity count.
The player killed their ghost, but it was able to float in midair without being kicked.
Presumably it was due to the alive player satisfying all the checks for being online. I assume if they logged out the ghost player may have timed out.
Killing the ghosted player results in the items dropping with the live player able to pick them up put them in chests etc.
When the live player logs out, and back in after ghost being killed, live player then takes the position of the respawned player.
I attempted to recreate this in 1.8, Nothing happens and this errir appears in the GameOutput.
I believe this is intended behaviour.
skulls only dispense if they are of type wither, and there is a valid wither base below the skull, (or if they mistakenly match the wither base pattern due to another bug)
I've managed to fix it in a modded version. http://puu.sh/cMfDn/cc88804ea3.jpg is a screenshot of what I've been doing to debug the issue.
I've uploaded the world with an example of what the code is doing.
at 0,64,0 is where the wither head was placed to generate the pattern.
0,0 - Dinnerbones code with a custom BlockPattern.
256,0 - My Fix with a custom BlockPattern.
512,0 - Dinnerbones code with a WitherBoss Pattern.
768,0 - My Fix with a WitherBoss Pattern.
Bedrock represents the block being placed.
Glowstone represents the "origin" of the BlockStructure / predicate array.
On the edge of each row / column / pillar is a "summary" of that column & pillar where the patterns are overlaid from each other.
When the wither skull was placed, the current block pattern in the first orientation overwrote its position, and 10 blocks above all possible rotations were overlaid over each other.
You can see the bug in dinnerbones code clearly, on the translations where the bedrock block is not a part of blockstructure test.
this.witherPattern = FactoryBlockPattern.start()
{"ORRR","G "," " }.aisle(new String[]
)
{"B "," "," " }).aisle(new String[]
.aisle(new String[] {"B "," "," " }
)
.where('O',IS_WITHER_SKELETON)
.where('R',Blocks.redstone_block) .where('R',BlockWorldState.hasState(BlockStateHelper.forBlock(Blocks.redstone_block)))
.where('G',Blocks.slime_block) .where('G',BlockWorldState.hasState(BlockStateHelper.forBlock(Blocks.slime_block)))
.where('B',Blocks.lapis_block) .where('B',BlockWorldState.hasState(BlockStateHelper.forBlock(Blocks.lapis_block)))
.where('~', BlockWorldState.hasState(BlockStateHelper.forBlock(Blocks.air))).build();
/time set day resets the world time to the time that day is interpreted as. this time effects the worldtime which affects the globalworldtime portion of the regiondifficulty / DifficultyInstance class.
Where as sleeping in a bed will result in
long i = this.worldInfo.getWorldTime() + 24000L;
this.worldInfo.setWorldTime(i - i % 24000L);
Which will end up setting the time to the next day, bumping the difficulty level higher.
Whether either of these events are supposed to be tied to the difficulty only Mojang know, but I suspect that either /time set day/night etc should either go to the next day, OR the difficulty should be tied to the total amount of ticks in the world instead of days passed OR the number of days passed for the difficulty counter should be counted separately and maybe be manipulated by subcommands of the /difficulty command.
An easy fix for this would be to penalize 2 deep water in the AI, mobs would be free to splash in the shallows, but would have a lot less chance to be stranded.
Duplicates #
MC-74249Can anyone confirm this for 15w31a
Another idea would be to recraft the map in a crafting grid with a compass to set a new centre to the current player position.
You have reported this under Mojang Web services, you should be reporting this under minecraft for whichever platform you are playing on.
You have reported this under Mojang Web services, you should be reporting this under minecraft for whichever platform you are playing on.
You have reported this under Mojang Web services, you should be reporting this under minecraft for whichever platform you are playing on.
You have reported this under Mojang Web services, you should be reporting this under minecraft for whichever platform you are playing on.
You have reported this under Mojang Web services, you should be reporting this under minecraft for whichever platform you are playing on.
You have reported this under Mojang Web services, you should be reporting this under minecraft for whichever platform you are playing on.
You have reported this under Mojang Web services, you should be reporting this under minecraft for whichever platform you are playing on.
You have reported this under Mojang Web services, you should be reporting this under minecraft for whichever platform you are playing on.
You have reported this under Mojang Web services, you should be reporting this under minecraft for whichever platform you are playing on.
You have reported this under Mojang Web services, you should be reporting this under minecraft for whichever platform you are playing on.
You have reported this under Mojang Web services, you should be reporting this under minecraft for whichever platform you are playing on.
@Mustek How are mods chosen for the bug tracker? / Is there any way I can help to clean issues up like this or bring them to moderator attention?
I sill get this issue or a similar one on 1.8.8
I've come across this issue after enabling cheats on lan mode, in order to access /gamerule doNaturalRegeneration false. (on 1.8)
Are you sure this is a bug and not intended behaviour, or that you didn't accidentally make eye contact?
It may have been that you spawned an endermite at your position, making the enderman target the endermite that was at your feet?
It's likely your computer stealing focus away from minecraft.
How is this a bug? endstone is more blast resistant so the dragon doesn't accidentally destroy the blocks. harvesting them and crafting them could potentially change the mechanics of combat of the dragon fight as you would be able to use endstone bricks as a dragon resistant structure.
Strange. I've used lan mode fine. No multiplayer is not being disabled with the introduction of minecraft realms, it would be social suicide for minecraft.
Edit: looked at the picture.
I disagree with the suggested fix, the correct fix would be to recalculate chat widths from a cache when unicode is enabled or disabled.
The problem is that the original chat is edited and line breaks added when messages are recieved.
But this is a really minor issue, restarting the client should fix this as it only happens when unicode mode is changed, not if unicode is just on, or just off all game session.
duplicate of
MC-81876Easiest fix would be to replace the ascii characters with unicode equivalents in the translation files.
Best fix I think for this would be to migrate anything using the hard coded formatting markers to use the IChatComponent like text tree's
Realized I never posted the fix for this in the issue, sorry about the obfuscation, it's the original copy and I havn't had time to get my head back into what causes this.
https://gist.github.com/ryantheleach/a345bd4474d51ac484637cdc6cf0b568
Agree, redirecting the output only would allow compact redstone without side effects.
Not only this, but spacing them by 1 block is NSEW UD dependent.
Either remove the functionality, or make it symmetric.
Unless "bob" has Moderator / Dev status how were they able to trigger this bulk message? That's the real thing that needs to be fixed...
But anyway, I've updated it to the latest available snapshot.
Sorry to bump this ancient issue, but Chris, we have tried and failed to get in contact with you regarding a license change on the SpongePowered SpongeDocs.
If you could get back to us we would really appreciate it.
https://github.com/SpongePowered/SpongeDocs/pull/573
If this was true previously, it definitely isn't now.
Tested on a new world, setting the max size resulted in a world border of the correct size, restarting with a smaller max size set, resulted in a border of the correct size. Sorry for wasting your time. @pokechu22
Sorry, I understand the confusion. I forgot to mention reproduction steps.
1. Kill a wither.
2. watch the nether star drop.
3. drop a stone block nearby.
4. note the stone block despawning.
5. Note that 5 minutes after the stone block despawns, the nether star despawns.
The nether star will have a creative despawn of 1 minute if dropped in creative mode, or 5 minutes in survival if dropped from a player inventory. Only after it drops from a wither is it given a negative age of -6000, and it's also the only place in the minecraft codebase that method is used, so it would be pretty easy to miss as a bug.
And Yes, I know MCP is not "officially" supported by Mojang, However the fact that EntityItem has a method, that changes the age to be a negative value on 1.12 , is usually a pretty sure sign that something is supposed to have an infinite timespan. negative values like that are commonly used in other programs, and elsewhere in minecraft to mean infinite.
That said I'm happy to accept this as Works as Intended after developer input, but definitely not closed due to 'cannot reproduce'
Affects 1.15.1
This bug still exists in some fashion on 1.18.1
Forced Unicode On
Forced Uncode Off: