Add a dungeon level generator, which:
1. generates an infinite sequence of rectangular rooms within the
dimensions of the level
2. removes any duplicates from that sequence
3. Generates a graph from the delaunay triangulation of the centerpoints
of those rooms
4. Generates the minimum-spanning-tree of that delaunay triangulation,
with weights given by line length in points
5. Adds back a subset (default 10-15%) of edges from the delaunay
triangulation to the graph
6. Uses the resulting graph to draw corridors between the rooms, using a
random point on the near edge of each room to pick the points of the
corridors
Make raster circle rendering use the Rasterific package instead of
attempting desperately to hand-roll it, and add a method for generating
filled circles.
Explicitly sets all local branches to all equivalent remote branches
after each update.
Branches deleted on the remote will eventually disappear when the
container is restarted.
It turns out I'm going to need multiple different OAuth clients for a
variety of reasons. This defaults to the client for tazj.in accounts,
but I use a different one in my work overlay.
Instead of splitting below and moving the target buffer into the new
split, split and move the buffer into the active window.
The other way around does (for some reason I don't fully understand)
not work because `split-window-below` may return invalid windows.
Configures edwina using `s-w` as the key prefix (in line with my other
EXWM-related commands).
An additional function is added that switches to a buffer (borrowing
the implementation from `ivy-switch-buffer`) but splitting it into a
new window instead.
Don't re-send the welcome message when loading the game if it's already
been sent. This is done by just tracking whether or not we've sent it as
a boolean in the game state, which may be a bit of a hack but should be fine
Recalculate the character's lines of sight every time we step the game,
rather than just every time the character *moves*. I had originally
thought this was a non-contiguous lines-of-sight bug - which there's a
test disproving - but it actually turned out to be that actions like
eating or attacking would step the game forward (thus moving gormlaks)
without re-calculating the positions visible to the character.
Make the setter for the atPosition lens preserve entityIDs for
already-existing entities at the position, so that when we plop
something in the same tile as the character the character's entity ID
doesn't disappear.
Add a drop command, bound to 'd', which prompts the character for an
item in their inventory, removes it from the inventory, and places it on
the ground. Along the way I had to fix a bug in the
`EntityMap.atPosition` lens, which was always appending to the existing
entities at the position on set, without removing the entities that were
already there - the rabbit hole of quickchecking the lens laws here also
lead to replacing the target of this lens with a newtype called
`VectorBag`, which ignores order (since the entitymap makes no
guarantees about order of entities at a given position).
When attacking, use either:
- the message defined on the entity raw of the wielded item, if any
- the generic attack message, if an item without an attack message is wielded
- the fists attack message, if no item is wielded
Use whatever items the character has wielded, if any, to calculate the
damage they deal when attacking. Currently this shortcuts handedness to
just use the *first* item they have equipped, which is fine since it's
currently only possible to equip something in the right hand.
Add a Wield command, which prompts for a wieldable item, if any, to take
out of the character's inventory and put in their right hand.
Eventually we should support other hands, but for now hardcoding the
right hand should be fine.
Split the character's inventory up into wielded items (in one or both
hands) and the backpack, and display wielded items when drawing the
inventory panel. Currently there's no way to actually *wield* items
though, so this is all unused/untested.
Also, add the ability for items to be "wieldable", which gives specific
descriptions for when attacking with them and also modified damage.
Implements fully static (i.e. no JavaScript!) highlighting of code
blocks when rendering Markdown.
This works by walking through the Comrak AST and replacing any code
blocks with pre-rendered HTML blocks.
Syntaxes are chosen based on the "block info", which is the string
users put after the block's opening fence. This can either be
a (case-insensitive) name of a syntax, or alternatively a file
extension associated with the desired syntax.
The theme is set to one that imitates GitHub.
This will render about pages using the Comrak renderer defined in
Cheddar.
Note that due to the way its implemented this will have one
interesting behaviour: Markdown files in the tree will *also* be
rendered as HTML.
I will need to see how that works out before deciding whether or not
to disable it.