Previously illumainate required manual users to manually download it and
place it in ./bin/. This is both inconvenient for the user, and makes it
hard to ensure people are running the "right" version.
We now provide a small Gradle plugin which registers illuaminate as a
ependency, downloading the appropriate (now versioned!) file. This also
theoretically supports Macs, though I don't have access to one to test
this.
This enables the following changes:
- The Lua lint script has been converted to a Gradle task (./gradle
lintLua).
- illuaminateDocs now uses a task definition with an explicit output
directory. We can now consume this output as an input to another
task, and get a task dependency implicitly.
- Move the pre-commit config into the root of the tree. We can now use
the default GitHub action to run our hooks.
- Simplify CONTRIBUTING.md a little bit. Hopefully it's less
intimidating now.
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.
- 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.
