scratchfoundation/scratch-vm
1
0
Fork 0
mirror of https://github.com/scratchfoundation/scratch-vm.git synced 2024-12-27 16:32:25 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
3293 commits 495 branches 1644 tags 1.4 GiB
Commit graph

3293 commits

This branch
This branch
All branches
Author SHA1 Message Date
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
Kevin Andersen
e24ace83a0 noticed several instances of getting especially power and direction properties from private variables instead of using the getter 2019-04-08 17:48:30 -04:00
Kevin Andersen
e986b0f4cb - changed max power setting in motor functions to be calculated with MathUtil.clamp() instead of MathUtil.wrapClamp() to avoid values rolling over! 
- 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.
 2019-04-08 13:48:10 -04:00
Christopher Willis-Ford
99f6c7b6a0 Update extension docs to reflect current implementation state 2019-04-05 16:05:42 -07:00
Christopher Willis-Ford
18f3307ed0 Use ES6 for code in extension docs 2019-04-05 15:00:09 -07:00
Christopher Willis-Ford
2a5abe028f archive (delete) "Extension translation straw cat" 2019-04-05 14:27:28 -07:00