Elyon

Interesting topic. You'll have to be a bit more specific about the kind of data, access and modification you require, though. There is no catch-all storage method.

Wonderful, thank you. How are we for importing current mappings?

Reflection or ASM, depending on your specific needs and your desired cross-mod compatibility.

You're assigning the field rather than comparing it. Use == .

For the current client: Minecraft.getMinecraft().thePlayer.capabilities.isCreativeMode fetch#Verb

Splendid work! However, I registered, but "something went wrong", and I never received my activation email. Is there any chance you could manually activate my account, or resend the activation email, or delete my user and resolve the issue I may have had?

As Zer0HD2 put, you'll want an instance of EntityPlayer . Fetch the capabilities field of this instance. Fetch the isCreativeMode field from the capabilities field.

A boolean would never work in an if -statement due to reasons? Please enlighten us

Why do you insist on using javac directly?

You are welcome, best of luck with your project

Normally, I would ask for an error log when you state you are getting an error. However, in this case that won't be necessary. I realise you want us to give you a break, and this is in no way meant personally ... but I am sad to say, you are making very basic mistakes in your code, and I suggest following Java Beginner tutorials from the first chapter. As for your code, most of it is coherent. This part has as many very basic errors as it has lines, though: for (int i = 0; i < this.color.length; ++i) { this.color[i] = iconRegister.registerIcon(BOW.MODID + ":" + this.getTextureName() + "_" + color[i]); this.color[i] = iconRegister.registerIcon(BOW.MODID + ":" + this.getTextureName() + "_" + color[i]); } You perform exactly the same operation twice, with the same result. You assign a new value to a final (constant) field. You assign the return value of IIconRegister#registerIcon - which is an object of type IIcon to a field of type String Furthermore, You never @Override any inherited methods You have plenty of import s you aren't using It is customary to have packages lowercase You never @Override or even implement getIcon You mention metadata not working, but not once do you set, get or use it Your block bounds are off for a slab You inherit from Block instead of leveraging the more fitting BlockSlab subclass Wherever on the forums you found the code, I suggest you stay away from that source. The errors and oversights I have mentioned here should guide you towards making a working Block - a BlockSlab even. Still, the very basic errors that you have failed to find - as well as your inability to parse the (unpasted) error log to solve the issues with the code - indicate that you are not exactly experienced as a programmer. As such, you might have further issues implementing a working Block. In that case, you are more than welcome to reply to this thread, and I will do my best to help and, if time permits, educate. I am sincerely sorry for coming off harsh. It was not my intention, but it is late and I cannot be bothered rewriting the post. I wish you the best of luck with your project, and feel free to post further issues for us to scrutinise

java.lang.StackOverflowError: Exception getting block type in world [snip] at refugeecraft.world.dimension.generators.WorldGenFalloutAsh.generate(WorldGenFalloutAsh.java:65) Line 65 of WorldGenFalloutAsh.java is not fit to handle Y-values above the height of the nether.

Is your RModBlocks.ashLayer.canPlaceBlockAt method fit to handle negative Y-values without trying to set or get them?

java.lang.NullPointerException at mhfc.heltrato.common.network.message.PacketAIMessageTest.handleTheClient(PacketAIMessageTest.java:37)

That is a nasty stack overflow trace. You risk yg + random.nextInt(4) - random.nextInt(4); being negative. There seems to be other issues with the code as well, but try making sure j1 is always in Z+.

The metadata works. Register your icons, and reference those registered icons in your getIcon @Override. To solve the issue of why your metadata isn't working, you're going to have to supply some code, though

Hmm, interesting issue, this. What does your test.network.PacketDispatcher class look like, and why not use the supplied SimpleNetworkWrapper instead?

Java hasn't changed that much - not the Java you need here, anyway; I fear for your sanity public static ItemFood extends Item doesn't make any sense, either; you have a class that extends another class, or you have a field of a specific class. Not both, the inheritance is inferred from the class definition (or declaration, but they're one and the same in Java). What you probably want is public static ItemModSoup porridge; , and then assign this field using the line you pasted earlier. Finally, we don't usually call classes or files "pages" - that terminology is usually reserved for pages in memory.

After digging around in various vanilla rendering classes, I figured out the issue: I needed to call RenderGlobal#updateRenderers before calling RenderGlobal#sortAndRender . I more or less consider the issue solved, but I will wait a few hours and see if I stumble upon any more clientside chunk rendering issues related to this thread before marking it [sOLVED].

There's a ComputerCraft 1.6 beta for 1.7.2. I would recommend developing a peripheral for that, instead

Casting new ItemModSoup() to ItemModSoup is moot, as an ItemModSoup is already returned. The second would be the way to go. Also, don't you mean to write porridge?

Nothing changed regarding the file structure since 1.7.2, I believe. How is your file structure different from the tutorials, and - assuming a sensible file structure - how is this a problem? If you're not sure the tutorials work for 1.7.10, why not give them a go and see if they do?

Ah, it seems I forgot to paste the code where I instantiate a new EntityCamera for use as renderViewEntity , as well as where I set that. Thanks for pointing that out! I have since moved some things around, still to the same effect, though: I instantiate a new clientside EntityCamera on line 60 of RenderCamera. EntityCamera is just a stub descendant of EntityLivingBase. Furthermore, before the call to RenderCamera#renderWorld , I made sure to set the Minecraft#renderViewEntity to this EntityCamera instance. After the call, I reset it. I have moved this getting and setting of Minecraft#renderViewEntity into RenderCamera#renderWorld, as can be seen in the updated paste from the paragraph above. As said, this whole setup works brilliantly so long as I use Minecraft#renderGlobal and Minecraft#theWorld , though - but that renders only the current dimension, not specifically the Nether. Thank you very much for your input, and my apologies for not having pasted the code where I instantiate and set a new renderViewEntity!

I went ahead and worked some more on clientside loading and rendering of chunks. This is the current modus operandi: Client adds block in overworld Server sends ChunkMessage to client Client parses chunk message, gets chunk from separate WorldClient, fills chunk with received data, and marks it for render update Client's RenderCamera calls renderWorld after setting up basic rendering stuff Separate RenderGlobal with the WorldClient from above calls sortAndRender Everything in that list seems to work by itself, according to numerous FMLLog#init calls, as well as the fact that using Minecraft's native RenderGlobal/WorldClient renders the overworld exactly as expected at the given coordinates. However, using a separate RenderGlobal/WorldClient (as initialized in RenderCamera#initialize, called in ChunkMessage.Handler#onMessage), populated as described above and seen in the ChunkMessage.Handler class, only the sky is rendered. Disabling the call to RenderGlobal#renderSky() for the separate RenderGlobal/WorldClient pair - which I have done in the pasted code already - leaves me with the result of having an absolutely transparent quad. As said, most if not all the items in the list work as expected on their own, and I suspect the issue is related to what happens between Chunk#fillChunk and RenderGlobal#sortAndRender. However, I cannot pinpoint why the sortAndRender call does not work for the separate RenderGlobal/WorldClient pair with the populated chunk data. I have been combing over the vanilla/forge classes to try gaining some insight into what I must do for these "fake" filled chunks to render, but so far, I have come up with nothing. Any input on the matter will be immensely appreciated. If there is any more info I should provide (there are no error logs as there are no errors), I will try my very best to do so. I cannot imagine how the issue could be found anywhere else than in the code I have posted, though. Thank you for your time!

Don't change vanilla source code. Use reflection/ASM to patch into classes at runtime, instead.