That was very good you gave me the error, it shows exactly where in code the error happened.
It is very strange it does that for you. I found out about that stackoverflow and it is based basically upon recursive calls. This could easily happen in my tables, because Hollywood is very flexible when it comes to tables, so i could for example have:
T_Table = { savedtable = CopyTable(T_Table)}
This would result in T_Tables item called "savedtable" to be having a copy of itself, which would in practice result in endless recursive calls i suppose, as the copy of that table would be having the copy of that table and that copy would once again have copy of itself till it crashes due to some sort of memory running out (stackoverflow).
However, in this specific place, I dont understand how it could happen, since that table doesnt have any tables inside it, only clear things like text="sometext", or amount=number.
Hence I am suspecting it is the ListItems() command that for some reason bugs in your computer, unless it does it on others computers too.
This ListItems command is very simple as well. It is simply listing how many items there are:
Table = {"item1", "item2", "item3}
number = Listitems(table)
print number
and i should get 3 printed on screen. Hence it is very strange it woudl result in stack overflow in this case.
I have now uploaded you another exe there, burnerknight.exe, replace it with the current exe and see if that fixes it. I am suspecting this fix might not fix anything, but I am hoping it does, since the next fix which actually should fix that problem, is something that is easy to cause a bug at some point.
This fix is another command doing almost same. This is called TableItems(), it does same as ListItems, except with ListItems, items need to be in order, for example:
Table = {[0]="a", [1]="b", [3]="c", [4]="d"}
with listitems, this table would result in 2, as it would stop counting at [1], since there is no [2], while TableItems would correctly see there are 4 items.
In my code the T_Table is bit like this:
T_Code = {Currentline = 1, [0] = "a", [1] = "b", [2] = "c"}
therefore the listitems was better, as it ignores all those "Currentline" items and only calculates the [n]s to the result, with TableItems I have to take into consideration that if i add any other variables than those [n]s, like this "Currentline", i need to remember they will show up in the result too.
So lets see if this works, if it doesnt, then I will next make manual account of how many lines there are, in which case i can use FOR-NEXT statement:
For n = 0 to T_Code.Totalnumberofcodelines
do stuff
next
This should be a sure fix, but what worries me is if I am able to catch every case when that totalnumberoflines should be increased or decreased.