It uses core.set_player_privs. This means it erases all other privileges if a player on one of the lists joins. (Technically this is just a bug, but it is a critical one.)
Everything is hardcoded, as the description implies:
Player names are hardcoded (and to valid names, which is a problem waiting to happen; someone installs this mod and suddenly players named Name1 and Name2 have excessive privs)
A few "rank" tables are hardcoded (owners, admins, builders, players)
The highly server-specific set of privileges assigned to members of each rank is hardcoded
It suffers from unnecessary code duplication
I think this mod is probably not general purpose enough to be very useful for others. So far it seems pretty much strictly inferior to /grant to me (note that privileges should be persisted if there isn't a mod like this one breaking them).
That said I'm not sure why you're giving a neutral review based solely on the name...
I think people forget that (1) issue trackers and (2) threads exist for minor things like this, a neutral review is not the appropriate tool to use here.
I would suggest converting this review into a thread.
Personally I perceived the atmosphere more as "weird" than "creepy"; it didn't occur to me to interpret the "writing on the walls" as blood for example.
Have you considered a friendlier reskin? It should be pretty easy to make something like a texture pack (or a mod which only overrides media including sounds, maybe a few story elements) to make this a game suitable for a broader range of peeps (though I don't know whether children would have the patience for some of the levels ;)).
A fun twist on the "stealth" genre: Not only are there evil eyes which must not see you; most of the time the challenge is to stay within the field of view of at least one good eye: "The Unseen are lost!"
The game further gains a bit of a puzzle game note by having buttons you have to press to make new paths accessible. These can be hard to find at times, but it is never wrong to press them. Hence the winning strategy essentially is to scour the levels for buttons, pressing all of them (and memorizing their positions and a sensible order to press them in for future attempts in case you fail), though this is in practice much harder to do than it sounds. Some buttons are definitely deviously placed :)
The graphics, music, and overall atmosphere are all consistent and nicely done.
Thanks for the clarification. In light of it, please let me apologize for insinuating that you were being mean towards the mod author. (I believe I owe you an explanation: I simply had not seen a direct connection between your review and this mod initially. It seemed to me as if you were not reviewing their mod specifically, but rather voicing generic criticism not specific to this mod.)
Given this clarification, ContentDB staff might want to reconsider whether this would qualify as a review.
There is no mechanism in this repository to limit proliferation of such mods
How ContentDB deals with library mods is a ContentDB problem, not a problem of this mod; and ContentDB has a tag for library mods ("API / Library").
It's bad enough that users get creatura, mobs_redo, etc. installed when they choose a mob related package
Is it though? If everything goes smoothly, I don't see any issues here. And I don't see a solid suggestion for how to handle library mods instead coming from you either.
How should a user know why they need logging, super_logging, logging_47, and logging_fork packages.
Easy: Because a mod they use depends on them. Note also that our users aren't just players, but also e.g. admins or other developers.
This gives bad user experience. Please don't do this.
Please don't do what you did here: Write a review which is not at all about the actual "content" of this library mod - the actual APIs implemented - but rather about the meta-topic of "how do we want to deal with library mods".
I frankly think you're being mean and unfair towards the author of this mod.
You have no substantial criticism relevant to what this package is about, yet gave this package a negative review.
PS: if someone thinks this is a great mod, write a positive review. Please do!
I will not write a positive review of a library mod I haven't used and potentially will not use just to balance out your unfair negative review.
unlike e.g. the unicode_text mod this package doesn't provide any value directly to the user of minetest, but only to the development of other mods.
This statement is false. Any library mod, including unicode text, only provides value to modders, who then use that value to create value for players. Some contributions may be more direct, but better logging may certainly benefit end users, especially as they get more technical (which does not just mean developers; there are also admins and moderators).
Such content does not belong as a separate entity (aka binary dependency) into this user facing repository.
(I still don't get why you're calling this "binary" when it's plaintext source code. That's a very confusing, fearmongering way to use the word "binary" for sure - as if this was some intransparent binary blob rather than a small piece of Lua any interested tinkerer can easily poke.)
This is where you go plain wrong. ContentDB is explicitly also a place for such dependencies, whether you like that or not. Quoting the package inclusion policy:
Adding non-player facing mods, such as libraries and server tools, is perfectly fine and encouraged. ContentDB isn't just for player-facing things, and adding libraries allows them to be installed when a mod depends on it.
In other words, you're negatively reviewing a package for doing something encouraged by the package inclusion policy.
I can only agree with the other reviewer(s): This is by far the best chess implementation in Minetest to date. It's nicely usable; you get a 3d view of the board. The engine works and actually picks decent moves.
Now, that's where the unexpected part comes in: Random "events" can completely change the course of the game. Strategies that work against the engine in "normal" chess don't work anymore. Beating the engine at "normal" chess is doable, but the "unexpected" version will give you a much harder time. It can be pretty frustrating if you worked hard on getting your pawns into good positions and suddenly they all just evaporate :P
Suggestions: Highlight the last move / action somehow (maybe using particle effects?). Otherwise it is at times hard to see what just happened.
Also, please give the player a moment to review a checkmate.
Huh, that's odd. Could you maybe detail your experience?
I found the game to be pretty straightforward: When you spawn, there's basically only one way you can go. As you walk this way, the story is presented to you through the dialogue between you and the light orb: You have to collect light crystals while fighting off "shadowspawns". For that you have to go through the portals.
The ending (the boss you have to fight) fits "unexpected" quite well, I'd say.
I like this demonstration of just how much Minetest can be abused, but there isn't really anything to do; all the "games" become pretty boring pretty fast.
Took me ~20 minutes to play this through, I like the mechanics. The "health powder" feels like a bit of a cheat - I had plenty of it when I went into the boss fight.
Good to know! but wait... you just said only 6.0 may break compatibility...
Yes, just like 5.0 broke compatibility in 2019. These breaking releases are rare though.
so does this mean I am in danger? in some eventual point in time?
I wouldn't say you are "in danger". Minetest likely won't have a breaking release for a while; the next scheduled release is 5.9. But there will eventually be a breaking release, and it is possible that some mods that aren't updated will not work with the newer Minetest engine then.
is there ANYTHING I can do to stop my engine from updating?
Yes: Don't update. Minetest doesn't update itself. If your package manager installs breaking updates automatically, configure your package manager properly.
it has instilled in me that mods sometimes usually break when you move up to the latest version(if the modder never updated their mod)
In an ideal world, they should not. However neither Minetest Engine nor modders are perfect. There are three reasons that mods do break:
Modders often rely on undocumented engine implementation details that aren't guaranteed to not change, which eventually change, accidentally or deliberately.
Core devs may accidentally break backwards compatibility.
Core devs may deliberately break backwards compatibility in "minor" ways if they are reasonably certain that (1) (most) mods don't rely on a certain (possibly documented) behavior (2) it provides significant benefit to do so.
But nevertheless, for the most part, the Minetest Engine has a good track record of keeping backwards compatibility. I don't know whether caverealms or Minetest is to blame in this specific instance. I would recommend reporting the issue.
if I were to get myself a fresh copy of the minetest game from 5.1.1 and put it into the game folder of the current engine... would it run?
It should. Since version 5.0, the Minetest Engine tries to follow semantic versioning. This means that "minor" releases like 5.8 are backwards compatible with other "minor" releases like 5.1. So if a game or mod works on 5.1, it should also work on 5.2, 5.3, ..., 5.8, 5.9 etc. Only 6.0 may break compatibility.
Hence Minetest Game 5.1.1 should work in Minetest Engine 5.8 just fine. Of course, you'll miss out on the bugfixes later Minetest Game versions bring.
Minetest Game strives to follow semantic versioning and be backwards compatible just as well, so if mods work with MTG 5.1, they should continue to work with MTG 5.2, 5.3, etc.
First off: On ContentDB, please open threads (rather than making neutral reviews) for questions.
I've been having a good time so far with this, except for the latest update that happened and just got forced down my throat. see, I just recently rolled in from my old version of minetest that was a version 5.1.1 that was on my old windows 7 pc. I have since, migrated to the latest version on Android(playing on a tablet). took me a while to get my bearings straight, but have adjusted relatively well.
All of this seems to concern the Minetest Engine rather than Minetest Game?
I MUST know if this means some out of date mods will stop working
They should not: Minetest 5.8 is a minor release. It should not be breaking compatibility.
will things start to break, if I DON'T update the main minetest game?
No.
NOT all content and mods are kept to date... so I must know if I'm in any danger.
You should not be. (There is always a small risk of modders relying on engine internals however.)
I noticed doors open with one tap now instead of two
This is an engine change. It is unrelated to Minetest Game.
It's not me who wants to waste your time reviewing my mod.
The time spent on mod reviews is not "wasted"; it is necessary to nip some issues in the bud before they arise, and it worked well here: Without the review, you would have released the mod under a name that was already in use.
There have also been plenty of other mods with issues that got caught in review. It is especially useful to try to catch copyright (and other legal) issues before there is a formal complaint.
Either way, I don't think the review system is up for debate.
You're still not finished after 17 hours now and referring to the review queue.
You're being very impatient. Waiting a few days for your mod to be reviewed is normal.
Thanks for the review! What exactly is nerdpoling (is it what I know as "pillaring"?), and what would you suggest to "stop it"? I wrote this as a means of (among other things) slowing down pillaring, since fast pillaring typically requires you to place blocks colliding with you. A block placement quota might additionally be useful to slow down pillaring. An alternative option to consider is something like structural integrity checking, where pillars past a certain height would degrade to piles (blocks would fall left and right).
This is likely to be out of scope. character_anim tries to be as game-agnostic as possible by only expecting a few standard bones the Minetest Game default player model (character.b3d) typically provides: Body, head and right arm. I don't plan to add custom models. I could add support for more advanced model conventions, but that would complicate the code and probably only serve a single game (Mineclone) which provides such a model (and already has its own provisions for animations).
You can use visible_wielditem.item_tweaks.names["default:torch"] to change that. I could add better default settings for MTG items, but I feel that would bloat the scope of this project - there probably are plenty of items in plenty of games that could use special tweaks...
Thanks for the report. This was a character_anim bug I never noticed because as soon as player_api changes the animation - as soon as you move, punch, rightclick, lay, use a boat, whatever - an animation would have been set; this bug was only noticeable if you actually immediately changed into third-person view before doing anything. The fix was trivial; I just had to preserve the initial animation.
Minetest Game being bundled by default is an engine issue rather than a game issue. This renders your review irrelevant for the Minetest Game ContentDB package.
I have recently bumped the modlib dependency to version rolling-100 since it fixes a bug with subfolder media collection. The error message should be telling you:
update modlib to version rolling-100 or newer
which is exactly what you have to do: simply update your modlib. rolling-100 is available on CDB.
Please read error messages. Note that this is tagged as a "developer tool", so I don't think it's entirely unreasonable to expect the users to read the error messages.
For the future: Please attach stack traces to bug reports.
This does not implement *nix Glob Patterns, but rather simply uses Lua patterns. Nobody in their right mind would do rm -rf .* in their terminal - that will not remove all files, but rather only hidden files (files starting with a dot in their name)!
The only function provided is not exactly useful; how often do you need to kick multiple players based on a pattern? I could imagine this being useful only in very rare cases where an attacker is dumb enough to make his names follow a pattern. What makes this even more useless is that the Minetest chat features tab completion for playernames.
What I could see being useful: Actual globs, e.g. for file traversal purposes, but as an API rather than user-facing chatcommands.
No, not at all. Devtest is a tool, not a base for modding. You should not base games on devtest (like e.g. runs did with the Samz); games won't want the quickly thrown-together test content devtest provides.
The only thing I would like to be changed is add a setting for 'default' mods, to allow for modders to test things for performance simultaneously with gameplay.
This would completely defeat the purpose of devtest which is to be a minimal testbed. If you want mods, add and enable them. Wrap them up in a modpack if you want to use your usual mod soup.
Usually the best testbed for engine development or if you want to quickly play around with an engine feature.
Also very useful in mod development due to its minimalism,
which allows for a very fast loading time and also helps ensure that
your mod works even in a minimalist environment without bloaty mods such as default.
Devtest also provides a few introspective facilities (e.g. node editing tools etc.) and example content (nodes, entities etc.) that aid in engine and mod testing.
That said, when you're developing a new game for players, you should under no circumstances base it on devtest (except if your game is intended to serve as a replacement testbed or perhaps a more specific mod testbed).
Take a look at https://github.com/Bapt-Tech/privs/blob/main/init.lua. There are some problems with this.
core.set_player_privs. This means it erases all other privileges if a player on one of the lists joins. (Technically this is just a bug, but it is a critical one.)Name1andName2have excessive privs)I think this mod is probably not general purpose enough to be very useful for others. So far it seems pretty much strictly inferior to
/grantto me (note that privileges should be persisted if there isn't a mod like this one breaking them).I think people forget that (1) issue trackers and (2) threads exist for minor things like this, a neutral review is not the appropriate tool to use here.
I would suggest converting this review into a thread.
I believe it's a pun on "extraordinary".
Can you be more specific about your environment?
Personally I perceived the atmosphere more as "weird" than "creepy"; it didn't occur to me to interpret the "writing on the walls" as blood for example. Have you considered a friendlier reskin? It should be pretty easy to make something like a texture pack (or a mod which only overrides media including sounds, maybe a few story elements) to make this a game suitable for a broader range of peeps (though I don't know whether children would have the patience for some of the levels ;)).
A fun twist on the "stealth" genre: Not only are there evil eyes which must not see you; most of the time the challenge is to stay within the field of view of at least one good eye: "The Unseen are lost!"
The game further gains a bit of a puzzle game note by having buttons you have to press to make new paths accessible. These can be hard to find at times, but it is never wrong to press them. Hence the winning strategy essentially is to scour the levels for buttons, pressing all of them (and memorizing their positions and a sensible order to press them in for future attempts in case you fail), though this is in practice much harder to do than it sounds. Some buttons are definitely deviously placed :)
The graphics, music, and overall atmosphere are all consistent and nicely done.
Overall, a good two to three hours of fun.
You mean renaming worlds? That's an engine feature request: https://github.com/minetest/minetest/issues/10147.
Thanks for the clarification. In light of it, please let me apologize for insinuating that you were being mean towards the mod author. (I believe I owe you an explanation: I simply had not seen a direct connection between your review and this mod initially. It seemed to me as if you were not reviewing their mod specifically, but rather voicing generic criticism not specific to this mod.)
Given this clarification, ContentDB staff might want to reconsider whether this would qualify as a review.
How ContentDB deals with library mods is a ContentDB problem, not a problem of this mod; and ContentDB has a tag for library mods ("API / Library").
Is it though? If everything goes smoothly, I don't see any issues here. And I don't see a solid suggestion for how to handle library mods instead coming from you either.
Easy: Because a mod they use depends on them. Note also that our users aren't just players, but also e.g. admins or other developers.
Please don't do what you did here: Write a review which is not at all about the actual "content" of this library mod - the actual APIs implemented - but rather about the meta-topic of "how do we want to deal with library mods".
I frankly think you're being mean and unfair towards the author of this mod.
You have no substantial criticism relevant to what this package is about, yet gave this package a negative review.
I will not write a positive review of a library mod I haven't used and potentially will not use just to balance out your unfair negative review.
This statement is false. Any library mod, including unicode text, only provides value to modders, who then use that value to create value for players. Some contributions may be more direct, but better logging may certainly benefit end users, especially as they get more technical (which does not just mean developers; there are also admins and moderators).
(I still don't get why you're calling this "binary" when it's plaintext source code. That's a very confusing, fearmongering way to use the word "binary" for sure - as if this was some intransparent binary blob rather than a small piece of Lua any interested tinkerer can easily poke.)
This is where you go plain wrong. ContentDB is explicitly also a place for such dependencies, whether you like that or not. Quoting the package inclusion policy:
In other words, you're negatively reviewing a package for doing something encouraged by the package inclusion policy.
I'm not sure where you see any "binary dependencies" here.
This is quite a critical, potentially game-breaking bug though. Users should be made aware of this one way or another.
I can only agree with the other reviewer(s): This is by far the best chess implementation in Minetest to date. It's nicely usable; you get a 3d view of the board. The engine works and actually picks decent moves.
Now, that's where the unexpected part comes in: Random "events" can completely change the course of the game. Strategies that work against the engine in "normal" chess don't work anymore. Beating the engine at "normal" chess is doable, but the "unexpected" version will give you a much harder time. It can be pretty frustrating if you worked hard on getting your pawns into good positions and suddenly they all just evaporate :P
Suggestions: Highlight the last move / action somehow (maybe using particle effects?). Otherwise it is at times hard to see what just happened. Also, please give the player a moment to review a checkmate.
Overall, a very good game!
Huh, that's odd. Could you maybe detail your experience?
I found the game to be pretty straightforward: When you spawn, there's basically only one way you can go. As you walk this way, the story is presented to you through the dialogue between you and the light orb: You have to collect light crystals while fighting off "shadowspawns". For that you have to go through the portals.
The ending (the boss you have to fight) fits "unexpected" quite well, I'd say.
I like this demonstration of just how much Minetest can be abused, but there isn't really anything to do; all the "games" become pretty boring pretty fast.
I like the graphics as well as the gameplay. The trick is to not fight too much, but to make a run for it ;P
Took me ~20 minutes to play this through, I like the mechanics. The "health powder" feels like a bit of a cheat - I had plenty of it when I went into the boss fight.
"Your a teenager who does the devious licks challenge"
Yes, just like 5.0 broke compatibility in 2019. These breaking releases are rare though.
I wouldn't say you are "in danger". Minetest likely won't have a breaking release for a while; the next scheduled release is 5.9. But there will eventually be a breaking release, and it is possible that some mods that aren't updated will not work with the newer Minetest engine then.
Yes: Don't update. Minetest doesn't update itself. If your package manager installs breaking updates automatically, configure your package manager properly.
In an ideal world, they should not. However neither Minetest Engine nor modders are perfect. There are three reasons that mods do break:
But nevertheless, for the most part, the Minetest Engine has a good track record of keeping backwards compatibility. I don't know whether caverealms or Minetest is to blame in this specific instance. I would recommend reporting the issue.
It should. Since version 5.0, the Minetest Engine tries to follow semantic versioning. This means that "minor" releases like 5.8 are backwards compatible with other "minor" releases like 5.1. So if a game or mod works on 5.1, it should also work on 5.2, 5.3, ..., 5.8, 5.9 etc. Only 6.0 may break compatibility.
Hence Minetest Game 5.1.1 should work in Minetest Engine 5.8 just fine. Of course, you'll miss out on the bugfixes later Minetest Game versions bring. Minetest Game strives to follow semantic versioning and be backwards compatible just as well, so if mods work with MTG 5.1, they should continue to work with MTG 5.2, 5.3, etc.
First off: On ContentDB, please open threads (rather than making neutral reviews) for questions.
All of this seems to concern the Minetest Engine rather than Minetest Game?
They should not: Minetest 5.8 is a minor release. It should not be breaking compatibility.
No.
You should not be. (There is always a small risk of modders relying on engine internals however.)
This is an engine change. It is unrelated to Minetest Game.
Let me add my opinion as a modder.
The time spent on mod reviews is not "wasted"; it is necessary to nip some issues in the bud before they arise, and it worked well here: Without the review, you would have released the mod under a name that was already in use.
There have also been plenty of other mods with issues that got caught in review. It is especially useful to try to catch copyright (and other legal) issues before there is a formal complaint.
Either way, I don't think the review system is up for debate.
You're being very impatient. Waiting a few days for your mod to be reviewed is normal.
Well, this is for player interaction, not for mods doing things.
Swap node detection? What do you mean by that? Like replacing, say, a plant with another node? What do you expect this mod to do in such a case?
Thanks for the review! What exactly is nerdpoling (is it what I know as "pillaring"?), and what would you suggest to "stop it"? I wrote this as a means of (among other things) slowing down pillaring, since fast pillaring typically requires you to place blocks colliding with you. A block placement quota might additionally be useful to slow down pillaring. An alternative option to consider is something like structural integrity checking, where pillars past a certain height would degrade to piles (blocks would fall left and right).
This is likely to be out of scope.
character_animtries to be as game-agnostic as possible by only expecting a few standard bones the Minetest Game default player model (character.b3d) typically provides: Body, head and right arm. I don't plan to add custom models. I could add support for more advanced model conventions, but that would complicate the code and probably only serve a single game (Mineclone) which provides such a model (and already has its own provisions for animations).You can use
visible_wielditem.item_tweaks.names["default:torch"]to change that. I could add better default settings for MTG items, but I feel that would bloat the scope of this project - there probably are plenty of items in plenty of games that could use special tweaks...Thanks for the report. This was a character_anim bug I never noticed because as soon as
player_apichanges the animation - as soon as you move, punch, rightclick, lay, use a boat, whatever - an animation would have been set; this bug was only noticeable if you actually immediately changed into third-person view before doing anything. The fix was trivial; I just had to preserve the initial animation.Sounds like a Minetest issue with chunkgen and (graphics card / Irrlicht) geometry limits (max vertices / indices / ...)
Minetest Game being bundled by default is an engine issue rather than a game issue. This renders your review irrelevant for the Minetest Game ContentDB package.
Devtest is to be used as a tool, not as a base for modding...
I have recently bumped the modlib dependency to version rolling-100 since it fixes a bug with subfolder media collection. The error message should be telling you:
which is exactly what you have to do: simply update your modlib. rolling-100 is available on CDB.
Please read error messages. Note that this is tagged as a "developer tool", so I don't think it's entirely unreasonable to expect the users to read the error messages.
For the future: Please attach stack traces to bug reports.
This does not implement *nix Glob Patterns, but rather simply uses Lua patterns. Nobody in their right mind would do
rm -rf .*in their terminal - that will not remove all files, but rather only hidden files (files starting with a dot in their name)!The only function provided is not exactly useful; how often do you need to kick multiple players based on a pattern? I could imagine this being useful only in very rare cases where an attacker is dumb enough to make his names follow a pattern. What makes this even more useless is that the Minetest chat features tab completion for playernames.
What I could see being useful: Actual globs, e.g. for file traversal purposes, but as an API rather than user-facing chatcommands.
No, not at all. Devtest is a tool, not a base for modding. You should not base games on devtest (like e.g. runs did with the Samz); games won't want the quickly thrown-together test content devtest provides.
This would completely defeat the purpose of devtest which is to be a minimal testbed. If you want mods, add and enable them. Wrap them up in a modpack if you want to use your usual mod soup.
Usually the best testbed for engine development or if you want to quickly play around with an engine feature.
Also very useful in mod development due to its minimalism, which allows for a very fast loading time and also helps ensure that your mod works even in a minimalist environment without bloaty mods such as
default.Devtest also provides a few introspective facilities (e.g. node editing tools etc.) and example content (nodes, entities etc.) that aid in engine and mod testing.
That said, when you're developing a new game for players, you should under no circumstances base it on
devtest(except if your game is intended to serve as a replacement testbed or perhaps a more specific mod testbed).Ah, so if you just wanted to translate it, why did you review it?
Your mod? You're not supposed to leave reviews on your own mods using alternate accounts…
You could (and should) have just left your personal feelings out of it to keep it professional. Professional reviews also don't "get hate".
How is this relevant for your review?
Would you consider yourself unbiased?