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.pocket.apis;
|
|
|
|
|
|
2017-11-18 13:40:38 +00:00
|
|
|
import dan200.computercraft.api.lua.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
|
|
|
import dan200.computercraft.api.lua.LuaFunction;
|
2017-05-02 00:53:30 +00:00
|
|
|
import dan200.computercraft.api.pocket.IPocketUpgrade;
|
2018-12-10 23:46:50 +00:00
|
|
|
import dan200.computercraft.shared.PocketUpgrades;
|
2017-05-02 00:53:30 +00:00
|
|
|
import dan200.computercraft.shared.pocket.core.PocketServerComputer;
|
|
|
|
|
import dan200.computercraft.shared.util.InventoryUtil;
|
|
|
|
|
import dan200.computercraft.shared.util.WorldUtil;
|
2019-03-16 11:18:03 +00:00
|
|
|
import net.minecraft.entity.Entity;
|
2019-06-08 12:36:31 +00:00
|
|
|
import net.minecraft.entity.player.PlayerEntity;
|
|
|
|
|
import net.minecraft.entity.player.PlayerInventory;
|
2017-05-02 00:53:30 +00:00
|
|
|
import net.minecraft.item.ItemStack;
|
2017-05-11 00:08:26 +00:00
|
|
|
import net.minecraft.util.NonNullList;
|
2017-05-08 23:41:20 +00:00
|
|
|
import net.minecraftforge.items.wrapper.PlayerMainInvWrapper;
|
2017-05-01 13:32:39 +00:00
|
|
|
|
Generate documentation stubs from Javadocs
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
2020-07-03 12:31:26 +00:00
|
|
|
/**
|
|
|
|
|
* Control the current pocket computer, adding or removing upgrades.
|
|
|
|
|
*
|
|
|
|
|
* This API is only available on pocket computers. As such, you may use its presence to determine what kind of computer
|
|
|
|
|
* you are using:
|
|
|
|
|
*
|
|
|
|
|
* <pre>
|
|
|
|
|
* if pocket then
|
|
|
|
|
* print("On a pocket computer")
|
|
|
|
|
* else
|
|
|
|
|
* print("On something else")
|
|
|
|
|
* end
|
|
|
|
|
* </pre>
|
|
|
|
|
*
|
|
|
|
|
* @cc.module pocket
|
|
|
|
|
*/
|
2017-05-01 13:32:39 +00:00
|
|
|
public class PocketAPI 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 PocketServerComputer computer;
|
2017-05-02 00:53:30 +00:00
|
|
|
|
|
|
|
|
public PocketAPI( PocketServerComputer computer )
|
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
|
|
|
this.computer = computer;
|
2017-05-01 13:32:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@Override
|
|
|
|
|
public String[] getNames()
|
|
|
|
|
{
|
2019-06-07 23:28:03 +00:00
|
|
|
return new String[] { "pocket" };
|
2017-05-01 13:32:39 +00:00
|
|
|
}
|
|
|
|
|
|
Generate documentation stubs from Javadocs
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
2020-07-03 12:31:26 +00:00
|
|
|
/**
|
|
|
|
|
* Search the player's inventory for another upgrade, replacing the existing one with that item if found.
|
|
|
|
|
*
|
|
|
|
|
* This inventory search starts from the player's currently selected slot, allowing you to prioritise upgrades.
|
|
|
|
|
*
|
|
|
|
|
* @return The result of equipping.
|
|
|
|
|
* @cc.treturn boolean If an item was equipped.
|
|
|
|
|
* @cc.treturn string|nil The reason an item was not equipped.
|
|
|
|
|
*/
|
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( mainThread = true )
|
|
|
|
|
public final Object[] equipBack()
|
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
|
|
|
Entity entity = computer.getEntity();
|
|
|
|
|
if( !(entity instanceof PlayerEntity) ) return new Object[] { false, "Cannot find player" };
|
|
|
|
|
PlayerEntity player = (PlayerEntity) entity;
|
|
|
|
|
PlayerInventory inventory = player.inventory;
|
|
|
|
|
IPocketUpgrade previousUpgrade = computer.getUpgrade();
|
|
|
|
|
|
|
|
|
|
// Attempt to find the upgrade, starting in the main segment, and then looking in the opposite
|
|
|
|
|
// one. We start from the position the item is currently in and loop round to the start.
|
|
|
|
|
IPocketUpgrade newUpgrade = findUpgrade( inventory.mainInventory, inventory.currentItem, previousUpgrade );
|
|
|
|
|
if( newUpgrade == null )
|
|
|
|
|
{
|
|
|
|
|
newUpgrade = findUpgrade( inventory.offHandInventory, 0, previousUpgrade );
|
|
|
|
|
}
|
|
|
|
|
if( newUpgrade == null ) return new Object[] { false, "Cannot find a valid upgrade" };
|
|
|
|
|
|
|
|
|
|
// Remove the current upgrade
|
|
|
|
|
if( previousUpgrade != null )
|
|
|
|
|
{
|
|
|
|
|
ItemStack stack = previousUpgrade.getCraftingItem();
|
|
|
|
|
if( !stack.isEmpty() )
|
|
|
|
|
{
|
|
|
|
|
stack = InventoryUtil.storeItems( stack, new PlayerMainInvWrapper( inventory ), inventory.currentItem );
|
|
|
|
|
if( !stack.isEmpty() )
|
|
|
|
|
{
|
|
|
|
|
WorldUtil.dropItemStack( stack, player.getEntityWorld(), player.getPositionVec() );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Set the new upgrade
|
|
|
|
|
computer.setUpgrade( newUpgrade );
|
|
|
|
|
|
|
|
|
|
return new Object[] { true };
|
2017-05-01 13:32:39 +00:00
|
|
|
}
|
|
|
|
|
|
Generate documentation stubs from Javadocs
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
2020-07-03 12:31:26 +00:00
|
|
|
/**
|
|
|
|
|
* Remove the pocket computer's current upgrade.
|
|
|
|
|
*
|
|
|
|
|
* @return The result of unequipping.
|
|
|
|
|
* @cc.treturn boolean If the upgrade was unequipped.
|
|
|
|
|
* @cc.treturn string|nil The reason an upgrade was not unequipped.
|
|
|
|
|
*/
|
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( mainThread = true )
|
|
|
|
|
public final Object[] unequipBack()
|
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
|
|
|
Entity entity = computer.getEntity();
|
|
|
|
|
if( !(entity instanceof PlayerEntity) ) return new Object[] { false, "Cannot find player" };
|
|
|
|
|
PlayerEntity player = (PlayerEntity) entity;
|
|
|
|
|
PlayerInventory inventory = player.inventory;
|
|
|
|
|
IPocketUpgrade previousUpgrade = computer.getUpgrade();
|
|
|
|
|
|
|
|
|
|
if( previousUpgrade == null ) return new Object[] { false, "Nothing to unequip" };
|
|
|
|
|
|
|
|
|
|
computer.setUpgrade( null );
|
|
|
|
|
|
|
|
|
|
ItemStack stack = previousUpgrade.getCraftingItem();
|
|
|
|
|
if( !stack.isEmpty() )
|
2017-05-02 00:53:30 +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
|
|
|
stack = InventoryUtil.storeItems( stack, new PlayerMainInvWrapper( inventory ), inventory.currentItem );
|
|
|
|
|
if( stack.isEmpty() )
|
|
|
|
|
{
|
|
|
|
|
WorldUtil.dropItemStack( stack, player.getEntityWorld(), player.getPositionVec() );
|
|
|
|
|
}
|
2017-05-02 00:53:30 +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 new Object[] { true };
|
2017-05-01 13:32:39 +00:00
|
|
|
}
|
2017-05-04 22:21:26 +00:00
|
|
|
|
2017-05-11 00:08:26 +00:00
|
|
|
private static IPocketUpgrade findUpgrade( NonNullList<ItemStack> inv, int start, IPocketUpgrade previous )
|
2017-05-04 22:21:26 +00:00
|
|
|
{
|
2017-05-11 00:08:26 +00:00
|
|
|
for( int i = 0; i < inv.size(); i++ )
|
2017-05-04 22:21:26 +00:00
|
|
|
{
|
2017-05-11 00:08:26 +00:00
|
|
|
ItemStack invStack = inv.get( (i + start) % inv.size() );
|
|
|
|
|
if( !invStack.isEmpty() )
|
2017-05-04 22:21:26 +00:00
|
|
|
{
|
2018-12-10 23:46:50 +00:00
|
|
|
IPocketUpgrade newUpgrade = PocketUpgrades.get( invStack );
|
2017-05-04 22:21:26 +00:00
|
|
|
|
|
|
|
|
if( newUpgrade != null && newUpgrade != previous )
|
|
|
|
|
{
|
|
|
|
|
// Consume an item from this stack and exit the loop
|
|
|
|
|
invStack = invStack.copy();
|
2017-05-11 00:08:26 +00:00
|
|
|
invStack.shrink( 1 );
|
|
|
|
|
inv.set( (i + start) % inv.size(), invStack.isEmpty() ? ItemStack.EMPTY : invStack );
|
2017-05-04 22:21:26 +00:00
|
|
|
|
|
|
|
|
return newUpgrade;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return null;
|
|
|
|
|
}
|
2017-05-01 13:32:39 +00:00
|
|
|
}
|