saxon564

I had forgotten about this post... I found the only way to do this is to listen to the EntityJoinLevelEvent and call level.registryAccess().registryOrThrow(Registries.BIOME).keySet() when an entity joins the level. Here is how I handled it: https://github.com/saxon564/MoChickens/blob/master/src/main/java/com/saxon564/mochickens/events/CommonEvents.java https://github.com/saxon564/MoChickens/blob/master/src/main/java/com/saxon564/mochickens/configs/txts/ItemFile.java

I'm trying to export all the biome keys into a file. I have it working for items, blocks, particles, etc.. But for some reason, the biomes list is coming back empty. I am trying to get this list during the FMLCommonSetupEvent, I even attempted to run it during the BuildCreativeModeTabContentsEvent with the same results. I do not get any errors, and when I log it to the console using the below snippit, it logs "Biomes: []" logger.debug("BIOMES: " + ForgeRegistries.BIOMES.getKeys().toString()) I know this used to work back in 1.15, when I last tried modding. I can't figure out why it isn't working now, especially since it is working for all the other lists. Is there a new way to get a list of biome keys other than ForgeRegistries.BIOMES.getKeys() now?

I managed to get this fixed. I remembered reading someone saying that the command order matters when setting up. Previously I had set up by running gradlew eclipse then gradlew genEclipseRuns I swapped the order and that seems to have fixed my issue.

I recently started trying to get back into modding after having last done anything in 1.15. Now when I try to run the client with Java8 I get this error Exception in thread "main" java.lang.UnsupportedClassVersionError: cpw/mods/bootstraplauncher/BootstrapLauncher has been compiled by a more recent version of the Java Runtime (class file version 60.0), this version of the Java Runtime only recognizes class file versions up to 52.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$100(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source) Doing some research I found I needed to update to at least Java16 to fix this error. But when I do that I now get this error Exception in thread "main" java.lang.ExceptionInInitializerError at cpw.mods.niofs.union.UnionFileSystemProvider.newFileSystemInternal(UnionFileSystemProvider.java:115) at cpw.mods.niofs.union.UnionFileSystemProvider.newFileSystem(UnionFileSystemProvider.java:105) at cpw.mods.jarhandling.impl.Jar.<init>(Jar.java:84) at cpw.mods.jarhandling.SecureJar.from(SecureJar.java:70) at cpw.mods.jarhandling.SecureJar.from(SecureJar.java:66) at cpw.mods.jarhandling.SecureJar.from(SecureJar.java:58) at cpw.mods.jarhandling.SecureJar.from(SecureJar.java:50) at cpw.mods.bootstraplauncher.BootstrapLauncher.main(BootstrapLauncher.java:84) Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field static final java.lang.invoke.MethodHandles$Lookup java.lang.invoke.MethodHandles$Lookup.IMPL_LOOKUP accessible: module java.base does not "opens java.lang.invoke" to unnamed module @7d4793a8 at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297) at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178) at java.base/java.lang.reflect.Field.setAccessible(Field.java:172) at cpw.mods.niofs.union.UnionFileSystem.<clinit>(UnionFileSystem.java:52) ... 8 more I can execute runClient in command prompt without any issues, but not through Eclipse. I have tried this with both Java16 and Java17 and both give this same error. Does anyone have any suggestions to get this working correctly?

What do you mean by "Forgesrc still doesnt show"? Are you actually looking for a folder in your project src that is the forge source? What are you expecting to be seeing and where are you looking?

Are you using eclipse of intellij?

Could you show a screenshot of the contents of the folder 'ye'?

I just had a break through. It seems it is an issue with the world itself. I went to a new fresh world and it works with no issues.

So I have found that the cause seems to be the createExplosion method, which tells me I must be passing some sort of bad information to it, or calling it improperly. But as far as I can tell, I am doing everything right with it.

Does anyone else have any thoughts as to what might be causing this issue?

Do you have json for the item model of your block? Nevermind me, I should have refreshed the page before responding.

The error is a resource pack error, which I can safely say I have never seen from any of the screwed up jsons I have made. It makes me think there is a resource pack installed for a previous version of Minecraft. If you don't have a resource pack installed, it could be.

Lex has a lot of haters. He is blunt and tells it how it is, which most people don't like. Everyone has a run-in with him thats makes them hate him, just some hold that hatred, others let that hatred go and learn that he was helping but is tired of people who don't know what they are doing and refusing to do what they really need to do, usually learning basic java and basic coding in general. The class you have there is as simple as it can get. For a single item the helper method isn"t really needed, but it becomes a more important resource when you start getting many more items since it will make updating the resource locations a lot quicker if something chages. Aside from that, I don't think there is anything anyone will say you can do to make that class any simpler or efficent.

Since I first built this in 1.5.2 I do not remember the reason I did not extend the vanilla chiclen. I would guess that at the time, it was because of spawning issues or issues with making the chickens hostile. As for why code isn"t split between each individual chicken, that is because I have made the chickens highly configurable, so any chicken can do anything. So to put the "respective" code in each chicken class, I would have 21 classes that would be almost 100% identical. Which would also mean loads more time would have to go into updating since I would have to update 21 classes instead of just a single class. I will admit, when I was first building the mod, I did copy and paste a lot of vanilla code, but I have also made several changes to get the code to work the way I wanted/needes it to.

Unfortunately that was not the case, there was no change in the result at all.