Reconsider the renaming of texture files #3802

New Issue

ryvnf · 2023-06-16T17:45:39+02:00

ryvnf commented

2023-06-16 17:45:39 +02:00

I see that you have started to rename texture files not following the mod prefix naming convention for MineClone 2. There is one merged PR #3708 and another #3758 waiting for review. I strongly encourage you to reconsider if it is worth proceeding with changes like this and its implications.

I am not sure if you are aware but the names of these files are not random. They are named to allow texture packs to support both Mineclone, Minetest Game and other games by providing textures named default_dirt.png, default_tool_steelpick.png, wool_blue.png etc.

Renaming the texture files will not only

Break compatibility with all existing texture packs for MineClone 2
Make texture packs for MineClone 2 incompatible with Mineclonia (we will definitely not be doing this)

It will also

Make it difficult for people making texture packs to support multiple games/mods
Texture packs for other games will not work with MineClone 2

Why are you even doing this? How is this motivated for something as small and insignificant as having different names for a few files? It just feels so incredibly unnecessary.

I think you should revert #3708, close #3758 and abort doing this before it leads to texture packs becoming fragmented within the Minetest community.

I see that you have started to rename texture files not following the mod prefix naming convention for MineClone 2. There is one merged PR #3708 and another #3758 waiting for review. I **strongly encourage** you to reconsider if it is worth proceeding with changes like this and its implications. I am not sure if you are aware but the names of these files are not random. They are named to allow texture packs to support both Mineclone, Minetest Game and other games by providing textures named `default_dirt.png`, `default_tool_steelpick.png`, `wool_blue.png` etc. Renaming the texture files will not only - Break compatibility with all existing texture packs for MineClone 2 - Make texture packs for MineClone 2 incompatible with Mineclonia (we will definitely not be doing this) It will also - Make it difficult for people making texture packs to support multiple games/mods - Texture packs for other games will not work with MineClone 2 Why are you even doing this? How is this motivated for something as small and insignificant as having different names for a few files? It just feels so incredibly unnecessary. I think you should revert #3708, close #3758 and abort doing this before it leads to texture packs becoming fragmented within the Minetest community.

ancientmarinerdev commented

2023-06-16 22:28:56 +02:00

This work was originally kicked off by your colleague to move assets to one folder:

MineClone2/MineClone2#3026

Discussed here:

MineClone2/MineClone2#3380

And finally:

MineClone2/MineClone2#3392

There may have been another issue or PR which I cannot seem to find right now.

Assets were incorrectly named from day 1 and against standards. As part of consolidating assets, it became clear that it was quite messy and difficult to maintain and the decision was taken to rename those not following minetest conventions so we are aware what assets are associated with which mod.

No comments were originally raised about breaking mods, and we unfortunately later discovered this one with mod. I discussed with this with the mod author, and they agreed with the decision, supported it, and renamed their assets.

Any textures renamed will as far as I'm aware revert back to their mcl2 default, which isn't ideal. However, long term, it'll make it easier to create, convert and maintain texture packs.

While I appreciate your sentiment, and have heard the arguments multiple times after the decision was taken, including from your old colleague Ehrlemann (sp?) in less than polite terms, I have to weigh up what is the right decision long term. While there will be some short term teething problems, and that sucks, it makes the codebase, quality and texture pack process easier long term so is right imho. The mineclone2 codebase is not in a good state, and I'm sure you'll agree with that. We either leave it in this state indefinitely, or we take steps to improve this, and the expectations of perfect backward compatibility permanently for a game that hasn't even hit version 1.0 at the cost of not being able to not improve the codebase isn't right. As a result, it is the right decision even factoring in the short term cost and I have not seen enough of an argument to sway me in this regards.

In regards to mcla and backwards compatibility, rather than forking from a later version, and improving things, it seems a decision was taken to fork months/releases earlier and many PRs have been rewritten because of personal preference over codestyle/commit style, or potentially other reasons. Of course, this is your right to do that, but if mcla isn't too focused on backwards/cross compatibility, it would be a little unfair to expect more from us in this regards.

Thanks for raising the issues, but I do not expect the decision will change in the way you expect. I wish you all the best success with Mineclonia.

