![]() ![]() The use case for this was: I was thinking of making a sub-game that relocated the action to an imaginary planet with completely different animals, minerals and vegetables from those found on earth. I can see the value in splitting out the functionality from a programming POV, but even so, I think that would be better done with a a in each mod. This is because I'm a sub-game designer and my interest in Minetest Game is primarily as a basis for modification, although I do play it occasionally. In my mind default should contain the minimum necessary for terrain generation excluding decorations. What I don't like about default is that it mixes minerals, flora and equipment together. Having the content in one mod and functionality in another I find really confusing. This makes it much simpler to add and remove node types. I prefer to keep the functionality and content of each node type together, one file for each node type or group of related nodes. Personally I don't like your approach although I do understand why you would want to do that. I can see that the reason this is never going to happen is that we will never agree on how to refactor things. Please suggest counter proposals and improvements, and any problems.ĮDIT by SmallJoker: is down, replaced IRC link with Add a meta-mod (sort of) called "default" which depends on all other mods.Dirt, stone, grass, ores, trees, cactus, papyrus.default_natural, default_environment or default_mapgen.This is needed if a separate mod points from something to an old name. We could leave the old default:item names, however that is inconsistent. Changing names and aliasing requires complicated aliases.This could be solved using a default_lib mod.However we'd be assuming that mods in game/ were maintained by the subgame creator to know about the split, which isn't ideal. As mods/ mods are loaded after game/ mods, we could just call the library default.Ideally these should be defined by a default mod which loads first and only has library stuff, but this breaks backwards compatibility.Sharing default.node_sounds / having a default api.If not done correctly, could end up in removal of backwards compatibility.Easier for subgames to separate certain features.Easier to override and customise from mods.Default has turned into a mod where you place stuff if you can't be bothered to think of a new modname or make a new folder. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |