Generalize hazard failure#4805
Conversation
|
lgtm! |
There was a problem hiding this comment.
Would be good to use a name that is not specific to the interpreter, since we need this to impact both blockly/non-interpreter and droplet/interpreter modes. I think it probably already works for the blockly case, but the name is a little misleading.
There was a problem hiding this comment.
There's an off-by-one error in the blockly case that I'm not sure how to
solve yet, where this failure is detected the command after the one that
moves you into the hazard's grid square. I suspect it's only working in
droplet-land because of that extra tick between steps.
On Mon, Oct 26, 2015 at 6:21 PM, Chris Pirich notifications@github.com
wrote:
In apps/src/studio/studio.js
#4805 (comment)
:@@ -801,7 +801,7 @@ Studio.onTick = function() {
Studio.clearDebugElements();
- var animationOnlyFrame = Studio.midExecutionFailure ||
- var animationOnlyFrame = Studio.pauseInterpreter ||
Would be good to use a name that is not specific to the interpreter, since
we need this to impact both blockly/non-interpreter and droplet/interpreter
modes. I think it probably already works for the blockly case, but the
name is a little misleading.—
Reply to this email directly or view it on GitHub
https://github.com/code-dot-org/code-dot-org/pull/4805/files#r43075472.
Brad Buchanan
Software Engineer, Code.org
brad@code.org
We still have a concept of a "hazard" item but instead of triggering failure directly it does so through the new progressConditions system.