jeffryfisher

My thoughts: 1) You should add the @override attribute to your quatityDropped functions (and then respond to the error messages). 2) You should include the source of Firstmod so we can see what may be interfering with object instantiation. Do all of those objects execute their constructors successfully? Did you confuse item classes with ore classes in declarations? (something like that would explain the smeltable metals succeeding while gem-dropping ores failed)

Yeah, I did all that (and it was working) back in 1.7. Something is missing in 1.8. Maybe there's some trick to the resource location in the new version? There isn't any texture, so I'm not sure where the resource should be located under the new scheme. I'll look again tomorrow with fresh eyes.

I've upgraded my mod from 1.7 to 1.8. Everything looks good except... My enchantment is missing (or hidden). It hasn't shown up in an enchanting table, and there's no book in creative inventory (there was in v1.7). I've walked through the constructors in Eclipse's debugger; the super executes, and all assignments look OK (then I "setName" and "addToBookList"). I've looked at how vanilla enchantments are constructed, and my addition looks right. I'd post a log or error, but there's nothing to see. It just vanishes silently, and the game comes up without it. Is there some new twist to enchantments in mc1.8? Is there yet another call to be made before my enchantment will be seen? Do enchantments now need json files too? I've scoured the upgrade tutorials and forums, and I don't see any hints. I've tried resource locations both with and without a "<mod>:" prefix; no joy. What am I missing?

To learn your first programming language, sign up for a class. If you're not in school, then try a local community college, which probably has at least one programming class at night. The class will not only show you basic programming concepts, but also introduce you to tools like IDEs. After you have some programming foundation, then the best way to add a new language is to pick up an existing program in that language and read it, then try to change it a little bit. The existence of various code and data structures shows by example how to accomplish certain things that you can file away in memory to do for yourself when you write your own programs. Therefore, I think that the ideal environment in which to learn Java is to get into modding Minecraft (that's how I started Java programming last year). Make sure you install your Forge to give you access to all of the source code. Spend some time exploring. With a handy tool like Eclipse for Java, you can learn a lot just by tracing definitions and references of variables and functions. Then imitate a simple mod. Then try to do something new. When you run into a "how does that work?" mystery, use Eclipse to jump into the Minecraft code that actually does it. Trace it. Take careful notes on 9-digit obfuscated variable and function names so you can decrypt their likely definitions. Curse the private final enum that stands between you and your long-sought mod. Then learn "reflection" so you can sometimes work around even such a hurdle. Then you'll know some Java. PS: To give you an idea of the learning curve -- I started with programming experience but zero Java. I finished my first simple mod in 4-5 days (half of that learning installation, gradle and Eclipse), but it was about two months before I learned enough Java, Minecraft code, and Forge before I used a little (brute-force) reflection successfully in a mod.

As I slog through all of the coding changes to upgrade my 5 mods from mc1.7 to mc1.8, I am developing an abstract parent-mod class from which each of my mods will be extended (or so goes my plan). It won't allow quite the flexibility that comes with Forge from scratch, but it might be a handy crutch for first-time modders or any quick-and-simple mod not needing exotic capability. I liken it to brewing beer from extract vs mashing all your own grain. If it works (i.e. if I don't run up against a drop-dead run-time incompatibility), then I'll find a place to share the source

Aha, I surmised as much (that it wouldn't be flexible enough to be incorporated into Forge itself). However, there may be a sample-mod or tutorial place where my package could give a head start to new modders attempting their first run-of-the-mill mods. If I end up with code that actually accelerates my next new mod (after I'm done with upgrades to 1., then I may yet find such a modders' forum and share the source there. -- Uncle Jeff, Vancouver WA

While making my five mods (in 1.7.10), I caught myself doing some of the same things again and again. For a while now, I've thought that some generic mod features could be codified in one place to be inherited by every mod I start. As I work to upgrade all my mods to 1.8, I am side-tracking to encapsulate as much of the required repetition as I can in a package of abstract classes that will do just that (become parents to all my mods/client proxies). It occurs to me that I might be able to generalize my own mod-series parents into something generally useful: an abstract class from which anybody could extend a new mod. So, if/when I get my mods working in MC1.8, should I share my package with its abstract classes, or just keep it for my own development? If I shared, where (I don't know jack about github, please point to *its* tutorial) Cheers, Uncle Jeff, Vancouver WA

"Display" is a red-flag word suggesting client side-only (because the server never displays anything beyond its log). Take a look at the method and anything it calls to see if that's so.

With that set of recipes, you can paint white wool into any color wool. If you want to paint from color to color, I think you can replace the white wool's zero "damage" with a wildcard value. If you wanted to, you might also play with the stack sizes so that one paint could color several wool blocks (e.g. 4 wool in and 4 wool out for each paint used).

Doesn't the common proxy need an empty "public void registerRenderThing()" that the client proxy will override with something non-trivial? BTW, rather than a method name like "registerRenderThing", you can mimic the Main class method names that do the calling. In other words, your proxies can parallel your Main class's PreLoad(), Load() sequence. Your common proxy can even do all the real work that's in those Main methods. The client proxy can call its super before doing a few client-only steps. What you'd be left with in each Main method is a simple call to the corresponding proxy.method. It's not necessary (and maybe not even good style), but see it that way once and suddenly proxies make perfect sense.

After walking through the interface, it looks like each piece is assigned an absorption ratio less than one, and if the sum of the pieces adds up to one, then all damage is absorbed. To make sure that some damage leaks through, assign absorption ratios that add to less than one (e.g. 0.2 for each of four standard pieces, adding to 80% absorption with 20% reaching the wearer). You probably don't want your armor to ever add up to more than one, because then the pieces would take excess damage on themselves, reducing entity damage to a negative number, and that neg would be rectified to zero in the calling method (but the excess damage to the armor would remain). I suggest that you lower your shield's absorption ratio significantly.

