jeffryfisher

Is it absolutely necessary to change something already in the game? Can you get most of what you want by adding something new instead? What is your goal anyway?

Modding in Minecraft presents some special challenges. For one thing, the vanilla code has been scrubbed of all of its authors' naming and internal comments that would tell us what's what (it's my understanding that all class and method names we see are "deobfuscation" provided by Forge, and all comments are by Forge). Whatever the process, we're left with a relatively low-information code base to work with (as compared to what one would see if hired to work from inside Mojang). One needs an above average IQ to decode method arguments like p_12345_5, but I find that solving those problems is a bunch of fun puzzles. It's like doing Sudoku. Then, as you say, we're not allowed to change the vanilla code base. This shortcoming is partially offset by adopting a modder's hacking style. We're not writing professional code, so we're not bound by anybody's standards and practices for producing an easily maintainable etc program. What that means to me is that I can take the gloves off and abuse Java's reflection in totally unprofessional (and sometimes inefficient) ways. If I were coding professionally, I'd improve the vanilla code rather than hacking around it. Finally, there's Forge itself. I am impressed by how well it is structured/organized, but it's still a lot to take in. Its reflection is not the easiest code to follow, especially because eclipse can't follow class and method references that won't be known until runtime. Furthermore, if you can even find your way to the part of Forge that you need for what you want to do, the internal comments don't always connect all of the "how to use" dots. Even more confusing is the haystack of obsolete examples available online. Forge changes with Minecraft, so the proper way to use it in 2012 may be the wrong way in 2014 (Sadly, this is also true of some tutorials floating around the Internet). Having been Forge-modding Minecraft since mid-May, I now overcome obfuscation and the inflexible core myself. It's the mysteries of Forge practices and terminology that sometimes bring me here to search the support forum and sometimes ask a question (and if I get down to the horse-armor mod at the bottom of my to-do list before seeing new horse-armor hooks in Forge, then I'll be asking another one in a few weeks). Good luck!

Look into EntityHorse. It is already doing a base-color + markings combo like you are describing. Imitate and adapt.

Search the Block class for methods containing the word "drop". Choose one to override. If unsure, look at a vanilla example such as diamond ore, which drops diamonds rather than itself. See how it does it and then imitate.

I was wondering a similar question about NBT utility: why are saves and world-loads done with NBT tags while entirely separate packets are used to spawn entities during play? Why don't entities utilize the NBT read/write methods they already have to make their spawn packets? Then I saw how huge the NBT tags are. Apparently, the complete state of an existing entity is vastly more complex than the default initial state of a freshly spawning one. Using NBT tags to spawn new entities would be very wasteful. Still, I wonder if packets could have been implemented as an O-O method system in Entity and its subclasses. Extending packet data would be so simple then.

Although you don't have a server-only proxy, you still need to define the serverSide , so you give it the CommonProxy like so: @SidedProxy(clientSide = "com.czaarek99.FrameMod.ClientProxy", serverSide = "com.czaarek99.FrameMod.CommonProxy"); This way, the server runs just the common proxy, and the client can run both (because the clientProxy can both execute some statements of its own and call its parent's methods using "super"). The statements in the common proxy end up running on both the client and the server. That's why it's called a common proxy -- because its actions are common to both client and server. You probably shouldn't put any @EventHandler attributes inside your proxies. Instead, put those on the methods in your main class and have those methods call their proxy counterparts. Finally, your client proxy shouldn't be empty. Wasn't there something you wanted to do that could only run on the client side? Those statements (and the import statements to support them) belong in the client proxy and its methods.

Now hold on a second... Playing a custom sound is a display idiosyncracy, so that is something that you should be able to do client-only. As long as your client has the data, it should be able to decide what sound to play when (just like an X-Ray mod that shows to much). A custom sound issue is OT, so start a new thread if you want help with it (but work on it first). Good luck!

If you change the method name to "init" in the proxy class, then you would call proxy.init from within in your main's init method. If that's news to you, then you need to take a timeout to get a one-quarter "Intro to Programming" course at school (or at a local Jr college). It doesn't need to be Java, but it should be at least an object-oriented language like C++. Alternatively, you might ask a programmer friend to partner with you, at least to start. Such a friend could help you to separate the programming concepts from the Minecraft and Forge concepts (and overcome them). If you don't have some programming background on arrival here, then some folks might lose patience. As it says in the forum description, this is a Forge help forum, not a Java help forum. I'm not saying that to be snarky or mean but to give fair warning. Incidentally, like my signature says, I arrived in mid-May with over 25 years of professional programming experience in over a dozen languages (including several O-O, but not Java), but even I found parts of the learning curve to be somewhat steep (I am still struggling to wrap my head around Java's "Reflection" even though I have already used it successfully). A non-programmer coming into this is doomed. You have no basis by which to perceive which aspects of a tutorial are Java style and which are Forge necessity. Get your head above water: Learn the essentials of O-O programming.

