We don't actually use this functionality in other projects (e.g.
emulators). In fact the method to add new APIs only exists in the mod
itself!
We still need some mechanism to remove mounts when the computer is
shutdown. We add a new ApiLifecycle interface (with startup and
shutdown hooks), and use those in the ComputerSystem impl.
This avoids us having to support requireless environments inside
cc.strings.
I do kinda wonder if os.loadAPI-loaded files should also have their own
shared "require", just so we're not loading 10 copies of cc.expect.
Build system:
- Switch to our new maven server. This has a cleaner separation between
published packages and mirrored packages, to avoid leaking those into
other people's builds.
- Update Gradle and Loom versions.
Code:
- Link to definitions instead in the breaking changes page.
- Fix several unused variable warnings.
Other:
- Remove unsupported Minecraft versions from the issue template.
- 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.
- 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
Due to the asynchronous nature of main-thread tasks, it's possible for
them to be executed on peripherals which have been detached. This has
been known for a long time (#893 was opened back in 2021), but finding a
good solution here is tricky.
Most of the time the method will silently succeed, but if we try to
interact with an IComputerAccess (such as in inventory methods, as seen
in #1750), we throw a NotAttachedException exception and spam the logs!
This is an initial step towards fixing this - when calling a peripheral
method via peripheral.call/modem.callRemote, we now wrap any enqueued
main-thread tasks and silently skip them if the peripheral has been
detached since.
This means that peripheral methods may start to return nil when they
didn't before. I think this is *fine* (though not ideal for sure!) - we
return nil if the peripheral has been detached, so it's largely
equivalent to that.
This feels a little overkill, but nice to standardise how this code
looks.
There's a bit of me which wonders if we should remove
IPeripheral.equals, and just use Object.equals, but I do also kinda like
the explicitness of the current interface? IDK.
The original runtime error reporting PR[^1] added a "cc.exception"
module, which allowed coroutine managers (such as parallel) to throw
rich errors, detailing the original context where the error was thrown.
Unfortunately, the change to parallel broke some programs (>_>, don't do
string pattern matching on your errors!), and so had to be reverted,
along with the cc.exception module.
As a minimal replacement for this, we add support for user-thrown
exceptions within our internal code. If an error object "looks" like an
exception ("exception" __name, and a message and thread field), then we
use that as our error information instead.
This is currently undocumented (at least in user-facing documentation),
mostly because I couldn't figure out where to put it - the interface
should remain stable.
[^1]: https://github.com/cc-tweaked/CC-Tweaked/pull/1320
