Uploaded image for project: 'Minecraft: Java Edition'
  1. Minecraft: Java Edition
  2. MC-275071

Movement predicates inconsistently handle negative values

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • None
    • 1.21.1, 24w35a
    • None
    • Community Consensus
    • Commands, Data Packs
    • Normal
    • Platform

      When testing if a speed value is in a range that includes negative numbers, the different speed checks handle the predicate in different ways.

      It should be noted that while a negative speed is invalid, a range that includes both negative and positive numbers should still pass if the actual speed is in that range. The game also doesn't throw any errors for using a negative number like it does for the periodic_tick predicate when a negative value is supplied. This means that the predicate will silently fail when used for "speed" or "horizontal_speed", but notably does work for "vertical_speed".

       

      Expected results:

      The predicate conditions "speed", "horizontal_speed", and "vertical_speed" should all work consistently when a negative number is in the range. They should either all pass if the given speed is within the range, or they should all throw an error due to a negative speed being in the range.

       

      Use this range for the following predicates:

      {min:-1,max:1}

      Predicate 1:

      /execute if predicate {condition:"entity_properties",entity:"this",predicate:{movement:{vertical_speed:{min:-1,max:1}}}}

      Predicate 2:

      /execute if predicate {condition:"entity_properties",entity:"this",predicate:{movement:{horizontal_speed:{min:-1,max:1}}}}

      Predicate 3:

      /execute if predicate {condition:"entity_properties",entity:"this",predicate:{movement:{speed:{min:-1,max:1}}}}

      When running these commands while standing still, only Predicate 1 passes. This makes sense, as the vertical speed is 0, which is within the range [-1,1], but since the horizontal speed and total speed are also 0, they should pass too.

       

      This appears to be due to the horizontal and total speed calculations taking squaring the real speed, squaring the two range speeds, then comparing if the squared actual speed is within the range of the squared range speeds. The vertical speed calculation simply looks at the absolute value of the "y" speed, but does not take the absolute value of the two range speeds.

       

      For reference, the following predicate example shows how the game usually throws errors for invalid inputs:

      /execute if predicate {condition:"entity_properties",entity:"this",predicate:{periodic_tick:-1}}

      This will output an error stating the "Value must be positive"

            Unassigned Unassigned
            42Richtofen42 42Richtofen42
            Votes:
            4 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              CHK: