Add print + erase commands, and a challenge scenario showing off print

[byorgey]

This PR is a complement/follow-up to #2224 .

• Add a new print : Text -> Cmd Text command which consumes a paper entity and produces an entity named paper: <text> where <text> is the given text to be printed on the paper
• Add an erase : Text -> Cmd Unit command which takes a printed-on paper entity and erases it back to a plain paper
• Add a challenge scenario necessitating the use of print

Especially eager to hear feedback from anyone who wants to try solving the new scenario!

./scripts/play.sh --scenario data/scenarios/Challenges/telephone.yaml

[kostmo]

Especially eager to hear feedback from anyone who wants to try solving the new scenario!

Am not sure how to obtain the water to make the paper, since I can't wade into the water to grab it.

[byorgey]

Am not sure how to obtain the water to make the paper

@kostmo maybe you need to refresh yourself with Tutorials/require.yaml 😄

[kostmo]

[kostmo]

Again, I've abstained from peeking at the solution, but now I'm stuck on how to give the paper to the shuttle robot. I lack copper or iron to craft a grabber.

[byorgey]

Again, I've abstained from peeking at the solution, but now I'm stuck on how to give the paper to the shuttle robot. I lack copper or iron to craft a grabber.

Ah, you're not supposed to give it, just drop it at the terminal (in the center of the square at the end of the track) and it will pick it up. I'll try to change the description to make this more clear.

[kostmo]

Nice challenge. Here's my solution.

[kostmo]

It seems fragile in some way to use an "in-band" indicator for erasability and printability, in that it must be inferred by the entity's name. Perhaps instead we want to define a "printable" property? Then we could have different printable entities like "papyrus", "clay", "whiteboard". Each of them can still be subject to the name transformation with the colon. A property called "printable" would be inherent to the "unmarked" entity, whereas the property called "erasable" would be dynamically set once the entity undergoes a "print".

[byorgey]

Oh, that's a nice idea. Let me play with that.

[byorgey]

@kostmo What do you think? I decided to just go with a single property printable that determines whether something can be both printed and erased. Having a separate property erasable didn't seem to make sense to me since it's not something that would make sense to set on base entities, and the only reason to erase something is that you previously printed on it.

[byorgey]

I guess this does mean that you can still print on something that has been previously printed on, like this:

> print "paper" "3"
it0 : Text = "paper: 3"
> print "paper: 3" "7"
it1 : Text = "paper: 3: 7"

That's a bit strange, perhaps, but I don't think it's really a problem.

[kostmo]

Added a few suggestions

[byorgey]

@kostmo thanks! Also, I saw you asked why we had to redefine mountain but then removed it. Presumably you figured out that it was to make the mountains get drawn on top of the shuttle, so it looks like it's going through a tunnel. However, I wondered about the opaque property. Currently it only affects the scout command, but I wonder about making opaque also imply that the entity should be drawn with a higher priority than robots? But perhaps having opaque mean several different things is just asking for trouble.

[kostmo]

but I wonder about making opaque also imply that the entity should be drawn with a higher priority than robots? But perhaps having opaque mean several different things is just asking for trouble.

I would be in favor of having the opaque property affect the display. It is consistent with the physical interpretation w.r.t. the scout command.