O_O, did you just give us a charge pad with a "built in" power source? that rocks!
its great for the nether realm, or the twilight forest....prob even work well with Galacticraft.
It's not built-in, so much as you can now "pipe" items into the charging slot via automation, so that you don't have to have it hooked up to a cabled power source where it sits.
Build #74 is the update for Minecraft v1.5.1 and the latest IC² v1.115-lf beta. You'll need a forge 7.7.1 build; I suggest 651+.
I also uploaded the fission pad update for 1.4.7 (build #72), for those people who haven't updated to 1.5.1, yet. There won't be any further releases or fixes for 1.4.7.
These latest builds have a new fission based charge pad that is more powerful than the Lapotronic, still classes as tier 3 but can be charged by placing uranium cells directly into the charging slot (since it's based around an IC2 nuclear reactor). There is no way to boost the speed of uranium energy production (if you want that, build a proper reactor!) but you'll never have to worry about overheating. The cells are depleted at the same rate as you'd expect from a reactor, so it's slow but constant, as opposed to an energy crystal which will discharge significantly quicker. You can also end up with depleted uranium cells when they're used up.
Additionally, the pads now support "sided" inventory management, so you can insert and remove whatever is in the charging slot (ie, batteries, crystals or uranium cells) automating things with appropriately advanced machines (e.g. factorization routers?).
Be warned, though: "abusing" a fission pad while it's processing uranium will be as explosive as you'd expect a nuclear reactor to be.
Fix-wise: efficiency upgrades now use the correct battery items and overclockers now boost rates properly (at peak, they bring a pad to just shy of the next level of pad)
Texture pack-wise: I provided a config file to the Soartex Unstitcher guys for ChargePads, so that should make unstitching for 1.5.1 significantly easier. 
Enjoy!
That's a crazy idea... and I like it. O_o Not sure I like the pad on top of the chest but that's just aesthetics... I'll think about it and see what I can come up with.
The shift to 1.5 is going to have to be dealt with first, since I'm shifting to custom rendering and it's going to be complete arse. :\
I seem to be having a issue with BC pipes and your charge pads. I have a pipe running next to a charge pad and after a few items go into the pad I can't open anything like chests, doors, etc... here is a pic of my setup, I removed the problem pads
[[imgsnip]]
is it a BC or MC or Cp problem.
Never seen this problem, in testing, but pads aren't meant to be piped into, in pre-72 builds (72 isn't released, yet). That said, I can't see how the pads would cause this, as I don't do anything "weird" with the internal inventory, at all. 
I followed the OP recipe for an Efficiency Upgrade and just received an "Invalid Item" with id 20262:
[[snippity-snip]]
Version info: MC 1.4.7, Forge 6.6.2.534, IC2 1.115.207 & Charge Pads 2.4.1.66.
You have an item ID conflict with ThermalExpansion:
2013-03-24 12:43:47 [INFO] [STDOUT] CONFLICT @ 20006 item slot already occupied by myrathi.ic2.chargepads.r@396352e while adding thermalexpansion.core.item.ItemTE@7a7d60d8
2013-03-24 12:43:47 [INFO] [fml.ItemTracker] The mod ThermalExpansion is overwriting existing item at 20262 (myrathi.ic2.chargepads.r from ChargePads) with thermalexpansion.core.item.ItemTEQuote2013-03-24 12:44:07 [WARNING] [ChargePads] Invalid meta check: 3/inactive (ignoring)
...
This is debug stuff (in ChP) that's caused by NEI, I think. Dunno why it does what it's doing but it can be completely (and safely) ignored.
There is a simple fix, by adding an upgrade equal to overclock that is normally stackable.
Eh. I don't see why I should have to add an extra step (and item) just because Greg decides to screw things up. The stack-size fix is nothing more than a bit of maths; I just need to reflect his config setting.
Once I have my dev environment set up again, that is. 
New computer: shiny! Setting all my development stuff again: not so shiny! ;P
I'm using an MFSU charging pad and nothing is happening.
Then I daresay you're not using it correctly. Check the FAQ and/or watch one of the mod spotlights.
It would need as GT lowers stacksize to 4 by default nerfing ALL your pads, alot.
The GT "fix" will sort that issue and I need to deal with it, at some point, anyway. Meh.
Think this is a bug on your part? not sure. But I am unable to utilize Charge Pads to charge Modular Power Suits pieces.
I was told that it did work. Tier is extremely important, though. So, if a pad isn't charging a power suit piece, then it's too high a tier for that pad.
About new pads, how about adding a GregTech pad, only available when it is installed.
I'll consider it.
QuoteAccepts up to 8192 EU/p and is 4 times faster than EV charging pad.
If it were T5, that would be its spec, by default.
QuoteIt has 7 overclocker/efficiency slots and 2 field module slots.
It wouldn't have any more slots than the current pads... but wouldn't need them, either.
I do still need to have the mod check for GT and see if its OC nerf is enabled, though. As things currently stand, GT completely screws the balance of the mod because of the lowered UpgradeStacksize setting.
Thanks for the post, though.
Thanks. Obligatory "after IC2 has released their 1.5 IC2API and build for me to build it from."
Besides... I have a "final" 1.4.7 release, just as soon as I get my new computer set up for MC dev, again. Prepare for EV pads and rebalanced overclock rates.
Can you make it so we could just right click a upgrade kit on a already placed charge pad and it will upgrade were ever you placed it?
You already can: you just have to click it on the underside (since that's where the "access panel" is). It's in the FAQ and readme file.
If you want to make it clickable on any side, you simply have to tweak a config option (see the .cfg file).
Edit: Eh. I may add a message if the kit's clicked on the non-access side, though. Far too many people don't know you can do that because no-one ever reads FAQs or ReadMe's. 
nah, i just derped and accidentally steped on 2 pads; one with drain conversion & wide band booster and the other one with armor priority & FE. no wonder the armor would not drain. it's just a 5 seconds of error
Haha! 
(I'm mostly laughing because I've done similar and spent ages trawling through the code to find a bug that didn't actually exist. xD)
how about adding a new effect for it to make the particles from the pads looks more thick and concentrated so it can reach the internal storage? i guess paying additional EU/t in that upgrade makes it balance for what it does. i think.
I appreciate the effort but I'm not going to touch internal inventory.
Quote
and BTW, a pad with a drain conversion module & wide-band booster module doesnt seem to drain the armor's energy. is it a bug?<< nah ignore this
I'm guessing you had something still in your bar? The hot-bar is prioritised before any armour is affected, so it won't start on the armour until the hot-bar item is drained completely (or items, if using proximity/wide-band upgrades). This is inverted, if you use an armour priority upgrade: the armour has to be completely charged/depleted before the hot-bar is affected.
can you add a tier 2 "wide-band booster module" that can also charge stuffs in the inventory not just in the hotbar?
I'd considered it but decided against it, sorry.
I've always considered your hot-bar to be a kind of "item belt," so everything on it is external to your pack. Similarly, the armour you're wearing is also external.
Everything in your pack, however, is "internal," so the energised particles from the pad would waste their charge just getting to the items and have nothing left to charge with.
Build #66 is a minor update that should make people who use revision control for backups happier.
This build tweaks how ChargePads deals with its configuration files: it no longer force-saves the configuration if it doesn't have to write anything out (which it will never have to do unless you remove an entry from the file and it has to reset that entry to default).
Enjoy!
So, make pads have two projector upgrade slots, this way we can either choose have a huge field (two field expander) or a decent field with "force active" module.
That's exactly why they don't have two slots. I see the projector module as a single circuit (which is the circuit included in the recipe to make the pad), so altering it in two separate ways would overload it; there's only so much the circuitry of a pad can take (or should take), for balance reasons.
QuoteAlso, it could be a Field upgrade anyway, as it keeps the field on all the time.
Projector Modules affect "how" particles are projected from a pad, once activated; not "when." Do they split up? By how much? Are they spread over a larger area?
Field Modules affect the actual "particles" that are created by the physical projector. Making particles harmful (damage module), or inverting the particles so they negate existing power (drain module) or "delayed energizing" the particles so they don't "seek" electric items until they're a certain range from the pad (armour priority) are all field effects.
Physically activating a pad is caused by the pressure plate (in the recipe) which then allows power-flow to the projector. There is a valve effect which the field expansion modules "hold open," detecting constant flow with the detector cables in their recipes (which is why the pads shut off when everything that can be charged has been charged or people move beyond the range of the field).
As you can see: neither of the module slots are involved in the initial "activation" of the pad, itself, and it's not a functionality I want to add to them.
QuotePermanently active fields with either damage or drain field upgrades would be good as they can be used for traps (mob/player).
I don't disagree, at all... I just don't see a feasible way of implementing it via projector/field upgrade modules, as they simply don't fit the bill, and general upgrade slots (that alter the "effectiveness" of a pad) definitely don't, either.
That said, I've taken note of the feature request and will think on it... but no promises: if I can't think of a balanced way to implement it, I'm afraid it won't happen.
I see, but i still have to step on the chargepad to start charging.
Yep. Working as intended.
QuoteWith expansion module + permanently active field = charge while at workshop without the need of stepping on the pad once. Its EU/t cost to keep active is the price i would pay for that.
I can see your point... but a "force active" module would be a projector upgrade... so you wouldn't be able to have a field expander installed, either. Kinda makes it useless.
QuoteAlso, i've noticed chargepads doesnt take in consideration items "tier"
It definitely does. Static and Crystalizor pads won't charge quantum suits as they're too high a tier, for example.
Quoteas the nanosuit charges at the same speed as quantum suit, so the quantum suit takes 10 times longer to charge. [100 times longer for gravisuit].
Yep... because it charges based on value (the same as the storage blocks do), not percentage. Working as intended.
QuoteChargepads should charge ARMOR items based on percentage (3% every second or something like and increasing exponentially based on overclockers/efficiency).
That's seriously overpowered and not going to happen. Sorry.
Try the field expander modules, SpwnX. They stay active while you're within their expanded field area and continue charging items until they fill or you move out of the field.
Build #64 is the update for Minecraft v1.4.7 and IC² v1.115. You'll need forge 489+ but it'll work just fine with the latest forge (518 as of this post).
This build fixes the IC² tick crash on startup with 1.115 (only seen when upgrades were installed in pads on startup) and adds half a dozen new emitter upgrades for you all to play with (you can thank DireWolf20 for the field expander! ;D)
Thanks to HanFox for pointing out Sphax issues, ahead of time, and to BlackNocturne and ShamblerDK for prompt help in testing the tick fixes in SMP.
Enjoy!
We're getting serious errors with ChargePads with the new IC2 dev build as well. Whenever we restart the server, all upgrades in our ChargePads disappear. We'll sit tight for an update
Thanks for the confirmation.
I've already been able to reproduce the issue locally and have fixed it (in SSP) for the next build. It still needs tested in SMP, though, and I won't release until I'm sure.
Also, if y'all are lucky, there'll be some new features, too... we shall see how long it takes for SMP to be tested.
In other words: Soon™! ;]
Hmm, unfortunately that didn't work. Still get the exception on startup.
Ugh! It looks like it is a bug (just reproduced it on my end), though I dare say it's not my fault. The tile entity trying to push a field update to the IC2 core on world load (funny, that ;)) and IC2 isn't testing to ensure 'world' is non-null (unlike before, I guess). I haven't changed this code in several releases, so it's definitely something in IC2 core (maybe a result of the switch to un/load events).
QuoteAt this point I'm tempted to just roll back IC2 and hope for the best (considering the warning spam for for unloaded machines that are attempting to draw power still fills my log files in this latest version)
Definitely a valid short-term solution, yeah. 
QuoteAny other thoughts on your end?
And thanks for not just writing this off as "couldn't reproduce"
I need to find a work-around. And no worries: you took the time to both 'spoiler' the report (as requested in the OP) and gave me the entire thing - as opposed to an out-of-context, useless snippet.
QuoteAESU - Adjustable Energy Storage Unit. Think of it as an upgrade to the MFSU. Holds 100,000,000 (million) EU and discharges at a configurable EU/t. From 0 - 2048. Quite handy, albeit very expensive to build (something like a stack of diamonds worth of lapotron crystals....) Also accepts EV for input, which is nice.
Ahh... I've heard people discussing that. Should go well with the EV pad.
