Post by chriscrawford on Feb 11, 2016 9:04:09 GMT -8
I had hoped to have wrapped up the work on combat this week, but that's looking less likely. I have the animation itself in pretty good shape. It could be a lot better, but it's adequate for now. But there are still problems with the sequencing of the events. Here's the latest pain-in-the-butt issue:
The sequence of events for combat is as follows:
Fate {tap actor for combat} ActorX
ActorX {attack} ActorY {with Auragon1} (in this sentence, Auragon1 is not visible to ActorY)
ActorY {defend} ActorX {with Auragon2} Auragon1
The idea of this last sentence is that, by moving Auragon1 from WordSocket #3 to WordSocket #4, it will not be visible to ActorY.
However, the painting of the window takes place asynchronously with the calculation of the WordSocket contents by the engine. The Engine does not calculate the contents of WordSocket #4 until AFTER the player has chosen the content of WordSocket #3 (because the contents of WordSocket #4 might be dependent upon the contents of WordSocket #3). But the painting routine takes place whenever a mouse event takes place, so when the player uses the mouse, the program attempts to redraw the window, and it knows that there should be something in WordSocket #4, but it finds that WordSocket empty, so it bombs.
I shall remove the breakpoint that triggers when the program gets into a hole with an unknown WordSocket, and see if it can simply continue safely.
The sequence of events for combat is as follows:
Fate {tap actor for combat} ActorX
ActorX {attack} ActorY {with Auragon1} (in this sentence, Auragon1 is not visible to ActorY)
ActorY {defend} ActorX {with Auragon2} Auragon1
The idea of this last sentence is that, by moving Auragon1 from WordSocket #3 to WordSocket #4, it will not be visible to ActorY.
However, the painting of the window takes place asynchronously with the calculation of the WordSocket contents by the engine. The Engine does not calculate the contents of WordSocket #4 until AFTER the player has chosen the content of WordSocket #3 (because the contents of WordSocket #4 might be dependent upon the contents of WordSocket #3). But the painting routine takes place whenever a mouse event takes place, so when the player uses the mouse, the program attempts to redraw the window, and it knows that there should be something in WordSocket #4, but it finds that WordSocket empty, so it bombs.
I shall remove the breakpoint that triggers when the program gets into a hole with an unknown WordSocket, and see if it can simply continue safely.