jeffryfisher

Also, rather than checking equal to Blocks air, it is probably better to call the isAir method on each block. That way, if there are any other blocks masquerading as air (especially from mods you never heard about), then those good-as-air blocks would be treated as air even though they're not actual air blocks.

When you installed Forge for development, did you specify "setupDecompWorkspace"? If not, then you may want to install it again. Once you have the "Decomp" setup, then you'll find a mostly deobfuscated transformation of vanilla source code in <ForgeDir>\build\tmp\recompSrc. The java is under "net", and json files are under "assets". All of the blocks and items and entities and achievements etc are there to be studied, called, extended, imitated (and copy-pasted and reflected).

No worries, I didn't expect Forge to fix the vanilla code. I saw that the vanilla code was already fixed in a build that came after the current recommended Forge. When Forge gets around to adopting a Minecraft build at or beyond 15w37a, then the fix will be there.

Where should I look in these forums to get a sense of when Forge will reach a recommended release? Where may I see which vanilla build is under each Forge release? I ask because vanilla EntityHanging had a bug in it that was fixed (according to Mojang's bug tracker) in 15w37a, and I am trying to decide whether the fix will come to Forge soon enough that I shouldn't bother with a work-around.

I'd be more sophisticated than simply checking for air. You don't want tall grass, bushes, flowers, tree-leaves etc stopping you. You might want to code a simple function for what kinds of blocks you're willing/unwilling to overwrite (and celebrate if you can find a common attribute like transparent/opaque that distinguishes them). As for your method, it does not even look to be syntactically correct, so I can't read it. However, it looks as if your loops are not nested, so you might only be checking edges of a space, not its entire volume. Please rewrite and format it in an IDE, and then paste between CODE tags to preserve formatting.

The main tutorials area has a whole tutorial series by CoolAlias

Nice traces; I saw several of those methods myself, but with full obfuscation in the crash report, I was unsure which were doing what where. It looks like the hardness call is to determine whether to trigger an achievement or something. If that does not need to execute on the client side, then I may work around this bug by returning a default value when isAir == true. Then my walls can go back to having variable hardnesses for actual breaking.

I think I have found a bug in vanilla MC 1.8 code (while using Forge b1450), but I don't like to think in that direction, so I have low confidence. I had the following client-side crash report: ---- Minecraft Crash Report ---- // Everything's going to plan. No, really, that was supposed to happen. Time: 10/14/15 5:22 PM Description: Unexpected error java.lang.IllegalArgumentException: Cannot get property PropertyInteger{name=skin, clazz=class java.lang.Integer, values=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]} as it does not exist in BlockState{block=minecraft:air, properties=[]} at net.minecraft.block.state.BlockState$StateImplementation.func_177229_b(BlockState.java:158) at jrfwalls.classAbstractWall.func_176201_c(classAbstractWall.java:119) at jrfwalls.classAnystoneWall.func_176195_g(classAnystoneWall.java:20) at net.minecraft.item.ItemTool.func_179218_a(ItemTool.java:59) at net.minecraft.item.ItemStack.func_179548_a(ItemStack.java:327) at net.minecraft.client.multiplayer.PlayerControllerMP.func_178888_a(PlayerControllerMP.java:154) at net.minecraft.client.multiplayer.PlayerControllerMP.func_180512_c(PlayerControllerMP.java:294) Context: My mod is a set of walls with 16 subtypes. When I break one of my walls, the game crashes on a call to getBlockHardness(World worldIn, BlockPos pos). ItemTool's call to getBlockHardness is inside onBlockDestroyed(). The crash report says that air does not have the property that my block uses to determine its subtype. It appears that the world has already replaced my wall with air before asking how hard it was. Am I imagining things, or is this a bonafide Mojang bug? Class Block simply returns this.blockHardness without using world or pos. I can't find an example of a vanilla block type that overrides getBlockHardness, so as far as I can tell, nothing in vanilla actually uses world and pos. In pure vanilla, the bug may be hidden. Does that make world and pos into red herrings that should not be used? My method: @Override public float getBlockHardness(World worldIn, BlockPos pos) { int meta = this.getMetaFromState (worldIn.getBlockState (pos)); switch (meta) { // Assign exotic hardnesses to some meta values case 6: return 0.7F; // Netherrack case 8: return 30.0F; // Obsidian case 15: return 1.5F; // End_stone; Todo: to become end_brick default: return super.blockHardness; } }

I'm trying to find an example of redstone device code that has more comments than the vanilla block classes. Unfortunately, my searches are running into haystacks of zany redstone constructions and their videos, so I am not finding help for modding. If anyone can point to a primer on coding redstone devices, I'd be grateful. In particular, I am getting all turned around (literally) as I try to calculate how much power my device is receiving from its six faces. My first confusion is from vanilla devices: if one looks UP at a block above, it asks how much strong power is being provided "UP". It's as if the device wants to know how much power is being sent even further away. Shouldn't it want to know if the block UP is sending power DOWN (and block offset NORTH is sending power SOUTH etc)? Obviously I am not reading the correct meaning of one or more deobfucated names. Is this explained somewhere? My second confusion is strong vs weak power. I want my device to be powered by connected wires or original source, but not by energized blocks. The magnitude of my device effect will depend on the strength of signal. I think that means I want only "strong" power, but I'm reading conflicting info on wire signals. I'm unsure what to believe (or what method to call).

Since Minecraft's big bandwidth hog is the transfer of chunks from server to client, I am confident that chunk data exists on the client (at least within viewing range, once it has loaded). I think it was the presence of all that data that made xray cheat mods possible. The server does update chunk data, though I suppose some are updated more frequently than others. One way to see an update is to measure the lag between when you mine a block on your client and when you see its drops appear -- there's a round-trip communication with the server in between. If you have ever lost a connection, you may have had the experience of mining blocks and blocks without any drops appearing.

For starters, please use more informative subject lines. A good subject line will draw people who know about your topic. Also, if you care enough to put info into your subject line, then more people will care enough to open your cry for help. Second, the minecraft version is 1.7.10, so let's not mention meshers. To the best of my knowledge, that horror doesn't appear until mc 1.8. Third, the crash was caused by a null pointer exception. Set a breakpoint at the offending statement, run again, and see what's null going into that statement. Then fix your code to give the null pointer an object. From the error message, it's a probably null itemstack, which can follow from a null item. Be sure that you have instantiated (and registered) each of your mod's items before you try to use them in recipes. A null itemStack can also follow from a malformed recipe. Be sure that every recipe defines all of its ingredients. In your code I see a recipe for "pestle" that starts with "ORO", but it only defines ingredient "S". This will fail. I also see a recipe for "crystal" starting with "ORO", and it has FOUR rows of ingredients. Have you defined a mod crafting table with four rows of input? If not, then this too will fail.

I think there's another function for combined light level. Would that save you from calculations? Or, if you care more about night/day rather than actual light-level (which can be affected by weather, trees etc), skip all light-level calc and go straight for modulus (%) of time. I'm unsure why the client/server numbers are incongruous. Do you have enough context (e.g. world-time) to be sure the numbers are comparable?

I agree. I wonder if the correction is a general one that could someday become an FML "pull-request" for a "final" 1.7.10 version of Forge that would save worlds to be readable by 1.8. For instance, if there are certain block, item and entity IDs that are going to be claimed by 1.8, then mod objects having those IDs in 1.7.10 should be converted to non-conflict IDs. Forge's registration, mapping, and chunk-saving machinery, not every little mod, seems like the place where that knowledge would be coded. A nice added feature would be a server-console command to grind through all chunks in the world, perhaps with all player logins disabled.

Then you need to add the poor-man's vision enhancement: Boost the brightness on your monitor. YMMV, but for me it does wonders for the nether (changing nether-brick from solid black to dull-brown brick).

Items, including items from blocks, must be "meshed" in your client proxy's init method. If you've done that and still see the "missing" texture, then you must carefully examine your item model json files for name mismatches. They can be tricky to spot; I lost hours over an errant underscore hiding within a json file. Case matters too, and one missing comma in a json file ruins the whole thing. Use a tool like JSON Lint to validate your json contents.

Exactly, and the prospect of extending several different block types in the same way had me thinking that the first step is to move the tricks into an interface that each extension would implement (Java's way to achieve something like multiple inheritance).

If thinking outside the box, then maybe a helm enchantment conferring night vision. If that's OP, then maybe a helm conferring night vision but very little protection.

What error log are you getting now? Is the error raised on the server? If so, that would be because everything about rendering is client-side only.

I am still hoping to someday be able to invent new levels and textures of horse armor, but (as of recommended build 1450) it looks like the three vanilla varieties are still wedged into entity horse with no java hook to add more. Is there a method for adding custom horse armor types? If so, then where may I learn it or see an example? Searching for discussions, all I can find are dead-ends from mc 1.6 and 1.7. Rather than resurrect one of those necro threads, I'll just link the most hopeful: Back in June 2014, SanAndreasP wrote that he had a transformer and would make a PR. I can still see his transformer at GitHub. Did that go any further (and fail)? If not, then would that transformer have any value today? If so, then how does one make a PR for it? The code inside the transformer is mostly gibberish to me, but it looks like it adds a method to EntityHorse that a modder like me could call to add any item to its list of acceptable and wearable horse armor. I can't figure out where my mod would specify protection value and rendering, but I suppose that would be easier to see after the source code is transformed. BTW, I failed in last year's attempts to crack EntityHorse using reflection. The code is too literal (for me).

How often will a block be in the way where a player has his head?

Indeed, I have already done that. I remapped each of my missing elements to its new object. Unfortunately, while that can handled renaming among my mods, it did not help with when Minecraft itself grabbed some of the ids belonging to my blocks and items. When I tried loading my 1.7.10 world using 1.8, all of my mod elements were found, but then some of their ids shifted by one. In addition, many of my mods' blocks in the world had become new block types introduced in mc 1.8. Maybe I didn't do enough. I wonder if it is even possible to rifle through all of the chunks in the world to replace all occurrences. If it hasn't already been solved by someone else, then I'll put my energy into my next mod.

Fascinating. Could you have extended BlockAir instead of starting with just Block? I started thinking about other blocktypes that a player can walk through (grass, water etc). You could take some of your methods into an interface and then extend each walk-through block class that you want to illuminate, implementing the interface. Then when walking, like would replace like (air becomes air-light, water becomes water-light etc). I can imagine the bugs... sugar cane uprooting when real water isn't adjacent. On expiration, the interface would put the parent block back in its place. I'll give it a go when I get around to doing the mining helmet (or helm enchantment) on my to-do list.

Indeed... for your first mod, do something dirt simple, something for which you need only one tutorial. Well, you'll need an installation tutorial followed by a 1st-mod tutorial. I recommend getting both from the same author because even those can have elements of "style" that need to fit together. Blocks with subtypes are best left to 2nd mod and later. You'll find out why when you get to the json files. Forge has invented a nifty way to reduce the tedium (mcforge.readthedocs.org/en/latest/), but you should do a simple mod end to end and taste success before climbing that learning curve. Even in 1.7, but especially since the jump to 1.8, there's a whole raft of features required in every mod. Consequently, experienced modders, who code for multiple mods rather than just one, have a tendency to "factor out" those common features and encapsulate them in some idiosyncratic shared package that makes sense to themselves and nobody else. For instance, for my own series of four mods (with more planned), I have written an abstract mod class that each of my mods extends. My abstract class does a number of things that every mod must do, and it has some methods that multiple mods need to call. For example, the abstract mod class defines the common proxy class inside of itself. Every mod inherits it, so I don't need to go to the trouble of creating a new one every time I write a new mod. For your first mod, you should probably stay away from any "fancy" structure; just write a simple mod as if it were the only mod you ever planned to write. After you've made your second mod and see what each has in common with the other, then you may think about ways to avoid code duplication. Warning: My approach has the drawback that if/when I "improve" my abstract mod parent class, I must rebuild all of my mods so they can play nice with each other. Your mod will have a "main" class having the @Mod annotation. That in turn will have annotated preinit, init and postinit event-handler methods. Incidentally, there are additional handlers you can have in there too, but simple mods won't need them. Because of the way that rendering is done for mc 1.8, and because rendering is a client-side only feature, any mod that defines any block or item will need a proxy. The "common" proxy class will mimic your main class's preinit, init and postinit, but the methods will probably be empty (since mine are shared among mods, this is where I write status to the log). A client proxy class will extend the common proxy and fill in the client-side rendering setup code (e.g. calls to a "mesher"). Read about the sided proxy annotation for instructions on how to declare these things. Forge will then figure out which proxy class to inject at runtime so you don't have to. Beyond that, you add classes to control the behaviors of the things in your mod. If you have some items, then each may have its own class, possibly extending one of Minecraft's item classes so you can hitch your wagon to existing functionality and only need to code your idiosyncrasies. Likewise blocks. When in doubt, look at the vanilla code (located in ~<Forge dir>\build\tmp\recompSrc\net\minecraft). If you don't have that, then you might want a better Forge installation tutorial that sets up a decomp workspace instead of a mere dev workspace. No, I don't think so. The server needs items, but only the client needs rendering info like models. An item will likely be registered by either your main class or the item class itself. However, item models are "meshed" in a client proxy. In general, pre-init constructs things, and init operates on those things. Each also calls its parallel method in proxy. For example, my preinit is full of block and item assignment to "new" expressions (my blocks and items registering themselves). Note: There's exactly one and only one instance of each block and item in the whole program; that one instance is the program for all occurrences of that thing in the world. My init method has recipes and achievements. Its client-side proxy meshes item models My post-init method registers a game-time event "listener" (not to be confused with mod-loader event handlers in your main mod class). Once you've learned Forge from a Forge tutorial, the best tutorial for actual Minecraft features is the deobfuscated Minecraft source code that I mentioned above. Your first simple mod should be one package. In general, each new mod is a self-contained package. If you graduate to shared code, then you might make one shared package plus one package per mod. By the time you get fancier than that, you'll have lessons to teach the rest of us. I've seen this mod described elsewhere. I think I recommended one abstract class for all of the shared functionality. That would be extended by five classes representing the five shades. These would become five distinct block instances. Each of those five classes would have 14 subtypes based on block metadata (which means learning about class BlockState). The json files will drive you crazy, but at least Forge has a custom format that will spare you from at least some of the Cartesian product: mcforge.readthedocs.org/en/latest/ When you get down to brass tacks, try searching for specific keywords (like class names) that you're up against. I've found that Google does a better job of finding threads on this site than the forum search does (because the forum search tends to dredge up blizzards of error logs and crash reports). A more global search can turn up other modding forums too. Almost any hurdle you face has already been discussed. When that fails, start a new thread specific to the crux of your problem (it becomes more useful for the next person searching for the same thing). Good Luck!

Well, I settled on upgrading my 1.7.10 world to the final recommended Forge build (1448) for that version, and I now think that it will never go to 1.8. It just is what it is. From my reading, I've gotten the sense that many long-standing worlds are in the same boat, so my "note to self" is to backport a few of my mods' improvements to their 1.7 incarnations. That could (for instance) add my second set of walls to my Anystone Walls mod in 1.7.10. I'll also keep back-ports in mind if/when I get around to adding more sets of paintings to my paintings mod. That left me wanting a Forge server for mc 1.8, so I started a new world for friends and nephews. After using creative mode to finish testing the client-server operation of each mod (crafting, placing and activating items, blocks and entities), we're enjoying a return to the harrowing start-up phase of the game, naked and empty-handed in survival. It sure brings back memories (though not always as quickly as I need them). Notes on adding a 2nd mc server: A single host does seem to be able to run two incompatible minecraft-Forge instances without harm. In Linux, I installed each in its own subdirectory to keep their ops, whitelist etc files apart. After some aggressive chown'ing, their respective "universal" jars are humming contentedly. I don't know how java is managing the memory (since each java run statement claimed most of the RAM on the machine). Maybe things will get sticky if players log into both worlds at the same time (so far we've stayed together in one or the other). Before launching, make sure to edit server.properties so that the 2nd mc will use a new port number. I recommend bumping the 1st server's port number by exactly one because... One may also need to open the new port in the host's firewall. Depending on your machine's architecture, this can be as easy as changing the existing rule(s) to span a range of two ports instead of merely opening the 1st one. And of course, if the host is serving from behind a router, then the router's port-forwarding should be updated to include the new port (another reason to make it contiguous with the 1st).

You're still indexing a 0..45 array with index=46. It's time for you to set a break point (or four) and run your code in debug mode. The firat thing you must figure out is why the array has only 46 elements when you thought you added 4. You thought you had 50 slots, so where did that array come from that it has only 46? Put your debug hat on and do some sleuthing!