[color=#000000]java.lang.NullPointerException[/color]
at drzhark.mocreatures.entity.MoCEntityTameable.func_70014_b(MoCEntityTameable.java:225)
at net.minecraft.entity.Entity.func_70109_d(Entity.java:1588)
at drzhark.mocreatures.MoCTools.isTamed(MoCTools.java:1714)
at drzhark.mocreatures.entity.passive.MoCEntityEnt.attackCritter(MoCEntityEnt.java:160)
at drzhark.mocreatures.entity.passive.MoCEntityEnt.func_70636_d(MoCEntityEnt.java:145)
at net.minecraft.entity.EntityLivingBase.func_70071_h_(EntityLivingBase.java:1826)
at net.minecraft.entity.EntityLiving.func_70071_h_(EntityLiving.java:257)
at net.minecraft.world.World.func_72866_a(World.java:2350)
at net.minecraft.world.World.func_72870_g(World.java:2311)
at net.minecraft.world.World.func_72939_s(World.java:2157)
at net.minecraft.client.Minecraft.func_71407_l(Minecraft.java:1921)
at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:910)
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:838)
at net.minecraft.client.main.Main.main(SourceFile:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:131)
at net.minecraft.launchwrapper.Launch.main(Launch.java:27)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:214)
at org.multimc.EntryPoint.listen(EntryPoint.java:139)
at org.multimc.EntryPoint.main(EntryPoint.java:53)
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- Head --
Stacktrace:
at drzhark.mocreatures.entity.MoCEntityTameable.func_70014_b(MoCEntityTameable.java:225)
-- Entity being saved --
Details:
Entity Type: MoCreatures.Bunny (drzhark.mocreatures.entity.passive.MoCEntityBunny)
Entity ID: 3665
Entity Name: Bunny
Entity's Exact location: 77.13, 71.00, 275.50
Entity's Block location: World: (77,71,275), Chunk: (at 13,4,3 in 4,17; contains blocks 64,0,272 to 79,255,287), Region: (0,0; contains chunks 0,0 to 31,31, blocks 0,0,0 to 511,255,511)
Entity's Momentum: 0.00, -0.08, 0.00
Stacktrace:
at net.minecraft.entity.Entity.func_70109_d(Entity.java:1588)
at drzhark.mocreatures.MoCTools.isTamed(MoCTools.java:1714)
at drzhark.mocreatures.entity.passive.MoCEntityEnt.attackCritter(MoCEntityEnt.java:160)
at drzhark.mocreatures.entity.passive.MoCEntityEnt.func_70636_d(MoCEntityEnt.java:145)
at net.minecraft.entity.EntityLivingBase.func_70071_h_(EntityLivingBase.java:1826)
at net.minecraft.entity.EntityLiving.func_70071_h_(EntityLiving.java:257)
at net.minecraft.world.World.func_72866_a(World.java:2350)
at net.minecraft.world.World.func_72870_g(World.java:2311)
-- Entity being ticked --
Details:
Entity Type: MoCreatures.Ent (drzhark.mocreatures.entity.passive.MoCEntityEnt)
Entity ID: 3711
Entity Name: Ent
Entity's Exact location: 78.00, 71.00, 279.47
Entity's Block location: World: (78,71,279), Chunk: (at 14,4,7 in 4,17; contains blocks 64,0,272 to 79,255,287), Region: (0,0; contains chunks 0,0 to 31,31, blocks 0,0,0 to 511,255,511)
Entity's Momentum: 0.00, -0.08, 0.00
Stacktrace:
at net.minecraft.world.World.func_72939_s(World.java:2157)
makin some progress with the forgemultipart compatibility. and i was right; multipart's torches are hard coded into the mod. i can probably override them, but it'd be waaaay too much work. one work around would be to do the unique torch of my own thing so i guess i'll do that instead.
Actually you should not need to touch Scala or anything of the sort. If you just implement the multipart api for the torch so it is a proper multipart block then I would think that it would likely work fine unless it does some odd hardcoded tests that it really should not be doing.
This something I broke recently? I should probably stop messing with core code.
Unsure, I just found out about this fascinating mod. However my server runs in adventure mode so people require the right tools for everything (with a mod that fixes the vanilla things that did not have assigned tools). And found out the chisel/hammer left-click do nothing when it looks like they should remove the coverings and so forth, so we have to break the block instead, which is not hard, but not being able to go backwards in the designs is a little time consuming.
The Pams mod integration is testing the wrong class, MFR is testing for "mods.Pam*" instead of for "assets.pam*" for example, thus the integration is failing.
Gotta love a bug report that not only tells you what's causing it, but also tells you how to fix it, thanks. Anyway, I'm away from my computer and dev environment for a few days, but I think I can still merge a PR if you feel like/have the time to patch it.
PR sent. Untested, but should work, simple enough change.
---- Minecraft Crash Report ----
// Who set us up the TNT?
Time: 10/26/12 10:34 PM
Description: Unexpected error
java.lang.NoSuchMethodError: xp.onGUICreateWorldPress()V
at aru.a(GuiCreateWorld.java:208)
at asw.a(SourceFile:64)
at aru.a(GuiCreateWorld.java:373)
at asw.d(SourceFile:112)
at asw.m(SourceFile:100)
at net.minecraft.client.Minecraft.l(Minecraft.java:1344)
at net.minecraft.client.Minecraft.J(Minecraft.java:730)
at net.minecraft.client.Minecraft.run(Minecraft.java:658)
at java.lang.Thread.run(Unknown Source)
Relevant Details:
- Minecraft Version: 1.4.2
- Operating System: Windows 7 (amd64) version 6.1
- Java Version: 1.7.0_04, Oracle Corporation
- Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
- Memory: 3384793912 bytes (3227 MB) / 4116054016 bytes (3925 MB) up to 4116054016 bytes (3925 MB)
- JVM Flags: 2 total; -Xms4096m -Xmx4096m
- AABB Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used
- FML: MCP v7.19 FML v4.2.6.422 Optifine OptiFine_1.4.2_HD_U_A6 3 mods loaded, 3 mods active
mcp [Minecraft Coder Pack] (minecraft.jar) Unloaded->Constructed->Pre-initialized->Initialized->Post-initialized->Available
FML [Forge Mod Loader] (coremods) Unloaded->Constructed->Pre-initialized->Initialized->Post-initialized->Available
mod_ReiMinimap [mod_ReiMinimap] ([1.4.2]ReiMinimap_v3.2_05.zip) Unloaded->Constructed->Pre-initialized->Initialized->Post-initialized->Available
- LWJGL: 2.4.2
- OpenGL: GeForce GTX 580/PCIe/SSE2 GL version 4.2.0, NVIDIA Corporation
- Is Modded: Definitely; 'fml'
- Type: Client
- Texture Pack: faithful32pack.zip
- Profiler Position: N/A (disabled)
- Vec3 Pool Size: ~ERROR~ NullPointerException: null
There's your FML.
Indeed, as you have found out it does not work for people that do not know how to read. FML can do what *ModLoader* does. However you installed something that is a jarmod, no pure modloader functionality, hence it does not use FML in full either, meaning you have a corrupt world class. Try to actually read next time and install mods that are ModLoader loading type, not jarmods, and perhaps you will not look like someone who is inept.
Have the latest tubestuff installed and notice that the buffer has no recipe, not in NEI nor when I tried them explicitely. The ACT2 also has no recipe in NEI but its non-bc non-rp recipe worked, which is odd because I have both installed (although I would not expect the RP2 recipe to work since RP2 had changes in 1.3 that are unseen yet, but the BC one should work yes?).
The server never crashes, only clients that connect to the server, seems to happen only while breaking a block, and seems random within that constraint.
In summation, the stacktrace is:
2012-10-02 21:05:52 [INFO] [STDERR] java.lang.NullPointerException
2012-10-02 21:05:52 [INFO] [STDERR] at qt.a(ItemTool.java:65)
2012-10-02 21:05:52 [INFO] [STDERR] at rj.a(SourceFile:196)
2012-10-02 21:05:52 [INFO] [STDERR] at atomicstryker.multimine.client.MultiMineClient.onBlockMineFinishedDamagePlayerItem(MultiMineClient.java:201)
2012-10-02 21:05:52 [INFO] [STDERR] at atomicstryker.multimine.client.MultiMineClient.onServerSentPartialBlockData(MultiMineClient.java:165)
2012-10-02 21:05:52 [INFO] [STDERR] at atomicstryker.multimine.client.ClientPacketHandler.onPacketData(ClientPacketHandler.java:28)
2012-10-02 21:05:52 [INFO] [STDERR] at cpw.mods.fml.common.network.NetworkRegistry.handlePacket(NetworkRegistry.java:249)
2012-10-02 21:05:52 [INFO] [STDERR] at cpw.mods.fml.common.network.NetworkRegistry.handleCustomPacket(NetworkRegistry.java:239)
2012-10-02 21:05:52 [INFO] [STDERR] at cpw.mods.fml.common.network.FMLNetworkHandler.handlePacket250Packet(FMLNetworkHandler.java:78)
2012-10-02 21:05:52 [INFO] [STDERR] at asv.a(NetClientHandler.java:1303)
2012-10-02 21:05:52 [INFO] [STDERR] at ce.a(SourceFile:56)
2012-10-02 21:05:52 [INFO] [STDERR] at bb.b(TcpConnection.java:441)
2012-10-02 21:05:52 [INFO] [STDERR] at asv.d(NetClientHandler.java:104)
2012-10-02 21:05:52 [INFO] [STDERR] at atd.b(WorldClient.java:69)
2012-10-02 21:05:52 [INFO] [STDERR] at net.minecraft.client.Minecraft.l(Minecraft.java:1790)
2012-10-02 21:05:52 [INFO] [STDERR] at net.minecraft.client.Minecraft.J(Minecraft.java:845)
2012-10-02 21:05:52 [INFO] [STDERR] at net.minecraft.client.Minecraft.run(Minecraft.java:775)
2012-10-02 21:05:52 [INFO] [STDERR] at java.lang.Thread.run(Unknown Source)
@Exanadu, all of this ores are currently working without any problem (IC2 copper and tin, Forestry copper and tin, RP2 silver in 1.2.5). Even this mod silver works with IC2 glass fiber cable recipe (magic of forge ore dictionary ).
Another small bug, that I would like to report, is that when moving upgraded barrel using Portal Gun from mod with the same name, storage upgrade is duplicated (it is dropped while moving, but after placing barrel block it is still upgraded). It is not a big deal, because Portal Gun is so OP, that small duplication isn't a problem. It would be nice if mixer would accept BC liquid, using it with RP would be trivial, but neither BC, nor Forestry provide a way to automatically fill buckets, in 1.3.2 only Railcraft water/iron tanks can do it. Barrels would be more compact in sorting systems, if they could be fed from sides and not only from the top.
As there is a rather large amount of misinformation and name calling around, and in an attempt to actually be logical amongst this group, here are some basic descriptions and information.
Jarmods - This is a class of mod that edits base files, whether they use an API like ModLoader or Forge or SomethingMythical, if they make base edits, they are a jarmod. Since a jarmod edits base files it will inherently be incompatible with other jarmods that make edits to the same base files, even if those edits are for a different purpose. In essence, any mod that makes base edits is actively not caring about compatibility as the very act of making base edits means that the mod *will* be incompatible at some point.
ModLoader - Is a jarmod that acts as a very thin API making a small amount of base edits to allow mods to achieve adding in basic classes such as new blocks or items and so forth. Its API does not allow for a good deal of functionality, hence why many ModLoader mods end up turning in to jarmods, and by doing so they instantly lose a great deal of compatibility. This is not an open-source mod and has no license that allows distribution, thus you require authorization directly from the author to redstribute. In essence, a mod can make calls 'to' modloader to do something in the base classes instead of needing to make those changes itself. Without modloader you could only, for example, have one mod that adds new blocks since they would conflict otherwise (it is more complicated than this, but this is the gist of why it exists).
'Clean Mod' - is a set of classes that are loaded by some form of mod loader, that then make callbacks to a mod loader to perform functionality within the Minecraft system, such as registering a new block type. If a mod starts to make edits to base files due to the limitation of the mod loader it is using, it then is no longer a clean mod and becomes a jarmod, thus losing potential compatibility with anything that edits the same base classes.
ForgeModLoader - Is a jarmod that performs similar, but different functionality to ModLoader. It does do everything ModLoader does, but it is a clean room implementation (meaning it was made only be seeing how mods 'use' modloader, but without looking at modloader itself) of modloader, however it also adds in higher functionality. One of its defining characteristics other than adding a few new hooks above beyond ModLoader is the concept of a 'coremod'.
FML CoreMod - Is a type of mod that can be loaded like a normal mod, however it makes minor edits due the java class bytecode for only what it needs. Basically this allows a mod to make a base edit, without actually editing the base class files. Since coremods are to add their own custom hooks it should always remain compatible with any other coremods. Jarmods, since they edit base files themselves, are still wholly incompatible due to the poor design of such a mod.
Given these definitions, it should be obvious why any mod that is a jarmod is inherently of poor design since it would not remain compatible with anything else that edits similar base classes. Thus it makes sense to create a set of hooks to let multiple mods interact with similar functionality to the base system, and since you need a hook to begin these classes to load you would then create a loader as well, hence a Mod Loader is born. The single-authors Mod Loader's capabilities are highly limited since it cannot possible fulfill the desire of every single base edit of every single mod out, thus a group of mod authors come together and combine what is needed to make an expanded set of hooks, hence Forge was born. Forge allowed any modder to submit new hooks, and after cleaning them up and making them properly generic for maximal usage the new hook is then added to the ecosystem for use by any and all other mod authors. The other mod authors, by seeing what hooks are available, get new ideas for new gameplay mechanics and it drives creativity even higher. However these hooks, although useful in preventing base edits and encouraging compatibility, still do not let the mods properly work together as there are a multitude of ways to access inventories, a multitude of identical blocks such as new ores amongst the mods. You then start creating compatibility layers on top of the hooks to allow for identical things in different mods to be treated as one, such as the Forge Ore Dictionary, which allows for any block or item to be registered by a unique name such as 'ore.copper' and any other mod that has a copper block can use yours and vice versa with no extra work required, thus increasing compatibility even further. These layers help reduce a massive amount of programming that would otherwise be needed by the modders by consolidating it in to a single, useful location, thus saving time. More ideas such as this are thought of and included and it spurs creativity even further.
Now, say there is a mod that edits a base class that forge also uses, by this mod being so poorly made so as to use a base edit that suddenly prevents an entire eco-system of mod authors that work well together from running with this mod, all because this one mod was not made well enough. Not that it is a big thing in any case, there are many mod ideas, and many programmers, and new ones coming all the time, and with the information available it is quite obvious that proper programming methods help let everything work together. In essence, just staying away from becoming a jarmod means that you should remain fully compatible with all non-jarmods, which is good, since jarmods themselves are not compatible with other jarmods either.
The question of bloat is also an odd one. The API's exposed do not cost anything if not used, and the designs presented can even make the game run faster. So the question is actually 'why not'? Only thing it could possibly break is a jarmod, of which is already designed to be incompatible anyway.
So why would anyone be 'for' jarmods when by their very design they try to break compatibility? When using a proper API can reduce the work that the modder does, and helps them at many turns? That is no doubt a question of intellect. A little research can go a very long way.
I do have to say that I am loving this mod. It will work very well with RailCraft and RedPower2 worlds when RP2 updates. I look forward to your updates!
0
Here is the relevant part:
0
Actually you should not need to touch Scala or anything of the sort. If you just implement the multipart api for the torch so it is a proper multipart block then I would think that it would likely work fine unless it does some odd hardcoded tests that it really should not be doing.
0
You should be able to by overriding the normal handling method on the tool itself I would think, though I have not tried myself.
0
Unsure, I just found out about this fascinating mod. However my server runs in adventure mode so people require the right tools for everything (with a mod that fixes the vanilla things that did not have assigned tools). And found out the chisel/hammer left-click do nothing when it looks like they should remove the coverings and so forth, so we have to break the block instead, which is not hard, but not being able to go backwards in the designs is a little time consuming.
0
0
EDIT: Railcraft compat is also failing to load.
0
0
PR sent. Untested, but should work, simple enough change.
Also, love Limbo, terrifying.
0
It appears to be caused by this line of code:
at https://github.com/StevenRS11/DimDoors/blob/master/StevenDimDoors/mod_pocketDim/dimHelper.java#L1050 and it is because getWorld(0) returns null once the overworld has been purged from memory, however it seems this function gets called one more time after that happens. Need to check if !=null before you try accessing the world.
0
Indeed, as you have found out it does not work for people that do not know how to read. FML can do what *ModLoader* does. However you installed something that is a jarmod, no pure modloader functionality, hence it does not use FML in full either, meaning you have a corrupt world class. Try to actually read next time and install mods that are ModLoader loading type, not jarmods, and perhaps you will not look like someone who is inept.
0
0
The server never crashes, only clients that connect to the server, seems to happen only while breaking a block, and seems random within that constraint.
In summation, the stacktrace is:
0
Vanilla dispenser can fill buckets as of 1.3.
9
Jarmods - This is a class of mod that edits base files, whether they use an API like ModLoader or Forge or SomethingMythical, if they make base edits, they are a jarmod. Since a jarmod edits base files it will inherently be incompatible with other jarmods that make edits to the same base files, even if those edits are for a different purpose. In essence, any mod that makes base edits is actively not caring about compatibility as the very act of making base edits means that the mod *will* be incompatible at some point.
ModLoader - Is a jarmod that acts as a very thin API making a small amount of base edits to allow mods to achieve adding in basic classes such as new blocks or items and so forth. Its API does not allow for a good deal of functionality, hence why many ModLoader mods end up turning in to jarmods, and by doing so they instantly lose a great deal of compatibility. This is not an open-source mod and has no license that allows distribution, thus you require authorization directly from the author to redstribute. In essence, a mod can make calls 'to' modloader to do something in the base classes instead of needing to make those changes itself. Without modloader you could only, for example, have one mod that adds new blocks since they would conflict otherwise (it is more complicated than this, but this is the gist of why it exists).
'Clean Mod' - is a set of classes that are loaded by some form of mod loader, that then make callbacks to a mod loader to perform functionality within the Minecraft system, such as registering a new block type. If a mod starts to make edits to base files due to the limitation of the mod loader it is using, it then is no longer a clean mod and becomes a jarmod, thus losing potential compatibility with anything that edits the same base classes.
ForgeModLoader - Is a jarmod that performs similar, but different functionality to ModLoader. It does do everything ModLoader does, but it is a clean room implementation (meaning it was made only be seeing how mods 'use' modloader, but without looking at modloader itself) of modloader, however it also adds in higher functionality. One of its defining characteristics other than adding a few new hooks above beyond ModLoader is the concept of a 'coremod'.
FML CoreMod - Is a type of mod that can be loaded like a normal mod, however it makes minor edits due the java class bytecode for only what it needs. Basically this allows a mod to make a base edit, without actually editing the base class files. Since coremods are to add their own custom hooks it should always remain compatible with any other coremods. Jarmods, since they edit base files themselves, are still wholly incompatible due to the poor design of such a mod.
Given these definitions, it should be obvious why any mod that is a jarmod is inherently of poor design since it would not remain compatible with anything else that edits similar base classes. Thus it makes sense to create a set of hooks to let multiple mods interact with similar functionality to the base system, and since you need a hook to begin these classes to load you would then create a loader as well, hence a Mod Loader is born. The single-authors Mod Loader's capabilities are highly limited since it cannot possible fulfill the desire of every single base edit of every single mod out, thus a group of mod authors come together and combine what is needed to make an expanded set of hooks, hence Forge was born. Forge allowed any modder to submit new hooks, and after cleaning them up and making them properly generic for maximal usage the new hook is then added to the ecosystem for use by any and all other mod authors. The other mod authors, by seeing what hooks are available, get new ideas for new gameplay mechanics and it drives creativity even higher. However these hooks, although useful in preventing base edits and encouraging compatibility, still do not let the mods properly work together as there are a multitude of ways to access inventories, a multitude of identical blocks such as new ores amongst the mods. You then start creating compatibility layers on top of the hooks to allow for identical things in different mods to be treated as one, such as the Forge Ore Dictionary, which allows for any block or item to be registered by a unique name such as 'ore.copper' and any other mod that has a copper block can use yours and vice versa with no extra work required, thus increasing compatibility even further. These layers help reduce a massive amount of programming that would otherwise be needed by the modders by consolidating it in to a single, useful location, thus saving time. More ideas such as this are thought of and included and it spurs creativity even further.
Now, say there is a mod that edits a base class that forge also uses, by this mod being so poorly made so as to use a base edit that suddenly prevents an entire eco-system of mod authors that work well together from running with this mod, all because this one mod was not made well enough. Not that it is a big thing in any case, there are many mod ideas, and many programmers, and new ones coming all the time, and with the information available it is quite obvious that proper programming methods help let everything work together. In essence, just staying away from becoming a jarmod means that you should remain fully compatible with all non-jarmods, which is good, since jarmods themselves are not compatible with other jarmods either.
The question of bloat is also an odd one. The API's exposed do not cost anything if not used, and the designs presented can even make the game run faster. So the question is actually 'why not'? Only thing it could possibly break is a jarmod, of which is already designed to be incompatible anyway.
So why would anyone be 'for' jarmods when by their very design they try to break compatibility? When using a proper API can reduce the work that the modder does, and helps them at many turns? That is no doubt a question of intellect. A little research can go a very long way.
0