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.
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.