If your paint is like dye, then I think you need a separate recipe for each color (use a loop with a var incrementing 0-15 which gets applied to the itemStacks in your recipe statement). Unfortunately, I can't see your recipe in the box labeled "recipe", so I can't see what you're trying to do.

That's not enough information. What is your mod trying to do, and what does happen when your "art" fails to appear? What "normal" Minecraft are you testing in (SP or MP-client/server)? For all I can tell, you have a client/server issue with server errors in the server console that you aren't telling us (and may not even have noticed). One common error mode (for me) is that some bit of client-only code runs OK in Eclipse only to fail in MP. Since texture handling and rendering are client side-only, this could be the nature of your problem (although most such problems crash completely, which is a symptom you should have mentioned if the case).

He said "I want to change the Enum so that the mod itself can load my textures as well." That looks like adding new enum values.

I don't want to reference the Enum though.. I want to change the Enum so that the mod itself can load my textures as well.. As far as I can find EnumHelper doesn't let me do that EnumHelper should let you do exactly what you've talked about (shove some new enum values into somebody else's enum), so look again. If there's still a problem, then start posting code. Maybe you need to learn reflection from looking at how EnumHelper works. Then you can hack the enum the way you want.

You should take a look at the getEntitiesWithinAABB(...) method and the other methods around it in its class. By that I mean to select the method name in your code in Eclipse, then right-click on it, then use the popup menu to view the method's declaration. You'll learn much more that way much faster than coming here to ask others to go do that reading for you. Once there, you will see several such methods. Look at their arguments. You can exclude an entity or include only a certain type of entity. I think you'll also see some calls to underlying methods in the chunk management class. Investigating those might give you more ideas how to refine your search to get exactly those entities you want to electrocute (i.e. you probably don't want lightning shooting at paintings and lead-knots). Good Luck!

Hold everything... Your BLOCK class implements the interface, but you're testing a TILEENTITY for instanceof? Maybe you need to translate the TileEntity into a Block (te.blockType) so you can test the instanceof that instead?

With 1.8 released (and Microsoft's acquisition likely to end all development that gamers would ever care about), can we see where vanilla horse armor coding will land? Knowing what we're stuck with, can someone more knowledgeable than I now do the "pull request"? In the mean time, for fun and as a Java exercise, I am going to attempt to subclass EntityHorse in a way that separates all horse armor from it. If I have my way, then my mod horses will wear armor defined in a subclass of ItemArmor. Horse-armor will simply become another piece following helm, chest, leg & boots. In other words, while a helmet goes on a humanoid head, horse-armor goes on a whole horse. I hope I can bring together both vanilla and mod armors Please let me know ASAP if progress has been made in this area so I don't reinvent too many wheels!

Where do I sign up? I'm an unemployed programmer and systems analyst with over 20 years' experience. I'm looking to add skills, references etc while continuing to hunt for paying work. I live in the Portland area (Vancouver), and I was also on Kumoricon staff (saw your tweets, but too late to suggest a meeting). Have beer, will travel.

If you want to start a new world, then you can start under a new program. However, if you want to port an existing world to a new server, then it's very tricky to change from one line of development to another. Anything (block types, items, entities etc) that one modded server saved into the world's files but is not known to the new server's mods is prone to be discarded. Seemingly random chaos can ensue. Unless you have a clear understanding of what your mods are doing (and not doing) internally, you shouldn't jam an existing world from one mod to another. If you decide that you can switch to a Forge-modded server, especially if you dip your tow in the water with a new world, is there something stopping you from hosting it yourself? I run mine on the same machine as my web server. It sits in my laundry room whirring away 24/7, and my Comcast broadband can support about 6 players concurrently. If you're new to MC server, or if you're just trying out something, then your usage pattern is likely not in the hundreds of players on at the same time. You might start by running at home. You can port that world later to a Forge-modded server on a higher-bandwidth host if you decide to keep it and grow it.

I happen to be in that mod today, so I can show you what I used: WorldClient wc = FMLClientHandler.instance ().getWorldClient (); It traces back to Minecraft.theWorld. This is in a @SideOnly(Side.CLIENT) class, so YMMV.

IIRC, domain is the part of a resource location string preceding the colon. In general, a fully qualified resource location is <domain>:<path within domain>. Resource domain (in this case) is "cm" (and then you need a colon). It's an important part of mod terminology, so remember the concept for all resources in all mods. It can be confusing, figuring out what is needed where. In context, you might need only a path within domain (just the path, or even just a filename), because other parts of the resource location are known. It appears that there is no such context for this file, so the full resource location string would be required.

It's a stumbling block for every new modder (and I tripped over it at least twice before I caught on): There are instructions and tutorials telling us to use setupDevWorkspace when it is much more useful to do setupDecompWorkspace. Is there EVER a reason to do just Dev? The only one I can think of is if one wants to compile on a different machine from where one does editing. Of course, that has me wondering why again...

In one of my mods, I needed the same thing in a place called from a method that had a world parameter that it was not kind enough to pass along to me. What I did was trace that method's call chain back to where a static world was being passed in, and I imitated the static reference (I was fortunate that it was public). Amazingly it worked

You shouldn't need to dive into the mechanics of breaking the block; the vanilla behavior should get that far as is. As for hitting until it breaks, that just drops the block by default, not some item (e.g. diamond) found within an ore (e.g. diamond ore). Your something-Block subclass needs to override a method pertaining to what it drops when harvested, but I can't recall the exact method name. Search for "drop" and imitate the BlockDiamond class.