FOSS gamedev and creative worlds

Based on the Github discussion I decided to try to make a modding base for Minetest. I want to split the default mod from Minetest Game into several mods, ignoring backwards compatibility at this point.

I successfully removed furnace and torch, also lava, and moved them into separate mods. Now they can be easily replaced by own mods or completely removed, including ABMs.

Each group of tools, based on the material, should become it's own mod, each tree including schematics and textures should become it's own mod etc

It should be possible to convert most of the mods with aliases.

The idea is that it should be easier to make a subgame. Currently it is difficult or impossible to make modifications without editing the MTGame code or it is just a lot of work to overwrite existing tools or nodes

here is some progress. The highlighted mods are from the default mod

I moved the ores into a modpack. Each ore has its own mod and can easily removed

The code should still be compatible with mods. The code should be compatible to MTGame

Early adopters can take a look here https://github.com/MarkuBu/minetest_game/tree/mod_base

In the next step I will move the tools into a modpack, one mod for each material

There might some bugs I missed or some missing dependencies. Feel free to report anything.

Good idea I think.

Just makes things more complicated, don't ya think?
Tried doing this once and gave up. :P

I applaud this experiment. Default is the single worst design flaw of Minetest Game, it's so bloated.
Another things I would definitely split off default are the player model and GUI settings. Sound functions would also be useful to be in their own mod, as I have seen it very often that mods had to depend on default only for sounds.

I already extracted the player model and put it into a seperate mod:
viewtopic.php?f=11&t=10349

It might make sense to merge in stuff like wieldhand and moving heads to make a proper player model. I'm too lazy to search for these mods now. And I'm also unwilling to make any updates to the playermodel mod right now. At least it is stable and works.

I think having 1 mod per ore is overkill. Papyrus and cactus are technically very similar, so they could also go into one mod. So are water and lava, I also think it would make more sense to have just 1 mod for both.

Wuzzy wrote: So are water and lava, I also think it would make more sense to have just 1 mod for both.

yep, and just title the folder "liquids"

Wuzzy makes sense... maybe easier to split the mods as the sections are split up in nodes.lua? i.e. "stone mod", "ores mod", and so on? And maybe add the ability to tick off each part in advanced settings, in the mods section. such as "copper ore" on or off, same for each other ore? which would remove all copper ore related code?
Might be as simple as adding code sort of like "IF copper ore off, THEN"... etc., etc.

Ore..... (<see what I did there? :D ) you could.... set, say "copper" and all copper aspects into one section of the ores mod.... including all the tools and weapons "copper" related... which would make even more sense than my comments above^.
Now, when a user goes into advanced settings, mods (and so on) they see options to tick off all copper related code completely... copper ore, copper block, tools, weapons, crafts, armor... as if it never even existed.
I have no idea why this would be desired or needed but..., I am just going off the main/basic idea you are working with.

I've done something, (sort of-ish) similar, but my approach has been to literally remove every aspect related to crafting/survival.
I'm not sure if things were split off this way, if it would have been easier for me to accomplish what I have so far or, more difficult to follow the trail.

One thing I wonder (or need to ask is) does this produce a longer loading time for you? I would think that if the engine needs to search through more material (meaning folders in this case) it would add to loading time? Just curious
And are you addressing how each new mod depends on one another? Meaning does this add the ability for each mod to be completely independent? And how much more added code is now required to tie them in together?
Because early on I noticed how tied in together so many aspects of MT are during my work. Especially related to crafting
If I remove this..., it affects that, and then after I make the changes to fix it there, now it affects part of another aspect.

And that is only within the default mods folder, not even mentioning the affect to outside mods. I have had to give up quite a lot of mods in my process, and actually needed to modify all of them to work with all of my changes. Some I still have not even gotten into yet (the more complex/intricate ones)

One thing I have come to not care for very much though, is a mod which carries hard dependencies of other mods, other than default. In my own opinion, every outside or "community" created mod should only have one hard dependency (being default) and all others should be soft dependencies.

