Jackson
- Jacksoncreeper
- jacksoncreeper
- Europe/Stockholm
- Yes
- No
When I use /setblock and /fill with the end gateway and add the
{Age:201}tag it does not remove the magenta beam on the end gateway. The tag is supposed to removed the beam when higher than 200.
Ex:
{Age:300}
/setblock ~ ~ ~ minecraft:end_gateway 0 replaceNote: I am using Minecraft 1.12.1 on Minecraft Realms.
When receiving a resource pack from the server via the resource pack packet the client downloads (or reapplies if it exists) the resource pack provided by the packet.
During this process, the client clears the current resource pack (the issue) and then
clears old serverpacks which may not be used anymore.However, clearing the server resource pack is an un-necessary step as it causes the client to reload all resources to
thenreload it a second time if the pack successfully downloads. When the pack is successfully downloaded (or found), the client sets the server pack which does the aforementioned step above ofclearing itand reloads theresourcepacks.In this situation, the client only needs to clear the server pack when the new resource pack fails to download, which is how it currently functions but without un-necessarily reloading when the pack succeeds in downloading.
Below is a patch of a code change I made to fix this issue in Official Mappings.
diff --git a/src/main/java/net/minecraft/client/resources/ClientPackSource.java b/src/main/java/net/minecraft/client/resources/ClientPackSource.java --- a/src/main/java/net/minecraft/client/resources/ClientPackSource.java +++ b/src/main/java/net/minecraft/client/resources/ClientPackSource.java @@ -112,8 +112,6 @@ CompletableFuture var14; try { - this.clearServerPack(); - this.clearOldDownloads(); File file = new File(this.serverPackDir, string3); CompletableFuture<?> completableFuture; if (file.exists()) { @@ -144,6 +142,7 @@ (void_, throwable) -> { if (throwable != null) { LOGGER.warn("Pack application failed: {}, deleting file {}", throwable.getMessage(), file); + this.clearServerPack(); deleteQuietly(file); Minecraft minecraftx = Minecraft.getInstance(); minecraftx.execute( @@ -172,6 +171,7 @@ } ); var14 = this.currentDownload; + this.clearOldDownloads(); } finally { this.downloadLock.unlock(); }This moves the clearOldDownloads call to after everything is finished, however this may not be necessary, I only made this change as a "just in case." The main change here is moving the clearServerPack to only when the pack fails to apply.
The result of this fix is the client only reloading once when receiving a server resource pack while one is already loaded. (for example, the server sends another resource pack packet after the initial one is sent)
When receiving a resource pack from the server via the resource pack packet the client downloads (or reapplies if it exists) the resource pack provided by the ClientboundResourcePackPacket.
During this process, the client clears the current server resource pack (the issue) and then deletes old server resource pack files which may not be used anymore.
However, clearing the server resource pack is an un-necessary step as it causes the client to reload all resources to set the server resource pack to nothing and reload it a second time if the pack successfully downloads to apply the new server resource pack. When the pack is successfully downloaded (or found), the client sets the server pack which does the aforementioned step above of setting the server resource pack and reloading resources.
In this situation, the client only needs to clear the server pack when the new resource pack fails to download, which is how it currently functions but without un-necessarily reloading when the pack succeeds in downloading.
Below is a patch of a code change I made to fix this issue using official mappings.
diff --git a/src/main/java/net/minecraft/client/resources/ClientPackSource.java b/src/main/java/net/minecraft/client/resources/ClientPackSource.java --- a/src/main/java/net/minecraft/client/resources/ClientPackSource.java +++ b/src/main/java/net/minecraft/client/resources/ClientPackSource.java @@ -112,8 +112,6 @@ CompletableFuture var14; try { - this.clearServerPack(); - this.clearOldDownloads(); File file = new File(this.serverPackDir, string3); CompletableFuture<?> completableFuture; if (file.exists()) { @@ -144,6 +142,7 @@ (void_, throwable) -> { if (throwable != null) { LOGGER.warn("Pack application failed: {}, deleting file {}", throwable.getMessage(), file); + this.clearServerPack(); deleteQuietly(file); Minecraft minecraftx = Minecraft.getInstance(); minecraftx.execute( @@ -172,6 +171,7 @@ } ); var14 = this.currentDownload; + this.clearOldDownloads(); } finally { this.downloadLock.unlock(); }This moves the clearOldDownloads call to after everything is finished, however this may not be necessary, I only made this change as a "just in case." The main change here is moving the clearServerPack call to only when the pack fails to apply.
The result of this fix is the client only reloading once when receiving a server resource pack while one is already loaded. (for example, the server sends another resource pack packet after the initial one is sent)
When receiving a resource pack from the server via the resource pack packet the client downloads (or reapplies if it exists) the resource pack provided by the ClientboundResourcePackPacket.
During this process, the client clears the current server resource pack (the issue) and then deletes old server resource pack files which may not be used anymore.
However, clearing the server resource pack is an un-necessary step as it causes the client to reload all resources to set the server resource pack to nothing and reload it a second time if the pack successfully downloads to apply the new server resource pack. When the pack is successfully downloaded (or found), the client sets the server pack which does the aforementioned step above of setting the server resource pack and reloading resources.
In this situation, the client only needs to clear the server pack when the new resource pack fails to download, which is how it currently functions but without un-necessarily reloading when the pack succeeds in downloading.
Below is a patch of a code change I made to fix this issue using official mappings.
diff --git a/src/main/java/net/minecraft/client/resources/ClientPackSource.java b/src/main/java/net/minecraft/client/resources/ClientPackSource.java --- a/src/main/java/net/minecraft/client/resources/ClientPackSource.java +++ b/src/main/java/net/minecraft/client/resources/ClientPackSource.java @@ -112,8 +112,6 @@ CompletableFuture var14; try { - this.clearServerPack(); - this.clearOldDownloads(); File file = new File(this.serverPackDir, string3); CompletableFuture<?> completableFuture; if (file.exists()) { @@ -144,6 +142,7 @@ (void_, throwable) -> { if (throwable != null) { LOGGER.warn("Pack application failed: {}, deleting file {}", throwable.getMessage(), file); + this.clearServerPack(); deleteQuietly(file); Minecraft minecraftx = Minecraft.getInstance(); minecraftx.execute( @@ -172,6 +171,7 @@ } ); var14 = this.currentDownload; + this.clearOldDownloads(); } finally { this.downloadLock.unlock(); }This moves the clearOldDownloads call to after everything is finished
, however this may not be necessary, I only made this change as a "just in case."The main change here is moving the clearServerPack call to only when the pack fails to apply.The result of this fix is the client only reloading once when receiving a server resource pack while one is already loaded. (for example, the server sends another resource pack packet after the initial one is sent)
When receiving a resource pack from the server via the resource pack packet the client downloads (or reapplies if it exists) the resource pack provided by the ClientboundResourcePackPacket.
During this process, the client clears the current server resource pack (the issue) and then deletes old server resource pack files which may not be used anymore.
However, clearing the server resource pack is an un-necessary step as it causes the client to reload all resources to set the server resource pack to nothing and reload it a second time if the pack successfully downloads to apply the new server resource pack. When the pack is successfully downloaded (or found), the client sets the server pack which does the aforementioned step above of setting the server resource pack and reloading resources.
In this situation, the client only needs to clear the server pack when the new resource pack fails to download, which is how it currently functions but without un-necessarily reloading when the pack succeeds in downloading.
Below is a patch of a code change I made to fix this issue using official mappings.
diff --git a/src/main/java/net/minecraft/client/resources/ClientPackSource.java b/src/main/java/net/minecraft/client/resources/ClientPackSource.java --- a/src/main/java/net/minecraft/client/resources/ClientPackSource.java +++ b/src/main/java/net/minecraft/client/resources/ClientPackSource.java @@ -112,8 +112,6 @@ CompletableFuture var14; try { - this.clearServerPack(); - this.clearOldDownloads(); File file = new File(this.serverPackDir, string3); CompletableFuture<?> completableFuture; if (file.exists()) { @@ -144,6 +142,7 @@ (void_, throwable) -> { if (throwable != null) { LOGGER.warn("Pack application failed: {}, deleting file {}", throwable.getMessage(), file); + this.clearServerPack(); deleteQuietly(file); Minecraft minecraftx = Minecraft.getInstance(); minecraftx.execute( @@ -172,6 +171,7 @@ } ); var14 = this.currentDownload; + this.clearOldDownloads(); } finally { this.downloadLock.unlock(); }This moves the clearOldDownloads call to after everything is finished to cover the edge case of an old resource pack still being in use, therefore being unable to be deleted and causing the method to fail. The main change here is moving the clearServerPack call to only when the pack fails to apply.
The result of this fix is the client only reloading once when receiving a server resource pack while one is already loaded. (for example, the server sends another resource pack packet after the initial one is sent)


Well theres a bug.. If parrots are around when getting a custom advancement you crash.
I have watched multiple videos and I also read the wiki. There is an age tag which removes the magenta beam. The videos showed that it works.
"Please make a backup in case you experience world corruptions." means corruptions are most likely gonna happen. If you clicked backup and load, there should be a zip file in your saves folder which contains a backup.