This is an identical fix to 013f2e500f,
but for computers rather than redstone integrators.
I don't love the duplication — it might make more sense to move this
into RedstoneState.updateOutput and have an "initial tick" flag there
instead.
Fixes#2392.
- Fix missing license header and some over-eager gitignore removals.
- Fix several isolated project errors. I think all the remaining ones
come from limitations in other projects:
- MDG's mod configs don't support referencing source sets from other
projects.
- idea-ext is terrible in every way.
There's some nastiness in MergeTrees where we can't do
`resources.elements.map { it.single() }` as it throws a configuration
cache error, so we now use a ConfigurableFileCollection. Somehow it
still works.
- Fix a whole bunch of ErrorProne warnings. It's still quite noisy, but
most of the remaining ones now come from Java.
- Move some config from java-conventions to a new base-conventions,
which can be used for non-Java projects. As part of this, we now kill
the CCTweaked plugin, and just install the cct extension in
base-conventions instead.
- Kill inlineProject/externalSources. We now:
- Add an embeddedProject configuration which is used to define
projects that are embedded within the final jar. We do some fun
variant resolution in ExternalProjectArtifacts to extract the
class/resource/source directories from the configuration.
- Add a new verifyClassesMatch task which recompiles the game and
ensures compiling everything against the loader's version of
Minecraft gives us the same result.
There's some really awkward duplication in the HTTP API right now, where
the Lua code reimplements the validation the Java implementation
provides, in order to throw errors at the right level.
In this particular case, our Lua validation was stricter than the Java,
only permitting a known set of verbs. This commit:
- Makes the Java-side validation a little stricter, to only allow verbs
matching [A-Z_-]{1,32}. This is strictly much stricter than what the
HTTP spec allows, but I think makes sense as a restriction.
- Update the Lua wrapper to match this logic, rather than being
stricter.
Fixes#2501.
- 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/
This dates back from when we had multiple MC versions in a single
project (see the build-tools branch). We don't do this any more, so no
need for it.
(More importantly, something has changed in IDEA/Gradle so that the
1.20.1 now is escaped as 1_20_1, which breaks Fabric Loom).
When we resume a process, the code looks like:
resumeProcess(nCurrentProcess, ...)
if cullProcess(nCurrentProcess, ...) then ... end
However, if the focused tab changes while resuming (via
multishell.setFocus), then we don't cull the correct process!
To fix this, we just add a helper function which resumes+culls, meaning
we only read the mutable global once.
The "type" field definitions for the "edit.autocomplete" and
"lua.autocomplete" settings were both randomly indented, compared to the
rest of the setting definitions.
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.
Now we just use builtin INetAddress predicates or HostRange, rather than
a mix of custom predicates, sets and HostRange.
Also add some other ranges from the reserved list, and link to that list
to make it a bit easier to find stuff in the future.
I don't konw if this actually matters, but better safe than sorry.
Everything here confuses me — my understanding of RFC 6052 was that
private IP addresses cannot be used with NAT64, but AWS apparently
allows it? Not sure if I or Amazon is wrong (or both!).
- Split implementation of `parallel.waitFor{All,Any}` up. Their
implementations are now sufficiently complicated it doesn't make
sense to share the core.
- Support spawning new functions from within `parallel.waitForAll`.
- Flesh out the `parallel.waitForAll` docs a little.
Jonathan Coates