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;
|
2020-06-30 11:35:39 +00:00
|
|
|
import dan200.computercraft.core.asm.TaskCallback;
|
2018-04-17 08:22:26 +00:00
|
|
|
import dan200.computercraft.core.tracking.TrackingField;
|
2020-06-30 11:35:39 +00:00
|
|
|
import dan200.computercraft.shared.peripheral.generic.data.ItemData;
|
2017-05-01 13:32:39 +00:00
|
|
|
import dan200.computercraft.shared.turtle.core.*;
|
|
|
|
import net.minecraft.item.ItemStack;
|
2018-02-16 10:33:32 +00:00
|
|
|
import net.minecraftforge.common.MinecraftForge;
|
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
|
2020-06-30 11:35:39 +00:00
|
|
|
public final MethodResult getItemDetail( ILuaContext context, Optional<Integer> slotArg, Optional<Boolean> detailedArg ) throws LuaException
|
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
|
|
|
{
|
|
|
|
int slot = checkSlot( slotArg ).orElse( turtle.getSelectedSlot() );
|
2020-06-30 11:35:39 +00:00
|
|
|
boolean detailed = detailedArg.orElse( false );
|
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
|
|
|
|
2020-06-30 11:35:39 +00:00
|
|
|
return detailed
|
|
|
|
? TaskCallback.make( context, () -> getItemDetail( slot, true ) )
|
|
|
|
: MethodResult.of( getItemDetail( slot, false ) );
|
|
|
|
}
|
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
|
|
|
|
2020-06-30 11:35:39 +00:00
|
|
|
private Object[] getItemDetail( int slot, boolean detailed )
|
|
|
|
{
|
|
|
|
ItemStack stack = turtle.getInventory().getStackInSlot( slot );
|
|
|
|
if( stack.isEmpty() ) return new Object[] { null };
|
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
|
|
|
|
2020-06-30 11:35:39 +00:00
|
|
|
Map<String, Object> table = detailed
|
|
|
|
? ItemData.fill( new HashMap<>(), stack )
|
|
|
|
: ItemData.fillBasic( new HashMap<>(), stack );
|
2020-06-16 08:24:14 +00:00
|
|
|
|
2020-06-30 11:35:39 +00:00
|
|
|
TurtleActionEvent event = new TurtleInspectItemEvent( turtle, stack, table, detailed );
|
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
|
|
|
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
|
|
|
}
|
|
|
|
}
|