Posts by narc

Well, you see, when you use covers on frames, you're telling them not to attach to anything. You might try panels, or just leaving the frame sides exposed -- in both cases, the frames will attach and pull things along when they move.

Right, as Sinnaj said, you can look at the API for how the energynet works -- specifically, in ic2/api/energy/usage.txt, which is a very detailed explanation of how it's intended to work.

If you want some code to look at, I'll point at my Interdictor tile entity from BeamMeUp. It does a few things more than just connecting to the ENet, but it should otherwise be a reasonable reference implementation.

I'm not sure how I feel about the use of this forum vs. the Support forum for API questions; they really do both work, though I suspect the Support forum gets more eyes.

Well, I was going to say you could get the Item singleton out using Items[ItemStack.itemID] and ask it if it's instanceof ElectricItem -- if so, as the API says, call charge with ignoreTransferLimit and simulate both set to true... but ElectricItem is final and the things IElectricItem has don't seem to help.

If you're just interested in fullness, you can try to get the damage value -- I believe it's 1 for full items and something like 31 for empties (don't quote me on that, though, I haven't checked recently).

Am I helping you go in the right direction, at least?

Betcha folks thought I'd forgotten about this? Not on your life, silly pants! Here's a status update that affects BeamMeUp:

Continuing the saga of figuring out where I grab time for myself from the fairly small bits thereof that life has been leaving me lately, I've managed to use most of today setting up a Jenkins at http://ci.narc.ro, and having it build both LiquidUU and BeamMeUp. What this means for the future: no more 'b' releases, ever -- they'll just get a build number increment instead. I'm quite happy about that, they were starting to look really ugly to me.

Regular players are strongly urged to continue using the normal download links in this post and on the narc.ro website, but those who, for some reason, want the bleeding edge (maybe saw something interesting in the commit history on github?) should be able to get their desires fulfilled now. As always, bug reports are very dear to me, just remember to tell me the versions of everything relevant so I know where you're coming from.

Quote from Quintine

The multi input output would allow for a much larger ability to be used with mod machines, Gregtechs come to mind as nearly all his machines have 4 ouitputs (Some 5 now i think about i, and 1-2 inputs)

Definitely sounds like something for an advanced accelerator, if one of those ever gets made.

Continuing the saga of figuring out where I grab time for myself from the fairly small bits thereof that life has been leaving me lately, I've managed to use most of today setting up a Jenkins at http://ci.narc.ro, and having it build both LiquidUU and BeamMeUp. What this means for the future: no more 'b' releases, ever -- they'll just get a build number increment instead. I'm quite happy about that, they were starting to look really ugly to me.

Regular players are strongly urged to continue using the normal download links in this post and on the narc.ro website, but those who, for some reason, want the bleeding edge (maybe saw something interesting in the commit history on github?) should be able to get their desires fulfilled now. As always, bug reports are very dear to me, just remember to tell me the versions of everything relevant so I know where you're coming from.

Dammit, no. Stop telling people to destroy their blocks and lose their work! Update your IC2.cfg to use the values stored in IC2_map.cfg, NOT the other way around!

Come on, follow my logic here:

• when the world is created, IC2 stores IC2_map.cfg inside it, containing its current block and item ID assignments.
• some time later, something happens (like the IC2.cfg gets deleted), and the block and item IDs get reassigned to different values.
• when trying to load the world, IC2 says "your current settings don't match the ones I had when the world was created"

At this point, which way does it make sense to resolve things: change the world to match the config, or change the config to match the world? Note that changing the world includes running it through something like mIDas because IC2_map is purely informational.

I can bunch them a little tighter, but I'm not sure why -- the GUI isn't going to change any. As for export slots, that is a thought; possibly with increasing the number of input slots. Perhaps an advanced variant -- the current accelerator is really meant to be used in production automation; it only has a GUI so that you can check up on it.

No, he's not forgetting. He's suggesting the recipe is a good one, and would be quite reasonable, if implemented.

Quote from Quintine

Good to hear, iv been hanging for some news for a while

You should only really worry if you don't see me logged into the forum here for days on end

Quote from Quintine

Edit: Do you think you could change the default name of the Accelerator to UUM-Accelerator so it doesn't have the same name as RP2's accelerator?

Certainly can! Sooner or later I need to look into externalizing the language bits, too, but this'll do for the interim.

Whaa? You mean I had it all along, but didn't think to check? Oh, my...! Thanks kindly, good sir.

It does if you configure it... just like the OP says. Here's the relevant section of my own config:

