Part of #549
Before this change, if the Classic scenario was started:
```
stack run -- --scenario data/scenarios/classic.yaml
```
and then "Start over" is selected from the Quit dialog, a new seed was generated.
Now, the previous seed is re-used.
Closes#757 . As discussed there:
- Default direction for robots whose parents have no direction is now `north`
- Fix the `scan` tutorial `base` to be facing north
- Clarify the text in the `build` tutorial to state that newly built robots face the same direction as their parent, which in the tutorial will always be north.
- Help modal now says "quit the current scenario" instead of "quit game" for Ctrl-q
- If you select "Keep playing" after completing a challenge scenario, it will now pop up a modal advising you to hit Ctrl-q whenever you're ready to move on.
- Added a note at the beginning of the tutorial reassuring that your progress will be saved and you can pick up where you left off from the menu.
- Improved quit dialog in a couple ways:
- Now warns that "your progress *on the current scenario* will be lost" (to emphasize that e.g. your progress on the entire tutorial won't be lost).
- Now says "quit to XXX menu" where XXX is the specific menu you will return to.
Closes#595. Closes#759.
- Never clear the `uiWorldCursor`.
- In practice it seemed annoying and glitchy to understand when it would or wouldn't clear. After clicking somewhere on the map to see the coordinates I was always afraid I was going to do the wrong thing and cause the cursor display to clear before I could make use of it.
- Pass on mouse clicks to the REPL input form
- This means you can click in the middle of the input to move the cursor
- Closes#470.
It is probably safer to have Template Haskell GitInfo in Main and not depend on it in Swarm modules.
Depending on how the build system and TH interact we were either recompiling too often or not often enough.
- if the git info was evaluated once and not again after making a commit, then it was not up to date
- if the git info was reevaluated on every commit then we would needlessly recompile dependent modules
I believe it was only the former, but this helps even in that case (any code change recompiles Main).
Implements #345
When Ctrl-D is received by `handleREPLEvent`, it checks if the prompt is empty (for both `CmdPrompt` and `SearchPrompt` cases). If it is empty, it calls `toggleModal`.
I'm new to Haskell in general, so if there's a better way to do this, please let me know.
- note how to install Fourmolu and run it from shell
- refactor the conventions to use subsections for easier readability
- simplify restyled arguments for Fourmolu 0.4
- adds `PolyUnit` pattern (just seemed useful?)
- persists the last type/value into the `REPLDone (Maybe (Polytype, Value))` constructor
- `value` is not needed right now, but I'm thinking about using it for #304
- I'm also considering if pretty-printing the last value in that cozy corner could also be a good idea
- notion of the "active" type (last or currently-executing) and the corresponding `Getter`: `replActiveType`
- show this active type in the REPL UI (fixes#692)
The goal is to make the move tutorial more interesting, by using multiple objectives in sequence:
- _move twice_ (the current **Moving, part 1**) teaches the `move` command
- _move six times_ (**new**) will teach about using <kbd>↑</kbd> to get previous commands in REPL and chaining with `;`
- _turn and move_ (part of the current **Moving, part 2**) teaches the `turn` command and `left`/`right`
- _repeat_ (part of the current **Moving, part 2**) will let the player enjoy reusing previous commands
The map of the next part will be revealed (🪄🧙) upon fulfilling the objective.
```
+--+
|> |
+--+
```
move seven times:
```
+--+------+
| > |
+--+------+
```
turn and move:
```
+--+
| |
+ |
| |
| |
+--+---+ +
| >|
+--+------+
```
repeat:
```
+---------+
| |
| +------+
| |
| |
| +---+--+
| ^|
+------+ |
| |
| |
+--+---+ +
| |
+--+------+
```
---
<sup>The number of moves and the shape itself is subject to change. 😉 </sup>
- when `datadir` is not available, try using the XDG data directory
This way the game can be installed as an executable and data files unpacked to `~/.local/share/swarm/data`.
Notice that the XDG data folder is `~/.local/share/swarm`; inside it is the unpacked `data`.
The alternative approach is to use the environment variable `swarm_datadir` and set that to the unpacked data folder.
That works (even after this change) but is not very beginner friendly.
Ideally, we would like to set this in Cabal when building executable, for example to `/usr/share/swarm/<version>`.
Reading through haskell/cabal#5997, it looks like that is not supported.
