Even if Drathora doesn't want this, I would be interested, if you have the time/inclination.
Thanks.
Even if I don't want this? I think you are confusing me with Dymdez.
Yes, I would be very interested in an updated version and would be willing to help in any way I can (I was thinking about editing the graphics to include instructions to help the user understand how to operate the mini-game)
Also, some other ideas include
1) displaying the percentage that the "force lock open" function has at that specific instance
2) being able to control difficulty not just in how fast the pins move but also by reducing the space that qualifies a "successful pick" (currently it is too easy and the user can get a successful lockpick without really having the pins close to the top)
Lastly, the only "bug" I was able to find is that the event sometimes does not register input 20% of the time for the first time the : C key is hit (try the demo a few times on "epic" and youll see it will fail to register a key input every now and then). Edit: Actually, it occurs less than 20% of the time, around 5% of the time, but I can tell it's just some latency in when the event is looking for input, it's hard to describe, though :/
Feel free to respond here or PM me if you want to work on this! I don't have scripting knowledge (even the common event is difficult for me to comprehend) but my brother codes in ruby professionally and I can forward any questions to him (or even just other members of this forum, who are quite good, in fact).
Looking forward to it.
If you want to redo the graphics feel free to do so. I had thought about doing it when I was making the original edit but I rather liked Maker Victors graphics as it looks very modern. As for your ideas I would like to show the percent chance to force the lock but I need to figure out how to display and clear text outside of a textbox and without adding a new script. As for the difficulty I had said that my original plan was to use basic trigonometry to better control the speed and in doing so I would free up the space to give better control over sensitivity of pin location. The bug you are experiencing is probably 1.66%-3.33% of the time, you are probably pressing the button at the same time the event is calling for a wait of one frame. I don't think it is possible to fix this without crashing the game as everything (as far as I know) is dependent upon frames. I might be able to move the call to wait to reduce the percent of the time that is experienced but it will probably always exist. Finally, I don't think I would need any help with the coding, I just need to find a good function dictionary as well as a better understanding of what is and is not allowed to be called by the in-event scripts.
Anyways, I have successfully found a way to cut the length of the event and the amount of scripting in half and add better control to speed of pin movement I am currently working on a way to lower the events dependencies on $game_variables so that people don't have to edit it too much to get around issues with the variables already being in use. I will keep you guys updated as I get closer to a working demo. The things are I am currently changing are as follows:
1. More difficulty settings, which not only change the number of pins but also the speed of the pins movement and the sensitivity of the pin locations.
2. Item requirements to even attempt to pick the lock.
3. Item requirements to bypass the lock picking minigame (i.e. if you have a key you don't need to pick the lock)
4. Penalties for failing the minigame.
5. Fewer, preferably no, dependencies on $game_variables.
6. More options for flipping switches (so that locks can be permanently unlocked without needing extra pages in the door/chest/whatever event).
7. If I can manage to display text on screen outside of a textbox and without a new script I will give an optional display of chance to force the lock.
If anyone has any additional ideas let me know, I will take any ideas into consideration.