FOSS gamedev and creative worlds

So, we have all these different great mobs mods, but F is based upon B, which originally was based upon A, so both contains the same "sheep", "cow" and "foo" mobs, yet several times modified.

Then we have some mobs mod packs with the same problem as both mod pack A and B contains 7 different mobs, but 2 similar making these packs conflict with each other.

I have been looking into creating a completely new mod pack, based upon what ever works, but in isolated form.

Some mobs are easy to isolate, but others such as "tenplus1" great new "mobs" mod has one single HUGE api.lua for all the mobs in his mod pack. Pulling things apart seems to cumbersome as it lacks commenting.

We need to start isolating mobs from each other so there is one "sheep" mod, or several - as long as they are separated it doesn't matter, and one "cow" mod, etc.

So we can have "sheep foo" mod and "sheep bar" mod if we have two different sheep mods.

If we separate mobs no conflicts exists and it is easy for everyone to put together the mobs they want.

Or perhaps some kind of "mod package" system.

I agree. That is why all my mobs are independent from one another so you can mix and match and there is no conflicting issues. Sometimes all I want is a good monster mob and a sheep for survival.

Having a single mob api keeps the size of additional mobs mods to a minimum not having to include their own api each time, also it is a LOT easier to spot and fix bugs instead of going through each mod if one ever does conflict with the other, and new features and improvements are spread across each mob using the api...

Each mob in Mobs Redo can easily be disabled by commenting out the appropriate line in the init.lua file...

TenPlus1 wrote:...

Each mob in Mobs Redo can easily be disabled by commenting out the appropriate line in the init.lua file...

commenting out some lines in some code file is not user friendly and easy!

you have to locate the init.lua for a start. Hopefully you have manually installed the mod yourself so that you might know where to search for the mods folder. If the mobs are part of a game you will have to search in another place. If you downloaded via the builtin modstore (if that feature should indeed work again) you will have no idea where the mod files whent. Knowing where the valid mods folder is seems to be indeed a basic problem for many "player only" users.

Next you will have to open a *.lua file. If you live on a mobile device initially designed to communicate you might notice that things like a file manager and ascii editor are not the stuff you use every day.

Once you have the file open you need to identify the lines in question. Remember you have no idea of coding so this might not be as trivial as it may seem to someone who has seen code before.

"Commenting out" ?
What's that? Ah putting some character in front of the line so that it is ignored. What if the line breaks in my window?
Uhm, what characters do this? Is there a common standard?, Nope each coding language may use different methods in different ways.

So just for deactivating some bad guys, I, as a casual player on some cheap small screen mobile phone with touchscreen items a lot smaller than my fingers, am forced to learn a lot more about coding than I ever wanted to.

Easy for the user would be some GUI with some funny mugshots of each mob as icon that I could just punch to activate or deactivate.
But then again that would not be quite so trivial for the coder to provide.

twoelk: this was aimed mainly at mod developers, not players... although some kind of gui to enable/disable mobs would be handy...

I wish mods were more modular. Mods like Simple Mobs should be in a mod pack structure, sharing a common API library. (You can call a modpack [Mod] if the mods are similar, rather than [ModPack]).

That could be a good idea although certain mobs carry specific items which would be important to other mods so a few dependancies would have to be changed and re-used models copied over causing duplicates...

You can use aliases for the specific items, but doesn't solve dependency.

true... it would get weird though if hunger mod has to check for mobs and having mobs_pig to register porkchops... I'd like to keep the default SET enabled for simplicity...

