LÖVE

How does one go about telling love2d to use a different file than main.lua? Please do not tell me to use states; I am looking to make two separate applications that use the same set of libraries. Currently I am syncing all of my libraries using git subtrees, but it is a very painful process.

LÖVE automatically reads a main.lua file at the root, but nothing prevents you from require-ing any other file from there. You could go for an architecture like this:

/
main.lua
lib/
app1/
main.lua
app2/
main.lua

and then require your libraries from the main.lua of each app. just my 2 cents

Or zip them into different .love files. For example:

application1.love - contains main.lua for application1
application2.love - contains main.lua for application2

Besides, you'd usually have the libraries NOT have their entrypoints called main.lua, since, you know, they're libraries? After that, i personally would just zip download the libs and hard-include them into my projects, instead of messing around with the nightmarish git subtrees stuff... people might disagree with me on this though

Ulydev wrote: ↑Fri Aug 24, 2018 12:07 pm LÖVE automatically reads a main.lua file at the root, but nothing prevents you from require-ing any other file from there.

Unfortunately, I am looking to create two applications that can operate independently of each other. This approach would result in only a single window that can only switch between the two. Maybe a good solution is to take this approach and then inform the user that they may open multiple instances of this application.

pgimeno wrote: ↑Fri Aug 24, 2018 1:50 pm Or zip them into different .love files. For example:

application1.love - contains main.lua for application1
application2.love - contains main.lua for application2

That is actually a really good idea. If I cannot find a better solution, I will adopt a workflow that supports this. The only downside is that the end user will have two copies of the libraries shared between the applications, but the libraries in mine are not too big.

zorg wrote: ↑Fri Aug 24, 2018 3:45 pm Besides, you'd usually have the libraries NOT have their entrypoints called main.lua, since, you know, they're libraries? After that, i personally would just zip download the libs and hard-include them into my projects, instead of messing around with the nightmarish git subtrees stuff... people might disagree with me on this though

Sorry, I think you misunderstood me because I was not clear. I was talking about the entry points of applications, not libraries. I only brought up the libraries to explain why I wanted to be able to specify the entry point of applications.

I have a folder with several Lua files, and I have a main.lua like this:
Then I run: love . filename.lua

Maybe it helps?

NetherGranite wrote: ↑Sat Aug 25, 2018 3:32 am Unfortunately, I am looking to create two applications that can operate independently of each other.
...
That is actually a really good idea. If I cannot find a better solution, I will adopt a workflow that supports this. The only downside is that the end user will have two copies of the libraries shared between the applications, but the libraries in mine are not too big.
...
Sorry, I think you misunderstood me because I was not clear. I was talking about the entry points of applications, not libraries. I only brought up the libraries to explain why I wanted to be able to specify the entry point of applications.

Let me elaborate; i wanted to highlight that it's the same thing. I myself usually hate the fact how i have about 20 versions of the visual C redistributable packages installed on my computer because that piece of shit library is included in tons of games and even non-game applications, and each of them need a slightly different version. (I'd be less salty if there'd be a way for it to function like in linux, having one C runtime actually kinda baked into the OS itself, and everything relying on that... to my knowledge anyway)

In contrast to those 500MB+ compiled binaries, lua project libraries really don't have that big of a footprint for you to need to only have them in one place, and not allow yourself the luxury of using separate project directories with main.lua-s in them for separate projects.

If you're really space-conscious, then just symlink in the library folders into both project folders; that can work on windows too, and similar solutions exist on OSX and unix/linux systems. When it comes to versioning though, care not whether git or whatever you use actually pulls the files and uploads them or indexes them; that shouldn't worry you.

If the goal is to just share libraries you could write a loading screen that downloads "NetherGraniteUtils" from a website into a save directory when the identity is set to "NetherGraniteUtils" this will create a folder in the save location called NetherGraniteUtils that all of your games can reference. As long as they set their identity to "NetherGraniteUtils". I'm bad at explaining things but essentially you will download your util package(libraries) to it's own save directory. Then each of your games can check for your util package and use if it exists and download if it doesn't. I would only do this do if your util package is huge and you expect people to download more than one of your applications. I'll write up an example.

Edit: doesn't necessarily have to be a loading screen

Edit 2: What i was recommending would have used luasocket to download a core libs folder from whatever website hosts the source. I was going to use github as my source in my example but the lack of ssl support in love2d would have made that impossible. Even if I did find a website that allowed the downloading of files through http it wouldn't really be secure anyways.

bobbyjones wrote: ↑Mon Aug 27, 2018 2:37 am If the goal is to just share libraries you could write a loading screen that downloads "NetherGraniteUtils" from a website into a save directory when the identity is set to "NetherGraniteUtils" this will create a folder in the save location called NetherGraniteUtils that all of your games can reference. As long as they set their identity to "NetherGraniteUtils".

That is actually very interesting idea, thanks for taking the time to explain it.