Oooh, core-mod. Anything could be happening outside the rendering of your object and causing your symptoms. I can't help with that.

Enchantability is expected to be a fixed characteristic of an item class and its material. Are you sure that it needs to become a dynamic (changeable) property of each individual stack of an item? If you aren't planning very many distinct enchantability levels, then the painful work-around might be to create multiple instances of the item's class, one for each possible level. When an item stack's enchantability changes, it would be replaced by a stack of a different subclass of the item. The call to getEnchantability could then return a function of both material and the subclass's enchantability modifier. If you're doing something like having tools magically transmute material, then subclassing by material could change several properties based on the one parameter.

Other items and other slots shouldn't have any effect whatsoever, so there's something not right about the way your rendering code is preparing to draw. Some data from the previous draw (or the wrong object) is somehow getting into your part of the process, and that should never happen. I recommend walking through comparable vanilla code line-by-line with yours to see what your code is missing. If that doesn't turn up an obvious "oops!", then my next step would be to set a break point and run the debugger to step through your rendering while examining values being used. Don't be afraid of the debugger. It is there to extract information in cases like this. When you see some horribly wrong value in a variable, then you will know what direction to turn your investigation. There's also an outside chance that something you did isn't multithread-safe. I doubt that's the problem, but you can look for vulnerable code (Google the topic if you want to learn more). Does your renderer rely on any static/global GL objects?

You already have the code, but I'd suggest changing the name of your "ServerProxy" to "CommonProxy" , and rename your "registerRenderThings" to whatever event-handling method name calls it from your main mod class. Then if possible, have each override-method in ClientProxy call the same-named method in CommonProxy like this: @Override public class ClientProxy extends CommonProxy { public void init(FMLInitializationEvent e) { super.init (e); // Register client-specific stuff (e.g. renderer & packet-handler callback etc) } }

When you call registerModEntity, one of the parameters is updateFrequency, a number of ticks. Have you played with that yet?

