jabelar

i have to use event handler right? you know any good tutorials? and do i use it to call my class instead? My tutorial on events might help: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html Basic idea is that you need a handler class that "subscribes" to the event, and you need to register that class as a handler. When the event occurs, you can use the data passed in the event parameter to further determine what happened then do whatever you want. Depending on the event, many are cancelable, meaning you can totally override what the vanilla code does.

Okay, I generally follow this tutorial: http://www.minecraftforge.net/wiki/How_to_make_an_advanced_configuration_file You'll see in the "Basic Property Creation and Usage" section that there are advanced methods where you can specify the category when accessing the property, and I think you just need to create your custom ConfigCategory instance prior to using those methods. Not certain but something like: String myCategoryName = "myCategory"; ConfigCategory myConfigCategory = new ConfigCategory(myCategoryName); boolean isThisTrue = config.get(myCategoryName, "IsThisTrue", true).getBoolean(true);

No, I mean you literally should not use it, ever. It's a marker interface by forge that results in the merging process of Client & Server. We get 2 jar files from Mojang, the client & the server. Both contain roughly the same things, but the client has a whole lot more things and the server has some things too that the client have. The decompilation process merges these two jars into one universal codebase, so that you can make only one mod jar that works on client & server. @SideOnly is a marker for you that tells you "oh, this class / method / field only exists in the Server / Client jar file". That means you can only use such a class / method / field only with care, because it doesn't always exist. I understand that, but don't see how you can say "never". If I extend a class and override a method that is already SideOnly, don't I have to also be SideOnly in my overriding method? Yes you shouldn't create your own sided stuff, but if you're calling, extending, or copying stuff that is already sided don't you have to follow that?

I strongly recommend using SourceTree. It is a free client that helps manage git on either Windows or Mac. You should choose to use the "embedded" version of git (meaning it will set up git for you). A lot of people, and I expect someone here will answer the same, will say "git isn't so hard, just do it from command line" but honestly it can be a bit tricky figuring it out. Why not use a graphical client that handles it for you? Anyway, I use it on Windows and like it a lot and recommend it to anyone who is a casual coder. I haven't tried it on Mac, but it seems to be available.

Post exactly what you would like to do and what code you've tried so far. It is difficult to help with general questions, because my answer to your current question is "just create custom categories and use them". Anyway, the one general hint I'd give is look at the Configuration class and look at all the public methods. You'll see some things there that might be related to your interest.

He already said he used that tutorial... I used it and it worked fine for me. However, it is a good suggestion from WorldsEnder to look at how Forge uses it itself for its own options.

ok, why should I never use @SideOnly? I know not for mobs I just checked my code, do you mean never for the entire mod or just the mob stuff? He means (I think) that you should only use it when absolutely necessary, which should be infrequent. Technically Minecraft and Forge could have let all classes be loaded on both sides (and just not call them when not needed) but as an optimization decided that server doesn't need to load classes related to GUI and user input stuff so used the SideOnly. Therefore any code of ours that depends on classes with SideOnly technically also need to be SideOnly too, so it is sometimes needed. It is common modding practice to move as much of that as you can into your sided proxy -- like registering renderers -- since this is major reason that we do the proxy stuff in the first place. In other words you can put the functionality into the proxy and don't need SideOnly annotation because the proxy is already sided. Otherwise you shouldn't create new hierarchies that are sided, since there really isn't that much use in the optimization of hiding a few classes. Certainly you may still need to run code on only one side, but can just check for the side using world.isRemote instead. Basically the SideOnly creates "weird" sets of classes that you have to manage and it is normally unnecessary. It is not outright wrong, just troublesome. At least I think that is part of diesieben07's aversion to it.

That sort of thing usually indicates some sort of static field or method is involved. However, I can't see any problem when quickly looking at your code -- it seems you're just extending the standard EntityTameable functionality for sitting. And you don't have any static fields or methods that would mess you up. One thing I've never liked about the sitting is that the AI sitting field is private so you need another field in the entity and have to keep them synced -- it would be better to simply have a getter in the sitting AI class. However, that isn't your problem here either. I don't see any static fields or methods in your code that could cause trouble. So the next idea might be related to client-server syncing. The isSitting field is (in EntityTameable) stored in the datawatcher which should sync automatically. Are you doing anything weird to separately sync the fields of your entity? Or are you using the datawatcher yourself?

