jabelar

Okay, the code you posted doesn't seem to have anything for double-height plants. So if you're getting texture problems you should fix those first. You need to confirm you have proper texture files with exactly the right names in the right asset location, and those files need to be properly recognized by Eclipse as part of your project. Can you show screen shot of your assets package structure and file names? For a double-height block it is probably best to create a separate block for the top part. So the bottom part will grow and then when it finishes growing it should place the top block on top of itself, then the top should grow. You can check if the block is finished growing in the incrementGrowStage() method of the bottom block, if the growthStage is >= 7 it is finished growing. Alternatively you can associate a tile entity with the bottom block and it can check to see about growing the top block.

You might want to try CoolAlias' tutorial on APIs: http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571434-tutorial-modding-with-apis

Okay, they are doing a kinda a complicated build.gradle that actually renames each one to mcmod.info during the build. Look at their build.gradle file. It has lines such as: rename ("lighting_mod.info", 'mcmod.info') When building code, you can pretty much navigate all sorts of folder structures. But I don't think doing it their way is necessary. But yeah if you want to mess around with the build.gradle you can pick up the files you need from any folder structure.

His code doesn't have a body. That isn't the problem. I think the problem is that for interfaces you don't need to declare scope -- it is automatically public. Secondly, you can't use static methods in interfaces in Java. So I think you should delete all the public scoping and static declarations. Instead something like: interface IBFMEntityElemental { void registerElemental(IBFMEntityElemental elemental) { } } Anyway, back to your earlier questions, how you develop your API depends on what you want to allow people to do with it. For example, a Java interface is useful for categorizing (like using instanceof to confirm that some class implements it). So imagine that you want to allow other modders to indicate that their entities should be treated specially by code in your mod. You can then provide an API for a Java interface called something like ISpecialEntity, and then in your code you can check for instanceof ISpecialEntity to find those that others have added the interface to. Alternatively, maybe you want to make sure you can get information about other modders' classes. For example maybe you have a werefwolf mod and you want other modders to make other were creatures and you will need to know whether they are in "were-form". Then you could make an API for a Java interface called something like IWerewolf that has a method called inWereForm(). The other modders that decide to extend IWerewolf would be reminded to implement the inWereForm() method so then your mod would be able to check them for the were state. However, an API can also contain classes and regular methods. Don't get confused and think that an API has to be Java interfaces only. For example, if you have a method in your mod called spawnCoolEntity() and you want to allow others to spawn them in their code then you could make that method an API. So it really depends if your API is proving access to functionality in your mod, or instead you're asking others to implement functionality that you can call on. What exactly are you making your API for? I think that in your case that registering an elemental would be an actual class method -- not an interface -- because the code for registering would be written by you. Other mods could call your registration method.

Great! Getting a version control system working is worth the effort. Once you're comfortable with it you'll wonder how you lived without it.

Anyway, in addition to the specific questions about your code, I think you should consider using the Fluids that are now implemented in Minecraft Forge. There is a whole bunch of functionality there that might be useful to your need. See this tutorial: http://www.minecraftforge.net/wiki/Create_a_Fluid

It is your code, so you can do what you want. I think it is good practice that if you are creating an API for others to use, that you also use it within your mod(s) because this helps ensure that it is correctly implemented and behaves identically to your own mod. Note that an API doesn't have to be a Java Interface. Even though the "I" in API means interface, interface is just a generic term regarding accessing code from other code. An API just means that you are presenting some public methods in an un-obfuscated (and ideally well documented) way so that other code can call it. From the error, it seems that you're trying to implement a Java interface. That is fine (an API can include Java interfaces). Can you post the whole code for your interface class?

