Allow .dll and .so with games

[Bobbyjoness]

I think binaries are doable on our end. If a game is deemed unplayable we should have the right to email the author and remove the game. But other than that I think we should allow binaries. It's really quite simple and would allow some potentially cool games. Well if any cool ones that use binaries come out that is lol.

[pablomayobre]

This is part of the vapor 1.x milestone, not the vapor 0.x (which addCompat targets) though. So yeah, totally possible

[Bobbyjoness]

Well I'm working with my testing of things on 0.x as its all already there. If I get the go then I'll implement it for 0.x. Especially since currently 0.x is the only released version of Vapor so until 1.x is fleshed out enough for pull requests I'll work with 0.x in the end the backend would be the same for both versions anyway. So I can start working on backend stuff now.

[pablomayobre]

Well yeah, and no, later then you will probably have to rewrite everything, probably the same will happen to appCompat, it is great that it is there and really useful, but using that in 1.x will probably mean major changes (for example I think that appCompat should not be part of Vapor 1.x but an external application, which is totally doable but would require some work, we discussed this in the IRC I think)

[Bobbyjoness]

Well seeing there is no work on 1.x being done yet I'm sure that as long I keep applying for pull request for 0.x that it would remain release branch for awhile. I would say at least for another 5 months

[pablomayobre]

That is true, you may continue working on this, I'm just saying, that most probably this is not how things will be done in the later release, if you want to do stuff twice, do it, but I dont think you should ask here, I mean... You can freely fork this and do as you like with it...

[Bobbyjoness]

But I kinda want a standard so that it can be compatible with 1.x I want it all to be coordinated.

[pablomayobre]

Well that will depend on 1.X though, and 1.X has a broader scope thant 0.X, so LOTS of thing would be different, and this is one of the biggest parts, as we discussed somewhere else, 1.X will not be aimed purely at LÖVE but as a Client for the masses... So it will support a bunch of different binaries... and not just .dll or .so files but also executables (.exe in windows, .app in MacOSX) so lots of thing will be different

[Bobbyjoness]

That wasn't decided on officially though if I'm not mistaken. Currently its just a love game distribution service. Maybe this will be a separate thing then idk. It depends on how @josefnpat weighs in on this.

[pablomayobre]

I think we said that we would allow any distribution form, but anything that is not a .love file or that doesn't use the standard LÖVE executables would be treated as dangerous and a warning will pop-up when the users tries to download this stuff.

Also we said that the launcher would be pretty much standard having three fields, executable (Here it defaults to LÖVE), game (Optional because the game could be bundled in that executable) and extra arguments

And the final script to run this would be:

$ executable game arguments

[Bobbyjoness]

Where was this talk at?

[pablomayobre]

I remember we commented an issue but I cant find it, and surely at the IRC... @josefnpat should remember...

[Bobbyjoness]

Well I'm sure I was against it the whole time.

[pablomayobre]

And HERE it is... Yes you were... But that is because of your "Brand Pride" or something... Which I consider something totally unnecessary... and actually bothersome because it limits the scope of Vapor

[Bobbyjoness]

Well I think brand pride is important. It's a niche. Once we have everything on our client. Then love devs are basically back fighting for views and downloads. This somewhat levels the playing ground. Well if it takes off. But about .so and .dlls how do you think we should go about this?

[pablomayobre]

Like this, hahaha

And support for unzipping (so that you can bundle .dll's with the .exe and such)

Much like GameJolt does with QuickPlay (But something that actually works and doesnt use Java 😞 )

[Bobbyjoness]

Well I don't like that way. Hmm I think we need to review things. And I have unzipping

[Bobbyjoness]

It's used for addCompat

[pablomayobre]

If you keep Vapor a LÖVE thing it will take off in the LÖVE forums, and will never go outside of it... which means things will stay pretty much the same. For Vapor to take off we need to think about the whole indie community and less about JUST LÖVE

[pablomayobre]

Why dont you like that way?

Yeah I like your unzipping it is actually really nice!!

[Bobbyjoness]

Using our great developers to market Vapor I'm sure it can take off outside of love. But if we end up just for Indies we might as well fork desura its open source and just rebrand it.

[pablomayobre]

Well lets hear what @josefnpat has to said about this since I dont think we would think the same way anyway...

I think that the pride is pointless and wont take us anywhere while you think we should make Vapor a LÖVE only thing because of Brand Pride... so I consider the creator of Vapor should decide which way should Vapor go

[josefnpat]

Vapor originally was just for love 0.8.0 games, just as the vapor 0.x branch reflects.

For vapor 1.x, I full intend on making the system just as @positive07 mentioned. When executing a game, three things will be taken into account:

• The framework to be used, e.g.: /usr/bin/love08
• The location of the file, e.g.: /home/seppi/.vapor/foo.love
• Arguments to be passed to the file, e.g.: fullscreen=false

With this, Vapor will run:

/usr/bin/love08 /home/seppi/.vapor/foo.love fullscreen=false

The framework used IMO should really be maintained by the owner of the mirror. For example, @shakesoda wrote a game that is meant to be run with a modified version of love 0.9.x. He also is a maintainer of hate which in many ways is much like love. Frameworks like this I have no problem adding to the vapor.love2d.org mirror.

What I would have a problem with is users supplying .dll or .so files that could very easily contain viruses and other issues.

I'm avoiding talking about using loveSE, but I think by allowing users to supply files that are to be run against frameworks binaries, as opposed to users supplying binaries themselves, we can avoid many security issues that would arise from distributing binaries.

To finally "weigh in":

For Vapor 1.x: I don't see a problem integrating different frameworks (and thus including trusted .dll and .so files in them) is a problem so long as this is managed carefully to protect the end users.

For Vapor 0.x: The original purpose of the system was to distribute .love files, not frameworks. To do the latter "correctly" (imo of course, as mentioned before) would not only require a lot of work on @Bobbyjoness' behalf, but a lot of extension of vapor.love2d.org/api which for the 0.x release I really am not interested in extending as it is in the 1.x roadmap.

But as usual, it's FOSS! Fork to your hearts content!

[josefnpat]

I will close this ticket as it is in the vapor 1.x roadmap already, but folks are free to continue discussion!

[pablomayobre]

What I would have a problem with is users supplying .dll or .so files that could very easily contain viruses and other issues.

Well we could still put that HUGE warning everywhere (web and client) and allow them as a new framework... But I'm fine with the approach 1.X is taking

[josefnpat]

@positive07 Yup, I agree :)