OreCruncher

I need to be able to do some processing after data has been sync'd between client and server. Right now I listen for the "TagsUpdatedEvent" to do this processing. (I used to listen for the player login event, but that fires too early.) It looks like this event fires twice during the initial connection phase which is kinda redundant, and I am not to certain about the reliability of this event firing. My question is if there is different place/hook I can make to trigger my processing. The reason I need to do this processing is that my mod does client side configuration based on tags and I need to make sure that the data is current.

Thank you!

In my code I get an script engine reference: this.engine = new ScriptEngineManager().getEngineByName("JavaScript"); When using Java 8 (1.8.0_232 by AdoptOpen), with Forge 36.x it will fail with: java.lang.UnsupportedClassVersionError: org/openjdk/nashorn/api/scripting/NashornScriptEngineFactory has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0 When using Java 15, it works. I had code prior that used the Nashorn package explicitly that was present in Java 8, and that was working. I am trying to generify so that my mod can be used with later versions of Java, and I am hoping to have a single mod release that works with 1.16.4 as well as 1.16.5 since, well, MC 1.16.5 is bug fix release and is wire compatible with 1.16.4. The questions I have are: 1. Is it even possible to use Forge 36.x with Java 8 and obtain a JavaScript engine reference using a generic factory method? 2. Is there a 1.16.4 Forge release that has the Nashorn engine that I could reference to bridge this gap? I see from the change log that there was some work in Forge 35, but I do not see the downloads available. (I am assuming this is intentional to encourage folks to move to 1.16.5.) 3. Am I even looking at this issue correctly? It's possible I am working from some bad assumptions.

I agree it should, but for some reason it looks like it isn't. Not sure why. This is my first time dealing with Biomes in 1.16.4 so I could be doing something boneheaded. To be clear this only happens when connecting to a remote server. If I run single player with integrated it doesn't happen.

Forge 35.1.10 if it makes a difference... I have client side logic (on the main client thread) that scans around the player surveying the biome distribution. In single player, the Biome reference I receive returns back a non-null value for getRegistryKey(). However, when I connect to a remote server, the Biome reference I get back from the getBiome() call returns null for the getRegistryKey() call. Ultimately what I am trying to accomplish is correlating the Biome reference I get back from getBiome() to an entry in ForgeRegistries.BIOMES. EDIT: Found it. I recalled that F3 debug shows the biome ResourceLocation so I went to see how they did it. Essentially the Biome reference would be used to look up in the DynamicRegistry to get a key, and then that key could be used to look in the Forge registry: final ResourceLocation loc = world.func_241828_r().getRegistry(Registry.BIOME_KEY).getKey(world.getBiome(pos)); return ForgeRegistries.BIOMES.getValue(loc);

Based on your statement I will assume that it is by happenstance of the implementation rather than an intended design feature of the event system. Thanks! EDIT: A little more background as to why I asked the question. I am reworking some of the implementation in my mod which resulted in a dependency ordering between some objects. These objects were registered to listen on the event bus for the same modded events. Because of design I couldn't just go in and change priorities of the event listeners. I noticed the "in order" callback behavior of the event bus but was unsure if it was intentional or not. As result of this post I need to go back and rework my design. Yay.

That is precisely why I am asking the question.

I see that the list of listeners for an event is maintained in an ArrayList. Assuming multiple listeners with the same priority it means that the listeners are invoked in order of registration. My question is whether this is just happenstance because an ArrayList is used to track listeners, or can I be assume that this "in order" behavior is part of the event subscription contract?

Great! Thanks for the info. Now to go off and see if I can get it to do what I want.

Nice! When would be a safe time to do that?

When manipulating the Configuration data structure I can set a property on an entry to tell the Gui system what IConfigElement class to use when manipulating that property. I don't see anything like that available for the Config annotation system that Forge provides. I was wondering is if I am overlooking something, or if indeed the annotation system cannot do this if it could be added. My thought would be a new annotation on a Config property where I could specify the class name, and the annotation process would do the magic to set property on the config element. If that is not possible adding a pre/post event for config processing could be useful. In the pre I could set the the IConfigElement property appropriately and perhaps modify the structure somewhat better fit presentation, and on the post it has the potential of doing post processing before being persisted.

Ok. So if I am understanding correctly I would have to implement an IRecipeFactory that creates a modded IRecipe handler that accepts the damaged tools on input and provides the repaired tool on output. I would also create a recipe.JSON that specifies my recipe handler (input/output would be irrelevant in the JSON because of how my custom recipe would work). And lastly I would update _factories.json with the specifications for the recipe handler. EDIT: If this is indeed the case what would my IRecipe::getRecipeOutput() return? It wouldn't have any notion about the input stack. Seems the system is built around the fact that getRecipeOutput() is deterministic. EDIT2: I had getRecipeOutput() return ItemStack.EMPTY and it runs and works. Of course, it is a hidden recipe because of the finagling I had to do. I guess my next stop is to look at JEI and fix things up there. Thanks!

