jakalth

Picture uploaded: HERE Bottom is a single segment. Left is a vertical tower. Right is a horizontal tower. They are scalable, upgradable by making them taller or longer, and simple to build.

Edit again: disregard the whole post. The MJ Adapter is simply malfunctioning atm. Posted details on your GitHub account.

Yeah, it can be fun. But for someone like me who is far to used to straifing, having to always look in the direction you want to go can be troublesome. Too used to operating things like aiming a tank turret one direction while driving a different direction... Same with turreted aircraft...

if y-control on the flight control module is set to 100%, it sometimes acts like the jetpack is off, preventing vertical liftoff. Otherwise, like Timendainum said, your jetpack might have gotten turned off. Pushing [K] in game should open the mps control menu allowing you to keybind your jetpack and flight control modules to keyboard keys. This will alow you to turn them on and off at will. Highly suggest doing both just in case this happens again. Also conveniant to be able to turn off the flight control when you want to stay on the ground.

4 rows of rec's. Input in the center area between all the cells. 2 output lines on the outside, that link to each other, but not the center input line. Fairly good and balanced way to buffer store large amounts of power. each tower can be a single power buffer on it's own tesseract channel, with several other towers nearby for different channels.

I went with the excessive power storage so I can run mine for short bursts with longer delays between running it. But then again, I don't have the high power demand to require constant operation. And the steam buffers in mine are mostly for show, and so I can tap into some of the steam when I want to for other uses, like filling buckets with steam for giggles.

I believe that the LM should also have very little memory usage, they don't show the liquid they are storing, it is all done with internal numbers. The memory usage it will have should at least be less then the high cost of your huge BC tank farm. Phazeonphoenix does have an elegant solution to the LM's quirks. And his design does scale quite well.

Oh, those things. Yep, they are part of the latest versions of Galacticraft, not the one in current Tekkit. but... I believe the trick is using the aluminum wire from GC to transfer the power and use GC's power storage block as a power converter. Should be able to output from GC's power storage block to a quarry just fine using either more aluminum wire or BC kinetic pipe.

Liquid managers(LM) hold a lot more per block then a BC tank, they are also able to manage the liquids in complex ways that you could never do with BC tanks. Only drawback is, each LM is a single block and can not interact directly with another LM, they require piping to interact with each other. but being able to hold as much as 32 BC tanks in a single block has its benefits.

Agreed on both accounts. It's the sheer size of the LM's that make them appealing. They also do work nicely with gates, pipes, engines, and anything else that can detect and/or use liquids. But they are costly and complex to make.

"Milker" is a steve's carts module. In combination with the cage module, it will milk a caged cow every so often(not sure how often...) and store the milk in an internal storage on the cart. Not entirely sure how to actually use it in game though. I have not tried it out yet. I think the cart has to have rail lines going through your cow farm. My guess is the cart bumps into a cow, loads it into the cage, milks it, then releases it again and continues on along the track. Probably repeats the process as it travels, with different cows.

well, it would require traveling quite a distance from your base(1000+ meters) to mine for it, or creating a mystcraft age specifically to mine in. Uranium ore has a very low spawn rate, between 0 and 2 ores in a 15 x 15 area. it spawns near bedrock If your mining nearby, or in a place you had been to before you changed the config, there will still be no ores in that area since that part of your world is already logged by minecraft, so no new ores will be in those locations. Creating a new mystcraft age would be the same is starting over from scratch, in terms of ore generation, so it should generate the ores properly. Also traveling far enough from your base should have the same effect. newly generated ores with uranium added to them.

