jeffryfisher

Well then, that's your problem. Your entity can't work unless it is registered. Register your entity, then rerun your mod, and then show us the log that two of us have asked for. Oh, and while you're rerunning the mod, set some breakpoints so you can step through the spawning code in the debugger. If you see where the entity is determined, then you will know what went zero that shouldn't have.

Can you show us the log? I'd like to see what commend you used and what the game thought of it. You should also try running in the debugger and setting some breakpoints. And, just for good measure, show us where you register this entity. I am suspicious of the pig result. It is the default for a spawner block because pig=0 in some entity or mob list. That suggests that there's a zero in your code (or command) that the game is translating into pig.

Is it really important to make the double directly? Isn't it reasonable to make singles and then double them up when placed? I suppose what I am asking is what you are trying to achieve (Why do you want this?)

Writing code such as two variables in the same place with the same name, and trying to register two entities using the same resource location shows that you do not even begin to comprehend programming, let alone Java. I say this in the friendliest possible way: It's time to phone a friend. Invite a more computer-savvy acquaintance over to sit at your keyboard and translate your concepts into computer language. You need more help than we can provide remotely.

Eclipse can highlight syntax and semantic errors, but it can't predict very many runtime errors. Code can be faulty simply by trying to use a pointer before it points to something. Eclipse can sometimes warn you where that's likely, but not always (Eclipse can't predict that a method will return null). Anyway, there are many ways for programmers to make promises and then break them at runtime. These broken promises are faulty code even if not the kind of faults that Eclipse can detect and show in red. Take away lessons: 1) When you don't know how to use a method, use Eclipse to show you all references to it. Look at how Minecraft and Forge use it. 2) Learn how to set breakpoints and run your mod in the debugger. Just as Eclipse gives you red to highlight syntax errors, it also gives you a debugger to step through code and into method calls so you can see what the frick-frack is actually going on when (or just before) it fails at runtime.

You didn't show us the parent constructor or either class's version of getDefaultState(), so we can't judge whether that call is wrong. I suspect that it is ok. When I can't see how some segment of code could possibly work (but when I run it, it seems to), I run it in the debugger to see with my own eyes how the pieces come together. If you find a bonafide error in BoP, then contact the mod developer directly. If it's popular, you might find it in Forge's Mods Forum.

Something else could be setting it to dead. Trace the callers of your methods. What calls onImpact? Does that caller also set your entity to dead? If hunting code doesn't turn up an obvious answer, then set breakpoints and start stepping through and into to watch what actually happens. You might decide that onImpact is not quite good enough to do what you want. You might need to find a hook upstream that fires an event you can use to replace the impact.

There are two parts to the technique, and you can use either or both. First you register your ingots, gems etc with the dictionary so that they become usable thereby. This will offer your items for use in other mods' recipes. Second, you write recipes to use generic ingredients from the dictionary (employ dictionary methods), thus enabling other mods' items to work in your recipes. Read the docs if you want to go either or both ways.

If you want help with a (another) crash, make sure that you post the crash report.

Or you could reduce the number of stages of rot to the point that you don't mind having separate stacks. For instance, have only fresh and tainted before something turns completely into rotting flesh or its vegetable equivalent (dirt?). Along the way, decide if/what will be durable for long journeys, and whether an enchantment (e.g. refrigeration) on a chest (or new device) might stop the rot. And after all that, figure out if the game would still be playable. What if you go on vacation for two weeks while your baked chicken sits in a multiplayer world. Will your character starve to death the next time he logs in?

I think that stackSize is now a private field, so you need to replace it with one of its (SRG) getter methods (if you even continue to use it).

Just in case somebody failed to see the obvious in the OP: private int stackSize; "Private" means that the field can't be seen outside of its own class (not even extensions can see it). The solution was to find a public method that would divulge it. In this version, the public method is camouflaged (obfuscated) by its SRG name. Expect that to change to a friendlier name by the next time you update your mod. In fact, you should do your future self a favor by leaving a comment to yourself in your code.

You should probably talk to DarthXenon. You might also look at the other subforums on this site. I think there's one for reporting trouble with others' mods.

Right -- There's a difference between an instance not existing and a class not existing. If missing an instance, you can avoid the null with a runtime branch like you had. However, if a class hasn't even been loaded, then your class will fail to load (the import statement alone will blow sky high). Runtime avoidance needs reflection, hence the proxy system. As for your color problem, you still need to step through the block's initialization using the debugger. You either have something out of order or a subtle wrong-field-referenced mistake. These are tedious to spot from just reading code, but they become blindingly obvious in a debugger.

Minecraft.getMinecraft().getItemColors().registerItemColorHandler(new ItemColorHeated(), ScientificMethodAPI.i_heatedIron, ScientificMethodAPI.i_heatedIronBlock); Class Minecraft may not exist in a dedicated server, so you might need to put this in a proxy before it can run outside of SP. Have you tried to reverse the order of the ingot and the block? If that does nothing, then you may need to step through your initialization to see if you accidentally use/store the vanilla iron block somewhere you intended to have your heated iron block. The mesher is obsolete, its use discouraged.