I didn't notice any longer loading time. And there is absolutely no extra code. You just have to have an eye on the dependencies.

Most dependencies can be resolved, but it seams there are some dependencies I can't resolve because some stuff is hard coded in the C++ code (code quality? To much KISS?)

I split some things into extra mods by intention. I put in this mod everything related, e.g. in the bronze mod the registration for slabs and stairs and the ore registration in the mapgen, or in the lava mod the cooling ABM. Don't need lava in your game? Just remove the mod and it is gone, including the ABM. You don't want bronze? Remove bronze ore and bronze tools. Adding if .. then code to disable parts would make it complicated

I tied simpler nodes together like stone, cobble and so on. I have one mod for stone, sand, desert sand, obsidian...

The idea is, that it should be easy to remove or modify a part of the game, but still be able to update the rest of the mods. The problem of the default mod is, that it is a monolithic block. A simple change to one aspect effects the whole block.

It seams a bit exaggerated to make so many mods, but I want to make the exact opposite to default. It is no problem to tie some mods together later. Everything should still be compatible because every node is still related to default. I just add a : to the registration

In my own opinion, every outside or "community" created mod should only have one hard dependency (being default)

NO! A dependency on default implies a dependency on Minetest Game, and it is not always desired to mod Minetest Game.
It is certainly possible to create mod which do not depend on anything, not even default. Example: A mod which only adds chat commands.
When I need some stuff from default, I usually try to make this dependency optional. This is especially the case if it's just about crafting recipes. That way, my mods are very flexible and not strongly coupled with Minetest Game.

Only for mods which are directly tailored towards extending Minetest Game itself, I don't bother making this dependency optional, as the mod would not make much sense with any other subgame.

To be honest, what I do here is still Minetest Game, just split into multiple files. But it will be more flexible.

What I really want to do is to write everything from scratch, but this will break compatibility with a lot of mods

What is the common core for each game? The player and a map. Everything else is optional, even inventory and crafting.

What I would like to have is a core, a set of optional tools like crafting, and based on that a reference game similar to MTG. But the game should only a reference, not the whole base

Wuzzy wrote:

In my own opinion, every outside or "community" created mod should only have one hard dependency (being default)

NO! A dependency on default implies a dependency on Minetest Game, and it is not always desired to mod Minetest Game.
It is certainly possible to create mod which do not depend on anything, not even default. Example: A mod which only adds chat commands.
When I need some stuff from default, I usually try to make this dependency optional. This is especially the case if it's just about crafting recipes. That way, my mods are very flexible and not strongly coupled with Minetest Game.

Only for mods which are directly tailored towards extending Minetest Game itself, I don't bother making this dependency optional, as the mod would not make much sense with any other subgame.

Ohhh..., duh, now I get what you were saying earlier. Don't know why that didn't register in my brain when I made the statement regarding dependencies. So now I get your point and, while I agree...., I also... "disagree?" o_O (confusing I know) :P

I think this is only because having "default" as a dependency has become a deeply instilled mindset?

Default is currently a necessary dependency for any mod which intends to add new aspects to MT game-play, but only if it intends to add aspects which will rely upon the default textures, sounds, models, etc... or, if I want to create a whole new type of stone..., I want to take advantage of the "already provided" function of stairs, which is part of default...

I guess it does cause some dilemma at times. It's one of those "sometimes it's nice to be able to have default to set as a dependency (because it does remove the need for all that extra work), but at the same time, it can be a burden".
I think most add it mainly because it is one thing which is constantly commented..., as well as for functionality reasons.


I definitely like what you're doing burli..., it would definitely have (most likely) made my own task/goal easier but..., I also realize the way MT game default has been structured, is well, more or less the common approach for all or most games around as well as from a maintenance aspect.
When changes or fixes are implemented and pushed... makes it really nice to have that push go off into all the areas it needs to go rather than individuals needing to track/hunt down all the individual roads.
It is also convenient for trouble shooting.

