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

45 Commits

Author SHA1 Message Date
Jonathan Coates
86c4c7483d
Bump Cobalt and ForgeConfigAPI versions
Fixes #1248, fixes #1249
2022-12-21 15:58:51 +00:00
Jonathan Coates
2b237332ce
Update to latest Forge
This fixes the issue with DeferredRegister crashing on non-wrapped
registries.
2022-12-15 17:53:50 +00:00
Jonathan Coates
06163e4f25
Fix a couple of packaging issues
- Fix client classes not being included in Forge.
 - Only remap Nettty's HTTP classes, not all of them. This feels a
   little more error prone - maybe we should jar-in-jar this in the
   future.
 - Use the correct refmaps on Forge.
 - Prevent the Fabric jar pulling in some other mods.

Closes #1247
2022-12-12 20:28:18 +00:00
Jonathan Coates
8007a30849
Actually update README with the new maven coordinates
Also bump REI to 1.19.3
2022-12-09 18:05:35 +00:00
Jonathan Coates
c3fe9f00d4
Update to Minecraft 1.19.3
Lots of minor changes, but nothing too nasty - just tedious.

Known bugs/issues:
 - REI and JEI haven't been updated at the time of writing, so our usage
   of their APIs may be incompatible.

 - Crash when opening the config UI in Fabric, as forgeconfigapi-port
   hasn't been updated yet.

Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
Jonathan Coates
020c5cd2d3
Support renaming files directly without copying/deleting
In classic squid tradition: 20% code, and 80% test logic.

Closes #962. Alas, whoever reported this has deleted their account, so
they can't even be happy about it :(.
2022-12-04 21:59:30 +00:00
Jonathan Coates
fa122a56cf
Resolve a few TODOs
- Update ForgeConfigAPI to the latest version, to fix the race
   condition.
 - Move WirelessNetwork lifecycle management to ServerContext.
 - Some doc fixes.
2022-12-03 15:55:48 +00:00
Jonathan Coates
95c57e843d
Pass project root to cct-javadoc
Fixes #1238
2022-12-02 22:00:00 +00:00
Jonathan Coates
2255d49d16
Update to latest Fabric
Love being on the bleedin' edge. More importantly, this fixes a couple
of issues:
 - Translations are loaded on the server, meaning .getItemDetail
   correctly translates modded items.
 - Shulker boxes cannot be moved inside other shulker boxes using the
   transfer API.
 - Start using Fab API's ItemStack.getRecipeRemainder().
2022-11-20 16:05:28 +00:00
Jonathan Coates
08df68dcc0
Generate en_us.json via datagen
I was originally pretty sceptical about this, but it actually ends up
being useful for the same reason any other form of datagen is: we can
ensure that names are well formed, and that every string is actually
translated.

There's some future work here to go through all the custom translation
keys and move them into constants (maybe also do something with the
/computercraft command?), but that's a separate chunk of work.

The main motivation for this is to add translation keys to our config:
the Fabric version of Forge Config API provides a config UI, so it's
useful to provide user-friendly strings. Our generator also
automatically copies comments over, turning them into tooltips.

This also updates all of the other language files to match en_us.json
again: it's a very noisy diff as the file is now sorted alphabetically.
Hopefully this won't affect weblate though

