Error on Windows, not on Mac

[Neko250]

Hello,

In my game, on Windows, if I double click on an object (a token) the game crashes and says:

Code: Select all

Error
main.lua:819: attempt to index a nil value

Traceback
main.lua:819: in function <main.lua:809>
[C]: in function 'xpcall'

However, if I do the same thing on the Mac version, which is compiled from the same code, this does not happen.

Here is the code, the lines (809 & 819) are indicated by comments:

Code: Select all

function love.mousepressed(x, y, b)
    if global.inGame then
        if b == "l" then
            if not timers.toMenu and boxHit(x, y, button.back.x * settings.scale, button.back.y * settings.scale, button.back.width * settings.scale, button.back.height * settings.scale) then
                button.back.isDown = true
            end

            if boxHit(x, y, button.again.x * settings.scale, button.again.y * settings.scale, button.again.width * settings.scale, button.again.height * settings.scale) then
                button.again.isDown = true
            end
        end
    elseif global.inCredits then
        if b == "l" then
            if not timers.toMenu and boxHit(x, y, button.back.x * settings.scale, button.back.y * settings.scale, button.back.width * settings.scale, button.back.height * settings.scale) then
                button.back.isDown = true
            end
        end
    else
        if b == "l" then -- LINE 809 !!!
            if not timers.toGame and boxHit(x, y, button.play.x * settings.scale, button.play.y * settings.scale, button.play.width * settings.scale, button.play.height * settings.scale) then
                button.play.isDown = true
            end

            if not timers.toCredits and boxHit(x, y, button.info.x * settings.scale, button.info.y * settings.scale, button.info.width * settings.scale, button.info.height * settings.scale) then
                button.info.isDown = true
            end

            if not timers.exit and boxHit(x, y, button.exit.x * settings.scale, button.exit.y * settings.scale, button.exit.width * settings.scale, button.exit.height * settings.scale) then
                button.exit.isDown = true -- LINE 819 !!!
            end
        end
    end
end

I don't really know what is happening... please, help me.
Thank you in advance.

[Positive07]

Well the code you posted doesnt tell us ANYTHING... could you just post a .love file? We could give you better feedback on what is going wrong

[Jasoco]

Without the .love we can't do much. But I suspect it's because button.exit does not exist so trying to set button.exit.isDown will error. Make sure you have defined the button.exit table.

[Neko250]

I have already told you that the same code does not crashes on Mac. So... indeed I have initialized properly the table.
Anyway, I don't think it's an error on my code. Because of what I said before. And all the code I posted shall give you enough information, I think. This said, my code is not open-source, and it's all in the same file, so... if I could avoid making it public... well you know.

What I thought:
Could it be an error in the "love.exe"? Maybe it is not compiled from the same exact source as the "love" executable for Mac? Maybe the Windows dynamic link libraries?

Thank you for your support and answers.

[Jasoco]

If you give us a .love, we can try it ourself and make sure it is indeed the Windows version's fault. But without it, we cannot tell you anything.

Otherwise, you'll have to take your .love to a friends house and try it on his Windows machine because you're not willing to share. Your code has no errors that we can see from here. Without a way to test it ourselves, we cannot help any more.

[Positive07]

-snip-

THIS! EXACTLY!

And all the code I posted shall give you enough information, I think

It does not! Because:

• You are not showing the initialization of your tables
• There is no actual error in that code
• Cannot replicate the issue with just that code

This said, my code is not open-source, and it's all in the same file, so...

Well a closed source project asking questions in a forum and even more asking for help fixing a bug is not something you see everyday, if you want to hold that then or you do as Jasoco says and ask a friend or you pay someone (You now, hiring a programmer)

Could it be an error in the "love.exe"? Maybe it is not compiled from the same exact source as the "love" executable for Mac? Maybe the Windows dynamic link libraries?

Probably not, Love is compiled from a single source with little to no difference, if you havent messed up the dlls or compiled it yourself then everything should be the same.

Your error is most probably a variable depending on a Love value that changes between computers or updates, that said we dont know how those variables are initialized so we cant tell

[Jasoco]

Neko and I have been talking on PM for a few days trying to figure this problem out and it appears to have been a problem with the compression utility, not the code. He sent me a .love and I unzipped it and looked at the code and ran it and it ran fine. However if I ran the .love in its compressed form it would error. There was nothing wrong with the code at all. When I rezipped the code again and ran it, it stopped erroring. And it would never error when unzipped. (In folder form.) So it appears to have been a problem with the CLI version of the compression utility he was using.

I also determined that the line where the code was erroring DOES NOT ACTUALLY EXECUTE at the time of the error. So the error was false and in the wrong place. The code block posted in this thread has no errors in it at all, but for some reason Löve thought it did, even though that block of code does not even get accessed during the point in the game where the error occurs.

It's understandable to not want to share your code when it's an important project like this, so I appreciate Neko letting me try and figure it out in confidence. Shame it wasn't a tangible error that could be fixed, rather some weird glitch that occurred for no particular reason.

Either way, it's just a weird bug that has absolutely no solution and hopefully can be avoided next time.

[Positive07]

Okay, sorry if I was rude! Thanks for posting the real issue.

Questions: Does this happen whenever Neko250 makes an archive in his machine or was it just this specific LÖVE? Does it happen with an specific zipping tool?

[Jasoco]

Okay, sorry if I was rude! Thanks for posting the real issue.

Questions: Does this happen whenever Neko250 makes an archive in his machine or was it just this specific LÖVE? Does it happen with an specific zipping tool?

I don't know. He hasn't updated me yet. It happened when he used OS X's built-in command-line ZIP program. I rezipped the files using OS X's built-in GUI-based ZIP program and it didn't error for me. I'm waiting to see if he has the same problem when he ZIPs with the GUI himself.

It's a strange issue indeed. As I've never seen a ZIP algorithm cause code errors in code that isn't even being executed at the time. There's like no way to catch an error like that since there's no actual error at all.

[Garmelon]

However if I ran the .love in its compressed form it would error. There was nothing wrong with the code at all.

Something like that happened to me too a while ago. When I ran my .love it couldn't find files with 'ö' etc. in their name. Not sure if it has anything to do with this or if it was just a f*ckup on my part. I'll include an example .love anyways.