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.
- Sand is now found near water. Sand regenerates immediately (like water).
- Sand can be used in a furnace to make glass.
- Glass + copper wires + 3D printer can be used to make solar panels.
- Note that with #361 I intend to start the base with a small number of 3D printers, so other robots could carry this out. But also, the base will start with a bunch of solar panels too.
- Solar panel + counter can be used to make a calculator.
* add robotNamed : string -> cmd robot
* add chess knight challenge
In challenges, it's impossible to access the robot
by its assigned number. We do however name it.
Seems reasonable to add a way to get robot by its name.
* Fix doctests
* Regenerate haskell-ci with config
- use latest haskell-ci
- configure haskell-ci to use doctest
* Update tested with compiler
- update cabal tested-with field
- update .mergify.yaml to new compiler
- restore note about mergify in haskell-ci
Generalize challenges + various modes to all be "scenarios" which are described by `.yaml` files in `data/scenarios`.
- Both challenges and classic/creative modes are now subsumed under the more general notion of "scenarios".
- A scenario describes how to set up the world etc. when starting a game; all scenarios are stored in a `.yaml` file in `data/scenarios`.
- "New game" menu item now lets the user choose a scenario.
- Some small improvements to the way seeds are handled.
See #296. This will enable #35 and #25 .
Hitting `Enter` on an inventory item pops up a dialog box with its description. For items with longer descriptions this is a convenient way to be able to see the whole description without having to scroll the info box in the lower left.
`Enter` used to try to `make` the focused item; that is now accomplished with `m`.
Lots of refining, adding more menu options, etc. that still needs to happen, but this adds a basic menu. Quitting a game now quits to the menu rather than quitting the entire application.
I initially thought this would be tricky, but it's not: all we need to
do is reprogram the salvaged robot to give the salvaging robot one
item at a time.
Closes#202.
Closes#77 . When hitting Ctrl-Q, now a dialog box opens up allowing you to confirm you want to quit or cancel. The machinery for dealing with pop-up windows is somewhat generalized as well, which should make it easy to add other similar pop-up windows as needed in the future.
It is now impossible to destroy `base`. In `Step.hs` we now always check whether the current robot is `base` (by checking whether its `robotID` is 0) before the `selfDestruct` flag is set. If it is `base` a `CmdFailed` exception is thrown instead.
This resolves#297 .
Fixes#82.
Right now it only works in classic mode. It wouldn't be too hard to
make it work with challenge mode as well, but that would require some
more careful thinking about whether every challenge is required to
have a 'base' and how we identify which robot that is, so that we run
the given file on the right robot.
See the discussion at
https://github.com/byorgey/swarm/pull/303#discussion_r817471340 .
This seems like an unqualified success: no more hacky (-1)'s, and
doing the refactoring actually uncovered a bug! Previously, we were
not actually assigning ID's to the robots that were read as part of a
challenge. This means that in a challenge with multiple robots, all
but one of them would instantly disappear since they all shared the
same ID number.
