Detecting Block ID's

A small suggestion: the creators of this product/forum seem to have a hatred of the idea of detecting block IDs, and also of people asking them to add that in the future. That's all fine, but no where in this pinned thread is this explained. It's such a natural and obvious feature to ask for, that unless you explain why it can't/won't be added, people will keep asking for it ad nauseum. So my suggestion for the owners of this site would be to explain–in this pinned topic–exactly WHY there is such emphatic rejection of this idea. Is it a personal bias? Is it thought to be too close to cheating? Is it because other mods already have this covered? Is it because it's technically impossible? (I know it's actually possible, I'm just saying that people might assume otherwise in lieu of explanation) Just saying NO NO NO NEVER GONNA HAPPEN does not tell people why it can't/won't be done, and until they have been presented an explanation, you can't really blame them for asking for something so straightforward…

It's a matter of balance. It would be too OP to have the ability to detect block id's. if you want block and item id recognition, the Aperture Science peripheral has a database turtle. It doesn't detect id's, but you can "teach" it certain information about a block, such as name or id, and it will remember it.

Dlcruz129, on 31 January 2013 - 05:53 PM said:

It's a matter of balance. It would be too OP to have the ability to detect block id's. if you want block and item id recognition, the Aperture Science peripheral has a database turtle. It doesn't detect id's, but you can "teach" it certain information about a block, such as name or id, and it will remember it.

No, it was actually because it doesn't fit in the game (to quote dan200 and Cloudy, it breaks the fourth wall).
There's no reason things inside Minecraft should know about block IDs, because they only make sense when viewed from outside the game.

immibis, on 31 January 2013 - 06:17 PM said:

No, it was actually because it doesn't fit in the game (to quote dan200 and Cloudy, it breaks the fourth wall).
There's no reason things inside Minecraft should know about block IDs, because they only make sense when viewed from outside the game.

That is true but in the game the player can tell apart different blocks store the differences in there/your head and reference this data later to identify blocks. Turtles lack that long term memory of what a block is. A method of storing some data about the block would be useful. Block ID's are a not the best solution but a the problem can be solved other ways. Assigning an arbitrary weight to each block and a basic color or something that the turtle can remember and test against latter. It is implied that some method of separation is carried out by the compare function using some characteristics of the block in question if it can do that is should be able to remember those charismatics.

Well, one could go into a great deal of detail about how difficult it is for automated sensors to reliably tell different kinds of material apart…but this is an evolving field given the state of the art. And there are a lot of things that turtles can do (such as storing a thousand cubic meters of stone inside of a robot less than a cubic meter in size) which would seem to defy any foreseeable technological development. Still, one has to draw limits on their abilities somewhere.

For myself, I'm content to think of the comparison block as representing a sensor module specific to testing for similar blocks. Sure, the turtle remembers how to use the magnometer/laserspetrograph that distinguishes one ore from all other kinds of rock (and other solid materials), but that doesn't mean it has unlimited space for it. So you give up an inventory slot for each different material you want to test…leaving you with less than a thousand cubic meters of room inside of your less than a meter cube robot–which I do not consider a terrible penalty.

Or, one can take it as a pure gameplay limitation without invoking any "realism" at all. Block ID's are incredibly OP. They'd remove nearly all the challenge from programming a turtle, beyond the basic level of learning the commands.

If you need the ability to deal with many different kinds of blocks, then you have turtles work in teams of dedicated inventory comparison turtles. Yes, designing that is quite a challenge (as it should be). But that is kinda the point of CC. Turtles should be useful, and more useful as you put more effort into programming them.

May be detecting any block id is too much, but some simple detectors are quite logical. I mean detection of water/lava/solid/non-solid block and such simple.

Sebra, on 01 February 2013 - 04:06 AM said:

May be detecting any block id is too much, but some simple detectors are quite logical. I mean detection of water/lava/solid/non-solid block and such simple.

More I think about it

weight = derivate of blocks required damage to break explained by density increasing strength
volume = for blocks non square
matter state = solid liquid gas
color out of the 16 CC knows

would allow computers to remember characteristics instead of carrying blocks and also for one turtle to explain to another what block it has learned about.

Anyway I will leave it here and move on.

immibis, on 31 January 2013 - 06:17 PM said:

No, it was actually because it doesn't fit in the game (to quote dan200 and Cloudy, it breaks the fourth wall).
There's no reason things inside Minecraft should know about block IDs, because they only make sense when viewed from outside the game.

