Rather than blanket disabling http with http.enabled. I think it's still
useful to keep the option around, but hopefully make it clearer what the
ramifications are.
- Changed page background to render as one quad, instead of two halves.
- Set page background to a z-offset that is between zeroth (potentially
bold border) and subsequent background pages. Bold borders were at the
same z-offset before.
We removed the config which ran all JavaExec tasks with the given
launcher, so need to override this again.
A little abusrd that this isn't done by Gradle, but there we go.
Just saves us from having to worry about conflicts with other mods which
bundle Cobalt. This might make the transition to Jar-in-Jar easier too -
not sure yet!
Also produce an API jar - fixes#1060.
- Switch to plugins { ... } imports for Forge (FG finally supports it!)
- Use FG's new fg.component to clean up our Maven metadata instead. We
also mark JEI as optional (using Gradle's registerFeature), which
means we've no stray deps inside our POM any more.
No bearing on MC, but allows us to drop the depenedency in other
projects (CCEmuX, eval.tweaked.cc, etc...)
I'd quite like to spin the core into a separate project which doesn't
depend on MC at all, but not worth doing right now.
- Add a basic data exporter to the test mod, run via a /ccexport
command. This dumps all of CC's recipes, and the item icons needed to
display those recipes.
- Post-process our illuaminate HTML, applying several transforms:
- Apply syntax highlighting to code blocks. We previously did this
at runtime, so this shaves some bytes off the bundle.
- Convert a mc-recipe custom element into a recipe grid using
react/react-dom.
- Add a recipe to the speaker page. I'll probably clean this up in the
future (though someone else is free to too!), but it's a nice
start and proof-of-concept.
I tried so hard here to use next.js and MDX instead of rolling our own
solution again, but it's so hard to make it play well with "normal"
Markdown, which isn't explicitly written for MDX.
We now track whether a tile is enqueued or not via an atomic boolean on
the block entity itself, rather than using a hash set. This is
significantly faster (>10x).
This is mostly intended for monitors, as they're the only peripheral
likely to call TickScheduler.schedule lots of times (rather than modems,
which just invoke it when opening/closing a channel[^1])[^2]. This
change is enough to allow me to update 120 monitors each tick without
any major tearing.
[^1]: GPS does do this on each gps.locate call, so it will help there,
but modems are typically limited by other computers sending messages,
not peripheral calls themselves.
[^2]: Note that montitors implement their own change tracking, so still
only call this once per tick. But it's enough to introduce some latency!
This gives us slightly better compression, as backgrounds will often be
a single run of colours while the foreground won't be.
In practice, this is rarely an issue, as most terminals are small, but
worth doing anyway.
Just like vanilla locking, this isn't accessible in survival.
> "im retired! im retired!!", i continue to insist as i slowly shrink
> and transform into a corn cob.
- Make assertions a little more relaxed
- Increase timeouts of computer tests (again :D:).
- Log where we're up to in computer tests, to make tracking stalls a
little easier
- Rewrap everything at 80 columns. To make this tolerable I'm using
IDEA's language fragment support - hence the absurd line lengths.
- Add full stops to all comments.
- Clarify that HTTP rules are applied in-order.