I have a feature in my mod where the player can put a damaged item in a crafting grid, combine it with some other ingredients, and the output would be the same item except that the damage has been improved. I have all this working using the traditional in-code way of generating shapeless recipes, but I am struggling with trying to map this to recipe jsons and the _factories feature that Forge has. To briefly outline what the traditional in-code way does: during post init the logic will scan the registered item list looking for items that are damageable and derived from some well known classes (like ItemTool). If there is a match a modded shapeless recipe is created with an ItemStack representing the damaged tool with a wildcard specified, the fixed ingredients my mod supplies, with the output being listed as a fully repaired tool. So if there were 50 items registered in the system 50 recipes would be created. To clarify the point related to the modded shapeless recipe, I have a class that derives from ShapelessRecipes, overriding matches() and getCraftingResults() to ensure the right things happen during the craft operation. I know enough about the JSON/factory system to be confused - more than likely me looking at this particular problem domain incorrectly. So before I go light my hair on fire, run around in the backyard beating a drum and spouting Vogon poetry is what I am wanting to even possible using factories and recipe json? If it is possible I would appreciate an outline of what I need to do to implement - I can go through and sort through the details myself.

Yes, there are mods that do manipulate the weather parameters of Minecraft. Is there a specific question?

Remember that your mod isn't the only mod in the modpack. Learn to profile Java applications. Profiling will point out hot spots and bottlenecks in your mod.

That was what I was fearing. Thanks!

From the client perspective is there a unique ID that identifies the server/map instance? I would like to be able to track some information client side without having my mod installed on the server, and have it immune to things like server renames, IP address changes, and map resets.

My mod can run 100% client side or with server support, though if not on the server runs with reduced functionality. If the mod is installed on the server the versions between the client and server need to match. Is there a standard way of accomplish this? It looks like I could put code in a NetworkCheckHandler but I am not sure if a meaningful error message will be given to the user. In my dev sandbox I forced a failure by returning false and the GUI hung up showing a 0%. Of course, this is running with an integrated server so the context of the version check is kinda bogus.

For performance reasons I have code that renders text elements using drawString() to a dynamic texture. The texture is updated whenever resources are reloaded (i.e. a resource pack is added/removed). Right now I have a hard coded 64x64 texels for each of the elements stitched into this texture. The code works with the default Minecraft font as well as texture packs that have "64x" support. My concern, though, is the amount of resources being used based on the default assumption of 64x64 texels. What I would like to do is pick the texel size for each element based on whether a "16x", "32x", "64x" font is being used. Is there a method somewhere or a calculation I can perform that would give me this answer?

I do realize this stretches ore dictionary use in ways that weren't expected/intended. But for my mod for what it does it helps a lot with things such as "out of the box" default configs for mods that I haven't seen. The information your provided above is helpful and I think I know which direction I need to go.

The problem is I need to get the block, if any, associated with a given ItemStack. My mod is heavily configuration driven. The configuration allows for the me, or a modpack author, to specify a Forge dictionary collection when defining sound profiles for footsteps, a sound profile being something within my mod. During startup the defined the Forge dictionary name is used to query the dictionary to get a list of ItemStack members. I need to crack each of those ItemStacks to get the Block references, if any, in order to populate my internal data maps. As an example, it expands "oreIron" in order to identify the various iron ore ItemStacks in the modpack to determine which blocks the "ore" sound profile. There are a lot more details to this process (like meta handling) - I just wanted to give a broad brush outline as to what the mod is doing. During runtime I use IBlockState information to resolve a sound profile based on the data maps mentioned above. Once it is resolved that solution is inserted into a map using the IBlockState as key.

The code I have iterates through the ItemStacks of a ore dictionary collection (ex. "sugarcane"), trying to identify any of those entries that have associated blocks by using the Item returned from ItemStack.getItem() passed into Block.getBlockFromItem(). The code I have originated with the 1.7.10 version of the mod so it is very possible I have to change my approach.

The code for Block.getBlockFromItem() checks for ItemBlock, but not ItemBlockSpecial. As a result getting the block for, say, Sugar Cane would return null since it is an ItemBlockSpecial. What I am wondering is if getBlockFromItem() should be modified to handle ItemBlockSpecial as well, or is there a fundamental difference between an ItemBlock and an ItemBlockSpecial that is not apparent to me.

Then your mod would have to send packets to clients when a player logs in. Up to your mod to do that, assuming the client really needs your updated server side values.

Uh, this isn't related to writing mods. I suggest you read the documentation for the various mods you use in your pack. A lot of them provide configuration settings to do specifically what you want, or provide integration with systems such as Minetweaker/Crafttweaker.