I understand that argument. It does make sense to respect block IDs as "internal" (encapsulated, inside the black box) and subject to change. What might be a nice compromise is a "diamond filtering turtle" that works a little like a diamond BC pipe, and allows you to give it an internal lookup table of block types your program can reference, without have to put examples of them into the turtle's already space-limited inventory slots.

For stackable items (including all block items), filtering can be achieved simply by having multiple turtles (which needn't have tools, a pretty significant cost savings) suck/drop items into inventories while having at least one item (of a "known" type) in each inventory slot. You could even do it with just one turtle programmed to use an array of chests (with known contents) to alter its inventory (though this slows down the processing a lot).

Lava/water is a bit tricky, given that buckets do not stack. You can tell if something is a liquid by using an empty bucket on it, but you can't tell what kind of liquid it is without having another full bucket for comparison purposes…or using the buckets of lava as fuel (a perfectly reasonable option, but not a reversible one). I personally favor using the lava as fuel and destroying water blocks (as they can be infinitely regenerated easily enough), but this may not be considered ideal for all possible cases. One can also use a water filled strip-mine to turn all lava into obsidian, but this has the drawback of requiring a strip-mine, meaning more blocks must be broken. This is only really a problem once durability becomes implemented, and hopefully improved compare based on the pick block logic will be implemented by that time (or soon after).

Anyway, my perception of the planned developments is that they adequately address these concerns. You can do things, you just need to put in the effort to design and code a program to do it…which is kinda the point of CC.

ChunLing, on 01 February 2013 - 11:22 AM said:

For stackable items (including all block items), filtering can be achieved simply by having multiple turtles (which needn't have tools, a pretty significant cost savings) suck/drop items into inventories while having at least one item (of a "known" type) in each inventory slot. You could even do it with just one turtle programmed to use an array of chests (with known contents) to alter its inventory (though this slows down the processing a lot).

The server I play on is a Feed The Beast server, so we already have BuildCraft diamond pipe for sorting after the fact. What I was suggesting would be a way for the turtle to avoid ever digging the blocks it doesn't want, for the considerable time savings when doing things like tunneling and picking ores from the walls, or plunge mining.

Detecting of items is already at the maximum amount of detection it's ever going to get. Comparing blocks to items you already have in the turtles' inventory will work just fine.

BigSHinyToys, on 31 January 2013 - 07:27 PM said:

immibis, on 31 January 2013 - 06:17 PM said:

No, it was actually because it doesn't fit in the game (to quote dan200 and Cloudy, it breaks the fourth wall).
There's no reason things inside Minecraft should know about block IDs, because they only make sense when viewed from outside the game.

That is true but in the game the player can tell apart different blocks store the differences in there/your head and reference this data later to identify blocks. Turtles lack that long term memory of what a block is.

Indeed. Aperture Science Turtle Upgrades has the database turtle which adds exactly that. It would fit somewhat in CC, but I also like having things not be that simple. I like having to use effort to get around the limitations of compareTo.

BigSHinyToys, on 01 February 2013 - 04:42 AM said:

Sebra, on 01 February 2013 - 04:06 AM said:

May be detecting any block id is too much, but some simple detectors are quite logical. I mean detection of water/lava/solid/non-solid block and such simple.

More I think about it

weight = derivate of blocks required damage to break explained by density increasing strength
volume = for blocks non square
matter state = solid liquid gas
color out of the 16 CC knows

would allow computers to remember characteristics instead of carrying blocks and also for one turtle to explain to another what block it has learned about.

Anyway I will leave it here and move on.

Weight would be something measured by a peripheral when it has the block on top of it.
Exact volume isn't possible for non-square blocks, but you can estimate it from the collision boxes.
Matter state is possible. You can already detect it, btw - with a liquid block in front of the turtle, turtle.detect() will return false and turtle.dig() will return true. You can't detect it without destroying the block, though.
Colour isn't possible.

BigSHinyToys, on 01 February 2013 - 04:42 AM said:

Sebra, on 01 February 2013 - 04:06 AM said:

May be detecting any block id is too much, but some simple detectors are quite logical. I mean detection of water/lava/solid/non-solid block and such simple.

More I think about it

weight = derivate of blocks required damage to break explained by density increasing strength
volume = for blocks non square
matter state = solid liquid gas
color out of the 16 CC knows

would allow computers to remember characteristics instead of carrying blocks and also for one turtle to explain to another what block it has learned about.

Anyway I will leave it here and move on.

That would be a lot of work on Dan and Cloudy's part. They would have to "teach" ComputerCraft the textures, colors, etc. And then the suggestion section would be spammed with, "Can you add block detection for Railcraft/IC2/BuildCraft, etc."

Not a lot of work to add isLiquid, isSolid, even if_you_can_place_a_block_without_actually_placing. Just such general properties all blocks have already.

What is the point of detecting if a block is liquid? You use a bucket on it, if it's lava, you can use it as fuel, if it's water, it's basically worthless cause you can easily infinite generate the stuff.

If you want to collect obsidian, you use a water source and a strip mine to turn all lava sources into obsidian. Of you use a water bucket and compareTo, so you know if you've got lava, then back up, place placeUp water, and place lava to convert individual source blocks (more code work, but probably worth it if you're not into strip mining).

To elaborate:
Turtles are intended to be blind. As such, they cannot detect anything except whether something is in front of it, or comparing that same item to something it already has. This is why turtles can only use peripherals that can be attached to them as in upgrades.
I don't see any reason why this would ever change. If you want block ID detection, use one of the peripherals available to you in the peripherals section.

Cranium, on 04 February 2013 - 12:45 PM said:

To elaborate:
Turtles are intended to be blind. As such, they cannot detect anything except whether something is in front of it, or comparing that same item to something it already has. This is why turtles can only use peripherals that can be attached to them as in upgrades.
I don't see any reason why this would ever change. If you want block ID detection, use one of the peripherals available to you in the peripherals section.

How do people compare objects. first you need a list of ways to compare them so color , texture , weight , density , how it reacts to being poked ect… the turtle can compare implying some methods of comparison are being used. we know out side the game that it is using number for this but from game perspective it must be using some of the characteristic of the block. If those pieces of information exists there must be in data form for the turtles CPU to process. so there are data variables used by toe computer that the user cant access seams kind of strange that some information would be kept from the player.


I really don't care if a method of storing a blocks profile or not is added to CC but It just seams a bit inconsistent with a mod that gives the player ultimate control.

on a sub note I think item inventory problems are part of the reason a self replicating turtle system has not been built yet.

They've been built, but most people that do build one decide against releasing the programs.

Like I've said before, I'm comfortable thinking of the inventory space taken by the blocks to compare as accommodating sensor equipment designed to discover the particular characteristics of a block without having to mine it first. If you want to complain that this is unrealistic, then I move to eliminate the inventory of the turtle entirely…how much sense does it make for a robot less than a meter cube to be able to hold 64 cubic meters (let alone over a thousand) of stone? If you think that turtles are underpowered…well, I'm not sure how to make a dignified response to that assertion.

There are ways to get around the limitations of turtles, they just require some coding work and imagination, is all. CC isn't a "win button" mod. It isn't supposed to be.

Turtles are already OP. I'm quite agree with Chunling and may repeat him
I think the point of CC Craft is to make frkkin awsome thing, but only by the hardest way. That's the spirit in wich Minecraft grew ; remember your old automatized cart station, when there were no powered rail, your mob farm when there were no piston, your light detector when there were no light sensor, your hundred's of fall when digging when there were no turtles…

Compared to the buildcraft quarry, a mining turtles cost nothing, except the time you spend to program it. And that's the point, you can do everything, but you got to program it.

You can actually already with very simple tests identify a large set of the usefull natural blocks and items of vanilla (trees, salpings, dirt, sand, stone/cobble, coal, iron ore, gold, redstone, lapis and diamond). I said simple not obvious, and a big part of the fun is to find how give the vision to these blind turtles. Simple also means you can identify it at the place you found it.

For most of your suggestion, turtles can already do that, you just ignore it.

1. Liquid/Solid and Lava/water detection : chunling already respond, but if you don't want to refuel with lava, nor to use a slot for comparison : have water, attempt to build a cobble machine - just a joke. Throw the liquid in a hole (in order to not spread it), drop a useless item, get the liquid back and try to get the item back.
2. Solid / non solid "volume" hit box detection : many natural non solid block are quite easily identifiable (like sugar cane). one can imagine some complicated machine with mobs to test it. Having mob without human help could sounds pretty hard, but poulps are easily spawned. Indeed I joke, dropped/thrown items suits better than mobs, and the machines aren't so complicated.
3. Licght : dayLight detector are availiable since long (etho), low light detector can be imagine with mushrooms.

ChunLing, on 01 February 2013 - 11:22 AM said:

I personally favor using the lava as fuel and destroying water blocks

Did you already tried to refuel with a water bucket?

aaa, on 21 June 2013 - 04:54 PM said:

ChunLing, on 01 February 2013 - 11:22 AM said:

I personally favor using the lava as fuel and destroying water blocks

Did you already tried to refuel with a water bucket?

Yes because an (old) bug is an indication of anything.

Thread locked due to excessive necromancy. The dead threads, they walk!