Posts by AkhkharuXul

Quote from Rick

with new update buckets got nerfed they only cool 250 heat now but ice got buffed it cools 300 heat now. Makes me wonder do they want us to use EE?

You may have missed this part:

Quote

-Compressors can now be combined with Pumps to create snow from infinite water sources.

So now we can create ice using just IC2 without having to sacrifice tons of tin. [And it might actually be slightly viable since pumps make water once every 10 seconds.... ok maybe not -that- viable :)]

Ed: I'll retract the last bit since, water buckets are still more powerful then ice, considering if you were just going to use IC2 to make ice (with pump + compressor = snow, snow + compressor = ice) you'd also require 2 compressor operations to make 1 ice, vs just 1 pump operation to make 1 water. ---- then again if you were only using IC2 you'd have no way to make a CASUC reactor.

Quote from Alblaka

I'll probably disable bucket/ice cooling entirely and replace it with a proper addition-block of some sort. Eventually something you can use instead of a chamber, not providing coloumns, but large amounts of cooling.

Heh I was just looking at the "halved the effectiveness of water buckets" and was like "why do you hate us?" but... since it's just a temporary thing til the real deal shows up, I guess that's ok. [You know we can still make our crazy reactors, they just need to be twice as crazy now :)]. Guess it's fair since reactors output twice as much now

Quote from MJEvans

