- Switch to using OptionalInt/OptionalLong instead of @Nullable
Long/Integers. I know IntelliJ complains, but it avoids the risk of
implicit unboxing.
- Instead of mutating PartialOptions, we now define a merge() function
which returns the new options. This simplifies the logic in
AddressRule a whole bunch.
This is a noisier diff than I'd like as this is just a direct copy from
the multi-loader branch.
- Rename "ingame" package to "gametest"
- Don't chain GameTestSequence methods - it's actually much cleaner if
we just use Kotlin's implicit this syntax.
- Use our work in 71f81e1201 to write
computer tests using Kotlin instead of Lua. This means all the logic
is in one place, which is nice!
- Add a couple more tests for some of the more error-prone bits of
functionality.
This is an initial step before refactoring this into a separate module.
It's definitely not complete - there's a lot of work needed to remove
referneces to the main ComputerCraft class for instance - but is a
useful first step.
I still don't really understand why the ROOT locale is wrong here, but
there we go. We'll need to remember to uncomment the tests on the 1.18
branch!
Also add some code to map tests back to their definition side. Alas,
this only links to the file right now, not the correct line :/.
This offers very few advantages now, but helps support the following in
the future:
- Reuse test support code across multiple projects (useful for
multi-loader).
- Allow using test fixture code in testMod. We've got a version of our
gametest which use Kotlin instead of Lua for asserting computer
behaviour.
We can't use java-test-fixtures here for Forge reasons, so have to roll
our own version. Alas.
- Add an ILuaMachine implementation which runs Kotlin coroutines
instead. We can use this for testing asynchronous APIs. This also
replaces the FakeComputerManager.
- Move most things in the .support module to .test.core. We need to use
a separate package in order to cope with Java 9 modules (again,
thanks Forge).
This allows other mods to create wired-modem alike blocks, which expose
peripherals on the wired network, without having to reimplement the main
modem interface.
This is not currently documented, but a peripheral_hub should provide
the following methods:
- isPresentRemote
- getTypeRemote
- hasTypeRemote
- getMethodsRemote
- callRemote
- Add a new file_transfer event. This has the signature
"file_transfer", TransferredFiles.
TransferredFiles has a single method getFiles(), which returns a list
of all transferred files.
- Add a new "import" program which waits for a file_transfer event and
writes files to the current directory.
- If a file_transfer event is not handled (i.e. its getFiles() method
is not called) within 5 seconds on the client, we display a toast
informing the user on how to upload a file.
- Use <p> everywhere. This is uglier, but also technically more
correct. This requires a version bump to cct-javadoc, and will give
me a massive headache when merging.
- Link against the existing OpenJDK docs.
We now wait for workers to terminate when closing the computer thread.
I'll be honest, I'm not happy with this code. Multi-threading is really
hard to get right, and I can't say I'm convinced this is especially well
behaved. I did look at trying to model this in TLA+, but in the end
decided it wasn't worth it.
In the future we probably want to split ComputerExecutor into two
objects, where one is our entry in the ComputerThread queue (and so
holds timing information) while the other is responsible for actual
execution.
- Correctly handle Git commands failing. We need an actual default
value, not just null!
- Use run/ and build/tmp/ for temporary test locations, not
/test-files.
- Switch over to the Gradle GH action. Not expecting massive changes,
but might provide some better caching.
- Bump some GH action versions.
- Fix a Java 8 compatability issue in our build scripts.
- Add a new Node plugin. This automatically installs npm dependencies
and provides a "NpxExecToDir" to dir task. This allows us to make the
doc website task dependencies a little nicer, by simply chaining
tasks together, rather than doing dependsOn + `input.files(the other
task output)`.
- Switch over to CurseForgeGradle from CurseGradle. The latter is
super clunky to use in non-Groovy languages.
- Copy our Modrinth description body to our repo, and add support for
syncing it. We'll still have to do CF manually I think.
Look, I don't enjoy having 600 LOC long build.gradle files, it's just
very easy to do! This at least moves some of the complexity elsewhere,
so the build script is a little more declarative.
It's more verbose as the default license plugin doesn't support multiple
license headers. However, it also gives us some other goodies (namely
formatting Kotlin and removing unused imports), so worth doing.
This converts ComputerThread from a singleton into a proper object,
which is setup when starting a computer, and tore down when the
ComputerContext is closed.
While this is mostly for conceptual elegance, it does offer some
concrete benefits:
- You can now adjust the thread count without restarting the whole
game (just leaving and rentering the world). Though, alas, no effect
on servers.
- We can run multiple ComputerThreads in parallel, which makes it much
easier to run tests in parallel. This allows us to remove our rather
silly IsolatedRunner test helper.
Computers now use a MainThreadScheduler to construct a
MainThreadScheduler.Executor, which is used to submit tasks. Our
previous (singleton) MainThread and MainThreadExecutor now implement
these interfaces.
The main purpose of this is to better manage the lifetime of the server
thread tasks. We've had at least one bug caused by us failing to reset
its state, so good to avoid those! This also allows us to use a fake
implementation in tests where we don't expect main thread tasks to run.
As we're now passing a bunch of arguments into our Computer, we bundle
the "global" ones into ComputerContext (which now also includes the Lua
machine factory!). This definitely isn't the nicest API, so we might
want to rethink this one day.
In some ways this isn't as nice as the Forge version (requires ATs,
doesn't check texture/model existence). However, it's more multi-loader
friendly and in some cases has much less boilerplate.
Blockstate JSON files are incredibly verbose, so we add a custom JSON
pretty printer which writes things in a slightly more compact manner.
This also changes how turtle upgrades are loaded - we now support
standard ResourceLocations (so computercraft:blocks/some_turtle_upgrade)
as well as ModelResourceLocations (computercraft:items/some_turtle_upgrade#inventory).
I don't think any resource packs need to touch our upgrades, but
apologies if this breaks anything.
- Convert remaining recipes over to datagen.
- Switch loot tables to use vanilla's loot table generator. It's
honestly not too different, just the earlier system confused me too
much :).
Alas, a positive diff because the JSON is so verbose. I've got a really
nice patch which makes the JSON more compact, but alas the Mixin doesn't
apply on 1.16 :(.
- Remove TrackingField and replace it with a Metric abstract class.
This has two concrete subclasses - Counter and Event. Events carry an
additional piece of data each time it is observed, such as HTTP
response size.
- Computers now accept a MetricsObserver, which tracks metrics for this
particular computer. This allows us to decouple Computer classes and
metrics information. The concrete MetricsObserver class we use within
Minecraft exposes the ServerComputer directly, so we no longer need to
do the awkward mapping and lookups!
- The /computercraft command can now do aggregates (count, avg, max)
over all Event metrics. This removes the need for special handling of
computer and server time.
There's also a small number of changes in removing the coupling between
Computer and some of its dependencies (ILuaMachine, MainThreadExecutor).
This makes some future refactorings easier, I promise!
This is a little odd (it's more complex for one!), but means we can
reuse the internal API interface in other classes, which is useful for
the data provider refactor I'm about to do.
This is much nicer in Java 17 :D (records, ServiceLoader.stream()),
but such is the perils of still targetting 1.16.
Jonathan Coates