Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

So here's the stackoverflow bug I keep getting. It came up again twice with the new build you uploaded.

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.

(2 edits)

I actually figured out other wway to do it manually:

quitloop=false

Repeat

n=n+1 if haveitem(Table, n) then...

until quitloop=true

I have uploaded another exes for you which use this system. So if listitems() command is the cause of problem, then that is there no more.

Those exes are burnerknightwin32-2 and win64-2

however, if you dont mind, you could first try the other version just so that in case the other version with tableitems instead of listitems works fine, then it is a sure thing there is some bug in that ListItems() command in hollywood language itself that gets triggered in your computer for some reason. although basically i suppose if there is a bug, then that same bug will happen in both those commands, since they are anyway quite similar.