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

18 Commits

Author SHA1 Message Date
Jonathan Coates
e157978afc
Deprecate ITurtleAccess.getVisual{Position,Yaw} 2023-06-08 18:32:00 +01:00
Jonathan Coates
f0abb83f6e
Eagerly create upgrade registries for Fabric
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.
2023-06-03 19:04:02 +01:00
Jonathan Coates
4d064d1552
Document some of our client classes
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!
2023-06-02 21:59:45 +01:00
Jonathan Coates
a9547d1d6f
Further licensing work
- 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.
2023-03-29 23:00:18 +01:00
Jonathan Coates
895bc7721a
License CC:T according to the REUSE specification (#1351)
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/
2023-03-15 21:52:13 +00:00
Jonathan Coates
118d04f018
Allow placing items against some blocks
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.
2023-03-04 18:17:43 +00:00
Jonathan Coates
2e5cd29e12
Use tags to what items turtle.place() can .use()
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.
2023-02-04 18:14:18 +00:00
Jonathan Coates
1554c7b397
Always expose nbt from turtle.getItemDetail
- 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
2023-01-25 18:37:14 +00:00
Jonathan Coates
6cd32a6368
Fix a few typos
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/
2023-01-24 18:47:29 +00:00
Jonathan Coates
367773e173
Some refactoring of mounts
- 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.
2022-12-09 22:02:31 +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
87c6d3aef6
Initial pass of the API breaking changes for 1.19.3 (#1232)
- 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.
2022-12-03 15:02:00 +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
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