jabelar

Looks like this issue is solved on release 1147.

Are you saying they already had GuiConfig class before, the IModGuiFactory interface, and the ConfigChangedEvent on the FML bus? This is new stuff, I'm pretty sure. I didn't see those events when I made a list of all Event subclasses on recent previous releases. You could of course make your own config GUI before, but this is now the official method for using that built-in "Options" button on the loading screen when you look at the list of mods. It automatically parses your config and creates the buttons, adds undo and restore to defaults, etc. Anyway, I just tried it and it works great. Took a mod that was already using a config file and now all the options are available in the mod list and when I change them they properly apply to the game when loaded.

Just wanted to let people know that the 1147 release of Forge includes a feature many of us have been waiting for -- that options button in the mod loader now works, with config GUI functionality. There is a tutorial here on it. I'm going to try it today, can't wait. http://minalien.com/minecraft-forge-feature-spotlight-config-guis/

If you look closely at your apply attributes method you are registering the attackDamage attribute in that method and you're also calling the super method which registers other attributes. So if you called the apply attributes method again there would be an error. So if you want to update attributes later, you should create different method called setAttributes() that doesn't include the lines that do registrations. Or if you only want to update the max health then create an setMaxHealthAttribute() method that only does that: public void setMaxHealthAttribute(double parMaxHealth) { maxHealth = parMaxHealth; System.out.println("Setting maxHealth attribute"); System.out.println("Before setting, maxHealth attribute = "+this.getEntityAttribute(SharedMonsterAttributes.maxHealth).getBaseValue()); this.getEntityAttribute(SharedMonsterAttributes.maxHealth).setBaseValue(maxHealth); System.out.println("After setting, maxHealth attribute = "+this.getEntityAttribute(SharedMonsterAttributes.maxHealth).getBaseValue()); } Honestly, what I'm trying to teach you is to go through your code line by line and "trace" what would happen. It should be very easy to see that if you get an error that says "already registered" and you go back to your code and see that you are in fact registering again, so fix it...

Okay, I tried this out and it works well. Subscribe to rendertick event on FML bus and used following method: @SubscribeEvent(priority=EventPriority.NORMAL, receiveCanceled=true) public void onEvent(RenderTickEvent event) { // DEBUG if (Minecraft.getMinecraft().ingameGUI.getChatGUI().getChatOpen()) { System.out.println("Chat is open"); } } And it printed "Chat is open" over and over on console when I either opened the command line with "/" or a chat with "T". It stopped printing to the console when I pressed ESC to get out of chat.

If you mean typing anything (including movement keys) then you can of course just use key input event handling. You might also be able to be clever and check for chat entry and exit, but might be a bit tough to ensure you're in sync with when it is actually in chat. I think the best way might be to detect when the chat gui is open. The GuiNewChat class has a public method called isChatOpen(). There is only one GuiNewChat instance per client (it is persistent because it has to keep track of all the previous chat entries) which can be retrieved with the public method called getChatGui() in the GuiIngame class. The GuiIngame class is extended by Forge and there seems to be one public instance in the Minecraft class. So...I think (haven't tried it) that you can use (only on client side!) Minecraft.getMinecraft().ingameGUI.getChatGUI().getChatOpen() to check if chat is being entered. It should be true when open. You could check it every tick I guess in some sort of tick method or event handler, or you could check during key input event to save some processing burden. EDIT: I just tried this and you have to use a tick handler -- key input events actually DON'T fire while chat interface is up.

Well Minecraft is just Java so anything you can do with video in Java you can potentially do. However, based on other discussions on the topic it seems it can be pretty difficult actually. Instead of video, I suggest you can easily do more of a slideshow. It is easy to create a GUI that pauses the game play and takes up the whole screen, displaying images of your choice. Not sure if that works for you, but a slideshow story is simple and would probably still be pretty cool. Another option is that you can fairly easily use Java to bring up an browser window, so you could have the cutscene on Youtube and then have that pop up in a new window. I know that isn't perfect, but again is simple and would get the job done. (Some people might not like having window pop up, so you might have to have option in your GUi where they click OK button to launch window, with option not to). Those were the best two solutions I've found to providing a story-like element to Minecraft.