To maxamize output, 100% uptime is not really needed unless you can utilize every drop of steam your reactor can produce. Otherwise you end up with wasted steam. The reactor will still be able to output full steam power, even without deuterium being generated, for a somewhat random amount of time. This time is going to be short, probably no more then 1 minute after the deuterium stops being produced. Steam generation is not always consistant due to many variables in how much plasma is generated per cell and how far the plasma spreads out in your reactor. It is a rather large set of random variables to keep in mind. Only drawback to running your reactor at full power like this is the cost of setting up all the turbines, and the fact that it will be eating through deuterium cells like a mad man. BUT, it should output enough power to more then make up for it's hunger. If your going for efficiency instead of max power, lowering the number of turbines, slightly, and finding your reactors cooldown time is key. Maximizing steam usage for a given amount of deuterium will give you a lower powered reactor that produces power for a longer period of time, vs: a much higher powered reactor that eats through deuterium quickly. The highest efficiency I have found, requires delaying deuterium insertion until your reactor is nearly cold, or 80% of it's cooldown time. Once you find how long your reactor setup will run off a given amount of deuterium cells(2 for example). Over at least 3 runs for averaging. You can then take this time and use 80%-90% of that length to set your delay. You will be lowering the potential output of your reactor doing this, but you will save on tin and glass for deuterium cells. Example: I have a reactor setup that is currently capable of outputting 1175 MJ/tick, consistantly(averaging out its total power output over the duration it is capable of outputting power). I have it set to take 2 deuterium cells in a row, with a delay of 1 second between the 2 cells(seems to increase efficiency but is probably just an illusion). It then sits and waits for 10 minutes, completely cooling down before restarting cold. the turbine array of 45 large turbines keeps spinning for 7 minutes after the deuterium cells are inserted. All total it nets me about 9,800,000 MJ in 7 minutes and 0 MJ for the next 3 minutes. This power is buffered into 4 sets of 10 redstone energy cells that output their power to a fully powered MFR laser drill and a 50x50 4 Deriver MFFS forcefield system with 15 speed upgrades in the generator. The reactor is self sustained, powering its own chemical extractor and auto crafting unit to create the dueterium cells from the tin the laser drill produces and sand I have piped in from elsewhere. I have never used more then 10% of the power in my buffers even with drawing extra power for other experiments on top of the constant demand from its usual sources. If I change things up and run it as a high output reactor, it would require switching to a 2 minute delay and increasing the large turbine count from 45 too 90+. It's power output would be brought up from a measly 1175/tick, to a much more substantial 2600+/tick. the downside is I would loose some of the total output, dropping that down to less then 8,000,000 Mj per 2 cells. not a big loss though considering I would be getting that much power about every 3 minutes. Reason I don't do that? Simple. I have no use for that much power. My whole base uses less then 1000 MJ/tick even if I have everything running at once. As for the CC --> Rednet issue. Here is a simple fix. Computer --> Dirt block --> Rednet cable. No more feedback issues, no more conflicts. Simply works. But only one way, from the computer to the cable.

waterproof switch pipe to divert the water between the phased pipe and a void pipe, on the sending end. That way you can have the pump always running at full speed(ish). Would give you a more consistent redstone signal on the receiving end. Then the switch pipe would be your on/off point instead of the pump and engines. That's about all I can think of atm. HERE:

Have you tried building it in a pocket dimension as Phazeonphoenix suggested? it will probably still lag to death inside the pocket dimension, but as long as you keep the whole thing chunk loaded, it should still work while your not there. And, it should also greatly reduce the lag you experience in the overworld. The more options you have to work with the more likely you'll find one that works for you. That's why it is nice to have different people giving different ideas.

I haven't played around with the particle accelerator for a while, just been grabbing bits of info from different videos. Some of it might be for newer versions of minecraft, like 1.6.2... I can't really test any of this myself, my game crashes when I try to fire up an accelerator, no matter the size. Something about my computer being old and not being able to handle the amount of data involved with running an accelerator... :\ from the videos I've watched, most of the info is for about the same version of atomic science that is in tekkit. I do know for a fact that the accelerator will spit out the strange matter at the point of collision instead of collecting it at either end. That has been more or less the way it's made strange matter for the last year. not completely sure about the size thing. the video that stated the minimum size for a collider was using the 1.6.4 version of atomic science...

