There's no longer an Egyptian fireball in the sky, so I can go back to
normal.
Change-Id: I6fdcd12f3d3e62c367115f3712cc0fd36eeff78d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3568
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
For now mblog only contains the mnote-html executable which takes a mime
message from a maildir and prints the equivalent HTML fragment to
stdout. It is intended to work with the mblaze(7) utilities,
i. e. mnote-html resolves all `object` tags to proper `img` inclusions
with the correct filename, so mshow(1)'s -x version can supply the
needed image files. A note created using Apple's Notes app (tested with
the iOS version) can be converted in a viewable HTML file like this:
$ mnote-html path/to/msg > fragment.html
$ mshow -x path/to/msg
$ cat <(echo "<!DOCTYPE html>") fragment.html > document.html
$ xdg-open document.html
Note that only the limited feature set of Apple Notes when using the
IMAP backend is supported. The iCloud-based one has more (quite neat)
features, but its notes can only accessed via an internal API as far as
I know.
This CLI is a bit impractical due to the big startup overhead of loading
the lisp image. mblog should be become a fully fletched static site
generator in the future, but this is a good starting point and providing
the mnote-html tool is certainly useful.
Change-Id: Iee6d1558e939b932da1e70ca2d2ae75638d855df
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3271
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
This is mostly to yet another silly idea which turns out to be
possible. This may be actually useful should I implement more
sophisticated format specifiers like "%xd" or "%f".
Change-Id: Ia56cd6f5793a09fe5e19c91a8e8f9098f3244d57
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3537
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
hpack is a bit dumb when generating the list of modules for a cabal
file's component if multiple of them live in the same directory.
Specifically it seems to assume that all modules in the source-dirs
of a particular component are also necessary for its compilation.
This is quite bad in the case of xanthous since both library and
executable have source-dirs: src, so all modules will be compiled
twice: Once for the library and then again for the executable
despite it depending on the library (actually 4 times in total
since we need to build a unprofiled and profiled object for each
module…).
To fix this we just move Main.hs into its own directory and change
the executable's source-dirs, so hpack doesn't get confused anymore.
Since all components now have their own source-dirs, unnecessary
redundant compilation should be down to 0. The diff of the cabal
file shows quite nicely how many module recompilation we've gotten
rid of.
Change-Id: I2df4fab9b0299b3a2b5d3005508c79b2d9796039
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3533
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: grfn <grfn@gws.fyi>
Since //web/bubblegum depends on nint, we need to move it to a non user
directory to conform with the policy established via cl/3434.
Note that this likely doesn't mean greater stability (which isn't
really implied in depot anyways), since I still would like to use a more
elaborate calling convention to allow for additional useful features.
Change-Id: I616f905d8df13e3363674aab69a797b0d39fdd79
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3506
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
This allows me to add stuff without doing a commit for every feed. I can
always import them in bunches if I want to later.
Change-Id: I080f40b3627940a1f68cf13598c102953f4994b1
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3505
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
`config.home.homeDirectory` is never set, meaning that when this builds
in CI it just uses the $HOME of the buildkite agent that's running,
causing it to almost always rebuild on new changes - I'm never going to
have a username on a system other than `grfn`, so this is fine to just
hardcode.
Change-Id: I920a0c546f4c06d0429534d116465e8f732218e7
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3495
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Reviewed-by: tazjin <mail@tazj.in>
I have some secret stuff here (not security-secret, just secret that I'm
installing it in my system) so this has to be conditionally included
Change-Id: Idb12e5bbab507ad3dc5eb610199fd384789c0e20
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3491
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
The backported fix is no longer required and we can just apply the
patch in the overlay, this makes everything a little easier.
Change-Id: I654a1bb002eef5c578b8e576e133a159bde3f850
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3483
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
This lets us benefit from the recent OpenSSL security-related
update [1]. Since nixos-unstable is still stuck, we temporarily
use nixos-unstable-small as our unstable channel.
Fixes necessary:
* //users/sterni/nix/char:
Someone has decided to drop writers.writeC upstream [2],
so we reimplement it ad-hoc using runCommandCC
[1]: https://www.openssl.org/news/secadv/20210824.txt
[2]: 982f46985e
Change-Id: Id84756e2e370296b7a27e1a3f1744f58f8fe3c47
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3463
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
Unfortunately this doesn't work with Gerrit yet, but it's fine for SSH auth.
Change-Id: Idcfebb117ca39e47ef5595f5bb64ea31dbef3af7
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3442
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
I no longer use this, I just use the rebuild-system that all nixos
systems get now.
Change-Id: I2272ff13b21b3194c06b51dbc340c19b8bb336a9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3430
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
It's now more like my personal homepage depends on TVL assets, not the
other way around.
Change-Id: Ifb9d61aa8ec2cab549e25de3a3dfbbd08f3d336c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3435
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Prevent flycheck-next-error and flycheck-prev-error from being repeated
by evil, since they're movement commands rather than editing commands.
This lets me spam `]e.` if I have to do the same thing to all the errors
in a buffer, for example.
Change-Id: I5993f6d19b71b63e5f4be1f3ce9e0cfd0357cc6e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3425
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
This was missing a path segment, plus calling it rust-analyzer makes it
clearer what's going on
Change-Id: I8f71fe1b438d72f743472ab10ec939f686ad0da1
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3424
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Adds ECL as a second supported implementation, specifically a statically
linked ECL. This is interesting because we can create statically linked
binaries, but has a few drawbacks which doesn't make it generally
useful:
* Loading things is very slow: The statically linked ECL only has byte
compilation available, so when we do load things or use the REPL it is
significantly worse than with e. g. SBCL.
* We can't load shared objects via the FFI since ECL's dffi is not
available when linked statically. This means that as it stands, we
can't build a statically linked //web/panettone for example.
Since ECL is quite slow anyways, I think these drawbacks are worth it
since the biggest reason for using ECL would be to get a statically
linked binary. If we change our minds, it shouldn't be too hard to
provide ecl-static and ecl-dynamic as separate implementations.
ECL is LGPL and some libraries it uses as part of its runtime are as
well. I've outlined in the ecl-static overlay why this should be of no
concern in the context of depot even though we are statically linking.
Currently everything is building except projects that are using cffi to
load shared libaries which have gotten an appropriate
`badImplementations` entry. To get the rest building the following
changes were made:
* Anywhere a dependency on UIOP is expressed as `bundled "uiop"` we now
use `bundled "asdf"` for all implementations except SBCL. From my
testing, SBCL seems to be the only implementation to support using
`(require 'uiop)` to only load the UIOP package. Where both a
dependency on ASDF and UIOP exists, we just delete the UIOP one.
`(require 'asdf)` always causes UIOP to be available.
* Where appropriate only conditionally compile SBCL-specific code and
if any build the corresponding files for ECL.
* //lisp/klatre: Use the standard condition parse-error for all
implementations except SBCL in try-parse-integer.
* //3p/lisp/ironclad: disable SBCL assembly optimization hack for all
other platforms as it may interfere with compilation.
* //3p/lisp/trivial-mimes: prevent call to asdf function by substituting
it out of the source since it always errors out in ECL and we hardcode
the correct path elsewhere anyways.
As it stands ECL still suffers from a very weird problem which happens
when compiling postmodern and moptilities:
https://gitlab.com/embeddable-common-lisp/ecl/-/issues/651
Change-Id: I0285924f92ac154126b4c42145073c3fb33702ed
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3297
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: eta <tvl@eta.st>
This has been folded into dash itself.
Change-Id: I19e7a9fbc4d6206e3624b7c226de2225153689c6
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3407
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
Lets trust that the Emacs overlay is using the right packages from the
right sources by default. I'm not overly attached to any specific
versions.
Change-Id: Id53a4587f680965f13b5cd329a10f0384ff97c13
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3406
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
The channel has caught up with this fix.
Change-Id: I86287a6808e6936e50e5d43cbafc74b9362e0bd8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3404
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Wanted to port my emacs config to depot, but missing a dependency from
the channel. Adjustments:
* Downgrade grfn's Kernel to 5.10: The ck1 patch is not yet available
for 5.13 unfortunately and the 5.12 set has been removed upstream.
Change-Id: Ifaf315427bda2af590549ca0abec02a79f19a3ec
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3375
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: grfn <grfn@gws.fyi>
Someone asked for this, so here it is.
Change-Id: I00c52deb8c3f4e8f786cf4763b39d862ad041f6d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3371
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Telega keeps getting loaded with old sources, the origin of which I
can not figure out, and which are not compatible with my Emacs
anymore. This means that opening Telega essentially breaks the active
Emacs until the telega process is killed.
Until I have time to properly sit down and debug where Nix decides to
get an old version of telega from (building the package directly from
a Nix REPL yields the expected one), I'll disable it to avoid
accidentally breaking my Emacs via muscle-memory.
Change-Id: I937ac3a2b208c08fa0ef0b6e3e201526baa3a522
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3367
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
This stops it from interfering with command line invocations of things
like cargo test
Change-Id: Icc24a27ac5e17bb88ed539c13fc33204ef55ce82
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3288
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
The latest Emacs versions removed some (private) functions that telega
depends on, and this is fixed in HEAD of telega.el.
However, without these fixes, the unstable version of telega doesn't
build because the patch Nix tries to apply doesn't match the source
anymore.
The patch itself doesn't seem to do anything relevant for me.
Change-Id: Ib9a042c636cb438b2b15d231a07afd5c02be72ee
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3294
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
I used //tools/depot-nixpkgs-update for this - thanks again, sterni!
Included fixes:
* temporary workaround for building notmuch python package, fixed in
upstream already (but channel hasn't advanced there)
* Disable fprintd in grfn.system.yeren, as the fprintd-tod package
currently has a version mismatch in nixpkgs
Co-authored-by: Griffin Smith <grfn@gws.fyi>
Change-Id: If6d71b08ace9db57daadfe3b69b9cd4aec6a5a4e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3274
Reviewed-by: grfn <grfn@gws.fyi>
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
... for the rare cases where I am watching a movie on this laptop.
Change-Id: I9f6a5a4079b32a67d46e744c024c2accf09b3d6d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3273
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
This is required for launching desktop applications from XDG shortcuts
via counsel.
Change-Id: I147fb0d6568e359c23655230b2a56214715827f6
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3267
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
The old one's displaying as an emoji, upsettingly
Change-Id: I50980e4b9f2a58463e749a8adcc32f0f9ca1d154
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3261
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Didn't bother to update the stable channel as it is unused currently.
Changes required:
* tazjin/frog, grfn/modules/obs:
Remove obs-v4l2sink as it has been integrated into upstream OBS and
the package removed from nixpkgs subsequently (at least according to
the `builtins.throw`-message).
Change-Id: I4335ed060eef2c4ff8ac55a68d894bcc3d8ef4a3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3243
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Reviewed-by: tazjin <mail@tazj.in>
Telegram adds this itself, which means the file is different from what
home-manager knows about, which means running home-manager switch
breaks unless this is here.
Change-Id: Iad507bf63365a630b7eef349228b633f5b83d78b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3251
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
I don't know why this is causing issues, I really don't. But I get
agenda items without having to reload this file now.
Change-Id: I38fd4f7942430a07231cadbc0320e1ba786616e6
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3249
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Yes, this is a fix.
Change-Id: Ie80dc0f60c6343388388fba3327816d8a1b0fbe0
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3244
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Very worried about this, Lenovo has a knack for bricking devices with
firmware updates ...
Change-Id: Idc111fe9d4bd7edf1e6c633040cf35e82f858724
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3224
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
These end up being things like "hey, you used a proc macro" which isn't
useful to me, and clogs up the rest of my error navigation.
Change-Id: I9ccfddcce9683184f2479ae1aa30a8414f7e7c51
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3242
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Previously this'd display `5 m m³`, because it'd show the underlying
value then add the unit suffix on at the end
Change-Id: Idd240ddfebc212460f9fb529eff72732a5dafe2a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3241
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
If org-tracker-headlines-from-search is called non-interactively, it
only *returns* the org headlines as a string, rather than inputting them
at point.
Change-Id: Ia43d516f35a11383b206a57f345a6aeedfe86831
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3230
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Previously, we were using `smallestNotIn` for selecting new characters
for menu items with duplicate chatacters - this uses the 'Bounded'
instance for the type, which for Char meant the first character we would
always select was \NUL - making it look like the menu item had no
character, and making it impossible to actually select the menu item.
This introduces an AlphaChar newtype, which is a wrapper around Char
whose Bounded and Enum instances only use alphabetic characters (a-ZA-Z)
and uses that for menu characters instead.
Change-Id: If34ed9e9ce84f2bcb1cb87432cc6273f40b69f72
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3229
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
When describing items in the inventory, both in detail and when
producing menus from those items, describe not just the item itself but
also *where* in the inventory the item is (either in the backpack, or
wielded in either or both of the hands). This uses a new
InventoryPosition datatype, and a method to get a list of items in the
inventory associated with their inventory position. When *removing*
items from the inventory (to wield, drop, or eat them), we want to make
sure we remove from the right position, so this also introduces
a `removeItemAtPosition` method to make that happen correctly.
Finally, some of the tests for this stuff was getting really slow - I
narrowed this down to runaway arbitrary generation for message
Templates, so I've tweaked the Arbitrary instance for that type to
generate smaller values.
Change-Id: I24e9948adae24b0ca9bf13955602108ca9079dcc
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3228
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Add a new DescribeInventory command, bound to I, to prompt for an item
in the inventory (anywhere in the inventory, including wielded) and
display a (new) panel describing it in detail. This description includes
the description, the long description, and the item's physical
properties (volume, density, and weight).
Change-Id: Idc1a05ab16b4514728d42aa6b520f93bea807c07
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3227
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Generate random volumes and densities for items based on the ranges for
those two quantities in the raw when building instances of items.
Since this is the first time creating an item is impure, this also lifts
entity generation into a (random) monadic context
Change-Id: I2de4880e8144f7ff9e1304eb32806ed1d7affa18
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3226
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Allow the itemType raw to have density and volume fields, both of which
represent *intervals* of both density and volume (because both can
hypothetically vary a bit). The idea here is that when we're making
an *instance* of one of these items, we pick a random value in the
range.
Lots of stuff in this commit is datatype and typeclass instances to
support things like intervals being fields on datatypes that get
serialized to saved games - including a manual definition of Ord for
Item since Ord isn't well-defined for intervals
Change-Id: Ia088f2f75cdce9d00560297e5c269e3310b85bc3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3225
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
2000 ticks after the character damages their fists by hitting something,
the character now develops calluses on their fists (scaled by *how*
damaged they've become) that reduce the chance of them receiving
additional damage from hitting things - up to a max of 5, which
prevents *all* damage from fistfighting.
This is all tracked in a new "Knuckles" struct in a new "Body" struct on
the character datatype, which manages stepping itself forward as part of
the Brain impl on the character.
Change-Id: Ica269f16fb340fb25900d2c77fbad32f10c00be2
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3222
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Add a command that automatically rests (essentially just stepping the
game forwards) until the character's hitpoints are back to full.
Currently due to the time it takes for the character to heal this takes
a bit too long - my thought there is to make the per-step delay for
autocommands different depending on the specific autocommand.
Change-Id: I40378c29d3d9d19e9787af1f015bde65fd08868c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3221
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Allow configuring the natural attacks (eg, part of their body rather
than an item) of a creature. Each attack has a description and a damage
associated with it.
Change-Id: I69698a8ac4ee2da91e4c88e419593627519522a5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3220
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
This required making sayVerb optional, as oozes don't say anything
Change-Id: I2c7f425ca26d92beef1097eda49d84f00c84c482
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3218
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
This gets us the zlib-flate command line utility, which is useful for
decompressing our zlib-compressed save files and poking around in the
JSON
Change-Id: Ia0d8259d261c4313322d68cc8409ba13f9fb570c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3217
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
If the game steps forward, entities could be moving around, so we need
to wipe the memoized character vision.
Change-Id: If6ea6a8c4bed7aefef90a0a2ab17eff0af9b9bbe
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3215
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
I'm typesetting a type system! `semantic` is the big winner here, but
also `mathpartir` is nice
Change-Id: I27ee91d30e0fe680377ce48f7539553fd0707684
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3212
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
This is how I'm writing test files for xanthous now, and I'm not writing
any other haskell code, so let's update the snippet
Change-Id: Ia513490ee1cfc87b3d58ee1a8e94244f2e862963
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3208
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Add a new "greetedCharacter" field to the creature hippocampus type,
which tracks whether or not that creature has greeted the character
yet. In the gormlak AI, when the gormlak sees the character and starts
running towards them, if that field is set to False send a message that
says that the gormlak yells a single randomly-generated gormlak word at
the character, then set the field to true
The gormlak yells "gukblom"!
Change-Id: I17a388393693a322c2e09390884ed718911b2fc4
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3207
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
I didn't end up using this directly for the thing I was doing, but it
still seems generally useful enough that I'm keeping it around for now
Change-Id: I05c8902d75845f2230ec2373a9677d61cfaafafd
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3206
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Add a new "language" field to the CreatureType raw type, which
references the *name* of the language that creature speaks (this is so
that different creatures can speak the same language without having to
duplicate the language definition in the raws). At some point this
should change to not hardcode the sets of languages and instead define
them in data files like we do for creatures, but this is fine as a
start.
Change-Id: I6708570175e23472cb37e0061a329e54e8eac9c0
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3205
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
This is generally just good practice for foundational data-types like
these
Change-Id: I88c5b6b73dad6665cf25837b8d6a9e0ea66f2b0b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3204
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Wrap up the Phonotactics type into a Language type including both the
phonotactics and a distribution of the number of syllables per word, so
we can generate arbitrary words in addition to just arbitrary syllables
Change-Id: I8a37ce9c0eec019c9b84d21b0f2b3b9f5fd319eb
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3203
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Add a new "speech" generator module, with the beginnings of the vague
definition of the phonotactics of the language (there's one in here for
English based on the wikipedia article for English phonology, but it's
less than ideal as it has generated words like "sprurlkt") and the
ability to generate random syllables of a language by picking an onset,
nucleus, and coda from the list for that language (within a range of the
number of allowed of each syllable part). This will be used down the
road to automatically generate utterances from various
non-english-speaking creatures (so the accuracy is less important, just
that it "feels real").
Change-Id: I7b81375ec595239c05c5c800cbde1a2a900e38ac
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3202
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
I'm going to start adding generators for things like text soon, so it
makes sense to specifically sequester level generators as their own
thing
Change-Id: I175025375204fab7d75eba67dd06dab9bd2939d3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3201
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Memoize the return value of characterVisiblePositions to a new,
semi-abstracted "memo" field on the GameState, recalcuclated if the
character position ever changes. I'm 90% sure that the perf issues we
were encountering were actually caused by characterVisiblePositions
getting called once for *every tile* on draw, but this slightly larger
change also makes the game perform relatively-usably again.
Since this is only recalculated if the character position changes, if we
ever get non-transparent entities moving around without the characters
influence (maybe something building or knocking down walls?) we'll have
an issue there where the vision won't be updated as a result of those
changes if they happen while the character is taking a non-moving action
- but we can cross that bridge when we come to it.
Change-Id: I3fc745ddf0014d6f164f735ad7e5080da779b92a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3185
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
