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.
Awww no, here we go again.
The Forge/Fabric versions are identical again, but keeping them separate
for now, as I'm a) lazy and b) not convinced they won't diverge again.
Fixes#2311
- Accept the full range of unquoted strings
- Fix error when failing to parse an unquoted string
See #2277. This is not sufficient to close the issue (wow, there's so
much more wrong with the code), but at least stops unserialiseJSON
crashing.
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
This doesn't work with getTableUnsafe, as empty arguments are considered
closed already. We could argubly special-case the empty args, but the
optimisation has very minor benefits, so I don't think worrying about too
much.
Fixes#2246.
I don't love the implementation of this (see discussion in #2220), but
it's better than nothing. Wow, the editor really needs a bit of a
rewrite, the code is kinda messy.
Fixes#1396.
I've been putting this off for a while, as I had issues in the past with
people using old Node versions (e.g. #1806), but it no long works on my
machine, so time to make the switch.
Also do a bit of a package update. Hit a rollup bug while doing this
(https://github.com/rollup/plugins/issues/1877), so holding that update
back for now.
This is slightly more accurate for long strings and comments. Note that
we still work a line at a time (and in a non-incremental manner), so
doesn't actaully support multi-line strings (#1396).
We do now treat goto as a keyword (fixes#1653). We don't currently
support labels — those *technically* aren't a token (`:: foo --[[ a
comment ]] ::` is a valid label!), but maybe we could special-case the
short `::foo::` form.
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.
Jonathan Coates