1
0
mirror of https://github.com/SquidDev-CC/CC-Tweaked synced 2024-12-14 20:20:30 +00:00
Commit Graph

28 Commits

Author SHA1 Message Date
Jonathan Coates
8d2e150f05
Various improvements to packaging
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.
2022-11-17 09:26:57 +00:00
Jonathan Coates
8152f19b6e
Fabric lol
- Add support for Fabric. This is mostly pretty simple, though does
   require a lot more mixins than Forge.

   Half this diff is due to data generators: we run them separately as
   some aspects (recipes mostly) are different between the loaders.

 - Add integration with Iris (same as our Oculus support) and REI
   (mostly the same as our JEI support).

 - Generic peripherals only support inventories (or rather
   InventoryStorage) right now. Supporting more of the Fabric storage
   API is going to be tricky due to the slotted nature of the API: maybe
   something to revisit after Transfer API V3 (V4?, I've lost track).

Note, this does /not/ mean I will be publishing a Fabric version of
CC:T. My plan is to rebase CC:R on top of this, hopefully simplifying
the maintenance work on their end and making the two mods a little more
consistent.
2022-11-10 19:42:34 +00:00
Jonathan Coates
8360e8234d
Post multi-loader cleanup
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
2022-11-10 15:55:34 +00:00
Jonathan Coates
1d335f7290
Add a couple of errorprone plugins
- Check that common code does not reference client-only classes.
 - Check that @ForgeOverride really overrides a method in Forge
   projects.
2022-11-10 08:54:09 +00:00
Jonathan Coates
f04acdc199
Split CC:T into common and forge projects
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.
2022-11-10 08:54:09 +00:00
Jonathan Coates
bdf590fa30
Clean up data generators a little 2022-11-09 22:02:47 +00:00
Jonathan Coates
b36b96e0bc
Make the main mod non-null by default
This was actually much more work than I thought it would be. Tests pass,
but I'm sure there's some regressions in here.
2022-11-09 18:59:51 +00:00
Jonathan Coates
55494b7671
Rewrite how we do inventory transfers
- Add a new ContainerTransfer class to handle moving items between
   containers. This is now used for turtle.drop/turtle.suck as well as
   inventory methods.

 - Any other usages of IItemHandler (which are mostly on turtle
   inventories) now use Container and a couple of helper methods.
2022-11-08 21:31:24 +00:00
Jonathan Coates
320007dbc6
Improve packaging of published jars
- 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.
2022-11-08 16:43:27 +00:00
Jonathan Coates
955b9c7d28
Default Forge/Common API to non-null 2022-11-06 15:50:24 +00:00
Jonathan Coates
76710eec9d
Move our public API into separate modules
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.
2022-11-06 15:07:13 +00:00
Jonathan Coates
c82f37d3bf
Switch the core library to be non-null by default
See comments in c8c128d335 for further
details. This requires /relatively/ few changes - mostly cases we were
missing @Nullable annotations.
2022-11-06 11:55:26 +00:00
Jonathan Coates
c8c128d335
Switch the core-api to be non-null by default
We'll do this everywhere eventually, but much easier to do it
incrementally:

 - Use checker framework to default all field/methods/parameters to
   @Nonnull.

 - Start using ErrorProne[1] and NullAway[2] to check for possible null
   pointer issues. I did look into using CheckerFramework, but it's much
   stricter (i.e. it's actually Correct). This is technically good, but
   is a much steeper migration path, which I'm not sure we're prepared
   for yet!

[1]: https://github.com/google/error-prone
[2]: https://github.com/uber/NullAway
2022-11-06 10:28:49 +00:00
Jonathan Coates
acc254a1ef
Move dan200.computercraft.core into a separate module
This is a very big diff in changed files, but very small in actual
changes.
2022-11-06 10:02:14 +00:00
Jonathan Coates
a17b001950
Move the core API into a separate module
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.
2022-11-04 21:41:59 +00:00
Jonathan Coates
f478c4ffc4
Reformat everything
- 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!
2022-11-04 13:41:38 +00:00
Jonathan Coates
0db32bd0fe
Merge branch 'mc-1.16.x' into mc-1.18.x 2022-11-02 09:55:10 +00:00
Jonathan Coates
aefda6a381
Fix a couple of issues with the release process
Only way to test these is in prod, alas :D:
2022-11-01 21:53:05 +00:00
Jonathan Coates
38b2c944f3
Merge branch 'mc-1.16.x' into mc-1.18.x 2022-10-30 08:49:52 +00:00
Jonathan Coates
71f81e1201
Move some test support code into testFixtues
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).
2022-10-29 18:17:02 +01:00
Jonathan Coates
be827a21db
Merge branch 'mc-1.16.x' into mc-1.18.x
I dare say there's going to be some bugs with this. I was as careful as
I could be, but yikes it was nasty.
2022-10-25 22:38:26 +01:00
Jonathan Coates
8171578e80
Some minor build system improvements
- 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.
2022-10-24 19:21:09 +01:00
Jonathan Coates
3e3bc8d4b1
Fix a whole bunch of GH action issues
- 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.
2022-10-22 21:36:52 +01:00
Jonathan Coates
6ab90dc30d
Convert build script to Kotlin
- 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.
2022-10-22 21:09:08 +01:00
Jonathan Coates
0cfdd7b5e9
Move some more build logic to buildSrc
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.
2022-10-22 20:47:47 +01:00
Jonathan Coates
af5d816798
Use spotless for enforcing licenses
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.
2022-10-22 18:19:51 +01:00
Jonathan Coates
9db3e6d2a0
Load the CC API with services loaders
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.
2022-10-21 23:50:44 +01:00
Jonathan Coates
ba64e06ca7
Use a Gradle plugin to download illuaminate
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.
2022-09-11 14:11:33 +01:00