gavjenks

No. Minecraft is already threaded pretty much as much as it can be without a COMPLETE rewrite by Mojang. Multithreading can additionally be done within individual mods to the game (like computercraft could do all its internal calculations on an asynchronous thread) to make them individually faster, but that's up to each individual mod developer. There is no such thing as an "addon" that magically rewrites every one of the 30 mods or so in tekkit to suddenly be multithreaded. You would have to convince each and every mod developer to do this individually, and then repackage the entire tekkit in a future update.

I think it is very much overpowered, and would not add to gameplay value. Specifically, the ability to just dial in a coordinate and blow something up. That eliminates the need to use most of the high end pvp options in tekkit, like sensors, frame airships, etc., and replaces them with a much more simplistic and less fun/challenging alternative. Additionally, the fact that it runs on an entirely new power system is confusing, and wouldn't work into the tekkit world very well, unless it came along with an additional mod for converting between IC power and ICBM power. Which, as far as I know, does not yet exist.

the rest of the machine doesn't do anything, or at least it wasn't doing anything at the time (not receiving any power or signals). Might as well cut it off right where that blue alloy wire is. Those two frame motors on the ends in the picture simply aren't getting pulled along.

those are 2 pairs of frame motors. Each has the traction side facing the other (two for up, two for down). It works fine for moving the rig up or down, but the problem is, if I move it up, the one fram motor on the end on the down side doesn't move along with the rest of the rig, it gets left behind. I was under the belief that the traction side of a frame motor acted passively like a frame, which would mean that the inner frame motors should be dragging the outer frame motors along with them, but they aren't? What am I missing? Thanks!

1) Ice provides 300 cooling, buckets of water provide 250 cooling. Ice has the advantage of stacking (less likelihood of a tragic traffic jam) and very slightly higher cooling, but unless you're using EE, it also has the slight disadvantage that compressing snow to make it uses up a decent portion of the power you produce from your reactor. More so if you begin with water -> snow. 2) autocrafting tables only work with buildcraft if you pump directly in. If you want to use redpower tubes, you have to do something different, but you have 2 options. One, yo can put the items i a chest NEXT TO the auto crafting table, and it will pull the correct ratios out of the chest when ready. Two, you could use an auto crafting table Mk II, which is basically just a chest and auto crafting table in one, to do the same thing in a single block, making it inherently redpower friendly.

Maybe if you actually bothered to read both sentences of two sentence threads before quoting them, and maybe if you weren't so obnoxious to people trying to help you, your problems would be solved a lot sooner. I had a couple ideas I might have tested for you, but forget that.

No, on my server I hooked up one at spawn to a single 1 EU/tick solar panel and it terraformed just fine over the course of several real life days. @OP, I'm not sure why on earth you would expect a flatification terraformer to do anything whatsoever on a perfectly flat brick patio...

If youre using ice cooling anyway, simply go with an MFFS reactor controller, and then you can put the ice in a separate inventory, leaving your reactor to ONLY ever have empty slots where the uranium goes. (fill all other slots with buckets)

I dont think theres any way to make sure the pattern is maintained. If you want to maintain your layout and ONLY uranium cells are being depleted (for example a mark 1 typical reactor with uranium surrounded by coolant), then you can do that by filling the entire reactor with buckets, then removing only the ones that are where the uranium and coolant cells go. Hook up a transposer feeding the reactor from a chest with uranium cells, and then hook up a filter pumping out of the chest depleted uranium cells only. As they run out, they will be replaced by new uranium cells (including depleted ones), in the correct pattern since that will be the only available slot in the inventory with everything else jammed up by buckets.

Wait, I'm an idiot. Those top two blocks are leftover from an earlier, less efficient plan, and it never even occurred to me to remove them. it's actually THREE blocks. And technically, both the frame and the deployer could be stored inside the turtle and placed every turn. The single "everything in one turtle" possibility would still have its uses though, for instance in transporting the whole thing on site to pick up a frame sled and tow it somewhere, etc. I.e., when the system is not actually towing anything, it can just move around as a simple turtle. But when it is towing something, there would be no need to store those two blocks (just extra unnecessary steps) So ^That is possible (and useful for moving it around when it is not towing anything). Although please note that if you do this, you will have to reorient the whole rest of the machine to accommodate whatever direction a turtle naturally places an assembler in. Very very little, actually. It would pretty much just be a bunch of short scripts spelling out exactly what the turtle should do step by step, like what I wrote above (but more painstakingly detailed, obviously). Not anything very clever or coding complicated though. Then you would have a tiny shell program that just listens for wireless instructions and decides which of the 6 scripts to run Shrug. The main disadvantage is not coding. The disadvantage is that it would move like 5x slower than other frame motors. However I think this is MASSIVELY made up for in most situations in terms of ease of deployability, cheapness, and the fact that once you write the code, you can upload it to pastebin and make another one of these in like 10 minutes, even in survival. NOTE: to help in practical situations, you may want to add a few more blocks to have a permanent battery and solar panel sitting there. Wouldn't be quite as small, but it would make the whole thing move VASTLY more quickly, since waiting for the frame motor to charge from scratch is the main bottleneck here.

