remove ask box

This isn't a bug report. It's a feature request, but the feature requests section was removed from the forum.
Remove the answer reporter and the ask block and add an ask reporter.
This is a good idea because there is no reason for it not to be a reporter in the first place. Why is there a special global variable, instead of users building their own variable and setting it?
It can be replaced in old projects by adding a global variable if there is any answer blocks, and replacing ask with setask and answerspecial with answer

The feature requests are in Advanced Topics.

I support this suggestion.

Well, if you want, it's possible to turn it into a custom reporter block. If you want me to do that for you, I'll do so gladly.

It's possible, I always do it. It should be primitive because there should not be random reporters that are just variables. Snap fixed much of that with first class lists. I just suggest they finish it.askreporter In case someone doesn't know how to make it.

Half support. The block should not be removed.



But why is it a command block? It would make so much more sense for it to be a reporter

it's a command block so that you don't have to set a variable to it, or you can save the answer for later, for example, untitled script pic

But there is no reason to make that function primitive. It is currently a combination of the correct ask block and a global variable. The advantage of this feature request is that, even if it is used for a variable, it can be a sprite-global variable or a local variable. Snap! doesn't have a special block called “save mousex” that sets the reporter “saved mousx” to the value of “mousex”. Snap! also doesn't have that for mousey or timer. The current solution is like requiring only useage of the save mousex and saved mousex blocks. Sure, there is a solution, but the primitive solution is what most new users will expect, and that suggests bad code, even if it doesn't enforce it.
Snap! only has the block the way it is because scratch decided that having an ask reporter was too confusing, but having it used only in variable blocks was okay. In scratch, that was mostly okay because the only other variables were sprite-global variables, and those are only slightly less bad than fully-global variables like answer. In Snap! however, there are local variables, and there is no downside (Snap! has lots of blocks that don't just save to variables) If scratch had decided that user input of this form was too complicated for their audience at all, then Snap! would still get input eventually, possibly even in the first release. It would then use the form shown here, or something like it. If scratch had decided that an ask reporter was safe for their audience, then Snap! would use that version. Scratch 3.0 may have then removed it again (their audience seems to have gone down in programming power per capita) but Snap! would have held it.
There may be an advantage to holding the scratch blocks, but at least remove it from existing projects and from snapin8r2 (and 3, when it finishes), and add the new one as primitive.

I agree (as does Jens) that an ANSWER TO (question) reporter would be better than the current arrangement. But... two things:

  1. I'd like to train everyone to stop calling niladic reporters (ones with no inputs) "variables." They're not variables; the value they report can change out from under you without you doing a SET. In this case, some other part of your code could have another ASK AND WAIT with a different question, and so the value reported by ANSWER will change. Variables are orange and can be set (only) by SET (and CHANGE, if they're numbers). This doesn't affect the merit of your suggestion, just your vocabulary. Learn to say "niladic reporter." :~)

  2. Of course the reason we have the old blocks is, as you say, that we inherited them from Scratch. There is one intellectually respectable argument for the Scratch way, namely that in general reporters only report values, without changing anything about the state of the program. Your proposed reporter will SAY the question and open a reply widget on the stage, prior to reporting a value. Also, @ego-lay_atman-bay's practical argument has pragmatic value, even if intellectually not the most aesthetically pleasing. We haven't wanted to break Scratch projects, of which there are lots more, so far, than Snap!-native ones.

We have a vague understanding that When Things Slow Down™ we'll create a Scratch compatibility library and do all the Scratch-project-breaking things at once. But lots of things are more urgent.

will that include allowing raycasters to... exist?

Instead of removing the version of "ask" that we don't like we could at least:

  1. Hide the old version
  2. Update the manual
  3. Update example and library programs

And maybe the documentation for the old version could explain it is deprecated.

This could be done for any incompatible change while maintaining backwards compatibility.

Maybe after the feature freeze...

Sorry, I don't understand what one has to do with the other.

Can you please move the topic to feature requests?


or we could just keep it the way it is and add the new one so that there's both options in the block pallet. I know I'll keep using the old version.

raycasters are currently impossible on snap. import any scratch raycaster or make your own, and you'll see that. for some reason, they run slower and only render like 10 rays until the next frame. and no, it's not my PC, nor is it browser based, and I should really be posting this under bug reports as a seperate topic, sorry, I'll continue this seperate discussion elsewhere. edit: it turns out I had already made a post about this topic, but had 0 replies and got lost with all the other posts. Raycasters not working on Snap!

I'm not an expert on raycasters, as is probably obvious by now, but Jens says that the new version of Morphic will speed up everything, so let's wait until it's in beta and then we can reopen this if it doesn't solve your problem.