Overall, have fun. This is a cool venture but I know from my own experimenting, it can get frustrating at times too ; )

And, I agree with you Wuzzy, as well as disagree with you :P this whole dependency topic has been a 50/50 damned if you do, damned if you don't throughout pretty much any and/or all projects throughout time.

It can be nice to be able to rely on, while it offers convenience, it can also add some restrictions/limitations.
But..., it's pretty cool that MT is open and we all have the ability (or at least option) to make all these changes we want on an individual basis : )
Similar to burli, a lot of changes I implement are in regards to aspects of the mapgen as well. I was even just recently looking over all the "australa-something" mapgen work bob zenz was doing a while back. But it's really heavy stuff

So burli, this is all very cool but, (I realize this is all experimental for now) it may be a real "w"itch to deal with later with updates? Lots of extra steps? Maybe not but... I'm definitely watching the progress because I find it interesting : )
But I ran into the very same problem with most all mods outside of default... because they rely so strictly on various functions built into default. Take frequent breaks :D

burli,

I've thought much the same, in that the various objects made available through default could be better organized. Case in point, stairs, slabs, walls, doors, and fences. All of these mods are part of default, and give you VERY basic options for each of the three. Only a couple of doors, wood, glass, and steel. What if I want a gold door, or a stone door? Write a new mod to essentially call code in default to register a new door type, that is then only available if this new mod is installed. In other words, write multiple lines of code to do what should have simply been added in the code for doors, walls, and fences, in the first place. Simply add ALL the other node types. Copy/paste. It's what I did to increase the types of walls available. So the only thing default does, is provide a basic rudimentary, Minecraft. This really lessens the value of Minetest, and I do believe, contributes heavily to the impression that Minetest is a Minecraft clone.

In my WIP building_elements mod, I have tried to standardize a shapes library, that gives players access to nodes of all shapes and sizes, ie, nodeboxes. These nodebox shapes can then be applied to any "material", such as stone, metals, wood, or glass. What I've come to discover, is that the lack of a consistent convention for defining things in default, is a HUGE problem.

Just as in the real world, where everything is based on the 120+ base elements found on the Periodic Table, the same concept should be used here in Minetest, providing materials from which to craft anything else, tools included. Due to the lack of any real "materials" support, outside of the groups that are defined for the tools, (cracky, oddly_breakable_by_hand), there is no way to determine the type of node that is registered.

Going back to the shapes concept, I had to essentially hard code stone, metals, wood, and glass, since those material types made the most sense for the shapes I provided. Metals aren't given a default group, complicating this process. Making columns out of Wool might be creative, and even look good, but a wool column cannot support a brick wall. In several of the buildings provided by Instabuild, Cottages, or the Villages mods/pack, sand is used as a wall. Dig out a hole, and you have to rebuild the wall, due to the falling sand.

A better system for handling node registration should be considered here. Some nodes are actual devices that can be used, while other nodes are simply materials. In this case, the material is provided a texture, sound(?), a name, and some basic groups. With better materials support, nodes could be more correctly defined. From this, things like doors, fences, and walls, or for that matter, ANY other shape, could then be applied to any node defined as a material. Imagine.... stone doors. Or bronze or copper, or any wood, tree, metal, stone, or what ever else gets defined. And I wouldn't have to (re)write any code, each shape is applied to each "material" node, thus giving users 'infinite' combinations.

With this thinking, I've managed to create stone and diamond doors, half height doors, shutters, better fence gates, fences that use a stone pillar and wood rails. They are in the building_elements mod. My goal for the mod is to, in fact, complete the transition into a library, and then begin work on better materials support. Both would then become part of a modpack.

However, in the bigger picture, a shapes lib, and a materials lib, would necessarily have to become incompatible with default, since so much of this concept essentially means a rewrite of all that constitutes what currently makes default.

