You can be sure that I analyzed this bug carefully. However, you should check the following information for accuracy before implementing it.
Keep in mind that stones interact with the magic wall, not the magic wall with stones. When a falling stone drops into the magic wall, the following things will happen (go to step 2.)
Code: Select all
1. A falling stone drops into the magic wall
2. The scan is aborted directly without changing or resetting the delayed state of any element in the cave
3. The position of the field to the diagonally up/left will be saved
4. Only the delayed states of all elements above this saved position are reset (delayed state = false)
5. Now, the cave is rescanned from the beginning
6. If another stone drops into the magic wall, then go to step 2.
Code: Select all
=> 2) All the following elements are not scanned during this frame. If no amoeba was able to grow before, all amoebas will turn into diamonds in the next scan.
=> 3) Example: The falling stone that lies on the magic wall, before it drops into it, is located at position xy(5,5). The field to the diagonally up/left is at xy(4,4)
=> 4) The delayed state of the elements from xy(0,0) to xy(3,4) are set to "false/not delayed"
=> 5.) This is a normal scan. all the elements above the saved position (step 3.) can move again (delayed state = false)
During the rescan, the elements above the saved position (step 3.) move very quick. Sometimes you can't even see the drawing. The elements beyond the wall move nearly at normal speed, slowed down only a little bit.
My opinion is that the cave delay takes place after the scan routine. If the scan was aborted, the cave delay is performed after finishing the rescan, not before.