oh c'mon, why st dont just add this stuff
its not even hard to implement, they did the same thing with variables

(ツ) // one unicode character kumquat guard

RobloxianMinecraft wrote:

oh c'mon, why st dont just add this stuff
its not even hard to implement, they did the same thing with variables

lol, not to be rude, but are you a web designer? Some stuff seems pretty simple, but Engineering has to make everything “scaleable”, that is, it has to work on basically every device, every obscure browser, every OS, every version (to an extent). The last thing they want is a “simple” feature breaking Scratch for schools lol.

-effortIess- wrote:

lol, not to be rude, but are you a web designer? Some stuff seems pretty simple, but Engineering has to make everything “scaleable”, that is, it has to work on basically every device, every obscure browser, every OS, every version (to an extent). The last thing they want is a “simple” feature breaking Scratch for schools lol.

Development is hard; they have finite time, their projects need a well-defined scope, a lot more is involved than most people might think, they have a big website to take care of, tasks need to be prioritized, everything needs to be maintained forever, and they need to do ALL of this while keeping the site running.

<0-0::sensing>//This is Charles; he protects my signature from evil kumquats.
when I'm spawned::events hat//This is the code Charles' brain runs on.
forever
if <[100] > (distance to [an evil kumquat v])> then
delete the evil kumquat::control
end
end

EDawg2011 wrote:

-effortIess- wrote:

lol, not to be rude, but are you a web designer? Some stuff seems pretty simple, but Engineering has to make everything “scaleable”, that is, it has to work on basically every device, every obscure browser, every OS, every version (to an extent). The last thing they want is a “simple” feature breaking Scratch for schools lol.

Development is hard; they have finite time, their projects need a well-defined scope, a lot more is involved than most people might think, they have a big website to take care of, tasks need to be prioritized, everything needs to be maintained forever, and they need to do ALL of this while keeping the site running.

Not to mention that they are a PoOr NoNpRoFiT with nO mOnEy /j

~ bump ~

One of the problems I have with my program is that I need to create clones of sprites.. Each sprite has quite complex AI, but because of all the code in the sprite the cloning process is slow (~0.5s per sprite now, and only going to get worse) Of course, if I want 20 clones, that means a ten second or more wait while the level / game starts.

If I could, say, put global blocks into the stage, which take parameters, and they run independently (threaded) so that they're multi-access from sprites concurrently without globbing over shared variables, I could reduce the code within my sprites and shorten the clone time. Perhaps just make stage functions callable from sprites on that stage. They can access global variables etc, but any parameters that are passed in are called-by-value, as they are with normal blocks

I imagine it would be possible to just add more “dummy” parameters to the block and leave them blank in order to have local variables. A nicer way would be to have a third parameter type (local variables) which don't show up in the block template when you try to call it, but which are assignable within the block.. Which means, of course, allowing the set() to access local parameters, which it doesn't at the moment….