This is a long way away from "feature complete" as it were. However,
it's definitely at a point where it's suitable for general usage - I'm
happy with the API, and don't think I'm going to be breaking things any
time soon.
That said, things aren't exposed yet for Java-side public consumption. I
was kinda waiting until working on Plethora to actually do that, but not
sure if/when that'll happen.
If someone else wants to work on an integration mod (or just adding
integrations for their own mod), do get in touch and I can work out how
to expose this.
Closes#452
Minecraft propagates "strong" redstone signals (such as those directly
from comparators or repeaters) through solid blocks. This includes
computers, which is a little annoying as it means one cannot feed
redstone wire from one side and a repeater from another.
This changes computers to not propagate strong redstone signals, in the
same way transparent blocks like glass do.
Closes#548.
The HTTP filtering system becomes even more complex! Though in this
case, it's pretty minimal, and definitely worth doing.
For instance, the following rule will allow connecting to localhost on
port :8080.
[[http.rules]]
host = "127.0.0.1"
port = 8080
action = "allow"
# Other rules as before.
Closes#540
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.
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.
I'm really not very good at this modding lark am I? I've done a basic
search for other missing methods, and can't see anything, but goodness
knows.
Fixes#480
When calling .flip(), we limit the size of the buffer. However, this
limit is not reset when writing the next time, which means we get
out-of-bounds errors, even if the buffer is /technically/ big enough.
Clearing the buffer before drawing (rather than just resetting the
position) is enough to fix this.
Fixes#476 (and closes#477, which is a duplicate)
We never added back replacing of ${version} strings, which means that CC
was reporting incorrect version numbers in _HOST, the user agent and
network versions. This meant we would allow connections even on
mismatched versions (#464).
We shift all version handling into ComputerCraftAPI(Impl) - this now
relies on Forge code, so we don't want to run it in emulators.
This is simply exposed as a table from tag -> true. While this is less
natural than an array, it allows for easy esting of whether a tag is
present.
Closes#461
- Use texture over texture2D - the latter was deprecated in GLSL 1.30.
- Cache the tbo buffer - this saves an allocation when monitors update.
Closes#455. While the rest of the PR has some nice changes, it
performs signlificantly worse on my system.
This moves monitor networking into its own packet, rather than serialising
using NBT. This allows us to be more flexible with how monitors are
serialised.
We now compress terminal data using gzip. This reduces the packet size
of a max-sized-monitor from ~25kb to as little as 100b.
On my test set of images (what I would consider to be the extreme end of
the "reasonable" case), we have packets from 1.4kb bytes up to 12kb,
with a mean of 6kb. Even in the worst case, this is a 2x reduction in
packet size.
While this is a fantastic win for the common case, it is not abuse-proof.
One can create a terminal with high entropy (and so uncompressible). This
will still be close to the original packet size.
In order to prevent any other abuse, we also limit the amount of monitor
data a client can possibly receive to 1MB (configurable).