Just to be clear, I am creating a client-side only mod for playing on a vanilla server. Does it still trigger? Oops, I doubt it. Client-only mods can process and reveal data from the server (hence the notorious "X-ray" mods), but they can't change the world. You might eventually program something client-side that will tell you that you earned an achievement, but your vanilla client won't fire via the usual vanilla client pathways (it's not receiving the server packets telling it to do so). If you walk through the vanilla code behind your stat call, you'll probably find one of those pesky "!isRemote()" tests barring the gate.

If anyone searching similar problems comes upon this thread and wonders what code solved mine, here it is. What I ended up doing was a bit more involved than the above suggestions, but that's because: a) I'm stubborn, and b) Modding is a Java learning exercise for me, and I need to learn reflection. Implementing the IEntityAdditionalSpawnData interface let me add to and read from the existing painting packet, but FML's EntitySpawnMessage doesn't call my read method until after constructing my entity with the simplest of all constructors. My parent class, EntityPainting, handled its packet by reading the data and then calling an elaborate constructor. If I waited until my read was called, then I would not be able to use the constructors I wanted (mine and parent and grandparent). That would create problems. Fortunately, I noticed another interesting action in EntitySpawnMessage: It could be told to call a "custom spawn method". This looked like what I wanted. I resolved to write my own entity spawn method that would read my extra data and then call the constructor I wanted. But there was a hitch: My extra data was locked away in the message's private datastream, and the message, not datastream, was what got passed into the custom spawn method. The data was close enough that I could taste it. Looking at the control flow, I could see that the datastream had already disgorged its other data and had no purpose except to be passed to me (into my read method a few lines further down). It was ready for me if I could just find a way to crack it. [Of course, if the coding of EntitySpawnMessage ever changes this, then my mod will blow sky high!] This is where I decided to study reflection, especially how to look into private fields I'm not supposed to read. An online Java tutorial showed me how to pick apart the message class, look at a field, change the reflected field's privacy setting, and then access my data via the reflected field (the compiler still protected against normal access). Finally, the message handling occurs only on the client side. That meant that I ran into some SideOnly issues that forced me to learn about proxies. I'm still sorting out the meaning of SideOnly, especially when applied to things other than whole classes, so don't trust my use of the attribute in the snips below. Putting these things together, here are the relevant code snippets... Set custom spawning: public class ClientProxy extends CommonProxy { @Override @SideOnly(Side.CLIENT) public void init(FMLInitializationEvent e) { // Register client-specific stuff (renderer & callback) super.init (e); ModContainer mc = Loader.instance ().getIndexedModList ().get (classAltPaintingsMod.MODID); EntityRegistration registration = EntityRegistry.instance ().lookupModSpawn (mc, 0); // my mod's only entity is #0 registration.setCustomSpawning (new classAltPaintingSpawnCallback (), false); } } The callback class that cracks datastream's privacy using reflection: @SideOnly(Side.CLIENT) public class classAltPaintingSpawnCallback implements Function<EntitySpawnMessage, Entity> { protected Field fieldStream; public classAltPaintingSpawnCallback() { // This will be constructed in the init phase System.out.println ("Constructing classAltPaintingSpawnCallback"); try { // Crack open the message and enable access to dataStream via Field variable (reflection) this.fieldStream = EntitySpawnMessage.class.getDeclaredField ("dataStream"); this.fieldStream.setAccessible (true); } catch (NoSuchFieldException e) { System.out.println ("ERROR: In classAltPaintingSpawnCallback constructor, " + e.getMessage ()); } } /** * Helper class with one function to parse message and call the correct entity constructor that returns an instance of my entity * class. Got all that? I wrote it, and it still makes my head hurt. * * Why does the message protocol delay reading my extra data until after entity construction? I may never know, but I do know that * it's there waiting for me, so I'm taking it by force. */ @Override public Entity apply(EntitySpawnMessage m) { WorldClient wc = FMLClientHandler.instance ().getWorldClient (); try { ByteBuf b = (ByteBuf) fieldStream.get (m); // Steal the dataStream from message m int x = b.readInt (); // world tile x (+ is East) int y = b.readInt (); // world tile y (+ is Up) int z = b.readInt (); // world tile z (+ is South) int SWNE = b.readByte (); // Compass dir 0-3 is S, W, N, E int lot = b.readByte (); // Texture number 0-15 taken from carpet color used to craft item String title = ByteBufUtils.readUTF8String (b); return new classAltPainting (wc, x, y, z, SWNE, lot, title); } catch (ReflectiveOperationException e) { System.out.println ("ERROR: In classAltPaintingSpawnCallback.apply(), " + e.getMessage ()); return null; } } } Amazingly, this now works in client-server multiplayer Minecraft Forge 1.7.10. All I need to do now is make 15 more texture files filled with 31 paintings each