Yes, of course that is how I find them (in Eclipse it is F4). But it is easier I think to have a list that already filters out the abstract ones (the problem encounterred by the person on this thread) and further organizes them by what bus to register on (as that is another common noob mistake). Plus in my list I am starting to link tutorials on interesting examples of uses for each one, and other comments as needed. Anyway, it could be said that most of the questions on this forum can be solved by following the code in Eclipse ...

I don't think you're thinking this through. To fix a problem you need to "trace" the execution of the code. Pretend you're the computer and execute your code. And use println statements to help you. Don't just experiment, that isn't the way to fix things. In this case, are you sure that the maxHealth isn't being changed to 0 when the loadNBT happens? Something in your code is changing maxHealth value to 0, and that is the only place in the code that changes that field. So look at that. Just make sure every line of code is doing what you expect by confirming with println. It should only take you about 3 minutes to figure this out if you trace the execution to the point where maxHealth is being changed to 0.

Diesieben07's somewhat cryptic remark means that you have to look at the extended events from PlayerUseItemEvent and find the one you want. There is actually these events available: PlayerUseItemEvent.Start PlayerUseItemEvent.Tick PlayerUseItemEvent.Finish PlayerUseItemEvent.Stop By the way, I know it is hard to figure out all the available events, and also you can get ideas from mods by learning all the available events so I've tried to compile a list in my tutorial, you might want to check it out: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html

Okay, what I believe is happening is that your loadNBT is being called and overwriting your maxHealth value in the properties class. Again, you can debug this stuff easily yourself if you put in console statements for every method. When I'm coding I seriously put in a System.out.println in every method so I can follow the execution to confirm it is correct. So please add statements in your properties class, in all of the constructor, the loadNBT, and the getMaxHealth methods. You should be very easily able to figure out where the problem is if you check the values at every point.

Okay, so it is obvious that the problem is that your maxHealth field is set to 0 at the point you're setting the attribute. You just need to figure out why. Can you post the full code for your class now since you've been editing it a bit? In the worst case, instead of using a field, you could just set the attribute directly to the value you want, but it would be good to understand why this is happening.

Okay, so you can see that it is actually setting max health to 0 at point where you're setting the attribute. Can you add debug statement so we can confirm that maxHealth is actually 0 at that point: Run it again and post the console output here. Please include the console output related to the constructor println statements I asked you to add earlier.

Like diesieben07 and brandon3055 mentioned you need to put your iterator into a field before you start the while loop. So then you're using the same iterator each time the loop tests for .hasNext(). Also I think the break statement in your loop is in the wrong place. Since I think you want to stop searching as soon as you find an entity, you want to break the while loop inside the if statement where you find the entity you are searching for. Basically there are two ways the while loop will end -- if it gets to end of list so there is no hasNext() or if it finds an entity that matches what you're looking for. Maybe like this:

You don't understand, at the point where you have this code: public BlocklingStats properties = BlocklingStats.get(this); The "this" that you're passing hasn't even been constructed yet. You're trying to get properties for an entity that doesn't exist yet. So all that stuff should be moved into your constructor. Maybe something more like: public class EntityBlockling extends EntityTameable { public BlocklingStats properties ; public int level; public double maxHealth = 10.0D; public EntityBlockling(World world) { super(world); properties = BlocklingStats.get(this); // <-- now the "this" should properly exist level = properties.getLevel(); System.out.println("Constructing EntityBlockling"); System.out.println("maxHealth field = "+maxHealth); System.out.println("properties.getMaxHeath() ="+properties.getMaxHealth()); // <-- add more debugging statements this.setSize(0.91F, 0.91F); Now I'm not sure the above will fully fix your problem, but you should do it. I think we also need to see what is happening in the applyEntityAttributes() method. Add debug statement like this: protected void applyEntityAttributes() { super.applyEntityAttributes(); System.out.println("Applying entity attributes"); System.out.println("Before setting, maxHealth attribute = "+this.getEntityAttribute(SharedMonsterAttributes.maxHealth).getBaseValue()); this.getEntityAttribute(SharedMonsterAttributes.maxHealth).setBaseValue(maxHealth); System.out.println("After setting, maxHealth attribute = "+this.getEntityAttribute(SharedMonsterAttributes.maxHealth).getBaseValue()); this.getEntityAttribute(SharedMonsterAttributes.movementSpeed).setBaseValue(0.25D); this.getAttributeMap().registerAttribute(SharedMonsterAttributes.attackDamage); this.getEntityAttribute(SharedMonsterAttributes.attackDamage).setBaseValue(5.0D); } Run the code with the debug statements I added above and post the console output here.

