- 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.
We were generating methods with the original object, rather than the
extra one.
Updated our tests to actually catch this. Unfortunately the only places
we use this interface is in HTTP responses and transferred files,
neither of which show up in the Lua-side tests.
We switched to Forge's loot modifier system in the 1.20 update, as
LootTable.addPool had been removed. Turns out this was by accident, and
so we switch back to the previous implementation, as it's much simpler
and efficient.
- 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.
- Document that settings.set doesn't persist values. I think this
closes#1512 - haven't heard back from them.
- Add missing close reasons to the websocket_closed event. Closes#1493.
- Mention what values are preserved by os.queueEvent. This is just the
same as modem.transmit. Closes#1490.
- 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.
- Remove the "force_print" code. This is a relic of before we used
table.pack, and so didn't know how many expressions had been
returned.
- Check the input string is a valid expression separately before
wrapping it in an _echo(...). Fixes#1506.
- 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.
- Fix mainThread=true methods calling IArguments.escapes too late. This
should be done before scheduling on the main thread, not on the main
thread itself!
- Fix VarargsArguments.escapes not checking that the argument haven't
been closed. This is slightly prone to race conditions, but I don't
think it's worth the overhead of tracking the owning thread.
Maybe when panama and its resource scopes are released.
Thanks Sara for pointing this out!
Slightly irked that none of our tests caught this. Alas.
Also fix a typo in AddressPredicate. Yes, no commit discipline.
- 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.
- Use integer indexes instead of strings (i.e. text, textColour). This
is a tiny bit faster.
- Avoid re-creating tables when clearing.
We're still mostly limited by the VM (slow) and string concatenation
(slow!). Short of having some low-level mutable buffer type, I don't
think we can improve this much :(.
Instead of reporting an error with `.report(f(...))`, we now do
`.report(f, ...)`. This allows consumers to ignore error messages when
not needed, such as when just doing syntax highlighting.
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 was broken/commented out already as part of the 1.20 update. I
don't think this is really going to be easy to add back without a lot of
reflection, so going to remove this feature instead.
Closes#1471.
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.
Fixes#1473.
There's an argument we should use Screen.hasControlDown() (which handles
Cmd vs Ctrl) instead of checking the modifiers, but we then need to
update all the translation strings, and I'm not convinced it's worth it
right now.
- Use GuiGraphics for rendering UI elements. Almost definitely some
z-fighting issues slipped in here.
- Use Forge's loot modifier system for handling treasure disks. I have
mixed feelings about this - it's a nice system, but also is far less
efficient than the previous approach.
- Regenerate data. This is the brunt of the commit, but nothing
especially interesting here.
- 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.
- Provide a helper method for creating threads with a lower priority.
- Use that in our network code (which already used this priority) and
for the computer worker threads (which used the default priority
before). I genuinely thought I did this years ago.
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.
We could do this in a more concise manner by wrapping Throwable rather
than reimplementing printStackTrace. However, doing this way allows us
to handle nested exceptions too.
Modrinth proxies images hosted on non-trusted domains through wsrv.nl,
for understandable reasons. However, wsrv.nl blocks tweaked.cc - I'm not
sure why. Instead we reference the image on GH directly, which works!
Also:
- Fix the modrinthSyncBody task pointing to a missing file.
- Update the licenses of a few files, post getting permission from
people. <3 all.
- 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 little more general than InventoryStorage and means we can get
rid of our nasty double chest hack.
The generic peripheral system doesn't currently support generics (hah),
and so we need to use a wrapper class for now.
- Standardise our badges a little, adding a modrinth badge.
- Mention Fabric and Forge support.
- Don't include MC version in the Modrinth version number. I feel this
was required at some point, but apparently not any more! This also
allows us to use Modrinth for the Forge update JSON.
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.
Trying to play a non-DFPWM (or WAV) file will generate terrible noise,
which in turns generates confused users. Instead, fail to play the audio
file and redirect them to the docs.
When a client sided pocket computer was first seen via an item stack
(rather than the computer state being synced over the networK), it would
always be created in greyscale due to this incorrect instanceof check.
Closes#1347
- Consult __name in native code too. Closes#1355. This has the added
advantage that unconvertable values (i.e. functions) will now
correctly be reported as their original type, not just nil.
- Fix the error message in cc.expect, so it matches the rest of Lua.
This has been bugging me for years, and I keep forgetting to change
it.
- Several files where @MCJack123 is the exclusive contributor. He has
signed over all contributions to "any OSI-approved license". Thank
you!
- Various the file handle classes: Looking at these again, I don't
think they contain any of the original code.
- 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/
Many thanks to Lem for managing to reproduce it. It was actually an easy
bug bug to spot on second look, but having a reliable way to verify was
super helpful.
Fixes#1338
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.
See the discussion in #1352 - Netty uses the system one by default,
so no sense creating our own.
Also make sure we through the HTTP error every time, not just on the
first failure. Otherwise we get cryptic connection dropped errors.
Given an input like f(x), which is both a valid statement and
expression, both parsers would accept the whole input. However, this was
treated the same as both parsers rejecting the input, resulting in a
crash when trying to print the error.
We now return immediately when any parser accepts the input.
Fixes#1354
Translations for Italian
Translations for French
Co-authored-by: Alessandro <ale.proto00@gmail.com>
Co-authored-by: RomanPlayer22 <romansulc13122006@gmail.com>
Co-authored-by: chesiren <chesiren63@gmail.com>
If someone had a recursive table (created with an IIFE), then we'd throw
an error inside reserialize. We now catch this error and silently drop
the value.
I'm not thrilled by this behaviour - there's an argument we should
return false instead - but it's consistent with what we currently do.
Closes#1337.
Historically, the VBO was an order of magnitude slower than the TBO
renderer. However, as of fccca22d3f, the
difference is much smaller now. While TBOs /are/ still faster, this only
has a measurable impact in extreme stress tests, and so isn't worth the
occasional issues which occur.
I'm still keeping the code around for now: I'm incredibly fond of it,
even three years later. I may end up re-evaluating this the next time
Minecraft's rendering code changes :D.
This also adds a line to the debug screen showing the current monitor
renderer, though maybe less useful now that almost everyone will be
using VBOs!
Previously it was possible to access all methods of the multishell
redirect by calling term.current(). This is definitely not intended, as
it leaks all sorts of internals to the user.
Also bump illuaminate - the new version is about twice as fast on my
machine.
Woops!
- Fix the REPL not printing values, as exception.try didn't return
values. It did originally, and then I tried to simplify it >_>
- Change repl_exprs to run an expression and program parser in
parallel, rather than handling the parallelism on the grammar side -
that has a few shift/reduce conflicts which result in bad parse
errors.
- Bump Cobalt to 0.6.0. We now track both line and column numbers of
each bytecode instruction, allowing us to map an error to a concrete
position.
- `loadfile` (and similar functions) now use the full path, rather than
the file name. Cobalt truncates this to 30 characters (rather than
the previous 60) so this should be less noisy.
- The shell, edit and Lua REPL now display the corresponding source
code alongside an error.
Note this is incredibly limited right now - it won't cope with errors
which cross coroutine boundaries. Supporting this is on the roadmap,
but requires some careful API design.
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.
- Encode the DFA as a virtual machine (identical to lrgrep) rather than
compiling it to a series of Lua functions. While this is a little
slower and uglier, it's much more space efficient, shaving off 16Kb.
- Minimise the DFA properly. This only shaves off a few states, but
every little helps.
- Run the error handling code from a non-reduced parser stack. This was
incredibly nasty to get right (and positions are still not correctly
handled), but it fixes several broken error messages.
- 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.
- Add several (internal) modules for lexing and parsing Lua code. These
allow us to provide (hopefully) higher quality error messages than
Lua's built-in messages.
- `shell.run`, `edit` and `lua` now use this parser when fed invalid
code. This allows us to provide better syntax errors, while not
having any impact on the happy path.
Note this does not affect any other mechanism for loading code
(`load`, `require`, `dofile`).
There's still a lot of work to do here in improving error message
quality, but hopefully this provides a good starting point.
- 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.
