Leaderboard

"entity joins world" event - make your extended villager, copy data from original (if you care to), spawn your villager into the world instead of the original ok, but refreshBrain is public - override it. either let the inherited code do its thing and re-add your stuff, or rewrite the method completely. and it looks like you'll need ATs sooner or later - no worries, they are not a big problem.

react to "entity joins world" event. if the entity is a villager, remove goal g1 and add goal my_g1. (if you didn't find g1, you have a conflicting mod.)

Sorry for resurrecting an old topic, but I just found this thread and I've been wondering about why nobody does something about this for years. There were questions about newer version, and just for reference the 128x version of the PureBDCraft texture pack (which I've been using since 1.11 days) takes a frigging 7 minutes to stitch with my latest modpack, the Stacia Expert 1.8.2. The game is completely unresponsive for the entire time. This is on MC 1.16.4, and a relatively beefy computer (AMD 5600X, 32GB of DDR3200 memory, a fast PCIE4 NVME drive) The modpack has >200 mods in it, and without the texture pack the it loads in about one minute. Reasonable, considering the amount of mods. However the seven minutes stitching time is on top of that - the total game load time from launcher is thus roughly 8 minutes. Does this sound reasonable to you? Here you go if you want to try it yourself: https://www.curseforge.com/minecraft/modpacks/stacia-expert https://bdcraft.net/downloads/purebdcraft-minecraft/ I used to be a Java developer for many years, and in my opinion this system is broken...

Of coarse simple single use code is going to be faster then unrelated complex code. The kicker is the integration with Minecraft itself, and taking into account the things you so nonchalantly ignored, user configs dynamic textures, or any of the plethora of other things mods do that screw up the cache. Also, what parts of the texture stitching event actually takes time? What parts could be accelerated? The actual slot allocation shouldn't be that time consuming. But it'd be worth quantifying. So, as I said before, write something up and add benchmarks. And i'm talking real world implementations not unrelated theoretical code.

I like the sound of parallel loading, but I seriously doubt that textures can be stitched in parallel, but if that's been parallelized, good work, i'm impressed. One thing I'm not sure of is this statement "I don't feel like periodically cleaning my disk of cached texture atlases, especially since different packs with the same mods would cause a new atlas set to be cached, and a resource pack change would cause a re-cache, and pack devs would see their test installation bloat with every mod added to the pack." Let's think of set theory. We have set M. set M contains all mods in your mod pack. any mod 'm' is a set containing three items: 1: s, the space that the mod takes up. 2: a set C containing source files for the mod. 3: a set R, which contains all of the resources that a mod uses. Similarly, we have an Atlas set A, for which there is one A for every one M. Set A contains all R sets within M, as well as a D set, for Directory. The A set also contains a unique element s, which is the space that A takes up. Then it follows that so long as set C is lesser in space than set D, then Mc will take up less space than Ac. In short, The atlas will always take up less space than the mods, considering that most worlds are bigger than the mods, then space won't be an issue, especially if you cull old atlases automatically.

See the benchmark below. I think you are very wrong. 1.) That Is really not something that a mod should have access to. 2.) Like in Minecraft, the easter eggs are still in the game and loaded even when it is not present. Same concept flies here. 3.) That's why you hash the textures as well, not just the mod versions and names If the textures change, the jar changes, and the hash will be different. Ok! Here's my script that can load, hash ,and unload mod files in 356ms(+/- 40ms) on my computer, using the mods for the Feed-The-Beast Continuum modpack, during which the texture stitching takes 34.5 seconds, with 500ms of human error. import java.io.IOException; public class ShaHasher { public static void main(String[] args) { String cmd = "7z h -scrcSHA1 mods"; String result = ""; long timeStart = System.currentTimeMillis(); try { result = execCmd(cmd); } catch (IOException e) { e.printStackTrace(); } System.out.println(result); System.out.println("^^^CMD OUTPUT^^^"); System.out.println("Extracted SHA1 for data only: "+ getSHAContents(result)); System.out.println("Extracted SHA1 for data and names: "+ getSHAContentsAndNames(result)); System.out.print("Time taken: "); long timeStop = System.currentTimeMillis(); System.out.print(timeStop-timeStart); System.out.println(" ms."); } public static String getSHAContents(String toExtractFrom) { int loc = toExtractFrom.indexOf("SHA1 for data:"); loc +=16; while(toExtractFrom.charAt(loc) == ' ') { loc++; } int end = loc; while(toExtractFrom.charAt(end) != '\n') { end++; } return toExtractFrom.substring(loc,end-1); } public static String getSHAContentsAndNames(String toExtractFrom) { int loc = toExtractFrom.indexOf("SHA1 for data and names:"); loc +=26; while(toExtractFrom.charAt(loc) == ' ') { loc++; } int end = loc; while(toExtractFrom.charAt(end) != '\n') { end++; } return toExtractFrom.substring(loc,end-1); } public static String execCmd(String cmd) throws java.io.IOException { Process proc = Runtime.getRuntime().exec(cmd); java.io.InputStream is = proc.getInputStream(); java.util.Scanner s = (new java.util.Scanner(is)).useDelimiter("\\A"); String val = ""; if (s.hasNext()) { val = s.next(); } else { val = ""; } s.close(); return val; } } here is the output of the program. https://pastebin.com/7mTLdmkq What else can I benchark for ya?