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

[Marty]

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]

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.

[Marty]

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

function love.load(args)
    print(read_file(args[2]))
    write_file(args[3], string.dump(loadstring(read_file(args[2]))))
    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]

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?

[coffeecat]

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]

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

[raidho36]

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]

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.

[raidho36]

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

[Marty]

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

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?

(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.

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?

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.

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.