jabelar

Actually a specific question was not asked. You assumed what "loaded" meant, and I gave them options to choose from. Most people asking about "loaded" have something in mind, and based on the further conversation on this thread, the original poster did not in fact understand that the FML events indicated the state of the various mods loading. In fact there is a FMLLoadCompleteEvent, although I'm not sure it registers to a general event bus or not. But the LoaderState has an enum of AVAILABLE when all modes are loaded. I'd like to also add that you can (mostly) control the order of the mod loading using the @Mod annotation attribute dependencies = "after:FileName". I think you can specify that your mod loads after all, but of course if multiple mods did that then I'm not sure you could be fully sure. But anyway, in the post init, if you made your mod load last, you could be pretty confident that all the mods had done their loading.

Yes, sort of. The FML lifecycle events are for this. First all the mods go thorugh pre-init, then through init, and then through post-init. So in the init handler you can be confident that all mods have gone through their pre-init, and so forth. I think by the time you get to the server started event you can be sure that they are all loaded. Anyway play with the FML life cycle events. I describe them a bit in my events tutorial: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html

During launcher I'm getting the following error, which is new after upgrading to latest version 1217 This seems to be just related to upgrading, as I don't think I've seen that before. It is pretty early in the launcher so not sure that my code would be affecting it anyway at that point. Plus it says "it should be impossible"! [EDIT] Looks like this is a known issue, ignore it for now: https://github.com/MinecraftForge/FML/issues/519

After upgrading to latest release 1217, I find that the console messages are now much more verbose and frankly a bit annoyingly so. I use System.out.println() a lot for debugging, and now every line has something like this: [21:25:35] [Client thread/INFO] [sTDOUT]: [com.blogspot.jabelarminecraft.magicbeans.MagicBeansEventHandler:onEvent:187]: before the actual output! This is annoying because it now sometimes scrolls off side of my console window. Is there any way to reduce how much context is output along with the standard output to console?

Well, the association of the texture with the entity happens in the renderer class. For example RenderCow class sets the cowTextures ResourceLocation to be ResourceLocation("textures/entity/cow/cow.png"). The problems are that: a) each render class is different and they don't all have consistent fields or methods for the textures. b) the texture resource location field and methods are private and protected respectively. So I think your best bet is to change the renderer mapping by editing the RenderManager.inistance.entityRenderMap directly to replace the renderers with custom renderers. The safe way to do this is with the rendering registry. I just tried it out and it works pretty well, but it does mean you need to make a custom renderer class for each texture you want to associate: You need to put something like this in your client proxy class. RenderingRegistry.registerEntityRenderingHandler(EntityCow.class, new RenderCowMagicBeans(new ModelCow(), 0.7F)); In this case, I made a RenderCowMagicBeans class that looks like this: public class RenderCowMagicBeans extends RenderLiving { private ResourceLocation cowMagicBeansTexture; /** * @param parModelBase * @param parShadowSize */ public RenderCowMagicBeans(ModelBase parModelBase, float parShadowSize) { super(parModelBase, parShadowSize); setEntityTexture(); } protected void setEntityTexture() { cowMagicBeansTexture = new ResourceLocation(MagicBeans.MODID+":textures/entities/cow_magic_beans.png"); } @Override protected ResourceLocation getEntityTexture(Entity par1Entity) { return cowMagicBeansTexture; } } The new texture I pointed to was used for all entity cows.

Anything visual is considered "rendering". There are several render events that may help you. Such as the RenderGameOverlay event. You could also possibly use a fog effect to make cool distorition -- this might make sense for gas. You can create colored fog with the FogDensity and FogColor events. If you want to know more about event handling generally, you can look at my tutorial here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html At the end of that tutorial I have an example where I used the FogDensity event to create a basic fog effect (in my case I made the fog thicker as person flew into cloud level, but you could change the logic to make fog density based on your gas effect).

That is pretty much what I'm asking -- should I go ahead and do that, or am I missing something about the villager registry that would be easier? I'm pretty good at custom entities, but I know very little about villages and villager modding...

