I'm unsure if this is the place to post this, since it might be an issue with openPeripheral or computercraft. I'm running a script in computercraft to look through my AE system. I'm using openPeripheral functions connected to an ME interface to run the command interface.getAvailableItems(). This returns an array of item data, most notably the item fingerprint. I then pull item details from the fingerprint using interface.getItemDetail(interface.getAvailableItems()[i].fingerprint). I'm not sure why but sometimes when going through the for loop of interface.getAvailableItems() the iterator will go out of scope of the array returned. This likely happens because I'm using LUA and LUA runs the second argument for the for loop once and stores the data, rather than running it each time to get a new value. What's worse is that once I've obtained an i value to look up an item in the array, sometimes the i is in scope, and sometimes it's not (according to the errors I'm getting) and it's not consistent either. Sometimes it will do it on Iron Blocks, sometimes on Cryo-Stabilized Flux Ducts, and sometimes on Cobblestone. I found a way around this, to check weather the look up value went out of scope. I threw an exception, and tried again, but not only does this make looking up items take waaaaaaay too long, sometimes after it gets the fingerprint for the item, the fingerprint will fail to look up the item details in the interface.getItemDetail(fingerprint) function. And this also isn't consistent, sometimes it will fail to look up the display_name, other times it will fail to look up the dmg or the qty. I'm unsure if this is a bug or just part of the way that lua + java running in minecraft have to work together. Either way it seems like a bug. If you need more information I can post it here. Then again I'm unsure if this belongs here, if it doesn't please close the issue. Thank you for time if you read all of this. :)

I think you'll need to do more testing to identify where the problem is.

I'd suggest starting using as few mods as possible and attempting to
recreate the problem without AE at all.
My initial thought is that it sounds like the issue could be related to the
inventory contents changing while your LUA code is running. Do you have
automated mining/crafting happening in your AE system? If so, can you
setup a test using something like hoppers chained together to create a loop
(IE vanilla, but could probably use enderIO conduits on extract moving
items between two chests slowly... no accel upgrades).

Once you have that setup, run your code again... and if its too fast on
that small an inventory add some delays to the code to make sure the
inventory contents can change.

No clue if it'll help, but it might help you figure out where the problem
is.

You might also want to try finding some of the computercraft/openperipheral
devs in IRC. They might have some good insight to add as well.

On Wed, May 18, 2016 at 5:19 PM xxakirhaxx [email protected] wrote:

I'm unsure if this is the place to post this, since it might be an issue
with openPeripheral or computercraft. I'm running a script in computercraft
to look through my AE system. I'm using openPeripheral functions connected
to an ME interface to run the command interface.getAvailableItems(). This
returns an array of item data, most notably the item fingerprint. I then
pull item details from the fingerprint using
interface.getItemDetail(interface.getAvailableItems()[i].fingerprint). I'm
not sure why but sometimes when going through the for loop of
interface.getAvailableItems() the iterator will go out of scope of the
array returned. This likely happens because I'm using LUA and LUA runs the
second argument for the for loop once and stores the data, rather than
running it each time to get a new value. What's worse is that once I've
obtained an i value to look up an item in the array, sometimes the i is in
scope, and sometimes it's not (according to the errors I'm getting) an d
it's n ot consistent either. Sometimes it will do it on Iron Blocks,
sometimes on Cryo-Stabilized Flux Ducts, and sometimes on Cobblestone. I
found a way around this, to check weather the look up value went out of
scope. I threw an exception, and tried again, but not only does this make
looking up items take waaaaaaay too long, sometimes after it gets the
fingerprint for the item, the fingerprint will fail to look up the item
details in the interface.getItemDetail(fingerprint) function. And this also
isn't consistent, sometimes it will fail to look up the display_name, other
times it will fail to look up the dmg or the qty. I'm unsure if this is a
bug or just part of the way that lua + java running in minecraft have to
work together. Either way it seems like a bug. If you need more information
I can post it here. Then again I'm unsure if this belongs here, if it
doesn't please close the issue. Thank you for time if you read all of this.
:)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#2283

Ah, yes that would be a good test to set up thank you. And you're probably right, I suspected that might be the problem. On a test server I have, I run the same code on a small AE system with no items running in or out and it works great. I'm going to set up some input/output on the test server and see if i can recreate the bug.

Reporting back. I posted this on the openperipheral forum. The getItemDetails(fingerprint) was running iterations through my AE system every time it was ran. The solution was to call getAvailableItems("proxy") and storing this as a table and using the information from it to export items. Rather than calling getItemDetails(getAvailableItems()[i].fingerprint) every time. Since every time getAvailableItems() is called the table size can change. I now have a very fast army of turtles who can build anything as long as the items exist in my storage or crafting network and the turtles have an ender chest. Thanks for the kick ass mod.