Commit graph

3298 commits

Author SHA1 Message Date
Christopher Willis-Ford
0247447792 embed extension blockInfo into block XML 2019-04-22 09:53:05 -07:00
Christopher Willis-Ford
bd1aaecdf3 add category info to extension add & update events 2019-04-19 16:06:11 -07:00
Christopher Willis-Ford
833d33355c retrieve blockInfo from args when isDynamic is set 2019-04-19 16:06:11 -07:00
Christopher Willis-Ford
3b395a10d1 add test for extension methods receiving blockInfo 2019-04-19 14:35:35 -07:00
Christopher Willis-Ford
638062e982 pass blockInfo to extension methods
Sometimes a single extension method needs to service several different
instances of the same opcode. This can happen with variables or custom
procedures, for example. This change allows the extension method to
inspect the `blockInfo` for instance data, including arbitrary
extension-specific properties if necessary.
2019-04-19 14:35:35 -07:00
Chris Willis-Ford
9135780c55
Merge pull request #2123 from cwillisf/extensions-xml-escape
use xmlEscape instead of escape-html for extensions
2019-04-18 14:38:41 -07:00
Chris Willis-Ford
26cf90228a
Merge pull request #2098 from cwillisf/extension-docs
Extension docs
2019-04-18 09:21:49 -07:00
Eric Rosenbaum
2b32b265a1
Merge pull request #2071 from ericrosenbaum/bugfix/stub-timer-for-test
Stub timer to fix flaky test
2019-04-18 11:29:36 -04:00
Christopher Willis-Ford
a308b1e02f use xmlEscape instead of escape-html for extensions 2019-04-17 16:48:58 -07:00
Karishma Chadha
cc75154f9a
Merge pull request #2122 from LLK/revert-1930-runtime-script-cache
Revert "Cache hat block information for the runtime"
2019-04-17 16:06:49 -04:00
Karishma Chadha
23136ad9c3
Revert "Cache hat block information for the runtime" 2019-04-17 16:05:24 -04:00
Karishma Chadha
a984d1ae9d
Merge pull request #1930 from mzgoddard/runtime-script-cache
Cache hat block information for the runtime
2019-04-17 15:55:47 -04:00
Christopher Willis-Ford
519a37bb00 add require lines for arg/block types in getInfo intro snippet 2019-04-16 14:13:49 -07:00
Eric Rosenbaum
ddd5bb2d7b
Merge pull request #2119 from ericrosenbaum/bugfix/boost-color-sensing-fixes
BOOST color sensing fixes
2019-04-16 15:44:13 -04:00
Eric Rosenbaum
8dc4832100 Reorganize color ids and indices 2019-04-16 15:24:39 -04:00
Katie Broida
eedc0b16e0
Merge pull request #2041 from ktbee/use-empty-bitmap-size
Set height and width to zero for the canvas and costume size if bitmap's sourceHeight or sourceWidth are zero
2019-04-16 14:50:42 -04:00
Kevin Nørby Andersen
1c8dfea382
Merge pull request #2115 from knandersen/bugfix/2108
Fix #2108 by making setMotorPower() and setMotorDirection() yield for a tick
2019-04-15 18:41:28 -04:00
Kevin Nørby Andersen
8504d077c5
Merge pull request #2111 from knandersen/bugfix/2103
Fix #2103 and #2110 by clearly defining motor state and how it's modified
2019-04-15 18:41:03 -04:00
Eric Rosenbaum
07768652f9 clean up whencolor is seeingcolor functions 2019-04-15 11:34:02 -04:00
Eric Rosenbaum
1381d2c4c0 Add boolean “seeing color brick?” 2019-04-15 09:59:03 -04:00
Eric Rosenbaum
bd5bc7947b rename hat to “when color brick seen” 2019-04-15 09:58:44 -04:00
Eric Rosenbaum
0cadf685b2 Remove color reporter 2019-04-12 17:14:34 -04:00
Eric Rosenbaum
d77944beff Clean up detection of color any 2019-04-12 17:09:10 -04:00
Eric Rosenbaum
c25b84d510 Clean up color sensing using IDs 2019-04-12 16:56:09 -04:00
Kevin Andersen
6611abec9e Makes setMotorPower() and setMotorDirection() yield for a tick 2019-04-12 14:12:43 -04:00
Kevin Andersen
12e969119a Simplified the return value for when power is 0 in motorOnForRotation() 2019-04-12 14:07:26 -04:00
Kevin Andersen
a98f3af2e1 Added a special case in motorOnForRotation() to avoid hanging blocks if power is 0 2019-04-12 13:56:29 -04:00
Kevin Andersen
8ece9757aa changes BoostMotor.status(value) to reset all motor state 2019-04-12 12:27:54 -04:00
Kevin Andersen
3f0816bac8 This commit addresses point 1 from the discussion with @ericrosenbaum around moving the setting of motor-state into the BoostMotor-class rather than having it in the opcodes.
- 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.
2019-04-12 11:33:10 -04:00
Kevin Andersen
cd7319d044 Added state-change for Boost.stopAllMotors() 2019-04-11 14:07:07 -04:00
Kevin Andersen
c3908b5f2c removed power wrongly being set in setMotorDirection() 2019-04-11 11:16:51 -04:00
Kevin Andersen
ba2aaf90dd Corrected documentation for BoostMotor._clearRotationState() 2019-04-11 11:12:52 -04:00
Kevin Andersen
63726044e4 Major change of motor state handling to increase reliability, clear responsibility of handling state, and readability of the code.
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.
2019-04-11 10:39:56 -04:00
Eric Rosenbaum
66ff92433e
Merge pull request #2107 from ericrosenbaum/bugfix/boost-when-color
Fix BOOST whenColor hat
2019-04-10 10:30:20 -04:00
picklesrus
d182659a57
Merge pull request #2065 from picklesrus/duplicate-sprites
Fix #4573 by using an existing utitlity that re-ids blocks when we du…
2019-04-10 09:05:53 -04:00
Karishma Chadha
51ad4185d1 Update src/sprites/sprite.js
Don't use object.values because it doesn't work in old Safaris.

