jeffryfisher

Look at class ChunkProviderGenerate, especially its replaceBlocksForBiome method. I see a Forge event hook in there that could be useful if you subscribe to it.

Registrations usually belong in one's main class (probably in init). Sometimes, for something client-only, a registration might belong in a client proxy.

So it works correctly now? If not, then where did it do something you didn't expect?

Granted; playSoundEffect does nothing on the client side (the subclass of World instance passed in on the server-side is not the same as on client-side). Being paranoid (and wanting my code to remind me of what happens where), I still try to imitate vanilla code by bracketing my calls when I know what side they should run.

Please step through tryToCreatePortal in the debugger and tell us where it goes wrong.

When something doesn't render at all, then you should look at the log file (not console output, it is incomplete). Rerun in debugger to see what is really happening. It is very strange that you don't even get a missing-texture block (pink & black checked cube). Find out how your mod skips rendering without a missing texture or a crash.

Both your java code and json files have errors. Fix them and the problem will go away. PS: The console does not show enough output. Look in the log files to see more warnings. Then run in the debugger.

I can sympathize with the modder because the method, although static, takes a parameter that is an instance of the class. That's a red flag in my design book (if the method needs an instance, then why on earth is it static???). Find out what calls this "clickBlockCreative", and then see if you can inject your ship hit and test ahead of the call. Alternatively, let the static method handle its fire first; put your ship code into onPlayerDestroyBlock.

1) Learn Java 2) Install Forge decomp workspace. 3) Find and read the source code for the vanilla clock 4) Do as much as you can yourself 5) Come back here, tell us what aspect you want to customize, and show your work + error log (if any).

Then you'll need to search for it. It should be nearby, if not the same.

I believe that Minecraft's usual bottleneck is still bandwidth, not CPU, so put on your client-server hat and choose an approach where the server does enough thinking to minimize traffic before off-loading visual analysis to its clients.

