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).
The awesome art is mostly thanks to TEMHOTAOKEAHA and Dragoni, our awesome pixel artists :)
The mech model looks nice, I only wish it had animations.
This was planned but the model had to be added last minute and there was no time left to add animations unfortunately. In fact there even is an animated model that just couldn't be added yet.
I believe that the music in the ice layer could be more varied, as you're bound to spend more time in there to stockpile supplies for the danger ahead.
Agreed. IIRC I had to sort out some tracks due to nonfree (non-commercial) licenses.
I couldn't complete the game because the enemies simply frightened me too much: when I poked my head in a cave close to their spawn depth, a swarm of 10~ of them attacked me and caused me to flee. When I tried to fight them, they always overwhelmed me with numbers because of their fast spawn rate.
Hostile spawning has been limited post-submission.
The pixel art in the opening and menus is very clean too.
That's mostly thanks to TEMHOTAOKEAHA and Dragoni, our awesome pixel artists :)
especially for drilling
There is a sound effect for drilling, but it requires MT 5.7-dev... Should be fine as soon as 5.7 releases though. More sound FX are definitely planned long term.
There were some plants that were kind of floating a few blocks off the ground that looked like they should be hanging from the ceiling.
Hmm indeed, I'll look into this.
Hostile spawning has been limited post-submission.
What was confusing is the game tells you to go to a spot on your radar but I did that and found ... nothing. Strange. Probably this wasn't coded yet?
This definitely is implemented ("beacons"). How many of these (and of which kinds) you manage to obtain determines your ending. Note that the dot on your radar gets larger the closer you get to the beacon on the vertical axis. Perhaps you were at the wrong depth? (It is possible that there are issues with beacon spawning code though; in my tests I have always been able to dig at least one beacon though).
This game should actually be called "Speedrunning Down" because that's the winning strategy. :D
Heh, not quite. You should have gotten the "bad" ending if you just went down immediately; that is, "you find the same fate as the astronauts before you". Speedrunning Down is an "ending" strategy, but not a "winning" one :D
Minetest actually allows you to let a texture span over multiple nodes
We considered world-aligned textures but preferred mapgen randomization of textures.
Also, using the spray gun triggers an error message (not a crash).
Yep, added that last minute and the Minetest player name vs. player ref inconsistency got me :)
Fixed post-submission.
[Performance Problems]
I have fixed mob overpopulation post-submission. Optimizing the mapgen further is hard. I think it is already asymptotically optimal (or close to it), and I haven't been able to go much further on the constant factors using the LuaJIT profiler. In hindsight implementing the custom mapgen probably wasn't the best idea as it took an immense development effort and largely wrecks performance, even after optimization.
The acid sprayer is functional (it requires acid though); it's only the sound playing that's not working (I added that last minute). Fixed on Git (post-submission).
The lag is definitely a major problem - we didn't have enough time to optimize it properly (optimizing the mapgen in particular is very hard). We learned that implementing a fully custom, sophisticated Lua-only mapgen for a game jam game probably isn't the best idea.
I have fixed the mob overpopulation already, it's just post-submission as well. I'll also look into further optimizing stuff.
TL;DR: Not enough time in the game jam timeframe to polish everything (esp. as mapgen dev was very time consuming), but we will get there :)
Uranium Stuff author here, don't get discouraged by his negative review, you will figure out unique features to add.
I've actually added some very unique functions to my mod (beyond just radiation protection). The red thumbs down still stays though, lol.
No it doesn't :)
I've converted my review to a thread seeing that you added unique features.
Your stuff mod is a random stuff mod. It provides unique-ish items rather than just different tiers of the tools that already come in 5? tiers. The only thing it shares with this stuff mod is the "stuff" in its name.
The Uranium Stuff mod was even more unique than this - this is just pretty much a copypasta of the typical MTG stuff - ore, block, tools - without any unique-ish features like protection from radiation. As such, a copypasta review feels appropriate.
(plus even more stuff mods which do not live on CDB or have died with MT 0.4.x, such as galvorn & mithril in LOTT; besides, has anyone ever considered a more specific name like "equipment" rather than the insanely generic "stuff"?)
This is boring. It already was boring in Minetest Game - the tools don't differ except in their stats. Generally, the better the tier, the better the stats. "Stuff" mods just add yet another boring & redundant tier. The only notable exception here is LandarVargan's Lava Stuff, which has special effects (e.g. the lava pickaxe already "cooks" everything you dig with it like the MTG furnace).
Yes. The newest modlib update gets rid of modlib.conf in favor of a better API. I have updated hud_timers, but did not create a release yet. Fixed in rolling-9.
Minetest's profiler provides insufficient granularity for doing any serious profiling. Sure, in larger games it may point you towards the culprit, but that often still is a large globalstep or mapgen function.
More often, you already know the culprit - mapgen, in our case - and want to optimize it. To do so, you need a maximum of granularity, down to every function call, every vector operation, to be able to micro-optimize the hottest spots where it matters. The LuaJIT profiler provides this granularity and this mod makes it accessible (without having to go through the hassle of reinventing this mod).
Back to mapgen: After algorithmic optimizations were exhausted, this mod allowed me to gain a 2x speedup, bringing mapgen to an acceptable performance, by confirming that certain vector operations were better off localized and helping me uncover a nasty bug in my memoization (which wasn't working).
You only have 100ms between two globalsteps; Minetest is mostly single-threaded. Taking any more time will create noticeable lag. Thus practically all mapgen, ABMs, pathfinding, mob steps, and some expensive globalsteps are performance-critical.
Adoption of this mod will hopefully cause the widespread performance issues observed across the mod landscape to slowly cease existence.
The globalsteps runs only once per second (!); this is way too poor granularity. It could be a lot smoother if it ran as often as possible since it is a rather cheap globalstep.
Insufficient approach: This subtracts one from the player pos on the vertical axis. Player pos is a feet pos however. Thus this will fail horribly when standing on slabs and is always on the verge of failing (due to precision errors) when standing on full / almost full nodes. A more accurate approach would only subtract a small epsilon from the feet pos and take node boxes into account (e.g. when standing on smaller nodes (slabs) or larger nodes (doors)).
Misc. other (minor-ish) code quality issues:
Use of deprecated methods: player:getpos() (should trigger a warning?) and {x=...,y=...,z=...} vector (rather than vector.offset).
Unnecessary loc ~= nil check.
Poor formatting: Inconsistent use of indentation & semicolons.
Custom fields should use underscore prefixes. This mod does not abide by that convention for on_walk_over.
In conclusion, I would strongly advise against depending on this library in its current state. Modders should rather roll their own.
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?
Thanks for your review.
The awesome art is mostly thanks to TEMHOTAOKEAHA and Dragoni, our awesome pixel artists :)
This was planned but the model had to be added last minute and there was no time left to add animations unfortunately. In fact there even is an animated model that just couldn't be added yet.
Agreed. IIRC I had to sort out some tracks due to nonfree (non-commercial) licenses.
Hostile spawning has been limited post-submission.
Bugs
Thanks for your review.
That's mostly thanks to TEMHOTAOKEAHA and Dragoni, our awesome pixel artists :)
There is a sound effect for drilling, but it requires MT 5.7-dev... Should be fine as soon as 5.7 releases though. More sound FX are definitely planned long term.
Hmm indeed, I'll look into this.
Hostile spawning has been limited post-submission.
This definitely is implemented ("beacons"). How many of these (and of which kinds) you manage to obtain determines your ending. Note that the dot on your radar gets larger the closer you get to the beacon on the vertical axis. Perhaps you were at the wrong depth? (It is possible that there are issues with beacon spawning code though; in my tests I have always been able to dig at least one beacon though).
Heh, not quite. You should have gotten the "bad" ending if you just went down immediately; that is, "you find the same fate as the astronauts before you". Speedrunning Down is an "ending" strategy, but not a "winning" one :D
We considered world-aligned textures but preferred mapgen randomization of textures.
Yep, added that last minute and the Minetest player name vs. player ref inconsistency got me :)
Fixed post-submission.
I have fixed mob overpopulation post-submission. Optimizing the mapgen further is hard. I think it is already asymptotically optimal (or close to it), and I haven't been able to go much further on the constant factors using the LuaJIT profiler. In hindsight implementing the custom mapgen probably wasn't the best idea as it took an immense development effort and largely wrecks performance, even after optimization.
The acid sprayer is functional (it requires acid though); it's only the sound playing that's not working (I added that last minute). Fixed on Git (post-submission).
The lag is definitely a major problem - we didn't have enough time to optimize it properly (optimizing the mapgen in particular is very hard). We learned that implementing a fully custom, sophisticated Lua-only mapgen for a game jam game probably isn't the best idea.
I have fixed the mob overpopulation already, it's just post-submission as well. I'll also look into further optimizing stuff.
TL;DR: Not enough time in the game jam timeframe to polish everything (esp. as mapgen dev was very time consuming), but we will get there :)
(accidentally posted under a shared account which obviously may not reflect the views of only a single member)
Nothing more to this game. About 30 lines of Lua:
and
which mostly are taken verbatim from the Void Game (and which are just boring definitions anyways). No game logic behind it.
You can simply pillar up using your own feces. On a roof, you won't be disturbed while packing your feces.
Massive robocop overpopulation also causes insufferable lag.
Screenshot
No it doesn't :)
I've converted my review to a thread seeing that you added unique features.
Converted the review into a thread as the author has started adding unique features.
converted review into a thread
Your stuff mod is a random stuff mod. It provides unique-ish items rather than just different tiers of the tools that already come in 5? tiers. The only thing it shares with this stuff mod is the "stuff" in its name.
I don't want to discourage you from modding. Many people seem to start modding with a "stuff" mod. You don't need to upload every mod that you create.
This doesn't change the fact that I would not recommend any of these stuff mods to players.
The Uranium Stuff mod was even more unique than this - this is just pretty much a copypasta of the typical MTG stuff - ore, block, tools - without any unique-ish features like protection from radiation. As such, a copypasta review feels appropriate.
Quoting my review of the last stuff mod:
I have fixed them (except for deathlist) already but haven't fixed the script that releases new versions on CDB...
Oops, looks like I forgot to push; should be fixed now. Sorry.
Yes. The newest modlib update gets rid of
modlib.confin favor of a better API. I have updated hud_timers, but did not create a release yet. Fixed inrolling-9.Minetest's profiler provides insufficient granularity for doing any serious profiling. Sure, in larger games it may point you towards the culprit, but that often still is a large globalstep or mapgen function.
More often, you already know the culprit - mapgen, in our case - and want to optimize it. To do so, you need a maximum of granularity, down to every function call, every vector operation, to be able to micro-optimize the hottest spots where it matters. The LuaJIT profiler provides this granularity and this mod makes it accessible (without having to go through the hassle of reinventing this mod).
Back to mapgen: After algorithmic optimizations were exhausted, this mod allowed me to gain a 2x speedup, bringing mapgen to an acceptable performance, by confirming that certain vector operations were better off localized and helping me uncover a nasty bug in my memoization (which wasn't working).
You only have 100ms between two globalsteps; Minetest is mostly single-threaded. Taking any more time will create noticeable lag. Thus practically all mapgen, ABMs, pathfinding, mob steps, and some expensive globalsteps are performance-critical.
Adoption of this mod will hopefully cause the widespread performance issues observed across the mod landscape to slowly cease existence.
Have you considered converting your review into a thread?
player:getpos()(should trigger a warning?) and{x=...,y=...,z=...}vector (rather thanvector.offset).loc ~= nilcheck.on_walk_over.In conclusion, I would strongly advise against depending on this library in its current state. Modders should rather roll their own.
See my review on the last stuff mod.