- Allow TransformedModel to also hold a list of tints for the model.
- Update our turtle item colour provider to fetch tints from the
upgrade's TransformedModel.
This requires rewriting the quads in the upgrade model, mapping the
existing tint indices to (2 * tintIndex) + (left ? 1 : 2). We already
have to rewrite quads to apply transformations, so fortunately this
isn't too bad.
I have no clue how this is going to work on 26.3 though 😬.
- Add a custom turtle upgrade modeller for the storage upgrade that
applies the shulker tint colour.
- Add a new ThreadUtils.newReentrantLock/newReentrantReadWriteLock
functions. These use Guava's CycleDetectingLockFactory to create a
cycle-detecting lock in a development environment.
- Rename ForbiddenImports to ForbiddenAPIs, and forbid constructing
these instances directly, requiring you to go through ThreadUtils.
- Add support for extracting a ContainerTransfer from a container-like
item (shulkers, and in the future, bundles). For Forge we can just
use capabilities, but Fabric doesn't support this in 1.20, so we roll
our own there.
- Adds a new TurtleStorage peripheral, which allows transferring items
to/from these container-like items.
- Register a turtle storage upgrade for every shulker. This is
currently gated behind a datapack, as I want some time to mull on the
API, and don't want to ship this as a stable feature quite yet.
Closes#2213.
- Replace our existing ContainerTransfer class with a more general
ItemContainer. This supports all the functionality we need for our
inventory peripheral.
- Change AbstractInventoryMethod to use ContainerTransfer. This reduces
the duplicated code between the two InventoryMethod implementations
(well, somewhat) — they only now have to handle extracting
ContainerTransfers.
When we have a function with a type-variable target defined in an
abstract class, if we can resolve that to a concrete type in the
registered instance, then it's safe to use as a generic target.
For example:
abstract class Foo<T> { @LuaFunction public final void foo(T) { } }
class Bar<Qux> { } // Register foo(Qux)
Just to prove to myself that it works! Specifically, I have some
concerns with HTTP streaming about how that will interact with bandwidth
limits, so having this in place should make it easier to write further
tests.
7c60ed109f already proving useful. As we
no longer have any global state we can run these tests in parallel.
I wrote this ages ago when looking at alternative GPS arrays for #1681.
None of the designs I've tried seem any more reliable, and still have
some positions where they fail, hence this test being marked "pending".
- Split JSON and SNBT parsers up, and move them into their own
modules. While there is a lot of overlap, there's sufficient
difference it's not worth trying to keep them the same.
- Update SNBT parser to support most of 26.3's features.
Fixes#2277.
- Correctly send a close websocket frame when a websocket is manually
closed (status code 1000) or is garbage collected (1001). Computer
shutdowns still just close the socket, as we don't/can't wait for the
socket to cleanly shutdown.
- After a user calls close(), don't mark the websocket as closed until
we receive the server's close response. This means we now have a
slightly awkward interstitial state where we can receive messages but
not send them, but I don't think there's much we can do about that.
Fixes#2096
A bit simpler, means we don't have to poll it every tick.
I had one test failure in the websocket code where the websocket was
GCed and closed too early, so adding some reference fences in here. I've
not been able to reproduce this, so fingers crossed it works.
Add a new HttpHandler interface, which handles checkUrl, request and
websocket calls for a computer. The default implementation is provided
by a NettyHttp class, which also stores any related HTTP config and
state.
This is a little over-engineered, but has two advantages:
- Our Javascript/TeaVM implementation can now just implement this
interface, rather than patching/overwriting classes.
- This removes the final (large) bits of global state/config from
CC:T's core. Our tests no longer need to temporarily override global
address rules, and the traffic shaping handler no longer requires
resetting.
It might be a bit nicer to move all the netty-specific code into a
dan200.computercraft.apis.http.netty package, so there's some cleaner
separation from the common code, but I'm trying to avoid moving code
about any more than I have to.
Within our TeaVM code we currently do some class rewriting magic to
replace individual classes, such as ComputerThread. However, all our
code is written to allow changing these implementations already, it's
just TeaVM isn't smart enough to look through our builder and realise
it's dead code!
We now make the ComputerContext's constructor public (though
deprecated), which allows our TeaVM code to call it directly.
Unlike (Neo)Forge, Fabric's transfer API distinguishes between slotted
containers (such as chests) and non-slotted ones (such as bundles). Our
current code (and interface) currently assumes everything to have slots,
but for #2213, we need a way to support non-slotted containers.
We can't really change the interface here, so instead we go the other
route: treat the Iterable<StorageView<...>> as a list of slots. This is
pretty gross (which is why I've put it off for so long), but easy enough
to implement.
This is an identical fix to 013f2e500f,
but for computers rather than redstone integrators.
I don't love the duplication — it might make more sense to move this
into RedstoneState.updateOutput and have an "initial tick" flag there
instead.
Fixes#2392.
- Fix missing license header and some over-eager gitignore removals.
- Fix several isolated project errors. I think all the remaining ones
come from limitations in other projects:
- MDG's mod configs don't support referencing source sets from other
projects.
- idea-ext is terrible in every way.
There's some nastiness in MergeTrees where we can't do
`resources.elements.map { it.single() }` as it throws a configuration
cache error, so we now use a ConfigurableFileCollection. Somehow it
still works.
- Fix a whole bunch of ErrorProne warnings. It's still quite noisy, but
most of the remaining ones now come from Java.
- Move some config from java-conventions to a new base-conventions,
which can be used for non-Java projects. As part of this, we now kill
the CCTweaked plugin, and just install the cct extension in
base-conventions instead.
- Kill inlineProject/externalSources. We now:
- Add an embeddedProject configuration which is used to define
projects that are embedded within the final jar. We do some fun
variant resolution in ExternalProjectArtifacts to extract the
class/resource/source directories from the configuration.
- Add a new verifyClassesMatch task which recompiles the game and
ensures compiling everything against the loader's version of
Minecraft gives us the same result.
There's some really awkward duplication in the HTTP API right now, where
the Lua code reimplements the validation the Java implementation
provides, in order to throw errors at the right level.
In this particular case, our Lua validation was stricter than the Java,
only permitting a known set of verbs. This commit:
- Makes the Java-side validation a little stricter, to only allow verbs
matching [A-Z_-]{1,32}. This is strictly much stricter than what the
HTTP spec allows, but I think makes sense as a restriction.
- Update the Lua wrapper to match this logic, rather than being
stricter.
Fixes#2501.
- Fix *some* cross-project isolation issues. This appears to be the
bare minimum to make the configuration cache happy. There is
obviously a lot more work to do here.
- Enable Configuration cache.
- Fix some new checkstyle/errorprone/nullaway warnings.
Using typos[^1]. I wrote a config for this years ago, but never checked
it in. All things considered, there's fewer than I expected.
Fun fact: the CCPL contains the text "if added to to the main
repository", and I can't/shouldn't fix it, because it's an external
license!
[^1]: https://github.com/crate-ci/typos/
This dates back from when we had multiple MC versions in a single
project (see the build-tools branch). We don't do this any more, so no
need for it.
(More importantly, something has changed in IDEA/Gradle so that the
1.20.1 now is escaped as 1_20_1, which breaks Fabric Loom).
When we resume a process, the code looks like:
resumeProcess(nCurrentProcess, ...)
if cullProcess(nCurrentProcess, ...) then ... end
However, if the focused tab changes while resuming (via
multishell.setFocus), then we don't cull the correct process!
To fix this, we just add a helper function which resumes+culls, meaning
we only read the mutable global once.
The "type" field definitions for the "edit.autocomplete" and
"lua.autocomplete" settings were both randomly indented, compared to the
rest of the setting definitions.
Just clarify a couple of things which are a little confusing.
- Explicitly initialise the position within deployOnEntity, rather than
relying on getWithPosition above.
- Rename "position" to "blockPos" in deployOnBlock to make it clearer
whose position it is.
- Clarify that we need to call use(...) for all directions.
When we upgrade a normal pocket computer to an advanced one, we need to
create a new ServerComputer instance (and destroy the old one).
On 1.20.1 the ComputerUpgradeRecipe does not preserve the
instance/session ID on the resulting stack. When the item is next
ticked, we create a new computer, with the old computer no longer being
kept alive and eventually dying.
On 1.21.1 we copy all components, *including* the the current computer
reference. This means a new computer is never created and so we continue
to use the old one (with the wrong family). We could exclude the
computer component from the recipe (and so have the same behaviour as
1.20.1), but by adding a hook in onCraftedBy we can destroy the old
computer immediately, ensuring it no longer continues to run.
Fixes#2479.
Jonathan Coates