That would have to be a problem either with the application or with your computer (although frankly creating the remote repository shouldn't tax most computers). I would search web for similar crashes. Maybe some other Mac users here have some suggestions. Sorry, but the app crashing isn't something I can really help with. The one thing I know is that in the release notes in previous fixes there were similar such issues. Possible work-around: I think you might want to try doing it the other way around. In my tutorial I have the hosted repository get created from SourceTree, but you can actually create it directly on github website first. So just go to the github web site and create a new repository (use name of your project folder). Then skip the step in my tutorial about creating the hosted repository and just add the repository as a remote (later step) to your local repository.

You mean SourceTree app crashes? At what point exactly? What kind of computer are you using (what OS and is it good performance)?

Sure, it wouldn't hurt. The thing is for me I use the repo mostly for private backup and tutorial examples, so I mostly care about the code and I don't usually collaborate. If I clone I likely still install a new Forge over top, and just preserve the source. I don't usually edit the wrapper in a unique way, so am not worried about re-creating it as needed. But still good idea for proper posterity.

I'm not sure that is the best way to organize mods that work together. I think you should have them all at same level in the workspace (each with own /src folder). Then to use them together they should have API that can be called from each other, and if any depend on others you should list them as dependencies (in the mcmod.info). How are you building the directory structure you have currently? It seems like it would be a problem to have the source all intermingled like that.

I suppose maybe in that same event you could instead check the item and see it has silk touch enchantment? Just a thought.

You don't set it in the GuiConfig, instead you set it in your configuration itself. At least by category, there are public methods in the Configuration class such as setCategoryRequiresWorldRestart() and setCategoryRequiresMcRestart(). Then by property, there are public methods in the Property class such as setRequiresWorldRestart() and setRequiresMcRestart(). So I think you can do all in GuiConfig, by category, or by property.

I agree, I do similar effect (although slightly different entries) in my gitignore: $ cat .gitignore /* !/src !build.gradle !*.project I would say the philosophy I use is that anything I edit directly I put in repo, anything that is built or referenced or pre-existing I don't.

There are a few event buses that all operate in Minecraft forge, with the primary ones being the ones you mentioned. Different events get fired on different buses, so it is quite likely that you need to register handlers for both (and maybe others like the ore gen or terrain gen, as well as the FML lifecycle events). Anyway, you can usually tell (there are couple exceptions) which event bus an event is fired on by looking at the package it comes from. Alternatively, you can use Eclipse or IntelliJ to trace the call hierarchy to confirm the post. I have a tutorial on events that may be of interest. It includes a list (and links to other lists) of the events and buses. http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html

Sorry for the delay, but I realized that there was a lot to write and so went ahead and wrote it up as a tutorial. Please check out the tutorial, and let me know if you have any trouble (I just wrote it, so probably could be improved): http://jabelarminecraft.blogspot.com/p/minecraft-forge-publishing-to-github.html

I'm away from my computer at the moment but will try to give some instructions in a couple hours. But for now you should install it with the option for embedded git otherwise you'll have to do a separate git install. You should sign up for a github account if you don't have one already.

I do think it is a lot easier to just do the block that you've got selected. There are multiple ways to detect the block that the player is looking at, but perhaps best there is actually an event called onDrawBlockHighlight where you could just record the block and then later handle the RenderPlayerHandEvent and call some rendering. However, I think it may actually be possible to do all blocks (at least that are close to player or in their FOV). I noticed that there is a public method called drawSelectionBox() in the RenderGlobal class. The interesting thing is you can pass your own moving position parameter into it, meaning that you don't have to just draw the box for what the player is looking at. So I think, not sure, you might be able to handle the REnderPlayerHandEvent and do a drawSelectionBox() kind of thing for each block around the player. Instead of the stock drawSelectionBox() you'd probably want to make your own (copying the code) where you check for lava and go red, etc. My point with the drawSelectionBox() is that it is easy example of how to find the block rendering cube within the rendered view. So then you could do other things, like instead of outline could blend in an overlay. I suspect performance might be an issue, but logically it could work I think. Maybe TheGreyGhost (expert in block rendering) could comment on whether this scheme might work: 1. Handle RenderPlayerHandEvent 2. Calculate moving object positions into enough directions to hit all blocks in close proximity (I think you would just go through array of blocks around player's position. For perf reasons, might not want to calculate these every tick, but maybe every couple ticks or something. 3. Pass the moving object positions to all a method similar to drawSelectionBox() which would find the cube and either outline it or blend over it based on other checks (for lava and water).

You shouldn't combine different questions in same thread. Anyway, there is an event called PotentialSpawns that you can handle. The event parameter will have a field called list that contains what it thinks it can spawn, and it also has x, y, and z for the position. You can edit the list in the handler. So you'd check the position and if it isn't good for your entity you'd edit the list to remove your entity (if it was in the list).

You can probably set it as a parameter to the command, but I just put it right in my build.gradle file. What does your build.gradle file look like? The whole point of the build.gradle file is to control how the build is done -- where the files are, where they go, etc.

Doesn't the build.gradle file do this for you? When I build I think the jar name is combination of the archiveBaseName plus the version, and I think the assetDir sets location it gets put in. So I've set all my jars from multiple mod projects to pop out in one directory in my workspace.

I think the point is that music files should just be sound assets and there is already a standard folder system for mod assets.

How have you organized your development workspace for "child" mods? Each mod, child or otherwise, should have its own project folder with its own mcmod.info. There shouldn't be any need to name them differently.

It is an event subscription, so needs to be in a class that is registered to the proper event bus. Interestingly, even though it is in the terraingen package, it seems to be fired on the regular EVENT_BUS. So in your init() method in your main class or common proxy, you want something like: MinecraftForge.EVENT_BUS.register(new yourClassWithEventHandlerMethods());

Yes, look at the ExtendedBlockStorage class that he is using. There are public methods for getExtBlockMetadata() and setExtBlockMetadata() so you can both test for metadata and set metadata.