stickfiregames wrote:

I think an

ask [] until <> :: sensing

would be a useful addition.

ask [] for () secs :: sensing

would also be good, I know it can be worked around if my first block is added, but we already have both options for the wait block.

I support your first block, not the second because of the workaround.

but @TheLogFather already figured out how to do a ask for seconds

stickfiregames wrote:

I think an

ask [] until <> :: sensing

would be a useful addition.

ask [] for () secs :: sensing

would also be good, I know it can be worked around if my first block is added, but we already have both options for the wait block.

I support your first block, not the second because of the workaround.

Astickfiregames i dont think your second block is neccasary because @TheLogFire has found a way around that

Support both.

Support both; who cares about a superfluous workaround?

I support!

I'd quite like to see some way to have more control over ask-and-wait, via something like ‘stop asking’, etc. - despite the workarounds I've shown are possible.

Another ask enhancement that could be quite handy would be dynamic reporting of the answer - i.e. the value of ‘answer’ changes as the user is typing, not just once the user clicks the button or presses enter.

That would allow provision for some immediate error-checking/feedback as an answer is being given, which could be useful sometimes.

All support as workaround for 2nd is not completely trustable (what if a part of the program changes it?)

+1

Support for the first, semi-support for the second because of the workaround.

Zappy1333 wrote:

stickfiregames wrote:

I think an

ask [] until <> :: sensing

would be a useful addition.

I support this block and block 1.
No support for the second because of the simple workaround.

This, it would be useful for quizzes

I need it too! I have to stop project and run it after 0.2s only because I want to hide asking panel…

stickfiregames wrote:

I think an

ask [] until <> :: sensing

would be a useful addition.

ask [] for () secs :: sensing

would also be good, I know it can be worked around if my first block is added, but we already have both options for the wait block.

I support your first block, not the second because of the workaround.

what if they didn't have time to answer though?

EmeraldSapphire41 wrote:

stickfiregames wrote:

I think an

ask [] until <> :: sensing

would be a useful addition.

ask [] for () secs :: sensing

would also be good, I know it can be worked around if my first block is added, but we already have both options for the wait block.

I support your first block, not the second because of the workaround.

what if they didn't have time to answer though?

Either it wouldn't change the answer, or it would set it to nothing. It wouldn't really matter which as long as it was consistent.

Support for 1.
No support for 2, workaround:

set [ask in progress? v] to [1]
ask [] and wait
set [ask in progress? v] to [0]