I really don't understand how that could be a server-side only mod. If you have a custom entity that the client can see (in disguise) at some point a client has to render it and furthermore won't there be trouble when the server tries to send packets about the entity to the client (which it normally does for all entities) if the client doesn't have the same custom entity class?. Any custom entity created on server would need to be rendered on the client. Or maybe I don't understand what you're saying you're doing -- right now it sounds like you're placing a custom entity that is rendered with a disguise. Or are you placing an actual block on the server from an invisible entity?

Not sure but it is possible that in KeyInputEvent handler you could check for mouse buttons and cancel the event. Not sure that canceling will cancel built-in keybindings but I suspect is might.

Where's your GUI factory class? Can you show all your code related to configruation? You should have an annotation in your main class pointing to the GUI factory class as well. Also, you say you do it but don't show your proxy call to the init() where you pass the file location. Coding is all about the details so need to see all related code to help you.

I followed same tutorial and it works great for me. You can see the config button is active, and below you can see that the config is actually editable if I click that button:

Yes. If you use a get method like getBoolean() it will just get a boolean value which you can't of course use to set, but if you use the get() method you get the Property from the file and from that you can further set it. Note that you're asking about this because you want users to be able to change the config options, you should consider the new Forge config GUI functionality. Basically it creates a standardized options setting interface. There is tutorial here: http://minalien.com/minecraft-forge-feature-spotlight-config-guis/

I don't think it can be server side only, or at least it would be extremely difficult. The client is aware of the player, and is also does all the rendering (i.e. the "disguise" part). Even if you made a new entity, the client would have to have the mod for that entity. Anything that requires displaying something different would need client-side.

Do you mean naturally generate in village (like on the ground around the village), or in the village garden areas? I think for the village garden areas you might want to create a village "component" which I think would extend StructureComponent. I don't know much about village generation, although there is a 1.6.4 tutorial for adding a structure to the village generation: http://www.planetminecraft.com/blog/modding-trouble---adding-village-components-forge-164/. An alternative approach might be to look for farms that are generated and then replace them with your blocks. Basically after world generation (use event to detect) you could search for all plots of sugarcane and replace them with your plant.

Yeah, I was going to suggest similar. The question is whether you want to speed up the decay (meaning still go through all the stages of decay) or just you want to remove them faster. But the trick seems to be that the decay level seems to be controlled by a package-private int array (called field_150128_a in 1.7.10). I can't quite understand how the array works (kinda hurt my head) but I would guess that it is a map to the decay levels. I'm not sure why they didn't use metadata, or maybe they did but my guess is wrong, but probably because they wanted breaking leaves and decaying leaves to be different. Anyway that field seems to hold the decay values in some sort of "map". So I think to speed up the decay you'd have to access that field. Because it is non-static I think you can use Java reflection to access it. Just some thoughts based on my quick look at the BlockLeaves class.

No, he means have you written any code yet to try to accomplish this: disguise the player as an entity as a block. People aren't inclined to help if you haven't already tried. Why are you asking us? How do you think you'd disguise the player? At least tell people what you've tried, or tell them what you think might work, otherwise your question sounds like "write my mod for me". It's not just about being lazy, you really need to struggle through the thought process yourself if you want to really get good at modding. So, here are some questions to figure out for yourself: - what code controls how the player looks? - how do you think you can intercept that code to modify it?

That makes sense and is the way I do structures. However, it seems that the point of his mod is to have worker entities do the building step by step over time depending on available resources. So it may be more complicated then just looping through and placing the blocks (which is normally a great way to do structures as long as you want the whole structure to instantly appear).

The bounding box is set by the setSize() method but that is protected so not accessible from different package. However, the setSize() just updates the boundingBox (which has maxX, maxY, etc. fields). The bounding box is public, so theoretically you can access it directly, but it is also final so I'm not sure if it is editable after it is is initialized (my Java knowledge on this is a bit sketchy). I've heard that you can only change a final field in the constructor, but the Entity class sets it to all 0s in the constructor so I don't really understand how classes that extend it can change it later, but I guess they also do it in the constructor. Anyway, you should see if you can change the boundingBox directly, but I suspect you can't unless you're doing it in the constructor of a class that extends Entity. So I think the answer is to use Java reflection. I think it should work because it is a non-static field, and I believe final fields are editable with reflection if they are non-static. So try that. Reflection isn't really that hard to do.

