Valkyrie: Code puzzles question. Specific codes

Created on 30 Nov 2018  路  15Comments  路  Source: NPBruce/valkyrie

Description of Problem or Question

Anyone knows if it is possible to tweak a code puzzle so as to lock specific numbers instead of random ones? For example y i want the lock to be the number 666 specifically.

thanks in advance

enhancement

Most helpful comment

Hello, please see PR #976 for some code that implements this feature.
Let me know how you would like it improved, and whether you want me to write the documentation for the wiki page mentioned by @redwolf2 .

All 15 comments

I don't think this is possible yet. Still a valid request, but consider, that settings a fixed value would impact replayability. It would be nice, if this could be tied to a variable.

This wiki entry relates to the current features:

https://github.com/NPBruce/valkyrie/wiki/QuestIniPuzzle

(I will try to look into this over the next days. Will let you know if I quit.)

Hello, please see PR #976 for some code that implements this feature.
Let me know how you would like it improved, and whether you want me to write the documentation for the wiki page mentioned by @redwolf2 .

Nice, I will have a look at it tomorrow :)

If you can update the wiki, it's even better of course.

hehe I don't quite know how to edit a github wiki, but here is the text that should go below the puzzlealtlevel description:

### puzzlesolution
Pre-determined solution for a code puzzle (can only be used with code puzzles).

The input is a set of space-separated integers that specify the solution. For example, the input "1 3 4 1" specifies the solution as [1,3,4,1] for a code puzzle of level 4 with puzzlealtlevel>=4.

Hi @asn-d6 ,

a few things I've seen :

  • the solution should only be available for puzzle type code, not image
  • Error test does not check if the code is too small (this can break the puzzle while running it.)
  • if current solution is invalid, it uses the previous valid solution. This may be confusing.
    As soon as something is written, old valid solution should be deleted.
  • I think it would be easier to use without space in the solution like "0123" instead of "0 1 2 3"
    But maybe that's just me. Happy to get others opinions on this. @newusergettingnuts @redwolf2 @scrubbless

Also a more general remark, I see you are using logs for error to guide the authors.
But I'm not sure people writing scenarios are really checking this.
It's quite obvious while working in Unity as we have the logs always on, but in Valkyrie you would have to have the logs opened in a text editor, and check it manually.
So it's better to rely on a clear usage, or clear doc :)

For the wiki, I will update it when we are done with the fix.

Thanks for review! I will try to get some revisions in this following week.

(Also I managed to bork my VS installation... so I need to fix that first :-1: )

Hello, I pushed some fixups to the PR#976 that address the first three of your review comments.

WRT going from "0 1 3 2" to "0132", I can certainly do that if we think it's more usable. However, that would make it impossible to encode numbers bigger than 9, in case someone makes a puzzle with a big puzzleAltLevel. Furthermore, I think the ideal usability for this kind of thing would be to have some sort of [(),(),(),(),()] cell structure in the UI where you put numbers into the parentheses, so that the puzzleLevel becomes obvious.

Finally, I'm using logs mainly for me when I develop, I don't really assume that users are gonna see that. I left them in because maybe it will help someone in the future when they debug that feature, and because they don't seem to hurt.

Let me know what else I can do here!

I will try to find some time to test your fix tomorrow.

Regarding the space between digits, you are right, it's smarter to have a space.

To make it easier for the users, maybe you could add an example in the cell, with dark grey color, so it's clear it's not "active".
And when the user type something it's written in white.

But it's clearly not mandatory, they should RTFM ;)

I found one last problem : I was able to use 0 as a valid value for the code.

Almost good to go :)

Please see latest fixup which addresses both of your comments. Let me know how you like it.

Looks good to me :)
It is now merged.

Thank you @asn-d6 !

Fix will be available in version 2.2

Wiki is also updated

Thanks! BTW, I made fixup commits for the revisions so that you could squash them into the final commit, and it doesn't clobbber the git history. Let me know if you don't like fixup commits and I will just make regular ones next time.

Fixup commit are perfect for me.
I usually squash PR, but here I just clicked to fast, and rebased everything instead of squashing them :/

Was this page helpful?
0 / 5 - 0 ratings