510 posts
Posted 13 March 2012 - 08:42 AM
I know that this has already been suggested multiple times. It is clear that a system based on block ids wouldn't work.
But every block also has a name. This is used by eg. NEI to find it. so why not create an API that allows access to block and item types in a way like this.
local itemType = turtle.getItemType()
if itemType == item.iron then
...
You could also say item["iron"]. This could be used as a base for working with all kinds of blocks and items. NEI even recognizes items only identified by their damage value, like colored wool or industrialcraft/redpower items. (Yes, NEI needs a plugin for redpower, but CC already has some redpower interop code)
Such an API could be a base for more extended peripherals, like eg. an programmable item filter or automated crafting table.
88 posts
Posted 13 March 2012 - 08:46 AM
the compare function is meant to fill this role
510 posts
Posted 13 March 2012 - 08:12 PM
Yes, but that is not enough to instruct programmable item filters or such. Normally you place on block of the desired type in the filter's inventory, a programmable version could just say "filter.setFilteredItems(item.stone,item.ironBlock)". but this would need a fully aware item/block API.
33 posts
Posted 15 March 2012 - 02:53 PM
What about adding a function that returns a semi-random string of gibberish, based on the block ID and meta data plus the world seed? turtle.analyze()
1 second hardcoded sleep on it so compare() is faster.
With that and a peripheral to analyze the blocks in a trunk, you could code a base server that creates a list of keep or trash blocks. Turtles could ping the server with an analyze string and get back a keep or toss signal.
That would give people more power over block detection while bypassing the modded block ID problem and preventing pregenerated lists.
38 posts
Posted 26 March 2012 - 09:59 PM
I suggested something very similar as Neowulf earlier. They've stated repeatedly that they want turtles blind. Which is fine, their call to make.
But it would be great if we could get some data on what's in front of the turtle. Right now we can't distinguish material at all, I'm not asking for block id, just someway to differentiate materials. I suggested that they use a hash based on the block id and the turtle id. That way no 2 turtles analyze the block the same, keeping them essentially blind. But the turtles can still tell when the blocks are of different type.
I don't think they'll go for anything like a hash that returns the same across all turtles. It would be too simple of a task to scan, compare, dig and build a central table to do a hash look up to determine block type. A couple turtles and like one hour later your control computer has indexed all the hashes and your turtle now can do look ups against it to instantly determine block type. Not exactly blind.
473 posts
Location
Poland
Posted 26 March 2012 - 10:03 PM
It's not that hopeless a case right now, it just requires a live user to determine block types and keep them in storage. When a turtle is 'aware' of its contents, it can be used as a scanning device and distinguish blocks for other turtles. There's not much need to make turtles capable of recognizing blocks. Although an optical feed would be an awesome thing. Just think of the views! :o/>/>
16 posts
Posted 26 March 2012 - 10:42 PM
If turtle can compare 2 items, why it cannot hold data of item in its memory to compare after, without having that item? Im not saying that it should have data of all item by default, but maybe make it able 'learn blocks' ? In implimentation like for each turtle each block has its unique hash code (few unique random values) then when you "analyze" the block, turtle get its code. The limitations is that you cant set the block id before turtle analyze the block because you just dont know its id for current turtle.
2447 posts
Posted 27 March 2012 - 11:35 AM
This has been said multiple times before - a way to detect the block in front without compare isn't going to happen, sorry. I think compare is a good solution - I understand you may have many ores in the world, but you could simply check for different ores at different times.
However, dan200 was thinking of adding a way for peripherals to be attached to turtles (and moving). If this happens, a peripheral could be created to check the block ID in front of the turtle.
38 posts
Posted 28 March 2012 - 09:23 AM
But the problem with compare comes when you have many blocks that exist in world that have no corisponding item. Diamonds, redstone, etc… it's more that were looking for a solution that satisfies keeping them essentially blind while not having a group of blocks that are essential indeterminate with the current compare. We know there's a block there, but have no idea what it is, only the it's it the group of indeterminates.
473 posts
Location
Poland
Posted 28 March 2012 - 10:22 AM
Then mine it and replace. If it's possible then it's probably grass, and if it's not, it's diamond/coal/redstone and you can always keep them in your inventory and check for it. It IS doable.
38 posts
Posted 29 March 2012 - 04:01 AM
As much as that is a workable solutions to block detection, I'd like to find a solution that doesn't involve my titles violently destroying things as the blindly "feel" their way through the world.
2447 posts
Posted 29 March 2012 - 11:29 AM
Then use a pickaxe with silk touch to pick up a diamond or redstone block. That way you can check against it.
510 posts
Posted 29 March 2012 - 09:49 PM
Why not let the turtle compare with the dropped items for a block, too? Then it would be able to detect a grass block etc. This wouldn't be a big change and still save us from the need to obtain dianmond/redstone ore.