Something else that's random is what type of block you're about to replace at a randomly chosen coordinate within a chunk. If your rarite ore is only allowed to replace a certain material (like rock), then it won't generate where it hits air or water or dirt etc. It could be really really rare if it were only allowed to replace iron ore (or even coal).

That's a very strange message to get from running a bat. Is it marked as an executable file? Is there another (hidden) file extension on it that is confusing Windoze? Did you change Windoze versions so that it no longer fits? I agree with the fresh installation. It has been about ten years since you could simply copy an installed application's file hierarchy and have even a prayer of things running correctly.

I just learned this proxy stuff last week, so I know just enough to be dangerous By custom, the parent proxy is called "CommonProxy". That's because there probably isn't anything that runs *only* on the server. Calling it CommonProxy will make it easier for the rest of us to read your code. When Forge loads your mod, it will instantiate your proxy variable for you, using reflection to employ the client-side or server-side class that you specified. With your client-side class overriding the parent CommonProxy methods, it will do all of the "dirty work", assuring that SideOnly classes are only touched in the client. If there's nothing bad happening in your parent's methods, then have your client methods call their supers. Since "proxy" means "stand-in for my main mod class", you'll gain clarity if you name your proxy's methods in accordance with the methods (PreLoad, Load, PostLoad) in FrameMod. Then each of those event handlers can simply call its corresponding proxy method. Note: In some cases (e.g. if you use reflection yourself), the mere presence of an unused import statement (of a client-only class) can blow up the server. I've seen a rule that client-only classes should only be imported into client proxies. However, runtime exception checker is usually more forgiving as long as you don't instantiate the client-only class or reflect the importing class at runtime on the server. Just know that you'd be playing with fire. PS: I had to do my event-listener bus-registrations in my PostInit, but I can't remember why. YMMV

Did you make sure that your call to setSize runs after the vanilla call to set size? IIRC, setSize has some side effects, so you might just want to override it anyway.

Success! Since classAltPaintingSpawnCallback is only needed for processing a message received on the client side, I made it @SideOnly. Then I moved all references to it into my client proxy. However, I'm still... disappointed at Java's error message. When it complained that a class wasn't found, it would have been nice to tell me *which* class wasn't found (and tell me that it was starting to analyze that callback class). I lost a lot of time because all it gave me was a line number in another class that had a "new classAltPaintingSpawnCallback()" expression, and classAltPaintingSpawnCallback happened to import one SideOnly class among a dozen imports. I won't be surprised to see more modders baffled by similar bugs.

Aha, very informative. Since my case involves reflection, I guess I have run into extreme bounds checking (i.e. parts of the class not used on the server are still being tested). I can already see an import that has a SideOnly attribute. That's probably the culprit. I'll see if I can recode my class without the offending import. Instead, I'll try to use a fully-qualified reference deeper in the class, surrounding it with isRemote. If that doesn't work, then I'll try to push the work into my proxy, with only the ClientProxy having the real reference to the client-only class. I'll post my solution when I find it.

You do not add a recipe. Instead, in each tool and armor class, override the method "getIsRepairable". If the 2nd stack is the input that should repair your object, then return true.

