This was caused because the case for BoostMessage.PORT_FEEDBACK didn't handle the BoostPortFeedback.DISCARDED type, which corresponds to a command failing on the Boost hub.
- Creating Boost._colorBucket will contains BoostColorSampleSize-amount of samples
- Boost._onMessage administers the _colorBucket and assigns Boost._sensors.color a value if all items in the bucket match.
E.g. if BoostColorSampleSize is set to 3, three continuous readings of the same color are required for the color to be detected by scratch-vm.
- Renamed BoostOutputCommandFeedback to BoostPortFeedback and its values for brevity
- Removed buf2hex-function
- Removed BoostMotor._pendingPositionOrigin (unused)
- Removed Boost._led (unused)
- Simplified _onMessage-handling of BoostPortFeedback-messages
- motorOnForRotation() now returns a Promise.all rather than a single promise. This solves two bugs:
-- when running turn ABCD for 3 rotations without motors connected to CD, the block would finish yielding immediately.
-- when running turn C for X rotations without a motor connected to C, the motor would never finish yielding.
- BoostMotor-class now has pendingPositionDestination, the rotation-equivalent of pendingTimeout, that stores a destination the motor should reach. When using setMotorPower() or setMotorDirection() while a motorOnForRotation()-block is running, a new motorOnForRotation()-command will be run for the remaining amount of degrees but with new power/direction, cancelling the old command.
- BoostMotor._status is only affected by feedback from the hub.
- setMotorPower() and setMotorDirection() no longer yields, since they just set state.
From design meeting regarding block design:
- Renamed all motors-label to ABCD.
- Added 'AB' motor label to address built-in motor pair.
- use the word direction in the setMotorDirection-block
- moved argument label in motor position reporter
- changed wording of color-sensing block.
- removed isTilted-boolean reporter
- removed changeLightHueBy-block
- fixed pingDevice-function bug.
-- Using a max-power setting of 100 rather than following the speed in the motor-commands will allow motors to run at really slow speeds.
-- As a result, motor-commands now use max-power of 100 regardless of speed and setMotorPower no longer scales according to a minimum speed of 20.
- BLE-rate enums consolidated into BoostBLE enum