The accelerator only needs to be a minimum of 9 blocks long. Longer accelerators work better but use up a lot more power. both ends need to send off particles at the same time.(give or take a few ticks) going at each other. the strange matter will not be at either end, but floating on the ground somewhere in the middle. you will need to collect the strange matter off the ground yourself. the accelerator may get damaged in the process of making the strange matter, requiring replacement magnets. The chances are small, very small, that strange matter will even be formed. somewhere between 1-5% chance. possibly higher. any material can be collided, the material has minimal effect on the chances.

actually, that is an option that might work.

lave + water in combustion engine = 1MJ/tick oil + water = 2MJ/tick fuel + water = 6MJ/tick(wait it's 6? my mistake...) different types of liquids give different amounts of power output in the combustion engine. If you really want to use lave, Magmatic Engines output 4Mj/tick, using lava, without the need for water. But, their total output per bucket of lava is lower then a combustion engine. Combustion engines are more efficient with the liquids supplied to them.

aah completely missed the autospawner bit... ghasts in an auto spawner need a bit more room to spawn. The height of the room needs to be a bit taller to allow for their size. Grinding them is tricky since the grinder needs to be the height of the top of the ghasts head, so roughly 3 blocks higher then the spawner. It will also have a hard time seeing the ghasts due to their strange hitbox. enchanted items gained via mob farming... that's a tough one... with the modular power suit and some of the other higher end armor, most will be useless. But some enchants are nice. Like if you get lucky and end up with a fortune enchant or a silk touch enchant. getting those placed onto a book would be useful for tweaking your special use gear. ok, most mfr machines will ignore a block directly in front of them. so it is safe to have them outside the walls of a spawn room. Just remember the limited range of the grinder when placing it. I've only noticed any real lag when dealing with tree farms. The other types of farms do not seem to lag noticeably, even psychotically over fertilized wheat farms..

Tree farms cause client lag with MFR. Simple as that. Non-fertilized tree farms less so, but still cause some client lag. 2 ways to really fix this problem. 1: switch to a different crop. Anything really, mellons, pumpkins, wheat for seeds, cactus for cactus green, even milking a squid for ink.(last one is a bit cheaty...) Also, fertilized giant mushroom farms are quite effective. 2: if you want to keep the trees. Steve's Carts tree farms are nearly lag free and have only slightly lower sapling output. They just require a bit more infrastructure to support them. Coal/charcoal to fuel the cart(or just logs), tracks laid down for the cart to run on, the cargo manager(s) to load fuel and saplings for planting, and to unload wood, apples, and saplings. They also only easily work with Oak, though the exotic plants module lets you use other types of trees. Mfr farms are simpler and cheaper, and unless you go ahead and spend the very high cost of making galgadorian tools for your reinforced hull steve's cart, you'll be spending diamonds, on occasions, repairing the tools. Yes, you can place blocks directly in front of the harvester. It limits the size of your fields a little though. But it can be used to protect the harvester from damage.

Do you have the redstone conduit set to output(orange) coming out of the energy cell? If not, it's not sending any power. Just hooking up the cell to the reactor should take roughly 150Mj strait away, even before the reactor turns on.(filling the energy conduits with power) If the conduit is still default(blue), it will not output any power from the energy cell. Documentation on this mod is nearly non-existent, which is why this topic and the original one were started. Any findings are useful for trying to flesh out the understanding of this mod.

Outside testing shows that Modular powersuit has issues with the Thermal Expansion 3 recipes. As in, it is still trying to use the TE2 recipes. Disabling Thermal Expansion recipes, for this mod, fixes this issue. When later versions of the mod are made, the mod will probably have this fixed up. Also, as of this post, Immibis Microblocks causes a crash to desktop error when placing TE3 Conduits. It tries to treat them as microblocks, and since they are not, it gives a brief item class mismatch error before closing minecraft. This error, if the mod is used, can not be fixed with current releases of Immibis Microblocks. The other Immibis mods do not have any noticeable issues. Lastly, several of the other mods might give crash to desktop errors dealing with recipes. These are also most likely due to the same TE3 recipe mismatch. Disabling TE3 recipes in those mods, for now, might fix them as well. At least until the recipes are fixed in later versions of the effected mods. Just giving you guys a heads up. Hopefully this helps you guys out a little.

Yeah, we can hope.