jabelar

MrParker, Forge is free cost and open source so upgrading shouldn't be any issue for educational purposes. However, since this is a request for supporting kids getting into coding I hope the forum here will make an exception and provide support one way or another. I'm at work, but I'll certainly take a look and help if I can. Note: MrParker -- this sort of thing is a really good teaching moment for your students about debugging code. I realize you may not have a lot of time to devote to the subject. But crawling through the console errors, looking at the lines of code that are errored, running the mod in debug mode and so forth are hopefully something you will discuss. Also the way to research and recruit support online.

As mentioned there are several type of possible errors. Were there console errors/warnings during the loading of the mod indicating a problem with resource assets? Was there continuous console errors when the entity was trying to render? Do you mean that the model just looks different than intended? Do you mean the entity never appears but there are no errors reported? Please describe which case it is and if it is an actual console error please post the logs to Gist or Pastebin as requested above.

Yes. If you think about it, the crafting GUI has to loop through all the recipes whenever you change the inputs.

Nice. So do you need any more help, or did you complete what you wanted to do?

After the mods are loaded you can get a list of all the recipes from the various registries and then loop through them to see if you find a recipe whose output matches what you're looking for.

Look at how the GUI scale factor is used to set the GL scale factor. There is probably a formula or conditional statement somewhere.

I'm not sure what you're doing but you're supposed to be setting health by applying the SharedMonsterAttributes.MAX_HEALTH which you can set to anything you want.

good point -- it is recent versions of the resource format (version 3), which need to be indicated in the pack.mcmeta file. This can definitely be confusing when porting older mods as I usually forget to update the pack.mcmeta.

Yeah, the lang file has to be capitalized US in recent versions. Overall, for things outside the code itself such as package and file names and json contents most problems tend to be typos so you just have to look really really carefully. Glad you fixed it all.

The first thing is that the RenderGameOverlayEvent is actually a parent event that has Pre and Post sub-events. You should really just subscribe to one of those otherwise you're actually handling it twice. The normal crosshairs should still render if you don't cancel the Pre event. You can see this in the GuiIngameForge#renderCrosshairs which has the code: protected void renderCrosshairs(float partialTicks) { if (pre(CROSSHAIRS)) return; bind(Gui.ICONS); GlStateManager.enableBlend(); super.renderAttackIndicator(partialTicks, res); post(CROSSHAIRS); } Where you can follow the call to pre(CROSSHAIRS) and see that is only true if the event is canceled. Since you didn't cancel the event, something else must be going on. At the time the event is called, there is already an GL11 matrix being processed so usually I directly use GL code to draw what I want. You're using the Gui class methods. Maybe it should work, just I know that weird stuff can happen with GL code once you start nesting methods -- for example the drawString() calls the enableAlpha() method so maybe that is making the crosshairs transparent or something. One way to test for this is to comment out all your code inside the event (but leave the event to fire) and I should expect that the crosshair should draw. Then add the code back bit by bit to see which line is leaving some residual effect on the rendering.

