1
ShelLuser
Hi gang!
(edit): A solution has been shared, see below.
As you probably know 1.13 has changed quite a bit in the game; commands got changed and sometimes even removed (or replace by others). One of which is /testfor which has been removed in favor of /execute. Unfortunately there's one thing missing...
If you were to use /testfor in a command block then this would result with the block sending a redstone signal based on the result of the testfor. For example: check the amount of sheep in your world and you'd get a redstone signal with the same strength. Of course this had pretty limited use because the maximum amount of a redstone signal is 15 and there can easily be more than 15 sheep (or any other entities) in your world. Still, it was a fun feature.
In 1.13 this doesn't work anymore: if you run /execute if entity @e[type=sheep] then you'll only get a redstone signal of 1 at best which indicates that the test succeeded. But you no longer get the actual value itself anymore. So I tried to work my way around it but unfortunately I think that this isn't possible anymore: generating a redstone signal based on the amount of entities in the world.
The next thing I tried was checking up on redstone components and when studying the comparator using /data I discovered the OutputSignal property which represents the redstone signal. Unfortunately you can't really use it. Although it's perfectly doable to use /execute store to store the amount of entities into this property it won't change the actual signal, nor will the change retain; as soon as you perform a block update (by placing another block nearby) then it resets to its original value.
Then I remembered that an item frame can also generate a redstone signal based on its rotation. And using /data once more I discovered the ItemRotation byte property. Guess what? Updating it using /execute store works, though it gets annoying because it also generates an ongoing noise. Worse yet: if you check the redstone value using a comparator you'll once again notice that despite the change in rotation (even visible) it doesn't change the redstone signal itself.
So right now I'm starting to get convinced that it is no longer possible to generate a redstone signal based on an amount of entities anymore, and I'd like to be proven wrong if possible :)
Don't get me wrong though: I'm well aware that we have much better alternatives now. For example: while a redstone signal can only reach a maximum value of 15 a bossbar (for example) can easily do 100. Making a bossbar an ideal way to display a certain value (like the amount of players or sheep or...).. No arguments there; the whole thing was kind of useless. Still, it was also fun seeing redstone lamps turn on or off based on the amount of sheep or players or...
Is this the one thing that's no longer possible?
(edit): It is possible, please see Garlicbreathinator's response below, thanks Garlic!
(edit): A solution has been shared, see below.
As you probably know 1.13 has changed quite a bit in the game; commands got changed and sometimes even removed (or replace by others). One of which is /testfor which has been removed in favor of /execute. Unfortunately there's one thing missing...
If you were to use /testfor in a command block then this would result with the block sending a redstone signal based on the result of the testfor. For example: check the amount of sheep in your world and you'd get a redstone signal with the same strength. Of course this had pretty limited use because the maximum amount of a redstone signal is 15 and there can easily be more than 15 sheep (or any other entities) in your world. Still, it was a fun feature.
In 1.13 this doesn't work anymore: if you run /execute if entity @e[type=sheep] then you'll only get a redstone signal of 1 at best which indicates that the test succeeded. But you no longer get the actual value itself anymore. So I tried to work my way around it but unfortunately I think that this isn't possible anymore: generating a redstone signal based on the amount of entities in the world.
The next thing I tried was checking up on redstone components and when studying the comparator using /data I discovered the OutputSignal property which represents the redstone signal. Unfortunately you can't really use it. Although it's perfectly doable to use /execute store to store the amount of entities into this property it won't change the actual signal, nor will the change retain; as soon as you perform a block update (by placing another block nearby) then it resets to its original value.
Then I remembered that an item frame can also generate a redstone signal based on its rotation. And using /data once more I discovered the ItemRotation byte property. Guess what? Updating it using /execute store works, though it gets annoying because it also generates an ongoing noise. Worse yet: if you check the redstone value using a comparator you'll once again notice that despite the change in rotation (even visible) it doesn't change the redstone signal itself.
So right now I'm starting to get convinced that it is no longer possible to generate a redstone signal based on an amount of entities anymore, and I'd like to be proven wrong if possible :)
Don't get me wrong though: I'm well aware that we have much better alternatives now. For example: while a redstone signal can only reach a maximum value of 15 a bossbar (for example) can easily do 100. Making a bossbar an ideal way to display a certain value (like the amount of players or sheep or...).. No arguments there; the whole thing was kind of useless. Still, it was also fun seeing redstone lamps turn on or off based on the amount of sheep or players or...
Is this the one thing that's no longer possible?
(edit): It is possible, please see Garlicbreathinator's response below, thanks Garlic!
Create an account or sign in to comment.
7
2
It is actually still possible. You overlooked that the success count of /execute as <...> is the number of entities it runs as. Therefore, the command "/execute as @e[type=minecraft:sheep] run data get entity @s" will fulfill the same purpose. The success count is the number of sheep that can read their own entitydata (as in all of them).
edit: P.S. are you still working on that sokoban project? I could help you draft that up really quickly!
edit: P.S. are you still working on that sokoban project? I could help you draft that up really quickly!
2
Perfect! Yeah, I did know about the construction but I'd never have imagined that this would actually generate the redstone signal I was after. Thanks, much appreciated!
And yes, still working on that project. Got the redstone / command block routines all sorted out, now it's merely setting up & decorating the levels and creating some solid score mechanics & advancements. It'll work.
And yes, still working on that project. Got the redstone / command block routines all sorted out, now it's merely setting up & decorating the levels and creating some solid score mechanics & advancements. It'll work.
1
Minecraft was killed when 1.13 released
3
That's what they said about 1.9 too and here we are :)
1
1.13 killed many servers, plugins dont work, worlds had to reset and all the character and alphabet was changed, all the designs on all the server like ----[ Server ]----- now look trash...
2
Did 1.13 kill those servers or did bad management do that?
See, at the time of writing 1.13 isn't even officially supported yet by the modding community. Although the Spigot project (= modded Minecraft server (for those who didn't know)) allows you to build and run 1.13.1, the default (and therefor recommended) version is still 1.12.2 at this time. And it's not just Spigot. Forge, another big name for modded Minecraft on both client and server, also provides 1.12.2 at the moment while there is no official ETA on 1.13 support.
I think this is also the reason why many bigger (more serious?) servers haven't upgraded to 1.13 just yet. Both servers I'm mostly familiar with (player amounts vary between 30 - 110) both sit on 1.12.2 at this time.
And finally... Vanilla servers have no issues. Realms for example has easily upgraded and I'm not aware of hundreds of upset players who had to cope with broken worlds. In fact, I'm convinced it's the opposite because my (private) vanilla LAN server also easily upgraded without any problem.
In fact: I'm even playing a single player world which I started around 1.8.9 and have continued to play and upgrade throughout the years. No issues, not even on 1.13.1.
You can't blame Mojang for everything ;)
See, at the time of writing 1.13 isn't even officially supported yet by the modding community. Although the Spigot project (= modded Minecraft server (for those who didn't know)) allows you to build and run 1.13.1, the default (and therefor recommended) version is still 1.12.2 at this time. And it's not just Spigot. Forge, another big name for modded Minecraft on both client and server, also provides 1.12.2 at the moment while there is no official ETA on 1.13 support.
I think this is also the reason why many bigger (more serious?) servers haven't upgraded to 1.13 just yet. Both servers I'm mostly familiar with (player amounts vary between 30 - 110) both sit on 1.12.2 at this time.
And finally... Vanilla servers have no issues. Realms for example has easily upgraded and I'm not aware of hundreds of upset players who had to cope with broken worlds. In fact, I'm convinced it's the opposite because my (private) vanilla LAN server also easily upgraded without any problem.
In fact: I'm even playing a single player world which I started around 1.8.9 and have continued to play and upgrade throughout the years. No issues, not even on 1.13.1.
You can't blame Mojang for everything ;)
3
That's what happens with ANY major giant update. I wish people would stop quoting other people on this aspect. 1.13 has more players then almost any other Minecraft version to DATE. Saying it's dying simply just is FALSE. <3
As far as dead servers, try to find yourself server owners that recognize the game has to evolve and have kept up with updating. The servers that completely fall apart because of the update don't NEED to. They are simply too invested in the heavy amount of plug ins they rely on and aren't willing to spend the time and energy it takes to make a 1.13 server. 99 percent of my plug-ins have successfully updated without too many issues :o
The last comment I'll make (and this is all just for friendly information!) is that Minecraft is going into a REALLY fantastic place with a long life due to the hard work and dedication of the community and Devs. Don't get sad and discouraged, Try to remember this all and find yourself a harder working Server owner. Nothing is built to last <3
As far as dead servers, try to find yourself server owners that recognize the game has to evolve and have kept up with updating. The servers that completely fall apart because of the update don't NEED to. They are simply too invested in the heavy amount of plug ins they rely on and aren't willing to spend the time and energy it takes to make a 1.13 server. 99 percent of my plug-ins have successfully updated without too many issues :o
The last comment I'll make (and this is all just for friendly information!) is that Minecraft is going into a REALLY fantastic place with a long life due to the hard work and dedication of the community and Devs. Don't get sad and discouraged, Try to remember this all and find yourself a harder working Server owner. Nothing is built to last <3
