2017-05-07 00:18:59 +00:00
|
|
|
/*
|
2017-05-01 13:32:39 +00:00
|
|
|
* This file is part of ComputerCraft - http://www.computercraft.info
|
2020-01-01 00:09:18 +00:00
|
|
|
* Copyright Daniel Ratcliffe, 2011-2020. Do not distribute without permission.
|
2017-05-01 13:32:39 +00:00
|
|
|
* Send enquiries to dratcliffe@gmail.com
|
|
|
|
|
*/
|
|
|
|
|
package dan200.computercraft.shared.turtle.apis;
|
|
|
|
|
|
Replace getMethodNames/callMethod with annotations (#447)
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
|
|
|
import dan200.computercraft.api.lua.*;
|
2017-05-01 13:32:39 +00:00
|
|
|
import dan200.computercraft.api.turtle.ITurtleAccess;
|
|
|
|
|
import dan200.computercraft.api.turtle.ITurtleCommand;
|
2018-12-26 09:21:33 +00:00
|
|
|
import dan200.computercraft.api.turtle.TurtleCommandResult;
|
2017-05-01 13:32:39 +00:00
|
|
|
import dan200.computercraft.api.turtle.TurtleSide;
|
2018-02-16 10:33:32 +00:00
|
|
|
import dan200.computercraft.api.turtle.event.TurtleActionEvent;
|
2019-03-27 20:58:00 +00:00
|
|
|
import dan200.computercraft.api.turtle.event.TurtleInspectItemEvent;
|
2017-05-01 13:32:39 +00:00
|
|
|
import dan200.computercraft.core.apis.IAPIEnvironment;
|
2018-04-17 08:22:26 +00:00
|
|
|
import dan200.computercraft.core.tracking.TrackingField;
|
2017-05-01 13:32:39 +00:00
|
|
|
import dan200.computercraft.shared.turtle.core.*;
|
|
|
|
|
import net.minecraft.item.Item;
|
|
|
|
|
import net.minecraft.item.ItemStack;
|
2020-06-01 10:14:36 +00:00
|
|
|
import net.minecraft.util.ResourceLocation;
|
2018-02-16 10:33:32 +00:00
|
|
|
import net.minecraftforge.common.MinecraftForge;
|
Update CC: Tweaked to 1.13
Look, I originally had this split into several commits, but lots of
other cleanups got mixed in. I then backported some of the cleanups to
1.12, did other tidy ups there, and eventually the web of merges was
unreadable.
Yes, this is a horrible mess, but it's still nicer than it was. Anyway,
changes:
- Flatten everything. For instance, there are now three instances of
BlockComputer, two BlockTurtle, ItemPocketComputer. There's also no
more BlockPeripheral (thank heavens) - there's separate block classes
for each peripheral type.
- Remove pretty much all legacy code. As we're breaking world
compatibility anyway, we can remove all the code to load worlds from
1.4 days.
- The command system is largely rewriten to take advantage of 1.13's
new system. It's very fancy!
- WidgetTerminal now uses Minecraft's "GUI listener" system.
- BREAKING CHANGE: All the codes in keys.lua are different, due to the
move to LWJGL 3. Hopefully this won't have too much of an impact.
I don't want to map to the old key codes on the Java side, as there
always ends up being small but slight inconsistencies. IMO it's
better to make a clean break - people should be using keys rather
than hard coding the constants anyway.
- commands.list now allows fetching sub-commands. The ROM has already
been updated to allow fancy usage such as commands.time.set("noon").
- Turtles, modems and cables can be waterlogged.
2019-04-02 12:27:27 +00:00
|
|
|
import net.minecraftforge.registries.ForgeRegistries;
|
2017-05-01 13:32:39 +00:00
|
|
|
|
|
|
|
|
import java.util.HashMap;
|
|
|
|
|
import java.util.Map;
|
Replace getMethodNames/callMethod with annotations (#447)
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
|
|
|
import java.util.Optional;
|
2017-06-12 09:28:31 +00:00
|
|
|
|
2017-05-01 13:32:39 +00:00
|
|
|
public class TurtleAPI implements ILuaAPI
|
|
|
|
|
{
|
Replace getMethodNames/callMethod with annotations (#447)
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
|
|
|
private final IAPIEnvironment environment;
|
|
|
|
|
private final ITurtleAccess turtle;
|
2017-05-01 13:32:39 +00:00
|
|
|
|
|
|
|
|
public TurtleAPI( IAPIEnvironment environment, ITurtleAccess turtle )
|
|
|
|
|
{
|
Replace getMethodNames/callMethod with annotations (#447)
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
|
|
|
this.environment = environment;
|
|
|
|
|
this.turtle = turtle;
|
2017-05-01 13:32:39 +00:00
|
|
|
}
|
|
|
|
|
|
2017-05-01 14:48:44 +00:00
|
|
|
@Override
|
2017-05-01 13:32:39 +00:00
|
|
|
public String[] getNames()
|
|
|
|
|
{
|
2019-06-07 23:28:03 +00:00
|
|
|
return new String[] { "turtle" };
|
2017-05-01 13:32:39 +00:00
|
|
|
}
|
2018-12-23 17:46:58 +00:00
|
|
|
|
Replace getMethodNames/callMethod with annotations (#447)
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
|
|
|
private MethodResult trackCommand( ITurtleCommand command )
|
|
|
|
|
{
|
|
|
|
|
environment.addTrackingChange( TrackingField.TURTLE_OPS );
|
|
|
|
|
return turtle.executeCommand( command );
|
2017-05-01 13:32:39 +00:00
|
|
|
}
|
|
|
|
|
|
Replace getMethodNames/callMethod with annotations (#447)
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult forward()
|
2017-05-01 13:32:39 +00:00
|
|
|
{
|
Replace getMethodNames/callMethod with annotations (#447)
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
|
|
|
return trackCommand( new TurtleMoveCommand( MoveDirection.FORWARD ) );
|
2017-05-01 13:32:39 +00:00
|
|
|
}
|
2018-12-23 17:46:58 +00:00
|
|
|
|
Replace getMethodNames/callMethod with annotations (#447)
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult back()
|
2017-05-01 13:32:39 +00:00
|
|
|
{
|
Replace getMethodNames/callMethod with annotations (#447)
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
|
|
|
return trackCommand( new TurtleMoveCommand( MoveDirection.BACK ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult up()
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleMoveCommand( MoveDirection.UP ) );
|
2017-05-01 13:32:39 +00:00
|
|
|
}
|
|
|
|
|
|
Replace getMethodNames/callMethod with annotations (#447)
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult down()
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleMoveCommand( MoveDirection.DOWN ) );
|
2017-05-01 13:32:39 +00:00
|
|
|
}
|
|
|
|
|
|
Replace getMethodNames/callMethod with annotations (#447)
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult turnLeft()
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleTurnCommand( TurnDirection.LEFT ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult turnRight()
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleTurnCommand( TurnDirection.RIGHT ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult dig( Optional<TurtleSide> side )
|
|
|
|
|
{
|
|
|
|
|
environment.addTrackingChange( TrackingField.TURTLE_OPS );
|
|
|
|
|
return trackCommand( TurtleToolCommand.dig( InteractDirection.FORWARD, side.orElse( null ) ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult digUp( Optional<TurtleSide> side )
|
|
|
|
|
{
|
|
|
|
|
environment.addTrackingChange( TrackingField.TURTLE_OPS );
|
|
|
|
|
return trackCommand( TurtleToolCommand.dig( InteractDirection.UP, side.orElse( null ) ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult digDown( Optional<TurtleSide> side )
|
|
|
|
|
{
|
|
|
|
|
environment.addTrackingChange( TrackingField.TURTLE_OPS );
|
|
|
|
|
return trackCommand( TurtleToolCommand.dig( InteractDirection.DOWN, side.orElse( null ) ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult place( IArguments args )
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtlePlaceCommand( InteractDirection.FORWARD, args.getAll() ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult placeUp( IArguments args )
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtlePlaceCommand( InteractDirection.UP, args.getAll() ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult placeDown( IArguments args )
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtlePlaceCommand( InteractDirection.DOWN, args.getAll() ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult drop( Optional<Integer> count ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleDropCommand( InteractDirection.FORWARD, checkCount( count ) ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult dropUp( Optional<Integer> count ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleDropCommand( InteractDirection.UP, checkCount( count ) ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult dropDown( Optional<Integer> count ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleDropCommand( InteractDirection.DOWN, checkCount( count ) ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult select( int slot ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
int actualSlot = checkSlot( slot );
|
|
|
|
|
return turtle.executeCommand( turtle -> {
|
|
|
|
|
turtle.setSelectedSlot( actualSlot );
|
|
|
|
|
return TurtleCommandResult.success();
|
|
|
|
|
} );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final int getItemCount( Optional<Integer> slot ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
int actualSlot = checkSlot( slot ).orElse( turtle.getSelectedSlot() );
|
|
|
|
|
return turtle.getInventory().getStackInSlot( actualSlot ).getCount();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final int getItemSpace( Optional<Integer> slot ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
int actualSlot = checkSlot( slot ).orElse( turtle.getSelectedSlot() );
|
|
|
|
|
ItemStack stack = turtle.getInventory().getStackInSlot( actualSlot );
|
|
|
|
|
return stack.isEmpty() ? 64 : Math.min( stack.getMaxStackSize(), 64 ) - stack.getCount();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult detect()
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleDetectCommand( InteractDirection.FORWARD ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult detectUp()
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleDetectCommand( InteractDirection.UP ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult detectDown()
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleDetectCommand( InteractDirection.DOWN ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult compare()
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleCompareCommand( InteractDirection.FORWARD ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult compareUp()
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleCompareCommand( InteractDirection.UP ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult compareDown()
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleCompareCommand( InteractDirection.DOWN ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult attack( Optional<TurtleSide> side )
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( TurtleToolCommand.attack( InteractDirection.FORWARD, side.orElse( null ) ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult attackUp( Optional<TurtleSide> side )
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( TurtleToolCommand.attack( InteractDirection.UP, side.orElse( null ) ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult attackDown( Optional<TurtleSide> side )
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( TurtleToolCommand.attack( InteractDirection.DOWN, side.orElse( null ) ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult suck( Optional<Integer> count ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleSuckCommand( InteractDirection.FORWARD, checkCount( count ) ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult suckUp( Optional<Integer> count ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleSuckCommand( InteractDirection.UP, checkCount( count ) ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult suckDown( Optional<Integer> count ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleSuckCommand( InteractDirection.DOWN, checkCount( count ) ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final Object getFuelLevel()
|
|
|
|
|
{
|
|
|
|
|
return turtle.isFuelNeeded() ? turtle.getFuelLevel() : "unlimited";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult refuel( Optional<Integer> countA ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
int count = countA.orElse( Integer.MAX_VALUE );
|
|
|
|
|
if( count < 0 ) throw new LuaException( "Refuel count " + count + " out of range" );
|
|
|
|
|
return trackCommand( new TurtleRefuelCommand( count ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult compareTo( int slot ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleCompareToCommand( checkSlot( slot ) ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult transferTo( int slotArg, Optional<Integer> countArg ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
int slot = checkSlot( slotArg );
|
|
|
|
|
int count = checkCount( countArg );
|
|
|
|
|
return trackCommand( new TurtleTransferToCommand( slot, count ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final int getSelectedSlot()
|
|
|
|
|
{
|
|
|
|
|
return turtle.getSelectedSlot() + 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final Object getFuelLimit()
|
|
|
|
|
{
|
|
|
|
|
return turtle.isFuelNeeded() ? turtle.getFuelLimit() : "unlimited";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult equipLeft()
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleEquipCommand( TurtleSide.LEFT ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult equipRight()
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleEquipCommand( TurtleSide.RIGHT ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult inspect()
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleInspectCommand( InteractDirection.FORWARD ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult inspectUp()
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleInspectCommand( InteractDirection.UP ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final MethodResult inspectDown()
|
|
|
|
|
{
|
|
|
|
|
return trackCommand( new TurtleInspectCommand( InteractDirection.DOWN ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@LuaFunction
|
|
|
|
|
public final Object[] getItemDetail( Optional<Integer> slotArg ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
// FIXME: There's a race condition here if the stack is being modified (mutating NBT, etc...)
|
|
|
|
|
// on another thread. The obvious solution is to move this into a command, but some programs rely
|
|
|
|
|
// on this having a 0-tick delay.
|
|
|
|
|
int slot = checkSlot( slotArg ).orElse( turtle.getSelectedSlot() );
|
|
|
|
|
ItemStack stack = turtle.getInventory().getStackInSlot( slot );
|
|
|
|
|
if( stack.isEmpty() ) return new Object[] { null };
|
|
|
|
|
|
|
|
|
|
Item item = stack.getItem();
|
|
|
|
|
String name = ForgeRegistries.ITEMS.getKey( item ).toString();
|
|
|
|
|
int count = stack.getCount();
|
|
|
|
|
|
|
|
|
|
Map<String, Object> table = new HashMap<>();
|
|
|
|
|
table.put( "name", name );
|
|
|
|
|
table.put( "count", count );
|
|
|
|
|
|
2020-06-16 08:24:14 +00:00
|
|
|
Map<String, Boolean> tags = new HashMap<>();
|
|
|
|
|
for( ResourceLocation location : item.getTags() ) tags.put( location.toString(), true );
|
|
|
|
|
table.put( "tags", tags );
|
|
|
|
|
|
Replace getMethodNames/callMethod with annotations (#447)
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
|
|
|
TurtleActionEvent event = new TurtleInspectItemEvent( turtle, stack, table );
|
|
|
|
|
if( MinecraftForge.EVENT_BUS.post( event ) ) return new Object[] { false, event.getFailureMessage() };
|
|
|
|
|
|
|
|
|
|
return new Object[] { table };
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
private static int checkSlot( int slot ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
if( slot < 1 || slot > 16 ) throw new LuaException( "Slot number " + slot + " out of range" );
|
|
|
|
|
return slot - 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private static Optional<Integer> checkSlot( Optional<Integer> slot ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
return slot.isPresent() ? Optional.of( checkSlot( slot.get() ) ) : Optional.empty();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private static int checkCount( Optional<Integer> countArg ) throws LuaException
|
|
|
|
|
{
|
|
|
|
|
int count = countArg.orElse( 64 );
|
|
|
|
|
if( count < 0 || count > 64 ) throw new LuaException( "Item count " + count + " out of range" );
|
|
|
|
|
return count;
|
2017-05-01 13:32:39 +00:00
|
|
|
}
|
|
|
|
|
}
|