## luajit - attempt to index global 'love' (a nil value)

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.
modiX
Citizen
Posts: 77
Joined: Mon Dec 04, 2017 1:47 am

### luajit - attempt to index global 'love' (a nil value)

So I got luajit 2.0 for Windows, compiled it and now trying to compile my code, but when it tries to compile my game it returns "attempt to index global 'love' (a nil value)"

How can I solve this issue?

Offtopic: It seems I cannot use the bcsave module of luajit, too. This is not related to love2d, but if anybody knows why, I'd like to get some advice into this issue, too. Details: https://stackoverflow.com/questions/487 ... -installed

───▄▀▀▀▄▄▄▄▄▄▄▀▀▀▄───
───█▒▒░░░░░░░░░▒▒█───
────█░░░░░░░░░█────
▄▄──█░░░▀█▀░░░█──▄▄
█░░█▀▄░░░░░░░▄▀█░░█

zorg
Party member
Posts: 2308
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

### Re: luajit - attempt to index global 'love' (a nil value)

luaJIT doesn't include löve... or i don't get your question.
Löve already comes with luaJIT.
(Also, bcsave.lua might require luaJIT 2.1, not 2.0, if its source is any indication: assert(jit.version_num == 20100, "LuaJIT core/library version mismatch")) but iirc Löve, or at least the nightlies, already have that.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.

modiX
Citizen
Posts: 77
Joined: Mon Dec 04, 2017 1:47 am

### Re: luajit - attempt to index global 'love' (a nil value)

zorg wrote:
Mon Feb 12, 2018 1:42 am
luaJIT doesn't include löve... or i don't get your question.
Löve already comes with luaJIT.
(Also, bcsave.lua might require luaJIT 2.1, not 2.0, if its source is any indication: assert(jit.version_num == 20100, "LuaJIT core/library version mismatch")) but iirc Löve, or at least the nightlies, already have that.
So how to compile my löve game properly? First I read this: https://love2d.org/wiki/Source_Obfuscation It simply uses luajit, but I don't find luajit shipped with löve.

slime told me to use string.dump instead, so I built:

Code: Select all

local function read_file(path)
local file = io.open(path, "rb") -- r read mode and b binary mode
if not file then return nil end
local content = file:read("*a") -- *a or *all reads the whole file
file:close()
return content
end

local function write_file(path, content)
local file = io.open(path, "w")
if not file then return nil end
file:write(content)
file:close()
end

love.event.quit()
end
However, the output is even larger than the input:

I need a solution that I can use from command line in Windows 10 and it needs to work on any folders.

Is there any more detailed guide how to do so?

───▄▀▀▀▄▄▄▄▄▄▄▀▀▀▄───
───█▒▒░░░░░░░░░▒▒█───
────█░░░░░░░░░█────
▄▄──█░░░▀█▀░░░█──▄▄
█░░█▀▄░░░░░░░▄▀█░░█

zorg
Party member
Posts: 2308
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

### Re: luajit - attempt to index global 'love' (a nil value)

LuaJIT is in lua51.dll with löve; i don't know where josefnpat (going by the history of the Source Obfuscation wikipage) got that the luajit command would work like that though... although i never tried it myself.