Inside the assembler (this could be a deployer. I just made it an assembler to make the following descriptions easier to understand since there is also a deployer inside the turtle) 1 screwdriver Inside the turtle 1 frame motor 1 deployer 1 solar panel 1 screwdriver 2 frames To move up or down: 1) turtle moves around to the side of the assembler, to control it 2) turtle places the deployer underneath the assembler. 3) assembler screwdrivers the deployer to face to the side (powered by turtle) 4) turtle "drops" the frame motor into the deployer's inventory 5) deployer deploys the frame motor (powered by the turtle) 5B) the frame motor will be pointing down by default (this only happens when the deployer deploys it, not the turtle). But if you want to go up, the turtle now "drops" its screwdriver into the deployer, then activates the deployer twice to reorient the frame motor upward. If you want to go down, just leave things as they are. 6) The turtle sucks out the screwdriver (if applicable) then digs the deployer 7) the turtle places a frame where the deployer was. 8) the turtle moves back and places another frame, so all 4 frames are connected in an "L" shape in front of the now correctly oriented frame motor. 9) the turtle moves around and places the bluetricity solar panel above the frame motor. 10) the turtle waits until the frame motor is charged, then digs the panel, moves down, and activates the frame motor, pushing everything up or down. 11) The turtle digs the frame motor and the frames, and moves to catch up with the rest of the rig one up or one down. Machine is now in its previous state, but one block higher or lower (including anything and everything attached to the 1 permanent frame, which is the highest one up in the above screenshot). If you want to move in any of the 4 horizontal directions: 1) turtle places a deployer under the assembler. 2) the assembler screwdrivers the deployer so it is facing to the side where the turtle is in the above screenshot (it has since moved out of the way and is now powering the assembler) 3) turtle places the frame motor directly in front of the deployer. Unlike assemblers or deployers, which always palce frame motors with the tracks facing one side, a turtle will always place a frame motor with tracks facing up. I have no idea why this is, but it makes this whole thing possible. 4) turtle "drops" its screwdriver into the deployer's inventory. 5) deployer screwdrivers the frame motor so it is facing in the desired direction, any of the 4 horizontal directions being possible. (deployer powered by turtle) 6) turtle sucks out screwdriver and digs the deployer. 7) The turtle digs the frame which is above the frame motor now. 8) turtle places the solar panel where the frame was (so it is on top of the frame motor), and waits for the frame motor to charge. 9) turtle digs the solar panel and replaces it with the frame again. 10) turtle activates the frame motor from a direction which will not cause it to be in the way (depends on overall direction of movement selected) 11) turtle digs the frame motor and catches up with the rest of the rig. The whole rig is now as it was before, but one block to any of the 4 sides, along with anything attached to the one permanent frame (the highest one in the screenshot) So do I win? =) Only 5 blocks exist in the world in its resting state, and only 10 blocks total, including in the inventory of the turtle. Only ONE frame motor is used. And yet the setup can (slowly) move 1000 block frame construction in all 6 directions. NOTE: the above was using computercraft 1.4, which allows you to interact with inventories directly. If you're playing with currently standard tekkit computercraft, you can still get this to work, but it is a bit more complicated, requiring the turtle to also carry a transposer and a pneumatic tube or two so it can drop stuff and then have it injected into inventories Bonus Edit: If you free up one additional inventory slot by sharing the screwdriver between the assembler and the turtle, then it could actually carry around its own entire MFFS force field system + HV solar + lapotron crystal to protect the frame ship at a moment's notice (set up time probably about 5 seconds) Or alternatively, 2 portable, separate, 6 directional scatter beam/explosive laser turrets

That is exactly what I just suggested, except with additional unnecessarily complicating steps added in. Unnecessary because there's no reason to worry about pinching pennies when the OP already has automatic ingredient factories?

The horrible graphical glitches it causes on frame motors + general uselessness to me as a mod make me want to trash it ASAP. However, since it modifies base classes... ? Is there a version of tekkit available without it or something?

Buildcraft does many things by emulating a fake player, and then tricking the server into thinking that fake player is doing stuff that would be impossible or more difficult to do otherwise. I sued to get weird errors sometimes when the server tried to kick buildcraft for moving wrongly and stuff, heh.

Secret rooms is an inappropriate mod for any actual protection. It is a fun toy to play with, but not a protection plugin. There are only two ways to ever actually protect a region in Minecraft SMP: 1) Have some mod (like WG or factions) that actively denies players the ability to place blocks or do other things in a region. Unfortunately, like you said, these can break pretty easily when mods come up with new ways to place blocks they haven't though of. 2) Hide the region by not ever even sending any information about it to the client in the first place. I'm not talking about secret buttons. I'm talking about something like a plugin that literally sends packets to the client that do not include the room at all, but instead have data that just tells the client there is blank stone there. So no matter what x-ray or anything you have, you will not see the room. And then only when you approach, does the server send you the actual data. As far as I am aware, no such plugin exists, although it is possible for it to. Anything else WILL fail when somebody uses a special texture pack, x-ray mod, etc. Therefore, the only reason to include this mod in tekkit would be for the cuteness factor. And personally, I don't think it's really all that cute, meh.

