Does this work with 1.5.2? Or perhaps more specifically with what builds (and API changes?) of IC2?
Tentative answer: Yes (industrialcraft-2_1.115.308-lf).
Does this work with 1.5.2? Or perhaps more specifically with what builds (and API changes?) of IC2?
Tentative answer: Yes (industrialcraft-2_1.115.308-lf).
Bumpity bump bump for 1.5.1 + release..
Does this work with 1.5.2? Or perhaps more specifically with what builds (and API changes?) of IC2?
Thanks for the quick response, I'll give that build a try tomorrow.
Avoided issue tracker pending confirmation that it wasn't really a Charge Pad issue :-).
Richard
Now installed and working.
Thanks.
Thanks for decent logs - though this should've really gone to the issue tracker listed in the OP.
As it stands, this is indeed an API issue as 304-lf changed significantly. There's currently a new build in testing and, if you wish to try it, you can grab it from here. Note that this IS a test build! Backup your world first! -- If you have any issues with it, please refer to the github issue tracker listed in the first post.
Thanks for the quick response, I'll give that build a try tomorrow.
Avoided issue tracker pending confirmation that it wasn't really a Charge Pad issue :-).
Richard
I'm building out my 1.5.1 mod set up. On adding Charge Pads 2.6.0.74 MC crashes on startup (before reaching single/server/... menu page).
Forge Log: http://pastebin.com/QyaaRHDL
This is repeatable: removing Charge Pads: no crash, add charge pads: crash:
2013-04-28 18:40:58 [SEVERE] [ForgeModLoader] Caught exception from ChargePads
java.lang.NoClassDefFoundError: myrathi/ic2/chargepads/x
at myrathi.ic2.chargepads.d.a(SourceFile:149)
at myrathi.ic2.chargepads.d.preInit(SourceFile:87)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:494)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:74)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:314)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:296)
at com.google.common.eventbus.EventBus.post(EventBus.java:267)
…
Display More
Could this be an IC2 API compatibility issue? (IC2 2_1.115.304-lf is in, but also GraviSuite 1.9.1 is in and OK.)
The actual ID's are the config'd ID's plus 256. That's just the way IC2 works and it's kinda weird.
Thanks.
I agree weird seems to fit.
You have an item ID conflict with ThermalExpansion:
Code2013-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.ItemTE
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.
Thanks.
Changing the CP config from item ids 20006–20008 to 21006–21008 seems to have fixed it (when time later I'll try making some modules, but at least NEI is showing far more CP items in game now).
However, in NEI's id dump and the tooltips in the game the ids showing are 21262–21264 rather than the numbers given in the CP config… in other cases of id conflicts the config file and in game ids have matched (and mismatches were therefore easier to spot and fix). Any idea what the relationship between the configured and in game numbers are?
I followed the OP recipe for an Efficiency Upgrade and just received an "Invalid Item" with id 20262:
According to NEI's id dump:
Item. Unused ID: 20260
Item. Name: item.liquid. ID: 20261
Item. Name: item.component. ID: 20262
Item. Name: item.tool. ID: 20263
Item. Name: item.upgradeKit. ID: 20264
Item. Unused ID: 20265
But ChargePads.cfg has:
item {
# Upgrades: Basic Modules ItemID
I:upgradeBasicModules=20006
# Upgrades: Emitter Conversion Modules ItemID
I:upgradeEmitterModules=20007
# Upgrade Kit ItemID
I:upgradeKits=20008
}
Display More
(20006, 20007 & 20008 are unassigned according to NEI.)
Switching to creative mode (and via NEI), the only charge pad items are the three charge pads and three upgrade kits. No sign of anything else.
What's going on?
Version info: MC 1.4.7, Forge 6.6.2.534, IC2 1.115.207 & Charge Pads 2.4.1.66.
Just added CP this morning without any other sign of problems (including a working Laptronic Charge Pad).
EDIT
Just been through the Forge log from that session. The only thing that looks of interest is this:
2013-03-24 12:44:07 [WARNING] [ChargePads] Invalid meta check: 3/inactive (ignoring)
2013-03-24 12:44:07 [WARNING] [ChargePads] Invalid meta check: 4/inactive (ignoring)
2013-03-24 12:44:07 [WARNING] [ChargePads] Invalid meta check: 5/inactive (ignoring)
2013-03-24 12:44:07 [WARNING] [ChargePads] Invalid meta check: 6/inactive (ignoring)
2013-03-24 12:44:07 [WARNING] [ChargePads] Invalid meta check: 7/inactive (ignoring)
2013-03-24 12:44:07 [WARNING] [ChargePads] Invalid meta check: 11/inactive (ignoring)
2013-03-24 12:44:07 [WARNING] [ChargePads] Invalid meta check: 12/inactive (ignoring)
2013-03-24 12:44:07 [WARNING] [ChargePads] Invalid meta check: 13/inactive (ignoring)
2013-03-24 12:44:07 [WARNING] [ChargePads] Invalid meta check: 14/inactive (ignoring)
2013-03-24 12:44:07 [WARNING] [ChargePads] Invalid meta check: 15/inactive (ignoring)
Full log: http://pastebin.com/pRdzHsxM