PapaRubby wrote:I don't know why, but 5 of my pictures on imgur disappeared, here are the new codes :
"768" : "bCeM9MU",
"772" : "JNyJdtB",
"777" : "QQFpAxM",
"827" : "FebTfim",
"831" : "cQsowng"
Probably because imgur.com requires you to "complete" the upload post and at least once retrieve the uploaded image. Fixed.
Lone_Wolf wrote:Players shouldn't need to use a notepad, screenshot tool, or calculator throughout the entire box
I disagree. Puzzles that are so hard that you need to take notes are fun.
The real problem is boxes where you just have to search for randomly hidden stuff.
There's an audience for both types of puzzles, which is why I'm allowing a wide range of "find the button" type of boxes as well as a wide range of "all the clues are there, you just need to figure them out" as well.
The mix is what makes this experiment so interesting. We're looking at hundreds of hours of game play already right now, with something for everyone. Lots of players don't play more than 20% of the available boxes - they get something out of it too, so we want to keep the quality up but leave it in the middle to specifically promote types of boxes.
PapaRubby wrote:I don't know why, but 5 of my pictures on imgur disappeared, here are the new codes :
"768" : "bCeM9MU",
"772" : "JNyJdtB",
"777" : "QQFpAxM",
"827" : "FebTfim",
"831" : "cQsowng"
Probably because imgur.com requires you to "complete" the upload post and at least once retrieve the uploaded image. Fixed.
I'm going to add another requirement to the screenshot rules, because you posted one that is from an "impossible" player viewpoint, and I would like to avoid that, entirely. It's both a major spoiler, and it doesn't look good in many cases (in this case, I don't feel it looks good, at all).
- screenshots must be made from a view point that the player can reach. IOW, you can't fly to a far corner up in the air to make a capture. If you don't know what this means, go into the box in *play* mode instead of *edit* mode and take the screenshot while test-playing the box.
sofar wrote:
- screenshots must be made from a view point that the player can reach. IOW, you can't fly to a far corner up in the air to make a capture. If you don't know what this means, go into the box in *play* mode instead of *edit* mode and take the screenshot while test-playing the box.
Hey there !
If you need some walkthrough boxes, you can check my new channel on You Tube : PapaRubby
And if you need one that is not on the list, just ask for it !
PapaRubby wrote:Hey there !
If you need some walkthrough boxes, you can check my new channel on You Tube : PapaRubby
And if you need one that is not on the list, just ask for it !
hey, nice to see people solving my boxes! Did you really finish Stairways and Confusion with those jumps or just for the speedrun? most of them were not suposed to be possible!
Kurtzmusch wrote:hey, nice to see people solving my boxes! Did you really finish Stairways and Confusion with those jumps or just for the speedrun? most of them were not suposed to be possible!
For the speedrun, i've only put the right answer and went out and it took me 1'40". I thought the good way to finish it was those hard jumps on stairs, did i miss something ?
I'd like to understand some little things about the ranking system. I looked at the ranking code and didn't find answers :
- If a player often leaves a box before or after completing it, does it changes the box/builder/player rank ?
- How is it possible for a player to upgrade in the ranking without playing ? i mean, i was in 2nd position when i stopped to play, after some time, the 3rd one took the 2nd place an a few time later (days ?), without playing, i get back to the 2nd position. Does this mean a player can loose points when playing ?
- If a player often leaves a box before or after completing it, does it changes the box/builder/player rank ?
It does not. Indirectly, it affects total number of players completing the box (since, it will be lower) and therefore boxes that are not getting completed will rank lower than boxes that are getting completed. This is needed to discourage people from making boxes that are too difficult.
- How is it possible for a player to upgrade in the ranking without playing ? i mean, i was in 2nd position when i stopped to play, after some time, the 3rd one took the 2nd place an a few time later (days ?), without playing, i get back to the 2nd position. Does this mean a player can loose points when playing ?
Your rank is relative. Actions of others can affect your rank. If others play "badly", they will lose ranks compared to players that did not play.
Could the "reveal tool" be added to a players inventory when they play a box they've built and something like a "signal tool" that outputs a mech signal when hit against a node. This would make play testing mech boxes a lot nicer and easier to identify the problem with mechs if a problem does occur while play testing.
The "reveal tool" will allow you to check the information of the mechs.
The "signal tool" will allow you to break non-mech nodes to get to the mechs. It will also be able to recreate scenarios which a randomiser could create.
Could the "reveal tool" be added to a players inventory when they play a box they've built and something like a "signal tool" that outputs a mech signal when hit against a node. This would make play testing mech boxes a lot nicer and easier to identify the problem with mechs if a problem does occur while play testing.
The "reveal tool" will allow you to check the information of the mechs.
The "signal tool" will allow you to break non-mech nodes to get to the mechs. It will also be able to recreate scenarios which a randomiser could create.
I agree that it's useful. However, it does give a problem. We've recently changed the submit system to require that the box is playtested first. We can't have people playtest boxes with a "cheat" tool since it would allow them to bypass this important QA step. Having the tool to send a trigger is certainly useful, and I think we should definitely add it for the creative inventory. But I'm not so sure how I would make sure that playtesting doesn't inadvertently turn into bypassing the testing requirement.
I retracted my box in the review queue, made some edits and re-submitted my box. I did playtest it but I never completed my box after I made the edits.
I retracted my box in the review queue, made some edits and re-submitted my box. I did playtest it but I never completed my box after I made the edits.
Interesting, the playtest bit should get reset after edits... I'll have to check the code XD
if bmeta.meta.tested then
-- reset tested flag if significant edits were made
if t - box.start_edit_time > 150 then
bmeta.meta.tested = 0
end
end
Seems like I had the common sense to allow builders who have previously tested their box, and who only made quick edits (low additional edit time used) to omit having to retest their boxes.
2020-09-29 18:00:16: ERROR[Main]:...t-5.3.0-win64\bin\..\games\insidethebox\mods\db\init.lua:59: add the "db" mode to secure.trusted_mods in minetest.conf
2020-09-29 18:00:16: ERROR[Main]: stack traceback:
2020-09-29 18:00:16: ERROR[Main]: [C]: in function 'assert'
2020-09-29 18:00:16: ERROR[Main]: ...t-5.3.0-win64\bin\..\games\insidethebox\mods\db\init.lua:59: in main chunk
2020-09-29 18:00:16: ERROR[Main]: Check debug.txt for details.
2020-09-29 18:00:16: ACTION[Main]: Server: Shutting down
2020-09-29 18:04:44: ERROR[Main]: mod "boxes" has unsatisfied dependencies: "music"
2020-09-29 18:04:44: ERROR[Main]: mod "creative" has unsatisfied dependencies: "boxes"
2020-09-29 18:04:44: ERROR[Main]: mod "doors" has unsatisfied dependencies: "mech"
2020-09-29 18:04:44: ERROR[Main]: mod "inspector" has unsatisfied dependencies: "boxes"
2020-09-29 18:04:44: ERROR[Main]: mod "irc_whereis" has unsatisfied dependencies: "boxes"
2020-09-29 18:04:44: ERROR[Main]: mod "mech" has unsatisfied dependencies: "boxes"
2020-09-29 18:04:44: ERROR[Main]: mod "menu" has unsatisfied dependencies: "boxes" "music"
2020-09-29 18:04:44: ERROR[Main]: mod "music" has unsatisfied dependencies: "localmusic"
2020-09-29 18:04:44: ERROR[Main]: mod "nodes" has unsatisfied dependencies: "mech"
2020-09-29 18:04:44: ERROR[Main]: mod "player" has unsatisfied dependencies: "menu"
2020-09-29 18:04:44: ERROR[Main]: mod "signs" has unsatisfied dependencies: "boxes"
2020-09-29 18:04:44: ERROR[Main]: mod "terminal" has unsatisfied dependencies: "mech"
2020-09-29 18:04:44: ERROR[Main]: mod "tools" has unsatisfied dependencies: "nodes"
2020-09-29 18:04:44: ERROR[Main]: mod "torches" has unsatisfied dependencies: "nodes"
2020-09-29 18:04:44: ERROR[Main]: mod "xpanes" has unsatisfied dependencies: "nodes"
2020-09-29 18:04:44: ERROR[Main]: ...t-5.3.0-win64\bin\..\games\insidethebox\mods\db\init.lua:59: add the "db" mode to secure.trusted_mods in minetest.conf
2020-09-29 18:04:44: ERROR[Main]: stack traceback:
2020-09-29 18:04:44: ERROR[Main]: [C]: in function 'assert'
2020-09-29 18:04:44: ERROR[Main]: ...t-5.3.0-win64\bin\..\games\insidethebox\mods\db\init.lua:59: in main chunk
2020-09-29 18:04:44: ERROR[Main]: Check debug.txt for details.
2020-09-29 18:04:44: ACTION[Main]: Server: Shutting down
I think mod security is blocking the mod named db (first error line). Other line are just domino effect because db is blocked.
You need to add it in trusted mods. Open minetest.conf and add this line:
I had a look at the server ranking code and I don't like how death effects box ranking. death is directly tied to damage. The more a player dies the more damage they take(death from full health is 20 damage). Damage also effects box ranking. If you look at the top 25 ranked boxes you'll notice that almost all of them involve a way for a player to be killed, mostly lava. box 125: "Terminal Trouble" even has 2 traps that kills the player when triggered that if they weren't included there wouldn't be a way for a player to die.
Death also effects box solve time (solve time effects box ranking). When a player dies they are sent to the start of the box. In most cases* this will increase the box solve time as they will have to redo parts of the box. This is most prevalent in parkour across lava. The server not having default physics will make new players more likely to make mistakes on early boxes involving parkour as they get used to physics.
Overall I find the inclusion of death to the box rankings to be a massive disadvantage to boxes that focus more on the puzzle element than parkour/adventure. The idea that box 281: "Projector" which I consider a good box would of had a significantly higher box ranking if the projector floor was lava doesn't sit well with me. There is also box 225: "Colors" which is a pure puzzle box based on a unique puzzle idea but has a lower box ranking then I think it should since there is no way to get damaged/killed. The removal of death from box ranking will give a more fair chance for puzzle focused boxes to do well in the rankings.
Hi! Just wanted to say. Played through the tutorial. Absolutely great, very atmospheric, superb soundtrack! Reminded me of the first Half Life and the Cube movie. Probably the first time I felt not relaxed/uncomfortable/not in control/isolated while playing Minetest. Was feeling like I might not get out of this place, especially while walking along the dark corridors below in part 8.
I was researching commands in the basement terminal in the first part of tutorial and then some fast music kicked in and I'm like "what?! a boss?! there shouldn't be any bosses in this game", but quit the terminal and looked around just to be sure. So yeah, pretty real thing.
Maybe the dark hopeless tone should be mentioned in the server description. Now it's just "A puzzle server", but what I experienced was far from that, felt more like survival in some very strange circumstances.
And the Nexus block is very cool and mysterious. I stumbled upon this server by accident while reading about mtmediasrv and googling foo-projects.org. Nexus is what caught my attention and led me to play.
v-rob wrote:I think terminals should also be able to send trigger and untrigger signals, probably with the commands "trigger" and "untrigger."
They actually already send a trigger. The trigger is sent when the player opens the terminal interface.
I don't actually want normal boxes to use this feature. It is meant to be used by the tutorial series only. Any sort of box scripting in normal boxes shouldn't use this feature, because it relies too much on forcing the player to click terminals. In the tutorial however this makes sense, since there is an (unfinished) storyline that can be followed through the terminal (replay value/easter egg/RP element).
did you finish the storyline yet and is the tutorial related in any way with the main island
If my post says something, it is a opinion and not fact unless i say something