Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/logging/log4j/LogManager
"log4j" is only used by newer versions (1.7 and later); you surely didn't try installing TMCW in a newer version, did you? The instructions specifically state to use 1.6.4 (not to be confused with 1.16.4), and like nearly any other mod it will only work with that version.
How do you install directly into the jar? I try to copy files over using Open in my ZIP program BreeZip, and it says 'file already exists'. I then try to delete files and it gets corrupted...
How do you install directly into the jar? I try to copy files over using Open in my ZIP program BreeZip, and it says 'file already exists'. I then try to delete files and it gets corrupted...
I'm not sure why so many archivers have problems with adding files to the jar but WinRar doesn't have this issue (I also have 7Zip and it gives me an error when I try to add files; using Windows' file explorer, as some mod installation instructions tell you to do (rename to .zip and extract, add files, then rezip and rename to .jar), will not work for 1.6.4 and many other versions because one of the class files is named aux.class, which is an invalid Windows filename and it is possible this also affects zip tools even when within an archive).
I just can't seem to get this to work. It just opens a normal vanilla 1.6.4, not a title TheMasterCaver's World and no granite blocks etc
How did you install it? You need to make a copy of the ".minecraft\versions\1.6.4" folder and rename it and the 1.6.4.jar file inside to "TMCWv4.5" and replace the json file with the one which is included in the download (make sure it is deleted, don't just add my file, and directly add the files inside the "mod" folder in the zip you downloaded to the jar, deleting META-INF (if you don't do this the game won't launch and you'll get an error about an invalid signature); this mod will not work if you try to add it to the ".minecraft\mods" folder, as you would with Forge or other mod loaders (Forge will probably just ignore it with a warning about an invalid mod file).
You can use a name other than "TMCWv4.5" for the folder and files but you have to make sure to edit the json so the "id" inside matches, and in any case it must not match any vanilla version, otherwise the launcher will detect the jar as corrupt because the checksum doesn't match and redownload it (i.e. it launches as vanilla).
Obviously, you also need to make sure it is selected in the launcher profile, ideally by using a separate profile with its own game directory (I use a different name for options.txt so it won't conflict with vanilla, especially newer versions, but you still want worlds to be separate; versions prior to 1.7 also saved statistics in the "stats" folder, which will also conflict).
After years of development I've finally released TMCWv5, the largest update that I've ever made, larger than all previous updates combined, with the total number of features or changes at well over 500, maybe even a thousand when including every change, with the changelog for TMCWv5 listing 224 changes/additions, many describing multiple/complex features (I've added a total of 325 blocks, 103 biomes, 45 entities/variants, 31 items, and 5 enchantments; this includes things that are in vanilla but are not used/obtainable/usable outside of world editors or were given significant new functionality (giants, bark logs, sponges, etc), while not including special variants of blocks that only exist when rendered or are otherwise not obtainable (e.g. the "stalactite" variant of stalagmites, and their variations when placed on blocks like stained clay, which would add 168 blocks alone if all were counted, compared to 21 actual item forms).
The update history of TMCWv5 goes back about 4 years, with the first period of development starting in early 2018 and continuing through the end of the year, after which I got sidetracked by making my own "Optifine replacement" and massive refactoring of the vanilla codebase, which took another year, but was very well worth it in the end. I then merged this mod, which I call "World1" as I use it when playing on my first world (this was developed completely independently of TMCW but included its early optimizations/refactors, as well ones I previously made to a personal modified copy of Optifine at least as far back as 2015) with TMCWv4 and released it, along with about half the features I'd added to TMCWv5 at the time, as TMCWv4.5, the name of which is derived from TMCWv4 and TMCWv5, as opposed to indicating an intermediate version (e.g. 1.6, 1.6.1, 1.6.2, etc); this was still considered to be version 4 as world generation was not altered, aside from some minor bugfixes.
Merging World1 with TMCWv5 was much more complex because I'd already made many core changes, including many hacks to avoid having to directly modify classes modified by Optifine as I still wanted it to be compatible at the time; I did this by incrementally adding TMCWv5 code to TMCWv4.5 until I'd reach a point where I figured I could just merge TMCWv4.5 with TMCWv5 (with the help of a tool to show code differences), which took a couple months. Some of the code I originally wrote back in 2018 has been refactored multiple times, further increasing development time, but in the end it was well worth it (for example, when I first added "water plants" they could only be placed if they were entirely submerged because they would cause "air" bubbles (water did not render adjacent to them so the "air" was invisible unless it was at the surface, adjacent to glass, etc); by modifying the rendering system I was able to make blocks render on both render passes (opaque/transparent and translucent), which was impossible without overwriting classes modified by Optifine). I then spent the first half of 2021 adding more content and tweaking/fixing existing features, then the past month on making final additions/changes/bugfixes before releasing it today.
Another factor in the time it took is the time I spent on actually playing the game, which is usually an "either" and not "both" situation when it comes to allocating my "Minecraft time" (I usually only play or work on mods, not both, and usually over extended periods of weeks, not alternating days or the like), and even my first world/World1 mod is quite enjoyable despite not having any new biomes or underground features and only the less vanilla-altering gameplay changes.
Note that due to the size and complexity of TMCWv5 there is less confidence than usual that it is free of any significant bugs, which will always be present to some degree; a common claim is that there are 15-50 bugs per 1000 lines of code, which seems insanely high (due to lack of popularity some significant bugs have gone undetected/reported for years; when TMCWv4 was released it had a bug where Mending only worked if it was the last enchantment to be added; I only discovered this about 3 years later when I decided to add Unbreaking to my armor to take advantage of a change made in TMCWv4.5 which made it more effective (Unbreaking III gives 2x durability instead of 1.43x, which is still half the effectiveness as on tools), and because I hadn't been finding enough amethyst recently to keep up with repairs (I still had plenty, and did start finding more before it would be an issue). If anybody else had experienced this it was either unnoticed or never reported (Mending is probably the last enchantment that will be added to an item; this is even more so in TMCWv5 as I made it so the cost to add Mending is the cost to repair the item, preventing you from making items too expensive to be repaired unless you add more enchantments after Mending).
Also, this is a more detailed look at the seed I featured in the update description for version 5, "6511199847387183207", which has many new and/or rare biomes close to spawn in addition to the largest known cave:
There is a Volcanic Wasteland biome, one of the rarest full-size biomes and a very good source of minerals, which are more common, just to the south of spawn (a disadvantage of having this next to spawn is magma cubes, which spawn at all times of day and are more common since TMCWv4.5 due to slimes having their own mob cap separate from hostile mobs):
Spawn itself is in a Mega Tree Plains, with a Jungle to the east and a small Rocky Mountains to the west, and further to the north is one of the new biomes added in TMCWv5, Iceland:
A top-down view from above spawn; there is a jungle temple in the jungle near the right edge:
Further to the west is another new biome, Autumnal Forest, with new types of trees and mobs; they may also have a new structure though one isn't present in this biome. Also visible is part of a Desert M, which contains the rarest biome by area, Oasis (fun fact - it is possible to spawn in an Oasis but highly unlikely):
Mushroom Forests can be found to the northeast of spawn as well as to the west of the Autumnal Forest, along with another Iceland and an Ice Plains with Ice Hills; the main features of this biome are the foliage color and surface mushrooms in every color (they can also be found in larger caves underground):
North of the Iceland is a Big Birch Forest, with large birch trees in 1x1 and 2x2 forms:
Further to the northwest is a Roofed Forest with a woodland mansion; while nowhere near as rare as they are in vanilla they are still the rarest structure in TMCW, in part due to the rarity of any one biome and the failure rate due to uneven terrain (all my own structures require that the ground be flat enough):
The southern part of the Desert M contains a small village next to an enormous ravine which goes all the way from the surface down to lava level; while quite large they can get much larger, 368 blocks long and 50 blocks wide and over 600,000 blocks in volume (while ravines are normally about 3 times deeper than their width larger ravines have a reduced ratio and they may bee too low/high up so even the widest ravines may not break the surface; the maximum floor-ceiling depth is about 70 blocks, or +/-35 from the center altitude):
A bit further from spawn is the enormous cave that is the highlight of this seed, the largest single cave that I've found within 2048 blocks of spawn in several thousand seeds; the cave is so huge it goes out of render distance even at 16 chunks:
As if that wasn't enough, there is another enormous cave just to the north; both caves combined have a volume of more than 1.5 million blocks, which is still less than the average giant cave region, the largest underground structure (technically a type of cave system as it is made up of many individual caves, hence why I say largest single cave):
Also, the jungle to the east of spawn contains jungle caves, a new "lush cave" variant which generates in jungles and tropical swamps (the screenshots are from a different world as I didn't see them until I used Minutor to map the world). You'll also notice that other caves have a lot of vegetation in them, including vines and patches of grass with "cave grass" (a variant of tall grass which doesn't need light):
Here is a surface map made with Minutor:
A biome map made with the BiomeMapper tool, with a radius of 2048 blocks from 0,0 (the grid is 512 blocks):
Maps of the underground made with the CaveFinder tool (I used this instead of Unmined as it has more contrast and is free of underground lakes), centered at 0, -512 with a radius of 768 blocks; the second map only shows "special" caves (caves/ravines with a volume of at least 25000 blocks, circular rooms with a diameter of at least 34 blocks, larger "vanilla" large caves (some may actually exceed 25000 blocks but will not be listed, only my "custom" large caves) and new cave variations, except for the smallest "cave clusters" and "jungle caves". Dungeons are also not listed because they require the world to actually be generated, likewise, jungle caves and biome-specific variations like more caves above sea level in mesas require that the biome be known):
A listing of underground features found by CaveFinder within 1024 blocks of 0, -512 (the maps above are slightly smaller due to Imgur's 1 MB limit without resizing/reducing quality); note also the underground volume given at the end, which is nearly triple that of vanilla 1.7-1.17 and double that of vanilla 1.6.4, and the highest of any of my mods in terms of percentage of blocks between cave lava level and sea level. About 75% of this is due to larger caves and special cave variations (even "normal" caves have more variation than in vanilla):
A new feature of CaveFinder is that it adds a "caveinfo" option which shows details for "normal" cave systems, even listing the "size" of each individual cave system within the area ("caveinfo 1" only lists the center chunk and overall stats while "caveinfo 2" also lists individual cave systems, of which a small sample is shown; the second option should not be used with a large radius); this also shows all the ways I vary normal caves:
Normal cave system parameters for center chunk:
largerCircularRooms: true
circularRoomChance: 1/2
largerLargeCaves: false
largeCaveChance: 1/20
widthMultiplier: 1.5
maxLength: 112
curviness: 0.2
verticalVariation: 1/6
circularRoomCaves: 0-1
minWidth: 3.0
extraBranchChance: 0%
extraLavaLevelCaves: false
extraSeaLevelCaves: false
Size 16 cave system at 512 448; total number of caves: 19
Size 10 cave system at -464 464; total number of caves: 12
Size 4 cave system at -80 464; total number of caves: 6
Size 1 cave system at 96 464; total number of caves: 1
Size 3 cave system at 192 464; total number of caves: 3
Size 1 cave system at 480 464; total number of caves: 1
Size 16 cave system at 544 464; total number of caves: 27
Size 19 cave system at 704 464; total number of caves: 26
Size 1 cave system at 64 480; total number of caves: 1
Size 3 cave system at 192 480; total number of caves: 3
Size 2 cave system at 592 480; total number of caves: 2
Size 1 cave system at 608 480; total number of caves: 1
Size 2 cave system at -832 496; total number of caves: 2
Size 10 cave system at -800 496; total number of caves: 10
Size 12 cave system at -768 496; total number of caves: 12
Size 5 cave system at -656 496; total number of caves: 5
Size 13 cave system at -112 496; total number of caves: 13
Size 15 cave system at -96 496; total number of caves: 15
Size 2 cave system at 672 496; total number of caves: 3
Number of cave systems: 665
Initial number of caves: 4720; largest cave system: 43 (-880 -576)
Total number of caves: 6131; largest cave system: 54 (-880 -576)
Additional circular room caves: 945
Additional lava level caves: 268
Additional sea level caves: 198
Number of small caves: 5405; average width is 5.69
Number of large caves: 726; average width is 12.11; max width: 31.42 (744 4 -551)
Number of circular rooms: 1968; average width is 12.25; max width: 61.53 (-269 24 -636)
Additional caves per circular room: 0.48
Average caves per chunk: 0.37420654 (16384 chunks)
Average altitude: 26.60
Percentage of caves on layers -7 to 2: 20.68
Percentage of caves on layers 3 to 12: 20.06
Percentage of caves on layers 13 to 22: 13.21
Percentage of caves on layers 23 to 32: 10.49
Percentage of caves on layers 33 to 42: 8.33
Percentage of caves on layers 43 to 52: 8.11
Percentage of caves on layers 53 to 62: 7.45
Percentage of caves above layer 62: 11.66
Also, you can easily experience every biome by giving a world a name starting with "debug_biomes", which will enable a special mode where every Overworld biome is laid out in a 14x9 grid with each biome being 4x4 chunks; there is another mode, "debug_flat", that generates a Superflat-like world with normal biome generation but there are only biome-specific ground blocks, caves, and structures (both of these were in TMCWv4.5 but could only be enabled with a flag in code at development time):
In addition, the OP has been refactored so all the previous update descriptions were moved to the comment section, replacing comments which described new features added by that update (it got so large that it actually exceeded the character limit and had nearly 200 images so this should also reduce loading times).
Oof, I was making a resource pack for v4.5 and just found an update. Well, I’ll share a piece anyway.
I edited the water biome colors so that each biome matches the water color that is at the corresponding coordinates of the unused watercolor.png texture from Minecraft b1.6–1.5.2, matching the coordinates of the grass and foliage colors.
This is what came out (UPDATED for v5) and I think it looks really nice with TMCW water textures and biomes.
(remade after the v5 release, edited the changed colors and added new ones)
P. S. Vanilla (unused) watercolor.png from pre-1.6:
java.lang.ArrayIndexOutOfBoundsException: -157
at yc.<init>(Item.java:271)
at zh.<init>(SourceFile:17)
at TMIReplaceItems$MetadataBlock.<init>(TMIReplaceItems.java:18)
at TMIReplaceItems.modMushroomBlock(TMIReplaceItems.java:93)
at TMIReplaceItems.replaceItemsOnce(TMIReplaceItems.java:53)
at TMIController.onCreate(TMIController.java:52)
at awy.<init>(awy.java:45)
at axp.<init>(SourceFile:16)
at axv.<init>(SourceFile:20)
at GuiInventoryTMCW.<init>(GuiInventoryTMCW.java:38)
at atv.k(Minecraft.java:1518)
at atv.S(Minecraft.java:743)
at atv.d(Minecraft.java:683)
at net.minecraft.client.main.Main.main(SourceFile:101)
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- Head --
Stacktrace:
at yc.<init>(Item.java:271)
at zh.<init>(SourceFile:17)
at TMIReplaceItems$MetadataBlock.<init>(TMIReplaceItems.java:18)
at TMIReplaceItems.modMushroomBlock(TMIReplaceItems.java:93)
at TMIReplaceItems.replaceItemsOnce(TMIReplaceItems.java:53)
at TMIController.onCreate(TMIController.java:52)
at awy.<init>(awy.java:45)
at axp.<init>(SourceFile:16)
at axv.<init>(SourceFile:20)
at GuiInventoryTMCW.<init>(GuiInventoryTMCW.java:38)
There are no other known mods that TMCW is compatible with, even my other mods, so don't try to mix them.
Specifically, in this case I refactored the Item class to use actual IDs instead of "offset IDs", where e.g. iron shovels are 0 in vanilla but the actual internal ID is 256:
// Vanilla
public static Item shovelIron = (new ItemSpade(0,
protected Item(int par1)
{
this.itemID = 256 + par1;
if (itemsList[256 + par1] != null)
{
System.out.println("CONFLICT @ " + par1);
}
itemsList[256 + par1] = this;
}
// TMCW
public static final int shovelIron = 256;
public static final Item shovelIron = (new ItemShovel(ItemIDs.shovelIron,
protected Item(int par1)
{
this.itemID = par1;
if (itemsList[par1] != null)
{
throw new IllegalArgumentException("Item ID " + par1 + " is already taken up by " + itemsList[par1] + "!");
}
else
{
itemsList[par1] = this;
}
}
Vanilla also has code like this; all those additions/subtractions of 256 are a maintenance disaster waiting to happen (I imagine that Mojang had a lot of fun when they refactored the game in later versions, I had my fair share of crashes due to missing +/- 256 somewhere, but now I don't have to worry about it):
public ItemBlock(int par1)
{
super(par1);
this.blockID = par1 + 256;
}
Item.itemsList[cloth.blockID] = (new ItemCloth(cloth.blockID - 256)).setUnlocalizedName("cloth");
This was also done because it enables using the same constant with the actual ID everywhere without worrying about the difference between "offset" and "real" IDs; a lot of code like "if (id == Block.stone.blockID)" is now "if (id == BlockStates.stone", where "BlockStates.stone" is set to 1, and is inlined at compile time, avoiding the need to reference "Block.stone" while also avoiding code like "if (id == 1)" ("BlockStates" can also be a combined block ID + metadata, like 1281 (1 + 256 * 5) for "BlockStates.stone_andesite", enabling code like "if (world.getBlockState(x, y, z) == BlockStates.stone.andesite)" and avoiding the need for two separate comparisons and method calls to get the ID/metadata).
That aside, its GUI may not work as it probably depends on the GuiInventory class (though I extended the original class and only added a call to a "displayStats" method, otherwise it calls the original code that draws the GUI). I also noticed that TMI is calling it from "TMIReplaceItems.modMushroomBlock"; as with many other blocks I completely refactored/replaced the original vanilla code for mushroom blocks (both the plant and block, this includes adding items for blocks in the Creative inventory, which were not available in vanilla) - the only way any mods would be compatible is if they are rewritten to interface with my own classes.
Note that in addition to mushroom blocks I made other previously unobtainable items available in the Creative inventory, such as dragon eggs, mob spawners, and spawn eggs for giants, iron golems, and snow golems. Some items also don't exist at all anymore, such as the item form of beds, cake, and cauldrons, which all now drop the block itself (they actually had two items, one for the block and one for the "actual" item; one benefit of this change is that it makes it possible to render them in 3D, without a lot of changes to item rendering (1.6.4 only supports a generic "pseudo 3D" item model for non-block items and I did not change this).
Another thing to note - do not try loading a world created with TMCW in vanilla, no matter what version, including newer versions (some blocks do have the same IDs, such as the 1.8 stone types, but most are different, as are item, biome, and entity IDs, as well as NBT data) - I know that people have done this before because somebody said they found a minecart with command block in a dungeon chest, which only exist in 1.7 and later (the ID for them corresponds to the ID for amethyst items in TMCWv4, which is now the "strad" music disc; which reveals yet another change - all allocated item IDs are now consecutive and the size of the item list was reduced from 32000 to 512; blocks were previously changed from 4096 to 256 with basic support for "extended" IDs up to 4095 removed (this itself would require substantial refactoring to support since only the chunk storage system supported these IDs; even Mojang never attempted it, instead completely replacing the ID system in 1.13). The 256 ID limit is not seen as an issue because metadata allows for up to 4096 unique blocks (not including render-only states, e.g. fence connections and snowy grass) and I added support for metadata to change things like the light level (most of the blocks that I've added are variants of existing blocks with about 60 IDs left).
Also, I updated the download as I forgot to include the legend with biome colors used by BiomeMapper; I also updated Documentation\biomes.txt to include a list of every biome by its frequency:
I've added a download for a specially modified version of MCMap that properly renders worlds created with TMCWv5:
There are also some bugfixes and optimizations, including properly rendering some vanilla blocks which did not use the correct model/color and optimizing the underground rendering mode to map a more realistic range around torches (the original program used a +/-18 block range, which is far in excess of anything a torch can cover; I reduced it to 8 blocks by taxicab, matching the minimum light level of 6 to prevent hostile mob spawning; in practice, you'll place them closer together, for example, when branch-mining I place them every 10 blocks as that is the point where it gets too dark to see well, which is a radius of 5 blocks from a torch) and better account for "ceiling" blocks (caves above sea level only render if there are at least 2 blocks above them, excluding all variants of leaves and logs; the original version required that all caves, including below sea level, have a ceiling of 3+ blocks and due to a coding error it did not ignore leaves/logs/some other blocks; fixing this reduces the amount of "clutter" near the surface, while the relaxed ceiling requirements includes previously missing caves just below the surface).
Granite/diorite/andesite also render as stone when underground mode is used, which along with the aforementioned changes gives much clearer renderings of explored caves, as seen in this comparison between the original program and TMCWv5 version (this is actually of a world created in TMCWv4 but most blocks still render correctly):
Notably, I'd previously modified MCMap as far back as early 2014 but never released it (this example compares the original range to a circular radius of 6 blocks, which I recently changed to a taxicab distance of 8); the program itself is open-source and development has been continued by several others; unfortunately, the "original" MCMap is no longer readily available as the the forum thread by the original creator was deleted and the website created by WRIM, who took on development, is also no longer available (there is a more current version with active development but it appears to be for 1.13+ only. WRIM's version is still available on their GitHub, I modified 2.4.3 since that was the latest version I'd previously modified and it would have less vanilla 1.7+ blocks to remove/change).
I've made a significant change to mob spawning - the hostile mob cap is now split into semi-independent "surface" and "cave" caps in a similar manner to Bedrock Edition, but without that version's ridiculously low spawn rates (11/2000 per chunk per tick vs 1/4 for TMCW and 1/1 for vanilla; the difference between the latter two is not significant outside of mob farms) and mob caps (only 8 per 9x9 chunk area, which is approximately the size of the overall spawn area used by TMCW (a 5 chunk circular radius encompassing 101 chunks), with the despawn radius of 96 blocks (x and z only) encompassing about 113 chunks; together this gives an average density that is 6-7 times higher).
The overall cap was increased to 105 with each individual cap set to 70 (50% higher and the same as vanilla respectively; this does not include slimes, which were previously given a separate sub-cap of 25) and the cave cap is prioritized so it will always be full if enough mobs can spawn underground, while the surface cap takes up the remainder, averaging 35 mobs at night and rising to 70 as the cave cap drops to 35 or less. This effectively simulates locking the time to always day, which I'd done before to force mobs to spawn underground to increase the number I encounter while caving, while not affecting surface spawning, which is also a lot more consistent now (with the old system various areas had less than 20 to over 50 mobs on the surface at night. Due to an increased density due to a reduced spawning range 35 is roughly equivalent to 60 mobs in vanilla, higher than will typically be present on the surface):
Mob counts under the old system (vanilla other than a reduction in spawn/despawn ranges):
Vanilla 1.6.4 for comparison (modified to add count of surface/cave mobs); mob counts are less variable due to the larger area mobs can spawn within smoothing out the effects of variations in cave density (deserts are still more favored due to less obstructions; in particular, vanilla 1.6.4 only considers air blocks to be valid pack spawn locations, which I changed to include any transparent block as 1.8 did, thus Ice Plains in particular has a very low surface spawn rate). Also, "All: 50" indicates that only 50 entities (including non-hostile mobs) are within 80 blocks of the player, the maximum distance at which the server will send most entities to the client ("mob counts" is server-side); nearly all hostile mobs will be within this range in TMCW due to the spawn radius of 5 chunks (circular) and despawn radius of 96 blocks:
TMCW with the new spawning system; the number of mobs underground is around 70 regardless of the time of day while the surface count takes up the remainder of an overall cap of 105 (note that this is in a similar location to a previous example that had only 18 mobs on the surface due to a high cave density, thus the amount was doubled):
A Superflat world without caves; the surface count has reached its cap, as it also can if the cave count is 35 or less:
This demonstrates how mobs are counted towards a cap; either being below sea level (defined as the highest non-air layer in Superflat worlds) or the absence of sky light is used to count mobs towards the cave cap:
Also, mobs will now start spawning on the surface as soon as it gets dark enough since mobs in caves don't need to despawn, while vanilla may take as long as a minute in the worst-case (the average life of a mob is 40 seconds after an initial 30 second period and due to spawn mechanics the cap can be exceeded during a single spawn cycle so it may take a while to drop below 70 (technically, the cap is 79 in vanilla 1.6.4 due to a faulty calculation; 1.8 and later use a divisor of 289, the same as the number of chunks counted within range of a player).
ETA: After some additional playtesting I've set the individual caps to 60 and overall cap to 100 (40 on the surface at night); the reduction from 70 to 60 was mainly because I felt there were too many mobs, even for my liking, and I've still encountered about 25% more mobs per session than before. The Nether and End still use the original cap of 70.
I made a video tutorial showing how to install this mod because I see a lot of people don't know how to install JAR mods.
I've never liked the idea of having to use a 3rd party launcher; I've even made posts on other threads saying that it was possible to install their mod on the vanilla launcher (for example), and the installation steps you show don't seem any more complicated (I'm guessing the main issue with my method is modifying the jar; for some reason when I try to use 7Zip to add files it gives me an error but WinRar has no such issues. Another method that I've seen is to rename the jar to zip and use Windows File Explorer to extract/rezip it but there are class files with invalid filenames like aux.class (I tried doing this for my very first attempt at modding, before Optifine had an installer back in the 1.5 days, as that was what the instructions I found said to do, presumably referring to a older version without those files).
I installed this mod and I liked it a lot, but there is one thing that is bothering me. Looks like the battle system is different. When I try to hit with the sword, I can only do damage in the first few hits, but then the sword loses power and I have to hit the mobs a lot to kill. I've died more than 10 times because of it.
Can you explain to me how combat works in this version? Or is this a bug?
I installed this mod and I liked it a lot, but there is one thing that is bothering me. Looks like the battle system is different. When I try to hit with the sword, I can only do damage in the first few hits, but then the sword loses power and I have to hit the mobs a lot to kill. I've died more than 10 times because of it.
Can you explain to me how combat works in this version? Or is this a bug?
There is an "attack cooldown" feature - much like 1.9 you can't just spam-click or the damage dealt will be reduced; unlike 1.9 it only takes effect when you either miss or hit a mob while it is damage-immune (red) from a previous player attack - you can attack as fast as you can provided every hit lands on a mob while it is not immune (1 mob = 2 hits/second, 2 mobs = 4 hits/second, and so on).
The threshold for when missed hits increases the "penalty" is less than 1 second between attacks while holding a weapon (an item that increases damage; any other item has no effect) while damage-immune hits increase it by the maximum amount allowed per hit (this includes unarmed attacks), as shown by these two charts (20 ticks = 1 second); this is controlled by a counter which starts at -20 and increases with each missed hit, only reducing damage once it rises above 0, and capped to a maximum of 140, with the effects capped at 100, which corresponds to a 75% reduction in damage dealt; the counter is decremented once per tick so it takes up to 140 ticks or 7 seconds to drop back down to 0, and another second to completely reset:
Note that the damage shown is that of a Sharpness V amethyst sword; amethyst items have the same damage values as diamond in vanilla and all other tiers deal one less damage than before (this is similar to how 1.9 reduced the damage dealt by swords by one and the addition of netherite in 1.16 basically gives you the old diamond sword back), and stronger weapons will help since you can still kill most mobs in two hits as long as you deal at least 10 damage per hit (or three hits for at least 6.67 damage, etc); axes also penetrate armor, similar to 1.9's mechanic, so can be better against armored mobs (a Sharpness V amethyst axe kills a zombie in full diamond armor in about half as many hits. Amethyst armor has "armor toughness" which reduces the penetration effect).
The recovery time of up to 7 seconds may be a bit excessive but the occasional missed attack won't have any effect (at 2 attacks per second it takes 3 missed hits in a row to start reducing damage (the first missed hit does not count, the second increases the penalty from -20 to 0, and the third increases it from -5 to 15, at which point you are dealing 88.75% of full damage); if you alternately miss a hit, then successfully land a hit it will act as if you missed once per second, thus the penalty will never be triggered).
Also, the effectiveness of armor on players was reduced; damage reduction is 3.3% instead of 4% per armor point so iron is 50%, and diamond has 18 points instead of 20 for 60% damage reduction (the same as iron in vanilla), and amethyst reduces damage by 66.7% (these are equivalent to having 2x, 2.5x and 3x more health, compared to 2.5x and 5x for iron and diamond in vanilla). Protection enchantments were modified to remove their randomized damage (in vanilla 1.6.4 full Protection IV reduces damage by a random 40-80% while in TMCW it is a fixed 60% and the specialized enchantments, including Feather Falling, are capped at 75% instead of 52-80%; these are again similar to how 1.9 made them non-random, except 1.9 set Protection at 64% and others at 80%, though the lower protection in TMCW should be compared to the original values, not 1.9 (in particular, the original guaranteed minimum was a lot lower, best seen for fall damage - 52% only allows survival from a 44 block fall while 75% allows 82 blocks, or nearly double the distance).
I thought to note that I fixed a stronghold generation bug that causes them to be disconnected; I discovered it after finding a stronghold whose portal room was blocked off and only found because a cave intersected it; it was connected to a "5-way crossing" room, which turned out to have a bug with clearing the proper entrances/exits on the sides in specific orientations (this causes the wrong one to be cleared, which is only noticeable when only one of the two entrances leads to something):
Code and explanations of why the bug occurs and how it was fixed:
This method adds pieces to each of five entrances/exits from the room, with getNextComponentNormal adding one to the middle of the wall in front of the archway and adding two to each side, at floor level and above the archway; if the orientation is 1 or 2 it swaps their order (only the y-offset appears to change but the x/z offsets also change). The comment added indicates a minor tweak I made, which is to set the fields that determine whether to add pieces to an exit to false if they failed to prevent "false" openings; this has no impact on the bug:
public void buildComponent(StructureComponent par1StructureComponent, List par2List, Random par3Random)
{
int var4 = 3;
int var5 = 5;
if (this.coordBaseMode == 1 || this.coordBaseMode == 2)
{
var4 = 5;
var5 = 3;
}
this.getNextComponentNormal((ComponentStrongholdStairs2)par1StructureComponent, par2List, par3Random, 5, 1);
// When set to true these fields also cause entrances to be cleared; set to false if no piece could be added
if (this.field_74996_b && this.getNextComponentX((ComponentStrongholdStairs2)par1StructureComponent, par2List, par3Random, var4, 1) == null) this.field_74996_b = false;
if (this.field_74997_c && this.getNextComponentX((ComponentStrongholdStairs2)par1StructureComponent, par2List, par3Random, var5, 7) == null) this.field_74997_c = false;
if (this.field_74995_d && this.getNextComponentZ((ComponentStrongholdStairs2)par1StructureComponent, par2List, par3Random, var4, 1) == null) this.field_74995_d = false;
if (this.field_74999_h && this.getNextComponentZ((ComponentStrongholdStairs2)par1StructureComponent, par2List, par3Random, var5, 7) == null) this.field_74999_h = false;
}
This is part of the code that actually generates the structure; vanilla does not account for the aforementioned change in orientation so it ends up clearing away the wrong exits (it always uses the code in the "else" block):
public boolean addComponentParts(World par1World, Random par2Random, StructureBoundingBox par3StructureBoundingBox)
{
this.fillWithRandomizedBlocks(par1World, par3StructureBoundingBox, 0, 0, 0, 9, 8, 10, true, par2Random, StructureStrongholdPieces.getStrongholdStones());
this.placeDoor(par1World, par2Random, par3StructureBoundingBox, this.field_143013_d, 4, 3, 0);
// Swaps order entrances are cleared in to fix a bug that causes the wrong one to be cleared, blocking the correct one
if (this.coordBaseMode == 1 || this.coordBaseMode == 2)
{
if (this.field_74996_b) this.fillWithBlocks(par1World, par3StructureBoundingBox, 0, 5, 7, 0, 7, 9, 0, 0, false);
if (this.field_74997_c) this.fillWithBlocks(par1World, par3StructureBoundingBox, 0, 3, 1, 0, 5, 3, 0, 0, false);
if (this.field_74995_d) this.fillWithBlocks(par1World, par3StructureBoundingBox, 9, 5, 7, 9, 7, 9, 0, 0, false);
if (this.field_74999_h) this.fillWithBlocks(par1World, par3StructureBoundingBox, 9, 3, 1, 9, 5, 3, 0, 0, false);
}
else
{
if (this.field_74996_b) this.fillWithBlocks(par1World, par3StructureBoundingBox, 0, 3, 1, 0, 5, 3, 0, 0, false);
if (this.field_74997_c) this.fillWithBlocks(par1World, par3StructureBoundingBox, 0, 5, 7, 0, 7, 9, 0, 0, false);
if (this.field_74995_d) this.fillWithBlocks(par1World, par3StructureBoundingBox, 9, 3, 1, 9, 5, 3, 0, 0, false);
if (this.field_74999_h) this.fillWithBlocks(par1World, par3StructureBoundingBox, 9, 5, 7, 9, 7, 9, 0, 0, false);
}
This is also mentioned in the Wiki, if not as a bug, and indicating that it still happens in the latest versions (they link to a video from 1.14 which shows a blocked entrance next to an incorrectly cleared entrance; in this case the blocked entrance has an iron door with a button which was inset in the wall so it was obvious but this is not always the case):
Sometimes, doors can be sealed off by stone bricks, resulting in "secret doors", usually occurring with 5-way crossings.
Incidentally, there was a similar bug with mineshafts; the game clears out a small "room" at the entrances to the central room to ensure they are clear due to the top of the room curving inwards; this piece was always aligned to the top of the bounding box of the connecting piece but this was incorrect for 2-story high crossings, which could even be higher than the ceiling of the room, thus not connect at all, as well as being too wide (5 blocks when it should be 3); I fixed this a while back, along with a much older vanilla bug in TMCWv1 (the "ocean bubbles" bug, which was due to these rooms not being offset with the rest of the structure).
I've also been making various small updates, just not announcing every one; for example, I recently added "Swift Sneak" and "Long Fall" enchantments as "rare"/"semi-treasure" enchantments (you can get them from the table but they are much rarer than most enchantments; conversely, they are much more common than other enchantments in mineshafts). Swift Sneak is directly based on the enchantment being added to 1.19 (so yes, TMCW officially has it before vanilla, similar to various other features; e.g. I added the 1.8 stones while 1.8 was still in snapshots) while Long Fall increases the distance you can fall without taking damage by 1 block per level (up to 7 blocks at level IV), but is mutually exclusive with Feature Falling (it can be very useful though in situations where you regularly take damage from lots of small falls; when combined with full Protection IV the maximum survivable fall distance is 56 blocks, compared to 82 with Feather Falling).
Also, I think it is an extremely bad practice to have any sort of long-term list of pending bugs that need to be fixed - I fix bugs as soon as they are discovered (I actually did know about the stronghold bug before but not exactly why it happened, or that it wasn't intentional), in contrast with most mods, and especially vanilla (worst of all are extremely simple bugfixes or bugs with fixes provided, such as MC-2025 - there is absolutely no reason why mobs should still be suffocating in or glitching through walls; the fix in this comment is the one that I used - just a simple addition of a "margin", which I set to a more conservative 1 millionth, plus a 1 billionth margin added to y to be extra safe. Granted, there might be edge cases where it still happens but I've never noticed it since fixing it, and the related MC-9568, also using a fix provided with that report). Nothing beats Mojang's refusal/inability to fix a bug in Bedrock Edition that causes no portal room to be generated (it was even closed as "works as intended" for a while), which is avoided with a single line of code (as a loop) in Java Edition:
This is my own code; vanilla only checks if a portal room is present; my additions ensure that strongholds have a decently large minimum size (vanilla can rarely generate strongholds with just a few rooms; on average, the portal room fails to generate about 5-10% of the time, with a similar chance of less than 100 pieces, so the loop doesn't iterate more than once or twice in most cases):
protected StructureStart getStructureStart(int chunkX, int chunkZ)
{
StructureStrongholdStart start;
// Changed getComponents().empty() to getComponents().size() < 100 to ensure that strongholds generate with
// a minimum size (also changed portal rooms to generate at least 10 rooms from the start instead of 5).
do
{
start = new StructureStrongholdStart(this.worldObj, this.rand, chunkX, chunkZ);
}
while (start.getComponents().size() < 100 || ((ComponentStrongholdStairs2)start.getComponents().get(0)).strongholdPortalRoom == null);
return start;
}
Also of interest, while testing I found the tallest stronghold I've ever seen; the top is at y=65, above sea level, while the lowest floor is at y=2 (it is at "148 55 3028" in the seed "-4426978636490490569"; this is the same seed I'm currently playing on but this is too far away for me to ever find it; the stronghold shown above is at "260 34 1396" in the same seed, which I discovered while caving; if I'd found it with eyes of ender it would have been frustrating to find the portal room. The y-coordinates, which I recently added to CaveFinder's output, are at the bottom of the starting staircase):
So, is there a way to disable this combat feature? The changes in combat system is what keeps me from playing Minecraft 1.9+. I can play 1.18 just fine, but I still think that 1.8 combat still rocks and keep playing 1.8. Now I knew this mod and liked it, but noticed the changesd in combat. Not so bad as 1.9, but it still bothers me.
"log4j" is only used by newer versions (1.7 and later); you surely didn't try installing TMCW in a newer version, did you? The instructions specifically state to use 1.6.4 (not to be confused with 1.16.4), and like nearly any other mod it will only work with that version.
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Sorry, somehow I was installing it on 1.16.4, my bad. It works flawlessly.
How do you install directly into the jar? I try to copy files over using Open in my ZIP program BreeZip, and it says 'file already exists'. I then try to delete files and it gets corrupted...
I'm not sure why so many archivers have problems with adding files to the jar but WinRar doesn't have this issue (I also have 7Zip and it gives me an error when I try to add files; using Windows' file explorer, as some mod installation instructions tell you to do (rename to .zip and extract, add files, then rezip and rename to .jar), will not work for 1.6.4 and many other versions because one of the class files is named aux.class, which is an invalid Windows filename and it is possible this also affects zip tools even when within an archive).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Great concept! I wish I found this mod earlier. I've also been working on something similar, but for Beta 1.7.3 for the past few months.
BetterCraft 0.7
I just can't seem to get this to work. It just opens a normal vanilla 1.6.4, not a title TheMasterCaver's World and no granite blocks etc
How did you install it? You need to make a copy of the ".minecraft\versions\1.6.4" folder and rename it and the 1.6.4.jar file inside to "TMCWv4.5" and replace the json file with the one which is included in the download (make sure it is deleted, don't just add my file, and directly add the files inside the "mod" folder in the zip you downloaded to the jar, deleting META-INF (if you don't do this the game won't launch and you'll get an error about an invalid signature); this mod will not work if you try to add it to the ".minecraft\mods" folder, as you would with Forge or other mod loaders (Forge will probably just ignore it with a warning about an invalid mod file).
You can use a name other than "TMCWv4.5" for the folder and files but you have to make sure to edit the json so the "id" inside matches, and in any case it must not match any vanilla version, otherwise the launcher will detect the jar as corrupt because the checksum doesn't match and redownload it (i.e. it launches as vanilla).
Obviously, you also need to make sure it is selected in the launcher profile, ideally by using a separate profile with its own game directory (I use a different name for options.txt so it won't conflict with vanilla, especially newer versions, but you still want worlds to be separate; versions prior to 1.7 also saved statistics in the "stats" folder, which will also conflict).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
The update history of TMCWv5 goes back about 4 years, with the first period of development starting in early 2018 and continuing through the end of the year, after which I got sidetracked by making my own "Optifine replacement" and massive refactoring of the vanilla codebase, which took another year, but was very well worth it in the end. I then merged this mod, which I call "World1" as I use it when playing on my first world (this was developed completely independently of TMCW but included its early optimizations/refactors, as well ones I previously made to a personal modified copy of Optifine at least as far back as 2015) with TMCWv4 and released it, along with about half the features I'd added to TMCWv5 at the time, as TMCWv4.5, the name of which is derived from TMCWv4 and TMCWv5, as opposed to indicating an intermediate version (e.g. 1.6, 1.6.1, 1.6.2, etc); this was still considered to be version 4 as world generation was not altered, aside from some minor bugfixes.
Merging World1 with TMCWv5 was much more complex because I'd already made many core changes, including many hacks to avoid having to directly modify classes modified by Optifine as I still wanted it to be compatible at the time; I did this by incrementally adding TMCWv5 code to TMCWv4.5 until I'd reach a point where I figured I could just merge TMCWv4.5 with TMCWv5 (with the help of a tool to show code differences), which took a couple months. Some of the code I originally wrote back in 2018 has been refactored multiple times, further increasing development time, but in the end it was well worth it (for example, when I first added "water plants" they could only be placed if they were entirely submerged because they would cause "air" bubbles (water did not render adjacent to them so the "air" was invisible unless it was at the surface, adjacent to glass, etc); by modifying the rendering system I was able to make blocks render on both render passes (opaque/transparent and translucent), which was impossible without overwriting classes modified by Optifine). I then spent the first half of 2021 adding more content and tweaking/fixing existing features, then the past month on making final additions/changes/bugfixes before releasing it today.
Another factor in the time it took is the time I spent on actually playing the game, which is usually an "either" and not "both" situation when it comes to allocating my "Minecraft time" (I usually only play or work on mods, not both, and usually over extended periods of weeks, not alternating days or the like), and even my first world/World1 mod is quite enjoyable despite not having any new biomes or underground features and only the less vanilla-altering gameplay changes.
Note that due to the size and complexity of TMCWv5 there is less confidence than usual that it is free of any significant bugs, which will always be present to some degree; a common claim is that there are 15-50 bugs per 1000 lines of code, which seems insanely high (due to lack of popularity some significant bugs have gone undetected/reported for years; when TMCWv4 was released it had a bug where Mending only worked if it was the last enchantment to be added; I only discovered this about 3 years later when I decided to add Unbreaking to my armor to take advantage of a change made in TMCWv4.5 which made it more effective (Unbreaking III gives 2x durability instead of 1.43x, which is still half the effectiveness as on tools), and because I hadn't been finding enough amethyst recently to keep up with repairs (I still had plenty, and did start finding more before it would be an issue). If anybody else had experienced this it was either unnoticed or never reported (Mending is probably the last enchantment that will be added to an item; this is even more so in TMCWv5 as I made it so the cost to add Mending is the cost to repair the item, preventing you from making items too expensive to be repaired unless you add more enchantments after Mending).
Also, this is a more detailed look at the seed I featured in the update description for version 5, "6511199847387183207", which has many new and/or rare biomes close to spawn in addition to the largest known cave:
Spawn itself is in a Mega Tree Plains, with a Jungle to the east and a small Rocky Mountains to the west, and further to the north is one of the new biomes added in TMCWv5, Iceland:
A top-down view from above spawn; there is a jungle temple in the jungle near the right edge:
Further to the west is another new biome, Autumnal Forest, with new types of trees and mobs; they may also have a new structure though one isn't present in this biome. Also visible is part of a Desert M, which contains the rarest biome by area, Oasis (fun fact - it is possible to spawn in an Oasis but highly unlikely):
Mushroom Forests can be found to the northeast of spawn as well as to the west of the Autumnal Forest, along with another Iceland and an Ice Plains with Ice Hills; the main features of this biome are the foliage color and surface mushrooms in every color (they can also be found in larger caves underground):
North of the Iceland is a Big Birch Forest, with large birch trees in 1x1 and 2x2 forms:
Further to the northwest is a Roofed Forest with a woodland mansion; while nowhere near as rare as they are in vanilla they are still the rarest structure in TMCW, in part due to the rarity of any one biome and the failure rate due to uneven terrain (all my own structures require that the ground be flat enough):
The southern part of the Desert M contains a small village next to an enormous ravine which goes all the way from the surface down to lava level; while quite large they can get much larger, 368 blocks long and 50 blocks wide and over 600,000 blocks in volume (while ravines are normally about 3 times deeper than their width larger ravines have a reduced ratio and they may bee too low/high up so even the widest ravines may not break the surface; the maximum floor-ceiling depth is about 70 blocks, or +/-35 from the center altitude):
A bit further from spawn is the enormous cave that is the highlight of this seed, the largest single cave that I've found within 2048 blocks of spawn in several thousand seeds; the cave is so huge it goes out of render distance even at 16 chunks:
As if that wasn't enough, there is another enormous cave just to the north; both caves combined have a volume of more than 1.5 million blocks, which is still less than the average giant cave region, the largest underground structure (technically a type of cave system as it is made up of many individual caves, hence why I say largest single cave):
Also, the jungle to the east of spawn contains jungle caves, a new "lush cave" variant which generates in jungles and tropical swamps (the screenshots are from a different world as I didn't see them until I used Minutor to map the world). You'll also notice that other caves have a lot of vegetation in them, including vines and patches of grass with "cave grass" (a variant of tall grass which doesn't need light):
Here is a surface map made with Minutor:
A biome map made with the BiomeMapper tool, with a radius of 2048 blocks from 0,0 (the grid is 512 blocks):
Maps of the underground made with the CaveFinder tool (I used this instead of Unmined as it has more contrast and is free of underground lakes), centered at 0, -512 with a radius of 768 blocks; the second map only shows "special" caves (caves/ravines with a volume of at least 25000 blocks, circular rooms with a diameter of at least 34 blocks, larger "vanilla" large caves (some may actually exceed 25000 blocks but will not be listed, only my "custom" large caves) and new cave variations, except for the smallest "cave clusters" and "jungle caves". Dungeons are also not listed because they require the world to actually be generated, likewise, jungle caves and biome-specific variations like more caves above sea level in mesas require that the biome be known):
A listing of underground features found by CaveFinder within 1024 blocks of 0, -512 (the maps above are slightly smaller due to Imgur's 1 MB limit without resizing/reducing quality); note also the underground volume given at the end, which is nearly triple that of vanilla 1.7-1.17 and double that of vanilla 1.6.4, and the highest of any of my mods in terms of percentage of blocks between cave lava level and sea level. About 75% of this is due to larger caves and special cave variations (even "normal" caves have more variation than in vanilla):
A new feature of CaveFinder is that it adds a "caveinfo" option which shows details for "normal" cave systems, even listing the "size" of each individual cave system within the area ("caveinfo 1" only lists the center chunk and overall stats while "caveinfo 2" also lists individual cave systems, of which a small sample is shown; the second option should not be used with a large radius); this also shows all the ways I vary normal caves:
Also, you can easily experience every biome by giving a world a name starting with "debug_biomes", which will enable a special mode where every Overworld biome is laid out in a 14x9 grid with each biome being 4x4 chunks; there is another mode, "debug_flat", that generates a Superflat-like world with normal biome generation but there are only biome-specific ground blocks, caves, and structures (both of these were in TMCWv4.5 but could only be enabled with a flag in code at development time):
In addition, the OP has been refactored so all the previous update descriptions were moved to the comment section, replacing comments which described new features added by that update (it got so large that it actually exceeded the character limit and had nearly 200 images so this should also reduce loading times).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Oof, I was making a resource pack for v4.5 and just found an update. Well, I’ll share a piece anyway.
I edited the water biome colors so that each biome matches the water color that is at the corresponding coordinates of the unused watercolor.png texture from Minecraft b1.6–1.5.2, matching the coordinates of the grass and foliage colors.
This is what came out (UPDATED for v5) and I think it looks really nice with TMCW water textures and biomes.
(remade after the v5 release, edited the changed colors and added new ones)
P. S. Vanilla (unused) watercolor.png from pre-1.6:
P.P.S. V5 is super awesome!
Crashed when opening inventory with TooManyItems:
---- Minecraft Crash Report ----
// Uh... Did I do that?
Time: 1/12/22 2:59 PM
Description: Unexpected error
java.lang.ArrayIndexOutOfBoundsException: -157
at yc.<init>(Item.java:271)
at zh.<init>(SourceFile:17)
at TMIReplaceItems$MetadataBlock.<init>(TMIReplaceItems.java:18)
at TMIReplaceItems.modMushroomBlock(TMIReplaceItems.java:93)
at TMIReplaceItems.replaceItemsOnce(TMIReplaceItems.java:53)
at TMIController.onCreate(TMIController.java:52)
at awy.<init>(awy.java:45)
at axp.<init>(SourceFile:16)
at axv.<init>(SourceFile:20)
at GuiInventoryTMCW.<init>(GuiInventoryTMCW.java:38)
at atv.k(Minecraft.java:1518)
at atv.S(Minecraft.java:743)
at atv.d(Minecraft.java:683)
at net.minecraft.client.main.Main.main(SourceFile:101)
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- Head --
Stacktrace:
at yc.<init>(Item.java:271)
at zh.<init>(SourceFile:17)
at TMIReplaceItems$MetadataBlock.<init>(TMIReplaceItems.java:18)
at TMIReplaceItems.modMushroomBlock(TMIReplaceItems.java:93)
at TMIReplaceItems.replaceItemsOnce(TMIReplaceItems.java:53)
at TMIController.onCreate(TMIController.java:52)
at awy.<init>(awy.java:45)
at axp.<init>(SourceFile:16)
at axv.<init>(SourceFile:20)
at GuiInventoryTMCW.<init>(GuiInventoryTMCW.java:38)
-- Affected level --
Details:
Level name: MpServer
All players: 1 total; [bdi['TheRealTTSV'/1, l='MpServer', x=60.50, y=65.62, z=-76.50]]
Chunk stats: 205
Level seed: 0
Level generator: ID 00 - default, ver 1. Features enabled: false
Level generator options:
Level spawn location: World: (52,63,-84), Chunk: (at 4,3,12 in 3,-6; contains blocks 48,0,-96 to 63,255,-81), Region: (0,-1; contains chunks 0,-32 to 31,-1, blocks 0,0,-512 to 511,255,-1)
Level time: 114 game time, 114 day time
Level dimension: 0
Level storage version: 0x00000 - Unknown?
Level weather: Rain time: 0 (now: false), thunder time: 0 (now: false)
Level game mode: Game mode: survival (ID 0). Hardcore: false. Cheats: false
Forced entities: 155 total; [EntityFish['Fish'/512, l='MpServer', x=30.50, y=60.00, z=-111.50], EntityFish['Fish'/513, l='MpServer', x=31.50, y=60.22, z=-111.50], EntitySkeletonTMCW['Skeleton'/2, l='MpServer', x=60.50, y=43.00, z=-65.50], EntitySkeletonTMCW['Skeleton'/260, l='MpServer', x=-3.50, y=19.00, z=-23.50], EntitySkeletonTMCW['Skeleton'/261, l='MpServer', x=-6.50, y=19.00, z=-22.50], EntitySkeletonTMCW['Skeleton'/262, l='MpServer', x=-8.50, y=19.00, z=-23.50], EntitySkeletonTMCW['Skeleton'/263, l='MpServer', x=-12.50, y=19.00, z=-21.50], EntityZombieTMCW['Zombie'/264, l='MpServer', x=55.50, y=18.00, z=-89.50], EntityBatTMCW['Bat'/274, l='MpServer', x=24.28, y=13.00, z=-155.53], su['entity.MinecartChest.name'/31, l='MpServer', x=-17.50, y=28.50, z=-103.50], EntityBatTMCW['Bat'/40, l='MpServer', x=-18.27, y=16.86, z=-55.20], EntityBatTMCW['Bat'/552, l='MpServer', x=34.50, y=13.00, z=-13.50], su['entity.MinecartChest.name'/41, l='MpServer', x=-11.50, y=27.34, z=-89.50], EntitySilverfishTMCW['Silverfish'/42, l='MpServer', x=-4.04, y=21.00, z=-31.30], EntityBatTMCW['Bat'/556, l='MpServer', x=45.50, y=4.00, z=-89.50], EntityBatTMCW['Bat'/557, l='MpServer', x=44.50, y=4.00, z=-89.50], rr['Cow'/46, l='MpServer', x=7.50, y=63.00, z=-96.50], rr['Cow'/47, l='MpServer', x=4.09, y=65.00, z=-88.47], rr['Cow'/48, l='MpServer', x=6.39, y=64.00, z=-90.22], rr['Cow'/49, l='MpServer', x=3.28, y=64.00, z=-89.66], EntitySkeletonTMCW['Skeleton'/50, l='MpServer', x=13.50, y=45.00, z=-43.50], rq['Chicken'/55, l='MpServer', x=26.50, y=70.00, z=-153.50], rq['Chicken'/56, l='MpServer', x=26.50, y=70.00, z=-153.50], rq['Chicken'/57, l='MpServer', x=27.50, y=70.00, z=-152.50], rq['Chicken'/58, l='MpServer', x=29.50, y=70.00, z=-154.50], EntityZombieTMCW['Zombie'/59, l='MpServer', x=31.50, y=31.00, z=-141.50], EntityCreeperTMCW['Creeper'/60, l='MpServer', x=24.50, y=27.00, z=-84.50], EntityCreeperTMCW['Creeper'/61, l='MpServer', x=26.50, y=27.00, z=-80.50], rq['Chicken'/62, l='MpServer', x=27.47, y=67.00, z=-82.47], su['entity.MinecartChest.name'/63, l='MpServer', x=31.50, y=22.50, z=-71.50], EntitySpiderTMCW['Spider'/64, l='MpServer', x=25.42, y=27.00, z=-72.44], rq['Chicken'/65, l='MpServer', x=29.50, y=65.00, z=-76.50], rq['Chicken'/66, l='MpServer', x=26.50, y=66.00, z=-76.50], EntityBatTMCW['Bat'/322, l='MpServer', x=135.80, y=20.18, z=-103.56], rq['Chicken'/67, l='MpServer', x=27.50, y=66.00, z=-79.50], ry['Pig'/68, l='MpServer', x=27.78, y=64.00, z=-54.50], EntityBatTMCW['Bat'/324, l='MpServer', x=137.45, y=20.18, z=-102.65], ry['Pig'/69, l='MpServer', x=26.44, y=64.00, z=-54.81], ry['Pig'/70, l='MpServer', x=25.19, y=64.00, z=-53.19], ry['Pig'/71, l='MpServer', x=26.50, y=64.00, z=-49.50], rr['Cow'/72, l='MpServer', x=25.55, y=64.00, z=-34.56], rr['Cow'/73, l='MpServer', x=26.59, y=64.00, z=-35.72], rr['Cow'/74, l='MpServer', x=28.50, y=64.00, z=-38.50], rr['Cow'/75, l='MpServer', x=28.50, y=64.00, z=-31.50], EntityZombieTMCW['Zombie'/82, l='MpServer', x=35.50, y=14.00, z=-150.50], EntityZombieTMCW['Zombie'/83, l='MpServer', x=32.50, y=13.00, z=-154.50], EntityHorseTMCW['Horse'/84, l='MpServer', x=36.06, y=70.00, z=-145.69], EntityHorseTMCW['Horse'/85, l='MpServer', x=36.50, y=70.00, z=-141.50], EntityHorseTMCW['Horse'/86, l='MpServer', x=38.50, y=71.00, z=-140.50], EntityHorseTMCW['Horse'/87, l='MpServer', x=34.50, y=70.00, z=-138.50], EntityHorseTMCW['Horse'/88, l='MpServer', x=36.50, y=70.00, z=-143.53], ss['item.item.seeds'/89, l='MpServer', x=47.39, y=64.13, z=-73.32], EntityCreeperTMCW['Creeper'/90, l='MpServer', x=37.50, y=53.00, z=-38.50], rq['Chicken'/91, l='MpServer', x=47.17, y=69.00, z=-2.41], rq['Chicken'/92, l='MpServer', x=45.50, y=68.00, z=-2.50], EntityZombieTMCW['Zombie'/99, l='MpServer', x=52.50, y=55.00, z=-137.50], EntitySkeletonTMCW['Baby Skeleton'/100, l='MpServer', x=50.50, y=27.00, z=-35.50], EntitySkeletonTMCW['Baby Skeleton'/101, l='MpServer', x=50.50, y=27.00, z=-31.50], EntityBatTMCW['Bat'/102, l='MpServer', x=55.84, y=21.26, z=-23.93], rq['Chicken'/103, l='MpServer', x=51.50, y=70.00, z=-4.50], rq['Chicken'/104, l='MpServer', x=47.72, y=69.00, z=-2.56], su['entity.MinecartChest.name'/106, l='MpServer', x=64.50, y=25.50, z=-87.50], su['entity.MinecartChest.name'/107, l='MpServer', x=73.50, y=28.50, z=-81.50], EntityZombieTMCW['Zombie'/108, l='MpServer', x=70.50, y=18.00, z=-40.50], EntityCaveSpiderTMCW['Cave Spider'/109, l='MpServer', x=74.50, y=7.00, z=-1.50], EntitySkeletonTMCW['Skeleton'/110, l='MpServer', x=77.50, y=21.00, z=-15.50], EntitySkeletonTMCW['Skeleton'/111, l='MpServer', x=78.50, y=21.00, z=-14.50], EntityBatTMCW['Bat'/112, l='MpServer', x=75.56, y=39.00, z=-10.28], rq['Chicken'/113, l='MpServer', x=71.50, y=77.00, z=-12.50], rq['Chicken'/114, l='MpServer', x=71.50, y=77.00, z=-10.50], rq['Chicken'/115, l='MpServer', x=68.50, y=77.00, z=-11.50], rq['Chicken'/116, l='MpServer', x=70.50, y=77.00, z=-11.50], ry['Pig'/118, l='MpServer', x=93.50, y=66.00, z=-128.50], ry['Pig'/119, l='MpServer', x=91.88, y=62.33, z=-124.11], ry['Pig'/120, l='MpServer', x=91.81, y=63.00, z=-125.53], ry['Pig'/121, l='MpServer', x=92.50, y=64.00, z=-126.50], rr['Cow'/122, l='MpServer', x=95.50, y=69.00, z=-103.50], rr['Cow'/123, l='MpServer', x=91.78, y=70.00, z=-100.22], rr['Cow'/124, l='MpServer', x=89.59, y=70.00, z=-101.62], su['entity.MinecartChest.name'/125, l='MpServer', x=84.50, y=19.50, z=-40.50], EntityCreeperTMCW['Creeper'/381, l='MpServer', x=31.50, y=47.00, z=-74.50], ry['Pig'/126, l='MpServer', x=87.20, y=70.00, z=-45.69], EntityCreeperTMCW['Creeper'/382, l='MpServer', x=18.50, y=47.00, z=-78.50], ry['Pig'/127, l='MpServer', x=91.50, y=71.00, z=-42.50], EntityCreeperTMCW['Creeper'/383, l='MpServer', x=-8.50, y=30.00, z=-102.50], ry['Pig'/128, l='MpServer', x=88.91, y=70.00, z=-46.56], EntityCreeperTMCW['Creeper'/384, l='MpServer', x=-11.50, y=30.00, z=-99.50], ry['Pig'/129, l='MpServer', x=89.81, y=70.00, z=-44.88], EntityCreeperTMCW['Creeper'/385, l='MpServer', x=-13.50, y=30.00, z=-98.50], su['entity.MinecartChest.name'/130, l='MpServer', x=93.50, y=18.50, z=-21.50], EntityEndermanTMCW['Enderman'/386, l='MpServer', x=-8.50, y=20.00, z=-65.50], EntityEndermanTMCW['Enderman'/387, l='MpServer', x=-7.50, y=20.00, z=-64.50], rr['Cow'/137, l='MpServer', x=97.50, y=68.00, z=-103.50], EntityZombieTMCW['Zombie'/138, l='MpServer', x=108.50, y=7.00, z=-77.50], su['entity.MinecartChest.name'/139, l='MpServer', x=101.50, y=20.34, z=-75.50], su['entity.MinecartChest.name'/140, l='MpServer', x=103.50, y=20.34, z=-70.50], EntitySkeletonTMCW['Skeleton'/141, l='MpServer', x=101.50, y=19.00, z=-18.50], EntitySkeletonTMCW['Skeleton'/142, l='MpServer', x=101.50, y=19.00, z=-12.50], EntitySkeletonTMCW['Skeleton'/143, l='MpServer', x=103.50, y=19.00, z=-11.50], rq['Chicken'/148, l='MpServer', x=122.09, y=64.00, z=-82.44], EntitySilverfishTMCW['Silverfish'/404, l='MpServer', x=106.50, y=28.00, z=-50.50], rq['Chicken'/149, l='MpServer', x=123.41, y=63.00, z=-83.06], EntitySquidTMCW['Squid'/151, l='MpServer', x=119.14, y=62.39, z=-89.47], rq['Chicken'/152, l='MpServer', x=121.31, y=64.00, z=-81.34], EntitySilverfishTMCW['Silverfish'/408, l='MpServer', x=106.84, y=28.00, z=-54.06], rq['Chicken'/153, l='MpServer', x=118.43, y=64.00, z=-84.26], EntitySilverfishTMCW['Silverfish'/409, l='MpServer', x=107.67, y=28.00, z=-50.38], EntityRabbit['Rabbit'/154, l='MpServer', x=127.50, y=75.00, z=-17.50], EntityRabbit['Rabbit'/155, l='MpServer', x=125.53, y=74.00, z=-18.22], EntityRabbit['Rabbit'/156, l='MpServer', x=125.37, y=74.92, z=-18.79], EntityCreeperTMCW['Creeper'/157, l='MpServer', x=112.50, y=25.00, z=-8.50], EntityRabbit['Rabbit'/159, l='MpServer', x=131.50, y=67.00, z=-105.50], EntityRabbit['Rabbit'/160, l='MpServer', x=131.50, y=67.00, z=-105.50], EntityRabbit['Rabbit'/161, l='MpServer', x=133.50, y=67.00, z=-105.50], EntityRabbit['Rabbit'/162, l='MpServer', x=131.50, y=66.00, z=-104.50], EntitySilverfishTMCW['Silverfish'/421, l='MpServer', x=25.50, y=50.00, z=2.50], EntitySkeletonTMCW['Skeleton'/166, l='MpServer', x=140.50, y=49.00, z=-40.50], EntitySkeletonTMCW['Skeleton'/167, l='MpServer', x=138.50, y=49.00, z=-35.50], EntitySkeletonTMCW['Skeleton'/168, l='MpServer', x=140.50, y=49.00, z=-44.50], su['entity.MinecartChest.name'/169, l='MpServer', x=138.50, y=26.50, z=-8.50], EntityZombieTMCW['Zombie'/428, l='MpServer', x=-13.50, y=20.00, z=-66.50], EntityZombieTMCW['Zombie'/429, l='MpServer', x=-14.50, y=20.00, z=-66.50], EntityZombieTMCW['Zombie'/430, l='MpServer', x=-15.50, y=20.00, z=-66.50], EntityZombieTMCW['Zombie'/432, l='MpServer', x=-15.50, y=20.00, z=-64.50], EntityZombieTMCW['Zombie'/440, l='MpServer', x=134.50, y=32.00, z=-25.50], bdi['TheRealTTSV'/1, l='MpServer', x=60.50, y=65.62, z=-76.50], EntitySkeletonTMCW['Skeleton'/189, l='MpServer', x=28.50, y=26.00, z=-75.50], EntityCreeperTMCW['Creeper'/445, l='MpServer', x=53.50, y=27.00, z=-104.50], EntityZombieTMCW['Baby Zombie'/193, l='MpServer', x=-7.50, y=20.00, z=-18.50], EntitySkeletonTMCW['Skeleton'/194, l='MpServer', x=117.50, y=26.00, z=-26.50], EntitySkeletonTMCW['Skeleton'/195, l='MpServer', x=112.50, y=26.00, z=-28.50], EntitySkeletonTMCW['Skeleton'/196, l='MpServer', x=123.50, y=26.00, z=-24.50], EntitySkeletonTMCW['Skeleton'/197, l='MpServer', x=129.50, y=26.00, z=-22.50], EntityCreeperTMCW['Creeper'/198, l='MpServer', x=-2.50, y=45.00, z=-122.50], EntityCreeperTMCW['Creeper'/199, l='MpServer', x=-5.50, y=45.00, z=-121.50], EntitySkeletonTMCW['Skeleton'/455, l='MpServer', x=24.50, y=25.00, z=-65.50], EntityBatTMCW['Bat'/200, l='MpServer', x=123.28, y=27.14, z=-24.56], EntityZombieTMCW['Zombie'/456, l='MpServer', x=64.50, y=27.00, z=-29.86], EntityZombieTMCW['Zombie'/457, l='MpServer', x=63.50, y=27.00, z=-24.50], EntityZombieTMCW['Zombie'/458, l='MpServer', x=66.50, y=27.00, z=-27.50], EntityZombieTMCW['Zombie'/459, l='MpServer', x=58.50, y=27.00, z=-32.50], EntityBatTMCW['Bat'/215, l='MpServer', x=102.25, y=44.25, z=-21.72], EntityZombieTM
CW['Zombie'/222, l='MpServer', x=-13.50, y=45.00, z=-122.50], EntityZombieTMCW['Zombie'/223, l='MpServer', x=-14.50, y=45.00, z=-121.50], EntityZombieTMCW['Zombie'/224, l='MpServer', x=-11.50, y=45.00, z=-117.50], EntityZombieTMCW['Zombie'/225, l='MpServer', x=-11.50, y=45.00, z=-116.50], EntityBatTMCW['Bat'/226, l='MpServer', x=-8.28, y=20.57, z=-25.53], EntityBatTMCW['Bat'/227, l='MpServer', x=-5.41, y=20.26, z=-27.09], EntityBatTMCW['Bat'/230, l='MpServer', x=70.43, y=29.28, z=-108.70], EntityBatTMCW['Bat'/231, l='MpServer', x=72.33, y=29.48, z=-108.50], EntityBatTMCW['Bat'/232, l='MpServer', x=80.22, y=44.89, z=-36.13], EntitySkeletonTMCW['Skeleton'/233, l='MpServer', x=56.50, y=29.00, z=-119.50], EntityFish['Fish'/509, l='MpServer', x=38.50, y=62.00, z=-104.50], EntityFish['Fish'/510, l='MpServer', x=39.50, y=62.00, z=-105.50], EntityFish['Fish'/511, l='MpServer', x=30.50, y=60.00, z=-105.50]]
Retry entities: 0 total; []
Server brand: vanilla
Server type: Integrated singleplayer server
Stacktrace:
at WorldClientFix.a(WorldClientFix.java:300)
at atv.b(Minecraft.java:2049)
at atv.d(Minecraft.java:708)
at net.minecraft.client.main.Main.main(SourceFile:101)
-- System Details --
Details:
Minecraft Version: 1.6.4
Operating System: Windows 10 (amd64) version 10.0
Java Version: 1.8.0_51, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 425863472 bytes (406 MB) / 503316480 bytes (480 MB) up to 2147483648 bytes (2048 MB)
JVM Flags: 8 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx2G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=32M
AABB Pool Size: 11613 (650328 bytes; 0 MB) allocated, 2 (112 bytes; 0 MB) used
Suspicious classes: GuiInventoryTMCW, ParticleRenderer, GuiIngameTMCW, ...]
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
Launched Version: TMCWv5
LWJGL: 2.9.0
OpenGL: Intel(R) UHD Graphics 620 GL version 4.6.0 - Build 27.20.100.8681, Intel
Is Modded: Very likely; Jar signature invalidated
Type: Client (map_client.txt)
Resource Pack: EPIC Resource Pack.zip
Current Language: English (US)
Profiler Position: N/A (disabled)
Vec3 Pool Size: 2151 (120456 bytes; 0 MB) allocated, 11 (616 bytes; 0 MB) used
Please note the OP:
Specifically, in this case I refactored the Item class to use actual IDs instead of "offset IDs", where e.g. iron shovels are 0 in vanilla but the actual internal ID is 256:
Vanilla also has code like this; all those additions/subtractions of 256 are a maintenance disaster waiting to happen (I imagine that Mojang had a lot of fun when they refactored the game in later versions, I had my fair share of crashes due to missing +/- 256 somewhere, but now I don't have to worry about it):
This was also done because it enables using the same constant with the actual ID everywhere without worrying about the difference between "offset" and "real" IDs; a lot of code like "if (id == Block.stone.blockID)" is now "if (id == BlockStates.stone", where "BlockStates.stone" is set to 1, and is inlined at compile time, avoiding the need to reference "Block.stone" while also avoiding code like "if (id == 1)" ("BlockStates" can also be a combined block ID + metadata, like 1281 (1 + 256 * 5) for "BlockStates.stone_andesite", enabling code like "if (world.getBlockState(x, y, z) == BlockStates.stone.andesite)" and avoiding the need for two separate comparisons and method calls to get the ID/metadata).
That aside, its GUI may not work as it probably depends on the GuiInventory class (though I extended the original class and only added a call to a "displayStats" method, otherwise it calls the original code that draws the GUI). I also noticed that TMI is calling it from "TMIReplaceItems.modMushroomBlock"; as with many other blocks I completely refactored/replaced the original vanilla code for mushroom blocks (both the plant and block, this includes adding items for blocks in the Creative inventory, which were not available in vanilla) - the only way any mods would be compatible is if they are rewritten to interface with my own classes.
Note that in addition to mushroom blocks I made other previously unobtainable items available in the Creative inventory, such as dragon eggs, mob spawners, and spawn eggs for giants, iron golems, and snow golems. Some items also don't exist at all anymore, such as the item form of beds, cake, and cauldrons, which all now drop the block itself (they actually had two items, one for the block and one for the "actual" item; one benefit of this change is that it makes it possible to render them in 3D, without a lot of changes to item rendering (1.6.4 only supports a generic "pseudo 3D" item model for non-block items and I did not change this).
Another thing to note - do not try loading a world created with TMCW in vanilla, no matter what version, including newer versions (some blocks do have the same IDs, such as the 1.8 stone types, but most are different, as are item, biome, and entity IDs, as well as NBT data) - I know that people have done this before because somebody said they found a minecart with command block in a dungeon chest, which only exist in 1.7 and later (the ID for them corresponds to the ID for amethyst items in TMCWv4, which is now the "strad" music disc; which reveals yet another change - all allocated item IDs are now consecutive and the size of the item list was reduced from 32000 to 512; blocks were previously changed from 4096 to 256 with basic support for "extended" IDs up to 4095 removed (this itself would require substantial refactoring to support since only the chunk storage system supported these IDs; even Mojang never attempted it, instead completely replacing the ID system in 1.13). The 256 ID limit is not seen as an issue because metadata allows for up to 4096 unique blocks (not including render-only states, e.g. fence connections and snowy grass) and I added support for metadata to change things like the light level (most of the blocks that I've added are variants of existing blocks with about 60 IDs left).
Also, I updated the download as I forgot to include the legend with biome colors used by BiomeMapper; I also updated Documentation\biomes.txt to include a list of every biome by its frequency:
Also, these are the frequencies of biomes in vanilla for comparison:
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
I've added a download for a specially modified version of MCMap that properly renders worlds created with TMCWv5:
There are also some bugfixes and optimizations, including properly rendering some vanilla blocks which did not use the correct model/color and optimizing the underground rendering mode to map a more realistic range around torches (the original program used a +/-18 block range, which is far in excess of anything a torch can cover; I reduced it to 8 blocks by taxicab, matching the minimum light level of 6 to prevent hostile mob spawning; in practice, you'll place them closer together, for example, when branch-mining I place them every 10 blocks as that is the point where it gets too dark to see well, which is a radius of 5 blocks from a torch) and better account for "ceiling" blocks (caves above sea level only render if there are at least 2 blocks above them, excluding all variants of leaves and logs; the original version required that all caves, including below sea level, have a ceiling of 3+ blocks and due to a coding error it did not ignore leaves/logs/some other blocks; fixing this reduces the amount of "clutter" near the surface, while the relaxed ceiling requirements includes previously missing caves just below the surface).
Granite/diorite/andesite also render as stone when underground mode is used, which along with the aforementioned changes gives much clearer renderings of explored caves, as seen in this comparison between the original program and TMCWv5 version (this is actually of a world created in TMCWv4 but most blocks still render correctly):
Notably, I'd previously modified MCMap as far back as early 2014 but never released it (this example compares the original range to a circular radius of 6 blocks, which I recently changed to a taxicab distance of 8); the program itself is open-source and development has been continued by several others; unfortunately, the "original" MCMap is no longer readily available as the the forum thread by the original creator was deleted and the website created by WRIM, who took on development, is also no longer available (there is a more current version with active development but it appears to be for 1.13+ only. WRIM's version is still available on their GitHub, I modified 2.4.3 since that was the latest version I'd previously modified and it would have less vanilla 1.7+ blocks to remove/change).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
can you give a mediafire link? dropbox doesn't seem to work at all in China
I've made a significant change to mob spawning - the hostile mob cap is now split into semi-independent "surface" and "cave" caps in a similar manner to Bedrock Edition, but without that version's ridiculously low spawn rates (11/2000 per chunk per tick vs 1/4 for TMCW and 1/1 for vanilla; the difference between the latter two is not significant outside of mob farms) and mob caps (only 8 per 9x9 chunk area, which is approximately the size of the overall spawn area used by TMCW (a 5 chunk circular radius encompassing 101 chunks), with the despawn radius of 96 blocks (x and z only) encompassing about 113 chunks; together this gives an average density that is 6-7 times higher).
The overall cap was increased to 105 with each individual cap set to 70 (50% higher and the same as vanilla respectively; this does not include slimes, which were previously given a separate sub-cap of 25) and the cave cap is prioritized so it will always be full if enough mobs can spawn underground, while the surface cap takes up the remainder, averaging 35 mobs at night and rising to 70 as the cave cap drops to 35 or less. This effectively simulates locking the time to always day, which I'd done before to force mobs to spawn underground to increase the number I encounter while caving, while not affecting surface spawning, which is also a lot more consistent now (with the old system various areas had less than 20 to over 50 mobs on the surface at night. Due to an increased density due to a reduced spawning range 35 is roughly equivalent to 60 mobs in vanilla, higher than will typically be present on the surface):
Vanilla 1.6.4 for comparison (modified to add count of surface/cave mobs); mob counts are less variable due to the larger area mobs can spawn within smoothing out the effects of variations in cave density (deserts are still more favored due to less obstructions; in particular, vanilla 1.6.4 only considers air blocks to be valid pack spawn locations, which I changed to include any transparent block as 1.8 did, thus Ice Plains in particular has a very low surface spawn rate). Also, "All: 50" indicates that only 50 entities (including non-hostile mobs) are within 80 blocks of the player, the maximum distance at which the server will send most entities to the client ("mob counts" is server-side); nearly all hostile mobs will be within this range in TMCW due to the spawn radius of 5 chunks (circular) and despawn radius of 96 blocks:
TMCW with the new spawning system; the number of mobs underground is around 70 regardless of the time of day while the surface count takes up the remainder of an overall cap of 105 (note that this is in a similar location to a previous example that had only 18 mobs on the surface due to a high cave density, thus the amount was doubled):
A Superflat world without caves; the surface count has reached its cap, as it also can if the cave count is 35 or less:
This demonstrates how mobs are counted towards a cap; either being below sea level (defined as the highest non-air layer in Superflat worlds) or the absence of sky light is used to count mobs towards the cave cap:
Also, mobs will now start spawning on the surface as soon as it gets dark enough since mobs in caves don't need to despawn, while vanilla may take as long as a minute in the worst-case (the average life of a mob is 40 seconds after an initial 30 second period and due to spawn mechanics the cap can be exceeded during a single spawn cycle so it may take a while to drop below 70 (technically, the cap is 79 in vanilla 1.6.4 due to a faulty calculation; 1.8 and later use a divisor of 289, the same as the number of chunks counted within range of a player).
ETA: After some additional playtesting I've set the individual caps to 60 and overall cap to 100 (40 on the surface at night); the reduction from 70 to 60 was mainly because I felt there were too many mobs, even for my liking, and I've still encountered about 25% more mobs per session than before. The Nether and End still use the original cap of 70.
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
I made a video tutorial showing how to install this mod because I see a lot of people don't know how to install JAR mods.
BetterCraft 0.7
I've never liked the idea of having to use a 3rd party launcher; I've even made posts on other threads saying that it was possible to install their mod on the vanilla launcher (for example), and the installation steps you show don't seem any more complicated (I'm guessing the main issue with my method is modifying the jar; for some reason when I try to use 7Zip to add files it gives me an error but WinRar has no such issues. Another method that I've seen is to rename the jar to zip and use Windows File Explorer to extract/rezip it but there are class files with invalid filenames like aux.class (I tried doing this for my very first attempt at modding, before Optifine had an installer back in the 1.5 days, as that was what the instructions I found said to do, presumably referring to a older version without those files).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
I installed this mod and I liked it a lot, but there is one thing that is bothering me. Looks like the battle system is different. When I try to hit with the sword, I can only do damage in the first few hits, but then the sword loses power and I have to hit the mobs a lot to kill. I've died more than 10 times because of it.
Can you explain to me how combat works in this version? Or is this a bug?
There is an "attack cooldown" feature - much like 1.9 you can't just spam-click or the damage dealt will be reduced; unlike 1.9 it only takes effect when you either miss or hit a mob while it is damage-immune (red) from a previous player attack - you can attack as fast as you can provided every hit lands on a mob while it is not immune (1 mob = 2 hits/second, 2 mobs = 4 hits/second, and so on).
The threshold for when missed hits increases the "penalty" is less than 1 second between attacks while holding a weapon (an item that increases damage; any other item has no effect) while damage-immune hits increase it by the maximum amount allowed per hit (this includes unarmed attacks), as shown by these two charts (20 ticks = 1 second); this is controlled by a counter which starts at -20 and increases with each missed hit, only reducing damage once it rises above 0, and capped to a maximum of 140, with the effects capped at 100, which corresponds to a 75% reduction in damage dealt; the counter is decremented once per tick so it takes up to 140 ticks or 7 seconds to drop back down to 0, and another second to completely reset:
Note that the damage shown is that of a Sharpness V amethyst sword; amethyst items have the same damage values as diamond in vanilla and all other tiers deal one less damage than before (this is similar to how 1.9 reduced the damage dealt by swords by one and the addition of netherite in 1.16 basically gives you the old diamond sword back), and stronger weapons will help since you can still kill most mobs in two hits as long as you deal at least 10 damage per hit (or three hits for at least 6.67 damage, etc); axes also penetrate armor, similar to 1.9's mechanic, so can be better against armored mobs (a Sharpness V amethyst axe kills a zombie in full diamond armor in about half as many hits. Amethyst armor has "armor toughness" which reduces the penetration effect).
The recovery time of up to 7 seconds may be a bit excessive but the occasional missed attack won't have any effect (at 2 attacks per second it takes 3 missed hits in a row to start reducing damage (the first missed hit does not count, the second increases the penalty from -20 to 0, and the third increases it from -5 to 15, at which point you are dealing 88.75% of full damage); if you alternately miss a hit, then successfully land a hit it will act as if you missed once per second, thus the penalty will never be triggered).
Also, the effectiveness of armor on players was reduced; damage reduction is 3.3% instead of 4% per armor point so iron is 50%, and diamond has 18 points instead of 20 for 60% damage reduction (the same as iron in vanilla), and amethyst reduces damage by 66.7% (these are equivalent to having 2x, 2.5x and 3x more health, compared to 2.5x and 5x for iron and diamond in vanilla). Protection enchantments were modified to remove their randomized damage (in vanilla 1.6.4 full Protection IV reduces damage by a random 40-80% while in TMCW it is a fixed 60% and the specialized enchantments, including Feather Falling, are capped at 75% instead of 52-80%; these are again similar to how 1.9 made them non-random, except 1.9 set Protection at 64% and others at 80%, though the lower protection in TMCW should be compared to the original values, not 1.9 (in particular, the original guaranteed minimum was a lot lower, best seen for fall damage - 52% only allows survival from a 44 block fall while 75% allows 82 blocks, or nearly double the distance).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Code and explanations of why the bug occurs and how it was fixed:
This is part of the code that actually generates the structure; vanilla does not account for the aforementioned change in orientation so it ends up clearing away the wrong exits (it always uses the code in the "else" block):
This is also mentioned in the Wiki, if not as a bug, and indicating that it still happens in the latest versions (they link to a video from 1.14 which shows a blocked entrance next to an incorrectly cleared entrance; in this case the blocked entrance has an iron door with a button which was inset in the wall so it was obvious but this is not always the case):
Incidentally, there was a similar bug with mineshafts; the game clears out a small "room" at the entrances to the central room to ensure they are clear due to the top of the room curving inwards; this piece was always aligned to the top of the bounding box of the connecting piece but this was incorrect for 2-story high crossings, which could even be higher than the ceiling of the room, thus not connect at all, as well as being too wide (5 blocks when it should be 3); I fixed this a while back, along with a much older vanilla bug in TMCWv1 (the "ocean bubbles" bug, which was due to these rooms not being offset with the rest of the structure).
I've also been making various small updates, just not announcing every one; for example, I recently added "Swift Sneak" and "Long Fall" enchantments as "rare"/"semi-treasure" enchantments (you can get them from the table but they are much rarer than most enchantments; conversely, they are much more common than other enchantments in mineshafts). Swift Sneak is directly based on the enchantment being added to 1.19 (so yes, TMCW officially has it before vanilla, similar to various other features; e.g. I added the 1.8 stones while 1.8 was still in snapshots) while Long Fall increases the distance you can fall without taking damage by 1 block per level (up to 7 blocks at level IV), but is mutually exclusive with Feature Falling (it can be very useful though in situations where you regularly take damage from lots of small falls; when combined with full Protection IV the maximum survivable fall distance is 56 blocks, compared to 82 with Feather Falling).
Also, I think it is an extremely bad practice to have any sort of long-term list of pending bugs that need to be fixed - I fix bugs as soon as they are discovered (I actually did know about the stronghold bug before but not exactly why it happened, or that it wasn't intentional), in contrast with most mods, and especially vanilla (worst of all are extremely simple bugfixes or bugs with fixes provided, such as MC-2025 - there is absolutely no reason why mobs should still be suffocating in or glitching through walls; the fix in this comment is the one that I used - just a simple addition of a "margin", which I set to a more conservative 1 millionth, plus a 1 billionth margin added to y to be extra safe. Granted, there might be edge cases where it still happens but I've never noticed it since fixing it, and the related MC-9568, also using a fix provided with that report). Nothing beats Mojang's refusal/inability to fix a bug in Bedrock Edition that causes no portal room to be generated (it was even closed as "works as intended" for a while), which is avoided with a single line of code (as a loop) in Java Edition:
Also of interest, while testing I found the tallest stronghold I've ever seen; the top is at y=65, above sea level, while the lowest floor is at y=2 (it is at "148 55 3028" in the seed "-4426978636490490569"; this is the same seed I'm currently playing on but this is too far away for me to ever find it; the stronghold shown above is at "260 34 1396" in the same seed, which I discovered while caving; if I'd found it with eyes of ender it would have been frustrating to find the portal room. The y-coordinates, which I recently added to CaveFinder's output, are at the bottom of the starting staircase):
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
So, is there a way to disable this combat feature? The changes in combat system is what keeps me from playing Minecraft 1.9+. I can play 1.18 just fine, but I still think that 1.8 combat still rocks and keep playing 1.8. Now I knew this mod and liked it, but noticed the changesd in combat. Not so bad as 1.9, but it still bothers me.