[^1]: Amusing really that the Fabric port actually is more useful than
the original.
2022-11-20 13:00:43 +00:00
Jonathan Coates
8f92417a2f
Add a system for client-side tests (#1219)
- 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.
2022-11-18 23:57:25 +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
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
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
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
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
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
629abb65e3
Merge branch 'mc-1.18.x' into mc-1.19.x 2022-11-01 20:11:36 +00:00
Jonathan Coates
5d4c34fbac
Merge branch 'mc-1.16.x' into mc-1.18.x 2022-10-31 18:03:39 +00:00
Jonathan Coates
1490ca8624
Bump Cobalt version
Adds debug.getregistry() support
2022-10-30 16:39:25 +00:00
Jonathan Coates
b5056fc3b8
Merge branch 'mc-1.18.x' into mc-1.19.x 2022-10-30 09:06:40 +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
97387556fe
Handle file transfers inside CraftOS (#1190)
- Add a new file_transfer event. This has the signature
   "file_transfer", TransferredFiles.

   TransferredFiles has a single method getFiles(), which returns a list
   of all transferred files.

 - Add a new "import" program which waits for a file_transfer event and
   writes files to the current directory.

 - If a file_transfer event is not handled (i.e. its getFiles() method
   is not called) within 5 seconds on the client, we display a toast
   informing the user on how to upload a file.
2022-10-29 12:01:23 +01:00
Jonathan Coates
a2911038c5
Merge branch 'mc-1.18.x' into mc-1.19.x 2022-10-26 09:53:32 +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
f45614175a
Some improvements to Javadoc publishing
- Use <p> everywhere. This is uglier, but also technically more
   correct. This requires a version bump to cct-javadoc, and will give
   me a massive headache when merging.

 - Link against the existing OpenJDK docs.
2022-10-25 19:17:55 +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
1e703f1b07
Fix several off-by-one issues in UploadFileMessage
We now fuzz UploadFileMessage, generating random files and checking they
round-trip correctly.

The joy of having a long-lasting refactor branch with an absolutely
massive diff, is that you end up spotting bugs, and then it's a massive
pain to merge the fix back into trunk!
2022-10-21 23:10:18 +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
Jonathan Coates
f9f8233ef4
Some "improvements" to our Gradle script
- 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.
2022-06-19 11:21:42 +01:00
Jonathan Coates
e247bd823e
Bump Gradle and Kotlin versions
I think we need this for 1.18
2021-11-26 21:12:20 +00:00
Jonathan Coates
ab6b861cd6
Move repo to cc-tweaked org
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.
2021-10-17 18:14:32 +01:00
Jonathan Coates
abb9c14256
Bump Forge Gradle version 2021-07-02 21:48:28 +01:00
Jonathan Coates
8644c4ebf6
More gradle tweaks
- 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.
2021-06-09 18:01:13 +01:00
Jonathan Coates
061514549d Bump Gradle/ForgeGradle version
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.
2021-02-13 12:39:52 +00:00
SquidDev
f9e13ca67a Update CC: Tweaked to 1.13
Look, I originally had this split into several commits, but lots of
other cleanups got mixed in. I then backported some of the cleanups to
1.12, did other tidy ups there, and eventually the web of merges was
unreadable.

Yes, this is a horrible mess, but it's still nicer than it was. Anyway,
changes:

 - Flatten everything. For instance, there are now three instances of
   BlockComputer, two BlockTurtle, ItemPocketComputer. There's also no
   more BlockPeripheral (thank heavens) - there's separate block classes
   for each peripheral type.

 - Remove pretty much all legacy code. As we're breaking world
   compatibility anyway, we can remove all the code to load worlds from
   1.4 days.
 - The command system is largely rewriten to take advantage of 1.13's
   new system. It's very fancy!

 - WidgetTerminal now uses Minecraft's "GUI listener" system.

 - BREAKING CHANGE: All the codes in keys.lua are different, due to the
   move to LWJGL 3. Hopefully this won't have too much of an impact.

   I don't want to map to the old key codes on the Java side, as there
   always ends up being small but slight inconsistencies. IMO it's
   better to make a clean break - people should be using keys rather
   than hard coding the constants anyway.

 - commands.list now allows fetching sub-commands. The ROM has already
   been updated to allow fancy usage such as commands.time.set("noon").

 - Turtles, modems and cables can be waterlogged.
2019-04-02 20:59:48 +01:00
SquidDev
eaf24a3ceb Update to JUnit 5
Also display test results within the Gradle build
2019-03-10 09:40:06 +00:00
SquidDev
28e3ffe978 Update Gradle and build system
- Bundle Javadoc and APIs using gradle instead of deploy.sh
 - Bump Gradle to 4.3, significantly improving compile times.
2017-11-14 22:42:03 +00:00
Daniel Ratcliffe
e85cdacbc5 ComputerCraft 1.79 initial upload
Added the complete source code to ComputerCraft 1.79 for Minecraft
1.8.9, plus newly written README and LICENSE files for the open source
release.
2017-05-01 14:32:39 +01:00