I like the idea of using "Base" as a name, since what you are considering/proposing would make a better foundation for games and mods.

Instead of just a sandbox survival or creative game, what if we had real time strategy, using PvP or mobs. Something akin to AgeOfEmpires meets Civilization, with a touch of the trading system from Colonization, but in 3D/First-Person. This is very possible, would not be difficult to make, and would make a far more compelling game for the Minetest engine than the current MC-like Minetest_Game.

Let me know if/where I can help. I can code well and can provide unparalleled data and systems analysis, to work out the kinks.


Shad MOrdre

@ShadMOrdre: you are wrong with your door example. Doors is an extra mod. I think you don't need to depend on default if you want to add a door (but not 100% sure)

But what I criticize is that in this mod some doors are registered by default. This mod should only provide functions for register doors and whatever is needed. The registration itself should be done somewhere else.

Lets assume your subgame plays in a world without wood, but you still have wooden doors, wooden fencegates and so on. Maybe it doesn't matter because without wood you can't craft them, but they are there

Anyway, they are always there, if you want or not, and if you want to get rid of them you have to write extra code to overwrite the recipe. How stupid is that? TumeniNodes asked me if it takes more time to load with so much mods. This extra code definitely takes time. Time to code, time to load, time to maintain...

Edit: @TumeniNodes: same with stairs. It is an extra mod, but a lot of nodes are registered by default, if you want them or not

burli wrote: TumeniNodes asked me if it takes more time to load with so much mods. This extra code definitely takes time. Time to code, time to load, time to maintain...

Edit: @TumeniNodes: same with stairs. It is an extra mod, but a lot of nodes are registered by default, if you want them or not

I definitely get what your reasoning and goals are, and I like it.

In my work I have removed, as I have said, any crafting functions and aspects. I have also removed 2 types of trees, and I am down to basically just grasslands nodes. dirt, clay, grass, gravel, stone, sand, and sandstone, and tree types and some plants,etc.
Although I have been thinking of splitting trees off, not sure yet. Seems to make more sense to keep them in the "nature" or core mod

I like to keep default/base/core nodes to specifically natural materials for the world, then "manufactured" materials are in another mod/directory such as bricks, cobblestone..., and then those each have their own items such as stairs, walls, and so on.
Glass and doors are in their own mod.

I know someone was commenting about you making a sep mod for each ore as possibly being overkill but, I see your reasoning..., since you group literally all aspects and functions per ore, they do almost naturally create a mod of their own.. (using copper again as the reference)

Copper includes copper ore, copper lump, copper block, copper tools, armor, underwear... wait..., what? o_O ... and whatever else is related to copper in-game as well as in map generation.
So, yours is a pretty cool concept, and just differs from how things have been previously categorized and then grouped. And will be cool to see the end result

TumeniNodes wrote: I know someone was commenting about you making a sep mod for each ore as possibly being overkill but, I see your reasoning..., since you group literally all aspects and functions per ore, they do almost naturally create a mod of their own.. (using copper again as the reference)

Copper includes copper ore, copper lump, copper block, copper tools, armor, underwear... wait..., what? o_O ... and whatever else is related to copper in-game as well as in map generation.
So, yours is a pretty cool concept, and just differs from how things have been previously categorized and then grouped.

That's exactly what I want to do.

default:iron_lump is defined in craftitems.lua, the cooking recipe for default:steel_ingot is defined in crafting.lua, the default:steel_ingot craft item is registered again in craftitems.lua, default:stone_with_iron and default:steelblock and defined in nodes.lua, the steel stairs and slabs are defined in stairs.lua, the steel door is registered in doors.lua, the iron_ore is registered in mapgen.lua and, what's a little bit ridiculous, the register_sing function has no extra mod. It is just a local function in nodes.lua and if you want to add a new sign you have to put it in nodes.lua itself.

so if you want to remove iron/steel from your game you have to edit minimum 6 files, which is, again, ridiculous. If you want to update minetest game to a newer version you are totally scewed

