joe5

ah, water strainers possibly the most usefull and glitch block in tekkit. could you please post pictures? can you see a water build up? can you post pictures of the creative one as well? is this on your server or somone elses? is the red-stone touching the strainers?

yep, we run a huge brodcasting system on my server and regardless of what you do to them, they will eat up to 72eu/t and no more.

remember that you need a wooden pipe to extract the power, and that it will eat up to 72eu/t regardless of what you are powering

use an energy link

hmm, I have been using a system of bock breakers and deployers to accomplish much the same thing (the two black things in the top picture) with a rolling caterpillar of anchors. however, I am not one hundred percent sure that chunk-loading is still enabled so I will check on that. good idea, though at the moment it does have a habit of crashing peoples clients if they spend to much time in its vicinity. is the system your are talking about on smp?

hmm, in that case I will try to beam a signal out and see if it matches up update: just checked, timers move at normal speed in force loaded chunks but the system does not

hi, I have just finished working out the kinks of an automatic machine and while it now performs rather well when someone is their it stops completely about half a minute after everyone has left the area. I have tried every combination of world anchors and anchor carts i can think of (including a red power based systems to keep them off the frames) but nothing seems to work. has anyone had any succes auto-loading frames?

is it caused simply by having build craft installed? or though its use?

I would say that in my experence, Nukes are not a problem. Nukes in the central storage area are.

ah, awesome terrain sculpting

did that map generate naturaly?

hmm, on the other hand, without them several of the frame ships operated by Allied would be invulnerable. what do you think of the idea of implementing a "nuke tax" to be paid once the server was reset?

Hi, I run a small tekkit server that periodically fights small wars over anything from land ownership to [mutual] bordum. however, recently their has been a lot of discussion about how to shift the focus away from individual pvp and more onto industrial warfare, frame ships, t&t cannons, base destruction, ect. our goal is to reduce the use of one person suicide missions and encourage large scale destruction. to this end we have enacted the following initiatives: disabled quantum banned the use of pickaxes during wars all wars take place with rain/night survival cannot be made a victory condition (winning requires more than avoiding defeat) what do you think? any ideas for additional initiatives, rules, or post-reset bonuses, which might encourage greater use of military assets and explosives during war?

okay, so This is a minecraft problem not a tekkit problem?

I am getting the same error. It started about 3 hours ago. anyone else?

Seeing as my server is currently running a destributed power grid using that exact technology i can testify that it does indeed work in tekkit. furthermore, while the system has broken several times we have never had any problems with the actual pipes themselves. Have you used a world anchor? Is the windmil actualy generating power? is that power being received by the link? how much power are you atempting to transmit? were both pipes placed by the same player? could you post pics?

Thank you very much for the help, we have implemented a hardware solution that replicates what you proposed above and when their is somone nearby all is fine. However, as soon as people move away it shuts down. This is despite multiple world anchors and it restarts immediately upon the return of a player to its vicinity. Any thoughts on what could be causing this? Do frames work with chunk-loaders? Thanks

okay: This is a picture of the hole build, it is just a basic duel axis, brodcast powered tunneler. This is a picture of the drill bank. This is a picture of the problem, when the drill bank was in the up position water and lava combined to create the peice of coble shown below. that piece of coble is preventing the machine from moving down and completing its drill cycle.

hi, In an attempt to automate our resource collection process a large portion of my server constructed a masive redpower mining machine. it operations using the traditional horizantal block breaker system and, when functional has been ver succesfull at providing materials. unfortunatly, it is prone jamming when lava and water form underneath it and prevent it from moving into its down position. If anyone has an idea how to eliminate this problem the help would be greatly appreciated. Thanks

Depending on the type of forcefield that you use their are a couple of known weaknesses. however, there are not many and the vast majority can be combated with forethought and careful planning. While I feel that it would be counter-productive to post any of them here, I would encourage you to download the mod in ssp and experiment with it. Try prototyping your base before you build it on a server.

thank you for quick replies, If i understand you correctly what you are saying is that the problem revolves around the need to convert both the map type and the block IDs. if we restricted mod use to mods guaranteed to appear in the next Tekkit would that allow the built in converter to make the transition or is it simply impossible without the use of a third party converter.

hi, I have been looking at the possibility of starting a small Tekkit server with a couple friends. since we are all very building oriented people world continuity is a fairly important factor and we were wondering whether maps generated under Tekkit 2.1 will be compatible with Tekkit 3.0. if not, is their anything that we could do to improve the chances of a successful conversion? Thanks

for the record, that map he posted earlier does actually work with tekkit. In fact it makes a great red power spy base.

hi, i am in a simmiar situation and am wondering if this is the definative answer.