Combat. This would be the big difference between 'walking and puzzles with a bit of survival' and 'puzzle-adventure'. The biggest challenge here would be deciding what the adversaries should actualy be. Maybe some sort of ad-hoc 'creatures', or maybe something related to the current non-boss. Ideally, they would tie into the puzzles to some extent also.
A more sophisticated energy system. The current one only reaches an approximately walkie-talkie level of complexity; extensions should make puzzles actually require thought. Perhaps this could be based on circuits, or perhaps on physics. Perhaps I could combine both paradigms somehow.
Strengthening the co-op requirements. Right now it's just 'Key can trigger X, Vix can trigger Y'; ideally the puzzles would be such that you have to not only consider what each character can do (or even how well they can do it), but also when, where, why, and how they should do it.
I called this one Artifact One solely to distinguish it from the original, which I wanted to keep available for historical reasons. It's not Artifact Two because the plan is for Artifact Two to actually continue the story chonologically; for all practical purposes, this is just a replacement for the original Artifact, not a sequel.
In the future, I think what I want to do is move the game into more of an RPG realm than the pure puzzle design it has now. That would probably involve something like:
Making the environment a whole lot bigger, both to fit more mechanics and story and to strengthen the exploration aspect.
Making the environment more dynamic. Currently you can break leaveas and that's about it. Some kind of movable objects (push, pull, collision) would be more interesting (and could also factor into puzzles).
Adding a map. This would be able to show the whole facility or the nearby area, with names and labels to make it seem more real.
The achievements page mentioned above. This would allow for player-initiated hints as well as better organization.
Adding collectible items. Some of these could perhaps serve as currency, while others could be things like keys that tie directly into progression.
Adding some sort of XP system. Maybe as a bar like usual, but maybe something less currency-like such as having only named levels that are advanced by game events and unlock further progression. Perhaps this could be implemented as a subset of an energy system.
Indeed, in retrospect the level design is probably the most important part of a game like this, but I didn't end up actually developing it much. To be fair, this was partly because I only had about 2 weeks to work on the game due to Thanksgiving, most of which were spent making the mechanics and underlying APIs work properly, but I also (again) didn't quite have a clear enough picture of what I actually wanted to make to be able to make it.
Yes, there should probably be some indication that sprinting is indeed implemented; I already didn't really like breaking the illusion by showing the message about the blackrod, though, so I didn't actually add a similar message for sprinting. I suppose I could either a) show such messages as a small, muted label at the bottom left corner rather than a bright box in the middle, or b) re-add the inventory formspec as a progress tracker (known elsewhere as an achievements page), with milestones for learning the controls.
Part of it is that the only real new mechanics introduced are the interactions, which aren't much of a mechanic to explore on their own. I toyed with the idea of a more complex circuitry-based design, but never ended up deciding what such a design would actually look like.
The graphics are indeed probably the biggest point in favor of the game at present. And yes, the story didn't end up getting explored anywhere near as much as I wanted. In the future, I probably ought to make it move more slowly (to match the atmosphere a little more), and focus more on auxiliary world-building details.
I don't think I'll want any actual music in this game, but some kind of subtle ambience is something I ought to look into sometime. Sadly, my sound design skills are currently only at the level of putting one noise on top of another and tuning the frequency, so 'sometime' likely won't arrive anytime soon...
This is intentional. My idea is for the game to give the player as little guidance as possible, only telling the player what their tools are and not what they should do with those tools. (Ideally, even that would be as subtle as possible while remaining reasonably clear, probably like interacting and breaking are.) Thus, the question should never be what you're 'supposed' to do but what you can do.
That said, I readily admit that the way the game currently goes about emphasizing that aspect is rather lacking. Most of my focus was on the polish and API strength, so the actual implementation of the plot unfortunately didn't get the attention it probably should have. I do hope to improve that in the future, though, once I acquire a better vision of how the game would be structured overall (more like Warcraft III or Zelda, perhaps?).
I personally dont like 'puzzle' that is just trying to find a trigger/item in some large room
You do have a good point, though; the exploration aspect doesn't work nearly as well in a small setting like this as it does in a larger, more open-world setting... I may try to remedy that in the future by having more 'real' puzzles as well. (And if I ever get around to making a sequel, I plan to have it be more open-world as well.)
i pressed Esc (pausing) then unpaused and that was enough to trigger the softlock
This is... odd. I haven't been able to reproduce this, even after trying multiple times. Are you sure that this is caused by pausing, and not by leaving and rejoining sometime earlier? (The latter would cause generators broken after rejoining not to be recorded, which would explain what you describe; I've already reproduced and fixed that case in the repository.)
If it is indeed caused by pausing, I'm inclined to put this one down as an obscure Minetest issue rather than a problem with my code, especially considering it seems to be a rare corner case...
There's not actually a way to get stuck in that room unless you just can't figure out what to do (which is to parkour anywhere you can until you find the next trigger); if you fall in the water you can just swim back to the well-lit stairway that gets you back to the entrance. (Honestly, I probably ended up relying too much on my own instinct to persistently examine every square inch of a game world until I find what I'm looking for...)
I never did playtest multi-session playthroughs, partly because my automation gives me a clean world every time I play and partly because the game is short enough to complete in a few minutes, so I didn't seriously foresee anyone not playing it through in one session. (For what it's worth, though, I did plan for this case, but forgot to do so for Vix as well.) Pausing (pressing Esc in singleplayer) should only affect chat message expiry, because the scenes are all based on minetest.after (and/or triggered by player action directly) and therefore game time rather than clock time. What I assume happened is that you left and rejoined, and my reconstitution logic failed to restore the action callback that was supposed to trigger the scene.
Both bugs are fixed in the repository, but can't be released because the game jam is still on.
Really? I deliberately made (very nearly) everywhere the player is expected to go fairly bright for exactly that reason, but without making everything as bright as if it were in sunlight. Maybe it's just my setup, but in testing I never even had to look closely to see everything clearly.
I'll admit that the story isn't that different (it essentially just has more detail). However, the way the gameplay matches the story is far different: the blackrod's function is totally different (it used to grant double-jump), and while the energy bursts are (still) rather similar and the levers resemble the switches, the overall design is completely different. In terms of actual features it's still a little similar (mostly just levers and doors so far), but I want to widen that gap in the future.
While I never played the jam version of Lazarr, as near as I can tell it's still at least mostly similar in terms of mechanics and art style, whereas here the entire premise for the mechanics and art style has changed.
Fair point, I should probably either make it stay a bit longer or find some way to subtly hint it until you use it...
Well, this may just be me, but I find it much easier to write code than to rewrite code. My real vision for the game was much different from what I ended up creating; I didn't want to be encumbered by the poor design decisions I made originally, and fixing them would result in more work than just starting over, so I just started over from the same premise to save myself the trouble. The result is a very different game code-wise (as I reused very little), and while the experience is indeed noticeably similar, this has diverged enough that I see it as the successor to the original, not an update. (In fact, the only reason I didn't just delete the original Artifact entirely is because I still wanted to keep it on ContentDB for historical reasons.)
My thought process in that regard was that a) people who genuinely don't like the style of the game don't have to play it, b) the gameplay should conform to the story, not the other way around, c) the game should always prefer being good over being appealing to everyone and d) I didn't implement (b) as well as I would have liked and will hopefully end up fixing it (see planned features). I suppose the idea in this case is for the game to be exploration-driven, not achievement-driven, so everything depends entirely on how much the player wants to explore rather than on anything the game does; thus, marketing to anyone other than people who like this sort of game would be pointless. In this case, that's a tradeoff I'm willing to accept as long as the game executes its premise well, though I might attempt something more generic (or at least differently oriented) in the future.
However, this is just the original game's immature little brother. Why the repeat?
I'm having a hard time understanding that conclusion. The original Artifact had some good aspects (animations, a power system, doors, decent textures), but incompletely implemented (low-quality cutscenes, buggy power transfer, gameplay and story irrelevance, dubious controls). Code-wise, it was all right, but not as good as it ought to have been. This time, I don't have incomplete animations or a somewhat out-of-place power system, and instead focus on actual gameplay and story by only considering triggers and effectors; I also unified the controls so as to actually remove the unnecessary inventory. The code is also a lot better quality (and reusable), and I like the textures and builds a lot better (especially because there are actual decorative nodes now). All told, there's very little similarity to the original Artifact except the overall premise, to the point that it's effectively an entirely different game.
It's one keystroke (Drop) now instead of two (4 + Punch). I suppose you were trying to switch by interacting, but that's even easier in my opinion provided you're in range.
It follows the same storyline
Well, what I tried to do was use the original concept but actually execute it well. The original storyline was little more than a skeleton and only partly thought through.
the dialog is just as anti-expositional and pointless
I prioritized believability and story consistency in this case, because exposition and gameplay are not the characters' priority, so this is largely intentional. Admittedly, that can make it less interesting if having fun is your main goal, but I made the game to suit my own standards, and I personally value fun comparatively little in a game.
the building isn't even a different style from the last one
The original Artifact hardly even had building, mostly just strategically placed WorldEdit commands with polishing in places. I thought the building style this time was vastly superior in that it actually feels natural and overgrown rather than sterile and contrived.
You're actually supposed to jump around the upper leaf node there to the one behind it; I thought the jump was very easy when I built it, but perhaps it should be a bit clearer that you can actually jump there in the first place...
There aren't any other mechanics at that point. Hitting everything is exactly what you're supposed to do, because when you deactivate all the forcefield generators the story progresses automatically. (Spoiler: Doing so requires a small amount of parkour.)
I should probably make a note in the description not to expect the mechanics to be the puzzle as much as where to use them...
Adding footstep sounds to the cutscenes was something I wanted to do but forgot about until it was too late.
Well, breaking the first two generators made the big forcefield wall thinner. Logically, then, there must be another generator somewhere around the room, and there's really only one place it could be.
The puzzles in the game actually turned out being more situational than mechanics-based, in that figuring out what to use the mechanics on is often more challenging than actually using the mechanics themselves. I consider that a positive, but you do have a point and I should probably disclaim it so people don't expect a 'normal' puzzle game.
(If you did break all the generators without anything happening, that may be because you left the world and rejoined; I didn't test that case very well despite trying to plan for it.) (Update: That bug should be fixed in the latest commit on the repository.)
not really by the image, as it's AI-generated
Same here, to be honest. My only real reason for including it was for the novelty of playing a video in Minetest (though it does look quite decent).
... privet skins on mineclonia servers are added to the skin list so everyone can use them nomater what.
Oops, seems I forgot about the Mineclonia skin chooser when I added private skins. Since I don't know of a good way to customize it per-player (and given the existing limitations when optimized media is active), in the latest release I've opted to simply not register private skins with the mineclonia skin chooser.
The reason for the first issue is that the skin you uploaded doesn't have the layout expected by the player model. The most common reason for this is that you're trying to upload a Minecraft skin, in which case you can just crop off the bottom 32 pixels of the image. I'll probably just add a note that if the preview looks wrong it's because you uploaded a wrongly-laid-out image (since it's not really possible to programmatically 'validate' UVs).
The 'no permission' error is likely because you did /grantme all, and that granted you the no_skin_upload privilege that prevents you from uploading skins. Revoking that should suffice. (The reason I did it this way, by the way, is to allow players on servers to upload skins by default (i.e. without the admin modifying minetest.conf) while still using a privilege check. A better solution could be to just implement my own privilege system so this doesn't happen.) (Also note that if your request limit has been reached, subsequent requests will silently overwrite prior ones.)
The /skinlimit bug is caused by a silly mistake on my part in which I forgot that %w doesn't include dashes and underscores.
I'll fix/address these issues in the next release.
This should be fixed in the latest release. Seems I absent-mindedly forgot to write the table that tracks requests back into the database so it can be reconstituted...
I don't really reccommend enabling the fragmented_meta setting, mostly because it disables all searching functionality (though that's probably fine for singleplayer).
It seems like you somehow didn't correctly add the entry to the meta file, which could cause a crash if the file is invalid (or maybe if I try to access a key that doesn't exist — I've added fallbacks to the next version). It might crash on set_skin, but my checks there should just make it not work if the meta doesn't exist. What's the error message?
What happens if you name a copy of the original PNG 'libskinupload_uploaded_skin_1.png', put it in the skins folder, and then try to choose a skin? (You probably need to add a meta key to libskinuplod_meta.json as well; refer to the bottom of the description for what that should look like.)
I haven't been able to look into this very much yet, but I did notice a possible problem in the code: I do wait 5s, but only to set the player texture. The compatibility code for mcl etc. always runs immediately, which could still trigger the bug I tried to work around by setting the player texture before the client has the skin media.
To fix that oversight, you can try replacing the libskinupload.set_skin function (starting c. line 836) with this:
local function apply_skin(p, tx, id)
p:set_properties({
textures = tx,
})
if mcl then
mcl_player.player_set_skin(p, "libskinupload_uploaded_skin_"..id..".png")
mcl_skins.save(p)
end
if minetest.get_modpath("3d_armor") then
armor.textures[p:get_player_name()].skin = "libskinupload_uploaded_skin_"..id..".png"
end
end
function libskinupload.set_skin(p, id)
local fname = "libskinupload_uploaded_skin_"..id..".png"
local meta = libskinupload.get_skin_meta(fname)
if not meta then
libskinupload.forget_skin(p)
minetest.chat_send_player(p:get_player_name(), "Your skin does not exist anymore.")
return
end
if meta.p and meta.c ~= p:get_player_name() then
--minetest.chat_send_player(p:get_player_name(), "Insufficient permissions.")
return
end
local m = p:get_meta()
local tx = p:get_properties().textures
tx[1] = fname..m:get_string("texmod")
if not libskinupload.enabled[id] then
libskinupload.add_skin_media(id, false, function(name)
-- 5s delay to dodge a potential race condition that happens for unknown reasons.
minetest.after(5, function()
apply_skin(p, tx, id)
end)
end)
else
minetest.after(0, function()
apply_skin(p, tx, id)
end)
end
db:set_string("skin:"..p:get_player_name(), id)
end
What should happen is that nothing should change for 5s, then your skin should update correctly.
It seems I can reproduce this issue, but not reliably. My guess is that something is going wrong with dynamic media, but I still don't know what. (Even more strange is that I wait 5s after requesting that the skin be dynamically allocated specifically to work around a similar issue.) If you keep trying to upload, accept, and apply the skin, does it eventually work? Also, what game are you using libskinupload with? I'll keep testing and try to fix this in the next update.
So the saved file is now a valid PNG? If so, what's the specific error message you're getting now?
You can also try disabling the libskinupload.optimize_media setting to use the simpler scheme of always referencing the textures by name, and report how that affects things.
The meta directory shouldn't be created: version 6 added basic search functionaliy, which requires metadata for all skins to be stored in a single file (libskinupload_meta.json next to the libskinupload_skins folder).
Converting the skin to base64 works fine, because the texture renders properly in the upload and review formspecs.
The base64 is stored correctly, because the review formspec works just fine.
However, the file that gets saved to disk is not a valid PNG.
So, the issue would appear to lie in either how the base64 in the request is decoded, or how the file is written.
Since I can't seem to reproduce the issue, the problem is probably not with the base64 decoding. One thing that comes to mind is minetest.safe_file_write(path, content), which "Replaces contents of file at path with new contents in a safe (atomic) way." I don't know how relevant it is, but it's recommended for writing binary files. You can see if it makes a difference by replacing the following code around line 316:
local f = io.open(fp, "w+")
if not f:write(minetest.decode_base64(req.data)) then minetest.log("error", "Failed to write skin file.") end
f:flush()
f:close()
with:
if not minetest.safe_file_write(fp, minetest.decode_base64(req.data)) then minetest.log("error", "Failed to write skin file.") end
In that case, are you sure you're converting the image to base64 correctly? If the image itself is valid, then the issue is most likely with how it's converted to base64. You can try using (a different) one of the numerous online converters, which ought to work.
(I'm not really sure what you mean by 'output file', since you should just be getting plain text that you can copy/paste. If you're putting it in a file, that makes sense, since as a rule image editors don't open base64-encoded PNGs.)
For what it's worth, this issue isn't really the fault of libskinupload, since the base64 you paste in isn't touched except for stripping data URL prefixes and a length check. The issue, thus, almost certainly lies somewhere in how you get your data.
This means that you're trying to upload something that isn't a valid PNG image. The reason this got through to cause a Minetest error is because I only do a simple check for 'iVBOR' at the start of the data, which as you can see your invalid data still passes. The un-base64 version of the data you mention includes 'PNEc', not 'PNG' like it ought, so it's possible that the file is somehow corrupted or in a different format (since your OS doesn't understand it either). An interesting thing to note is that your data visually looks similar to what it should be: 'iVBORWOK' vs. 'iVBORw0K'. Probably the only thing for it is to use another image file that you know is valid (i.e. that opens in your image editor), which should be as simple as redownloading/re-exporting the skin in question.
I apologize for the issue. It's a known bug that I've already fixed locally (and that GreenXenith fixed in the PR in the git repository), but I'm currently updating the cutscenes to be less 'placeholder' and I don't want to push an update until those are ready. The reason I don't consider it game-breaking enough to merit a single-bugfix release is that (1) it doesn't happen reliably, so half the time everything works correctly, and (2) it's trivial (albeit annoying) to work around (as mentioned in CalebJ's review).
For now, you can use /teleport 84 237 136 to get to the correct start position (or apply the PR in the not-yet-outdated git repository).
Skins aren't automatically added to the selection list; they need to be reviewed first. Right now, you do that by running /grantme skin_review, then running /skinreview, selecting your skin, and clicking Accept.
I'll admit that in the case of singleplayer, the review phase can be a bother, since it's completely unnecessary. I'll look into making requests from authorized users (with the server privilege? Skin reviewers?) be auto-accepted.
The room after the blackrod probably needs work in that regard, since the final loose wire can be difficult to spot given the darkness... I don't think any of the doors are actually broken, though, at least they weren't in my playtests. (Some I left locked so the player couldn't race through and miss the cutscene; if you didn't miss any cutscenes, you most likely didn't break anything, since those are the only state change triggers.)
I did mostly guess on the timing, I'll admit. I planned to have voice acting, which would have helped with that, but I had to drop it for the present. However, an interesting feature of my dialogue system is that it uses Minetest's own chat system for persistence: all dialogue messages can be re-read at your leisure in the chat log. (Fun fact: Sending a chat message yourself will do exactly the same thing.)
I apologize for the bug, it's never happened to me and I thought I had prevented it from being a possiblity. I'll try to fix it post-jam.
To be honest, I thought the exploration section wasn't enough of a maze when I made it: every path will lead to the next checkpoint as long as you stick to the path of most resistance (e.g. if a door can be activated with a switch, choose it instead of the other doors in the room). You can go in circles, but if you remember and avoid paths you've already taken, it's not very likely. Looking back on it, I think that making the exploration section as much of a maze as it is actually contributes nicely to the puzzle aspect of the game, because you're forced to think about where you're going instead of blindly following the author's cues. And in the context of the story, it also makes sense: the structure wasn't designed with Key's pleasure in mind, and the boss is using the puzzles to weed out small fry. The goal of the game isn't just to keep you constantly entertained, I'd like it to challenge you as well.
That said, I'll grant that the game has a slow start with the exploration stage. The interesting mechanics begin to be introduced after that, which is why it's unfortunate that you didn't want to keep going. I expect it could probably also use some improvement to make it less likely to go in a circle on the first try.
Yes, that's the end; because the final part of the game was thrown together at the last second, there's no real indication that the game is actually over. I thought about just kicking the player, but didn't end up implementing that.
That seems to be the case: the glass is actually a forcefield, and you're expected to turn it off, so as to free the other character. It could probably use some better hinting.
Thanks for the feedback. The formspec suggestion is interesting, I'll have to try that. For the rest, I agree that the pace needs work, since long hallways are at best an atmospheric element and more likely an annoyance. The original idea was actually to have the puzzles split not into discrete rooms, but 'regions', which in theory could make the hallways serve some further purpose than a delay, or even largely eliminate hallways in favor of wider spaces. The first cutscene was intended to have a slow start for suspense, though I may have overdone it slightly. The rest were essentially a rush job, so I mostly just strung the dialogue together with reasonable guesses for how long it would take to say (I was planning to have voice acting, but that fell through at the last minute) and worked off of that. They'll definitely be reworked later.
Where did you softlock? I know of one point (the room after the blackrod) where it's possible to trigger a minor wire update bug, but that's fixable by replacing a wire segment.
I'll grant that the game could probably use some clarification as to where to go in the first stage. However, the ambiguity is mostly intentional, as the first stage is intended to be mostly exploration-based since the player doesn't have any abilities at first. That said, the general rule is that down is further in, though it can take some perseverence to find out which doors actually lead 'down'. Eventually you'll trigger another cutscene, and from there the path gets much simpler. I doubt you softlocked yourself, because there are only two switches in the first stage, and only (at least) one of them is necessary to get to the cutscene.
I called this one Artifact One solely to distinguish it from the original, which I wanted to keep available for historical reasons. It's not Artifact Two because the plan is for Artifact Two to actually continue the story chonologically; for all practical purposes, this is just a replacement for the original Artifact, not a sequel.
In the future, I think what I want to do is move the game into more of an RPG realm than the pure puzzle design it has now. That would probably involve something like:
Indeed, in retrospect the level design is probably the most important part of a game like this, but I didn't end up actually developing it much. To be fair, this was partly because I only had about 2 weeks to work on the game due to Thanksgiving, most of which were spent making the mechanics and underlying APIs work properly, but I also (again) didn't quite have a clear enough picture of what I actually wanted to make to be able to make it.
Yes, there should probably be some indication that sprinting is indeed implemented; I already didn't really like breaking the illusion by showing the message about the blackrod, though, so I didn't actually add a similar message for sprinting. I suppose I could either a) show such messages as a small, muted label at the bottom left corner rather than a bright box in the middle, or b) re-add the inventory formspec as a progress tracker (known elsewhere as an achievements page), with milestones for learning the controls.
Part of it is that the only real new mechanics introduced are the interactions, which aren't much of a mechanic to explore on their own. I toyed with the idea of a more complex circuitry-based design, but never ended up deciding what such a design would actually look like.
The graphics are indeed probably the biggest point in favor of the game at present. And yes, the story didn't end up getting explored anywhere near as much as I wanted. In the future, I probably ought to make it move more slowly (to match the atmosphere a little more), and focus more on auxiliary world-building details.
I don't think I'll want any actual music in this game, but some kind of subtle ambience is something I ought to look into sometime. Sadly, my sound design skills are currently only at the level of putting one noise on top of another and tuning the frequency, so 'sometime' likely won't arrive anytime soon...
This is intentional. My idea is for the game to give the player as little guidance as possible, only telling the player what their tools are and not what they should do with those tools. (Ideally, even that would be as subtle as possible while remaining reasonably clear, probably like interacting and breaking are.) Thus, the question should never be what you're 'supposed' to do but what you can do.
That said, I readily admit that the way the game currently goes about emphasizing that aspect is rather lacking. Most of my focus was on the polish and API strength, so the actual implementation of the plot unfortunately didn't get the attention it probably should have. I do hope to improve that in the future, though, once I acquire a better vision of how the game would be structured overall (more like Warcraft III or Zelda, perhaps?).
You do have a good point, though; the exploration aspect doesn't work nearly as well in a small setting like this as it does in a larger, more open-world setting... I may try to remedy that in the future by having more 'real' puzzles as well. (And if I ever get around to making a sequel, I plan to have it be more open-world as well.)
This is... odd. I haven't been able to reproduce this, even after trying multiple times. Are you sure that this is caused by pausing, and not by leaving and rejoining sometime earlier? (The latter would cause generators broken after rejoining not to be recorded, which would explain what you describe; I've already reproduced and fixed that case in the repository.)
If it is indeed caused by pausing, I'm inclined to put this one down as an obscure Minetest issue rather than a problem with my code, especially considering it seems to be a rare corner case...
There's not actually a way to get stuck in that room unless you just can't figure out what to do (which is to parkour anywhere you can until you find the next trigger); if you fall in the water you can just swim back to the well-lit stairway that gets you back to the entrance. (Honestly, I probably ended up relying too much on my own instinct to persistently examine every square inch of a game world until I find what I'm looking for...)
I never did playtest multi-session playthroughs, partly because my automation gives me a clean world every time I play and partly because the game is short enough to complete in a few minutes, so I didn't seriously foresee anyone not playing it through in one session. (For what it's worth, though, I did plan for this case, but forgot to do so for Vix as well.) Pausing (pressing Esc in singleplayer) should only affect chat message expiry, because the scenes are all based on minetest.after (and/or triggered by player action directly) and therefore game time rather than clock time. What I assume happened is that you left and rejoined, and my reconstitution logic failed to restore the action callback that was supposed to trigger the scene.
Both bugs are fixed in the repository, but can't be released because the game jam is still on.
While I never played the jam version of Lazarr, as near as I can tell it's still at least mostly similar in terms of mechanics and art style, whereas here the entire premise for the mechanics and art style has changed.
I'm having a hard time understanding that conclusion. The original Artifact had some good aspects (animations, a power system, doors, decent textures), but incompletely implemented (low-quality cutscenes, buggy power transfer, gameplay and story irrelevance, dubious controls). Code-wise, it was all right, but not as good as it ought to have been. This time, I don't have incomplete animations or a somewhat out-of-place power system, and instead focus on actual gameplay and story by only considering triggers and effectors; I also unified the controls so as to actually remove the unnecessary inventory. The code is also a lot better quality (and reusable), and I like the textures and builds a lot better (especially because there are actual decorative nodes now). All told, there's very little similarity to the original Artifact except the overall premise, to the point that it's effectively an entirely different game.
I'm not sure what you mean?
It's one keystroke (Drop) now instead of two (4 + Punch). I suppose you were trying to switch by interacting, but that's even easier in my opinion provided you're in range.
Well, what I tried to do was use the original concept but actually execute it well. The original storyline was little more than a skeleton and only partly thought through.
I prioritized believability and story consistency in this case, because exposition and gameplay are not the characters' priority, so this is largely intentional. Admittedly, that can make it less interesting if having fun is your main goal, but I made the game to suit my own standards, and I personally value fun comparatively little in a game.
The original Artifact hardly even had building, mostly just strategically placed WorldEdit commands with polishing in places. I thought the building style this time was vastly superior in that it actually feels natural and overgrown rather than sterile and contrived.
You're actually supposed to jump around the upper leaf node there to the one behind it; I thought the jump was very easy when I built it, but perhaps it should be a bit clearer that you can actually jump there in the first place...
There aren't any other mechanics at that point. Hitting everything is exactly what you're supposed to do, because when you deactivate all the forcefield generators the story progresses automatically. (Spoiler: Doing so requires a small amount of parkour.)
I should probably make a note in the description not to expect the mechanics to be the puzzle as much as where to use them...
Adding footstep sounds to the cutscenes was something I wanted to do but forgot about until it was too late.
Well, breaking the first two generators made the big forcefield wall thinner. Logically, then, there must be another generator somewhere around the room, and there's really only one place it could be.
The puzzles in the game actually turned out being more situational than mechanics-based, in that figuring out what to use the mechanics on is often more challenging than actually using the mechanics themselves. I consider that a positive, but you do have a point and I should probably disclaim it so people don't expect a 'normal' puzzle game.
(If you did break all the generators without anything happening, that may be because you left the world and rejoined; I didn't test that case very well despite trying to plan for it.) (Update: That bug should be fixed in the latest commit on the repository.)
Same here, to be honest. My only real reason for including it was for the novelty of playing a video in Minetest (though it does look quite decent).
Thanks for the review (and the bug report).
Oops, seems I forgot about the Mineclonia skin chooser when I added private skins. Since I don't know of a good way to customize it per-player (and given the existing limitations when optimized media is active), in the latest release I've opted to simply not register private skins with the mineclonia skin chooser.
/grantme all, and that granted you the no_skin_upload privilege that prevents you from uploading skins. Revoking that should suffice. (The reason I did it this way, by the way, is to allow players on servers to upload skins by default (i.e. without the admin modifying minetest.conf) while still using a privilege check. A better solution could be to just implement my own privilege system so this doesn't happen.) (Also note that if your request limit has been reached, subsequent requests will silently overwrite prior ones.)/skinlimitbug is caused by a silly mistake on my part in which I forgot that %w doesn't include dashes and underscores.I'll fix/address these issues in the next release.
This should be fixed in the latest release. Seems I absent-mindedly forgot to write the table that tracks requests back into the database so it can be reconstituted...
I don't really reccommend enabling the fragmented_meta setting, mostly because it disables all searching functionality (though that's probably fine for singleplayer).
It seems like you somehow didn't correctly add the entry to the meta file, which could cause a crash if the file is invalid (or maybe if I try to access a key that doesn't exist — I've added fallbacks to the next version). It might crash on set_skin, but my checks there should just make it not work if the meta doesn't exist. What's the error message?
What happens if you name a copy of the original PNG 'libskinupload_uploaded_skin_1.png', put it in the skins folder, and then try to choose a skin? (You probably need to add a meta key to libskinuplod_meta.json as well; refer to the bottom of the description for what that should look like.)
I haven't been able to look into this very much yet, but I did notice a possible problem in the code: I do wait 5s, but only to set the player texture. The compatibility code for mcl etc. always runs immediately, which could still trigger the bug I tried to work around by setting the player texture before the client has the skin media.
To fix that oversight, you can try replacing the
libskinupload.set_skinfunction (starting c. line 836) with this:What should happen is that nothing should change for 5s, then your skin should update correctly.
It seems I can reproduce this issue, but not reliably. My guess is that something is going wrong with dynamic media, but I still don't know what. (Even more strange is that I wait 5s after requesting that the skin be dynamically allocated specifically to work around a similar issue.) If you keep trying to upload, accept, and apply the skin, does it eventually work? Also, what game are you using libskinupload with? I'll keep testing and try to fix this in the next update.
So the saved file is now a valid PNG? If so, what's the specific error message you're getting now?
You can also try disabling the
libskinupload.optimize_mediasetting to use the simpler scheme of always referencing the textures by name, and report how that affects things.The meta directory shouldn't be created: version 6 added basic search functionaliy, which requires metadata for all skins to be stored in a single file (libskinupload_meta.json next to the libskinupload_skins folder).
Ah, I see. So, what we know is that:
Since I can't seem to reproduce the issue, the problem is probably not with the base64 decoding. One thing that comes to mind is
minetest.safe_file_write(path, content), which "Replaces contents of file at path with new contents in a safe (atomic) way." I don't know how relevant it is, but it's recommended for writing binary files. You can see if it makes a difference by replacing the following code around line 316:with:
In that case, are you sure you're converting the image to base64 correctly? If the image itself is valid, then the issue is most likely with how it's converted to base64. You can try using (a different) one of the numerous online converters, which ought to work.
(I'm not really sure what you mean by 'output file', since you should just be getting plain text that you can copy/paste. If you're putting it in a file, that makes sense, since as a rule image editors don't open base64-encoded PNGs.)
For what it's worth, this issue isn't really the fault of libskinupload, since the base64 you paste in isn't touched except for stripping data URL prefixes and a length check. The issue, thus, almost certainly lies somewhere in how you get your data.
This means that you're trying to upload something that isn't a valid PNG image. The reason this got through to cause a Minetest error is because I only do a simple check for 'iVBOR' at the start of the data, which as you can see your invalid data still passes. The un-base64 version of the data you mention includes 'PNEc', not 'PNG' like it ought, so it's possible that the file is somehow corrupted or in a different format (since your OS doesn't understand it either). An interesting thing to note is that your data visually looks similar to what it should be: 'iVBORWOK' vs. 'iVBORw0K'. Probably the only thing for it is to use another image file that you know is valid (i.e. that opens in your image editor), which should be as simple as redownloading/re-exporting the skin in question.
I apologize for the issue. It's a known bug that I've already fixed locally (and that GreenXenith fixed in the PR in the git repository), but I'm currently updating the cutscenes to be less 'placeholder' and I don't want to push an update until those are ready. The reason I don't consider it game-breaking enough to merit a single-bugfix release is that (1) it doesn't happen reliably, so half the time everything works correctly, and (2) it's trivial (albeit annoying) to work around (as mentioned in CalebJ's review).
For now, you can use
/teleport 84 237 136to get to the correct start position (or apply the PR in the not-yet-outdated git repository).Skins aren't automatically added to the selection list; they need to be reviewed first. Right now, you do that by running
/grantme skin_review, then running/skinreview, selecting your skin, and clicking Accept.I'll admit that in the case of singleplayer, the review phase can be a bother, since it's completely unnecessary. I'll look into making requests from authorized users (with the server privilege? Skin reviewers?) be auto-accepted.
The room after the blackrod probably needs work in that regard, since the final loose wire can be difficult to spot given the darkness... I don't think any of the doors are actually broken, though, at least they weren't in my playtests. (Some I left locked so the player couldn't race through and miss the cutscene; if you didn't miss any cutscenes, you most likely didn't break anything, since those are the only state change triggers.)
I did mostly guess on the timing, I'll admit. I planned to have voice acting, which would have helped with that, but I had to drop it for the present. However, an interesting feature of my dialogue system is that it uses Minetest's own chat system for persistence: all dialogue messages can be re-read at your leisure in the chat log. (Fun fact: Sending a chat message yourself will do exactly the same thing.)
I apologize for the bug, it's never happened to me and I thought I had prevented it from being a possiblity. I'll try to fix it post-jam.
To be honest, I thought the exploration section wasn't enough of a maze when I made it: every path will lead to the next checkpoint as long as you stick to the path of most resistance (e.g. if a door can be activated with a switch, choose it instead of the other doors in the room). You can go in circles, but if you remember and avoid paths you've already taken, it's not very likely. Looking back on it, I think that making the exploration section as much of a maze as it is actually contributes nicely to the puzzle aspect of the game, because you're forced to think about where you're going instead of blindly following the author's cues. And in the context of the story, it also makes sense: the structure wasn't designed with Key's pleasure in mind, and the boss is using the puzzles to weed out small fry. The goal of the game isn't just to keep you constantly entertained, I'd like it to challenge you as well.
That said, I'll grant that the game has a slow start with the exploration stage. The interesting mechanics begin to be introduced after that, which is why it's unfortunate that you didn't want to keep going. I expect it could probably also use some improvement to make it less likely to go in a circle on the first try.
Yes, that's the end; because the final part of the game was thrown together at the last second, there's no real indication that the game is actually over. I thought about just kicking the player, but didn't end up implementing that.
That seems to be the case: the glass is actually a forcefield, and you're expected to turn it off, so as to free the other character. It could probably use some better hinting.
Thanks for the feedback. The formspec suggestion is interesting, I'll have to try that. For the rest, I agree that the pace needs work, since long hallways are at best an atmospheric element and more likely an annoyance. The original idea was actually to have the puzzles split not into discrete rooms, but 'regions', which in theory could make the hallways serve some further purpose than a delay, or even largely eliminate hallways in favor of wider spaces. The first cutscene was intended to have a slow start for suspense, though I may have overdone it slightly. The rest were essentially a rush job, so I mostly just strung the dialogue together with reasonable guesses for how long it would take to say (I was planning to have voice acting, but that fell through at the last minute) and worked off of that. They'll definitely be reworked later.
Where did you softlock? I know of one point (the room after the blackrod) where it's possible to trigger a minor wire update bug, but that's fixable by replacing a wire segment.
I'll grant that the game could probably use some clarification as to where to go in the first stage. However, the ambiguity is mostly intentional, as the first stage is intended to be mostly exploration-based since the player doesn't have any abilities at first. That said, the general rule is that down is further in, though it can take some perseverence to find out which doors actually lead 'down'. Eventually you'll trigger another cutscene, and from there the path gets much simpler. I doubt you softlocked yourself, because there are only two switches in the first stage, and only (at least) one of them is necessary to get to the cutscene.