This does suggest a really horrible workaround... if nothing else is wrong, we could just detect values outside of the acceptable range, and switch them to LUA_YIELD
I'll give that a try. Do you think this would work?
if (Lres == LUA_YIELD)return SCRIPT_RUN_RUNNING; //yielded
//print Lres and message here
if ((Lres >5)||(Lres<0))return SCRIPT_RUN_RUNNING; //TESTING
No. I would do this in lua_resume()
status = luaD_rawrunprotected(L, resume, L->top - nargs);
+ if(status > 5) // LUA_ERRERR
+ status = 0
You might also want to add a console log or something so you know it happened and whether the script continued to run after that. Note that this is *not* a fix, even if it appears to work, it is terribly wrong and could have other unforeseen consequences down the road. But whether it "works" or not might give us some clue about the nature of the problem.
Do you think this info in asmsafe.h is relevant?
Off the top of my head, I think it's unlikely:
1) capt_seq_hook_set_nr happens in the capt_seq task, not the kbd task. Even if it was hosing kbd_task, it's hard to see it always causing this exact symptom
2) capt_seq_hook_set_nr is generally set up safely (for most ports), adding additional function calls is probably OK.
If you are making any lua calls in shot_histogram_shot_delay(), that would be a Bad Thing. Don't do that.
edit:
I messed this up originally. Status should be set to 0, because it's only used as the return status if it's non-zero. LUA_YIELD is set later from L->status if applicable.