There might not be any guarantees that string.dump would result in smaller filesizes, nor for it to work under all circumstances. (Although luajit adds a string.dump(function, strip) variant, where debug symbols get stripped if the second argument is true; and it can be loaded on all supported (by luajit) architectures as long as the luajit minor/major version is the same. (2.0.x and 2.0.y would be compatibvble, 2.0 and 2.1 wouldn't be)

That said, what exactly are your reasons for wanting to compile your code/project(s)? I'm assuming you read all the warnings on the aforementioned wiki page, right?
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.

coffeecat
Prole
Posts: 29
Joined: Sun Sep 13, 2015 4:10 pm

### Re: luajit - attempt to index global 'love' (a nil value)

I think you can build a fused love game (https://love2d.org/wiki/Game_Distribution) to run "lovegame infile outfile" in any directory from command line. You may want to disable any windows it opens up. (I am not sure it's possible)

As another way to do this, you need a separate LuaJIT for a "luajit -b in.lua out.lua" command. LuaJIT can be found here: http://luajit.org/index.html, but unfortunately it seems that they don't provide a simple Windows binary distribution that you can use right away.

pgimeno
Party member
Posts: 1154
Joined: Sun Oct 18, 2015 2:58 pm

### Re: luajit - attempt to index global 'love' (a nil value)

By default, string.dump does not strip debug info. Pass 'true' as the second parameter of string.dump to do this.

http://luajit.org/extensions.html#string_dump
Thrust II Reloaded - GifLoad for Löve - GSpöt GUI - My NotABug.org repositories
The Microsoft Github repositories I had have been closed after the acquisition announcement and will be removed in the near future.

raidho36
Party member
Posts: 1680
Joined: Mon Jun 17, 2013 12:00 pm

### Re: luajit - attempt to index global 'love' (a nil value)

It's guaranteed that bytecode will be larger than original filesize, because it has more individual commands and has to keep most of the strings regardless. It will also be less compressible than source code. It's guaranteed to work with the specific Lua version it was generated with, but otherwise it's basically guaranteed not to work - bad for futureproofing. I do however not suggest obfuscating your code, security through obscurity have never been any secure. You can't stop lockpickers just by making it harder to see what's inside the lock.

pgimeno
Party member
Posts: 1154
Joined: Sun Oct 18, 2015 2:58 pm

### Re: luajit - attempt to index global 'love' (a nil value)

raidho36 wrote:
Mon Feb 12, 2018 11:04 am
It's guaranteed to work with the specific Lua version it was generated with, but otherwise it's basically guaranteed not to work - bad for futureproofing.
Why does that matter? Löve 0.10 programs are basically guaranteed to not work in Löve 0.11 either.
Thrust II Reloaded - GifLoad for Löve - GSpöt GUI - My NotABug.org repositories
The Microsoft Github repositories I had have been closed after the acquisition announcement and will be removed in the near future.

raidho36
Party member
Posts: 1680
Joined: Mon Jun 17, 2013 12:00 pm

### Re: luajit - attempt to index global 'love' (a nil value)

If your LÖVE 10 somehow winds up with a different (updated) Lua version, it won't work even though it should.

modiX
Citizen
Posts: 77
Joined: Mon Dec 04, 2017 1:47 am

### Re: luajit - attempt to index global 'love' (a nil value)

Hey, sorry for my late reply, I was kinda busy on other things these days.

raidho36 wrote:
Mon Feb 12, 2018 11:04 am
I do however not suggest obfuscating your code, security through obscurity have never been any secure. You can't stop lockpickers just by making it harder to see what's inside the lock.
Let me first start by summing things up for you. I know about the reasons you must not have to obfuscate / compile your code. It's obvious to me that games written in LOVE can be read, if the player want's to. In fact even low level games can be reverse-engineered if the player got a good skill-set on that. "Protecting / Securing" my code is not my intention.

I just want to increase its speed and make it not easy to read by extracting the ZIP and using a traditional editor. When it's impossible to compile to a version that runs on Android / iOS on my Windows or Mac, then I'll prefer to deploy it un-compiled.

Here are the reasons why I want it to compile:
- For mobile: To increase speed
- For Windows: I'm serving the game to a friend who learning asset designing to test animations ingame, I want him not to be distracted by the game's code itself
- Proof of concept: Is it even possible to make a compiled version that works on Windows / Mac / Android / iOS with one step?

zorg wrote:
Mon Feb 12, 2018 4:59 am
(Although luajit adds a string.dump(function, strip) variant, where debug symbols get stripped if the second argument is true; and it can be loaded on all supported (by luajit) architectures as long as the luajit minor/major version is the same. (2.0.x and 2.0.y would be compatibvble, 2.0 and 2.1 wouldn't be)

That said, what exactly are your reasons for wanting to compile your code/project(s)? I'm assuming you read all the warnings on the aforementioned wiki page, right?
Yes I do. The sentence in your brackets helped a lot. Passing true made it look way better, this will work out to serve the asset previewer to my designer to work with. But as I understood fully, I cannot use this compiled code for Android / iOS, because it uses luajit 2.1, right?

How can I compile it using string.dump for Android / iOS? I think I need to run string.dump on Android or iOS to get the 2.1 version? It would be nice to be able to integrate this on my build process for my game that is hosted on Windows.

coffeecat wrote:
Mon Feb 12, 2018 5:21 am
As another way to do this, you need a separate LuaJIT for a "luajit -b in.lua out.lua" command. LuaJIT can be found here: http://luajit.org/index.html, but unfortunately it seems that they don't provide a simple Windows binary distribution that you can use right away.
Problem is the luajit does not include love functions. Eventually I understood that luajit is somewhat embedded into LOVE, that's why string.dump can exist, too.

So I came to the conclusion using string.dump is a good approach, but how about mobile?

pgimeno wrote:
Mon Feb 12, 2018 11:38 am
raidho36 wrote:
Mon Feb 12, 2018 11:04 am
It's guaranteed to work with the specific Lua version it was generated with, but otherwise it's basically guaranteed not to work - bad for futureproofing.
Why does that matter? Löve 0.10 programs are basically guaranteed to not work in Löve 0.11 either.
with Lua version he meant luajit not LOVE. The problem here is Mobile uses 2.1 luajit. Although the "futureproofing" argument is senseless, since the game will be deployed with the LOVE framework that is containing the appropriate luajit version.

raidho36 wrote:
Mon Feb 12, 2018 11:47 am
If your LÖVE 10 somehow winds up with a different (updated) Lua version, it won't work even though it should.
It won't.