- remove `raise` command
- rename `error` to `fail` - should suggest both that it is:
- recoverable - can be caught with `try`
- pure - `fail: string -> a` - so it can be used outside `cmd`
---
The problem with `raise` was that it was merely a specialized version of `error` (which was not limited to `cmd a`):
```
let raised: string -> cmd a = error in raised "ha"
```
I noticed this while making the list for #26.
On a meta-level, it also conflicts with the `raise` Haskell function we use to throw an error when a command (like `build`) fails.
This PR solves #85. It's still a little bit rough since it only shows the last entry in history with the given text.
The solution if found is making the prompt a sum type. This allow to handle reple events differently depending on which mode the repl is. I've found this more difficult to implement than expected. The main problems I've found are
- `UIState` is a huge data type. Maybe putting al repl-related stuff within the same record could improve things a little bit
- I think we can define a more complex Lenses, like `promptUpdateL` which can handle many parts of the logic. I think this is better than having a huge `handleREPLEvent` function.
All of this would imply a big refactor tough.
When grabbing entities that have `yield` property, I want to use what I obtained.
But `t <- grab` would give me "wavy water" instead of "water".
I noticed this because of our hack with known entities, which also use yield (#387).
And also enable modal view toggle using the same key.
* Unpause the game after quitting a modal with Esc
* Handle FKey event before `uiModal` event to enable toggle through Fkey
Some terminals (*e.g.* `gnome-terminal`) use the character to decide
how dark or light the color should be, rather than showing the
character itself (like *e.g.* `rxvt-unicode`). Light Shade looks OK
in terminals that display the actual character, but too dark in
terminals that use it as a brightness hint. Medium Shade seems to
look good (at least, IMO) in both.
See https://github.com/swarm-game/swarm/issues/196#issuecomment-1147298159 .
This change fixes an issue when the game is started directly using
the `-s` command line argument. The new behavior is to halt the game
when no previous menu is set.
This change slightly improves the navigation by saving
the menu position so that the user gets back to the next
tutorial or challenge after winning a game.
- Expand some entity descriptions
- Improve formatting, grammar, punctuation, wording etc. all around
- Also make big furnaces able to process copper and iron too
The `whoami` command used to be more interesting back when robot names were used to uniquely identify them. It seemed fitting to make `mirror` required for `self`, which now plays the same role. I also added a recipe for `mirror` which we lacked (`glass` + `silver`) and made a new type of `deep mine` where we can mine `gold`, `silver`, and `mithril`.
- add winning solutions to scenarios
- test the winning solutions
- fail if any robot has a `Fatal error` in its log
- timeout in X seconds (default 1)
- add a Testing scenario collection hidden without the `--cheat` flag
- add a test case for #394
- closes#388
- add command `teleport :: robot -> (int * int) -> cmd ()` requiring god capability
In challenges, it is useful to be able to check the state of some remote position.
This gets you there.
Fixes#385 . Note, we will need to update `TUTORIAL.md` since this changes what world 0 looks like, but I wanted to get some feedback before launching into updating that.
Sometimes I need a dirty and direct way to get the n-th robot in the world quickly.
The name of the command is longer by design so that it does not get confused with the proposed `child` command or custom user definitions.
- part of #343
- add iron ore, iron mine and iron vein (closes#93)
- split gear into iron/wooden gear
- add metal drill
- add faster recipes with the metal drill
- add compass (closes#341)
- handle multiple entities providing the same capability
- try to find if the robot has at least one entity providing the capability
- when no entity could provide the capability rejects it too
- list required devices in the `Incapable` error (closes#342)
Seed resolution used to happen in `loadScenarioFile`, but that was the
wrong place. Resolution now happens in `playScenario`. This means that, e.g. if you
select "New Game > Classic" from the menu, then quit back to the menu, then start
a second new game, you will get a different random world each time.
Fixes#369.
Recipes can now optionally have a `weight` (with a default weight of
1). Any time multiple recipes match the criteria by which we are
selecting a recipe, one of the recipes will be chosen randomly, with
probability proportional to its weight.
As a simple example, drilling a boulder now produces 3 rocks with
probability 3/4 and 4 rocks with probability 1/4.
The ultimate purpose of this is to support some things I would like to propose in relation to mines, iron, etc. but it seems like a useful/interesting feature on its own.
