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

18 Commits

Author SHA1 Message Date
Jonathan Coates
b58b9b7df3
Fix several issues with the Fabric API jar
- Bundle the core API inside the Fabric API jar for now, to ensure
   that ResourceLocation is remapped.

 - Add a dummy fabric.mod.json file to the API. We'll remove this once
   https://github.com/FabricMC/fabric-loom/pull/749 is released.
2022-11-18 23:21:05 +00:00
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
b2b58892e3
Minor fixes and cleanup
My working tree is a mess, so this is not a good commit. I'm making a
bit of a habit of this.

 - Fix UserLevel.OWNER check failing on single player servers.
 - Correctly handle the "open folder" fake command.
 - Some reshuffling of Forge-specific methods to make Fabric slightly
   easier.
2022-11-10 17:15:12 +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
77624fc6fd
Update project paths in our utility build scripts 2022-11-10 09:12:28 +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
0c4fd2b29e
Make the shader mod system a little more flexible
Mostly for multi-loader support, but also /technically/ makes it easier
to support multiple loaders in the future.
2022-11-09 21:05:27 +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
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
d8e2161f15
Move website source/build logic to projects/web
Mostly useful as it moves some of our build logic out of the main
project, as that's already pretty noisy!
2022-11-06 13:37:07 +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