Wow, some of this is /old/. All the Maps.newHashMap stuff dates back to
Java 6, so must originally be CCTweaks code?!
We're unlikely to drop our Guava dependency (we use too much other
stuff), but we should make the most of the stdlib where possible.
- Overhaul model loading to work with the new API. This allows for
using the emissive texture system in a more generic way, which is
nice!
- Convert some of our custom models to use Fabric's model hooks (i.e.
emitItemQuads). We don't make use of this right now, but might be
useful for rendering tools with enchantment glints.
Note this does /not/ change any of the turtle block entity rendering
code to use Fabric/Forge's model code. This will be a change we want
to make in the future.
- Some cleanup of our config API. This fixes us printing lots of
warnings when creating a new config file on Fabric (same bug also
occurs on Forge, but that's a loader problem).
- Fix a few warnings
We've supported resource conditions in the upgrade JSON for an age, but
don't expose it in our data generators at all.
Indeed, using these hooks is a bit of a pain to do in multi-loader
setups, as the JSON is different between the two loaders. We could
generate the JSON for all loaders at once, but it feels nicer to use
the per-loader APIs to add the conditions.
For now, we just support generating a single condition - whether a mod
is loaded not, via the requireMod(...) method.
- Normalise upgrade keys, to be "allowEnchantments" and
"consumeDurability". We were previously inconsistent with
allow/allows and consumes.
- Add tests for durability and enchantments of pickaxes.
- Fix a couple of issues with the original upgrade NBT being modified.
- Now store the item's tag under a separate key rather than on the
root. This makes syncing the NBT between the two much nicer.
Turtle tools now accept two additional JSON fields
- allowEnchantments: Whether items with enchantments (or any
non-standard NBT) can be equipped.
- consumesDurability: Whether durability will be consumed. This can be
"never" (the current and default behaviour), "always", and
"when_enchanted".
Closes#1501.
I think this left over from CCTweaks or Peripheral++. It doesn't really
make sense as an API - if/when we add multiple upgrades, we'll want a
different API for this.
Instead of creating the upgrade serialiser registries in mod
initialisation, we now do it when the API is created. This ensures the
registries are available for other mods, irrespective of mod load order.
This feels a little sad (we're doing side effects in the static
initialiser), but is /fine/ - it's pretty much what other mods do.
This is mostly aiming to give an overview rather than be anything
comprehensive (there's another 230+ undocumented classes to go :p), but
it's a start.
Mostly just an excuse for me to procrastinate working on the nasty bugs
though!
- 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/
We define a tag which allows specifying which blocks can be used. Right
now this is is just cauldrons and hives, as they have "placing into"
semantics.
Closes#1305. Many thanks to Lindsay-Needs-Sleep for their initial work
on this!
Fixes#1008. I believe also fixes#854.
In older versions we just used a hard-coded list of items and
superclasses. This was somewhat ugly, and so in 1.19.3 I tried to make
this code more generic.
However, this has a lot of unintended consequences - for instance
turtles can now throw ender pearls, which is definitely not intended!
By using a tag, we can emulate the old behaviour, while still allowing
modders and pack devs to add additional items if needed.
- Document the thread safety of DetailRegistry a little better.
- Turtles now duplicate their inventory to the "previous
inventory" (now called inventorySnapshot) immediately, rather than
when the block is ticked.
This is slightly more resource intensive, but I don't think it's so
bad we need to worry.
- As this snapshot is now always up-to-date, we can read it from the
computer thread. Given the item is immutable, it's safe to read NBT
from it.
_Technically_ this is not safe under the Java memory model, but in
practice I don't think we'll observe the wrong value.
Closes#1306
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/
- 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.
- 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.
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.
- 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.