What works for me (though there are drawbacks) is creating a separate package for shared code. One drawback is that I must avoid static fields that would work perfectly well to support one mod but fail miserably as soon as two or more mods collide. In other words, when you lift some of your existing code to a higher level of abstraction, you may need to fix some of its single-instance assumptions. Another drawback is that when more than one of my mods is installed, the classes in the shared package will be loaded from only one of them. This creates a synchronization hazard for users who download my mods at different times. If those mods are out of sync (built on different versions of the shared package), then some really weird run-time errors can crop up, so whenever anything changes in the shared package, I must remember to rebuild all of my mods and increment an intermediate version number. I now keep one level of my dot-versioning in sync across all of my mods to denote which version of the shared package is in them (thus I can easily see a mismatch in any crash report with multiple mods loaded). When running my mods, I (and my friends) must make sure that they're all from the same generation.

And make a conscious decision on whether you want to use UP and DOWN (like a piston) or only N, S, E & W (like a furnace). If the latter, use BlockHorizontal. Actual state receives a state (probably made from a metadata value 0-15) and returns another block state, not and integer, so it is not limited. You just need to set each property within the range for that property. The method may reach out to the world (neighbor blocks, tile entities etc) to get data for deciding the actual state.

Are you really talking about an item (still in hand) or a block (you had an item in hand, but it has been replaced by an object placed in the world). If the latter, then you might be able to use the PlayerContainerEvent. I think it fires whenever a player opens a container GUI such as a chest.

Well... With dev environment setup looking like more work than the coding itself, I have wimped out. I posted an "issue" in github along with the code for the two Forge parts that I semi-validated in Eclipse. I am hoping that someone with more experience and better tools can take it across the finish line.

Some of the methods have changed between 1.8 and 1.10. I think there were also changes between 1.7.10 and 1.8. You'd do best to look up a vanilla renderer in both 1.7.2 and 1.10.2 to see how usage differs. Find a vanilla item/block somewhat like what you are modding and use it as a guide.

Well, I was right about not understanding git and it's web UI. Agreed. It was the UI that railroaded me into saving each edit like that. I'll try again to see if there's a way for git to save each edit on the same branch before committing, but the web UI didn't seem to offer me any choices yesterday. I wonder if it might be better for me to post a suggestion (and half-baked code) in the suggestion forum so someone with better tools and more experience can do it right. Let me know if I should take that approach. So, even if it seems as if the only instantiator is the other file I edited, some mod out there might instantiate its own event object and break if my change hit it? I guess the original constructor can call the new one and pass null as an argument to the new player parameter. Aha, that's why it thought I had 3 changes! I have no idea how I managed to paste that there. I've reached that same conclusion myself. I'll see what happens in Eclipse when I try to work on my own copies of files that duplicate class names inside the libraries. OK, so after fixing a couple things, I should try a merge. If I merge in the right order, then my branches should reduce to one, and then I might make a proper PR. My other quandary is whether or not I should try to wade into the third part of the change: Fixing the hook's call from inside the vanilla class to pass its "this.thePlayer" field to the modified Forge method. I don't even know where to look for the script that injects Forge hooks into vanilla classes. Would you prefer that I leave that to someone else, or should I learn where to get it done?

Immerse yourself in the vanilla java source code. Start by "walking" through methods that you're calling and overriding. Wherever you see Java constructs or qualifiers that are not second nature to you, do a separate Google search on it + Java + programming. The vanilla code is a rich set of examples of Java programming techniques. Then fire up your debugger and step through some of the sequences that your starter mod touches. Not only will you see how Java functions, but you'll begin to see how Minecraft is stitched together. Pay particular attention to whether you are in the client or server. Learn to wrap your head around parallel execution. If you're lucky, you'll never need to wade into the morass that is client-server communication, but become aware that it is out their, lurking just beneath the surface. Then study "reflection". By this time in 2017 you should be ready for advanced modding.

I've taken the plunge into MinecraftForge at GitHub. However, being unfamiliar with git, I am unclear on the process. Not wanting to screw up anything, I first forked 1.10.x. I then edited two of Forge's classes. Each produced a "pull request", but only within my fork. Still not wanting to screw up Forge, I have not tried to merge anything. I am unsure what (if anything) to do next. My work is at https://github.com/jeffryfisher/MinecraftForge Should I merge, or should I let others take it from here?

That would be a core mod. This forum does not support core mods. You shouldn't edit vanilla methods. If you ever seriously needed a vanilla method to change, then you would submit a "pull request" to the Forge developers. Likewise, you shouldn't edit the methods inside other mods (if that's even possible). Instead, comunicate with the mod's owner about supporting what you want to do. Learn how to integrate your mod with Forge so that your mod can "play nice" with other mods. If you talk about core-modding or hacking others' mods, then maybe the forum moderators will explain things better than I have. However, if all you want to do is to detect the existence of a method in a class, then use reflection. The post-init event handler is a good place to accomplish such inter-mod coordination. Once your code knows that a class and method exist, then you can (still using reflection) call the method to act on the class or objects thereof. Be careful with reflection; it's inefficient.

Minecraft version? Forge build?