When a turtle attempts to place a block, it does so by searching for
nearby blocks and attempting to place the item against that block.
This has slightly strange behaviour when working with "placable"
non-block items though (such as buckets or boats). In this case, we call
Item.use, which doesn't take in the position of the block we're placing
against. Instead these items do their own ray trace, using the default
reach distance.
If the block we're trying to place against is non-solid, the ray trace
will go straight through it and continue (up to the maximum of 5
blocks), allowing placing the item much further away.
Our fix here is to override the default reach distance of our fake
players, limiting it to 2. This is easy on Forge (it has built-in
support), and requires a mixin on Fabric.
Closes#1497.
- Split the front face of the computer model into two layers - one for
the main texture, and one for the cursor. This is actually a
simplification of what we had before, which is nice.
- Make the cursor layer render as an emissive quad, meaning it glows in
the dark. This is very easy on Forge (just some model JSON) and very
hard on Fabric (requires a custom model loader).
This adds two slots to the right of the turtle interface which contain
the left and right upgrades of a turtle.
- Add turtle_upgrade_{left,right} indicators, which used as the
background texture for the two upgrade slots. In order to use
Slot.getNoItemIcon, we need to bake these into the block texture
atlas.
This is done with the new atlas JSON and a data generator - it's
mostly pretty simple, but we do now need a client-side data
generator, which is a little ugly to do.
- Add a new UpgradeContainer/UpgradeSlot, which exposes a turtle's
upgrades in an inventory-like way.
- Update the turtle menu and screen to handle these new slots.
Since 1.19.3, this was only populated when the player opened the
creative menu, and so was useless in survival or multi-player
worlds.
Rather than removing the field entirely (🦑 backwards compatibility), we
replace it with the empty list. We also remove it from the docs, and add
a note explaining what the field used to do.
Closes#1285, albeit in the least satisfactory way possible.
- Remove ITurtleItem (and ITurtleBlockEntity): this was, AFAIK, mostly
a relic of the pre-1.13 code where we had multiple turtle items.
I do like the theory of abstracting everything out behind an
interface, but given there's only one concrete implementation, I'm
not convinced it's worth it right now.
- Remove TurtleItemFactory/PocketComputerItemFactory: we now prefer
calling the instance .create(...) method where we have the item
available (for instance upgrade recipes).
In the cases we don't (creating an item the first time round), we now
move the static .create(...) method to the actual item class.
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!
This means the config is no longer stored as static fields, which is a
little cleaner. Would like to move everything else in the future, but
this is a good first step.
- Add a `timeout` parameter to http request and websocket methods.
- For requests, this sets the connection and read timeout.
- For websockets, this sets the connection and handshake timeout.
- Remove the timeout config option, as this is now specified by user
code.
- Use netty for handling websocket handshakes, meaning we no longer
need to deal with pongs.
In this case, we use Lua's tostring(x) semantics (well, modulo
metamethods), instead of Java's Object.toString(x) call. This ensures
that values are formatted (mostly) consistently between Lua and Java
methods.
- Add IArguments.getStringCoerced, which uses Lua's tostring semantics.
- Add a Coerced<T> wrapper type, which says to use the .getXCoerced
methods. I'm not thrilled about this interface - there's definitely
an argument for using annotations - but this is probably more
consistent for now.
- Convert existing methods to use this call.
Closes#1445
- Fix monitor renderer debug text showing up even when debug overlay
was not visible. This was a Forge-specific bug, which is why I'd not
noticed it I guess??
- Don't crash on alternative implementations of LoggerContext. Fixes
#1431. I'm not 100% sure what is causing this - it doesn't happen
with just CC:T at least - but at least we can bodge around it.
This is a horrible commit: It's a breaking change in a pretty subtle
way, which means it won't be visible while updating. Fortunately I think
the only mod on 1.19.4 is Plethora, but other mods (Mek, Advanced
Peripherals) may be impacted when they update. Sorry!
For some motivation behind the original issue:
The default IArguments implementation (VarargArguments) lazily converts
Lua arguments to Java ones. This is mostly important when passing tables
to Java functions, as we can avoid the conversion entirely if the
function uses IArguments.getTableUnsafe.
However, this lazy conversion breaks down if IArguments is accessed on a
separate thread, as Lua values are not thread-safe. Thus we need to
perform this conversion before the cross-thread sharing occurs.
Now, ideally this would be an implementation detail and entirely
invisible to the user. One approach here would be to only perform this
lazy conversion for methods annotated with @LuaFunction(unsafe=true),
and have it be eager otherwise.
However, the peripheral API gets in the way here, as it means we can no
longer inspect the "actual" method being invoked. And so, alas, this
must leak into the public API.
TLDR: If you're getting weird errors about scope, add an
IArguments.escapes() call before sharing the arguments between threads.
Closes#1384
- Add a new recipe type for turtle overlays, and recipe generator
support for this recipe.
- Add trans and rainbow flags.
- Exclude .license files from the generated jar. I'm not thrilled on
the whole .license file system, but it's kinda the easiest way.
- Regenerate data. Yes, this is 90% of the commit :D.
- 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.
- Timeouts are now driven by an interrupt system, rather than polling.
While we do not impose memory limits, this should close#1333.
- Update the table library to largely match Lua 5.4:
- Add table.move
- Table methods (with the exception of foreach/foreachi) now use
metamethods (closes#1088).
There's still some remaining quirks (for instance, table.insert
accepts values out-of-bounds), but I think that's fine.
- Cobalt's threaded-coroutine system is gone (load now supports
yielding), so we no longer track coroutine metrics.
- Type errors now use __name. See #1355, though this does not apply to
CC methods (either on the Java or CraftOS side), so is not enough to
resolve it.
See https://github.com/SquidDev/Cobalt/compare/v0.6.0...v0.7.0 for the
full delta.
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/
While it is a really nice library, it ends up being a bit overkill for
our needs - we don't need config syncing or anything. By NIHing our own,
we can drop one dependency and ease the updating burden a little.
Closes#1296
Mostly in prep for 1.19.4.
- Update to Loom 1.1.
- Simplifies our handling of remapped configurations a little.
- Removes the need for a fake fabric.mod.json in the API jar.
For reasons I don't quite understand, this required us to bump the
Fabric API version. Otherwise interfaces are not injected.
- Update to Rollup 3.0.
- Do NOT update NullAway: It now correctly checks @Nullable fields in
inherited classes. This is good, but also a pain as Minecraft is a
little over-eager in where it puts @Nullable.
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.
- We now write to a "ids.json.new" file, then move that on top of the
original ids.json file instead.
- Use FileChannel.force to ensure the new file is properly flushed to
disk. I can't really guarantee this'll work with the later
Files.move, but it's better than not doing it!
Closes#1346.
While it's a nice immersive interaction, it's far too easy to trigger by
accident. Dying/undying can now only be done via crafting and the
cauldron.
Closes#1321
It's much less aggressive than dunking it in a cauldron, so won't damage
any of your precious electronics.
I had this idea back in 2017 (dan200/ComputerCraft#230). Can't believe
it took me almost 6 years to implement.
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.
- Move modem recipes out of the usage section.
- Add missing argument names to BinaryWriableHandle.write. Illuaminate
really should catch this, but for now I did a grep and couldn't find
any more instances of this.
- 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/
When the peripheral is attached, we add the computer to the map and
queue the actual disk to be mounted next tick. This avoids the
thread-safety issues with mutating the item (and creating disk ids) that
might be caused by doing it on the computer thread.
The mount is now also managed separately to the MediaStack, as that was
meant to be an immutable snapshot of the item!
Fixes#1282
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.
