`environment_attribute` value providers give incorrect results on subsequent accesses within a tick

Expected behaviour

Either:

• Whenever an environment attribute changes (e.g. as a result of a command inside a function), reading from the environment attribute using a number provider (e.g. in a loot table) retrieves the updated value

  • (Note: Could be implemented by marking attributes as dirty when an associated timeline changes its value, and updating them when read while dirty, with the idea being that the attribute doesn’t update unnecessarily if a lot of timelines are associated)

• Environment attributes update at a pre-defined point in the tick order

  • (Note: Simpler, but slightly less useful for users because reading would not take previous modifications earlier in the tick into account)

=> Reading an environment attribute should never affect the outcome of future reads

What happens instead

Reading from an environment attribute using a number provider “locks” it to the same value for all subsequent calls for the remainder of the tick, even though the actual value updates correctly (at least by the end of the tick).

How to reproduce

1. Download the attached Data Pack and install it in a new world

2. Run the function bugreport:test/1

   1. Observation: It works as expected, because the value is read only once, after the modification is complete

3. Run the function bugreport:test/2

   1. Observation: The 2nd modification of the bugreport:test timeline (A function call for bugreport:test/1) changes the cloud height as expected, but the value that’s read is the same as before the modification

Data Pack Explanation

Timelines:

• bugreport:test’s value is added to the overworld’s cloud height

Functions:

• bugreport:test/reset_cloud_height sets the timeline to 0 and prints the (correct) default cloud height. Helper function for testing bugreport:test/1.

• bugreport:test/1 sets the timeline to 128 (adds 128 to the cloud height) and prints the cloud height in chat

• bugreport:test/2 first sets the timeline to 0, prints it in chat, then runs bugreport:test/1 (which prints the wrong value because it was already read after setting the timeline to 0)