Edit 2023-11-30:Mineclonia is a fork of MineClone2 with more Minecraft-like features that uses much less RAM. Mineclonia runs on devices on which MineClone2 crashes, only lacking music and the hamburger (which is not in Minecraft).
MineClone2 replicates Minecraft gameplay. It mostly works. Yet, I can not recommend the game, because of questionable dev practices.
Reasons:
Items turn into other items in new versions: Lapis (a rare gem) items turned into blue dye (made from flowers). In a refactoring item names got shuffled, and the devs did not understand item aliases; the fix was to add a recipe to make lapis from blue dye and disable crafting blue dye from flowers.
Texture names change: Texture packs and mods that depends on MineClone2 texture names break in new versions. Textures had stable file names originally, but the dev team put all files in one folder instead of mod's texture folders, with filenames prefixed with mod names. Whenever 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: New functionality is often added to an existing mod, even if it only makes sense from an aesthetic and not from an architecture point of view. 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 reason for all of these decisions is the same: Contributions are generally valued – even if they are 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.)
Are you going to add a disclosure to your review that you used to be a maintainer for Mineclonia with the maintainers there and are friends with them?
No amount of friendship could make me change my mind about which software I would recommend, everything else being the same. Consider the following: If I was friends with you, I would still not recommend MineClone2 in its current state.
Fact is that MineClone2 crashes on devices on which Mineclonia does not. This has nothing to do with me being friends with cora – but it has everything to do with one of these games requiring a lot more resources than the other, for little gain. As I see it, you are simply not interested in supporting devices with 2GB of RAM or less and the other team is. I updated my review not because of my friendship with cora, but because I noticed that people complained that MineClone2 does not run on their device anymore and I thought that the highest-rated negative review on the highest-rated Minetest game is a good way to point out a suitable alternative that is more lightweight.
FYI: The old Mineclonia I worked on is a fork of MineClone2 that just shares the name with the new Mineclonia (the one on ContentDB), both are forked from MineClone2 at different points in time. I believe that the improvements that it had that are part of the new Mineclonia are also part of MineClone2 … as they were either ported to MineClone2 before the new Mineclonia was forked or not ported at all.
You, and Cora worked on the old Mineclonia, so it's safe to say you were close before and that hasn't really been hidden recently and both of you are sharing the same troll image on our repo...
If we are interesting in a public statement, I'm sure we can come to you, as it seems you're unofficial spokesperson for the Mineclonia project. If the focus is to trash the rival project, it doesn't really come across too well though. Negative marketing isn't pretty. Dirt often rubs off more on those that throw it.
Of the issues you have mentioned. 1 and 3 are issues only you have complained about. Number 2, there has been a few issues that have been mopped up. The only mod so far impacted, actually agreed with the change and was happy to resolve the issue. Repeatedly talking about issues only you have an issue with doesn't make the issue any more significant.
I've seen very little mention of crashes other than from yourself or those involved in the Mineclonia project. It comes across more as negative marketing, than any legitimate issue.
We don't really support devices less than 2gb of ram as even if you do, eventually the world gets big and it goes pop. We also don't feel removing music is a good experience, and the benefits are questionable for most.
it seems you're unofficial spokesperson for the Mineclonia project
I am very much not a spokesperson for the current Mineclonia.
We don't really support devices less than 2gb of ram […]
Did you know that I play Minetest on an old Thinkpad with 2GB of RAM?
Many other games for Minetest run perfectly fine on that computer.
if you do, eventually the world gets big and it goes pop
I did not know that this could happen. Do you have any proof to back up that assertion?
We also don't feel removing music is a good experience, and the benefits are questionable for most.
There exist various ways of handling music that do not result in crashes, e.g. making it a separate mod or making music opt-in for players.
By the way, no amount of arguing will change the fact that you decided that it is acceptable to make MineClone2 crash on devices on which it used to run fine. If you look at my other reviews of packages on ContentDB, you can see that usually maintainers respond by addressing the actual issues (e.g. by fixing bugs or explaining where I was mistaken in cases where I complained about stuff that I misunderstood).
Just to point it out: The best result you could achieve by discussing my motivations is making me look bad – but it does not change the reality in which Mineclonia needs a lot less resources to deliver a comparable experience to MineClone2.
Edit:
I've seen very little mention of crashes other than from yourself or those involved in the Mineclonia project.
AFAIK none of the Android users complaining in MineClone2 issue #3874 are affiliated with Mineclonia.
I am done here. Anyone interested in why MineClone2 crashes do not get fixed can just read that issue.
Many other games for Minetest run perfectly fine on that computer.
Games will a lot less content require less resources, which is why they're better on low-RAM devices. You know this, so why do you sound like you're unaware of it?
you decided that it is acceptable to make MineClone2 crash on devices on which it used to run fine.
As a software developer you know that the minimum requirements of a project can't always stay at the same level if you want more features. Minetest versions older than 5.8.0 load all the music into RAM, uncompressed. That's why removing the music is a workaround for people who want to play MineClone2 on devices with 2GB RAM on older Minetest releases.
We didn't know when exactly the sound rework PR would be shipped, but we knew it would come. We had a surge of great contributions for our soundtrack, so we welcomed it in our game at the right time. The soundtrack makes MineClone2 a very nice experience, and with the latest Minetest the RAM usage went back down - only the currently playing song is loaded into RAM, then unloaded (as far as I know). Do you really not know this?
none of the Android users complaining in MineClone2 issue #3874 are affiliated with Mineclonia.
That thread makes it obvious that old and heavily modded Android ROMs require less RAM but most people have no clue how to install such ROMs, or can't because their devices aren't supported. I believe you knew that without me pointing it out. So why do you play the ignorant card if you don't want to look bad?
Games will a lot less content require less resources
As my review points out, another game with more-or-less the same content also requires less resources.
Please accept that some people (e.g. me) value not alienating users and modders a lot more than you do.
Edit: I am not going to discuss specific issues with you any further. The reason for my bad review is not the mere existence of game-breaking bugs … but that the current MineClone2 development team a) does not fix those bugs b) keeps introducing new bugs in similar ways c) spends a lot of time explaining why those bugs are totally okay to have and should not be fixed – even if all it would take to fix such a bug would be a simple git revert.
Edit 2: IMO you should be glad that there is a competing project that works better – it should leads to less complaining in your issue tracker about bugs you are never going to fix.
"Games will a lot less content require less resources"
Yes, and the game didn't used to run smooth on old harward until I opitimized it. Dual core CPU's started running smoother when they didn't before. Those devices would have likely been a bad experience even before this, so to now suggest they're not runable is using a very narrow view of history to misrepresent how good and efficient this game was. When I took over MineClone2 in December, it was poor performance wise. I spend months optimising it, rather than focussing on the existing backlog of bugs 700+. You were very quiet when the changes for Kelp node timers, Sculk went in, raids. For those who used to maintain the project to remove some music and their friends suggest the changes we made broke it performance wise... yeah... sure, buddy. Until you can learn to be balanced, your opinion isn't going to count for much.
As my review points out, another game with more-or-less the same content also requires less resources.
Mineclonia required(past tense) less resources after the removal of the newly introduced music.
And AncientMariner raised an important point about performance. I tried MineClone2 on my Core 2 Duo laptop before he took over, and I simply decided the hardware was too dated. But after he profiled various pain points and improved the game, that old laptop can now run the game very well. Even with the added music, the game performed well on the old laptop (with 4GB RAM). And with Minetest 5.8.0, the RAM problem is gone.
You can certainly be disingenuous with unaware people, but not with those who know full well how you mispresent important differences between the two projects.
Fun fact: Back when I was still the main dev of MCL2, I have been guilty of just spamming half-finished feature after feature after feature which eventually made the codebase messier and worse: buggier. The bugs started to pile up quickly which was one of the reasons that lead to me burning out and losing all motivation for MCL2. So some of the messiness of the codebase might be my partially my fault, lol. That having said, I think I never randomly broke compability for no reason except in VERY early stages of development.
If I would pick up leadership of MCL2 again today, my first priority would be to halt all feature development and focus on bugfixing and maintenance first until the bug count has returned to a managable level. Crash bugs will have top priority. Oh, and I would 100% nuke the hamburger. XD I would also be more strict on enforcing backwards-compability.
Anyway, I mostly agree with erlehmann and think having some dev standards for such a complex project is definitely very helpful. (Before you ask, no, I will not return to MCL2 dev in any way lol.)
As for the music argument, there are good news: In MT 5.8.0, music (or any large sound files) loads now much more efficiently (devs worked on performance). I think music should be "safe to use" for most games now.
PS: I haven't been following MCL2 development for years so please excuse me if I got anything wrong.
I think it's mostly a matter of direction, MCL2's development goal is richer functionality and experience, so it often introduces destructive changes and bugs, while Mineclonia's goal is stability and low footprint, so it doesn't make much sense to discuss which is better, leave it up to the players to decide, and just explicitly tell them the difference in the focus of the two projects.
It's true that a unified standard should be effective, but I personally feel that developers like to do things their own way, so it's something that can't be done.
I think it's mostly a matter of direction, MCL2's development goal is richer functionality and experience, so it often introduces destructive changes and bugs, while Mineclonia's goal is stability and low footprint
From my point of view, Mineclonia proves that you can add functionality without breaking things. Their ContentDB page has the claim “More features but more than 15k lines of code less” … and if I am not hugely mistaken the reason that they can make this claim is clever refactoring (“doing more with less“) and avoiding creation of pointless busywork (e.g. MineClone2 devs telling authors of mods they should update their mods whenever the devs break something a mod relies on).
IMO part of it is a difference in maintainer/dev attitude.
just explicitly tell them the difference in the focus of the two projects
I thought I already did in the first post: One project has a history of breaking user worlds, mods, and texture packs – even in cases in which the breakage was not necessary for new features to be added and even when someone (e.g. me) suggested a way to eliminate breakage … and even in situations in which literally doing nothing would have been a valid alternative. The other project has generally avoided doing such things, as far as I know.
One project has a history indeed, while the other is young. Mineclonia ripped away even code that made servers more resilient to crashes - talk about claims of stability. You're happy to nitpick one's history while ignoring the issues of the other.
Edit 2023-11-30: Mineclonia is a fork of MineClone2 with more Minecraft-like features that uses much less RAM. Mineclonia runs on devices on which MineClone2 crashes, only lacking music and the hamburger (which is not in Minecraft).
MineClone2 replicates Minecraft gameplay. It mostly works. Yet, I can not recommend the game, because of questionable dev practices.
Reasons:
Items turn into other items in new versions: Lapis (a rare gem) items turned into blue dye (made from flowers). In a refactoring item names got shuffled, and the devs did not understand item aliases; the fix was to add a recipe to make lapis from blue dye and disable crafting blue dye from flowers.
Texture names change: Texture packs and mods that depends on MineClone2 texture names break in new versions. Textures had stable file names originally, but the dev team put all files in one folder instead of mod's texture folders, with filenames prefixed with mod names. Whenever 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: New functionality is often added to an existing mod, even if it only makes sense from an aesthetic and not from an architecture point of view. 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 reason for all of these decisions is the same: Contributions are generally valued – even if they are 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.)
Are you going to add a disclosure to your review that you used to be a maintainer for Mineclonia with the maintainers there and are friends with them?
Without the impartiality, it just comes across as blatant advertising.
No amount of friendship could make me change my mind about which software I would recommend, everything else being the same. Consider the following: If I was friends with you, I would still not recommend
MineClone2in its current state.Fact is that
MineClone2crashes on devices on whichMinecloniadoes not. This has nothing to do with me being friends with cora – but it has everything to do with one of these games requiring a lot more resources than the other, for little gain. As I see it, you are simply not interested in supporting devices with 2GB of RAM or less and the other team is. I updated my review not because of my friendship with cora, but because I noticed that people complained thatMineClone2does not run on their device anymore and I thought that the highest-rated negative review on the highest-rated Minetest game is a good way to point out a suitable alternative that is more lightweight.FYI: The old
MinecloniaI worked on is a fork ofMineClone2that just shares the name with the newMineclonia(the one on ContentDB), both are forked fromMineClone2at different points in time. I believe that the improvements that it had that are part of the newMinecloniaare also part ofMineClone2… as they were either ported toMineClone2before the newMinecloniawas forked or not ported at all.You, and Cora worked on the old Mineclonia, so it's safe to say you were close before and that hasn't really been hidden recently and both of you are sharing the same troll image on our repo...
If we are interesting in a public statement, I'm sure we can come to you, as it seems you're unofficial spokesperson for the Mineclonia project. If the focus is to trash the rival project, it doesn't really come across too well though. Negative marketing isn't pretty. Dirt often rubs off more on those that throw it.
Of the issues you have mentioned. 1 and 3 are issues only you have complained about. Number 2, there has been a few issues that have been mopped up. The only mod so far impacted, actually agreed with the change and was happy to resolve the issue. Repeatedly talking about issues only you have an issue with doesn't make the issue any more significant.
I've seen very little mention of crashes other than from yourself or those involved in the Mineclonia project. It comes across more as negative marketing, than any legitimate issue.
We don't really support devices less than 2gb of ram as even if you do, eventually the world gets big and it goes pop. We also don't feel removing music is a good experience, and the benefits are questionable for most.
I am very much not a spokesperson for the current
Mineclonia.Did you know that I play Minetest on an old Thinkpad with 2GB of RAM?
Many other games for Minetest run perfectly fine on that computer.
I did not know that this could happen. Do you have any proof to back up that assertion?
There exist various ways of handling music that do not result in crashes, e.g. making it a separate mod or making music opt-in for players.
By the way, no amount of arguing will change the fact that you decided that it is acceptable to make
MineClone2crash on devices on which it used to run fine. If you look at my other reviews of packages on ContentDB, you can see that usually maintainers respond by addressing the actual issues (e.g. by fixing bugs or explaining where I was mistaken in cases where I complained about stuff that I misunderstood).Just to point it out: The best result you could achieve by discussing my motivations is making me look bad – but it does not change the reality in which
Mineclonianeeds a lot less resources to deliver a comparable experience toMineClone2.Edit:
AFAIK none of the Android users complaining in
MineClone2issue #3874 are affiliated withMineclonia.I am done here. Anyone interested in why
MineClone2crashes do not get fixed can just read that issue.Games will a lot less content require less resources, which is why they're better on low-RAM devices. You know this, so why do you sound like you're unaware of it?
As a software developer you know that the minimum requirements of a project can't always stay at the same level if you want more features. Minetest versions older than 5.8.0 load all the music into RAM, uncompressed. That's why removing the music is a workaround for people who want to play MineClone2 on devices with 2GB RAM on older Minetest releases.
We didn't know when exactly the sound rework PR would be shipped, but we knew it would come. We had a surge of great contributions for our soundtrack, so we welcomed it in our game at the right time. The soundtrack makes MineClone2 a very nice experience, and with the latest Minetest the RAM usage went back down - only the currently playing song is loaded into RAM, then unloaded (as far as I know). Do you really not know this?
That thread makes it obvious that old and heavily modded Android ROMs require less RAM but most people have no clue how to install such ROMs, or can't because their devices aren't supported. I believe you knew that without me pointing it out. So why do you play the ignorant card if you don't want to look bad?
As my review points out, another game with more-or-less the same content also requires less resources.
Please accept that some people (e.g. me) value not alienating users and modders a lot more than you do.
Edit: I am not going to discuss specific issues with you any further. The reason for my bad review is not the mere existence of game-breaking bugs … but that the current
MineClone2development team a) does not fix those bugs b) keeps introducing new bugs in similar ways c) spends a lot of time explaining why those bugs are totally okay to have and should not be fixed – even if all it would take to fix such a bug would be a simplegit revert.Edit 2: IMO you should be glad that there is a competing project that works better – it should leads to less complaining in your issue tracker about bugs you are never going to fix.
"Games will a lot less content require less resources"
Yes, and the game didn't used to run smooth on old harward until I opitimized it. Dual core CPU's started running smoother when they didn't before. Those devices would have likely been a bad experience even before this, so to now suggest they're not runable is using a very narrow view of history to misrepresent how good and efficient this game was. When I took over MineClone2 in December, it was poor performance wise. I spend months optimising it, rather than focussing on the existing backlog of bugs 700+. You were very quiet when the changes for Kelp node timers, Sculk went in, raids. For those who used to maintain the project to remove some music and their friends suggest the changes we made broke it performance wise... yeah... sure, buddy. Until you can learn to be balanced, your opinion isn't going to count for much.
Mineclonia required (past tense) less resources after the removal of the newly introduced music.
And AncientMariner raised an important point about performance. I tried MineClone2 on my Core 2 Duo laptop before he took over, and I simply decided the hardware was too dated. But after he profiled various pain points and improved the game, that old laptop can now run the game very well. Even with the added music, the game performed well on the old laptop (with 4GB RAM). And with Minetest 5.8.0, the RAM problem is gone.
You can certainly be disingenuous with unaware people, but not with those who know full well how you mispresent important differences between the two projects.
Fun fact: Back when I was still the main dev of MCL2, I have been guilty of just spamming half-finished feature after feature after feature which eventually made the codebase messier and worse: buggier. The bugs started to pile up quickly which was one of the reasons that lead to me burning out and losing all motivation for MCL2. So some of the messiness of the codebase might be my partially my fault, lol. That having said, I think I never randomly broke compability for no reason except in VERY early stages of development.
If I would pick up leadership of MCL2 again today, my first priority would be to halt all feature development and focus on bugfixing and maintenance first until the bug count has returned to a managable level. Crash bugs will have top priority. Oh, and I would 100% nuke the hamburger. XD I would also be more strict on enforcing backwards-compability.
Anyway, I mostly agree with erlehmann and think having some dev standards for such a complex project is definitely very helpful. (Before you ask, no, I will not return to MCL2 dev in any way lol.)
As for the music argument, there are good news: In MT 5.8.0, music (or any large sound files) loads now much more efficiently (devs worked on performance). I think music should be "safe to use" for most games now.
PS: I haven't been following MCL2 development for years so please excuse me if I got anything wrong.
I think it's mostly a matter of direction, MCL2's development goal is richer functionality and experience, so it often introduces destructive changes and bugs, while Mineclonia's goal is stability and low footprint, so it doesn't make much sense to discuss which is better, leave it up to the players to decide, and just explicitly tell them the difference in the focus of the two projects.
It's true that a unified standard should be effective, but I personally feel that developers like to do things their own way, so it's something that can't be done.
From my point of view, Mineclonia proves that you can add functionality without breaking things. Their ContentDB page has the claim “More features but more than 15k lines of code less” … and if I am not hugely mistaken the reason that they can make this claim is clever refactoring (“doing more with less“) and avoiding creation of pointless busywork (e.g. MineClone2 devs telling authors of mods they should update their mods whenever the devs break something a mod relies on).
IMO part of it is a difference in maintainer/dev attitude.
I thought I already did in the first post: One project has a history of breaking user worlds, mods, and texture packs – even in cases in which the breakage was not necessary for new features to be added and even when someone (e.g. me) suggested a way to eliminate breakage … and even in situations in which literally doing nothing would have been a valid alternative. The other project has generally avoided doing such things, as far as I know.
One project has a history indeed, while the other is young. Mineclonia ripped away even code that made servers more resilient to crashes - talk about claims of stability. You're happy to nitpick one's history while ignoring the issues of the other.