Key Control Trouble

[Kafuuka]

Since I started my first clicky based quest, two people have encountered a weird bug. Instead of getting the key which the script gives them at the start, they immediately get the last key, which allows them to see the list of people who started/finished the quest, but not actually do the quest. They're also not listed in said list, because the list is based on a stored variable, not on keys. I managed to write a small script that takes away the troublesome key from affected people, after which they try to start the quest again, with the standard quest procedure and then they do seem to get the right key and get added to the list.

Which makes this bug non reproducible, and a pain to figure out what went wrong. Furthermore the quest will be running for another month so I can't just post all the code here, but have to give a censored version...
[code]
@vz = "prefix"; //yes i changed this, no i'm not telling what it looks like
@vs = mds_storage("TBOT","aoau"); //get the id of the storage
if(@storage[@vs] == null)@storage[@vs] = array(); //initialize storage array

if(mds_has_rpcq_keys(@vz . "TBOT")){ //check whether users finished the quest -> scores
foreach(@storage[@vs] as @temp)
echo @temp['name'] . ' finished on ' . @temp['end'] . '<br />';
}

else if (mds_has_rpcq_keys(@vz . "TBOT_2")) { //check whether users is at stage 2 -> print 'error'
echo @content[2];
}

else if (mds_has_rpcq_keys(@vz . "TBOT_1")) { //check whether users is at stage 1 -> execute
censored... (1);
}

else if (isset(@input['turn'])) { //check for new users -> execute & initialize
@temp = array( 'name' => uv('name'), censored...);
@storage[@vs][uv('id')] = @temp;
mds_give_rpcq_keys(@vz . "TBOT_1");

censored... (copy of (1));
}

else //else print sign up button
echo @content[1];
[/code]

Content (first parts)
[code]<!-- content separator -->
Time. <br />
Censored<br />
<form method="post" action=""><br />
<input type="submit" name="turn" value="Turn the page"/>
</form>
<!-- content separator -->
This page is <b>currently</b> blank.
<!-- content separator -->[/code]

What should happen and does in 99% of the cases: people start without keys and end up in the 'else' part. They push the button 'turn', then the clicky refreshes and they get in the 3rd option, upon which they receive key TBOT_1 (+prefix), and get added to the list of questers.
What happens 1% of the time: people do not get added to the list of questers and sometimes get key TBOT (+prefix).

Possible reasons:
1. they had the endkey before accessing the script... unless Mur used that combination of prefix and key for something else and since i know what prefix i used, that it is extremely unlikely.
2. A lot of things in MD expire when the hour changes, perhaps this interferes with MD script? It seems unlikely for it to cut off exactly '_1' from the string, and also doesn't explain why the player wasn't added to the quester list.
3. The problem lies in a further part of the quest. That's nigh impossible, the people experiencing the problem mentioned they got stuck at the very beginning; all further scripts require other words to be activated, they never remove someone from the quester list and they all check if the previous key is on the user. Furthermore I explicitly put the remove key statements after the give key statements to be certain that nobody would get stuck if a scripts is aborted halfway...

Note that I tested the quest with several alts to see if I was able to go to the next phase and never encountered problems. Furthermore one person, [b]who shall remain anonymous for obvious reasons[/b], already managed to solve it.

Final note: the problem certainly can be circumvented, but if it is not my fault, then it implies that a lot more 'rogue keys' are in existence. Maybe any partial string is sometimes given as key instead of the full string but this is the first case in which a sub-string is actually a 'used' key.

[Rendril]

I somehow doubt it, but do you have a comma in your prefix?
Multiple keys are sent through as a comma seperated string not as individual variables.

[Kafuuka]

No comma's, but it does have an underscore _. It's also quite long, but it does work for most people. And for the ones who get the bug they don't reproduce it after I take away the troublesome key, so length can't be the issue either.

[Rendril]

Is this the only code that gives/reads the keys?
I don't see any logic error in the code, are you sure that you are not reusing @vz elsewhere and thereby overriding your key prefix or that some other clickable doesn't accidentally give the wrong key?

[Kafuuka]

[quote name='Rendril' date='21 July 2010 - 07:42 PM' timestamp='1279734127' post='64309']
Is this the only code that gives/reads the keys?
I don't see any logic error in the code, are you sure that you are not reusing @vz elsewhere and thereby overriding your key prefix or that some other clickable doesn't accidentally give the wrong key?
[/quote]
There are two other scripts that give/read keys, but they are hidden behind long passwords AND they all check if the previous key is held. Furthermore all code segments that give a key also change things to the storage, so they should either result in errors or leave traces in the storage, which remains empty for those affected. The basic structure of the other scripts is:
[code]
if(mds_has_rpcq_keys(@vz . "TBOT_1")){
@temp = @storage[@vs];
@temp[uv('id')][x] = y;
@storage[@vs] = @temp;
mds_give_rpcq_keys(@vz . "TBOT_2");
mds_take_rpcq_keys(@vz . "TBOT_1");

echo @content[1];
}
[/code]
So a player would need the right words, the right key, and then first the storage would be updated, second the new key would be given and only afterwards the old key deleted. They would also see the next riddle. Instead they tell me they never see the actual quest, only the sign up button and blank pages or a list of scores.

In all scripts @vz is exclusively used for the prefix, and even if it weren't, I don't see how it could lead to people getting a wrong second part of the key.

[Chewett]

i dont see why you are trying to debug something that is non reproducible. If you could make it happen on cue, or could identify a pattern between the people i might understand. But it doesnt seem like there is anything inherently wrong with the code.