Mazetar

Minalien has a great tutorial for that: http://minalien.com/tutorial-multi-block-structures-in-minecraft/

I would go into the file mentioned and find line 54, and see what the fuck "func_111121_a" is doing. Since you are working with an entity is it possible that you are trying to set a variable you don't have access to? Maybe you are reducing it's current health by adjusting it's health value directly or something similar? You could also try to run in debugg mode, get ready to dmg you're mob and tab to the IDE, set a breakpoint on the mentioned line and place, then dmg the mob and see how the code looks like when it hits the break point? For me it seems that you are trying to change a value you aren't supposed to change, there may be a method you need to invoke instead of changing a variable directly or something to that effect?

I guess that would be by doing it all by yourself? code a generation sequence which you run after/insteadof the original one for the selected area(s)?

As far as I have heard on twitter and here, the system ain't working as intended yet. I'd wait for the next recommended update before trying to make everything work

http://www.minecraftforum.net/topic/1878002-161forgeupdating-to-161-texturesinitialization/

Forge is not yet at it's recommended build, maybe it will be at the beginning of next week according to what's been said. Forge builds do not change the deofbfuscated names, that is MCP and their mappings. So there we just have to wait some. Luckly names are easy to fix and change so no worries. So 1.6.X is NOT stable yet and wont be for a least a few days. Which you could see since there's no recommended build and the release thread for forge for 1.6.X clearly states this

update to FORGE 768 OR LATER http://www.minecraftforum.net/topic/1878002-161forgeupdating-to-161-texturesinitialization/ or wait for recommended build

It's not a stable recommended release yet, they are still working on stuff so things will still change There's no answer as things aren't done yet, which ya knew when downloading the builds and hence the answer:

I believe he means the one currently on the wiki the one for textures 1.5.x

Replace all three with @EventHandler. Leave everything else alone. Just to make it more clear, with everything he means the parameter inputs as well, so don't change them either!

I'd suggest waiting then, if things don't work out. This is not a recommended release yet. And about documentation, well you got javadocs and the commit log that's it I guess. That's not perfect but it's better than you can find many other places. As a programmer you will need to learn not only to write documentation, but to study old code which has no such thing Consider it a learning exercise or wait a week for the dust to settle

if it's the installer files, can't you just open them yourself? and for the forge it's all on github.

I have learned to respect lex and I try to follow what he says, tough most is above my skill Anyways it's so early in the development of this forge version and much is speculations instead of facts here on the boards. I guess one should go read the github commitments and code changes along with some re-reading of the src code to understand more. Or one could wait for the dust to settle and use the time between to fix other stuff for the projects one is working on

Well that means there are far better ways to do this and that this way might break at a later build.

Then he must have changed more than he said between the screenshots then, since it shows the texture working in the first and not the second one?

Wouldn't that seem like that means they need to be setup during the pre-init and be ready Before the init method or else they will not be loaded in time for the methods which depend on them to make use of them? Sounds like a simple solution, load them in the place they should and all is fine?

Heh yeah, time to read the update notes Minecraft is changing texture system again, this time to resource packs. Haven't looked into how it's done yet tough

There's a local server even when you are playing on SSP, so there's a server and a client anyways

I'm pretty sure that's about as non-rude as I could get.. And I also gave you the link which would answer your questions I believe? If they didn't work, then why not mention what you tried and what failed, and since it's not within the scope of this board to do java basics why not use stackexchange or some other page which is made around dealing with basic/general java/programming questions? The method in one of the top links using writer works I have used it before in some of my programs. And this from another of the top hits also works fine: http://www.java-examples.com/write-int-file-using-dataoutputstream If you can't get them to work I suggest you open a new project and try to just get this function to work as you wish, then do the reading part as well, after that you should be able to open your modding project and do the same there

Wouldnt getServer() return null when used upon client side? That would explain the error at least in theory.

2013-07-01 21:13:02 [iNFO] [sTDERR] java.lang.NullPointerException 2013-07-01 21:13:02 [iNFO] [sTDERR] at com.dark2222.core.handlers.ServerTickHandler.tickEnd(ServerTickHandler.java:48) There is the problem right there, NPE at that packaged name, That file name, that method (filename.java: lineNumber) Go to the specified line and see what is happening there, set a Breakpoint and see wtf is "null" in value when used. Then you have solved most of it already.

Seriously go learn Java!!! Or at least learn to google basic java questions.. This has little to do with the forge API and is purely a Java question, a basic such as well.. Here ya go anyways [lmgtfy=save int to file java]Saving ints to file[/lmgtfy]

What if you change the velocity? to me it seems like the correct way is being used.

Inside Minecraft.java you will find the above mentioned field it contains whatever the player is looking towards which is within his range. You will understand once you see the field and what info it contains. Also you may want to open it's call hierarchy and see the get function for it to see how it's made As long as you got access to a player object, you can find out which item he is holding by a simple method call, you will find this inside the player's class. As long as you can get the player object then sure. Since you are already on client side, you can use the Minecraft.java's thePlayer field to get the player object.

Judging by his first post and his signature that's my best guess. It's a cool learning project I guess But Vinz243: If I understood your question correctly then you can look at how the bat file was written. But to be honest I don't see why you can't make you're program run the .bat file and then proceed after it's done?