- 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/
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.
- Check whether impostor recipes (and other custom shaped/shapeless
recipes) match the "real" recipe.
- Check whether our upgrade recipe generator generates valid recipes.
Reasoning about left/right upgrades (and top/back ones on 26.2) is a
bit confusing, so this should prevent any errors.
- Add a new LuaTable.get(int) overload to handle getting an integer key
instead.
- Update CobaltLuaMachine for more sensible Java->LuaValue conversion
for looking up keys.
- Add some tests for our two LuaTable implementations.
- Randomly reformat two files because spotless is ???
Fixes#2430
- Add (very basic) details provider for entities.
- Add commands.getEntity(selector) function, which gets details for all
matching entities.
Fixes#2383
This should avoid allocating slightly less memory *in some cases*. I
dare say there's still ways to OOM here. But also, if you want to OOM
the server, you don't need to place a sign to do it!
Closes#2365.
We removed onNeighborChange in 676fb5fb53,
on the basis that this was no longer needed for peripheral updates.
However, it *is* required for redstone updates, as MoreRed does not
trigger any block updates for bundled cables.
Fixes#2316.
I do not like the flow of this page, but did not know how better to
structure it.
We really need a way to write things which use the same type syntax as
parameters. I don't like how this (and events!) are formatted so
differently. It'll do for now though.
There's some nasty hacks here around potion durations on other items.
This should get a bit cleaner in newer versions of the game, once we
switch to data components.
Fixes#2266.
Fixes#2332.
I *think* what's going on here is:
- When we place a block with the turtle, we copy items between the
turtle's inventory and the fake player's inventory. We *don't* clear
items from the fake player's inventory after placing, as we'll do it
next time we use the fake player.
- At the start of the next tick, Stack Refill then loops over the
fake player's inventory and moves some items around. However, because
we just set the items directly (rather than using .copy()), this
mutates the items in the turtle's inventory too!
To fix this, we just clear the player's inventory after finishing with
it, so Stack Refill never sees these items.
- Shuffle some of the accessors in PocketComputerItem around, to make
them easier to use in the lectern code.
I still don't think we've got a good interface here. We could
possibly move more of the update code into PocketBrain, and just have
PocketComputerItem responsible for syncing brain<->stack
state. Something to fiddle with, but not sure it would be any
cleaner.
- Set the bottom peripheral when the pocket computer is placed in the
lectern (and on block updates, etc...), and clear it when removed.
Again, the code here is uglier than I would like (particularly with
all the instanceofs). I did wonder about having some LecternBehaviour
class, which holds the printout/pocket-specific state, but there's so
many places we need to hook in (and they're so different between the
two), I'm not sure it's worth it right now.
Fixes#2126, closes#2223.
We now forcibly update all redstone inputs/outputs when the relay is
first placed.
It's not entirely clear to me if this is the right solution. The
alternative one would be to persist the redstone state instead. However,
most peripherals do *not* do this (e.g. monitor, speaker), so let's
match that for now.
Fixes#2175.
Ideally we'd be able to support right clicking on anything when we have
a NoTermComputerScreen open. However, that's incredibly awkward to do
(see c45fc94752, and discussion in #2160),
so instead we create a new PocketComputerLecternScreen, which handles
mouse events.
We need to do some awkward converting the player's position and look
vector into the terminal's coordinate space, and then projecting it onto
the terminal screen, but otherwise this is fairly straightforward.
Closes#2330.
Hey, it lasted almost a year!
Computer input is somewhat stateful, as we need to track things like
which key(s) are currently held, and what the last mouse button/position
was. This code is currently duplicated in several places (specifically
TerminalWidget, ServerInputState and the standalone emulator).
In order to implement lectern pocket computer mouse interactions, we'd
have to duplicate this logic once again. Instead, we move this code into
a common class.
- Replace the InputHandler interface with a simpler ComputerInput one
(this no longer has computer actions, like reboot or terminate). This
interface never made much sense (aside from hiding implementation
details), as code only ever consumed a single implementation of it.
On the client, this requires a new "ClientComputerActions" class.
This feels a bit clunky to me, but it's simple and it works.
- Replace ComputerEvents with a EventComputerInput class (terrible
name, I know!), which queues events on a computer.
- Move common input state tracking and validation into a single
UserComputerInput class, which wraps an existing ComputerInput. This
is used by both the terminal widget, and the server-side input state.
- Update to Loom 1.12. This requires Java 21, so we now build with Java
21, but targetting 17. The new "-release" flag does make this much
easier, so hopefully shouldn't cause too many issues.
- Bump versions of a lot of other things.
- Fix various errorprone/checkstyle grumbles.
This *shouldn't* be needed, as the compartment index is always >= 0, and
Inventory.getItem returns an empty stack if the item is not found.
However, some mods pass a negative compartment index, which causes
getItem to throw an AIOOB instead.
Fixes#2267
Apparently this has been broken since the file was created in
53546b9f57d9acaa4cdca14ae00eaf68ce8c50bd!? I'm sure I fixed this before,
but maybe that was a different but similar issue >_>.
Convert GLFW's key codes back to their actual key, and then use that
when checking keyboard shortcuts. We *don't* do this for the paste key,
just to be consistent with vanilla's behaviour.
Fixes#2207.
Every few years I get confused about which side turtle upgrades go on
when crafting. The fact that it's flipped always throws me! Let's add a
comment to the recipe, and add some tests to reassure myself.
Reverts 76968f2f28. We'd originally added
this to gather some numbers for #1580, with the hope that it would also
be useful for server admins. Sadly, it's not as accurate as I originally
hoped — the number sometimes goes down for unclear reasons (something to
do with the TLAB maybe??).
Closes#1739.
Jonathan Coates