PreferredOres {
    S:dustBronze=ThermalExpansion
    S:dustCopper=ThermalExpansion
    S:dustGold=ThermalExpansion
    S:dustIron=ThermalExpansion
    S:dustObsidian=ThermalExpansion
    S:dustSilver=ThermalExpansion
    S:dustTin=ThermalExpansion
    S:ingotBronze=IC2
    S:ingotCopper=ThermalExpansion
    S:ingotLead=ThermalExpansion
    S:ingotSilver=ThermalExpansion
    S:ingotTin=ThermalExpansion
    S:nuggetCopper=Thaumcraft
    S:nuggetIron=Thaumcraft
    S:nuggetSilver=Thaumcraft
    S:nuggetTin=Thaumcraft
    S:oreCopper=IC2
    S:oreSilver=ThermalExpansion
    S:oreTin=IC2
}

Agaricus, a recommendation: when generating the config, add blank values for everything in the ore dictionary you don't have a default for, and ensure that when read, they behave as "don't unify". It's easier than dumping the ore dictionary and digging through the FML log.

Personally, I'd love to be able to monitor my Redstone Energy Cells (from Thermal Expansion), but I have no idea what the API for them looks like (if any). If you'd be willing to look into it, it'd really make my day

Quote from viliml

It would be great if you added support for the assembly table and assembly advanced workbench in the accelerator! Maybe even the regular autocrafting table!

The problems with doing it to the assembly table are: 1. handling the recipes that have more than one input (I think the most we'd have to handle is 5; diamond chipset + all four colors of pipe wire); and 2. handling recipes with multiple possible outputs (iron gates come in two flavors, for instance). I can see a possible fix for both problems: disable the accelerator input slot (and/or have it automatically insert into the assembly table) and use the assy table's next target item as the output item. What I don't like about this option is that it's basically all one big special case -- it doesn't work at all like any of the other supported connections. This is not a reason not to do it, but it does make me a little unwilling.

As for the autocrafting table, it's already instant -- the only limitation for getting stuff out of it is how quickly you can pull things out of it, and that's the same limitation as on the accelerator. What, exactly, is there to accelerate? It also shares the "needs multiple inputs" problem as the assembly table, but again, that's resolvable.

Quote from LostCoder

[How about an] antimatter engine for BuildCraft.

That sounds appropriately overpowered for something driven off UU-Matter. It's also closely related to the Antimatter Generator (for EUs), which is currently not one of my favorite ideas, but if I do one, I'll do the other.

And if anyone's wondering about progress (or, rather, the lack thereof): I'm (finally) starting to settle into a pattern at my new workplace, so I should be able to resume working on LiquidUU soon. Until now, I've been mostly looking out for compatibility -- if an update had broken LiquidUU, I would've fixed it ASAP; but that, happily, hasn't been necessary.

...right, that gets you an ItemStack. If you really want the Block for some reason, you have to fetch it from Block.blocksList[stack.itemID]. This is a vanilla thing, not an IC2 API thing.

RawCode is a jerk, but he's not inaccurate... most of the time.

Quote from RawCode

TC3 is great exsample of [...] mod strongly against any means of automation.

Except its own automation (golems). Which take a bunch of grinding to reach in the first place.

Actually, 10,000 seconds sounds exactly right for a cold breeder -- did your efficient breeder have time to heat up to 64,000 heat? The other problem is probably that you got the cell out of NEI or Creative: they come pre-cooked out of there; try crafting the depleted cells and see if it makes a difference.

Edit: Also, be aware the planner only shows you that the heating cells in the bottom-right corner are actually a stack of 64 heating cells if you hover over it -- this may have some relation to your problem.

I can't speak for anyone else, but I've never in my life started the GUI version of the Minecraft server. I honestly expect both would work equally well, since they're running the same code and all.

Quote from agaricus

[...]I may end up abandoning my addon in GregTech's favor. Although I suppose it could be useful to maintain OreDupeFix separately as an standalone addon

It is -- there are plenty of people who don't run GregTech (I'm one of them). I do agree with your later point that this should be part of Forge, though.

Quote from agaricus

Good catch. Fixed in 1.4.

Thank you kindly, good sir. I really love not having to think about the variants of dusts and ingots I've got going. Now if only we could convince people to put their [metal] blocks in the ore dictionary, we could unify those, too (as I don't think it would be appropriate for OreDupeFix to register them).

I'm too tired at the moment to make the change myself, else I'd make you a pull request, but when assigning the new output ItemStack, you should really make sure it has the same .stackSize as the original output. I don't think players like it when their copper block uncraft to a single copper ingot, even if it is the correct variant thereof.

Yeah, the term "malicious code" kind of implies that it's doing something to break your computer -- if it just breaks itself, it doesn't count.