This is sufficiently useful a class, that it's worthwhile exposing it.
Hopefully we can slowly encourage other mods to migrate to it (well, at
least in 1.14), and so make error messages more consistent.
Also:
- Add Javadoc for all public methods
- Clarify the method names a little (getNumber -> getDouble,
getReal -> getFiniteDouble).
- Make the *Table methods return a Map<?,?> instead of
Map<Object, Object>.
Previously we were just returning the current tile. However, if someone
was holding a reference to this inventory (such as a GUI), then it'd be
outdated and invalid once the turtle had moved.
This caused a couple of issues:
- turtle_inventory events would not be fired when moving items in the
turtle GUI.
- As of 75e2845c01, turtles would no
longer share their inventory state after moving. Thus, removing items
from a GUI using an invalid inventory would move them from an old
tile, duplicating the items.
Fixes#298, fixes#300
Closes#293. Doesn't really solve anything there aside from exposing the
number, but sadly there's not really anything obvious I can do on my end
- the command API just doesn't expose anything else.
- Adds cc.completions module, with a couple of helper functions for
working with the more general completion functionality (i.e. that
provided by read).
- Adds cc.shell.completions module, which provides shell-specific
completion functions.
- Add a "program completion builder", which allows you to write stuff
like this:
shell.setCompletionFunction( "rom/programs/redstone.lua",
completion.build(
{ completion.choice, { "probe", "set ", "pulse " } },
completion.side) )
Closes#232
It appears several mods inject their own drops on the LOWEST priority,
meaning that we capture the existing drops, and the other mod will clear
the (now empty) drop list and add its own, resulting in dupe bugs.
While I'd argue it's somewhat dubious doing this on the LOWEST priority,
it's not a battle I'm prepared to fight. For now, we just remove the
block/entity drop handlers, and handle all drop logic when entities are
spawned.
Fixes#288
This is the behaviour on 1.14 already, so it makes sense to backport to
1.12.
Any mod may now insert files into assets/computercraft/lua/rom, and
they'll be automatically added to the default ROM mount. This allows
other mods to easily register new programs or autorun files.
See #242
Lua 5.2+ uses loadfile(filename, mode, env), not loadfile(filename,
env). While this is a minor incompatibility, it'd be nice to be
consistent as much as possible.
We try to handle the incorrect case too, as obviously we don't want to
break existing programs.
This moves expect from the bios into a new craftos.expect module,
removing the internal _G["~expect"] definition. Apparently people were
using this irrespective of the "don't use this" comment, so we need to
find another solution.
While this does introduce some ugliness (having to load the module in
weird ways for programs, duplicating the expect function in memory), it
does allow people to use the function in a supported way, and removes
the global ugliness.
Equivalent to `pastebin run`, but allows running arbitrary URLs
instead.
Is this a little questionable? Yes - people shouldn't be downloading
and running code from the internet. But hey, people do that already,
so we might as well make it convenient.
- Adds a CheckStyle configuration which is pretty similar to CC's
existing one.
- Add the Gradle license plugin.
- Ensure the existing source code is compatible with these additional
checks.
See #239
- Convert existing changelog over to use Markdown. This mostly involves
wrapping code in backticks, and marking things as headers where
appropriate.
- Copy all of CC:T's release notes over to the changelog. This is
somewhat more verbose than Dan's notes, but keeping them in sync
seems reasonable (and allows for automation!).
As 'require' operates relative to the current program's directory,
rather than the current directory, it meant we were trying to load files
from /rom/programs.
This is never a good idea, so we add the current directory to the
package path, allowing you to use require as one'd expect.
- Define an expect(index, actual_value, types...) helper function which
takes an argument index, value and list of permissable types and
ensures the value is of one of those types.
If not, it will produce an error message with the expected and actual
type, as well as the argument number and (if available) the function
name.
- Expose expect in the global scope as _G["~expect"], hopefully making
it clear it is internal.
- Replace most manual type checks with this helper method.
- Write tests to ensure this argument validation works as expected
Also fix a couple of bugs exposed by this refactor and the subsequent
tests:
- Make rednet checks a little more strict - rednet.close(false) is no
longer valid.
- Error when attempting to redirect the terminal to itself
(term.redirect(term)).
This only renders the bounding box on non-screen edges of the monitor,
meaning you have an uninterrupted view of the screen when hovering
hover.
Closes#219