But, if you put everything iron/steel related in one mod (yes, including register_ore. Tested it yesterday and works fine) you just have to remove one file and everything is gone and you still can update the rest without a headache. Or you can edit the iron mod and add/remove whatever you want without touching all the other files. Or you can replace the iron mod with an other version

^ hehe... eyup.

And, as I'm sure you probably already know.... if you throw "technics" mod (as an outside mod) into that equation.... the mess is massively multiplied :P And technics is a really large and complex mod to get into if you want to recode it :P

This could be automated. I have been trying out a crafting mod that automatically finds out how things are made. So it must go through the mods, find out what makes them. Extending the concept a programmer might write code that does that and also locates the code for each mod then separates what can be separated. Mods that shared code or that depended on other mods could be separated with a dependency condition, much like a package manager handled dependencies.

After that you could turn the mods directory into a package managed area and use localized rpm or dpkg databases to manage it. Getting it set up would be some work, but after that it would be a dream for noobs to put mods in and take them out. Any volunteers want to do all this work?

It will take some time until I can show something showable. Currently I try to move the trees into mods and after that I want to add a new tree by just add a new mod.

I don't want to add any kind of complicated automation. I just want to organize the existing code more logically

Sorry! I get carried away.

lightseer wrote:Sorry! I get carried away.

I'm sorry, I had to read your post again to understand what you mean (I'm not a native english).

I think I don't have the time for such a project

Good to see you working on a minimal mod base, we have often asked for extra subgames to release with Minetest and this is the sort of thing we are looking for.
'Minimal' isn't a mod base and is unsuitable for that.

I want to discuss how I should handle trees and tree nodes. Originally I want to put trees and their nodes (planks, leaves, wood...) together in one mod. But then I found a recipe



That wood (joke) mean I had to put default:wood into its own mod. Also default:tree and default:leaves might be used from other mods.

So I think I'll put nodes like saplings and apples into the appletree mod and nodes like wood, tree and leaves into theire own mod

https://github.com/MarkuBu/minetest_gam ... e/init.lua
https://github.com/MarkuBu/minetest_gam ... s/init.lua

Then other mods can depend on these nodes without trees

What do you think?

I moved all trees into mods. Hopefully I didn't messed up something, but everything grows fine. trees.lua is now useless. Any common tree function moved to the tree mod, any tree specific function is in the associated mod

https://github.com/MarkuBu/minetest_game/tree/mod_base

These trees are grown by saplings



Next I will move the keys to a mod, then tools.lua is empty too and can be removed

Nice.

I think it's pretty cool we seem to have been working on the same path, just with different goals in mind : )

If you read back and also pay attention to what Wuzzy mentioned regarding the player.
My thoughts, (just a suggestion) are that when you do finally get to the player aspects, and split that into it's own mod, it would be cool to be able to get "the hand" out of hard-code completely and into that mod, and possibly all aspects of hud,, the hotbar,etc., etc. should be included in single "player" mod. If any of that makes sense to you?

I already hat the wieldhand in a mod, but then I made a mistake and couldn't find the reason, so a step back to a previous version

I don't know if it makes sense to put hud and hotbar in the player mod or make them in separate mods. I have to look at the code

Just for fun: add palm trees

burli wrote:Just for fun: add palm trees

Very cool, I like the other trees you just posted last night too. (with the high roots)

hmmm, coconut trees and coconuts coming next? :P

They already have coconuts ;-). The other trees are the default trees from MTG

This was just to test my assumption that trees can be added this way. These are schematics from ethereal

tools.lua removed and schematics folder is empty.

I still don't know what I should do with mods like doors, stairs and so on. Based on the paradigm of the modbase node registrations should be separated from other code

ShadMOrdre wrote: What I've come to discover, is that the lack of a consistent convention for defining things in default, is a HUGE problem.

Sounds interesting what you said. What kind of convention would you expect?