It's easier than you'd think. You send /multiple/ 32eU/t packets at the same instant. There are limits, each TF pair for a reboost can only support 4x the underlying wire maximum packet size. This means you'll need more pairs of transformers. Above a given point it's just cheaper to go to glass if for no other reason than your sanity (actually the fact that you'd more or less be making multiple cables the other way is why)

Query, when you send multiple packets of 32EU in the same frame (so in this instance, 512 EU/t total) over copper cable, how many times is the loss incurred? Is it once / packet or once for the entire 512 EU?

So in the example of 60 blocks traveled, copper cable would have 12 loss... would the loss for the 512 EU be, just 12 or 12x16 (so 192)?

An interesting note, if it's just 12 you'd get the same efficiency as EV. 12 loss out of 512 vs 48 loss out of 2048.

[Because I keep seeing Raw saying that he's using glass fiber to prevent the losses, when glass fiber can already transmit 39 blocks before loss is incurred...]
[When I first hear LVTs being involved, I thought it was "well 12 LVTs w/ 4 copper cable between each would prevent all the losses over 60 blocks"]

Quote from MJEvans

The overflow issue is entirely in IC2.

From another discussion I remember that IC2 specifies a 'chest' size of X for the reactor core. This is tied to the block ID, irrespective of damage value/etc. It just happens to /show/ us only the number of columns for the chambers we have installed. Every so often (every reactor tick?) it ejects the things stuffed in to the spaces that are unseen by automated insertions (which just take the next numerically open slot).

The easiest way of fixing this would actually be to just have the reactor stuff it's self with some (near) useless item. Wooden shovels for example. However I guess even those /burn/ which is exploitable... so something even /less/ valuable. Maybe a stone shovel with 1 HP of damage left.

Second easiest is a variant on the above, but simply not process the items in the hidden slots (leaving them to fill up until the unit is removed or something else empties them).

Third easiest is to, on each tick, have a 'pre tick' that goes through the 'hidden' spaces and stuffs whatever was in them in to the open slots within the reactor... before evicting the rest.

I -suspect- option #3 is what was chosen.

Display More

It's not actually a 'pre tick' it's on the tick where the power is produced. It goes through every slot checking for invalid items or items that are out of the "useable size" of the container and chucks them before it goes into the actual calculations for the reactor.

Also it was brought up earlier in this thread how other mods treat the reactor's inventory "kind of funny", this "add-on" takes out some of the funniness (or at least allows you to fill up the entire inventory, not just a row or so). Currently it doesn't have much of an impact, but fully automated reactors may be possible with the next release of red power 2.

Quote from Quartz

I perfectly agree with you.

Do you people know detailed mechanics of RP integrated circuits (sequencers, etc.), are they like repeaters - subjects to getting 'stuck' after reloging? And how do you expect your reactors to get implemented by random mortal if RP is not pasted properly by world editing software (or is it already?).

If you're talking about vanilla repeaters then no, they don't get stuck. Timers and sequencers are far better then vanilla circuits in lots of ways

There supposedly are some issues with redpower 2 and servers where things will stop working (but I'm not sure exactly which things get broken, might just be machines).

As far as loading schematics, I'm pretty sure they work as long as the circuitry isn't active (rapidly changing state) when the schematic is taken. [Though I could be wrong on this, and I'm not sure how it works with sequencers, I'm not a big fan of MCEdit so I try to use it as little as possible.]

Quote from MJEvans

Not just the retrievers; we can hope that the fix for 'overflowing' items is in 1.337 as well. In that case all we need to do is rapidly tick the retriever for empty buckets, and use a detector to trigger the refill. The question is, can that setup do a full 4 buckets/sec? (Actually dual injectors (filters driving buckets in) and retrievers could be setup with a tiny bit more work... quad if necessary).

Regardless of how it works, I'm pretty sure it will work. Seems like how the retrievers work will be the biggest factor, so if they're crap then everything falls apart, though I'm sure that could be fixable (through design) as well.

Are they actually working on a fix for the reactor overflow?
I'd still try to rapidly force the filled buckets in even so, since RP2 would just cause them to bounce back if they hit a full inventory (or not get sent to begin with if the inventory is full). Not to mention overflow collection is pretty easy to accomplish with RP2 anyways.

Quote from HeadHunter67

I saw someone suggesting using RedPower to turn cobble into panels - more items for recycling. The downside, of course, is that you need to invest gems in a saw, which is depleted over the course of the process.
It's up to the user to decide whether that's a worthwhile investment. Consider that you need to recycle about 4800 items to get enough UU-M to replace the 2 diamonds you used for the saw.

I think they were talking about vanilla MC glass panels, so macerating cobble to sand, smelting sand into glass, then crafting the glass into panes [though I'm sure you could cut them as well]

And if you're using buildcraft you could turn 3 cobble into 8 cobble transport pipes by just turning 1 cobble to glass. Though if you're running BC and need more sources of scrap, you're probably doing things wrong .... or you just wanna have LOTS of recyclers

Quote from Quartz

Actually, having all engines hooked up to the same pulse generator would work just as well as having 3 delayed signals. You would just need to place them in different order. First - circuitry being online and then engines. Since it isn't possible for you to place all 3 engines during one tick (can you click that fast? xD ), they are going to be innitialy desynchronised and pulse should prevent them from going into flashy red mode when they all synchronise. The question is whether reloging will force engines into synchronisation in such setup and it probably will. Therefore this cannot be realisticly applied, so your exact answers are likely to be optimal solutions. And this is what I meant in my question.

I'm not sure if reloading can sync them up, but I know the last time I played with a BC reactor, I had 6 redstone engines connected to 2 separate advanced wooden pipes and was only getting 2 buckets / sec (cos they all synced up). but then upon reloading one of the engines on one side got slightly out of sync so one side would pull 1 bucket / sec and the other bucket would pull 2 buckets / sec. It's stayed that way ever since though... [and obviously by sec I mean "however often redstone engines preform work when they're fluctuating between orange/red"]

I think the BC engines are too finicky to run without some sort of desync circuit.

Quote from SpeedDaemon

Regarding RP2 and CASUC reactors... Eloraam just posted a video of a "retriever" block. Basically it sucks the selected item out of a remote inventory connected to the tube network. This might mean we no longer need filters adjacent to the reactor hull, and can have a single tube for full buckets in, and empties out... It looks like as of RP pr4, a redpower-powered CASUC might be able to use 5 chambers!

Nice find, I didn't think we'd ever get anything like this. Yay for 5 chamber CASUC reactors I know I'll have one right off the bat.

And who knows, maybe it will help to make the systems more stable (guess it depends on how well the retrievers work).

http://forum.industrial-craft.…ad&postID=13456#post13456
^This

Though, it is rather on the side of "not safe". You could probably tone it down a bit, or re-create your buildcraft reactor using redpower (or come close).

[This is assuming they're going to add redpower machines, if not... you could still play with mark V reactors and use RP2 circuitry for the run/cooldown times.]

Quote

But: you are applying one negative tick per 10.4 sec (104 ticks? wiki says 1 tick = 0.1 sec, no?) to keep them desynchronized, because BC notices one-tick delay on an engine and ejects another bucket? Or is it because you are just preventing overheating?

I'll go ahead and field this one, the reason for the desynchronization pulse is to do just that, keep the redstone engines out of sync with each other. If the engines sync up then it doesn't matter how many engines you have hooked up to a wooden pipe as they'll all hit at the same time and only extract 1 item (instead of a number of items extracted = the number of engines connected to the pipe).

This was the problem I had when I tried bucket reactors w/ buildcraft. I haven't tried a desynchronization circuit myself, but it seems like it would work.

Heh, I thought about making a thread like this myself (cos it's a pain to search for the good reactor designs).

One of my favorite reactors (not my design) [Mark 1, 2.33 efficiency, 35 EU/t (2 chambers)]:
http://www.talonfiremage.pwp.b…=1o10101001501521s1r11r10

Also a slightly more costly version (though easier to remember design): http://www.talonfiremage.pwp.b…=1o10101001501521s1r11r10
I believe that one is by MJEvans.

Also I'm pretty sure Dezuman did a 2.5 efficiency Mark 2 that had like +3-5 heat/tick that should be included.

Quote from james_cochran

I have an MFSU, with a large amount of power in it. Connected to this is a HV cable which then splits into 2. One of these leads into an electrical engine (power crystal's mod), and takes 72 EU/t. The other leads to my house, where it is connected to an MV transformer, which connects to an LV transformer, neither of which is powered by redstone. The output of the LV then leads to a macerator, electric furnace, compressor and extractor. However, for some reason, no power is transmitted along the cable, even when there are items in the machines at the end (I have to power them by battery). Can anyone help?

There's about 3 common problems that could cause this; 1: Too much distance-based loss, 2: Improper wiring inputs/outputs [should be MFSU (1 dot) -> (3 dots) MVT (1 dot) -> (3 dots) LVT (1 dot) -> machines], 3: Accidental redstone power being applied to any of the devices (if the mfsu or any of the transformers is getting a redstone signal, the system will not work).

-- I don't know if the electrical engine is a problem (though I wouldn't think it would be) but since you said disconnecting it didn't fix the issue, I'd leave it disconnected to trouble-shoot the other half of the system, then reconnect it after you figure out why your machines aren't running.

Quote from Root Infinity

Explain?

I know back in IC1 days you could make a cobble generator with an automated miner and an ore block as "bait" then place the water/lava cobble generation in the middle. Probably still works.

I'm curious to know how the "power draw detection" works.

Cos it seems like you have filled buckets going into the side of the water mill, and then a filter below it (to suck out empty buckets, I would assume) which flows through a detector, then back into the deployer to be refilled. Maybe I'm just confused because the last time I tried to setup anything with automated watermills it failed because items entering from the side would go into the top slot of the watermill.

Quote from SgtChuckle

Would someone PLEASE explain what CASUC stands for? I can't find any references on Al's guide, and I think that the last 3 letters stand for Single Use Coolant, but please tell me what this is!

Constantly (or Continually) Applied Single Use Coolant.

Designation for the reactors that automatically stuff single-use coolants (ice/water) into the reactor [all the time] while it's running (vs just regular SUC where you stuff in some single-use coolants before you start the reactor up).

Quote from LordVe

I thank you for this. I no longer have to use 1 of the item, in this case Ice, in each open slot, to fill my reactor.

My only question would be, Can you make it so that it works with the additional pipes insertion pipe? I have to use EE's Chest and Ring to keep my ice from being thrown all over the room...

Unfortunately, no. (Or at least I don't plan to) I figure it'll cause more problems then it solves. It's a limitation built into reactors (since they always have 54 inventory slots; hence always free slots available when you need to have less then 6 chambers to connect pipes/tubes/other machines to the core).

I might still figure out a way to make it so we can connect to reactor chambers, which would should make insertion pipes work properly [on a 6-chamber reactor] (as well as giving several more surfaces to connect stuff to, which would be interesting to see the kinda crazy things people would make w/ it).

I don't make reactor designs but, I turned it into a Mark 1-1
http://www.talonfiremage.pwp.b…=1010101001501521s1r11r10
[Erg, I guess not quite Mk I-I, will not run in lava :P]

Quote

Distribution of explosion being one thing, how powerful is the actual explosion? I remember seeing something like 45 in the config, but the uranium add more, and I'm also not sure of temperature over time is an issue (obviously temperature at terminal is merely terminal).

Short Answer (to how powerful the explosion is): It's Complicated.

More Info:
Only 3 factors determine the "size" of the explosion, amount of uranium in the reactor, amount of reactor plating in the reactor, and the max reactor explosion variable [which is just the limit cap for explosion size].

It appears that 12 uranium (and no reactor plating) is the minimum amount of uranium to reach the default max explosion size of 45.
Though you have to think of that more as the blast radius not the destructive force.

As far as "destructive force" vs "blast resistance", I'm not exactly sure what it is for the reactor, Player did a number on it when he made the explosions spherical ... which is quite impressive, but makes it hard to read [Least I think someone said it was Player, forgive me if I give credit to the wrong person :)]

Yeah, MFSUs already output 512 EU/t so trying to convert them to 512 EU/t seems a little silly.

Though why it's only draining 1 MFSU is a little strange, it's possible that the top HVT isn't receiving redstone power... or that they both are, causing a feedback loop (the latter seems less likely) but considering your Mass Fab is receiving 1024 EU/t it would appear that everything is functioning normally... [the max 512/t for the mass fab is just the packet size, similar to how tin cables can only handle 3 EU/t but you can hook up 100+ solar panels to them and not fry the wire].
Note: That since the input on the 2 MFSU is only 90 EU/t that once they drain the Mass Fab will only be receiving 90 EU/t even if it's in the form of 2x 512 EU packets. An alternative would be to only wire up one of the MFSUs to the Mass Fab so that one MFSU would fill up then the entire 90 EU/t would go to the second MFSU and on to the Mass Fab. *shrugs* However you want to hook it up is fine.