Dealing with hat blocks about scratch-vm HOT 4 CLOSED

Here are a couple ideas (I know nothing about the VM, so this is pretty much JS pseudocode):

class Hat extends Block {
  constructor() {
    // set shouldActivate to true to call - later this gets turned to false
    this.shouldActivate = false
  }

  checkActivated() {
    // calls every tick - when this returns true, the VM runs the stack
    if (this.shouldActivate) {
      this.shouldActivate = false
      return true
    }
    return false
  }
}

class HatGreenFlagClicked extends Hat {}

(/* external */).on('green flag clicked', () => {
  for (let hat of eachBlockThatIsA(HatGreenFlagClicked)) {
    hat.shouldActivate = true
  }
})

class Hat extends Block {
  activate() {
    // run the stack *right now!*
  }
}

class HatGreenFlagClicked extends Hat {}

(/* external */).on('green flag clicked', () => {
  for (let hat of eachBlockThatIsA(HatGreenFlagClicked)) {
    hat.activate()
  }
})

The second here is in my opinion better, because for something like this:

..only one item will be added to a list, assuming broadcast doesn't cause a yield.

Which is how Scratch 2.0 behaves. That's the point of broadcast and wait.

So.. if we're doing this with promises - probably not :( - this could happen:

class Hat extends Block {
  async activate() {
    return await vm.runStack(/* my stack */)
  }
}

class StackBroadcast {
  callBlock(broadcastName) {
    const broadcast = (/* get broadcast using broadcastName */)
    broadcast.activate()
  }
}

class StackBroadcastAndWait {
  callBlock(broadcastName) {
    const broadcast = (/* get broadcast using broadcastName */)
    await broadcast.activate()
  }
}

// using async/await because it's handy especially for mockups like this!
// totally unnecessary though.

PS we really need an issue on broadcasts! (Wouldn't it be fun if it was less hacky?)

from scratch-vm.

Those are all pretty intriguing, thanks! I really personally like your version 2, with the explicit activation. To me that maps pretty well to what hats "seem" to do.

Of course, we need to consider cases like "when loudness > ..." For these cases, something needs to be looking at the sensor data and triggering hats when necessary. Not sure in our current framework where that should live, and whether that trigger should be defined near the block itself (like in the Scratch 2.0 extensions framework), or just handled like special cases (like in the actual implementation of the 2.0 "when loudness >_" block, https://github.com/LLK/scratch-flash/blob/3c1671b38e692637974c676064d140bc04957e36/src/scratch/ScratchRuntime.as#L658)

from scratch-vm.

"when () > ()" shouldn't be too hard to implement - there are two ways:

class HatWhen extends Hat {
  constructor() {
    super(/* etc */)

    // careful when you do this that this on-every-tick only
    // applies for blocks in the workspace!
    vm.on('every tick', () => {
      if (/* conditions */) {
        // don't run when already activated, right? Assuming #2,
        // we'd end up having *a ton* of threads running the same
        // stack (for "when timer > 5" after 5 seconds, in fact, a new
        // thread every tick [because vm-on-every-tick]!)
        if (!hat.activated) {
          this.activate()
        }
      }
    })
  }
}

class HatWhen extends Hat {}

vm.on('every tick', () => {
  for (let hat of eachBlockThatIsA(HatWhen)) {
    if (/* conditions */) {
      // see above
      if (!hat.activated) {
        hat.activate()
      }
    }
  }
})

The second would probably be more efficient because it only has one interval, and I'd write the interval creation right below the "when" hat definition (probably in some vm-on-ready () => vm-on-tick, again I don't know much about how scratch-vm currently works :) ).

EDIT: Aren't all hat blocks special cases? They'd all be activated using .activate() based on some event.

from scratch-vm.

Some initial notes:

• - Some hats will restart existing threads (flag clicked, sprite clicked, etc.) and some won't (when key pressed, when _ > _).
• - Some hats are event-triggered (flag clicked, sprite clicked, etc.) and some are edge triggered (when _ > _), which means it's only activated when a value crosses the boundary.
• - Some hats are activated by a caller with matching "parameters" (e.g., broadcasts).
• - Hats need to be able to evaluate any expression at run-time (e.g., for dropping in to when _ > _).
• - Some hats need to be sprite/target specific (when this sprite clicked); others apply globally.

from scratch-vm.