Doesn't fix#515 (arguably makes it worse in the sense that it's more
likely to throw). However it should provide better error reporting, and
make it more clear that it's not CC:T's fault.
It appears I had failed to update this when last bumping the Forge
version. Closes#521 - we're relying on a feature only added in Forge
31.1.16, and they're using 3.1.14.
Control characters become escaped as JSON requires
Non-ASCII characters get escaped as well for better interoperability
We assume here that lua strings represent only first 256 code points of unicode
We can just scrape them from the @AutoService annotation, which saves us
having to duplicate any work. Hopefully fixes#501, but I haven't tested
in a non-dev environment yet.
When dealing with invalid paths (for instance, ones which are too long
or malformed), Java may throw a FileSystemException. This contains the
absolute path (i.e. C:/Users/Moi/.../.minecraft/...), which is printed
to the user within CC - obviously not ideal!
We simply catch this exception within the MountWrapper and map it back
to the local path. The disadvantage of doing it here is that we can't
map the path in the exception back to the computer - we'd need to catch
it in FileMount for that - so we just assume it referrs to the original
path instead.
Doing it in FileMount ends up being a little uglier, as we already do
all the exception wrangling in FileWrapper, so this'll do for now.
Fixes#495
It's no longer possible to implement this on the tile, due to the
conflict in getType. Given this is a really bad idea, it's not a big
issue, but we should mention it in the documentation.
Fixes#496.
This PR adds some documentation for APIs that did not have docs in the
source yet. This includes the:
* drive peripheral
* FS API
* OS PAI
* printer peripheral
* speaker peripheral
illuaminate does not handle Java files, for obvious reasons. In order to
get around that, we have a series of stub files within /doc/stub which
mirrored the Java ones. While this works, it has a few problems:
- The link to source code does not work - it just links to the stub
file.
- There's no guarantee that documentation remains consistent with the
Java code. This change found several methods which were incorrectly
documented beforehand.
We now replace this with a custom Java doclet[1], which extracts doc
comments from @LuaFunction annotated methods and generates stub-files
from them. These also contain a @source annotation, which allows us to
correctly link them back to the original Java code.
There's some issues with this which have yet to be fixed. However, I
don't think any of them are major blockers right now:
- The custom doclet relies on Java 9 - I think it's /technically/
possible to do this on Java 8, but the API is significantly uglier.
This means that we need to run javadoc on a separate JVM.
This is possible, and it works locally and on CI, but is definitely
not a nice approach.
- illuaminate now requires the doc stubs to be generated in order for
the linter to pass, which does make running the linter locally much
harder (especially given the above bullet point).
We could notionally include the generated stubs (or at least a cut
down version of them) in the repo, but I'm not 100% sure about that.
[1]: https://docs.oracle.com/javase/9/docs/api/jdk/javadoc/doclet/package-summary.html
- Refer to this as "data" rather than "metadata". I'm still not sure
where the meta came from - blame OpenPeripheral I guess.
- Likewise, use getItemDetail within inventory methods, rather than
getItemMeta.
- Refactor common data-getting code into one class. This means that
turtle.getItemDetail, turtle.inspect and commands.getBlockInfo all
use the same code.
- turtle.getItemDetail now accepts a second "detailed" parameter which
will include the full metadata (#471, #452).
- Tags are now only included in the detailed list. This is a breaking
change, however should only affect one version (1.89.x) and I'm not
convinced that the previous behaviour was safe.
This allows for configuring the size of computers and pocket computers,
as well as the max size of monitors.
There's several limitations with the current implementation, but it's
still "good enough" for an initial release:
- Turtles cannot be resized.
- GUIs do not scale themselves, so "large" sizes will not render within
the default resolution.
This exposes a basic peripheral for any tile entity which does not have methods
already registered. We currently provide the following methods:
- Inventories: size, list, getItemMeta, pushItems, pullItems.
- Energy storage: getEnergy, getEnergyCapacity
- Fluid tanks: tanks(), pushFluid, pullFluid.
These methods are currently experimental - it must be enabled through
`experimental.generic_peripherals`. While this is an initial step towards
implementing #452, but is by no means complete.
Well, mostly. We currently don't do recipe serializers as I'm a little
too lazy. For items, blocks and TE types this does make registration
nicer - we've some helper functions which help reduce duplication.
Some types (containers, TEs, etc..) are a little less nice, as we now
must define the registry object (i.e. the WhateverType<?>) in a separate
class to the class it constructs. However, it's probably a worthwhile
price to pay.
No clue how we're going to do this for the dynamic peripheral system
if/when that ships, but this is a good first stage.
Like the Java APIs, this relies on stub files, so we can't link to the
implementation which is a bit of a shame. However, it's a good first
step.
