MineClone2 replicates the gameplay of Minecraft. It mostly works. Yet, I can not recommend the game without reservations.
Reasons:
Inventory items can turn into other items in new MineClone2 versions: E.g. all lapis (a rare gem) items turned into blue dye (can be gotten from flowers). IIRC the reason was that in a refactoring names for items got shuffled, and contributor and maintainer did not seem to understand how item aliases work – their fix was to add a recipe to make lapis from blue dye and to also disable the dropping of blue dye from flowers.
Texture names are not stable: Texture packs and mods that depends on MineClone2 texture names break in new versions. Texture files had stable file names originally, but at some point the dev team decided to put all files in one folder (instead of their mod's texture folders). This made it difficult to know which mod a texture belonged to, which resulted in filenames being prefixed with a mod name. Every time this is done, it breaks every usage of a texture file name in texture packs and other mods, which then need to be updated.
Mods are ill-defined and often tightly coupled: When new functionality is added, it is often added to some existing mod, even if that only makes sense from an aesthetic and not from an architecture point of view. Also, when functionality is rewritten in an incompatible way, in MineClone2 the new implementation often keeps the mod name. This makes it impossible to depend on the presence of certain features. You can not depend on the presence of crying obsidian, as it was added to mcl_core instead of being made its own mod – while the respawn anchor implementation was added to mcl_beds.
I believe the underlying reason for all of these decisions is the same: Contributions are generally valued and accepted – even if their design is so awful that doing nothing would yield a better experience for players and creators of texture-packs and third-party mods.
Just in case that someone responds to this that “progress needs sacrifice” or “this is still in beta”: IIRC I have, for all of these cases, pointed out how to implement the desired change without breaking user worlds, texture packs, or third-party mods. What is done here is not progress … it is doing the first thing that comes to mind and doubling down on that solution even if someone points out that it can be done better with less code or effort (in some cases, simply by not doing a questionable refactoring).
If you want to see how it can be done differently, just look at the actual Minetest engine, which actually does walk back changes that turn out to be ill-advised if people make enough noise about it before the next release. Minetest engine development is by no means a quality software engineering example, but contributions are often enough rejected, taken back or fixed if they unintentionally break stuff that used to work (not if they break it intentionally though). Compare this to MineClone2, where if a contributor adds a new feature (or even just refactors some code) and breaks some existing functionality, this is apparently entirely okay (as evidenced by the lapis conversion dye-saster).
Anyway, if you play this game without a texture pack, these kind of things will only occasionally annoy you. If you play it with a texture pack though, expect frequent breakage. And if you use some third-party mod that depends on some stuff in MineClone2, expect it to randomly break within about a year or so (and expect it to stay broken until the developer of that mod updates it to unbreak it).
Inventory items can turn into other items in new MineClone2 versions
The decision to do it like that is temporary, to help people through the change, and the conversion won't be possible for long.
Texture names are not stable
They are stable, they don't need further renaming, and mods can easily be updated for this. If a mod gets abandoned, or the maintainer doesn't care to handle a one-time change, then it's on them.
So making two big points about two low-impact changes and that are no longer true makes no sense. And maintaining compatibility with old versions of mods that are not even updated to run without warnings or errors with the most recent Minetest versions is not a net gain.
We can easily make a way longer list of engine changes that forced a lot of people to update their mods for various reasons, from texture clipping, explicit item descriptions being required, new vectors, changes in image format or font support, mod dependency enforcement, various deprecations, etc. Progress sometimes comes at a cost, but most of these are small and easy to deal with.
As with everything, it's a great idea not to use outdated stuff. And people who choose to do so can also contribute with compatibility updates, considering we're talking about open source software. You can't expect a handful of developers to be both productive and work at standards at or above those in the industry.
"Inventory items can turn into other items in new MineClone2 versions: ..."
You cannot yet make blue dye from flowers, we left that out for players to convert their old lapis (now blue dye) back into lapis from blue dye, we added this to the release notes also. It will be left in for 3-6 months.
"Texture names are not stable: ..."
They were named incorrectly and not to standards, we made the decision to change them once. At the time, we weren't aware of mod impact issues. Once aware, we worked with the one author impacted and apologised and they actually agreed with the change and that it was neccessary.
"Mods are ill-defined and often tightly coupled: ...."
I agree with you on this, and unfortunately both happened and was released long before I became maintainer. I have taken your points on board and will try to catch this in reviews in future. However, if you depend on where they've been added, it will remain a valid dependency. I can only see this being an issue if something is removed from an area.
I often agree on the importance of the things you care about, but will sometimes come to different conclusions on what is the best path forward. I appreciated hearing your perspective on this a few months ago when you raised it on IRC, and I'm always happy to get feedback on how we can improve things, but hyperbole such as "x will always break", or "x will break again", or "x will keep changing" isn't particularly helpful to a technical discussion, 'cause often it's factually incorrect. It's always better to ask why, rather than ranting on IRC and casting negative aspersions on people's character and incorrectly assuming their motives.
As far as my experience goes, everyone who breaks stuff needlessly always seems to claim that it is temporary, a one-time-change, that there are workarounds, that others should just fix what is broken now etc. … this is a common trope – we need not discuss it further, I have seen everything.
The fact of the matter is that “converting all hard-to-get gems into common blue dye” was a 100% avoidable part of the refactoring that happened: Simply using item names and their aliases correctly (exactly like every other Minetest mod or game does) would have avoided it. So there is no gain at all – just low quality contributions being merged (instead of being rejected for breaking stuff unnecessarily).
I often agree on the importance of the things you care about, but will sometimes come to different conclusions on what is the best path forward. I appreciated hearing your perspective on this a few months ago when you raised it on IRC, and I'm always happy to get feedback on how we can improve thing
I appreciate you listening. Just to note it here for posterity: For both the item name and the texture name thing (which again, breaks about every single MineClone2-specific texture pack that has worked for years before) I have suggested multiple solutions that could have achieved a very similar result, but would not have resulted in any breakage. Those solutions would have been a tiny bit of more work on the part of the MineClone 2 contributors – from my POV people were not willing to do the work to fix the mess they caused, demanding others do it. It is probably not fun to do it.
In my opinion, it is the maintainers most important job to make sure that contributions meet quality standards, e.g. not needlessly break things, to not alienate people using the software. Precisely because MineClone 2 keeps breaking stuff, I do not think it is a good foundation for developing a mod depending on it.
hyperbole such as "x will always break", or "x will break again", or "x will keep changing" isn't particularly helpful to a technical discussion, 'cause often it's factually incorrect
@ancientmariner my complaint is not necessarily about about you (the current maintainer) in particular – even though you do have a reputation of merging low-effort contributions that add new bugs or even enable new exploits. Previous maintainers of MineClone 2 and its forks have also broken things time and time again – and IIRC they also claimed every time that it was a one-time thing. Back then also most breakage I saw was not technically necessary … you just approved much more of it at once.
I fully expect the next maintainer to also break some stuff and then claim that it was a one-time-thing. I don't quite expect them (or you, for that matter) to break stuff as far as the item and texture breakages did, because I consider both of them the same type of beginner mistake in terms of systems engineering. (In my experience, the only people who do this kind of mistake more-than-a-few times are so arrogant neither of us could match a fraction of their raw ego.)
MineClone2 replicates the gameplay of Minecraft. It mostly works. Yet, I can not recommend the game without reservations.
Reasons:
Inventory items can turn into other items in new MineClone2 versions: E.g. all lapis (a rare gem) items turned into blue dye (can be gotten from flowers). IIRC the reason was that in a refactoring names for items got shuffled, and contributor and maintainer did not seem to understand how item aliases work – their fix was to add a recipe to make lapis from blue dye and to also disable the dropping of blue dye from flowers.
Texture names are not stable: Texture packs and mods that depends on MineClone2 texture names break in new versions. Texture files had stable file names originally, but at some point the dev team decided to put all files in one folder (instead of their mod's texture folders). This made it difficult to know which mod a texture belonged to, which resulted in filenames being prefixed with a mod name. Every time this is done, it breaks every usage of a texture file name in texture packs and other mods, which then need to be updated.
Mods are ill-defined and often tightly coupled: When new functionality is added, it is often added to some existing mod, even if that only makes sense from an aesthetic and not from an architecture point of view. Also, when functionality is rewritten in an incompatible way, in MineClone2 the new implementation often keeps the mod name. This makes it impossible to depend on the presence of certain features. You can not depend on the presence of crying obsidian, as it was added to mcl_core instead of being made its own mod – while the respawn anchor implementation was added to mcl_beds.
I believe the underlying reason for all of these decisions is the same: Contributions are generally valued and accepted – even if their design is so awful that doing nothing would yield a better experience for players and creators of texture-packs and third-party mods.
Just in case that someone responds to this that “progress needs sacrifice” or “this is still in beta”: IIRC I have, for all of these cases, pointed out how to implement the desired change without breaking user worlds, texture packs, or third-party mods. What is done here is not progress … it is doing the first thing that comes to mind and doubling down on that solution even if someone points out that it can be done better with less code or effort (in some cases, simply by not doing a questionable refactoring).
If you want to see how it can be done differently, just look at the actual Minetest engine, which actually does walk back changes that turn out to be ill-advised if people make enough noise about it before the next release. Minetest engine development is by no means a quality software engineering example, but contributions are often enough rejected, taken back or fixed if they unintentionally break stuff that used to work (not if they break it intentionally though). Compare this to MineClone2, where if a contributor adds a new feature (or even just refactors some code) and breaks some existing functionality, this is apparently entirely okay (as evidenced by the lapis conversion dye-saster).
Anyway, if you play this game without a texture pack, these kind of things will only occasionally annoy you. If you play it with a texture pack though, expect frequent breakage. And if you use some third-party mod that depends on some stuff in MineClone2, expect it to randomly break within about a year or so (and expect it to stay broken until the developer of that mod updates it to unbreak it).
The decision to do it like that is temporary, to help people through the change, and the conversion won't be possible for long.
They are stable, they don't need further renaming, and mods can easily be updated for this. If a mod gets abandoned, or the maintainer doesn't care to handle a one-time change, then it's on them.
So making two big points about two low-impact changes and that are no longer true makes no sense. And maintaining compatibility with old versions of mods that are not even updated to run without warnings or errors with the most recent Minetest versions is not a net gain.
We can easily make a way longer list of engine changes that forced a lot of people to update their mods for various reasons, from texture clipping, explicit item descriptions being required, new vectors, changes in image format or font support, mod dependency enforcement, various deprecations, etc. Progress sometimes comes at a cost, but most of these are small and easy to deal with.
As with everything, it's a great idea not to use outdated stuff. And people who choose to do so can also contribute with compatibility updates, considering we're talking about open source software. You can't expect a handful of developers to be both productive and work at standards at or above those in the industry.
"Inventory items can turn into other items in new MineClone2 versions: ..."
You cannot yet make blue dye from flowers, we left that out for players to convert their old lapis (now blue dye) back into lapis from blue dye, we added this to the release notes also. It will be left in for 3-6 months.
"Texture names are not stable: ..."
They were named incorrectly and not to standards, we made the decision to change them once. At the time, we weren't aware of mod impact issues. Once aware, we worked with the one author impacted and apologised and they actually agreed with the change and that it was neccessary.
"Mods are ill-defined and often tightly coupled: ...."
I agree with you on this, and unfortunately both happened and was released long before I became maintainer. I have taken your points on board and will try to catch this in reviews in future. However, if you depend on where they've been added, it will remain a valid dependency. I can only see this being an issue if something is removed from an area.
I often agree on the importance of the things you care about, but will sometimes come to different conclusions on what is the best path forward. I appreciated hearing your perspective on this a few months ago when you raised it on IRC, and I'm always happy to get feedback on how we can improve things, but hyperbole such as "x will always break", or "x will break again", or "x will keep changing" isn't particularly helpful to a technical discussion, 'cause often it's factually incorrect. It's always better to ask why, rather than ranting on IRC and casting negative aspersions on people's character and incorrectly assuming their motives.
As far as my experience goes, everyone who breaks stuff needlessly always seems to claim that it is temporary, a one-time-change, that there are workarounds, that others should just fix what is broken now etc. … this is a common trope – we need not discuss it further, I have seen everything.
The fact of the matter is that “converting all hard-to-get gems into common blue dye” was a 100% avoidable part of the refactoring that happened: Simply using item names and their aliases correctly (exactly like every other Minetest mod or game does) would have avoided it. So there is no gain at all – just low quality contributions being merged (instead of being rejected for breaking stuff unnecessarily).
I appreciate you listening. Just to note it here for posterity: For both the item name and the texture name thing (which again, breaks about every single MineClone2-specific texture pack that has worked for years before) I have suggested multiple solutions that could have achieved a very similar result, but would not have resulted in any breakage. Those solutions would have been a tiny bit of more work on the part of the MineClone 2 contributors – from my POV people were not willing to do the work to fix the mess they caused, demanding others do it. It is probably not fun to do it.
In my opinion, it is the maintainers most important job to make sure that contributions meet quality standards, e.g. not needlessly break things, to not alienate people using the software. Precisely because MineClone 2 keeps breaking stuff, I do not think it is a good foundation for developing a mod depending on it.
@ancientmariner my complaint is not necessarily about about you (the current maintainer) in particular – even though you do have a reputation of merging low-effort contributions that add new bugs or even enable new exploits. Previous maintainers of MineClone 2 and its forks have also broken things time and time again – and IIRC they also claimed every time that it was a one-time thing. Back then also most breakage I saw was not technically necessary … you just approved much more of it at once.
I fully expect the next maintainer to also break some stuff and then claim that it was a one-time-thing. I don't quite expect them (or you, for that matter) to break stuff as far as the item and texture breakages did, because I consider both of them the same type of beginner mistake in terms of systems engineering. (In my experience, the only people who do this kind of mistake more-than-a-few times are so arrogant neither of us could match a fraction of their raw ego.)