I think I'd probably extend it into multiple tables for the purposes of my program, since there are several hundred 'lines'. I guess I would have a variable denoting which table I'm currently in, and have some sort of syntax in a line, say:

Code: [Select]

[5] = {"Going to next table...","jumpTableExample2"}
And then modify the table parser to recognise that line[2] is a string, and then jump to that table.

Yes, of course you should modify it to your needs. My code is really more of a concept showing how I would do it. Anyway, glad that I could help

Very strange, judging those versions I don't think it's a prototype.
If you slightly tap your device, does that do anything? (Just seeing if it could be a hardware problem with a jumper or similar)

What about something like this?

local jumpTable = {
    [1]  = {"Choose your own adventure!"},
    [2]  = {"You wake up."},
    [3]  = {"Get out of bed?", {y=4, n=11}},
    [4]  = {"You get out of bed"},
    [5]  = {"Eat some breakfast?", {y=6, n=8}},
    [6]  = {"You eat some delicious breakfast."},
    [7]  = {"You win! You ate delicious breakfast.", "END"},
    [8]  = {"You go without breakfast."},
    [9]  = {"You should always start your day with breakfast!"},
    [10] = {"You lose!", "END"},
    [11] = {"You stay in bed all day."},
    [12] = {"You lose. You shouldn't be so lazy", "END"}
   
}

local position = 1
local question = false
local input = ""

local lines = {}

function printLine(str)
    table.insert(lines, str)
end

function drawLines(gc)
    local height = platform.window:height()
    local lineHeight = 14
    local linesMax = math.floor(height / lineHeight) - 1
    local linesTotal = #lines
    local startLine = math.max(linesTotal - linesMax, 0)
    local line = startLine
    for y=1, math.min(linesMax, linesTotal)  do
        line = line + 1
        gc:drawString(lines[line] or "", 2, y * lineHeight - lineHeight, "top")
    end
end

function jump()
    local text
    local data
    local line
   
    while not data do
        line = jumpTable[position]
        text = line[1]
        data = line[2]
       
        printLine(text)
        position = position + 1
    end
   
    if type(data) == "table" then
        position = position - 1
        question = true
        printLine(">")
    end
   
    platform.window:invalidate()
end

function on.charIn(ch)
    if question then
        input = input .. ch:lower()
        lines[#lines] = ">" .. input
        platform.window:invalidate()
    end
end


function on.enterKey()
    if question then
        if input == "y" or input == "yes" then
            position = jumpTable[position][2].y
        else
            position = jumpTable[position][2].n
        end
        input = ""
        question = false
        jump()
    end
end

function on.paint(gc)
    drawLines(gc)
end

function on.construction()
    jump()
end


You got a jumpTable containing all the statements and locations where you need to jump to in case something happens. Of course you still could extend it to make other stuff happen in other cases, this is just an example.
You could also easily add something so that if you would have a line such as {123} it would jump to 123. That way you can combine join and do lot's of other fun stuff. Maybe add a stack so you can have subroutine like stuff where you put your current location on the stack, jump to another spot and then return back when finished.

Very nice work ExtendeD! I'm looking forward to seeing the stuff in the Ndless API

Looks nice!
I've made some before, it's fun indeed.

Let us analyse your code a bit to identify the problem. First let's replace bt[3] by 'myfunc' and bt[4] by 'params'.
That would give us the following code:

local fCall = assert(loadstring(myfunc.."("..params..")"))
a, b = fCall()
self:addHistoryEntry("Returned: "..tostring(a).." and "..tostring(b))

Now, what does loadstring do? Create a chunk from the given data. Basically, create a function with the contents that you pass to loadstring. So if we evaluate what actually happens, we get something like this:
function fCall()
   myfunc(params)
end

As you can see, the function will never return anything because it doesn't contain a return statement. So there is your problem

Now, about the code itself, do not use loadstring for this. It will significantly slow down your script. Rather do something like this:
local params = {}
for i = 4, #bt do
   table.insert(params, bt[i])
end
local myfunc = _G[bt[3]] -- if it's a global function that is
a, b = myfunc(unpack(params))
self:addHistoryEntry("Returned: "..tostring(a).." and "..tostring(b))

Now, this is code for the situation that you have now. If possible, just pass the function as a reference, not as a string. Then put all the parameters in a table so that you don't need to copy them in a new one. Something like this:
{data, data, functionreference, {param1, param2}}
Then you could do a, b = bt[3](unpack(bt[4]))

The TI-Nspire doesn't have any buzzer, so it must be something malfunctioning. Could you try connecting your Nspire to the batteries while it's open? Maybe you could identify the component/location where the sound is coming from.

Well, you should always try to avoid that your script throws errors to the user level (so that you need to catch it with registerErrorHandler). Of course it's not bad to implement it in case that something goes wrong unexpectedly, but still a well designed script should never actually be able to arrive to that point.