This is basically the same as asking "Hey can somebody like... build a house for me and send me the schematic so I can WE it into my world?" It would be a whole different story if YOU had written some code, and you wanted help debugging it, but coming on here with two other programs written by other people and asking a third stranger to merge them together for you is just really lazy and confusing and weird. I mean why are you even making a fancy zombie grinder if you aren't going to do any of the difficult stuff yourself? If you just want pretty things to look at without doing any work, rent a movie. If you want to show off to your tekkit friends, then do the work yourself so you actually have something of yours to show off. If all you want is zombie meat, then make a grinder that doesn't even use a computer (not that hard). I don't get it.

I have a very simple solution to auto filling your cropmatrons. Merely place 3 cropmatrons next to one another, and power them all. Pump ONLY weed-ex into one of them, ONLY hydration into another, and ONLY fertilizer into the third. Each one will fill all three columns with only one type of product, but across all three of them, you will be guaranteed to have all 3 needs filled for the region. AND if you stack them vertically, you can still plant in a 9x9 area.

The armor is silly and I don't care at all. So I will only address this point, the one that matters for making a server actually run. Collectors and condensers are not expensive, because you can duplicate the materials for collectors and condensers inside of a collector or condenser. The very first time I tried out EE a couple weeks ago, I read up on all the wiki pages, and then I proceeded to make a collector and condenser in about half an hour of gameplay, starting from scratch on an SMP server. I attached this to an area with a world anchor, and then logged off. I came back a day later, and spent maybe another half an hour taking my stacks of diamonds and condensing them into more collectors and condensers. Then I logged off. Two days later, I logged on, and after 1 total hour of time invested, from the moment I began empty handed, I had 30 stacks of diamonds. That is what people mean by EE being overpowered. It is objectively true. If you still have fun anyway, good for you, keep doing what you're doing. But if you believe EE is not OP, you are simply wrong. It is several orders of magnitude faster at getting things than any other plugin or mod for time invested. That is basically the definition of OP.

Yeah I THINK i know what you mean, but daytime larger pictures and ideally a 6 axis one without a huge occluding box around it would be helpful. Can probably figure it out though now, thanks.

This is a less than ideal solution, since it makes it inconvenient for new people joining your server. A more permenant and global solution that will automatically fix this for all your members is to go to the NEI config, and list every single EE item and block as a disallowed ID for NEI. Then they will not show up in the list for anybody logging on, even if they have EE installed.

Hi I'm trying to add a new texture pack, and everything works, except glass stays default. Does anybody know what mod or plugin is overriding that texture? I guessed optifine, but on another vanilla server, people use default optifine all the time without seeing default glass

A simple LV solar panel will get to bedrock in about 5 seconds. HV is kinda silly/pointless as an investment if you want to do this.

No this won't work for SIX directions, though. At least not any way I can think of. It works for four only. If you want to be able to move up and down, then you can't just have two plates sliding together. You need to have at least 3 separate components for a standard caterpillar design in 6 directions. 2 parts for up/down, and 2 parts for the side directions (you can share one = 3) But then you have to have two separate mechanisms that temporarily bind the pieces together or unbind them. So if you want to move up, you need to use a deployer to place a frame to glue the two side-side plates together so they will both move up (otherwise you leave a piece behind) Then if you want to go side-side, you have to bind the top of the up/down part temporarily, so it doesn't get left behind. Then you need block breakers to unbind each time you change direction. 2 binding modules + 2 unbinding modules + a 2-dimensional sliding plate module + a 1 dimensional sliding module = really complicated. More so than my system. Moving just side to side is fairly trivial. With a wireless turtle, i can do it in like 4x4 or so, I think. I want to be able to move up though too.

I have a method that works, but it is very complex. I am wondering if anybody has a more efficient way of using frame motors to make a single vehicle that can move in all 6 directions on command? My method: For each axis (two opposite directions, e.g. up and down), I have 1 motor. A turtle or deployer places the motor, which is then flipped or not by a deployer with a screwdriver (depending on which way you want to go on that axis). It is then pushed one over so its touching the main structure, and then it pushes everything in the desired direction. It is then gobbled up by a block breaker at either end and fed back into its turtle/deployer. This way, when you aren't moving in a given axis, all the machinery for that axis is one solid piece, not two floating disconnected pieces. However, this still requires multiple breakers/deployers, turtles, computerized control, wireless galore, etc. Are there any really simple ways I'm not thinking of?

OHHH this was it. Thank you.