Add inspect method to robot HLAPI that returns name of block#108
Add inspect method to robot HLAPI that returns name of block#108rschulman wants to merge 1 commit into
Conversation
|
Thanks for kicking this off! I'd prefer to have anything that doesn't have to be part of the core robot API be its own module. To compensate for that, I'd be open for evolving this into a "sensor module", which could also detect entities. So the call might return a list of results, e.g. As for sides, I'd keep with the |
|
I think this could live in its own module, but as you go forward its obviously worth keeping in mind how many module slots the robots have and what functionality they would need to be baseline useful. Being able to know what thing is right in front of them feels like pretty baseline while something that (e.g.) gave broader vision (like radar or something) or delivered precise location would deserve its own module. |
|
I agree, most simple robots in real life have the capability to at least "see" what is in front of them. In my opinion, robots should be able to see the block directly in front of them, but have the capability to "see" more of the world around them with an additional sensor as said. In my opinion, and I know this might not be feasible to do, but I think robots shouldn't use slots for said sensors, but more of a tab of installed sensors, similar to mekanism upgrades, so that there could be indefinite upgrades, because otherwise it takes up way too many slots for making the actual robot better. That's always been a bit of an issue, and I know there are different tiers and stuff for that in OC I, but it's a bit of a cumbersome system in my opinion. |
|
Hmhm. I'll sleep on it. And sure, the more modules there are, the harder it'll be to pick, but that's also the point of the limited slot count. It encourages more specialized robots, instead of master-of-all god robots. Whether that's good or not may be something I need to re-evaluate. |
|
An idea, each successive module slot could require the next tier of ore (I.e. Iron, gold... ending with netherite), and perhaps the previous tier, in its crafting recipe. The same/similar approach could also be used to limit the tier of module that it would be able to accept. Once all of the usual module slots have been used perhaps additional ones could be added at a significant cost. |
| throw new IllegalArgumentException(); | ||
| } | ||
| final BlockPos pos = Robot.this.blockPosition(); | ||
| return level.getBlockState(pos.relative(RobotOperationSide.toGlobal(Robot.this, side))).getBlock().getDescriptionId(); |
There was a problem hiding this comment.
Do we maybe want to explicitly check if the block is "air" and return null instead if that's the case?
|
This kind of functionality was one of my favorate features of OC and I would love to see it make it into the next build! If my memory serves me correctly, in OC the geolyzer analyze method would return "minecraft:air" as opposed to null. Similarly when combigned with other mods (can't remember which now, sorry), I found that, what looked like air, was being returned as something else from another mod (which might break this if air return null rule). On that note, one other thing the geolyzer analyze method used to return is the metadata of the block (amongst other useful things like harvestTool, hardness, etc.). I found the metadata exceptionally useful in conjunction, a couple of examples; being able to predict where a source block may be from flowing water/lava, the various states of certain blocks (e.g. doors, switches, pressure plates, etc.), the rotation of stair blocks, etc. |
This PR adds a new method to the robot API that allows the robot to examine a block next to it to the front, above, or below. The method returns a string in the form of "block.mod.item_name".
Up for discussion: should this be gated behind a component (I think not) and should the robot be able to inspect to the sides and behind (I don't feel strongly one way or another).