Another thing. In your crop block class you need to @Override the getIcon() method. Something like this (this is copied from BlockPotato. The iIcon array should be whatever you use in your class to store the registered icons. /** * Gets the block's texture. Args: side, meta */ @Override @SideOnly(Side.CLIENT) public IIcon getIcon(int parSide, int parGrowthStage) { if (parGrowthStage < 7) { if (parGrowthStage == 6) { parGrowthStage = 5; } return iIcon[parGrowthStage >> 1]; } else { return iIcon[3]; } }

Yes, the keybinding will have the state, but the "sad" thing is you'll have to check it every tick if you need to respond to it continuously. (Until diesieben07s fix to the KeyInputEvent is in place.) To the OP, for now you need to have some method or handler that runs every tick and then do what CoolAlias said to check keybinding key state and maybe store the value in a boolean for use in your code.

I'm not sure but I suspect it is because when you use an array you are pointing to an explicit memory location which doesnt care that it was previously null. But I think with for-each the screens that are passed are null pointers which cause trouble to the iteration. I've run into this before with Java. For example if you do this: Block myBlock - null; ItemSeed mySeed = new ItemSeed(myBlock); myBlock = new BlockPotato; The ItemSeed will never get updated with the potato because it was originally told to point to null. Not sure if that is your problem, but it seems similar. If you init to null it isn't clear that there is any pointer to use in certain situations later. I think the explicit array index call in your for loop ensures you're pointing to allocated memory, but I think the screen iterator in the for-each just keeps pointing to null (i.e. not allocated space). Or maybe I'm totally wrong...

I'm debugging a texture problem that appeared in my mod and noticed something. It is a crop block that extends BlockBush and I @Override the registerBlockIcons() function. The code is simply: @Override @SideOnly(Side.CLIENT) public void registerBlockIcons(IIconRegister parIIconRegister) { // DEBUG System.out.println("Block Tomato registerBlockIcons()"); this.iIcon = new IIcon[8]; // seems that crops like to have 8 growth icons, but okay to repeat actual texture if you want this.iIcon[0] = parIIconRegister.registerIcon("recipeplus:tomatoes_stage_0"); this.iIcon[1] = parIIconRegister.registerIcon("recipeplus:tomatoes_stage_0"); this.iIcon[2] = parIIconRegister.registerIcon("recipeplus:tomatoes_stage_1"); this.iIcon[3] = parIIconRegister.registerIcon("recipeplus:tomatoes_stage_1"); this.iIcon[4] = parIIconRegister.registerIcon("recipeplus:tomatoes_stage_2"); this.iIcon[5] = parIIconRegister.registerIcon("recipeplus:tomatoes_stage_2"); this.iIcon[6] = parIIconRegister.registerIcon("recipeplus:tomatoes_stage_3"); this.iIcon[7] = parIIconRegister.registerIcon("recipeplus:tomatoes_stage_3"); } } Anyway, the weird thing is that the console statement prints out three times during Forge start up. Here is console log: The method is client side only so this isn't duplicate on server side. I checked the call hierarchy for the registerIcons() method and it is only called by TextureMap's registerIcons() method. Does anyone know why the TextureMap is calling registerIcons() multiple times (or why there are multiple texture maps)? Is it because there are TextureMap for different resolutions of textures? Note that I'm sure that there is only one instance in my mod of blockTomato, as I checked for all calls to the constructor and only instantiate it once (as expected).

I don't think you need to worry much about efficiency if it is something that is only done occasionally. In terms of it looking more even, that is a matter of adjusting the round-off in mapping to the block positions. I think maybe adding 0.5 to the x, y, and z might make it more even. In otherwords imaging drawing a perfect circle on some graph paper. You need the center of that perfect circle to be in the center of the center block. If it is at one edge then the outer edges will have aliasing irregularities versus the opposite side.

There are several places in the code where the structure of the if statements don't make much logical sense. For example you set it to air and then immediately test if it is grass (which can never be true at that point). Then you test for building type which might change the block type to some sort of "entity type" (whatever that is) and then you test for the block type (usually you'd just continue with the code that handles the case), then you test if it is 999 which it could never be because it can only be air or that entity type (unless that could be 999) and so on. Anyway, the way to debug these type of things is very easy. Just put a console statement (System.out.println("something useful")) at each point in the logic where the console statement is something useful. Like before each if statement print out the condition you're testing so you can see if it is true or false, and after each time you change the blockID print it out. It should be quickly obvious where things are going wrong.