- Update EMI and REI integration, and fix some issues with the upgrade
crafting hooks.
- Just use smooth stone for recipes, not #c:stone. We're mirroring
redstone's crafting recipes here.
- Some cleanup to printouts.
- Remote upgrade data generators - these can be replaced with the
standard registry data generators.
- Remove the API's PlatformHelper - we no longer have any
platform-specific code in the API.
- Use TinyRemapper to remap mixins on Fabric. Mixins in the common
project weren't being remapped correctly.
- Update to latest NeoForge
- Switch to the new tick events.
- Call refreshDimensions() in the fake player constructor.
NF now loads mods from neoforge.mods.toml rather than mods.toml, so CC
wasn't actually being loaded. Tests all passed, because they didn't get
run in the first place!
- Update Gradle to 8.7
- Configure IntelliJ to build internally, rather than delgating to
Gradle. We've seen some weird issues with using delegated builds, so
best avoided.
- Remove gitpod config. This has been broken for a while (used Java 16
rather than 17) and nobody noticed, so I suspect nobody uses this.
- Add the core TeaVM jar to the runtime the classpath, to ensure
various runtime classes are present.
- Fix computer initialisation errors not being displayed on the screen.
The terminal was set to the default 0x0 size when logging the error,
and so never displayed anything!
Rather than handling right clicks within the block entity code, we now
handle it within the block. Turtles now handle the nametagging
behaviour themselves, rather than overriding canNameWithTag.
This fixes several issues with @Nullable fields not being checked. This
is great in principle, but a little annoying in practice as MC's
@Nullable annotations are sometimes a little overly strict -- we now
need to wrap a couple of things in assertNonNull checks.
- Mention the timer event in os.startTimer. Really we should have a
similar example here too, but let's at least link the two for now.
- Fix strftime link
BYTECODE WAS NOT SUPPOSED TO BE REWRITTEN
YEARS OF DEBUGGING REMAPPING FAILURES yet NO ACTUAL SOLUTION FOUND.
Wanted to use Mixins for anyway for a laugh? We had a tool for that: it
was called "FABRIC LOOM".
"Yes, please produce completely broken jars for no discernable reason"
Statements dreamed up by the utterly Deranged.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
This removes our two mixins used on Forge:
- Breaking progress for cabled/wired modems.
- Running client commands from chat click events. We now suggest the
command on Forge instead.
Occasionally we get issues where the mixin annotation processor doesn't
write its tsrg file in time for the reobfJar/reobfJarJar task. I thought
we'd fixed that cb8e06af2a, but sometimes
we still produce missing jars - I have a feeling this might be to do
with incremental compilation.
We can maybe re-evaluate this on 1.20.4, where we don't need to worry
about remapping any more.
- Replace usages of WiredNetwork.connect/disconnect/remove with the
WiredNode equivalents.
- Convert "testLarge" into a proper JMH benchmark.
- Don't put a peripheral on every node in the benchmarks. This isn't
entirely representative, and means the peripheral juggling code ends
up dominating the benchmark time.
I didn't make a new years resolution to stop writing build tooling, but
maybe I should have.
This replaces our use of VanillaGradle with a new project,
VanillaExtract. This offers a couple of useful features for multi-loader
dev, including Parchment and Unpick support, both of which we now use in
CC:T.
- Debug hooks are now correctly called for every function.
- Fix several minor inconsistencies with debug.getinfo.
- Fix Lua tables being sized incorrectly when created from varargs.
- Update FG to 6.0.20 - no major changes, but required for the Gradle
update.
- Update Loom to 1.5.x - this adds Vineflower support by default, so we
can remove loom-vineflower.
- Add a check to ensure declared dependencies in the :core project, and
those inherited from Minecraft are the same.
- Compute the next Cobalt version, rather than specifying it manually.
- Add the gradle versions plugin (and version catalog update), and
update some versions.
This commit adds abstract classes to describe the interface for our
mod-loader-specific generic peripherals (inventories, fluid storage,
item storage).
This offers several advantages:
- Javadoc to illuaminate conversion no longer needs the Forge project
(just core and common).
- Ensures we have a consistent interface between Forge and Fabric.
Note, this does /not/ implement fluid or energy storage for Fabric. We
probably could do fluid without issue, but not something worth doing
right now.
- Update Cobalt to 0.8.0, switching our Lua version to 5.2(ish).
- Remove our `load` wrapper, as we no longer need to inject _ENV into
the enviroment table.
- Update the parser to handle labels and goto. This doesn't check that
gotos are well formed, but at least means the parser doesn't fall
over on them.
- Update our docs to reflect the changes to Cobalt.
Does it count as an emulator when it's official? I hope not, as this'd
make it my fourth or fifth emulator at this point.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Developing/debugging CraftOS is a massive pain to do inside Minecraft,
as any change to resources requires a compile+hot swap cycle (and
sometimes a `/reload` in-game). As such, it's often more convenient to
spin up an emulator, pointing it to load the ROM from CC:T's sources.
However, this isn't practical when also making changes to the Java
classes. In this case, we either need to go in-game, or build a custom
version of CCEmuX.
This commit offers an alternative option: we now have our own emulator,
which allows us to hot swap both Lua and Java to our heart's content.
Most of the code here is based on our monitor TBO renderer. We probably
could share some more of this, but there's not really a good place for
it - feels a bit weird just to chuck it in :core.
This is *not* a general-purpose emulator. It's limited in a lot of
ways (won't launch on Mac[^1], no support for multiple computers) - just
stick to what's there already.
[^1]: We require OpenGL 4.5 due to our use of DSA.
Historically we've used copy-cat to provide a web-based emulator for
running example code on our documentation site. However, copy-cat is
often out-of-date with CC:T, which means example snippets fail when you
try to run them!
This commit vendors in copy-cat (or rather an updated version of it)
into CC:T itself, allowing us to ensure the emulator is always in sync
with the mod.
While the ARCHITECTURE.md documentation goes into a little bit more
detail here, the general implementation is as follows
- In project/src/main we implement the core of the emulator. This
includes a basic reimplementation of some of CC's classes to work on
the web (mostly the HTTP API and ComputerThread), and some additional
code to expose the computers to Javascript.
- This is all then compiled to Javascript using [TeaVM][1] (we actually
use a [personal fork of it][2] as there's a couple of changes I've
not upstreamed yet).
- The Javascript side then pulls in the these compiled classes (and
the CC ROM) and hooks them up to [cc-web-term][3] to display the
actual computer.
- As we're no longer pulling in copy-cat, we can simplify our bundling
system a little - we now just compile to ESM modules directly.
[1]: https://github.com/konsoletyper/teavm
[2]: https://github.com/SquidDev/teavm/tree/squid-patches
[3]: https://github.com/squiddev-cc/cc-web-term
When the target method is in a different class loader to CC, our
generated method fails, as it cannot find the target class. To get
around that, we create a MethodHandle to the target method, and then
inject that into the generated class (with Java's new dynamic constant
system). We can then invoke the MethodHandle in our generated code,
avoiding any references to the target class/method.
I removed this in aa0d544bba, way back in
late 2021. Looks like it's been updating in the meantime and I hadn't
noticed, so add it back.
I've simplified the code a little bit, to make use of our new capability
helpers, but otherwise it's almost exactly the same :D.
- 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.
- Support printing and parsing hex float literals
- Fix string.format "%q"'s handling of nan and inf (Kan18)
- Fix string is-letter/is-digit patterns treating characters as
unicode.
- tostring(...) now uses __name.
Jonathan Coates