Co-Authored-By: picklesrus <picklesrus@users.noreply.github.com>
2019-04-10 08:55:54 -04:00
Eric Rosenbaum
c0ea5be1d3 Fix whenColor hat 2019-04-09 17:36:14 -04:00
Kevin Nørby Andersen
3d74bbd823
Merge pull request #2106 from knandersen/bugfix/2105
Fix #2105 by correctly accessing motor position from BoostMotor-class
2019-04-09 16:46:58 -04:00
Kevin Andersen
b8bbe80c4f get position from this._peripheral.motor() 2019-04-09 16:20:21 -04:00
Kevin Nørby Andersen
eb66855539
Merge pull request #2101 from knandersen/bugfix/2086
Fix #2086 by resolving pending promise even when power set to 0%
2019-04-09 15:43:09 -04:00
Kevin Andersen
b2c18e9dcd BoostMotor.power(value) now sets to 0 if value is 0 rather than scaling, to ensure that blocks skip immediately if speed set to 0 2019-04-09 15:34:08 -04:00
Kevin Andersen
75fc37aa30 Fixed conflicts 2019-04-09 14:57:27 -04:00
Kevin Andersen
41873bf7bf Use the power-getter rather than accessing the property directly 2019-04-09 14:52:41 -04:00
Kevin Nørby Andersen
6e976f854e
Merge pull request #2100 from knandersen/bugfix/2089,2088,2087
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
2019-04-09 14:25:44 -04:00
Kevin Andersen
3e55841011 Resolves #2087 and #2088. Because we weren't clearing a motor's _pendingPromiseFunction after executing it, it kept lingering, which made setMotorPower() and setMotorDirection() trigger a rotation-based command even if was responding to a timed or forever motorcommand. By clearing the property every time we fire the function, and by using pendingPromiseFunction as the conditional in setMotorPower() and setMotorDirection(), this should be taken care of. 2019-04-09 11:45:42 -04:00
Kevin Andersen
7b917cabb4 Added isBusy-flag in onMessage to make sure promises aren't resolved if the motor is still busy. Added check in motorOnForRotation() that ensure that any previous pendingPromiseFunction() is resolved before creating a new one, to avoid hanging blocks 2019-04-09 09:30:26 -04:00
Kevin Andersen
19e6a1d4c9 Merge branch 'develop' of https://github.com/LLK/scratch-vm into bugfix/2089,2088,2087 2019-04-09 08:51:28 -04:00
Kevin Andersen
c664fca9d7 changed getMotorPosition() to use the Boost.motor()-function instead of accessing the _motors-property directly 2019-04-09 08:47:00 -04:00
Kevin Nørby Andersen
03b4d0e582
Merge pull request #2099 from knandersen/bugfix/2085
Fix #2085 by handling discarded hub commands
2019-04-08 19:27:32 -04:00
Kevin Andersen
ecbbacd4c0 It seems like there's a tradeoff between how we choose to set the max power of the motors. Previously, I had set the motors' max power (torque) to follow their target speed, meaning they accelerated smoothly, but also lost their torque. Then in the following commit I changed the max power to 100 which means maximum torque to achieve the target speed, which resulted in very abrupt accelerations and erratic motor movement when changing speeds:
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.
2019-04-08 17:56:54 -04:00