I need help before I pull out all of my hair... I have a mod that runs perfectly in Eclipse SP. However, when I build the mod and install it on my server, the server fails to start. I don't see "side only" anywhere, so I am flummoxed. I've broken apart the offending code as much as I can: System.out.println (MODID + " attempting to declare my callback handle."); classAltPaintingSpawnCallback cb; // Succeeds System.out.println (MODID + " attempting to construct my callback instance."); cb = new classAltPaintingSpawnCallback (); // Line 125 blows up The server crashes with NoClassDefFoundError on line 125. It doesn't even begin to run the CallBack's constructor. Here's the entire java file for the classAltPaintingSpawnCallback class: package jrfpaintings; import io.netty.buffer.ByteBuf; import java.lang.reflect.Field; import net.minecraft.client.multiplayer.WorldClient; import net.minecraft.entity.Entity; import com.google.common.base.Function; import cpw.mods.fml.client.FMLClientHandler; import cpw.mods.fml.common.network.ByteBufUtils; import cpw.mods.fml.common.network.internal.FMLMessage.EntitySpawnMessage; public class classAltPaintingSpawnCallback implements Function<EntitySpawnMessage, Entity> { protected Field fieldStream; public classAltPaintingSpawnCallback() { // This will be constructed in the init phase System.out.println ("Constructing classAltPaintingSpawnCallback"); try { // Crack open the message and enable access to dataStream via Field variable (reflection) this.fieldStream = EntitySpawnMessage.class.getDeclaredField ("dataStream"); this.fieldStream.setAccessible (true); } catch (NoSuchFieldException e) { System.out.println ("ERROR: In classAltPaintingSpawnCallback constructor, " + e.getMessage ()); } } /** * Helper class with one function to parse message and call the correct entity constructor that returns an instance of my entity * class. Got all that? I wrote it, and it still makes my head hurt. * * Why does the message protocol delay reading my extra data until after entity construction? I may never know, but I do know that * it's there waiting for me, so I'm taking it by force. */ @Override public Entity apply(EntitySpawnMessage m) { WorldClient wc = FMLClientHandler.instance ().getWorldClient (); try { ByteBuf b = (ByteBuf) fieldStream.get (m); // Steal the dataStream from message m int x = b.readInt (); // world tile x (+ is East) int y = b.readInt (); // world tile y (+ is Up) int z = b.readInt (); // world tile z (+ is South) int SWNE = b.readByte (); // Compass dir 0-3 is S, W, N, E int lot = b.readByte (); // Texture number 0-15 taken from carpet color used to craft item String title = ByteBufUtils.readUTF8String (b); return new classAltPainting (wc, x, y, z, SWNE, lot, title); } catch (ReflectiveOperationException e) { System.out.println ("ERROR: In classAltPaintingSpawnCallback.apply(), " + e.getMessage ()); return null; } } } It works flawlessly in Eclipse, but on the server it doesn't even emit the first println in the constructor. The error log: jrfpaintings attempting to construct my callback instance. Init jrfwalls [16:42:10] [server thread/ERROR] [FML]: Fatal errors were detected during the transition from INITIALIZATION to POSTINITIALIZATION. Loading cannot continue [16:42:10] [server thread/ERROR] [FML]: mcp{9.05} [Minecraft Coder Pack] (minecraft.jar) Unloaded->Constructed->Pre-initialized->Initialized FML{7.10.18.1180} [Forge Mod Loader] (forge-1.7.10-10.13.0.1180-universal.jar) Unloaded->Constructed->Pre-initialized->Initialized Forge{10.13.0.1180} [Minecraft Forge] (forge-1.7.10-10.13.0.1180-universal.jar) Unloaded->Constructed->Pre-initialized->Initialized jrfmoonsensor{v1.7.2-0.01.04 Beta} [uncle Jeff's Moon Sensor] (jrfmoonsensor-1.7.2-00.01.04.jar) Unloaded->Constructed->Pre-initialized->Initialized jrfnethergem{v0.01.04 Beta} [uncle Jeff's Nethergem Mod] (jrfnethergem-1.7.10-00.01.05.jar) Unloaded->Constructed->Pre-initialized->Initialized jrfpaintings{v1.7.10-0.00.01 Alpha} [uncle Jeff's Paintings Mod] (jrfpaintings-1.7.10-00.00.01.jar) Unloaded->Constructed->Pre-initialized->Errored jrfwalls{v1.7.2-0.01.04 Beta} [uncle Jeff's Walls Mod] (jrfwalls-1.7.2-00.01.04.jar) Unloaded->Constructed->Pre-initialized->Initialized [16:42:10] [server thread/ERROR] [FML]: The following problems were captured during this phase [16:42:10] [server thread/ERROR] [FML]: Caught exception from jrfpaintings java.lang.NoClassDefFoundError: java/lang/ReflectiveOperationException at jrfpaintings.classAltPaintingsMod.init(classAltPaintingsMod.java:125) ~[classAltPaintingsMod.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.6.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.6.0_45] at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:513) ~[FMLModContainer.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.6.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.6.0_45] at com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.SynchronizedEventSubscriber.handleEvent(SynchronizedEventSubscriber.java:47) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:304) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.post(EventBus.java:275) ~[minecraft_server.1.7.10.jar:?] at cpw.mods.fml.common.LoadController.sendEventToModContainer(LoadController.java:208) ~[LoadController.class:?] at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:187) ~[LoadController.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.6.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.6.0_45] at com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.SynchronizedEventSubscriber.handleEvent(SynchronizedEventSubscriber.java:47) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:304) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.post(EventBus.java:275) ~[minecraft_server.1.7.10.jar:?] at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:118) [LoadController.class:?] at cpw.mods.fml.common.Loader.initializeMods(Loader.java:691) [Loader.class:?] at cpw.mods.fml.server.FMLServerHandler.finishServerLoading(FMLServerHandler.java:97) [FMLServerHandler.class:?] at cpw.mods.fml.common.FMLCommonHandler.onServerStarted(FMLCommonHandler.java:318) [FMLCommonHandler.class:?] at net.minecraft.server.dedicated.DedicatedServer.func_71197_b(DedicatedServer.java:210) [lt.class:?] at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:387) [MinecraftServer.class:?] at net.minecraft.server.MinecraftServer$2.run(MinecraftServer.java:685) [li.class:?] Caused by: java.lang.ClassNotFoundException: java.lang.ReflectiveOperationException at java.net.URLClassLoader$1.run(Unknown Source) ~[?:1.6.0_45] at java.security.AccessController.doPrivileged(Native Method) ~[?:1.6.0_45] at java.net.URLClassLoader.findClass(Unknown Source) ~[?:1.6.0_45] at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.6.0_45] at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) ~[?:1.6.0_45] at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.6.0_45] at net.minecraft.launchwrapper.LaunchClassLoader.findClass(LaunchClassLoader.java:104) ~[launchwrapper-1.9.jar:?] at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.6.0_45] at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.6.0_45] ... 33 more [16:42:11] [server thread/ERROR]: Encountered an unexpected exception cpw.mods.fml.common.LoaderException: java.lang.NoClassDefFoundError: java/lang/ReflectiveOperationException at cpw.mods.fml.common.LoadController.transition(LoadController.java:162) ~[LoadController.class:?] at cpw.mods.fml.common.Loader.initializeMods(Loader.java:692) ~[Loader.class:?] at cpw.mods.fml.server.FMLServerHandler.finishServerLoading(FMLServerHandler.java:97) ~[FMLServerHandler.class:?] at cpw.mods.fml.common.FMLCommonHandler.onServerStarted(FMLCommonHandler.java:318) ~[FMLCommonHandler.class:?] at net.minecraft.server.dedicated.DedicatedServer.func_71197_b(DedicatedServer.java:210) ~[lt.class:?] at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:387) [MinecraftServer.class:?] at net.minecraft.server.MinecraftServer$2.run(MinecraftServer.java:685) [li.class:?] Caused by: java.lang.NoClassDefFoundError: java/lang/ReflectiveOperationException at jrfpaintings.classAltPaintingsMod.init(classAltPaintingsMod.java:125) ~[classAltPaintingsMod.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.6.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.6.0_45] at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:513) ~[FMLModContainer.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.6.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.6.0_45] at com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.SynchronizedEventSubscriber.handleEvent(SynchronizedEventSubscriber.java:47) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:304) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.post(EventBus.java:275) ~[minecraft_server.1.7.10.jar:?] at cpw.mods.fml.common.LoadController.sendEventToModContainer(LoadController.java:208) ~[LoadController.class:?] at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:187) ~[LoadController.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.6.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.6.0_45] at com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.SynchronizedEventSubscriber.handleEvent(SynchronizedEventSubscriber.java:47) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:304) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.post(EventBus.java:275) ~[minecraft_server.1.7.10.jar:?] at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:118) ~[LoadController.class:?] at cpw.mods.fml.common.Loader.initializeMods(Loader.java:691) ~[Loader.class:?] ... 5 more Caused by: java.lang.ClassNotFoundException: java.lang.ReflectiveOperationException at java.net.URLClassLoader$1.run(Unknown Source) ~[?:1.6.0_45] at java.security.AccessController.doPrivileged(Native Method) ~[?:1.6.0_45] at java.net.URLClassLoader.findClass(Unknown Source) ~[?:1.6.0_45] at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.6.0_45] at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) ~[?:1.6.0_45] at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.6.0_45] at net.minecraft.launchwrapper.LaunchClassLoader.findClass(LaunchClassLoader.java:104) ~[launchwrapper-1.9.jar:?] at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.6.0_45] at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.6.0_45] at jrfpaintings.classAltPaintingsMod.init(classAltPaintingsMod.java:125) ~[classAltPaintingsMod.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.6.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.6.0_45] at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:513) ~[FMLModContainer.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.6.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.6.0_45] at com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.SynchronizedEventSubscriber.handleEvent(SynchronizedEventSubscriber.java:47) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:304) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.post(EventBus.java:275) ~[minecraft_server.1.7.10.jar:?] at cpw.mods.fml.common.LoadController.sendEventToModContainer(LoadController.java:208) ~[LoadController.class:?] at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:187) ~[LoadController.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.6.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.6.0_45] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.6.0_45] at com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.SynchronizedEventSubscriber.handleEvent(SynchronizedEventSubscriber.java:47) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:304) ~[minecraft_server.1.7.10.jar:?] at com.google.common.eventbus.EventBus.post(EventBus.java:275) ~[minecraft_server.1.7.10.jar:?] at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:118) ~[LoadController.class:?] at cpw.mods.fml.common.Loader.initializeMods(Loader.java:691) ~[Loader.class:?] ... 5 more [16:42:11] [server thread/ERROR]: This crash report has been saved to: /var/lib/games/minecraft/./crash-reports/crash-2014-08-08_16.42.11-server.txt