Okay, the problem is your initialization of the properties field. You're initializing with: public BlocklingStats properties = BlocklingStats.get(this); But that is a class field before you've called the constructor. In other words, I don't think there really is a "this" at that point ot pass to the BlockingState.get() method. You might be able to do this by calling the method within the constructor instead. In any case, I'm pretty sure that properties is coming back such that you're not getting the 10.0D property, probably because of this. Anyway, you should simply put System.out.println() statements in your code at key points in each class and print out the value of what is being processed in the code. You should quickly see that you're getting either 0.0D or null back at some point when you don't expect it.

I think you can use keybinding and intercept key input events by using event handling and checking for the keys you care about and checking if you're currently in the minigame and then doing what you want. Here is tutorial on keybinding, assuming you're using 1.7.2: http://www.minecraftforge.net/wiki/Key_Binding You can find out more about event handling at my tutorial (and others out there, like CoolAlias'): http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html You'll want to handle the FML event called KeyInputEvent.

Okay, this is just a Java thing, not really specific to modding. You probably need to learn more about Java. But here is an explanation. You have extended BlockContainer class which (if you look at the source for that class) implements the interface ITileEntityProvider. But BlockContainer doesn't fully implement that interface, which means that BlockContainer has to be declared as "abstract". Therefore it is up to your class to finish the implementation of the interface. What you need to do is to follow Eclipse's suggested fix -- if you hover over the red-underlined error part of your code Eclipse will usually suggest a fix. In this case it should suggest to add the unimplemented methods to your class. When you do that several methods will be added to the end of your class code, but the bodies of these methods will be empty (except a comment marking these as TODO). You then need to look at each method and put in your code that is relevant to your class. In this case, the only method that needs to be implemented is the createNewTileEntity() method. So of course in that method you should create and return the tile entity that is appropriate to your container. Hope that makes some sense...

Yeah, now that I know what is happening I can shut down the task in various ways -- I'm just using the task manager. Anyway, I guess this is "solved" since it seems to be a actual issue with the latest release (as opposed to something I'm doing wrong) and it can be worked around.

You want to make your own custom item that interacts with vanilla entities? Or you want vanilla items to interact with custom entities? Or you want to change the way that vanilla items interact with vanilla entities? I ask because the approach may differ depending on what your answer is.

I think the correct parameter is --username <username> Where <username> should be your username.

The registries are already an "array" (actually a map I think) that contains listing of all the blocks and items. Like any map they have methods for retrieving all the entries. Since this is a map, there are "keys" for each listing, so you don't just use ID numbers. Instead you can use the general map techniques (like iterators) and I think you can additionally retrieve the list of keys and then iterate through that. So I suggest that you get the set of all registered keys with something like GameData.getItemRegistry().getKeys(). That would actually give you all the registered items, so might be already what you need.

As mentioned there are different event buses. In my tutorial on events I explain which events are on which busses, so it might be interesting to you (either this time or in the future next time you are considering using events): http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html

Syncing motion between client and servers is actually a difficult art. It is a common problem in any multiplayer action game where lag or discrepancy will cause trouble for players trying to shoot, jump, etc. It is usually considered "best" (for the visual integrity) to have the client do some prediction to fill in the intermediate points between sync. For example, for a ballistic entity you shouldn't sync the actual position but rather just sync the starting condtions (position and velocity vector) and server only sends sync when something significant happens (i.e. hit an enemy). Anyway, I appreciate your response as I was suspicious about the same potential issues regarding syncing. I'll try some experiments with making it more explicit.

I think it is narrowed down to JVM not shutting down, not a general leak per se.