- turnOn() renamed to _turnOn() and marked as a private function, i.e. it should only be called by BoostMotor-functions, not opcodes.
- New function turnOnForever() to be called by opcodes.
- turnOff() now sets the motor state.
- _clearRotationState now does a check for null rather than a truthy value
- all motor state setting removed from Boost-class and opcodes: stopAllMotors(), motorOnFor(), motorOnForRotation(), motorOn(), motorOff()
- turnOnForever(), turnOnFor() and turnOnForDegrees() now have a resetState-parameter with the default value of true. This allows the setMotorPower() and setMotorDirection()-functions to not reset state, to avoid them resolving the promises of the original motor commands that they are affecting.
BoostMotor now has a status getter/setter that replaces isOn() and is responsible for clearing various motor state parameters.
A new BoostMotorState-enum contains the possible states a motor can be in.
Since time-based motor commands really just trigger a BoostMotor.turnOn(), it's the opcodes that are responsible for setting the motor state.
Fix 2087, 2088, and 2089 by properly setting parameters in rotation-commands and not using command feedback when relying on scratch-vm for motor timing
873b56c985
In the following commit I changed the functionality so that we add a fixed amount (10) more power than the target speed, e.g. for speed 50 it would provide power 60. This is fine for high speeds, but for low speeds it provides poor torque:
e3cdbffa2a
I assume it would be possible to design some sort of calculation that enabled high torque for low speeds, and vice versa. I will discuss with the team.
- added an else-case to both setMotorDirection() and setMotorPower() so that dynamic speed/direction changes also affect the motorOn()-blocks just like the time- and rotation-based ones.
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.
There's quite a few interactions between degrees, their sign, and the currently set direction for the motor the degrees relate to. In this case, BoostMotor.turnOnDegrees() was being run with -degrees, and since that function does a Math.max between 0 and degrees, it resulted in 0 degrees.
Because of this, and for clarity, turnOnDegrees now only gets called with positive values. If running CCW, that should be specified in the direction-parameter.
Partly resolves#2087, #2088.
This was happening because scratch-vm is responsible for timed motor commands rather than using the Boost hubs commands to run motors for a specific amount of time.
This meant that when we simply sent a motorOn-command, the hub would immediately return feedback for the motor that the command had completed.
The fix for this was, for timed motor commands, to not receive feedback from the motor, and instead have scratch-vm modify the BoostMotor._status.
TODO: Fix for rotation-based commands.
Agreed. Changed to 50%.
- BoostMotorMaxPower changed to BoostMotorMaxPowerAdd and now describes an extra boost (no pun intended) to the motor. Documentation added that describes the feature.
- _colorBucket renamed to _colorSamples for clarity.
- oldColor is renamed to previousColor, and is now initialized in this._sensors.
- Modified documentation.
There are parts of the extension registration process which rely on the
`info` field being non-null, even for block separators. At one point
during development I broke that, so here's a test to hopefully prevent
someone else from getting bitten by the same thing.
These compatibility changes:
- Use runtime.currentMSecs for the Clock timer "now" value
- Start executing hats before other threads change values
- Update test and fixtures to work with earlier hat execution
- Add test for hat execution block order