This work was originally kicked off by your colleague to move assets to one folder: https://git.minetest.land/MineClone2/MineClone2/pulls/3026 Discussed here: https://git.minetest.land/MineClone2/MineClone2/pulls/3380 And finally: https://git.minetest.land/MineClone2/MineClone2/issues/3392 There may have been another issue or PR which I cannot seem to find right now. Assets were incorrectly named from day 1 and against standards. As part of consolidating assets, it became clear that it was quite messy and difficult to maintain and the decision was taken to rename those not following minetest conventions so we are aware what assets are associated with which mod. No comments were originally raised about breaking mods, and we unfortunately later discovered this one with mod. I discussed with this with the mod author, and they agreed with the decision, supported it, and renamed their assets. Any textures renamed will as far as I'm aware revert back to their mcl2 default, which isn't ideal. However, long term, it'll make it easier to create, convert and maintain texture packs. While I appreciate your sentiment, and have heard the arguments multiple times after the decision was taken, including from your old colleague Ehrlemann (sp?) in less than polite terms, I have to weigh up what is the right decision long term. While there will be some short term teething problems, and that sucks, it makes the codebase, quality and texture pack process easier long term so is right imho. The mineclone2 codebase is not in a good state, and I'm sure you'll agree with that. We either leave it in this state indefinitely, or we take steps to improve this, and the expectations of perfect backward compatibility permanently for a game that hasn't even hit version 1.0 at the cost of not being able to not improve the codebase isn't right. As a result, it is the right decision even factoring in the short term cost and I have not seen enough of an argument to sway me in this regards. In regards to mcla and backwards compatibility, rather than forking from a later version, and improving things, it seems a decision was taken to fork months/releases earlier and many PRs have been rewritten because of personal preference over codestyle/commit style, or potentially other reasons. Of course, this is your right to do that, but if mcla isn't too focused on backwards/cross compatibility, it would be a little unfair to expect more from us in this regards. Thanks for raising the issues, but I do not expect the decision will change in the way you expect. I wish you all the best success with Mineclonia.

👍 1

ryvnf commented

2023-06-17 05:11:18 +02:00

Thanks for you response. I wanted you to be aware of all the points I raised, even though I assumed you have probably heard some of them before. I have not been in contact with erlehmann or anyone else except for cora lately so I would not know. Since you have not yet released a minor version with this change I figured there might be still some chance for it to be rolled back.

I would say I am more concerned with what this means long term rather than the short term incompatibilities introduced. Even games which are quite different from Minetest Game (like Repixture) use texture names from Minetest Game to make it easy for texture packs to modify its assets. I think it is unfortunate if MineClone 2 breaks that practice and people have to start maintaining multiple copies of texture packs in order to support different games. As far as improving the codebase quality, I also think the gains of this are very questionable.

A few words on compatibility between MineClone 2 and Mineclonia. I do not really expect the games to be compatible since we want the flexibility to do things our own way. Initially I wanted to aim for modding compatibility between the two, but it seems like that might be difficult as well considering the fact that incompatible modding APIs have already been introduced since then. I think them becoming texture pack incompatible is very unfortunate but unless Minetest introduces support for texture aliases I doubt we can find a solution.

I understand you make your own decisions and I am glad we have the fork so we can make our own. Closing the issue. Good luck with MineClone 2 as well!

Thanks for you response. I wanted you to be aware of all the points I raised, even though I assumed you have probably heard some of them before. I have not been in contact with erlehmann or anyone else except for cora lately so I would not know. Since you have not yet released a minor version with this change I figured there might be still some chance for it to be rolled back. I would say I am more concerned with what this means long term rather than the short term incompatibilities introduced. Even games which are quite different from Minetest Game (like [Repixture](https://codeberg.org/Wuzzy/Repixture)) use texture names from Minetest Game to make it easy for texture packs to modify its assets. I think it is unfortunate if MineClone 2 breaks that practice and people have to start maintaining multiple copies of texture packs in order to support different games. As far as improving the codebase quality, I also think the gains of this are very questionable. A few words on compatibility between MineClone 2 and Mineclonia. I do not really expect the games to be compatible since we want the flexibility to do things our own way. Initially I wanted to aim for modding compatibility between the two, but it seems like that might be difficult as well considering the fact that incompatible modding APIs have already been introduced since then. I think them becoming texture pack incompatible is very unfortunate but unless Minetest introduces support for texture aliases I doubt we can find a solution. I understand you make your own decisions and I am glad we have the fork so we can make our own. Closing the issue. Good luck with MineClone 2 as well!

ryvnf closed this issue

2023-06-17 05:11:20 +02:00

Ghost commented

2023-06-17 16:07:39 +02:00

MineClone 2 is such a different game from MineTest Game, that I find it a necessary evil to fully break any texture packs which haven't been explicitly made with MineClone 2 in mind.

When you try to use any texture packs which weren't made with MineClone 2 in mind, the result is a mishmash of many different textures, which just looks ugly.

A compromise could be made, however. MineClone 2 has a texture pack converter tool to convert MC textures to MCL2 textures. It shouldn't be too difficult to create a similar tool to convert MineTest Game textures into MCL2 textures.

MineClone 2 is such a different game from MineTest Game, that I find it a necessary evil to fully break any texture packs which haven't been *explicitly* made with MineClone 2 in mind. When you try to use any texture packs which weren't made with MineClone 2 in mind, the result is a mishmash of many different textures, which just looks ugly. A compromise could be made, however. MineClone 2 has a texture pack converter tool to convert MC textures to MCL2 textures. It shouldn't be too difficult to create a similar tool to convert MineTest Game textures into MCL2 textures.

chmodsayshello commented

2023-06-17 20:41:52 +02:00

Let's face the truth though: The texture converter didnt get fully updated in a long time... I've attempted to do so when 1.18 released, and after ca 70% I've stopped doing so, because it was really mundane in the long run

Sign in to join this conversation.