[SOLVED] Bizarre nil issue

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
milon
Party member
Posts: 472
Joined: Thu Jan 18, 2018 9:14 pm

[SOLVED] Bizarre nil issue

Post by 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! :halloween: )

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?
Attachments
maze.love
(2.57 KiB) Downloaded 248 times
Last edited by milon on Wed Sep 22, 2021 2:27 pm, edited 1 time in total.
Any code samples/ideas by me should be considered Public Domain (no attribution needed) license unless otherwise stated.
User avatar
BrotSagtMist
Party member
Posts: 659
Joined: Fri Aug 06, 2021 10:30 pm

Re: Bizarre nil issue

Post by 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.
obey
grump
Party member
Posts: 947
Joined: Sat Jul 22, 2017 7:43 pm

Re: Bizarre nil issue

Post by grump »

BrotSagtMist wrote: Thu Sep 16, 2021 7:30 pm Firstoff, for debug reasons you should use math.random instead love.math.random.
That makes debugging predictable.
Why? Elaborate please?
monolifed
Party member
Posts: 188
Joined: Sat Feb 06, 2016 9:42 pm

Re: Bizarre nil issue

Post by 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
Last edited by monolifed on Thu Sep 16, 2021 7:48 pm, edited 1 time in total.
User avatar
milon
Party member
Posts: 472
Joined: Thu Jan 18, 2018 9:14 pm

Re: Bizarre nil issue

Post by milon »

BrotSagtMist wrote: Thu Sep 16, 2021 7:30 pm 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.

grump wrote: Thu Sep 16, 2021 7:41 pm
BrotSagtMist wrote: Thu Sep 16, 2021 7:30 pm 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.
Last edited by milon on Thu Sep 16, 2021 8:05 pm, edited 1 time in total.
Any code samples/ideas by me should be considered Public Domain (no attribution needed) license unless otherwise stated.
grump
Party member
Posts: 947
Joined: Sat Jul 22, 2017 7:43 pm

Re: Bizarre nil issue

Post by grump »

milon wrote: Thu Sep 16, 2021 7:47 pm 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
User avatar
milon
Party member
Posts: 472
Joined: Thu Jan 18, 2018 9:14 pm

Re: Bizarre nil issue

Post by milon »

That's true, I'd forgotten that. I knew there was a reason I was using Love's version. :D
Any code samples/ideas by me should be considered Public Domain (no attribution needed) license unless otherwise stated.
User avatar
BrotSagtMist
Party member
Posts: 659
Joined: Fri Aug 06, 2021 10:30 pm

Re: Bizarre nil issue

Post by 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.
obey
grump
Party member
Posts: 947
Joined: Sat Jul 22, 2017 7:43 pm

Re: Bizarre nil issue

Post by grump »

BrotSagtMist wrote: Thu Sep 16, 2021 8:18 pm 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
Last edited by grump on Thu Sep 16, 2021 8:43 pm, edited 1 time in total.
User avatar
BrotSagtMist
Party member
Posts: 659
Joined: Fri Aug 06, 2021 10:30 pm

Re: Bizarre nil issue

Post by BrotSagtMist »

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

Who is online

Users browsing this forum: Ahrefs [Bot], Google [Bot] and 7 guests