It could be a little problematic that there are multiple different backends. There are, at least:
simple mobs by Pilzadam (+some forks that don't change the api much)
mobs redo by TenPlus1
creatures by BlockMen
creatures by MirceaKitsune
... (probably some more)

The difficulty isn't the amount of backends, but the different API. That way, these aren't interchangeable. Maybe this could be solved by adding a middleware that communicates with the backends and the individual mobs?

I've re-worked the Mobs Redo mod to be more modular so players can easily enable/disable any of the mobs inside... Make sure the actual 'mobs' mod is enabled though in the pack otherwise nothing will work :)

viewtopic.php?f=11&t=9917&p=178778#p178778

TenPlus1 wrote:Having a single mob api keeps the size of additional mobs mods to a minimum not having to include their own api each time, also it is a LOT easier to spot and fix bugs instead of going through each mod if one ever does conflict with the other, and new features and improvements are spread across each mob using the api...

What you're talking about is strictly speaking not an API but a library. The API is the interface a program/mod offers to the outside, with function names and parameters, but without regard to the actual implementation. The doc/lua_api.txt file describes the lua API Minetest itshelf provides. The mobs api would look something like this:

Local functions are not part of the api. Each function has to be described (what does it do? what does it return?). Each parameter passed has to be described in a similar way. But apart from the documentation (which is essential to an api), the list of functions above ought to be the complete api of the mobs(redo) mod.

The actual implementation of these functions is independent from the api and happens in what we usually call a library. They're just not very popular amongst Minetest modders, those libraries, because mods need to depend on them - making installation slightly more difficult for players and creating the fear that players may shy away from installing the mod because they've got to install something else first.

The reason why there are libraries in a programming environment is precisely what you stated above - there are no longer thousands of copies in 10000 of versions lying around, but only a single library, which can be updated, improved and changed wihtout regard to the programs (in our case: mods) using it - provided the api stays the same.

There are other functions I'd love to see beeing added to Minetest as libraries - we even talked about a possible "standard library" which could be shipped with Minetest. Such functions as save/restore a lua table in the world folder are what my own mods definitely need as a library instead of copies in each mod. The implementation (=actual working programming code) of the mobs mod, in this case api.lua (which, despite its name, contains what ought to be called a library), ought to be part of such a standard library.

However, I'm afraid the mobs' implementation is not ready for inclusion in a standard library yet. The main function of the mobs library - register_mob - is almost a thousand lines long. To make it worse, most of it is just a call to another function, with a list of parameters that spawns those almost thousand lines. That needs to be broken up into smaller functions that do just one job and which would have the additional benefit (if not beeing local but beeing part of the api) that other mods might change part of the behaviour of a mob without having to be a complete copy of the identical rest.

twoelk wrote:Easy for the user would be some GUI with some funny mugshots of each mob as icon that I could just punch to activate or deactivate.
But then again that would not be quite so trivial for the coder to provide.

Sapiers mobf has such an interface. It's more suitable to programmers and server maintainers than inexperienced tablet users. A nice gui that allows to selectively en- or disable installed mobs the way you describe it would be something that could reside well withhin the mobs library itshelf. The major problem I see here is to create a nice, convenient formspec - and to get tiny(!) screenshots showing each mob. Other than that, mobs like skins mod or just about any craft guide out there achieve more or less the same with formspecs.

TeTpaAka wrote:It could be a little problematic that there are multiple different backends. There are, at least:
simple mobs by Pilzadam (+some forks that don't change the api much)
mobs redo by TenPlus1
creatures by BlockMen
creatures by MirceaKitsune
... (probably some more)

There's Sapiers animals modpack, and there's npcf, peaceful_ncp...and probably others I forgot.

TePpaAka wrote:The difficulty isn't the amount of backends, but the different API. That way, these aren't interchangeable. Maybe this could be solved by adding a middleware that communicates with the backends and the individual mobs?

Simple mobs by PilzAdam is what TenPlus1's mobs_redo is derived from. Creating a common api for both might be possible. BlockMen's approach is a diffrent implementation with a completely diffrent api. It might be possible to re-use models and textures, but that'd be about it I think. MirceaKitsunes mobs seem diffrent again. And then there's Sapiers mobs - which require models to be rotated by 270 degree. But you're right - a common mobs api would be highly welcome! Each mod author/creator of a model could provide an interface for his mod that'd just have to work together with the common mobs api - which would at least allow re-usage of models and textures.

TenPlus1 wrote:I've re-worked the Mobs Redo mod to be more modular so players can easily enable/disable any of the mobs inside... Make sure the actual 'mobs' mod is enabled though in the pack otherwise nothing will work :)

Creating a library goes one step further. What you did was to split your mod up into a modpack with individual mods which can now be selectively installed an deinstalled using the functions Minetest provides for mod installation/activation/deactivation. That's not bad as such - Mesecons takes the same approach. But it may still not be the best choice. The list of mods installed gets very long that way and is more difficult to check.

It would be great if there could be such a common mod api and library as part of a standard library for Minetest.

By now Minetest does indeed have a fair amount of mob mods as this list on the wiki may show (please add to the list if you know any more mods. Not included yet are games that include mods not yet published as standalone mods.)

Casimir did extract a mobapi based on PilzAdam's Simple Mobs. So all that needs to be done is extend that api with any new features added by any mods based on "mobs". As far as I understand the mobs based on Simple Mobs would include:

• Mob Spawn Eggs [spawneggs]
• KPGMobs (was new mobs) [kpgmobs]
• Mobsplus and Edited Areas (modpack) [mobsplusareas-mp]
• Mobs Redo [0.3] [mobs]
• SimpleMobs++ [mobs]
• Carbone Mobs] [mobs]
• Senderman [senderman]
• Soldiermob [soldiermob]
• Spidermob (lottmobs extracted) [spidermob]
• CUTE CUBIC MOBS [ccmobs]
• Critters [critters]
• Creatures (mob framework) [minetest_mods_creatures]

Creatures(mob-framework) may be a little difficult but the others should be possible. There probably are more but if these could be organised in some "Unified-Simple-Mobs-API-with-Mobs" things could be easier to develop further. For one a lot of redundance could be saved by merging all those mobs. We must be carefull though to not loose the variety we have for example in the "breeds" of sheep.

As the wiki page shows there are a lot more mob mods out there but combining these might be a start. The next step would be to get the mobapi somehow included in mt-game or maybe later even into the engine, maybe first as lua in builtin or whatever and later on ...

maybe step by step is more realistic than the one big solving all problems at once solution

twoelk wrote:So all that needs to be done is extend that api with any new features added by any mods based on "mobs".

That's the *implementation* that would be changed and extended; not necessarily the *api*!

twoelk wrote:The next step would be to get the mobapi somehow included in mt-game or maybe later even into the engine, maybe first as lua in builtin or whatever and later on ...

I'm afraid the actual implementation does need more work. The API ought to be extended so that other mob mods can change the behaviour of mobs as well if they wish to. That overlong on_step function needs to be broken down, and callbacks for all functions added.

twoelk wrote:maybe step by step is more realistic than the one big solving all problems at once solution

That's certainly a good solution. And you did the first step by identifying candidates for the merge.

The second step is the API itshelf - the names of functions and their parameters. Take one implementation (i.e. Casimirs), write down its API (like I did for TenPlus1' implementation), and check if there are any differences. Chances are high that all these mobs already more or less share the same API - after all they started as forks of the same mod. The namespace may differ (mobs.*, mobapi.*, carbone_mobs.*, spidermob.*, ..). Those diffrent namespaces are no big problem for this simple API as they can be handled by find&replace or by wrapper functions. Mod creators may have added new functions - that needs to be written down as well so that the API may include these functions. Changed parameters may require a closer look at the actual implementation. The result of this step of comparison and merging ought to be the API itshelf, plus perhaps wrapper functions so that existing mob mods can use the new functions instead of their own. It may get a bit tricky because the most significant parameter for the most important function is a table which contains the actual parameters. Checking that the API gets reasonable defaults may already be part of the next step.

Next comes the implementation. It varies from fork to fork, although the core may have remained the same. It'll be work to compare all those implementations in order to see what was changed and to get it back together into one single implementation.

Step four is to improve the implementation. Break up that overlong function, add callbacks etc. - in short: make it ready so that we're not killed on sight by the devs when proposing to include it in a new standard library :-)

Btw, the creatures mod has a very nice api.txt file.

Yes, this work is badly needed. We have currently a very chaotic jungle of mob mods. I know from experience (while working on the Weird subgame) that you can't just combine multiple mob mods (from the mods we have now) for several reasons:

• 1000 duplicated yet incompatible APIs
• 1000 duplicated mobs
• Poorer performance
• Complete disregard for compability (I have seen mob mods which don't even bother to change the name of the main table, meaning that it will happily override the main table of another mod and thus wiping it out)
• The shortname “[mobs]” is used over and over again. Seriously, WTF? Aren't these shortnames supposed to be unique? Also, this means you can't even safely install (not neccessarily activate them in the same world) multiple of these mods together. Grrrrrrrrrrr …

Casimir's Mob API (that's the name) is a nice start, and I already used it, but it lacks features. It really needs more love and most importantly: Documentation. Another crucial point where many mods lack behind. Oh, and there should be more mods which use this mod, the only mods I know which use this mod are written by me for Weird.

The suggestion of providing one mob per mod is interesting, but I fear this may make balancing between the mobs a bit tricky.
On the other hand, this little problem could be easily solved by modpacks, so you can safely group multiple mobs together yet still don't force people to use the full package.

I'm constantly adding features to the Mobs Redo api in the hope that mod developers will use it for adding their own mobs and have a modular version available to enable/disable mobs inside and to make adding your own a lot easier:

viewtopic.php?f=11&t=9917&start=275#p178778

TenPlus1 wrote:I'm constantly adding features to the Mobs Redo api in the hope that mod developers will use it for adding their own mobs and have a modular version available to enable/disable mobs inside and to make adding your own a lot easier:

viewtopic.php?f=11&t=9917&start=275#p178778

I think using TenPlus1's api as a default library we all use and extend together could be a great solution!

He already, as I understood after he explained it, has done a lot to easily enable/disable the different mobs.

Could it not be possible for the Minetest devs to maybe adopt this api as the standard for mobs? We can all then start by improving and adding new features to the same api. Like we have the "minetest_game" so we could have TenPlus1 as the default when people wants mobs.

Anyway, that could be a nice solution in that it will gather people together around a single unified solution.

I stongly object to adopot TenPlus1's mod (in it's current state) as a default mod, intended to serve as some kind of “standard”.

Mobs Redo is not quite ready to be promoted to “standard” status anyways.

Mobs Redo 1.12 is currently distributed as two incompatible versions: One single mob blob and a modpack. This kind of distribution is not good IMO.

Also, just the API mod carries along useless cruft, it registers a few items.
And the API mod is not generic enough to be really useful as a standard. It forces blood particles for every mob. This is just stupid. Hell, it does not even make sense together with the mod's default monsters.
Atnd all mobs attack and get hurt with ONLY the “fleshy” group. There is only one kind of damage. Thus, Mobs Redo wastes a lot of potential by not adapting/allowing for a more complex damage system for your own mods.

And Mobs Redo is not the only mob mod, so it needs to be carefully compared against other mods. Especially Mob Framework, because it is very different (I don't know much about it, however).

Wuzzy, you have to start checking your facts before spouting them in the forum...

• Blood can be disabled by setting the "mobs_enable_blood" flag in minetest.conf file.
• Default meat and magic lasso items are registered by default which is not "useless cruft".
• Attack settings for each mob/monster can be tweaked in the mod code if someone wishes to make them more powerful or immune to hand attack.
• The api is suppose to be a fast mob system with many features available for use, not a fully fledged A.I. to have them make breakfast for you...

This thread has been sidetracked.This isn't a Mobs Redo advertisement thread, or at least it shouldn't be.

I actually strongly agree with with greencopper, the original poster, that mobs should be entirely separate from one another. Without sharing any form of mod api.

The arguments in favor of a unified api are not particularly compelling.

bdjnk wrote:The arguments in favor of a unified api are not particularly compelling.

advantages:

• less code repetition.
• smaller mods.
• easier to update shared code, rather than having to update all the mobs mod.

disadvantages:

• api may not have the behaviour you want (not a problem if the API is extendible)
• one more mod to install

Agreed... Am working on adding external mob routines to the api so it can be extended for specific tasks...

Update: 'do_custom' function has been added when registering a mob which runs every second mob is active, this allows for custom code to be run inside mob api.

rubenwardy wrote:

bdjnk wrote:The arguments in favor of a unified api are not particularly compelling.

advantages:

• less code repetition.
• smaller mods.
• easier to update shared code, rather than having to update all the mobs mod.

disadvantages:

• api may not have the behaviour you want (not a problem if the API is extendible)
• one more mod to install

Regarding size, a thousand characters is one kilobyte, so this is irrelevant. As is the one more mod to install.

Less code repetition and easier to update are tied in together. This is the idea of DRY coding. Unfortunately, this is dominated by the remaining two disadvantages.

When you mention the possibility of the api not being what you want, I would contend that's the more common scenario, and is always true to some degree. The notion of making the api extendible sounds nice, but as a practical matter, seems untenable.

The last problem is the one that started this thread. It might be ameliorated by a required api mod, but it certainly wouldn't be solved.

What is truly needed is improved mob related functionality in the modding api itself.

Smaller mods are easier to maintain and are less likely to have bugs. I wasn't talking about file size, really.

Reinventing the wheel isn't good.

TenPlus1 wrote:Blood can be disabled by setting the "mobs_enable_blood" flag in minetest.conf file.

That was not my point. My point was that only one particle type is supported. From a mod which claims to be “generic” I would not expect this.

Default meat and magic lasso items are registered by default which is not "useless cruft"

It still does not belong into a pure API which claims to be “generic”. Even less so if Mobs Redo is to become a standard. There are certainly use cases where an user of the API does not want any of those items. And for those users, those items are, in fact, useless cruft. I already suggested to move these items into a seperate mod.

Attack settings for each mob/monster can be tweaked in the mod code if someone wishes to make them more powerful or immune to hand attack.

“tweak in the mod code” sounds like an euphemism for “forking”. As if we don't have enough forks (and forks of forks) of Simple Mods already. ;-)
Also, you are missing my point completely. All this mod knows appears to be “damage”. The groups of the target are not checked, only “fleshy” is used. Likewise, all mobs are “fleshy”. It looks like that “fleshy” is mostly an artifact of Minetest Game. This is not generic at all. From a generic mob API I would not expect to limit itself to a single group, which is hardcoded to be “fleshy”, but rather than to be open about groups, so that mobs could deal damage to different groups and mobs could belong to different groups when attacks. That's what I meant “a lot of potential is wasted”.

The api is suppose to be a fast mob system with many features available for use, not a fully fledged A.I. to have them make breakfast for you...

Then why exactly do you advertise for your mod here? You just admitted that your mod can not fit everyone's use cases. But if this is the case, you just lost your best argument for why Mods Redo (in its current stage, at least) should be included as The One True Standard Mob API into Minetest.
In fact, maybe we'll never find any mod which could create The One True Standard Mob API for Minetest, because there are simply so many use cases.


Mobs Redo is already fine to use as a player—as long as you don't install and use ANY other of the Simple Mobs forks or even Mob Framework (things are likely to go “Boom!”). But for a generic API, even a standard? Certainly Mobs Redo is simply not ready for stuff like that.

I would be glad to see that Mobs Redo would become truly generic and modular, not just like any other Simple Mobs forks.

* sips coffee *

blood_texture = "insert_texture_here.png", -- if not stated then mobs_blood.png is used

The mob api could integrated in the default, so not every mpd has to bring the api with it.
This would be an idea for the new minetest 0.5

Related: https://github.com/minetest/minetest/issues/2291

that issue doesnt look like it has been touched in a few months. Is anything coming of it?

Wuzzy wrote:I would be glad to see that Mobs Redo would become truly generic and modular, not just like any other Simple Mobs forks.

To a degree. It's still based on "simple mobs" and ought to remain that way. If you really want modular and well-designed, go for Sapiers mobf. The reason why Mobs Redo is of particular intrest is because it's one of the forks of simple mobs, which is in turn used by quite a lot of mob mods, and in addition provides support for a large group of mobs on its own. The mod also works quite well on servers and is relatively easy to use by modders.

What we want (well, I at least) is to get rid of these thousands of forks of mods which more or less do the same and which are a nightmare to maintain and get a basic mobs mod (perhaps without any actual mobs) added to minetest_game. Whenever someone comes up with a nice new model and wants to do a mob, that modder ought to be able to create that mob without having to worry how the mob API is implemented - just using it ought to be enough. For now, this will not cover all mob mods as most are too diffrent internally (mobf can do a lot more but does require models to be rotated by 270 degrees). Players who wish for diffrent behaviour of their mobs might use a diffrent implementation of the mobs API.

Weather or not Mobs Redo covers all that a mob can ever require is of no particular intrest for now. What's far more crucial right now is to figure out how diffrent all those unintentional forks of simple mobs are, and then to create an API based on that. Afterwards, the implementation can and ought to be improved.