Demolishun

I think I may have solved this. I put in a 5 second startup delay before anything else happens. It seems to have perhaps fixed the issue with the turtle startup going into lala land. Yeah, I have been fighting the chunk loading for a while. I know older frame mods had this same issue apparently. The solution was dual chunk loaders. Well, I will keep testing and let you know what I find. Thanks for getting back to me quickly. I kind of figured I was in uncharted territory using the Arcane bore, RiM, and chunk loaders. But it does work mostly. Once I figure out this computer boot thing. When I get a chance I may do a small test setup that has 2 ender chests. Put an item in one chest and the carriage should pipe it to the other chest. This would allow for remote testing of the chunk loaders.

@jakj, I have a dual chunk loader bore setup and it keeps stopping. Everything is okay, but I keep finding the turtle controlling the two carriages is stopped working. It is just in lala land. I have delays, but maybe they are not where they need to be. Here is the code: local running = true local engineSide = "back" local engine = peripheral.wrap(engineSide) local direction = 3 local boreSide = "front" local bore = nil while running do -- is the other carriage in front if turtle.detect() == true then print("moving bore") sleep(2) bore = peripheral.wrap(boreSide) if bore ~= nil then bore.move(direction, false, false) end else print("moving self") sleep(2) engine.move(direction, false, false) end sleep(0.5) end Anyway, the setup is like this: http://imgur.com/a/sKJoi#0 The whole idea is the support carriage behind the main carriage is the controller with a turtle at the front. When it starts it checks for the controller from the other carriage. If it sees this then it waits a couple of seconds, then tells that carriage to move. Then it loops. If it does not see the carriage then the other carriage was able to move. So it waits 2 seconds and then moves itself. Both carriages have chunk loaders. The strategy is that only 1 chunkloader will be moving at any time. That way one will be in actual existence in the world keeping everything running. So I remember seeing something in this forum about the computers having issues. So of course the code is designed to be rebootable. What is happening though is the computer is rebooting, but at some point it glitches. I find it in a state where it does not make to the point where it actually will print anything out. My main question is: Do I need a big fat delay before everything in the program? That way things will settle and keep this out of lala land? I am running 1.5.2 Unleashed 1.1.4. I have the latest version of RiM 2.3.0. Thanks

Awesome sub! My first sub was done with yellow frames so I could use it as a work platform under water. Totally made the Beatles' song awesomer. Here is something cool I found today: imgur.com/a/CDiK8/noscript#0 I was wondering how to do this and the answer is the frame templates. Not nearly as simple without RIM. Thanks Jakj!

I used the translocator to steal an entire end portal lava and everything. So now my end portal is conveniently located near my base.

@jakj, I know it is probably a pain, but thank you for maintaining a 1.5 and a 1.6 version. It is really nice to not have to upgrade to use this awesome mod.

I know there is no registry. I just figured I would let people know there is a conflict. There was no conflict with 1.1.3. I just thought it was interesting that they added a mod between 1.1.3 and 1.1.4 and it happens to conflict with this one.

Just so you know the 1.1.4 version of Unleashed has added a new mod since since 1.1.3. The new mod is called switches that adds some fancy toggle switches. The numbers they used for the block IDs clash with RIM 1.2.1.0. I resolved this by putting the IDs that clashed before yours. I am assuming you are adding IDs after those you had already allocated for RIM 2.0. I have not tried the RIM 2.0 yet. I had enough issues migrating from 1.1.3 to 1.1.4 to change the RIM version. Is there a place you can still download 1.2.1.0?

Holy crap dude! That is the coolest quarry I have seen to date. It is way cooler than the traditional quarry systems. This is by far one of the best mods ever made for MC. I never did get into quarries or frames with RP. I mostly was a turtle guy. But these frames are just neat. I am still thinking about eating those big redwoods (not the natura, the biomes o plenty redwoods) with a frame system. I am thinking turtles, but the diamonds would be spendy for a whole 4x4 grid of them. They would never wear out though. The frames would make them need no fuel too.

Yeah, I was not even thinking about where the game is actually spending the most time. Premature optimization on my part. There is a lot more going on than just finding cubes in a set. Yeah, it was not designed for everything to be converted to entities and back on that large of a scale. Edit: The bigger on the inside is a ref to doctor who. Edit2: Doh, just reread your comment on that. Nice!

Do any MC mods use OpenCL for any kind of high speed code? I was thinking that some of the code in this mod could benefit from that kind of speedup. I wrote a fractal algorithm in Python using Numpy that I sped up hundreds of times using an OpenCL version of the same algorithm. It benefited partly because the algorithm can be parallelized significantly. Even though the Java bytecode is JIT compiled I still think graphics hardware could do better. I see the block search checks on your code to be similar in that they do not necessarily rely on the results from one check for another block. I would imagine there are OpenCL libraries for Java. The one I used was PyOpenCL for Python which is a nice wrapper around the library. Obviously if the users hardware does not support an OpenCL device it could be ignored on those machines.

@Shade25, That sounds awesome. Do you happen to have a video of it in action?

But what happens if the tardis teleports into itself? Will it be like crossing the streams?

In addition to the trans locator can you make it so structures inside frames are bigger on the inside? Edit: But only for the blue frames.

Bah humbug! I waited up all night for this. ;)

I am thinking of the blue blocks that are not connected to the main frame. Those would not be detected until the second loop. I would say for the second loop (if the main frame blue blocks are not analyzed in that loop) any blue blocks would be stopping points regardless if the sides were closed. I was thinking of the other block types and looking at your code I could see problems trying to apply their rules in combination. I could see a recursive effect happening. Like say you tried to apply the rules of two blue frames. They would recurs over each others blocks forever unless there was some kind of set vetting system where a block could only be analyzed once.