The main reason I say do not learn by making a mod is that when things go wrong or don't work (which will inevitably happen), how will you know whether it is a java issue or a modding issue? So you will ask here and just get told to "go learn Java".
You NEED to be able to read and understand exceptions and be able to debug your own code.
When there is no exception, but it isn't doing what you expected, that is when you come and ask us for assistance.
The people on this forum assume that the person they are helping has java knowledge, so understands what they are telling them to do without writing the code for them.
i starting watching lessons from Stanford university, I'm surprised at how simular it is to minecraft commandblocks using scoreboards with commands, tellraw. and trigger boards etc. at first i felt like what i was learning had no connection to minecraft but I'm starting to see connections. this is the playlist I'm using the following video
I find it to be easy to fallow and somewhat entertaining. i don't know what I'm going to get out of it yet because I'm not finished. but i think when all is said and done i think its an awesome way to learn java. in the first video he does a really good job of explaining why we cant just jump into making programs (in my case mods) because i need to understand the language first
his example "writing code is just like writing an essay. you cant be a good essay writing, without learning the language you want to write in. if you don't learn English, you cant be a good English essay writer. if you don'T know java (or another coding language) you cant write good code"
i had never looked at it that way before i saw the video, and i use to always want to skip java because in my mind. i was thinking "i don't want to learn java, i want to learn forge" but now i kinda understand why learning java is so important first.
watching the video also teaches good coding habits i have better foundation as a future coder because of good habits that im setting for myself
1
Override onBlockActivated in your custom block to check for your structure, and if it is valid, open a gui.
1
ModelLoader.setCustomModelResourceLocation takes the same arguments, must be called in preInit.
1
That's a problem. Both client AND server need to know what your blocks are.
Move the call to init() to your common proxy
1
This will crash the server. Minecraft.class is client-only. If you want to alert nearby players that the entity spawned, use World#getEntitiesWithinAABB(EntityPlayer.class, entity.boundingBox.expand(RANGE, RANGE, RANGE) and iterate through that list of players.
1
I have this old method you can use:
If you want to get the first air block from below, just switch a few things around:
Feel free to use these and modify them for your purposes. If you do use them, make sure to check that y is indeed between 0 and 255 before doing anything.
1
Well... you could have one call the other. I don't think it would cause any looping or anything terrible.
1
The Item class has a method for getting the player's look vector. Call this from onItemRightClick before returning an ActionResult.
Then check that it hit a block like this:
I do not know if this works flawlessly for blocks that do not have a selection box -- specifically air, fire, etc. In your case, detecting clicking on fire is very important. You may want to set hitPos to rtr.getBlockPos().offset(rtr.sideHit, 1) and see how that works.
1
The mod author of Mo' Creatures is very private about their code and mods, so that specific mod may not be a good example. My best guess is that it will take changes to every single class (if nothing else, organizing imports). Also MOC adds a dimension, and my dimension-adding mod took a bit of a beating in the 1.8.x -> 1.9 update.
My Extra Golems mod is comparable, though, since it mainly adds Entities. It did not take much effort to update from 1.8 -> 1.8.9 -> 1.9 -> 1.9.4 -> 1.10. The only major changes were my adding of new features and re-doing code that was using methods of a different name or methods that had been removed or deprecated. (deprecated = marked for removal in next release)
The 1.9 update, though, required a lot of method signatures to include an EnumHand argument and some returned an ActionResult instead of a boolean as before. Also in 1.9.4 the class everyone was using for translation was deprecated and its replacement was a bit tricky to find.
The 1.7.10 -> 1.8.x update, as you've no doubt heard, was also very tough. Blocks had to be redone to use IBlockState and Property things instead of direct integer metadata. Entity rendering had to be redone from this to this. DataWatcher ids were replaced by a generic DataParameter somewhere between 1.8 and 1.9. And not all these changes took place in one version, which is helpful for me but not for the person trying to update by skipping several versions.
1
A few things:
- Items should be registered in preInit. I didn't know it even worked to try to register them in init
- You should be using ModelLoader.setCustomModelResourceLocation instead of Minecraft.getMinecraft().getRenderItem()...
- - the ModelLoader method should be called from preInit as well. It takes the same arguments.
- You should not be using LanguageRegistry
- - use the .lang file instead, adding an entry to translate the unlocalized name. See here for instructions.
1
Actually, looking at your writeToNBT, it doesn't look like you're writing the items tag to the main NBTTagCompound.
That would explain why it's not entering the for loop -- NBTTagCompound#getTagList returns an empty list if it does not find the tag compound.