Name a more iconic duo than @SquidDev and over-engineered test
frameworks.
This uses Minecraft's test core[1] plus a home-grown framework to run
tests against computers in-world.
The general idea is:
- Build a structure in game.
- Save the structure to a file. This will be spawned in every time the
test is run.
- Write some code which asserts the structure behaves in a particular
way. This is done in Kotlin (shock, horror), as coroutines give us a
nice way to run asynchronous code while still running on the main
thread.
As with all my testing efforts, I still haven't actually written any
tests! It'd be good to go through some of the historic ones and write
some tests though. Turtle block placing and computer redstone
interactions are probably a good place to start.
[1]: https://www.youtube.com/watch?v=vXaWOJTCYNg
ForgeGradle (probably sensibly) yells at me about doing this. However:
- There's a reasonable number of mods doing this, which establishes
some optimistic precedent.
- The licence update in Aug 2020 now allows you to use them for
"development purposes". I guess source code counts??
- I'm fairly sure this is also compatible with the CCPL - there's an
exception for Minecraft code.
The main motivation for this is to make the Fabric port a little
easier. Hopefully folks (maybe me in the future, we'll see) will no
longer have to deal with mapping hell when merging - only mod loader
hell.
.getMethods() may throw if a method references classes which don't exist
(such as client-only classes on a server). This is an Error, and so is
unchecked - hence us not handling it before.
Fixes#645
- Fix doc library-path
- Only style <pre> code blocks as executable. Skip <code> ones.
- Document the default parameters in gps. Yes, we should do it
everywhere, but one has to start somewhere!
This has been broken for almost a year (28th Jan 2020), and I never
noticed. Good job me.
Fixes#641, closes#648 (basically the same, but targetting 1.15.x)
- Generate theme-color. Hopefully this time it works!
- Specify a site url. Technically this is wrong (we should use the
current git branch), but it's good enough for now.
- Move some options into a sub-category.
I knew I shouldn't do modding on things which aren't my main computer.
I actually did run checkstyleMain before committing, but entirely forgot
about this one. Go me.
- Move some common upgrade code to IUpgradeBase. 99% sure this this
preserves binary compatibility (on the JVM at least).
- Instead of requiring the share tag to match, allow upgrades to
specify their own predicate. IMO this is a little ugly, but required
to fix#614 as other mods chuck their own NBT on items.
- Remove incorrect impostor recipes for pocket computers. We were
generating them from the list of turtle upgrades instead!
- Fix JEI plugin not blocking impostor recipes as of the data-generator
rewrite.
As explained in the comment, "built-in" rendering types are now manually
rendered ("finish"ed) before calling finish() on the main renderer. This
means our depth blocker hasn't actually been drawn (if a monitor is the
last TE to be rendered), and so blocks pass the depth test when they
shouldn't.
Fixes#599
Maybe the capability system was a mistake in retrospect, as we don't
store the peripheral outside, so there's no way to reuse it. That will
probably come in a later change.
As a smaller fix, we pass the invalidate listener directly. The lifetime
of this is the same as the computer, so we don't create a new one each
time.
There's still the potential to leak memory if people break/replace a
computer (as listeners aren't removed), but that's an unavoidable flaw
with capabilities.
Fixes#593
