Posts by Vandalite

Quote from narc

I'd appreciate if you could turn on debug.override in LiquidUU.cfg and get me the stack trace that will be printed when the Forestry integration fails to load. Debug mode is a little chatty, so you might want to turn it off afterwards, but if you get me that stack trace I can maybe do better than guessing. Maybe.

Sure thing:
http://pastebin.com/smSFgwUV

Something I noticed: This error isn't happening in single player play. In single player mode the squeezer continues to operate just fine. This is the error i'm getting on the server when it launches with identical mod lists and configurations.

I also see an odd error about extrabees being unable to see the forestry configuration due to some java reflection error. I think that error was in the other server log I posted as well. Related?

For now I'm dumping the extra empty cells down a void pipe, but yeah it does strike me as something that you'd want to clear up for obvious reasons.

Sure. It's a bit long though.
http://pastebin.com/1Lrs032T

And since you asked, it's Forge v6.6.0.499

Also, using the thermal expansion liquid transposer to convert UU to liquid form generates empty cells! This is probably not expected.

I'm using Thermal Expansion 2.1.7

Using the latest LiquidUU (0.7.11b) with The currently available Forestry version (1.7.0.3) isn't working properly. LiquidUU is not properly registering the squeezer (and bottler) recipies. I found this in our server log:

2013-01-18 00:08:29 [INFO] [STDOUT] LiquidUU: Loading Forestry integration...
2013-01-18 00:08:29 [INFO] [STDOUT] LiquidUU: Did not load Forestry integration: java.lang.reflect.InvocationTargetException

To answer my own question, the 1.95b hotfix linked on the wiki and the releases thread seems to contain this fix. You should probably use that one now.

I can confirm the copies listed in the public releases thread are not the correct version. The thread is labelled 1.95b but the downloads aren't, and they do not fix the problem with embedded cables.

The ones on the wiki however seem to be updated. Tested with that one and errors i've been running into are fixed.

Good thing I made a backup before I upgraded from 1.2.3! The glitch with the cf-cable block caused the entire chunk to reset. I had a whole power plant installed, and it got gutted!

I just tried this build on a blank map with nothing but a fibre cable in a cf block. That used to crash the server or client, or both. now it seems to be working.

Yay? how long till this hotfix makes it to the main page?

I noticed on the blog that a newer version of 1.95 was released, but was the filename or filesize changed? How can I tell if the one I have is the hotfixed version or the original 1.95 release?

Also, did that hotfix mentioned on the blog fix the embedded cable-in-cf-blocks problem, or should I be waiting for a second hotfix?

Actually I may be able to shed some more light on the situation. Try building this:

Charged MFSU -> Transform power down to LV through two transformers -> Fiber line -> 35 luminators.

In my case, the luminators are spread out over the roof of a big room I'm building, but I don't think shape matters much. Connect the output of the transformer to the main line last so that all the luminators get power at the same time.

Expected: All the lights should get power, and turn on. An eu-meter will show you massive power being transmitted for a few seconds to fill up the internal luminator capacitor, followed quickly by a low but relatively constant flow of power to keep the luminators topped off.

Actual: the first few closest to the transformer get their charge and the ones behind start blinking. If you disconnect the line halfway down or so, (starting where the lights blink) and wait for it to stabilize and reconnect, it'll charge up the next group. An eu meter *will* show the high current to get the lights charged, and then a low but constant *not pulsing* current to keep them topped off... but see below.

What isn't happening: If you leave the line connected, eventually the internal capacitor on the luminator runs dry, and they shut off, and then go back to blinking like mad. The luminator is *not* charging itself while on! It *appears* to draw a very low current while on, but this could be a glitch with the eu-meter. I just watched half my roof's lights go out, while plugged into a live MFSU. There was power aplenty.

If it's coded the same way the other ic2 machines are, shouldn't it be able to request an eu packet once it has enough room for it in its internal storage? I do not know how a transformer outputting at 32eu is suddenly only sending 2-5 eu at a rather steady rate, and not pulses of 32 like it would to any other ic2 machine.

Edit: Here's some version info for you:
Minecraft 1.2.3
Forge: 1.4.1.59
IC2: 1.81

Is this the right place to post my own results on building a power plant? I'm not the guy who opened this thread, but it seemed to be on topic. It's not even close to the same design either...

About that flickering light thing -- That almost crashed my client. I was migrating things from an old map to a new one, and one of them had four luminators attached to 150+ solar panels with a massive mesh of tin cable. Plenty of power, but the light would just flicker and the framerate dropped to ... 2 ... If I was lucky. I'm guessing the branching of the 'i need power' seek requests across that much meshed cable really threw the client into a frenzy. Putting a batbox in between the tin cable mesh and the luminator fixed the performance problem and the flickering.