It is probably the /* line. If you're running it from main folder it would pick up all folders. I guess I run mine one folder lower than you do. Anyway, just play around with the gitignore to suit your folder structure. My point is that in addition to source most people recommend including the gradle stuff. It really is a nice way to clone the full build context.

As diesieben07 says, the problem is that the built-in container system uses an item stack directly and item stacks are limited to 64. But since this is Java you can make your own kind of container that keeps track of the quantities in a custom field. I'm not sure what you specifically wanted to do with this container, but generically you'd have to make sure you can display the quantity correctly (so you'd have to make your own rendering using item icon plus quantity based on your field) and you'd have to replicate the methods for moving things into and out of slots but base it on the custom quantity field instead of the item stack size. You may also have trouble in how you drop items and how player can get them. Basically you'll have to break up the stacks into 64-max stacks. Like if you had a custom slot with 100 quantity in it, if the player took that then you'd have to give them a stack of 64 and a stack of 36. It is basically a lot of coding to do, so I'd personally only tackle it if you are both a strong programmer and you really, really want this.

The important thing is your build.gradle file. That is what gradle uses to figure out what to put in the build, and also depends on your file organization. What does your build.gradle file look like? What does your asset directory structure look like?

I suggest you start out really simple. Figure out how to just make a custom block, a custom item, a custom entity, a custom crafting recipe, etc. Learn how to publish your mod (hint you have to build it with gradlew build). Learn Java well! You can't use an API from another mod without knowing a fair bit about Java. Learn to use your IDE (Eclipse) well! It is your "friend" to help follow the code to understand how the Forge, FML and Minecraft codebases work.

You mean your EntityConstructing event registration? That is the right bus to register, however one thing to know about that event is that it is fired before the constructor of the related entity is executed so many fields in the entity may not yet be initialized depending on how you coded it. Can you post your code you have now showing the event handler method now (with console print statements, and I assume you also updated it for WorldSaveData)?

I used to just do the source but then several experts explained that was wrong. They were right -- the gradle stuff is not very big but contains everything to recreate the entire environment. Regarding excluding eclipse folder, yes, do you know how the gitignore works? If you look at my example above I don't exclude that from being ignored (which means it is ignored). The eclipse folder gets recreated by the gradlew eclipse command.

Assuming you're using 1.7.x then you should put everything into the repo that is sufficient to rebuild the entire mod. So you include some of the gradle stuff. My gitignore looks like this: $ cat .gitignore /* !/src !build.gradle !*.project !/gradle !gradlew !gradlew.bat Then this can be downloaded/cloned onto any other computer and just run the gradlew setupDecompWorkspace and the gradlew eclipse commands and you'll have same modding environment ready to go.

Okay, I understand generally how to make a villager profession, or add merchant "recipes", however I want my villager to work a bit different -- the trade needs to depend on some other conditions. Furthermore I want my villager to have a custom skin. It is not clear to me that I can use the regular villager registry for such custom operation. The registry seems to be about adding and modifying merchant recipes, but not about registering a custom villager class. I can create a custom villager entity easily enough, either as an extension of vanilla villager or as implementing the merchant interface. But again I don't see how to add this as another actual villager handled like vanilla villagers. I don't mind doing it totally separately from villager registry, but I'm wondering if I'm missing something. I want to (a) create a new profession, which I can do, (b) add new merchant recipes for the profession, which I can do, © have that profession use a custom villager class -- this is what I don't know how to do. Thanks! Aaron

In all programming, programmers break their problem down into little pieces and solve them one at a time. Of course you need to make sure you're on the right track in the first place so I guess it is okay to ask for some helps on the general approach. However, it is still best to try to figure it out yourself first. For example, you will need a power source block. How would you try to make a power source block? Come up with some ideas, try a few things, post your code and we'll help you on next step. We also don't know how you want your idea to work -- like for power source do you want it always on, or does it need fuel, or does it need to be activated somehow? Are all power sources the same strength? Can they be combined to make stronger supply? These details are important.

Well, every structure is different, so you pretty much have to figure out a way that makes sense for you. A structure is simply just setting a bunch of blocks in the world. They can get large fast though, because even a 20 x 20 x 20 structure is 8000 possible block locations! If your structures are regular then you can use loops. Like a wall can just be a loop of setting blocks in the correct positions. If your structures are not regular, then you need some sort of map or template. I use text files with information that is basically a 3-d array of blocks. I read in the file into an array and then loop through that, placing each block indicated in the file. Randomness is just a matter of Java programming. In your generation code just test random number and build different things. If you're trying to make a dungeon or something, there are some open source programs (not necessarily Minecraft, just need any dungeon map code) and you can convert that to Java and Minecraft. Overall though your structures are different than other peoples so there is no good way to generalize a tutorial. Making a fleet of viking boats (I saw one guy doing this, it was cool) is different than generating a maze.

So that diesieben07 doesn't lose patience... here is some more info To make a crafting table (or anvil, inventory, chest, etc.) you will have a custom Container class associated with your custom Block. In that container, you should be using Slots. So you have Slot instances associated with your container. If you want custom behavior in the slot, like in this case updating damage on item removed from the slot, then you'll need a custom Slot class. So make a custom Slot that extends vanilla Slot and change the method mentioned for pickup item. Then in your container instance use the custom slots. So custom block should use custom container that uses custom slots.

Yeah, there are a lot of things available before you need to do base class modification. 1) public fields, methods, registries. You can do things like entirely change a mob's AI because the AI list is public, you can break blocks, set them on fire, etc., 2) you can replace the vanilla items with custom classes that extend them and have the additional code you need. 3) you can use events to intercept and replace many behaviors that are of common interest to modders. 4) you can use Java reflection, giving you access to otherwise private fields and methods. 5) you can use access transformers What are you trying to achieve that can't be done with the above?

Actually, did you know you can see the regular console output when playing Minecraft? there is a tab on the launcher called Game Output. So you can see your System.out.println() output even for deployed mod.

Well, it is standard Java so you can use the Logger class and I think you can get the mod logger instance with something like this (in your proxy or main class): public static Logger logger; @EventHandler public void preInit(FMLPreInitializationEvent event) { logger = event.getModLog(); } If you just mean to the console though, for that you use System.out.println("whatever you want to send");

As mentioned, there are various events that are related to creating world, loading chunks, etc. In my tips on blocks tutorial, I have an example where I use the PopulateChunkEvent to replace all blocks with different block. You could use same code but just delete the block without replacing it. See tutorial here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-modding-quick-tips.html

I think that is a legitimate way to do it. Basically what you wanted was more like a structure or as you said the cactus. If you think about it, world generation is a collection of quite different generations. You generate bedrock, carve caves, contour the landscape, add plants, ores, villages. Each is a very different algorithm of generation. If you want something custom, then you would do it yourself. There isn't (as far as I know) a generic "generate my pattern" method.

by the way, the hash check error was a known bug with one of the last releases of the 1.6.4. Anyway, part of the solution is definitely to use latest (1.7.10) so glad you went that way.

That is weird. It does seem like your code should be correct. I don't have time to check it out now, but will see if my own entities with similar wolf-like AI have trouble swimming. I think they do okay, but will check.