Unknown iterate failure

[Tortoise-zz]

Hi, after struggling through outdated guides and learning how to compile in scala to get the nbt2ascii program converting files, my robot refuses to build the file i've made. i ran the builder.lua file again today and somehow my robot decided to work. he moved up to Y level 57 and started building - however, after running out of supplies he dropped to the ground and tried to charge. now if i try to run the same command with the bot back on the charger he loads uip on supplies then spits out the 'unknown iterate failure'. Anyone else come across this issue or know what is causing it?

[Keks4Gaming]

Hi, i never run into this error. But i can have a look if you can send me the converted files.

Have a nice Day!

Keks

[InfinitiesLoop]

Just a guess, but make sure your build is possible to build. There needs to be continuous designated blocks, no 'islands', since the robot will only ever step into blocks that are a part of the build. There at least needs to be air connecting the blocks. Any path will work, as long as there is one. Each level also needs to overlap by at least 1 block, lest the robot would be unable to get into the next level from the level below, etc.

When re-running the build make sure to specify 'resume' so it picks up where it left off. Remember the robot will auto refill on supplies if you put a chest to the left of the charger (and if you need a lot of storage, you can keep chaining chest to the left). Be sure and have empty slots, too, so the robot can dump trash it had to mine (assuming you're building into existing blocks).

[Tortoise-zz]

Thanks guys, while running the build with crash.lua to provide logs it actually built with relatively no problems. for some reason it is building from the top down, and the iterate error appears when trying to move from layer 1 to 58 or however tall the model is. I'll see if i can provide a comprehensive guide for others trying to implement this code

[InfinitiesLoop]

It will build top down, so that it can always get back to the charger. If it went the other way it’d block itself in. Remember if will never step into a block not described in the model. The charger doesn’t have to be on the bottom level though. If it’s in the middle, it builds the bottom levels from the bottom up, the upper levels from the top down, then the charger level last. You can see it do that in the time lapse when it builds the sphere. Not that this is helpful for your problem, I just find it interesting.

[Tortoise-zz]

i did notice that in the video - just thought the script would offset the build from the charger by a certain amount... it does look like the case but it offsets it to under the build? i'm near the last layer of my structure and it looks like it is going to build right over the charger. will soon find out.

to be clear: charger is on level 0 (in the ground) robot was placed on top. chest to the left with supplies and script run. it's a flat world no obstructions at all.

robot heads to the top layer and commences build. it got through a few layers before descending to a random point and trying to charge. i moved the charger to this point to keep the script running and manually topped up supplies. i've moved the charger 3 times but it now seems to be happy with its current location... where it will build over the top

Now on the final level it's reverted back to charging at the original charger location it was placed on, so it wont build over it. i'm guessing this may be due to which upgrades are currently installed on the robot itself.

more importantly, it seems to have missed a section of the build. i've just double-checked with the structure the .nbt file was created from, but also possibly due to my lack of knowledge of mcedit2 :P

[InfinitiesLoop]

The robot's charging location isn't magical or automatic in any way. It's specified in the model file itself. It's supposed to be anyway, if it isnt then that might be the real source of your problem. Compare your model with simplehouse for example. See where the 'v' is? That indicates not only where the robot's home location is, but which direction it should be facing relative to the rest of the model. You can use '^' and '<' and '>' and 'v' for each cardinal direction. And that location can be on any level of the model, not only the bottom or middle or whatever.

[InfinitiesLoop]

Also, if your model is very large, you can't specify the actual block layout in the script, because it won't fit in the robot's memory. The worldtree model was my proof of concept for a model that worked that way. In that case, the base model file has to specify where the starting location is, so the robot knows without having to parse through every level file. See here:
https://github.com/InfinitiesLoop/oclib/blob/master/builder/models/worldtree.model#L8

That data is just the exact same thing that is determined in a regular model file like in SimpleHouse.

[Tortoise-zz]

strange, the model is not near as large as the worldtree, and sure enough Line 8 is quite the same

https://github.com/Tortoise-zz/nod/blob/master/nod.model#L8

you can also see that level 1 has 1184 dirt - this for whatever reason was not placed, so the structure hovers 1 block above the ground height