This gives us slightly better guarantees that the config has actually
been loaded. This, along with a FCAP bump, fixes this config option
not doing anything on Fabric.
Instead of taking control of the breaking logic in all cases, we now
only do so when we have both a cable and modem. This allows us to fall
back to default vanilla behaviour and so correctly drop the modem/cable
item.
- 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
- Separate FileMount into separate FileMount and WritableFileMount
classes. This separates the (relatively simple) read-only code from
the (soon to be even more complex) read/write code.
It also allows you to create read-only mounts which don't bother with
filesystem accounting, which is nice.
- Make openForWrite/openForAppend always return a SeekableFileHandle.
Appendable files still cannot be seeked within, but that check is now
done on the FS side.
- Refactor the various mount tests to live in test contract interfaces,
allowing us to reuse them between mounts.
- Clean up our error handling a little better. (Most) file-specific code
has been moved to FileMount, and ArchiveMount-derived classes now
throw correct path-localised exceptions.
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.
- Update ForgeConfigAPI to the latest version, to fix the race
condition.
- Move WirelessNetwork lifecycle management to ServerContext.
- Some doc fixes.
- Remove deprecated API members in prep for 1.19.3. This allows us to
remove the mc-stubs and forge-stubs projects.
- Make several methods take a MinecraftServer instead of a Level (or
nothing at all).
- Remove I prefixes from a whole bunch of interfaces, making things a
little more consistent with Java conventions.
This avoids touching the "main" interfaces people consume for now. I
want to do that another Minecraft version, to avoid making the update
too painful.
- Remove IFileSystem and associated getters. This has never worked very
well and I don't think has got much (any?) usage.
Forge requires the file to be in the root of the jar, hence doing it
this way round. The icon is read using ModContainer.findPath, so this
shouldn't conflict with other mods.
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().
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.
- 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.
- 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.
