[SOLVED] Bizarre nil issue

[milon]

SUMMARY
A variable which I've just successfully concatenated in a string gets copied to another variable, and decides to be nil instead

DETAILS
I have absolutely no idea why this is happening. I can't figure out a reproducer subset of code, so I'm attaching the whole .love file. When the maze builder hits a dead end it will backtrack to the previous node and look for other possible routes. When all routes are exhausted, it will backtrack to the very beginning and the maze building is done. Note that you need to look at the console output to actually see the error. In file maze.lua, line 74 is where y is assigned to the vertical backtrack co-ord. I can use the stored y0 (at notes[x][y].y0) in a string function before copying it into y, so it's fine there. But after setting y, it has a seemingly random chance of being nil instead. This seems to only happen on the very last backtrack step of a completed maze. (Yes, I could code around this, but it's a bug and I hate bugs! )

There's a second bug which seems to be unrelated, but occasionally the backtrack goes back 2 steps instead of 1. This rarely means part of the maze doesn't get dug out. I'd like to solve this issue too, but I'm primarily focused on the strange nil issue above.

Can anyone else reproduce this? Any idea why it's happening?

[BrotSagtMist]

Firstoff, for debug reasons you should use math.random instead love.math.random.
That makes debugging predictable.

Ok look at your code:
x = notes[x][y].x0
y = notes[x][y].y0
You are changing x then try to access the table with the CHANGED x. So your y is something completely different than in the debug backtrack.

[grump]

Firstoff, for debug reasons you should use math.random instead love.math.random.
That makes debugging predictable.

Why? Elaborate please?

[monolifed]

Code: Select all

x = notes[x][y].x0 -- x is never affected by this bug...
y = notes[x][y].y0 -- somehow this can set y to nil even though I've just shown a non-nil value for y0...

first statement sets x to notes[x][y].x0
but the second sets y to notes[notes[x][y].x0][y].y0 Not notes[x][y].y0

You can do

Code: Select all

x, y = notes[x][y].x0, notes[x][y].y0

[milon]

Firstoff, for debug reasons you should use math.random instead love.math.random.
That makes debugging predictable.

Ok look at your code:
x = notes[x][y].x0
y = notes[x][y].y0
You are changing x then try to access the table with the CHANGED x. So your y is something completely different than in the debug backtrack.

Bwa ha ha! Yup, I did that. Good catch! How in the world did it ever work at all? o_O

For anyone who cares, my fix is to combine the two lines into one:

Code: Select all

x, y = notes[x][y].x0, notes[x][y].y0

Both x0 and y0 get evaluated together and assigned together, so no index-monkeying occurs.

EDIT - This also fixes the second bug.

Firstoff, for debug reasons you should use math.random instead love.math.random.
That makes debugging predictable.

Why? Elaborate please?

I think because love.math.random is seeded with the OS timer to make it more random, and lua's basic math.random always has the same seed unless you give it a different one.

[grump]

I think because love.math.random is seeded with the OS timer to make it more random, and lua's basic math.random always has the same seed unless you give it a different one.

math.random is platform-dependent and can/will produce different numbers on different platforms, even with the same seed.

If you want a reproducible, platform-independent sequence of random numbers, use LÖVE's RNG with a fixed seed.

https://love2d.org/wiki/love.math.setRandomSeed or https://love2d.org/wiki/love.math.newRandomGenerator

[milon]

That's true, I'd forgotten that. I knew there was a reason I was using Love's version.

[BrotSagtMist]

It is yet not clear if there are actually differences between platforms, i have not seen them in the wild so far. It is only that there is no guarantee that it is the same. And on further downsides, loves version is a slight tick slower then luajits function.
In terms of map creation if we write math.randomseed(1) before a generation this will always create the same level and we can therefore say: There is a bug in level 1 instead of "sometimes it bugs".

Personally i use math.randomseed(love.math.random()) which gives the best of booth.

[grump]

It is yet not clear if there are actually differences between platforms, i have not seen them in the wild so far.

It is clear though, because different implementations of the C runtime library use different implementations of PRNGs.

It is only that there is no guarantee that it is the same.

love.math.random guarantees it.

And on further downsides, loves version is a slight tick slower then luajits function.

True, but also almost irrelevant unless you have to generate hundreds of millions of numbers per second.

In terms of map creation if we write math.randomseed(1) before a generation this will always create the same level

Only on the same platform and with the same runtime version, while love.math.random always produces the same sequence on all platforms.

Edit: I just remembered that LuaJIT has a different PRNG than vanilla Lua with more guarantees, so the point about platform independence might be moot

[BrotSagtMist]

I challenge you to find me a platform where the results differ then.