Posts posted by Choonster
-
-
-
-
-
I've created a Pull Request to fix this crash here. If the PR is merged, this particular error will be logged like other syntax errors instead of crashing the game.
-
-
Registry events are fired before preInit, so you need to annotate the event handler class with @Mod.EventBusSubscriber to automatically register it at mod construction time (or register it manually). In addition to this, you're registering an instance of the event handler but your methods are static; which is incorrect. Static event handler methods require you to register the Class object rather than an instance, as explained in the documentation.
You need to set the registry name of an IForgeRegistryEntry like Block or Item before you register it.
Having a constructor modify static fields in a class where there there are no instance fields or methods and calling this constructor purely for the side-effects is very strange and probably a bad idea. If you need to do more stuff to the Items in preInit, create a regular static method instead of a constructor.
ModelLoader is a client-only class and can't be referenced from common code. ModelRegistryEvent should be handled in a client-only class that's only registered with the event bus on the physical client (pass Side.CLIENT to the @Mod.EventBusSubscriber annotation or manually register it in a method only called on the physical client).
-
Edited by Choonster
It's not absolutely required, but it's a good idea to avoid potential conflicts. All unlocalised names are used as keys in the same Map, so your unlocalised name's translation could overwrite or be overwritten by the same name from another mod.
I recommend using the Item's registry name (IForgeRegistryEntry#getRegistryName) as the unlocalised name as it already includes the mod ID.
-
Edited by Choonster
6 hours ago, That_Martin_Guy said:I did find an existing version of CoFH-Core on there, but when I ran gradlew dependencies it showed
testRuntime - Runtime dependencies for source set 'test'. +--- com.github.CoFH:CoFHCore:a19dbc5eea | \--- mezz.jei:jei_1.11.2:4.5.0.+ FAILED
Is this an error on CoFH's part? I don't think 4.5.0.+ is a valid version of JEI (I might be wrong though). Also, I tried adding my own version of JEI, also via jitpack, but JEI doesn't show up in game, and no new files are created in my project directory. Is this intended? Do I still need a jar for viewing the CoFH's source code in my IDE?
You need add the dependency repositories used by CoFH to your build.gradle file manually, JitPack doesn't seem to handle that automatically.
Basically, copy the repositories from the repositories section of CoFHCore's build.gradle file into the repositories section of your build.gradle file. Use the repositories sections in the main body, not in the buildscript section.
I also had to add the universal classifier to the CoFHCore dependency, e.g. deobfCompile 'com.github.CoFH:CoFHCore:f60b7b70fe:universal'.
-
Quote
java.lang.ClassCastException: com.google.gson.JsonObject cannot be cast to com.google.gson.JsonArray
at com.google.gson.JsonObject.getAsJsonArray(JsonObject.java:181)
at net.minecraftforge.common.crafting.CraftingHelper.loadRecipes(CraftingHelper.java:738)
at net.minecraftforge.common.crafting.CraftingHelper.lambda$loadRecipes$22(CraftingHelper.java:612)
at net.minecraftforge.common.crafting.CraftingHelper$$Lambda$326/713193000.accept(Unknown Source)
at java.util.ArrayList.forEach(ArrayList.java:1249)
at net.minecraftforge.common.crafting.CraftingHelper.loadRecipes(CraftingHelper.java:612)
at net.minecraftforge.fml.common.Loader.initializeMods(Loader.java:828)
at net.minecraftforge.fml.client.FMLClientHandler.finishMinecraftLoading(FMLClientHandler.java:358)One of your mods has added an invalid recipe via JSON. Unfortunately the crash report doesn't say which one, so you'll need to remove mods until it stops crashing to figure out which one it is.
-
1 minute ago, TheMattyBoy said:
What do you mean by "rename the directory"? If I try to physically rename the folder ".gradle", Windows tells me that I must type a file name (maybe because .gradle is an extension and not a file name? Not sure on that one...)
Rename it to something other than .gradle (or move it to a different directory) so Gradle doesn't use the cached files stored in it.
You can rename a folder to a name starting with a period from the command line with the rename command (in Command Prompt) or the Rename-Item cmdlet (in PowerShell).
-
Item#onArmorTick being called in the wrong place is a known issue.
I'm not sure why the patches would fail to apply like that. It's possible that something in the Gradle cache is corrupted, you can try temporarily renaming the ~/.gradle directory (%USERPROFILE%\.gradle on Windows) and re-running the setupDecompWorkspace task.
-
You can also use CurseForge as a Maven repository, see the documentation. I explain this in more detail here.
-
Edited by Choonster
This is a known issue. There's a Pull Request open to fix this, but it hasn't been merged yet.
-
4 minutes ago, Draconwolver said:
Thanks, that was helpful. When I listen to the RenderLivingEvent.Specials.Pre event, should I suppress the raw type warning, or use something like RenderLivingEvent.Specials.Pre<? extends EntityLivingBase>?
Either use a wildcard in the parameter declaration or give the method a generic type argument and use that in the parameter declaration.
-
15 minutes ago, hogfly893 said:
com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_ARRAY but was STRING at line 1 column 1
at com.google.gson.Gson.fromJson(Gson.java:815)
at com.google.gson.Gson.fromJson(Gson.java:768)
at net.minecraft.server.management.UserList.func_152679_g(SourceFile:137)
at net.minecraft.server.dedicated.DedicatedPlayerList.func_187246_z(SourceFile:99)
at net.minecraft.server.dedicated.DedicatedPlayerList.<init>(SourceFile:25)
at net.minecraft.server.dedicated.DedicatedServer.func_71197_b(DedicatedServer.java:215)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:431)func_187246_z is loadPlayerBanList, which is the method responsible for loading the list of banned players from banned-players.json. This error was thrown because that file has a syntax error in it.
Either fix the syntax error or delete the file and re-ban any banned players.
-
16 minutes ago, Draconwolver said:
Why does cancelling RenderLivingEvent.Specials.Pre<AbstractClientPlayer> prevent all nametags from showing, rather than just players?
Are you subscribing to RenderLivingEvent.Specials.Pre<AbstractClientPlayer> directly, or are you subscribing to RenderLivingEvent.Specials.Pre and checking if the entity is an instance of AbstractClientPlayer? Only the latter will work in this case.
Forge only performs generic filtering for events that implement IGenericEvent, which RenderLivingEvent.Specials.Pre doesn't. It's too expensive to do multiple times every frame, so it's generally only done for load-time events.
22 minutes ago, Draconwolver said:What role does RenderPlayer::renderEntityName have in rendering player names? It seems to handle scores displayed under the player's name and then call Render::renderEntityName, which is also called by RenderLivingBase::renderName. So when a player's nametag needs to be rendered, which is called, RenderPlayer::renderEntityName or RenderLivingBase::renderName?
- Render#doRender (which is called by every class that overrides it) calls Render#renderName.
- RenderLivingBase overrides Render#renderName to fire RenderLivingEvent.Specials.Pre/Post and call Render#renderEntityName with the entity's display name.
- Render#renderEntityName calls Render#renderLivingLabel to render its argument.
- RenderPlayer overrides Render#renderEntityName to render the player's score with Render#renderLivingLabel and then call the super method.
-
-
That should be the method to override. Have you actually replaced the vanilla RenderPlayer instances with your own?
A better way to do this would be to subscribe to RenderLivingEvent.Specials.Pre, which is fired just before a living entity's nametag is rendered. You can cancel this to prevent the nametag from being rendered.
-
7 hours ago, AnthonyFuller said:
have you set unlocalized names and put the texture in blocks and added a model files as a json
The unlocalised name has nothing to do with models, it's only used for localisation. The registry name is what determines the default blockstates file/item model location. I have an explanation of the model loading process and where models are loaded from here.
-
-
1 minute ago, jeffryfisher said:
You might try making two block instances (basic, advanced) from one block class, registering each under a slightly different name. Then the basic/advanced value can be an instance field rather than a property, and then I think you could create a separate blockstates file for each registered name.
If the goal is to have a separate blockstates file for each value of a property, you can do that by creating an IStateMapper using StateMap.Builder and registering it with ModelLoader.setCustomStateMapper.
-
1 minute ago, Bektor said:
Ok. Thougt now eclipse tells me always this: Source not found. Edit Source Lookup Path.
There it just gives me the option to select default and then it works. I click on resume and the same thing happens again.
It sounds like Eclipse is showing you NullPointerExceptions being thrown in external code that it doesn't have source code for.
Restrict the breakpoint to your message handler class by doing the following:
- Show the Breakpoints view (Window > Show View > Other... > Debug > Breakpoints)
- In the Breakpoints view, right click on the exception breakpoint and select Breakpoint Properties...
- In the Properties window, select Filtering in the left column and then click Add Class...
- Type in the name of your message handler class, select it in the search results and click OK.
- Click OK in the Properties window.
-
Just now, Bektor said:
Hm, seems like eclipse has something like that, too. Thought I can't set the line of an exception breakpoint nor the class and for normal conditional breakpoints I have to write normal null checks like I would inside of the code, just inside of the breakpoint.
You shouldn't need to set the class/line or add any null checks, the breakpoint will be hit as soon as something throws a NullPointerException. Once your code throws the exception and hits the breakpoint, look at the debugger to see what's null.
-
Edited by Choonster
52 minutes ago, Bektor said:How can I create an exception breakpoint fpr NullPointerExceptions in eclipse?
Look at the documentation or use your search engine of choice.
If it's anything like IDEA, the Debug window should have a button that shows all breakpoints. Clicking this will bring up a window that also allows you to create new breakpoints.
Retrieve files from compiled mod. [Solved]
in Modder Support
·
Edited by Choonster
If you ever built your mod with the build Gradle task, you may have a source JAR in the build/libs directory of your mod's workspace. This will contain your source code obfuscated to SRG names.
BON2 can deobfuscate a compiled JAR from SRG (obfuscated) to MCP (deobfuscated) names, but probably not a source JAR. You can then decompile it with a decompiler like Bytecode Viewer. The decompilation process isn't perfect and all comments are stripped during compilation, so the code you get out of it won't be exactly the same as the original code.
If you use version control software like Git and host a copy of your repository on a site like GitHub, you can retrieve any version of your code. This will make it much less likely that you'll lose anything.