What have you tried so far? Obviously what you want to do requires being able to do the following: 1) Create a mod -- have you actually built a mod yet (even one that doesn't do much) that runs without errors? 2) Detect when mouse clicks happen. To do this you should look up how to handle events, in particular mouse-related ones. 3) Draw something on a screen. Anything that gets drawn on the screen is essentially a GUI. If you want it overlayed while playing then you probably want to handle the RenderGameOverlayEvent.Post event. 4) Get the network ping. This can be obtained (at least this was the code in last version I tried) with a somewhat convoluted series of getters: Minecraft.getMinecraft().getNetHandler().getPlayerInfo(Minecraft.getMinecraft().thePlayer.getUniqueID()).getResponseTime() Other than that, you should know there are 20 ticks per second in Minecraft. Lastly, hopefully you know enough about programming to be able to create the counting fields.

For the name, what is being shown is considered the "unlocalized" name. To allow for users who speak other languages, the name gets "localized" by looking up the translations in a .lang file in your assets. I have a tutorial on localization here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-localization.html For the texture it is usually a simple thing but often related to a typographical error. You need the blockstate to map to a specific section of the blockstates json file which has to have a name that matches exactly and then points to a texture asset where the name matches exactly. So you should post the contents of your blockstate file and maybe also your block class code in order for us to help you. You should also check the console messages during the loading of your mod -- it probably has a warning somewhere related to either not finding your block state or not finding the texture file. So you should post your console messages as well. It should tell you what is going wrong and it is very important to get familiar with looking at those messages. You can even get more detailed logs from the log file that is saved.

The reason why largerrits corrected you is because it is okay for something to be null, so that line is not really an error and is a perfectly valid line of code. It is only an error if/when later you dereference it to access something within the null instance. In programming it is important to be precise. The whole null thing can be a pain though especially in a situation like modding where you didn't write the rest of the code so it isn't always clear when something may be null. You can be safe and check everything for null before using it but that is unwieldy and seems like a waste of code (imagine if in every method you had to test every parameter for null). That is why the Nullable and Non-Null annotation is a welcome addition to Forge -- it really makes it clear when you should handle the null case. Tip: In fact you can usually configure your IDE to analyze this for you -- so if the entityHit() method was annotated with Nullable annotation it would have warned him (warning or error depending on how you configure your preferences) when he tried to use setDead().

Okay, so you're having trouble with the modeling or the textures? Do you mean the artwork isn't the way you want it? When you as "not as active" do you mean you want a faster animation? Or more random? One thing you might want to try is to use the "cross" style model like flowers have where the texture is applied to surfaces through the middle of the block instead of the outside sides. You can look at flower blocks to see how that is done. I would think that using the minecraft fire textures may not look "real" but would be nicely consistent with the Minecraft look. Anyway, it would probably be best if you could include a graphic of what it looks like currently and a more specific description of what you want to change.

The thing is that coding is very precise so when people are answering the questions here they usually do research to confirm what they are saying. Even if I have written a mod before that does exactly what you're asking, I would make sure I'm referring to the proper method name and such, so it means loading up the code and checking it, or whatever. For example if you look at Draco's answer above, he actually took the time to copy your code into his IDE and try to explore it and maybe run it. So basically answering questions takes work and usually isn't from the top of the head. It is much preferable to say "I looked up these couple mods in GitHub and this what they're doing but when I try it I still have this issue." Then we know you've put in the homework and we'll happily work to get you through the tough part. (It's kinda like when your kids ask you where something is when they haven't even looked for it...)

What have you done so far?

Why don't you look at their source code? Why are you asking us to look up something that you can find out yourself? Just find a mod that has similar teleportation and see if they have public source, like on github or otherwise published.

I don't think you need to handle the world tick event at all. You're just using that to reference the world entity list but you can just access that directly when you need it. I would get rid of the static worldEntities list field and forget the world tick handler. You also probably don't need the player tick event either. The render event happens often enough (even more than the tick) so whether the player is wearing the helmet can be checked at the time of rendering, and the render event will only happen for the one player. So moving the player tick code to the render event will also help avoid the issues that diesieben07 is mentioning. If you put everything into the render event then you shouldn't has as much issue with "reaching across the sides" or issue with syncrhonization between the time the other events fire for other players.

By the way I already have a tutorial that explains this (making weapons with extended reach) here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-extending-reach-of.html You cannot just override the on right click method on the server side because that only gets called after the normal reach is processed on the client. So you have to process the right click on the client to check the extended reach. Basically the approach is to make a copy of the mouse over method on the client to find entities at a longer distance and then send a custom packet that triggers an attack the same as normal attack on the server.

You're right that the code is a bit convoluted. You'll notice that it only checks for < 0 health if the guiScreenIn parameter is null. It seems that the screen passed in is null when "escaping" from some GUIs and so then this section of code will check if the death GUI should be shown. I guess they do this instead of going back to the parent GUI (the normal thing you do when exiting a GUI) because there is a chance that you died while you had the other inventory up on the screen. The Minecraft#displayGuiScreen() method with GuiGameOver is also called from the NetHandlerPlayClient when it receives a SPacketCombatEvent for ENTITY_DIED in the case where the entity is the player. So I suppose there could be a "race" condition that causes the event to fire twice -- once when client decides player health is < 0 and also when it receives packet from server notifying of the death. However, it is not clear to me that this would happen after pressing the respawn button.

Okay, all that stuff (buttons, showing information, icons and logos) are in fact a GUI. But what you're saying is that that GUI is outside minecraft and you want to send information to the interface that maintains that GUI. The problem with the events you were trying to use is they didn't have the information you needed. So as diesieben07 is recommending you can basically "poll" until the information is available in a tick event (with the client tick being the most obvious choice).

So your video says you want to make a GUI. Any time you're talking about a button, for spectate or join or whatever, that is a GUI. Maybe I'm crazy but I think you are saying you want to enable different buttons based on whether the game is multiplayer or single player, and maybe other information. Are you not trying to change buttons?

I don't understand why you try to handle that event for this. Your stated aim is to show something in a GUI right? So just check at the time you draw the GUI. GUI is client side and will have Minecraft.getMinecraft() instance where you can check it it is single player with the isSinglePlayer() and then get the player and world. Why are you checking before you need the information?

When trying to modify something vanilla, you have a few options. In this case using events is probably best bet. Just handle the RenderPlayerEvent.Pre event, do the rendering you want, and make sure you cancel the event to prevent the vanilla player renderer from rendering.

Animations are usually controlled with combination of the model class and renderer class.