The reason I'm commenting though is that this issue taken to large scales cripples the game engine.

I ran into that same problem, but I went back to the forge site just now, and it seems within the last hour or two, the 'recommended' build has been bumped up to 1.4.1.59. Using this version seems to fix that issue.

I'm still splicing together the client, but the server started without crashing and loaded ic2 without errors.

--Edit-- I just realized you were talking about the client. I ran into that error on a server build... but unless a dev here says otherwise, I still don't see why you can't upgrade to .59.

--Edit Again-- Client build finished with same forge version -- seems to be working fine.

Is there any chance you could make just the wires compatible with redpower2's microblock slabs? It would allow for some really nice wiring possibilities by laying the cabling directly into a wall and covering up the cable with slabs, making for a seamless-looking floors/celings/walls without having to make the walls three blocks thick.

Does redpower have an api for doing something like this that IC2 could take advantage of?

Thank you for that. Seems to be working now.

On another vein, I built myself an electric wrench today, and it works fine, as long as I'm not trying to do a lossless pickup. Holding the mod key 'm' while rightclicking just pops up the interface for the item I tried to dismantle, instead of dismantling it.

If you're seeing a looping cycle on the output of a batbox/mfe/mfsu check the positioning of your detectors. I've found having a detector sitting directly on the output of such a battery triggers the redstone cutoff for the battery, and since the detectors and splitters only update once (or twice not sure) a second, you get a nice loop of pulsing power from your battery...

I'm not certain if detectors on the input do it, or if it's just if the detectors are on the box's sides... will need some experimenting, but if you want to be sure stray redstone signals don't mess with your batteries, make sure the detectors are at least not in contact with the battery.

I'm trying to do something similar, but instead of one light to indicate "charging" or not, I wanted to have a *series* of lights indicating the charge status of a series of batteries. When charging only, or under load only, it's able to detect an empty (or full) battery and switch to the next one in the line, but detectors do not have the ability to tell if a battery is actually full, just if current is flowing, so if you are in a situation where your power generation is higher than your load, it will never think the battery is 'full' and switch to the next one, or if your load is higher than your charge, it will never think the battery is empty and will not switch to the next full battery.

What I'd love to see is a module you can stick on the side of the batbox/mfe/mfsu that triggers a redstone signal when battery is within %5 of full or empty... It would easily be able to tell what role it's playing by looking at the side of the box it's attached to: If it's on the output of a battery, trigger redstone on depletion (within a small margin of error - twice the output rating of the battery would be enough, to account for charging operations being done at the same time), if on one of the box's inputs, signal on completed charge (again, within a margin to account for the system being under load).

Just make sure not to let the battery itself see the redstone signal. I've seen some interesting side effects of putting cable detectors right next to battery boxes.

Such a module would allow me to make a system that would let me serial-charge an array of batteries, and would also allow me to build a power station capable of bringing backup generators online if all but the last battery are permitted to deplete themselves.

Unless someone can think of a way to do that using the current cable detectors and cable splitters...

They overheat.

I'm also in the process of building a centralized power station, but this one focuses more on renewable power sources (water towers capped by solar collectors). I did plan on having a backup generation system (geothem and buildcraft combustion engines with the conversion mod to convert to EU) but I'm running into an interesting problem with the regulator.

It's still in prototype stages so I havn't gotten around to making the building to hold it all, but here's my question:

I'm using EU Detector and EU Splitter cables to charge batteries in serial (instead of parallell). The idea being that the system should be capable of activing the non-renewable power generation systems only when the batteries get low, but the problem i'm running into has to do with how detector cables work.

When not draining the batteries, the detector cable is able to tell when a battery is full and activate the next splitter in the line to start charging the next battery.
When not charging the batteries, the detector cable is able to tell when a battery is drained and will activate the previous splitter in the line to start draining the previous battery.
However when charging *and* draining (charging the system under load when output is less than input) the detector cable is unable to detect that the battery is full because current continues to run through the battery. The total charging current simply drops to the output rate of the whole system and it doesn't send the excess current over to the next battery or signal that total current has dropped. The only way to get the system to start charging the next battery is to temporarily halt output from the station so the storage battery realizes it's full so it can trigger the switch to the next battery in line.

Would this make any more sense with pictures?

Does anyone know a method I could use to do this without running into the charging-under-load problem I've got?