Hi!
I am building a puzzle module for a fake bomb puzzle, but I need some guidance to how to achieve a sequence-check. My plan is to have 8 wires connected from digital inputs to gnd, with pullup. The sequence I want to check is that they should be disconnected in order, 1 to 8. The variation will be hardwired into the actual user panel, so no need for advanced patterns.
My problem is that I am shit at programming, and I am looking at a ton of nested ifs, which is no good. There will be a timer and a countdown factor going as well, so I can't bind up a million cycles in ifs and checks. I am pondering using an array, and reading the inputs into the array and then checking the array..but...I dunno. Anyone got any good ideas? I also want to disable the input once it's cut/removed, so you can't replace the wire.
My pseudo is something like:
Checkwirestate() - where CountFactor is updated depending on state/order cut, not settled yet
Blinkled() - blink warning led based on Countfactor, or just update the timer-display, not settled yet
So, any creative order-ideas?
At start only one wire should out of 8 be cut. Cutting the wrong wire, game over. Next step, one wire out of 7 should be cut.
Define an array of 8 elements containing the wires supposed to be cut. Example: 8,2,3,6,4,5,1,7.
First cut must be at index 0, If the right wire is cut, advance the index pointer one step. Check for the wire number beiung cut.
Reading the status of the wires before every step, excluding wires being correctly cut, using the index pointer, excluding wire 8 at the second cut, excluding wire 2 at the third cut…
Any help?
Ooooh, yes, that is good! Does it make it easier, or change the code requirements if the order, as mentioned, is ALWAYS 1,2,3,4,5,6,7,8 ? The visible wires on the panel will be in a different order, and an external puzzle will tell you which one to cut/remove. So, the player will remove, 8,2,3,6,4,5,1,7, which will ALWAYS be wired to the arduino in 1,2,3,4,5,6,7,8 order.
Yes, sure! Go for that! Then You can drop the array. Just read and check from input 1 to input 8.
I thought about a software controlled order but using a breadboard arrangement, like a switch board, is maybe more convienient.
Hmmm, I still need to handle that if any other wire is removed, bad things happen. So, an "easy" way to check might be to have an array of 1,2,3,4,5,6,7,8 and read the state of the wires according to the array anyways. If anything else than the first value is cut, that value is removed from the table, won't be checked anymore, and the badthings variable is updated with +1. If the lowest value is cut, i.e. gone HIGH (pullup), that value is removed and badthings stay still. Does that make sense?
Rub Your hair for a short while and write a "button check function" that returns the button number being pressed.
Then 8 steps of simple code does the rest. Maybe even a "for-loop", from 1 to 8, would do.
Head not really working at 1 am 
But I have two working loops which reads the state of wires and updates the list of active wires. The removed wires are no longer updated and can't be reconnected. I am probably over-coding this, but I am struggling with solving how to check if it's only the correct wire which has been removed. But I will ponder this in the morning 
And yes, I can probably do this whole thing in one loop.
int wirepins[] = {2, 3, 4, 5, 6, 7, 8, 9};
int wirestate[] = {0, 0, 0, 0, 0, 0, 0, 0};
// go through list of active wires and read state into wirestate array if the pin is not 0,
// thus ignoring previous cut wires.
// already cut wires can not be reconnected and change the state
for (byte i = 0; i < 8; i = i + 1) {
if(wirepins[i ]>0){ wirestate[i ]=digitalRead(wirepins[i ]);
}
}
// remove cut cables from pinlist by setting pinnumber to 0 in the respective positions
for (byte i = 0; i < 8; i = i + 1) {
if (wirepins[i ]>0){if (wirestate[i ] == 1) {wirepins[i ] = 0;}
}
}
By serial-printing the results, I can see that this works. Not sure if it helps me achieve my goal, but at least it works 
if(wirepins>0){ wirestate=digitalRead(wirepins);
Why not this
for i = 2; i<10; i++// input pins are 2 …. 9
wirestate=digitalRead(wirepins[i]);
Yes, it's late here as well. Hear from You "tomorrow".
Hmmm, yes, it can be compressed into that, but I use the wirepins-array to keep track of which cables are still active, so they can be ignored next time, to keep them from changing the state of result by re-connecting them.
I guess I could probably compress it by reading the state of all 8 wires into an array and use different code to verify that the first wire removed is pin 2 and ONLY pin 2. THEN pin 3...THEN pin 4 etc. The challenge lies in keeping track of what's cut and not, and how that affects the status of the bomb. Keeping track like I do now is working, and keeps track of wires removed and makes it impossible to reconnect them.
I just need to work out the order... 
Tomorrow.
Don't think about compressing the coda until it works and You know what You are doing. Sloppy, but working code is worth a lot more than smart and faulty code!
If the wrong wire is cut,game is over I guess. When the right wire is cut, the first one, You don't need to bother about that input the next time. Send the for loop index as a parameter to the function like check-wires(i) and let check-wires work from the parameter up to 9.
Ah, see, the game is not over
if you cut the wrong wire, the timer runs faster. Cutting the correct wire, in sequence, keeps the timer going in the same speed. Only when the timer hits zero, does the bomb go off. Hence I need to keep track of which wires have been cut, and ignoring them, AS WELL as check sequence.
This also means I need to check that the next in the sequence is cut and ONLY that, pr check.
I have something semi-functional, but it's way too complicated and non-robust yet, as I can yank out all cables at once and it reports success. 
Don't bother about the timer. Make sure Your code works well without timing aspects. Then You can add the time constrain later I think.
Oh yes, absolutely, that's what I am doing. The timer is a separate thing, I am not worried about that yet, right now I need to get the wire-handling done properly, which will feed a speed-factor into the timer process, easy peasy. 
Oh, and I need to keep track of the number of wrong wires cut pr round as well. Exciting times. Zzzz... 
Another approach is to wire all 8 into one port and do a port read.
Still use a array of values such as [255,127,63,31,15,7,3,1]
Now when you read the port, if all 8 wires are still connected you will get 255.
When there is a change in the read value compared to the array value, increment the array and compare again. If the values now match then they cut the correct wire, test to see if your at the end of the array and unlock.
The Uno has no ports with 8 bits open if you use RX/TX for Serial.
I would use bits but that's now for raw beginners.
Finchnixer, your game starts with countdown running and no wires cut (could just pull jumpers from a header or flip DIP switches?) then changes with each wire cut.
In void loop() you could set the countdown timer as one piece of code that always runs until zero when it's boom time. How fast it runs should be able to change by other code in void loop(). Making the timer stop is the game win.
In void loop() you can detect cut wires and change timer speed to fast or stop.
I will pretend that the trigger to start the bomb is the last part of void setup().
void loop()
{
countDown();
cutWires();
}
What to get here is that you can have different pieces of code that "run together" as long as both run fast, a practical form of parallel processing.
The process after trigger starts with no wires cut and changes as wires are cut but it's not linear, the "right" wire may not get cut -but- the process state stays until the right wire is cut and then it moves to the next unless the counter runs out.
Process states could be how many wires are cut. 0 is for none, when the state is zero, what wire should be cut? Same for the rest, you check the rest to see if the timer should run fast but only the right wire cut lets the process state change.
And you get a machine that does what's needed, it can take less code than a checklist sketch.
Sweet, I think I get your point...kinda. I will try to actually implement this in code. Thank you for all inputs! 