"Re-ink" paintbrush automatically while drawing for Scratch movements

[techninja]

Currently this requires some complex overhead inside of Scratch (if it's even possible). Should allow for switchable pen only mode, and changing of re-ink distance.

[oskay]

I'm not sure that this is needed. One of our Snap! examples (stars-reink.xml) does contain an example of automatic re-inking.

[oskay]

I'm not sure exactly how much is needed to do this on Scratch; I'll look into it.

[techninja]

What I worry about is "from scratch" (no pun intended) creation of Scratch projects. Without something pre-built, it's tricky to get reinking working as expected for apps.

I note this as an annoying consequence of adjusting existing Scratch projects that use drawing into something that works for the WCB. We have analog blocks for most drawing virtualizations, the only thing missing is re-inking.

[techninja]

If we decide to do this, to keep things simple, I'd recommend that on _reset, re-ink would default to off, then a user would invoke at the start of their run procedure, something like an "Enable re-ink at: [distance]" which would then go to the last used paint/water.

The problem of course becomes, how does one define what a re-ink is? Should we just say that a dip and then a wiggle in the last color is enough for common use case coverage and be done with it?

Or should we allow for more configuration in the re-ink init?

[oskay]

I have had some requests for putting less automation (i.e., more control) in the re-inking process. For example, one might want to get a lot of yellow paint on the brush, and then just dip once in the blue, and paint from there.

[techninja]

Well.. If that's in the context for RP, this wouldn't be the place to do that. In the context of Scratch/Snap, I suspect this could be quite useful, at least in the use case of "I want to paint this single long running drawing and not run out of paint in 10 seconds". Limiting the scope of this change to only the Scratch API seems a reasonable concession, as of right now I would not be able to load the bot up with paint and write/modify any old simple shape drawing application without the worry that the paint would run out quickly for long drawings.

The Sierpinski Triangle example is a very long single pen down line drawing and would need loop catches added all over to a new subroutine to check the distance painted and get the paint requested. A CNCServer level Scratch initialized abstraction for handling this seems like a helpful, optional, and quite common problem to be solved by users who don't want to use actual pens to draw and don't use our example files as base.

[techninja]

Did we reach some kind of consensus on this one?

Stated Options:

1. Keep our current limited assumption abstraction and offload paint refill to the user application
2. Implement a "per session" manually initialized paint refill handled by cncserver, with given set of options/rules, reset to default off after /reset_all

[oskay]

It would be very nice to have an auto-reink option, but I would insist that it would "reset to default off" as you say. :)

[techninja]

I never said I was good with words... or anything for that matter ;)

And yes, I agree. Having re-ink with a pen attached can be... disastrous, at least relatively. I'll see what I can work in, would likely make it in with RP 0.9.2, though will require a re-do of Scratch and other examples in WaterColorBlocks. I have trouble imagining much else that would make sense to be added to the API, so this will likely be stable after this.

If we agree to do it, lets lock down the init options and wording (total first draft text here):

• Block says "Start auto re-ink, get [arg1] every [arg2]cm"
• arg1 options: "auto", "water[n]" (0-2), "color[n]" (0-7).
  • "Auto" would be default and assumed to go get the last thing that was used/default to water0.
• arg2 options: "default", then 1-30? Or maybe just a number entry, with 0 meaning default.

[oskay]

Is arg1 even necessary? Trying to think of cases where auto is insufficient...

[techninja]

I worry that without making it clear what is being reinked, that it might not be obvious that they're expected to actually set a color to be reinked and they would just start drawing.

Perhaps this is fairly naive thinking as any attempt to just paint requires an initial inking. Other reasons for having arg1 are for the sake of override, though about all that would do is force a particular target that might not match expectations. I agree it seem superfluous.

If only there was some kind of event/ block that CNCServer could trigger and the user could set up their own re-ink "function". That would be nice.

[techninja]

In that example then, the block text could be "Start auto re-ink: Get last color every [distance]cm"

[techninja]

I'm going to move ahead with this as is till I hear any different. Feel free and give me any updated wording/text for this as you think it up :)

[oskay]

We need to keep the text short in the blocks.

How about:

Reload Paint Every [x] cm

End Paint Reloading

[techninja]

Didn't know we were going to have an "End"/stop block. Figure that if you'd initialized it after the last reset that you still wanted it. I'll add it in there, and also be sure that you can read the status of it on the poll page (while keeping the same order of them).

[techninja]

Tested this out with the Sierpinski triangle, only adding one block for automatic reinking and it worked swimmingly! ...though I might want a smaller brush next time.

[oskay]

I have not been able to get this to work, via RoboPaint 0.9.2. I can see that it's there in the code, but it does not seem to be working for some reason.

Trying to open the location (in Firefox):

http://localhost:4242/pen.off : Loads OK http://localhost:4242/move.forward./40 : Loads OK http://localhost:4242/penstopreink : times out http://localhost:4242/penreink/40 : times out

[techninja]

D'oh! :doughnut:

Its a real bug! The command is send, but the lack of return on the new endpoints meant that the connection just hangs until it times out! Whoopsies. Quick patch incoming.

[techninja]

Sooo... after I fix the other ticket, shall we roll a 0.9.3 bugfix release?

[oskay]

That would be awesome. :)

[techninja]

Cool. Will fix #58 tonight, and after I get confirmation from you that it works as expected, I'll roll RP 0.9.3 ASAP.

[oskay]

Are there any other relatively-recent features that need to be added to https://github.com/evil-mad/WaterColorBlocks ?

In this round, we have the re-inking, and the new Wait command (which works very well!). Was there anything else that I should be testing in this set?

[techninja]

A good question! I suspect we're covered with those three (though I think "wait" is older). Check the history/blame page for the s2e.