2

Follow

Command Block Comparator Output Proportional to Limit Set

Have it so the comparator strength given from a command block testing for a number is relative to the limit value given. It could function as normal if no limit is given.

The command /execute if entity @e[type=squid,limit=10] could send out 50% of a max redstone signal strength if 5 squids were found for example. 1 less than the limit, no matter how close, won't get a max signal strength such as 499 of 500. Going over the limit could just keep the redstone signal at max strength.

(To be compatible with my other suggestion a command like /execute if entity @e[type=squid,limit=10..20] would produce 50% signal if 15 squids were found and be off if outside the range given.)

(Also with compatibility a command like /execute if entity @e[type=squid,limit=10..20..] could have it so at 15 squids it is still at 50% strength but it stays at 100% strength if going over 20.[type=squid,limit=..10..20] would have it give minimum signal strength if it's below 10 squids. These last two paragraphs only apply if both suggestions were considered as they both have todo with the limit selector.)

Registered User shared this idea

• October 13, 2020 05:26
• Report a Concern

Please sign in to leave a comment.

• 0

  Registered User commented

  Comment actions Permalink

  • November 13, 2020 02:42
  • Report a Concern
  • Comment actions Permalink

  Commands and redstone are known not to go together well. If you are using comparators to measure signal strength as part of your command contraption, don't! A better way is to use scoreboards instead, unless your comparator ties into a redstone contraption instead of activating more commands.

  Scoreboards have a maximum of 2,147,483,647 rather than the maximum of 15 for redstone. You could do something like this:

  execute store result score FakePlayer myObjective if entity @e[type=squid]

  and then do operations based off of that scoreboard value.