- 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.
- 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.
- Parse Co-authored-by lines too. There's several contributors (mostly
via weblate, but a few GH ones too) who weren't credited otherwise.
- Add support for git mailmap, remapping some emails to a canonnical
username. This allows us to remove some duplicates - nobody needs
both SquidDev and "Jonathan Coates."
I'm not making this file public, as it contains email addresses. This
does mean that CI builds will still contain the full list with
duplicates.
This means that if the current player is breaking a cable/wired modem,
only the part they're looking at has breaking progress. Closes#355.
A mixin is definitely not the cleanest way to do this. There's a couple
of alternatives:
- CodeChickenLib's approach of overriding the BlockRendererDispatcher
instance with a delegating subclasss. One mod doing this is fine,
several is Not Great.o
- Adding a PR to Forge: I started this, and it's definitely the ideal
solution, but any event for this would have a ton of fields and just
ended up looking super ugly.
Let's see how this goes.
- Update references to the new repo
- Use rrsync on the server, meaning make-doc.sh uploads relative to the
website root.
- Bump Gradle wrapper to 7.2. Not related to this change, but possibly
fixes running under Java 16. Possibly.
- Fix broken /cctest marker
- Correctly wait for the screenshot to be taken before continuing.
- Filter out client tests in a different place, meaning we can remove
the /cctest runall command
- Bump kotlin version
This spins up a Minecraft instance (much like we do for the server) and
instructs the client to take screenshots at particular times. We then
compare those screenshots and assert they match (modulo some small
delta).
These are still equivalent to the official mappings but also include
method names and javadoc. Yay!
A bit weird to be on versioned mappings after 8 months of MojMap :).!
It's probably the lowest traffic module :p.
Also (somewhat) improve the deprecated messages in os.loadAPI. We really
need a proper article on require and converting from os.loadAPI.
- Allow help files to use the ".md" suffix, and move changelog/whatsnew
to use them.
- When files end with ".md", the "help" program attempts to highlight
them. This involves:
- Colour code blocks with a lightGrey background.
- Replace lists to use bullet points instead of "-"/"*".
- Colours headings yellow.
The implementation of this is a bit janky because a) I wrote this and
b) we need to run this step before text wrapping, but preserve
colours and section positions over wrapping (thanks to Jack for
getting this working).
- Add section navigation to the help viewer, with left/right to move to
the next/previous section.
Closes#569
- Upgade to Gradle 7.0 and FG 5.0
- Allow running with any Java version - this now correctly compiles
Forge with the right version.
- Upload to Modrinth too. This is entirely untested, so may need some
tweaking.
I've written three or four integrations with bundled cables now over the
various versions, and I'm still not convinced this one is right. It
appears to work though, so we'll see.
We need depend on the main jar here (rather than the API jar), as
otherwise our javadoc tools fails - the API references some internal
classes which aren't on our classpath.
It might be nice to write tests for this (and CT) in the future -
goodness knows these features are fragile - but that'll require some
more gradle work which I don't want to do right now.
Closes#772
- Simplify how the turtle's inventory is processed. We now copy all
items into the player inventory, attempt to place, and then copy the
items back.
This also fixes the problem where turtle.place() wouldn't (always)
update the item which was placed.
I'm also hoping this is more "correct" in how we process drops from
entities and whatnot. Though I've not had any reports of issues, so
it's probably fine.
- Replace the "error message" string array with an actual object. It'd
be nicer all these functions returned a TurtleCommandResult, but
merging error messages from that is a little harder.
Fun facts: the test suite was actually helpful here, and caught the fact
that hoeing was broken!
- Remove the service provider code and require people to explicitly
register these. This is definitely more ugly, but easier than people
pulling in AutoService or similar!
- Add an API for registering capabilities.
- Expand the doc comments a little. Not sure how useful they'll be, but
let's see!
There's still so much work to be done on this, but it's a "good enough"
first step.
These are largely copied across from Cobalt's test suite, with some
minor tweaks. It actually exposed one bug in Cobalt, which is pretty
nice.
One interesting thing from the coroutine tests, is that Lua 5.4 (and
one assumes 5.2/5.3) doesn't allow yielding from within the error
handler of xpcall - I rather thought it might.
This doesn't add any of the PUC Lua tests yet - I got a little
distracted.
Also:
- Allow skipping "keyword" tests, in the style of busted. This is
implemented on the Java side for now.
- Fix a bug with os.date("%I", _) not being 2 characters wide.
This is definitely going to break the build (it shouldn't, but these
things always do). Anyway...
- Use the new Java toolchain support, rather than requiring the user to
install multiple Java versions.
- Bump versions of several plugins.
We're sadly stuck on Gradle <7 for now, as they drop the old
maven-publish plugin, which drops SCP support.
