- Add a generic PermissionRegistry interface. This behaves similarly to
our ShaderMod interface, searching all providers until it finds a
compatible one.
We could just make this part of the platform code instead, but this
allows us to support multiple systems on Fabric, where things are
less standardised.
This interface behaves like a registry, rather than a straight
`getPermission(node, player)` method, as Forge requires us to list
our nodes up-front.
- Add Forge (using the built-in system) and Fabric (using
fabric-permissions-api) implementations of the above interface.
- Register permission nodes for our commands, and use those
instead. This does mean that the permissions check for the root
/computercraft command now requires enumerating all child
commands (and so potential does 7 permission lookups), but hopefully
this isn't too bad in practice.
- Remove UserLevel.OWNER - we never used this anywhere, and I can't
imagine we'll want to in the future.
Should be max_websocket_message, not just websocket_message.
Also add some additional validation to address rules, to check no
unrecognised keys are present.
Closes#1566.
We're very inconsistent with whether we use locks or concurrent maps
here. Something to sort out in the future, but for now add some missing
@GuardedBy annotations.
- Prefer {read,write}Nullable when possible.
- Use SoundEvent.{writeTo,readFrom}Network, instead of sending the
registry entries. This allows playing discs which don't register
their SoundEvent on the server.
- Add a couple of tests for round-tripping these packets.
This requires supporting registries in our platform test
code. Thankfully this is mostly the same as what we can do in Fabric -
the duplication is unfortunate - but it's easy enough.
This made more sense on 1.19.2 and before, but now that we have to do
this for tooltips, we might as well do it for messages as well.
Closes#1538, though hopefully will be resolved on the VO side too.
- Remove some unused translation keys.
- Run tools/language.py to sort the current translations and remove the
aforementioned unused keys.
- Update turtle tool impostor recipes - these now include the tool NBT!
Translations for Polish
Translations for French
Translations for Spanish
Translations for German
Co-authored-by: Patriik <apatriik0@gmail.com>
Co-authored-by: Sammy <SammyKoch@pm.me>
Co-authored-by: SquidDev <git@squiddev.cc>
- Move the tool action before the "is block present" check, fixes
#1527. This is where it was before, but we flipped it around in the
tool rewrite.
- Don't reuse as much turtle.place logic for tool actions. This fixes
some instances where tools could till/level dirt through solid
blocks.
- 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.
- Attach permission checks to the first argument (so the literal
command name) rather than the last argument. This fixes commands
showing up when they shouldn't.
- HelpingArgumentBuilder now inherits permissions of its leaf nodes.
This only really impacts the "track" subcommand.
- Don't autocomplete the computer selector for the "queue" subcommand.
As everyone has permission for this command, it's possible to find
all computer ids and labels in the world.
I'm in mixed minds about this, but don't think this is an exploit -
computer ids/labels are sent to in-range players so shouldn't be
considered secret - but worth patching none-the-less.
- 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.
This is a pre-requisite for #1501, and some other refactorings I want to do.
Also fix items in the turtle upgrade slots vanishing. We now explicitly
invalidate the cache when setting the item.
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.
This removes a tiny bit of duplication (at the cost of mode code), but
makes the interface more intuitive, as there's no bouncing between
getCombination -> cache -> buildModel.
It turns out we don't document the "port" option anywhere, so probably
worth doing a bit of an overhaul here.
- Expand the top-level HTTP rules comment, clarifying how things are
matched and describing each field.
- Improve the comments on the default HTTP rule. We now also describe
the $private rule and its motivation.
- Don't drop/ignore invalid rules. This gets written back to the
original config file, so is very annoying! Instead we now log an
error and convert the rule into a "deny all" rule, which should make
it obvious something is wrong.
- Update to Loom 1.2 and FG 6.0. ForgeGradle has changed how it
generates the runXyz tasks, which makes running our tests much
harder. I've raised an issue upstream, but for now we do some nasty
poking of internals.
- Fix Sodium/Iris tests. Loom 1.1 changed how remapped configurations
are generated - we create a dummy source set and associate the
remapped configuration with that. All nasty stuff.
- Publish the common library. I'm not a fan of this, but given how much
internals I'm poking elsewhere, should probably get off my high
horse.
- Add renderdoc support to the client gametests, enabled with
-Prenderdoc.
- Move the class cache out of Generator into MethodSupplierImpl. This
means we cache class generation globally (that's really expensive!),
but the class -> method list lookup is local.
- Move the global GenericSource/GenericMethod registry out of core,
passing in the list of generic methods to the ComputerContext.
I'm not entirely thrilled by the slight overlap of MethodSupplierImpl and
Generator here, something to clean up in the future.
- Move several interfaces out of `d00.computercraft.core.asm` into a
new `aethods` package. It may make sense to expose this to the
public API in a future commit (possibly part of #1462).
- Add a new MethodSupplier<T> interface, which provides methods to
iterate over all methods exported by an object (either directly, or
including those from ObjectSources).
This interface's concrete implementation (asm.MethodSupplierImpl),
uses Generators and IntCaches as before - we can now make that all
package-private though, which is nice!
- Make the LuaMethod and PeripheralMethod MethodSupplier local to the
ComputerContext. This currently has no effect (the underlying
Generator is still global), but eventually we'll make GenericMethods
non-global, which unlocks the door for #1382.
- Update everything to use this new interface. This is mostly pretty
sensible, but is a little uglier on the MC side (especially in
generic peripherals), as we need to access the global ServerContext.
- Remove SidedGenericPeripheral (we never used this!), adding the
functionality to GenericPeripheral directly. This is just used on the
Fabric side for now, but might make sense with Forge too.
- Move GenericPeripheralBuilder into the common project - this is
identical between the two projects!
- GenericPeripheralBuilder now generates a list of methods internally,
rather than being passed the methods.
- Add a tiny bit of documentation.
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.
- Reverse quads in our model transformer and when rendering as a block
entity.
- Correctly recompute normals when the quads have been inverted.
Closes#1283
- 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.
