InfinitiesLoop

10 minutes ago, Molinko said:

May I suggest the Geolyzer component to scan the building area? This way the script could clear only the necessary areas before building. This could potentially speed up hollow builds by a lot. Maybe it could just scan the areas expected to be hollow and clear obstructions to the actual model in the build path, this way scanning would be limited too as opposed to scanning the entire build area. Just some thoughts on efficiency. Nice script btw  

Yeah, I thought about doing that, but I deprioritized it for two reasons. (1) I wanted it to work without one anyway. I wanted to minimize the setup required. It's already kinda involved as it is -- if you have a large build, you have to setup chests with importers and exporters, whitelist the correct things, etc. If you have a lot to clear out you have to set up auto tool repair with an AA item repairer (or just do it manually, but I'm all about automation here). (2) It only helps if there's a lot of air in your build, and it wouldn't be hard to just design your model not to have that air. The model can have spaces for air, or `-` for DND (do not disturb). So one can just use `-` and the robot will ignore/avoid those areas.

But definitely worth looking into. It just has to be fast and memory efficient. It has to scan only 1 horizontal layer at a time (the robot only cares about one layer at a time for memory efficiency), but the geolyzer if I'm not mistaken does vertical columns. So some issues to work out probably.

28 minutes ago, LightningShock said:

It's a very handy program, however there's room for optimization. The robot was wasting a lot of time and energy while building the sphere, because sometimes it was running side by side instead of taking a circular path 

Nope. The model includes clearing out existing blocks, you see. The model for that sphere is hallow. The robot has to visit those blocks in the middle in order to make sure there's nothing there. You can see that it has to clear out some of the dirt and trees in the middle. There's no way for it to know that there's already air there, so it has to visit them all. If one wanted they could design a non-hallow sphere model and it wouldn't do that.

58 minutes ago, Nexarius said:

WOW

This looks awesome !

 

Whats the best way to convert a structure ingame into the file for the computer?

There's a java program in the github project. If you're a programmer you should be able to figure it out. If not, well, I'm way behind on doing things like documentation and creating a release that makes it easier to use. If this generates any interest I'll definitely spend more time on it. 

I created a generic builder program and made a video to showcase what it can do:

Features that make it interesting:

1. It can build very large structures, as seen in the video.
2. Build structures with any number of different types of blocks.
3. Structures are defined in ASCII text files that are easily human readable/editable.
4. A java conversion program is provided that can convert Minecraft structure files into the ASCII format the robot requires, meaning you could set your robot to build any structure the community has built.
5. Continuously resupplies itself with provided chest(s), and recharges when necessary.
6. Will mine away blocks if necessary, and can resupply its tools by dumping off broken tools and picking up new ones.
7. Builds layers in such a way that it will not disturb any surrounding blocks. For example, you could build a stone sphere inside a block of glass, and you'll end up with glass perfectly touching the sphere. It employs an algorithm that ensures it can build each layer in such a way that it can always return to the charger for supply runs.
8. Extremely large model files are ok -- the robot can download each layer of the model directly off the internet as it is needed, otherwise some models are literally too big for OpenComputers hard drives.

https://github.com/InfinitiesLoop/oclib

11 hours ago, Molinko said:

Have you tried getting the robot to pull from specific sides of the block? Some blocks robot can only pull from a specific side.

Yeah, I tried all the sides. 

The  Tool Forge has all these modes it can be in, so there's no way OC would know which mode it was sucking it out of.

TiC tools that have Moss will auto repair slowly, but it uses up "stored xp". They gain stored xp when mining ores. But not when a robot uses them. 

I had hoped moss would be a good way for robots to use tools without needing user intervention (see my other thread about automating repair). 

It seems that my only hope for that is using AA tools. Because they repair in an item repairer, which the robot can drop into and suck from. But AA tools seem lame compared to TiC and I'd have go deep into its tech tree to create the repairer. 

I'm trying to create a program that will mine out a configurable area. It has to deal with some conditions in order to run for long enough -- for example, empty its inventory into a chest when it is full, return to a charger when it's low on energy, craft more torches when it runs out, etc.

But it also breaks its tool, and I thought I'd be able to automate it using a Tinkers Construct Tool Forget to repair it. 

As far as I can tell this doesn't seem possible. It can place items onto the table and pick them up, but the "output" of the table isn't an inventory slot. I thought maybe it would be, and the robot could just pick it up to complete the repair.

Perhaps an adapter can be used somehow, but I don't know much about those yet, and there's no information I can find related to Tinkers Construct.

Is my goal possible somehow?