No kidding. On my first try, the client proxy itself became the offending class on the server, so all I accomplished was to move the error. Part of my problem is that the examples I've found have been v1.6.4 (and very complex mods). It's taking me a while to tease out the general proxy implementation details from the haystacks of mod-specific and Forge-version-specific context. That's what I figured. What remains somewhat mysterious is how I refer to something that will work on the client without the mere mention blowing up on the server. Okay, runtime polymorphism is old hat for me. What I haven't figured out is how I can even write the client-side instantiation without the server blowing sky high as soon as it tries to instantiate my main class (nothing within my main class even starts to run; my error now is during its construction). I'm obviously not doing a proper job of quarantine. Thanks, that should help. The mystery to me (for now) is how to write a "@SidedProxy(clientSide= ...)" statement. There are some very long strings in there with lots of dotted subparts that the compiler can't help me parse. Other example mods and tutorials have similarly long but differently dotted paths (and little or no context within which to interpret them). Since every tutorial I've seen so far simply tosses these strings at me without telling me what the parts mean, I haven't been able to write one of my own. Seeing your whole project, it looks as if each string is <package>.<class>, like an import statement. I'll give that a try and see what blows up next. The good news is that my mod runs flawlessly inside of Eclipse, so I'm doing something right.

An item in hand or inventory is actually an ItemStack. You can code the block's drop method to give the dropped stack a "damage" value, and from damage you can choose a texture.