I have a stupid suggestion, Have you considered upgrading the rendering code to use Streams? I know that java 8 is compatible with existing code.
I have no idea what you are referring to or how it might help/be implemented (this is also why I have not added mipmaps or other things; TMCW is basically just vanilla 1.6.4 and I haven't even changed the "target/source" options in MCP's config to use a newer version of Java (I even still use JDK 7, never having upgraded it because there is no need, and all my Java programming knowledge is derived from Minecraft's source code (aside from a bit in school, but no serious programming), and newer JDKs will complain about target/source 1.6). Plus, I've heard that various features of newer JDKs have been responsible for performance degradation in newer versions; for example:
Solution: Stop this Methodbased programming. Yes it looks nicer i give you that but you are slowing everything down. I mean technical players already know that the game is half as fast as it was before, this is 1 reason because of that. If you "HAVE" to use a Lambda. Cache it and Reuse it, that way you have 1 allocation and a smaller performance hit, because a lambda is slower then or equal calling everything via reflection.
Also, the biggest issue with rendering is uploading vertex data to the GPU, which dominates the time taken by a chunk update, even for the most complex chunk sections (Fancy leaves render all faces while Mega Tree flowerpot models are equivalent to several thousand blocks each, in addition to literally generating a tree in the same way as a real one and iterating over "fake chunk data" to decide what to render, yet even that only takes 2 ms for a dozen, which would be very manageable if not for the 33 ms needed to upload the data to the GPU):
16x16x16 Fancy leaves in vanilla:
Chunk update took 35652 us (render: 16481, upload: 19170)
TMCW:
Chunk update took 20927 us (render: 1971, upload: 18955)
12x Mega Tree flower pots:
Chunk update took 35611 us (render 2071, upload: 33539)
Even modern versions suffer from lag spikes./stuttering/FPS drops due to chunk updates because the vertex upload itself is not multithreaded (Optifine did have a "multicore" chunk loading option prior to 1.8 but it often caused issues); the only time I've had issues is in artificial environments, as shown above; the majority of chunk updates in a normal world (Fast leaves, Fact-Fancy is an intermediate option which doesn't render interior faces more than 1 block deep) take 1-2 ms or less and you can adjust how much time is allotted to them via the "chunk update time" slider; the default of 0.25 was chosen for the default settings on my computer and may need to be changed for optimal results):
It's already mostly parallel. The only part that isn't is the part that directly talks to opengl and that's also the part that is no longer artificially capped on this pre-release. And it can't be reliably made parallel because opengl doesn't officially support multithreading. While it works on some GPU drivers, it breaks on others (like 1.7.10 optifine multi core chunk loading, it actually breaks on some hardware configurations)
(even if OpenGL does support multithreading in newer versions TMCW only uses basic OpenGL 1.x, same as vanilla 1.6.4, and upgrading TMCW to modern OpenGL is out of the question, unless there is a good open-source example I can use; somebody said that have been modifying a decompiled copy of TMCW by "rewriting the rendering and sound engines" and making it multiplayer compatible but they don't seem willing to provide code - you also shouldn't give me too much credit for bugfixes, which were mostly pulled from code posted to the bug tracker).
Aside from that, I blame AMD and Intel for not supporting OpenGL that well (e.g. the lack of "curved" fog, though somebody said the fix was "really easy" but shamefully never said what it was; or Intel refusing to fix a serious rendering issue for the past year (fixable by downgrading drivers but this is not a long-term solution), though interestingly very old (Beta and earlier) versions are not affected so something that 1.0.0-1.7.10 do upsets it, thus it may actually be fixable by patching whatever code is at fault; AMD has issues, even in the latest versions, with texture animations causing lag (one reason why I did not animate water plants, aside from the blocky animation just not appealing to me. Note that all of these issues do not affect me and cannot be tested/debugged since I have an NVIDIA GPU).
Also, the biggest issue with rendering is uploading vertex data to the GPU, which dominates the time taken by a chunk update, even for the most complex chunk sections (Fancy leaves render all faces while Mega Tree flowerpot models are equivalent to several thousand blocks each, in addition to literally generating a tree in the same way as a real one and iterating over "fake chunk data" to decide what to render, yet even that only takes 2 ms for a dozen, which would be very manageable if not for the 33 ms needed to upload the data to the GPU):
Even modern versions suffer from lag spikes./stuttering/FPS drops due to chunk updates because the vertex upload itself is not multithreaded (Optifine did have a "multicore" chunk loading option prior to 1.8 but it often caused issues); the only time I've had issues is in artificial environments, as shown above; the majority of chunk updates in a normal world (Fast leaves, Fact-Fancy is an intermediate option which doesn't render interior faces more than 1 block deep) take 1-2 ms or less and you can adjust how much time is allotted to them via the "chunk update time" slider; the default of 0.25 was chosen for the default settings on my computer and may need to be changed for optimal results):
(even if OpenGL does support multithreading in newer versions TMCW only uses basic OpenGL 1.x, same as vanilla 1.6.4, and upgrading TMCW to modern OpenGL is out of the question, unless there is a good open-source example I can use; somebody said that have been modifying a decompiled copy of TMCW by "rewriting the rendering and sound engines" and making it multiplayer compatible but they don't seem willing to provide code - you also shouldn't give me too much credit for bugfixes, which were mostly pulled from code posted to the bug tracker).
Aside from that, I blame AMD and Intel for not supporting OpenGL that well (e.g. the lack of "curved" fog, though somebody said the fix was "really easy" but shamefully never said what it was; or Intel refusing to fix a serious rendering issue for the past year (fixable by downgrading drivers but this is not a long-term solution), though interestingly very old (Beta and earlier) versions are not affected so something that 1.0.0-1.7.10 do upsets it, thus it may actually be fixable by patching whatever code is at fault; AMD has issues, even in the latest versions, with texture animations causing lag (one reason why I did not animate water plants, aside from the blocky animation just not appealing to me. Note that all of these issues do not affect me and cannot be tested/debugged since I have an NVIDIA GPU).
That's a real shame. With OpenGL and all. Have you taken a look at This Bug(MC-67)? It seems to still affect 1.18.2!
Have you taken a look at This Bug(MC-67)? It seems to still affect 1.18.2!
I've never heard of it until now, and never moved entities through a portal (I barely go to the Nether at all, mostly just to find a fortress and mine quartz for XP). Also, this actually seems to be intentional since there are explicit checks for if an entity has a passenger, possibly because of issues while transferring it to another dimension (an old comment says that Dinnerbone said it was by design) a possible fix would be to transfer both at the same time, rather than relying on each entity's "portal timer" (which won't be in sync if they are different sizes, and in the case of an End portal the passenger is higher, so one will collide with the portal first and you'll have cross-dimensional/cross-world references):
// Entity.onEntityUpdate() (Nether portals)
if (this.ridingEntity == null && this.portalCounter++ >= var2)
{
this.portalCounter = var2;
this.timeUntilPortal = this.getPortalCooldown();
this.travelToDimension(this.worldObj.provider.dimensionId == -1 ? 0 : -1);
}
// BlockEndPortal (End portals)
public void onEntityCollidedWithBlock(World par1World, int par2, int par3, int par4, Entity par5Entity)
{
if (par5Entity.ridingEntity == null && par5Entity.riddenByEntity == null && !par1World.isRemote)
{
par5Entity.travelToDimension(1);
}
}
Note that there are various other places where the code shown above can be found (EntityMinecart has its own method which is basically a copy of the one in Entity, IDK why they did that and this annoys me since I'd have to modify multiple classes in order to fix it for every entity. Players also appear to be handled differently, at least in travelToDimension).
Also, you'd be surprised at how many bugs seem to be intended from looking at the code; for example, when they added sprinting they coded in a timer which stops it after 30 seconds, likely as a balance measure (many old (Beta) players cite sprinting as one reason why they dislike newer versions because it makes it easy to get away from mobs), yet it was filed as a bug and later "fixed", if probably because of the addition of a dedicated sprint key in 1.7, which can be held down so you can sprint indefinitely, thus creates inconsistent behavior.
The Meaning of Life, the Universe, and Everything.
Location:
Hypixel
Join Date:
9/28/2022
Posts:
53
Location:
America
Member Details
Here is a script I made to automate the compile-and-startclient process:
@echo off
cd PATH ::Replace PATH with where your coder-pack is.
runtime\bin\python\python_mcp runtime\recompile.py %*
runtime\bin\python\python_mcp runtime\startclient.py %*
pause
For MacOS:
#!/bin/bash
cd PATH
python runtime/recompile.py "$@"
python runtime/startclient.py "$@"
BTW, Can I force someone to unsubscribe from me? I have some creepy looking followers.
Here is a script I made to automate the compile-and-startclient process:
@echo off
cd PATH ::Replace PATH with where your coder-pack is.
runtime\bin\python\python_mcp runtime\recompile.py %*
runtime\bin\python\python_mcp runtime\startclient.py %*
pause
For MacOS:
#!/bin/bash
cd PATH
python runtime/recompile.py "$@"
python runtime/startclient.py "$@"
BTW, Can I force someone to unsubscribe from me? I have some creepy looking followers.
The only issue with this is that if any errors occurred during recompilation there will be missing files and the game won't run or crash; you also don't need to change the directory if you start from the root of the MCP folder (I work directly from it, just clicking on the batch files to compile/run/reobfuscate).
As for followers, you ought to see mine... I've considered reporting it (in forum discussion and info) but I have a hard time believing that they will respond in any timely manner (the last time a moderator replied was a couple months ago, such is the state of the forums when everybody uses sites like Discord, despite all their disadvantages; this explains why it is so hard to find any actual discussion about mods, or anything else for that matter, these days).
There doesn't seem to be much consistency in which blocks get stair, slab, and wall/fence variants. Some sort of parity would fix this. The image shows which blocks lack either a stair, slab or a wall variant, while having other variants. On the far right are blocks that for the sake of consistency should probably have their own slab/stair/wall variants, but that's up for debate.
Suggestion: Button/Pressure Plate Parity
While giving every single type of wooden plank its own door/fence/trapdoor variant might be a bit excessive (especially as this might require unique designs for each of the door and trapdoor variants), in my opinion, there should at the very least be more buttons to match the amount of pressure plates.
There doesn't seem to be much consistency in which blocks get stair, slab, and wall/fence variants. Some sort of parity would fix this. The image shows which blocks lack either a stair, slab or a wall variant, while having other variants. On the far right are blocks that for the sake of consistency should probably have their own slab/stair/wall variants, but that's up for debate.
Suggestion: Button/Pressure Plate Parity
While giving every single type of wooden plank its own door/fence/trapdoor variant might be a bit excessive (especially as this might require unique designs for each of the door and trapdoor variants), in my opinion, there should at the very least be more buttons to match the amount of pressure plates.
I don't quite understand from your image. We have variants for wood everything. You must mean non-wood ones. A stone door seems a bit overkill but otherwise I'm fine with this.
Unfortunately I don't think TMC will be updating his mod anymore.
First of all, a big thank you for your hard work improving the old version of minecraft and adding new things. Even if it looks like your work go unnoticed by many, a few like me follow your posts every now and then.
I am going to be honest I was a little bit hesitant to try your "modification?". Because you know, it's almost 10 years old version of minecraft even if it's updated.
Long story short, after months of playing 1.18-1.19 today I thought to myself; "I am not enjoying this. This isn't fun to play, what am I doing?". I realized I had to dig to -59 levels of y to mine diamonds "efficiently" every time I traveled to a new place, because you know I enjoy exploring and not being stuck in one place. I saw many people on youtube and in multiplayer servers creating the biggest auto farms, afk farms... just to get more iron and gold that they will never use? After many many things later, today fighting with the warden for the first time was the final nail in the coffin.
I know most people won't agree with me on this, but I literally hated it seeing how unfair and uninteresting it is. I always listened something (music, youtube videos, podcasts etc.) when playing minecraft and now I can't. I have to sneak and listen the sounds constantly, so I don't get killed in one or two hit when exploring the end city. You may ask: "but creepers do enough damage to one hit you too?". Yeah, but they don't spawn if there is a light source. Warden doesn't like any of that. Every small step or sound makes it teleport near the player. Ok, I made a mistake now I can kill it with a great strategy, right? Hah, good luck with that, it has 500 hp (twice the ender dragon's). You can't kill it because.....just because. There is no reason. Oh but it can kill you, in lots of *fun* ways. It can sonic boom you through the solid blocks. Awesome. You just have to sneak in the most boring way and hope it doesn't sniff you or run away while you can. Does this sound fun to you?
Now I am trying your modification and loving it so far. It has all the things I needed without the frustration. Just one quick question would you be so kind to answer? How can I edit the mob spawning light level? I want it to be 0 like in 1.18. I never liked filling the map with torches, it's just my taste. Thank you.
Now I am trying your modification and loving it so far. It has all the things I needed without the frustration. Just one quick question would you be so kind to answer? How can I edit the mob spawning light level? I want it to be 0 like in 1.18. I never liked filling the map with torches, it's just my taste. Thank you.
I haven't added any way to configure anything (other than things like video settings), mainly because I made it for myself (the opening description is quite old but the part about being made for my own use is still accurate); I'd have to edit the code to change the light level and while I've made such a "patch" before for a personal request I can't guarantee that they will remain up-to-date (understandably, having to maintain a lot of patches makes updates more difficult, even if it is as simple as changing a constant value in a file as I'd have to separately do it for each one).
That said, I did reduce the minimum light level (Overworld only, and excluding mob spawners) from 8 to 6, mainly because this matches the minimum level displayed by cave maps (if the entire area is mapped then no mobs can spawn, other than e.g. slimes), otherwise, this has had no effect on the number of torches I use while caving, which are placed for visibility and I generally place another torch when the light level drops to 2-3 (even if you place a new torch in the first block with a light level of 0 the minimum light level between torches will be 7, and in order to get the most out of a minimum light level of 1 you'd have to go far into the dark; because of this, I'm skeptical that even the 1.18 changes would have any effect on general caving; of course, you are probably referring to lighting up a house or other structure).
I haven't added any way to configure anything (other than things like video settings), mainly because I made it for myself (the opening description is quite old but the part about being made for my own use is still accurate); I'd have to edit the code to change the light level and while I've made such a "patch" before for a personal request I can't guarantee that they will remain up-to-date (understandably, having to maintain a lot of patches makes updates more difficult, even if it is as simple as changing a constant value in a file as I'd have to separately do it for each one).
Oh, I thought I could change it with a few lines of simple code, my bad. Well thanks for explaining.
Oh, I thought I could change it with a few lines of simple code, my bad. Well thanks for explaining.
I decided to make a patch anyway, including one that disables the "attack cooldown/penalty" feature, which I've previously made when somebody else requested it; either or both can be used at the same time (they are completely separate files, and they can easily be updated if necessary by simply changing a true/false or light level variable):
Note that only natural mob spawning in the Overworld is affected and this only applies to block light (the Nether, End, and mob spawners still use the original light level of 8, as does the behavior of sky light, and some mobs, like slimes (slime chunks only), ignore it entirely or have their own rules, similar to the latest vanilla version).
Thanks a ton for your mod, it's bringning me endless joy, when discovering all the new things and caving, of course. The only thing which bothers me a little is the texture noise in the distance. Do you think you could add mipmapping with some anti-aliasing?
Thanks a ton for your mod, it's bringning me endless joy, when discovering all the new things and caving, of course. The only thing which bothers me a little is the texture noise in the distance. Do you think you could add mipmapping with some anti-aliasing?
I'd need source code from an open-source mod that implements these; I can only seem to find Optifine, which is not open-source and makes a lot of unrelated changes (I have decompiled it; while I added features similar to ones it adds I did not copy its code). Also even current vanilla versions have issues with textures when anti-aliasing and anisotropic filtering are enabled (via the GPU control panel), and Mojang did temporarily add anisotropic filtering in 1.7 but removed it in 1.8 due to issues (I've never used Optifine's settings so I don't know how well it works or whether it has the aforementioned texture bugs. Note that my only experience with working with OpenGL is basic rendering stuff, and a lot of the block rendering code doesn't even directly use OpenGL, rather indirectly via a "tessellator").
I'd need source code from an open-source mod that implements these; I can only seem to find Optifine, which is not open-source and makes a lot of unrelated changes (I have decompiled it; while I added features similar to ones it adds I did not copy its code). Also even current vanilla versions have issues with textures when anti-aliasing and anisotropic filtering are enabled (via the GPU control panel), and Mojang did temporarily add anisotropic filtering in 1.7 but removed it in 1.8 due to issues (I've never used Optifine's settings so I don't know how well it works or whether it has the aforementioned texture bugs. Note that my only experience with working with OpenGL is basic rendering stuff, and a lot of the block rendering code doesn't even directly use OpenGL, rather indirectly via a "tessellator").
All right, understood! Anyway, it's only a small bother in open spaces, underground this issue is hardly noticeable. Once again, great mod, thank you for it. I couldn't help but play it in coop with my wife, although I know, it is single player only. Nevertheless, it plays awesome. Cheers!
All right, understood! Anyway, it's only a small bother in open spaces, underground this issue is hardly noticeable. Once again, great mod, thank you for it. I couldn't help but play it in coop with my wife, although I know, it is single player only. Nevertheless, it plays awesome. Cheers!
Do you mean open to LAN? The main issue with multiplayer is the dedicated server, which would require a separate mod, or at least patch (the client's internal server is mostly the same but there are some incompatibilities), otherwise, any issues are due to the way I fixed various bugs and send custom data between the client and server (for example, the "attack penalty" won't penalize missed attacks as I have the client side directly setting the variable on the server side, which is only possible if they are in the same process; conversely, hitting damage-immune mobs still works but all players share the same variable). I have considered making all or at least most of these things use the network, as I did a while back for server-side particles by making use of a function the game already had (up to now I've avoided trying to add any actual new packets).
Do you mean open to LAN? The main issue with multiplayer is the dedicated server, which would require a separate mod, or at least patch (the client's internal server is mostly the same but there are some incompatibilities), otherwise, any issues are due to the way I fixed various bugs and send custom data between the client and server (for example, the "attack penalty" won't penalize missed attacks as I have the client side directly setting the variable on the server side, which is only possible if they are in the same process; conversely, hitting damage-immune mobs still works but all players share the same variable). I have considered making all or at least most of these things use the network, as I did a while back for server-side particles by making use of a function the game already had (up to now I've avoided trying to add any actual new packets).
Yes, LAN play. From what I noticed so far is that only the host has the extended statistics on mobs killed, ore mined, etc. in the extended inventory window overlay (when you press R in the inventory). Anyway, this is really nothing.
Hello, lovely people of the Minecraft Forums! I know that this is my first post here. However, I must say that I'm really enjoying this mod! Especially with its new additions from cave generation, new blocks and items, and performance. I've got a few suggestions to be backported from future and past versions for TheMasterCaver's World.
Stained Glass and Glass Panes from 1.7
Beetroot and End Terrain Generation from 1.9
Glazed Terracotta from 1.12
More context for the suggestions if you're confused. More End islands for End Terrain Generation. If I come up with any more suggestions, I'll be sure to let you know. Thank you, and have a blessed day!
Disclaimer: I don't care if you add these suggestions or not to your mod. As it's your envision of how Minecraft should've been in your eyes.
a thousand thanks for this mod. Your vision of minecraft is really amazing and It has become my number one "to go" version of the game.
I would like to edit the lightmap and bring back the old, darker nights from beta 1.7.3 and earlier versions, however I have no experience with modding minecraft. I've only done mods (not addons) for World Of Warcraft since that was and still is the main game I play (and mod).
If you have time, could you please tell me how I could do that? I read a bit online and saw people suggesting using a custom lightmap along with mcpatcher or using optifine. Now I know that optifine doesn't work with V5 of your mod and I don't think mcpatcher works either - I have no experience with them to begin with since I mostly played vanilla minecraft since 2010 till present day (without manually installing mods).
I found a lightmap that mimics the alpha/beta lighting from a resourcepack called "NostalgiaCraft" but I don't think it works without mcpatcher. Is there any other way to bring the old lightning into your version of minecraft?
Thank you for all of your efforts once more! Really loving the game!
I would like to edit the lightmap and bring back the old, darker nights from beta 1.7.3 and earlier versions, however I have no experience with modding minecraft. I've only done mods (not addons) for World Of Warcraft since that was and still is the main game I play (and mod).
If you have time, could you please tell me how I could do that? I read a bit online and saw people suggesting using a custom lightmap along with mcpatcher or using optifine. Now I know that optifine doesn't work with V5 of your mod and I don't think mcpatcher works either - I have no experience with them to begin with since I mostly played vanilla minecraft since 2010 till present day (without manually installing mods).
I have no idea how to replicate the old lighting; the code that newer versions use to dynamically create the lightmap (done in code with no actual texture) doesn't seem to exist and they just appeared to change the brightness of blocks when rendering chunks (which is why day-night transitions involved chunk updates instead of a smooth transition).
Also, Moody already looks extremely dark to me, especially during a new moon; IMO most people have their monitors set WAY too bright and/or with a bad gamma curve (I set the gamma slider in Windows' display calibration tool to as low as it can go, and it still shows that it is correct; the default makes everything look washed-out):
Examples of brightness at night during a new moon and full moon on Moody and Bright, the latter also with "gamma offset" set to 0, 0.11, and 0.2:
The "gamma offset" setting can be found on the third page of video settings, although it doesn't work on Moody since its effect scales up as brightness is increased (it is intended to offset the inflation of lower light levels at higher brightness settings):
Interestingly, Optifine originally added a brightness slider (since added to vanilla) with the claim that properly calibrated monitors made the game look too dark at night (whether Optifine's method is the same or vanilla is unknown; one issue with vanilla is that a light level of 0 is not completely dark so it is affected, not just light levels 1-14, as a proper gamma adjustment would affect):
On a good calibrated monitor which can show near-black colors the Minecraft night scenes are almost fully black (light level 4). On the other hand, not so good monitors which have problems with near black colors show the night scenes very good.
The Brightness setting fixes the Minecraft light levels for properly calibrated monitors. Brightness 0% corresponds to default Minecraft light levels. Brightness 100% uses linear light levels, so the steps between all light levels are equal.
This is also reflected in the way I light up caves; I place torches for the light itself, not to prevent mob spawning, and play with brightness set to Bright, yet place a thousand or more torches per play session, and can't even imagine how I'd get by with Moody lighting:
A layer by layer cutaway of a giant cave region I explored, with more than 7,000 torches placed in and around it over 6 play sessions; followed by various screenshots from it and other caves:
I have no idea what you are referring to or how it might help/be implemented (this is also why I have not added mipmaps or other things; TMCW is basically just vanilla 1.6.4 and I haven't even changed the "target/source" options in MCP's config to use a newer version of Java (I even still use JDK 7, never having upgraded it because there is no need, and all my Java programming knowledge is derived from Minecraft's source code (aside from a bit in school, but no serious programming), and newer JDKs will complain about target/source 1.6). Plus, I've heard that various features of newer JDKs have been responsible for performance degradation in newer versions; for example:
Also, the biggest issue with rendering is uploading vertex data to the GPU, which dominates the time taken by a chunk update, even for the most complex chunk sections (Fancy leaves render all faces while Mega Tree flowerpot models are equivalent to several thousand blocks each, in addition to literally generating a tree in the same way as a real one and iterating over "fake chunk data" to decide what to render, yet even that only takes 2 ms for a dozen, which would be very manageable if not for the 33 ms needed to upload the data to the GPU):
Even modern versions suffer from lag spikes./stuttering/FPS drops due to chunk updates because the vertex upload itself is not multithreaded (Optifine did have a "multicore" chunk loading option prior to 1.8 but it often caused issues); the only time I've had issues is in artificial environments, as shown above; the majority of chunk updates in a normal world (Fast leaves, Fact-Fancy is an intermediate option which doesn't render interior faces more than 1 block deep) take 1-2 ms or less and you can adjust how much time is allotted to them via the "chunk update time" slider; the default of 0.25 was chosen for the default settings on my computer and may need to be changed for optimal results):
MC-123584 Updating blocks creates lag spikes proportional to geometry in chunk section
(even if OpenGL does support multithreading in newer versions TMCW only uses basic OpenGL 1.x, same as vanilla 1.6.4, and upgrading TMCW to modern OpenGL is out of the question, unless there is a good open-source example I can use; somebody said that have been modifying a decompiled copy of TMCW by "rewriting the rendering and sound engines" and making it multiplayer compatible but they don't seem willing to provide code - you also shouldn't give me too much credit for bugfixes, which were mostly pulled from code posted to the bug tracker).
Aside from that, I blame AMD and Intel for not supporting OpenGL that well (e.g. the lack of "curved" fog, though somebody said the fix was "really easy" but shamefully never said what it was; or Intel refusing to fix a serious rendering issue for the past year (fixable by downgrading drivers but this is not a long-term solution), though interestingly very old (Beta and earlier) versions are not affected so something that 1.0.0-1.7.10 do upsets it, thus it may actually be fixable by patching whatever code is at fault; AMD has issues, even in the latest versions, with texture animations causing lag (one reason why I did not animate water plants, aside from the blocky animation just not appealing to me. Note that all of these issues do not affect me and cannot be tested/debugged since I have an NVIDIA GPU).
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?
That's a real shame. With OpenGL and all. Have you taken a look at This Bug(MC-67)? It seems to still affect 1.18.2!
I've never heard of it until now, and never moved entities through a portal (I barely go to the Nether at all, mostly just to find a fortress and mine quartz for XP). Also, this actually seems to be intentional since there are explicit checks for if an entity has a passenger, possibly because of issues while transferring it to another dimension (an old comment says that Dinnerbone said it was by design) a possible fix would be to transfer both at the same time, rather than relying on each entity's "portal timer" (which won't be in sync if they are different sizes, and in the case of an End portal the passenger is higher, so one will collide with the portal first and you'll have cross-dimensional/cross-world references):
// Entity.onEntityUpdate() (Nether portals) if (this.ridingEntity == null && this.portalCounter++ >= var2) { this.portalCounter = var2; this.timeUntilPortal = this.getPortalCooldown(); this.travelToDimension(this.worldObj.provider.dimensionId == -1 ? 0 : -1); } // BlockEndPortal (End portals) public void onEntityCollidedWithBlock(World par1World, int par2, int par3, int par4, Entity par5Entity) { if (par5Entity.ridingEntity == null && par5Entity.riddenByEntity == null && !par1World.isRemote) { par5Entity.travelToDimension(1); } }Note that there are various other places where the code shown above can be found (EntityMinecart has its own method which is basically a copy of the one in Entity, IDK why they did that and this annoys me since I'd have to modify multiple classes in order to fix it for every entity. Players also appear to be handled differently, at least in travelToDimension).
Also, you'd be surprised at how many bugs seem to be intended from looking at the code; for example, when they added sprinting they coded in a timer which stops it after 30 seconds, likely as a balance measure (many old (Beta) players cite sprinting as one reason why they dislike newer versions because it makes it easy to get away from mobs), yet it was filed as a bug and later "fixed", if probably because of the addition of a dedicated sprint key in 1.7, which can be held down so you can sprint indefinitely, thus creates inconsistent behavior.
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?
Here is a script I made to automate the compile-and-startclient process:
For MacOS:
BTW, Can I force someone to unsubscribe from me? I have some creepy looking followers.
The only issue with this is that if any errors occurred during recompilation there will be missing files and the game won't run or crash; you also don't need to change the directory if you start from the root of the MCP folder (I work directly from it, just clicking on the batch files to compile/run/reobfuscate).
As for followers, you ought to see mine... I've considered reporting it (in forum discussion and info) but I have a hard time believing that they will respond in any timely manner (the last time a moderator replied was a couple months ago, such is the state of the forums when everybody uses sites like Discord, despite all their disadvantages; this explains why it is so hard to find any actual discussion about mods, or anything else for that matter, these days).
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?
Suggestion: Slab-Stair-Wall/Fence Parity
There doesn't seem to be much consistency in which blocks get stair, slab, and wall/fence variants. Some sort of parity would fix this. The image shows which blocks lack either a stair, slab or a wall variant, while having other variants. On the far right are blocks that for the sake of consistency should probably have their own slab/stair/wall variants, but that's up for debate.
Suggestion: Button/Pressure Plate Parity
While giving every single type of wooden plank its own door/fence/trapdoor variant might be a bit excessive (especially as this might require unique designs for each of the door and trapdoor variants), in my opinion, there should at the very least be more buttons to match the amount of pressure plates.
I don't quite understand from your image. We have variants for wood everything. You must mean non-wood ones. A stone door seems a bit overkill but otherwise I'm fine with this.
Unfortunately I don't think TMC will be updating his mod anymore.
I am trouble.
English isn't my main language but here we go,
First of all, a big thank you for your hard work improving the old version of minecraft and adding new things. Even if it looks like your work go unnoticed by many, a few like me follow your posts every now and then.
I am going to be honest I was a little bit hesitant to try your "modification?". Because you know, it's almost 10 years old version of minecraft even if it's updated.
Long story short, after months of playing 1.18-1.19 today I thought to myself; "I am not enjoying this. This isn't fun to play, what am I doing?". I realized I had to dig to -59 levels of y to mine diamonds "efficiently" every time I traveled to a new place, because you know I enjoy exploring and not being stuck in one place. I saw many people on youtube and in multiplayer servers creating the biggest auto farms, afk farms... just to get more iron and gold that they will never use? After many many things later, today fighting with the warden for the first time was the final nail in the coffin.
I know most people won't agree with me on this, but I literally hated it seeing how unfair and uninteresting it is. I always listened something (music, youtube videos, podcasts etc.) when playing minecraft and now I can't. I have to sneak and listen the sounds constantly, so I don't get killed in one or two hit when exploring the end city. You may ask: "but creepers do enough damage to one hit you too?". Yeah, but they don't spawn if there is a light source. Warden doesn't like any of that. Every small step or sound makes it teleport near the player. Ok, I made a mistake now I can kill it with a great strategy, right? Hah, good luck with that, it has 500 hp (twice the ender dragon's). You can't kill it because.....just because. There is no reason. Oh but it can kill you, in lots of *fun* ways. It can sonic boom you through the solid blocks. Awesome. You just have to sneak in the most boring way and hope it doesn't sniff you or run away while you can. Does this sound fun to you?
Now I am trying your modification and loving it so far. It has all the things I needed without the frustration. Just one quick question would you be so kind to answer? How can I edit the mob spawning light level? I want it to be 0 like in 1.18. I never liked filling the map with torches, it's just my taste. Thank you.
I haven't added any way to configure anything (other than things like video settings), mainly because I made it for myself (the opening description is quite old but the part about being made for my own use is still accurate); I'd have to edit the code to change the light level and while I've made such a "patch" before for a personal request I can't guarantee that they will remain up-to-date (understandably, having to maintain a lot of patches makes updates more difficult, even if it is as simple as changing a constant value in a file as I'd have to separately do it for each one).
That said, I did reduce the minimum light level (Overworld only, and excluding mob spawners) from 8 to 6, mainly because this matches the minimum level displayed by cave maps (if the entire area is mapped then no mobs can spawn, other than e.g. slimes), otherwise, this has had no effect on the number of torches I use while caving, which are placed for visibility and I generally place another torch when the light level drops to 2-3 (even if you place a new torch in the first block with a light level of 0 the minimum light level between torches will be 7, and in order to get the most out of a minimum light level of 1 you'd have to go far into the dark; because of this, I'm skeptical that even the 1.18 changes would have any effect on general caving; of course, you are probably referring to lighting up a house or other structure).
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?
Oh, I thought I could change it with a few lines of simple code, my bad.
Well thanks for explaining.
I decided to make a patch anyway, including one that disables the "attack cooldown/penalty" feature, which I've previously made when somebody else requested it; either or both can be used at the same time (they are completely separate files, and they can easily be updated if necessary by simply changing a true/false or light level variable):
https://www.dropbox.com/s/2ee5j78zexp29al/TMCWv5_patches.zip?dl=0
Note that only natural mob spawning in the Overworld is affected and this only applies to block light (the Nether, End, and mob spawners still use the original light level of 8, as does the behavior of sky light, and some mobs, like slimes (slime chunks only), ignore it entirely or have their own rules, similar to the latest vanilla 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?
Woah! This is awesome, I wasn't expecting a patch, not to mention this fast. Thank you so much.
Now's the time to play more
Hi, Master Caver!
Thanks a ton for your mod, it's bringning me endless joy, when discovering all the new things and caving, of course. The only thing which bothers me a little is the texture noise in the distance. Do you think you could add mipmapping with some anti-aliasing?
I'd need source code from an open-source mod that implements these; I can only seem to find Optifine, which is not open-source and makes a lot of unrelated changes (I have decompiled it; while I added features similar to ones it adds I did not copy its code). Also even current vanilla versions have issues with textures when anti-aliasing and anisotropic filtering are enabled (via the GPU control panel), and Mojang did temporarily add anisotropic filtering in 1.7 but removed it in 1.8 due to issues (I've never used Optifine's settings so I don't know how well it works or whether it has the aforementioned texture bugs. Note that my only experience with working with OpenGL is basic rendering stuff, and a lot of the block rendering code doesn't even directly use OpenGL, rather indirectly via a "tessellator").
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?
All right, understood! Anyway, it's only a small bother in open spaces, underground this issue is hardly noticeable. Once again, great mod, thank you for it. I couldn't help but play it in coop with my wife, although I know, it is single player only. Nevertheless, it plays awesome. Cheers!
Do you mean open to LAN? The main issue with multiplayer is the dedicated server, which would require a separate mod, or at least patch (the client's internal server is mostly the same but there are some incompatibilities), otherwise, any issues are due to the way I fixed various bugs and send custom data between the client and server (for example, the "attack penalty" won't penalize missed attacks as I have the client side directly setting the variable on the server side, which is only possible if they are in the same process; conversely, hitting damage-immune mobs still works but all players share the same variable). I have considered making all or at least most of these things use the network, as I did a while back for server-side particles by making use of a function the game already had (up to now I've avoided trying to add any actual new packets).
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?
Yes, LAN play. From what I noticed so far is that only the host has the extended statistics on mobs killed, ore mined, etc. in the extended inventory window overlay (when you press R in the inventory). Anyway, this is really nothing.
Hello, lovely people of the Minecraft Forums! I know that this is my first post here. However, I must say that I'm really enjoying this mod! Especially with its new additions from cave generation, new blocks and items, and performance. I've got a few suggestions to be backported from future and past versions for TheMasterCaver's World.
More context for the suggestions if you're confused. More End islands for End Terrain Generation. If I come up with any more suggestions, I'll be sure to let you know. Thank you, and have a blessed day!
Disclaimer: I don't care if you add these suggestions or not to your mod. As it's your envision of how Minecraft should've been in your eyes.
Dear MasterCaver,
a thousand thanks for this mod. Your vision of minecraft is really amazing and It has become my number one "to go" version of the game.
I would like to edit the lightmap and bring back the old, darker nights from beta 1.7.3 and earlier versions, however I have no experience with modding minecraft. I've only done mods (not addons) for World Of Warcraft since that was and still is the main game I play (and mod).
If you have time, could you please tell me how I could do that? I read a bit online and saw people suggesting using a custom lightmap along with mcpatcher or using optifine. Now I know that optifine doesn't work with V5 of your mod and I don't think mcpatcher works either - I have no experience with them to begin with since I mostly played vanilla minecraft since 2010 till present day (without manually installing mods).
I found a lightmap that mimics the alpha/beta lighting from a resourcepack called "NostalgiaCraft" but I don't think it works without mcpatcher. Is there any other way to bring the old lightning into your version of minecraft?
Thank you for all of your efforts once more! Really loving the game!
I have no idea how to replicate the old lighting; the code that newer versions use to dynamically create the lightmap (done in code with no actual texture) doesn't seem to exist and they just appeared to change the brightness of blocks when rendering chunks (which is why day-night transitions involved chunk updates instead of a smooth transition).
Also, Moody already looks extremely dark to me, especially during a new moon; IMO most people have their monitors set WAY too bright and/or with a bad gamma curve (I set the gamma slider in Windows' display calibration tool to as low as it can go, and it still shows that it is correct; the default makes everything look washed-out):
The "gamma offset" setting can be found on the third page of video settings, although it doesn't work on Moody since its effect scales up as brightness is increased (it is intended to offset the inflation of lower light levels at higher brightness settings):
Interestingly, Optifine originally added a brightness slider (since added to vanilla) with the claim that properly calibrated monitors made the game look too dark at night (whether Optifine's method is the same or vanilla is unknown; one issue with vanilla is that a light level of 0 is not completely dark so it is affected, not just light levels 1-14, as a proper gamma adjustment would affect):
This is also reflected in the way I light up caves; I place torches for the light itself, not to prevent mob spawning, and play with brightness set to Bright, yet place a thousand or more torches per play session, and can't even imagine how I'd get by with Moody lighting:
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?