Many aspects of sound are counter intuitive (well, most of client-server architecture takes some experience to wrap one's head around). Most of the sounds in the game are decided server-side and then sent to all listeners (world accesses) client-side. You'll see the calls bracketed by "!world.isRemote" (and you will want to do likewise). It's an unusual sound that starts as a decision made client-side so that nobody else can hear it. Clicking on a game-control would be like that, not in the world, so applicable to only the player doing the clicking.

The super profile for addInformation (as of mc 1.8 ): @SideOnly(Side.CLIENT) public void addInformation(ItemStack stack, EntityPlayer playerIn, List tooltip, boolean advanced) {} It looks as if you qualified the List in yours. And getSubitems: @SideOnly(Side.CLIENT) public void getSubItems(Item itemIn, CreativeTabs tab, List subItems) { this.block.getSubBlocks(itemIn, tab, subItems); } It looks as if you again added a qualifier to your List. If these are still like this in 1.8.9, then try again without qualifiers. If that works, and you still want to enforce the nature of the lists, then you might need a runtime data-integrity check.

1) I think the server should be the authority on what gets made. The client should dutifully display correct info to a player. If the client doesn't have good data, then the server must send it. 2) Don't forget about the End and Nether. They don't have day-night cycles, so you should think about how you want your custom crafting device to behave in those places. Do want your table to be inert? To explode? To act randomly like a clock or compass? To magically follow the day-night value of the overworld? If the day/night function doesn't default to what you envision, then you'll want to take steps. 3) I don't trust isDaytime(). IIRC, it is based on light value, in which a thunderstorm can turn day into night. In my own mods, I do modulo arithmetic on WorldTime: protected int signal(World w) { long wt = w.provider.getWorldTime (); if (w.provider.getHasNoSky () || // No sky means Nether or End (no moon phase) (wt % 24000) < 12000) { // Time of day 0..11999 is daytime (moon not up) return 0; } else {...

In MC 1.8, it's a class in <Forge>\build\tmp\recompSrc\net\minecraft\client\renderer\entity\layers

I tried to trace the appearance and use of "isDouble", but I got lost. There's a constructor for BlockColouredSlab that takes an isDouble parameter but does not seem to use it. You might need to break out the debugger to see what is being returned from calls to isDouble() methods at various stages. In what Vanilla code I can see (1.8 ), half stone slab and half wood slab (and the full slabs) are each a simple extension of BlockSlab. Yours is not so simple (seemingly combining all possibilities into one extension of BlockSlab), so there might be a timing problem during initialization. Set a breakpoint on the instantiation of a problem variant and trace its construction & initialization.

Sounds like lighting is failing on opacity. Therefore, your face may be "rendered" but not illuminated. Is the dark face always the "interior" face (halfway plane of the cube)? -- Interesting screenshot. Light is not getting into the empty part of the cube. It could be tricky to fix because slabs themselves had a lighting bug for a while (the underside of a half-slab being as dark as the top face even if there was a light source right under it). There was a "fix" sometime between 1.8 and 1.8.8 that I haven't read yet. If you can find what changed, then you might find the problem. Do vanilla slabs act differently? I wish I could be more help, but the more I think on it, the more it looks like something new and not a form of the bug I had seen before.

First learn how to program in Java. Then learn how to install Forge (see tutorials). Then learn how to develop a mod in Forge (see tutorials). Then subclass BlockTNT, overriding what you want to be different. When you get stuck, learn how to post the proper details of your work and and the runtime log. If you want to find somebody to make a mod for you, then you should probably post to another web site dedicated to mod requests. This forum is for mod programming help, and it expects you to have already done some study and some work, which you should evidence in your OP.

What is it about player entities that keeps chunks loaded around them? Could you imitate that? Or, create a special entity (or tile entity) that tricks the vanilla system into keeping its chunk loaded... sort of like a phantom player with observation radius 1.

How can you know? There is no information provided at all. Exactly, which I took as license to use my imagination. I imagined that the author had watched the wrong tutorial for the Forge version he had. Instead, it looks like he just missed a step. I think that each simple block in 1.7 needs to call setBlockTextureName. However, a block with subtypes has needs to override getIcon instead: @Override @SideOnly(Side.CLIENT) public IIcon getIcon(int side, int meta) {...}

You're using the wrong version (or the wrong technique for the version you have).

No, you just need to get a hell of a lot closer to the finished product before you ask for the tip that sets you free.

What is your experience in the debugger? What breakpoints did you set, and what variable values did you see that you can't explain? The debugger is your friend (at least it's a tool). Don't come here until you have either a log file from crash or a narrative from using the debugger. You'll be amazed how many bugs you crack on your own steam once you invoke the debugger, and we will be so much more productive when you can share its info after you get stuck again.

Don' feel bad. When I came to MC modding in spring 2014, I had never seen a stitch of Java in my life (but I had done object-oriented {O-O} design and programming in 3 other languages). Being unemployed at the time, I justified my modding effort as a learning experience for both Java and Eclipse (see my signature). It took me almost two weeks to write and debug my 1st basic mod (a new gem for the nether with tools and armor to suit). I blame conflicting tutorials and the jump from 1.6.4 to 1.7.2. If nothing else, then get this: 1) Eclipse is your friend, especially when you use it to jump (visually) into the vanilla code referenced by your mod (you really want to have setup a "decomp" workspace). 2) The debugger is also your friend, because it lets you see what is REALLY happening (no more guesswork!). I so deeply wish that every new modder would set break points and fire up the debugger before posting his/her 1st runtime "doesn't work" thread. However, if one is new to more than Java... If one is not familiar with O-O design, then there is much more to learn. Java is merely a tool like many other tools (though reflection was new to me when I arrived). If you've already mastered O-O design in one or more other languages, then the basics of Java are a snap. On the other hand, O-O design is a paradigm -- a kick-in-the-head, counter-intuitive thought process that is best acquired via mentoring (e.g. junior-college or better class with a good teacher/professor, or a real programming job with a good tech lead). If O-O design and coding (e.g. inheritance and run-time polymorphism) are new to you, then get help. Sign up for a class, or ask your boss for a mentor, and (to the reader finding this thread in the future) come back in a few months.

You're down to the level of the debugger. Set breaks and see what's really happening.