I didn't make a new years resolution to stop writing build tooling, but
maybe I should have.
This replaces our use of VanillaGradle with a new project,
VanillaExtract. This offers a couple of useful features for multi-loader
dev, including Parchment and Unpick support, both of which we now use in
CC:T.
- Add support for version overrides/exclusions in our dependency check.
Sometimes mod loaders use different versions to vanilla, and we need
some way to handle that.
- Rescan wired network connections on the tick after invalidation,
rather than when invalidated.
- Convert some constant lambdas to static method references. Lambdas
don't allocate if they don't capture variables, so this has the same
performance and is a little less ugly.
- Small code-style/formatting changes.
- Add a check to ensure declared dependencies in the :core project, and
those inherited from Minecraft are the same.
- Compute the next Cobalt version, rather than specifying it manually.
- Add the gradle versions plugin (and version catalog update), and
update some versions.
Previously we prevented our published full jar depending on any of the
other projects by excluding the whole cc.tweaked jar. However, as Cobalt
also now lives in that group, this meant we were missing the Cobalt
dependency.
Rather than specifying a wildcard, we now exclude the dependencies when
adding them to the project.
Historically we've used copy-cat to provide a web-based emulator for
running example code on our documentation site. However, copy-cat is
often out-of-date with CC:T, which means example snippets fail when you
try to run them!
This commit vendors in copy-cat (or rather an updated version of it)
into CC:T itself, allowing us to ensure the emulator is always in sync
with the mod.
While the ARCHITECTURE.md documentation goes into a little bit more
detail here, the general implementation is as follows
- In project/src/main we implement the core of the emulator. This
includes a basic reimplementation of some of CC's classes to work on
the web (mostly the HTTP API and ComputerThread), and some additional
code to expose the computers to Javascript.
- This is all then compiled to Javascript using [TeaVM][1] (we actually
use a [personal fork of it][2] as there's a couple of changes I've
not upstreamed yet).
- The Javascript side then pulls in the these compiled classes (and
the CC ROM) and hooks them up to [cc-web-term][3] to display the
actual computer.
- As we're no longer pulling in copy-cat, we can simplify our bundling
system a little - we now just compile to ESM modules directly.
[1]: https://github.com/konsoletyper/teavm
[2]: https://github.com/SquidDev/teavm/tree/squid-patches
[3]: https://github.com/squiddev-cc/cc-web-term
- Move the frontend code into src/frontend
- Move our custom element SSR system into src/htmlTransform.
This is mostly in prep for merging in copy-cat's core, as that's a whole
bunch of extra code.
- Update to Loom 1.2 and FG 6.0. ForgeGradle has changed how it
generates the runXyz tasks, which makes running our tests much
harder. I've raised an issue upstream, but for now we do some nasty
poking of internals.
- Fix Sodium/Iris tests. Loom 1.1 changed how remapped configurations
are generated - we create a dummy source set and associate the
remapped configuration with that. All nasty stuff.
- Publish the common library. I'm not a fan of this, but given how much
internals I'm poking elsewhere, should probably get off my high
horse.
- Add renderdoc support to the client gametests, enabled with
-Prenderdoc.
- Fix several inaccuracies with several files not marking Dan's
authorship. Most of these are new files, where the code was moved from
somewhere else:
- In the public API: IDynamicLuaObject, ILuaAPI, TaskCallbakc,
IDynamicPeripheral, UpgradeBase
- In the ROM: fs, http, require
- Do not mark Dan as an author for entirely new code. This affects
DetailHelpers, DropConsumer, FluidData, InventoryMethods, ItemDetails,
MonitorRenderState, NoTermComputerScreen, Palette, PlatformHelperImpl,
UploadFileMessage, the Terminal tests, and any speaker-related files.
- Relicence many files under the MPL where we have permission to do
so. See #1339 for further details.
Thank you to everyone who has contributed so far! Cannot overstate how
appreciated it is <3.
This adds SPDX license headers to all source code files, following the
REUSE[1] specification. This does not include any asset files (such as
generated JSON files, or textures). While REUSE does support doing so
with ".license" files, for now we define these licences using the
.reuse/dep5 file.
[1]: https://reuse.software/
Just ran[^1] over the codebase. Turns out we'd duplicated one of the
changelog entries entirely - I suspect due to a version merge gone
wrong!
[^1]: https://github.com/crate-ci/typos/
- Ensure they're correctly synced to the client. This definitely isn't
comprehensive, but doing anything further probably involves multiple
players, which is tricky.
- Quick rendering test for in-hand computers.
- Add a new ClientJavaExec Gradle task, which is used for client-side
tests. This:
- Copies the exec spec from another JavaExec task.
- Sets some additional system properties to configure on gametest framework.
- Runs Java inside an X framebuffer (when available), meaning we
don't need to spin up a new window.
We also configure this task so that only one instance can run at
once, meaning we don't spawn multiple MC windows at once!
- Port our 1.16 client test framework to 1.19. This is mostly the same
as before, but screenshots no longer do a golden test: they /just/
write to a folder. Screenshots are compared manually afterwards.
This is still pretty brittle, and there's a lot of sleeps scattered
around in the code. It's not clear how well this will play on CI.
- Roll our own game test loader, rather than relying on the mod loader
to do it for us. This ensures that loading is consistent between
platforms (we already had to do some hacks for Forge) and makes it
easier to provide custom logic for loading client-only tests.
- Run several client tests (namely those involving monitor rendering)
against Sodium and Iris too. There's some nastiness here to set up
new Loom run configurations and automatically configure Iris to use
Complementary Shaders, but it's not too bad. These tests /don't/ run
on CI, so it doesn't need to be as reliable.
This fixes several issues I had with consuming multi-loader CC:T in
various upstream mods.
- Include /all/ sources in the Forge/Fabric jar. Before it was just the
common classes, and not the core or API.
- Use some Gradle magic to remove superfluous dependencies from the POM
file. Also make sure Cobalt and Netty are present as dependencies.
- Start using minimize() in our shadow jar config again.
This commit got away from me, okay? No, I'm not proud of it either.
- Remove our overrides of handleUpdate tag: we now try to detect
whether we're on the client or server inside BlockEntity.load. Alas,
this is needed for Fabric.
- Remove BlockGeneric/TileGeneric entirely: we've slowly whittled this
down over the years, and nowadays we can get away with putting most
of its functionality into subclasses.
This allows us to do some nice things with overriding HorizontalBlock
(or our new HorizontalContainerBlock class), rather than
reimplementing functionality in each class. Though it would be nice
if Java had some sort of trait system :D:
- Simplify a lot of our container class so it's just defined in terms
of a NonNullList<ItemStack>. This also includes a total rewrite of
the disk drive which I'm not ... thrilled about. It ended up being
easier to copy the code from the mc-next branch :D:.
- Try to test some of the gnarly bits of this. Still a /lot/ more to be
done with testing this.
Closes#658
After several weeks of carefully arranging ribbons, we pull the string
and end up with, ... a bit of a messy bow. There were still some things
I'd missed.
- Split the mod into a common (vanilla-only) project and Forge-specific
project. This gives us room to add Fabric support later on.
- Split the project into main/client source sets. This is not currently
statically checked: we'll do that soon.
- Rename block/item/tile entities to use suffixes rather than prefixes.
- Publish javadoc again: for now this is just the common-api
- Remove all dependencies from the published Forge jar. This is
technically not needed (fg.deobf does this anyway), but seems
sensible.
This adds two new modules: common-api and forge-api, which contain the
common and Forge-specific interfaces for CC's Minecraft-specific API.
We add a new PlatformHelper interface, which abstracts over some of the
loader-specific functionality, such as reading registries[^1] or calling
Forge-specific methods. This interface is then implemented in the main
mod, and loaded via ServiceLoaders.
Some other notes on this:
- We now split shared and client-specific source code into separate
modules. This is to make it harder to reference client code on the
server, thus crashing the game.
Eventually we'll split the main mod up too into separate source sets
- this is, of course, a much bigger problem!
- There's currently some nastiness here due to wanting to preserve
binary compatibility of the API. We'll hopefully be able to remove
this when 1.19.3 releases.
- In order to build a separate Forge-specific API jar, we compile the
common sources twice: once for the common jar and once for the Forge
jar.
Getting this to play nicely with IDEs is a little tricky and so we
provide a cct.inlineProject(...) helper to handle everything.
[^1]: We /can/ do this with vanilla's APIs, but it gives a lot of
deprecation warnings. It just ends up being nicer to abstract over it.
It should be possible to consume the ComputerCraft's core (i.e.
non-Minecraft code) in other projects, such as emulators. While this
has been possible for years, it's somewhat tricky from a maintenance
perspective - it's very easy to accidentally add an MC dependency
somewhere!
By publishing a separate "core" jar, we can better distinguish the
boundaries between our Lua runtime and the Minecraft-specific code.
Ideally we could have one core project (rather than separate core and
core-api modules), and publish a separate "api" jar, like we do for the
main mod. However, this isn't really possible to express using Maven
dependencies, and so we must resort to this system.
Of course, this is kinda what the Java module system is meant to solve,
but unfortunately getting that working with Minecraft is infeasible.
- Switch to a fairly standard code format. This is largely based on
IntelliJ defaults, with some minor tweaks applied via editor config.
Should mean people don't need to import a config!
- Use "var" everywhere instead of explicit types. Type inference is a
joy, and I intend to use it to its fullest.
- Start using switch expressions: we couldn't use them before because
IntelliJ does silly things with our previous brace style, but now we
have the luxury of them!
This offers very few advantages now, but helps support the following in
the future:
- Reuse test support code across multiple projects (useful for
multi-loader).
- Allow using test fixture code in testMod. We've got a version of our
gametest which use Kotlin instead of Lua for asserting computer
behaviour.
We can't use java-test-fixtures here for Forge reasons, so have to roll
our own version. Alas.
- Add an ILuaMachine implementation which runs Kotlin coroutines
instead. We can use this for testing asynchronous APIs. This also
replaces the FakeComputerManager.
- Move most things in the .support module to .test.core. We need to use
a separate package in order to cope with Java 9 modules (again,
thanks Forge).
- Correctly handle Git commands failing. We need an actual default
value, not just null!
- Use run/ and build/tmp/ for temporary test locations, not
/test-files.
- Switch over to the Gradle GH action. Not expecting massive changes,
but might provide some better caching.
- Bump some GH action versions.
- Fix a Java 8 compatability issue in our build scripts.
- Add a new Node plugin. This automatically installs npm dependencies
and provides a "NpxExecToDir" to dir task. This allows us to make the
doc website task dependencies a little nicer, by simply chaining
tasks together, rather than doing dependsOn + `input.files(the other
task output)`.
- Switch over to CurseForgeGradle from CurseGradle. The latter is
super clunky to use in non-Groovy languages.
- Copy our Modrinth description body to our repo, and add support for
syncing it. We'll still have to do CF manually I think.
Look, I don't enjoy having 600 LOC long build.gradle files, it's just
very easy to do! This at least moves some of the complexity elsewhere,
so the build script is a little more declarative.
It's more verbose as the default license plugin doesn't support multiple
license headers. However, it also gives us some other goodies (namely
formatting Kotlin and removing unused imports), so worth doing.
This is a little odd (it's more complex for one!), but means we can
reuse the internal API interface in other classes, which is useful for
the data provider refactor I'm about to do.
This is much nicer in Java 17 :D (records, ServiceLoader.stream()),
but such is the perils of still targetting 1.16.
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.
