OpenJK Launcher/Installer (non-coder input wanted)

[eezstreet]

So after a bit of a discussion with @@Caelum about this over Discord, I had an idea in my head for a while.

 

What if everyone could compile OpenJK? Yes, I mean obviously, everyone can compile OpenJK, there's a whole tutorial about it and everything. But what if that was the primary way to install it?

 

The idea is very simple. You have a launcher with several options. Each of these options corresponds to an OpenJK repo, like those in the fork megathread. The program would then clone the code from that repository, compile it, and stash it for safekeeping. You can then launch the compiled code (if it compiled successfully, of course!) with some options like fs_game, etc. Every time you switch, it compares the stashed compiled stuff's git hash to the current head so you wouldn't be compiling the code every single time you run the game, unless there's updates.

 

Pros:

• Effectively eliminates the need for CI
• Anyone can compile and run any repo, no need to ask for current compiles.
• Can act as a springboard for other features, such as server browser, chat, JKHub API platform, etc
• Everyone is always updated to the latest version

Cons:

• Not really useful for servers
• Not sure how to package a C++ compiler, cmake, scons, etc within an app and have it work well.
• It's more work to do.

tl;dr how it would work:

• Get URL of repo that you want to play with (http://github.com/JACoders/OpenJK for instance) and branch
• Hit magic "compile" button
• Set your fs_game and run the game
• You are now pro-g®amer

pinging some coders @@Xycaleth @@ensiform @@Raz0r @@mrwonko

pinging some players @

[SomaZ]

First, I think we won't get the permission to supply cmake. Then, you really want the user to mess around with the path variable, if the cmake install fails to set it right? (yea, I got that problem once. Now I know what the PATH variable is )

 

Calling cmake via c++ is no problem, since this is a command line tool. Did a similar thing some time ago. Only the configuration could be a problem. gcc should be no problem either.

 

Though, wouldn't it be easier to simply download the latest compiled files? Set the gamedir in the launcher -> download -> unzip -> copy/overwrite files -> good to go -> profit?

[Circa]

I'd rather just have a 1.0 release that's as stable as possible on all OSes.

 

As a player, I don't even care about having the latest release unless there's a bug I know was fixed or something. I update it maybe once a year.

 

Right now it's easy enough to just download from the builds site and throw it in the right folder once a year.

 

If there was some kind of "Check For Updates" feature and download an updated version, that would be even better and more useful.

[Xycaleth]

This seems like a bad idea to me. What problem does it solve?

 

Pros:

• Effectively eliminates the need for CI
• Anyone can compile and run any repo, no need to ask for current compiles.
• Can act as a springboard for other features, such as server browser, chat, JKHub API platform, etc
• Everyone is always updated to the latest version

• You will still need CI. How else can you tell if the code compiles and that there are no missing files? You obviously don't want to find out when the players are starting to compile the code on their machines.
• Why waste the player's time compiling code, then they could download a precompiled version and run it?
• How does the player being able to compile the code, enable these features? It would be possible to do if the player downloaded a .exe
• Same as above - they can download the latest version manually, or through some automated check for new builds

You then have the issue of people using the master branch which is, for the most part, unstable. None of our weekly builds are stable; they just happen to be built on a Monday to give people something to use. We don't have a stable branch currently.

 

On top of that, the player now has to download an additional few hundreds of MBs of programs to compile the code.

 

If the problem you're trying to solve here is to keep everyone up to date, then have a launcher which downloads precompiled builds and keeps the user up to date.

[mrwonko]

What xycaleth said, pretty much. Don't see the point. Have a launcher and an updater, sure, but we still want CI and no player wants to compile themselves.

[eezstreet]

This seems like a bad idea to me. What problem does it solve?

 

• You will still need CI. How else can you tell if the code compiles and that there are no missing files? You obviously don't want to find out when the players are starting to compile the code on their machines.
• Why waste the player's time compiling code, then they could download a precompiled version and run it?
• How does the player being able to compile the code, enable these features? It would be possible to do if the player downloaded a .exe
• Same as above - they can download the latest version manually, or through some automated check for new builds

You then have the issue of people using the master branch which is, for the most part, unstable. None of our weekly builds are stable; they just happen to be built on a Monday to give people something to use. We don't have a stable branch currently.

 

On top of that, the player now has to download an additional few hundreds of MBs of programs to compile the code.

 

If the problem you're trying to solve here is to keep everyone up to date, then have a launcher which downloads precompiled builds and keeps the user up to date.

 

It solves the problem of having to provide precompiled binaries for people to use for each platform. Traditional CI is just not optimal for 90% of projects which are too small to warrant setting up appveyor or Travis CI or other services for them. This makes it easier for people to find binaries and makes it easier for programmers to provide them. Likewise, it guarantees an easy install for mods, and people could supply compiler options such as VEH_CONTROL_SCHEME or other stuff that's disabled normally. It solves multiple problems, not just one.

 

The point isn't to make this a launcher specific to OpenJK, but one that's capable of running any OpenJK based project. Ideally someone can simply say "I want this specific fork" and compile it on their machine using the launcher, rather than having to see if that person has builds for it. It makes finding mods much easier when they're in one nice little housing.

 

Honestly a lot of your points sound like organizational issues of OpenJK, and not issues with this launcher. If OpenJK doesn't have a stable branch, that's a problem of OpenJK, not a problem with my idea.

[Futuza]

I don't see how compiling the source code is going to be faster then downloading what you need from an update server.  Seems way too much headache for something that just needs to update off of a server based on platform.

[eezstreet]

I don't see how compiling the source code is going to be faster then downloading what you need from an update server.  Seems way too much headache for something that just needs to update off of a server based on platform.

It's not supposed to be faster.

In fact maybe an improvement would be to have the first client download the source, compile it, and upload to some kind of website?

[Futuza]

It's not supposed to be faster.

In fact maybe an improvement would be to have the first client download the source, compile it, and upload to some kind of website?

In a way you are wanting it to be faster and more convenient then having a build server do nightly builds of various different forks, etc.  Why would you want to upload the compiled source to the website from hundreds of different players on a frequent basis?  I mean if this is an issue of you solving the problem of I want openjk builds for every single linux distribution possible available, then the master build server is still an easier way to solve this problem.

 

 

 

It solves the problem of having to provide precompiled binaries for people to use for each platform

Why is this a problem?

[eezstreet]

In a way you are wanting it to be faster and more convenient then having a build server do nightly builds of various different forks, etc.  Why would you want to upload the compiled source to the website from hundreds of different players on a frequent basis?  I mean if this is an issue of you solving the problem of I want openjk builds for every single linux distribution possible available, then the master build server is still an easier way to solve this problem.

 

 

 

Why is this a problem?

To be clear, it would be downloading the source code via Git or something similar that uses delta compression techniques, so you wouldn't be redownloading the entire source code every single time you need to update, you would just be downloading the changes.

 

I think you are confused with how that particular optimization would work. If it becomes an issue that downloading the source code and compiling it becomes such a huge burden for people (it really isn't, there have been big advances in things like delta compression and compiler design to where it would only take a minute or two to compile), the first person whose client would compile the game on a particular platform would upload the build in the background, and other clients can use that instead of compiling the source code.

 

But I seriously doubt that's an improvement, it seems like a downgrade even. Like I said - look at how much Git downloads whenever you pull for updates. It's maybe ten kilobytes, max, vs a whole new client, which is several megabytes. Disk space is cheap, bandwidth is expensive.

 

 

[Futuza]

Then it's a trust issue, how do you certify that whoever uploaded the build didn't sabotage it and why bother even trusting random interweb builds in the first place instead of just having a build server?  I guess I'm still confused on what you're trying to solve, large file size downloads?  I really don't think binaries are that big...they take like 2-3 minutes to download if you're not using dial-up.

[eezstreet]

Then it's a trust issue, how do you certify that whoever uploaded the build didn't sabotage it and why bother even trusting random interweb builds in the first place instead of just having a build server?  I guess I'm still confused on what you're trying to solve, large file size downloads?  I really don't think binaries are that big...they take like 2-3 minutes to download if you're not using dial-up.

I mentioned it in an edit, I think JKHub just shit the bed lol.

 

The thing I'm trying to solve is the issue that modmakers need CI or need to have somewhere to host their builds. With this launcher, the need for CI to provide builds is effectively eliminated (although whether or not it compiles, you still need to determine on a local copy). Also with this launcher, you could provide a curated list of repositories for people to try out without them having to hunt down the modmaker to provide builds, follow dodgy install instructions, etc and serve as a launchpad for other features, such as achievements and a larger JKHub API.

 

Basically, I want to solve the problem of both difficult installs for new users and modmakers to provide hosted builds.

[Xycaleth]

It solves the problem of having to provide precompiled binaries for people to use for each platform. Traditional CI is just not optimal for 90% of projects which are too small to warrant setting up appveyor or Travis CI or other services for them. This makes it easier for people to find binaries and makes it easier for programmers to provide them. Likewise, it guarantees an easy install for mods, and people could supply compiler options such as VEH_CONTROL_SCHEME or other stuff that's disabled normally. It solves multiple problems, not just one.

 

The point isn't to make this a launcher specific to OpenJK, but one that's capable of running any OpenJK based project. Ideally someone can simply say "I want this specific fork" and compile it on their machine using the launcher, rather than having to see if that person has builds for it. It makes finding mods much easier when they're in one nice little housing.

It doesn't solve that problem at all. If the developer hasn't built it on platform Y, then he shouldn't claim it works on platform Y. If a regular player comes along and tries to compile it, it's more than likely not to work - what is he supposed to do now?

 

IMO, every code mod should be using CI. It simplifies the developer's life immensely, whether they realise it or not. So many devs waste time figuring out what files have changed, which files need to be repackaged, when it can all be automated. Some teams manage to do this (MB2) but it's very accident prone and time-consuming.

 

And there is no hosting problem. If the mod code is hosted on GitHub, they can host prebuilt binaries on GitHub using the releases feature.

 

Honestly a lot of your points sound like organizational issues of OpenJK, and not issues with this launcher. If OpenJK doesn't have a stable branch, that's a problem of OpenJK, not a problem with my idea.

I made one comment about not having a stable branch, and it's not directly related to any of the points I raised

[eezstreet]

GitHub is not really the most user friendly website though. And it's not simple for the uninitiated to install at all, unless you want to take the dirty approach of dropping it into your Gamedata folder directly.

 

I agree, every mod should be using CI, but CI is a pain to set up and get working correctly. Consider this approach to be CI and an updater all in one, that uses less bandwidth to boot.

 

If a mod doesn't compile, then it doesn't compile. Another nice problem this launcher could fix is have a bug reporter built into it like with JKG's old launcher that would create a GitHub issue without the user having to get a GitHub account. If a build fails for that repo, it can create an issue titled "Won't compile on <platform>" with the output of gcc as issue text.

[Xycaleth]

You could have the launcher check for release updates from the GitHub website. It has an API to interact with a project.

 

Letting people download broken code is just poor. It shows you don't care whether it works or not, just let the players find workarounds. For coders who want to see if it works, and who want to see if they can get it working, it's a different story because that's what they expect.

 

I think we've also both missed a major point here. How do you distribute compilers/build tools for a platform which we don't foresee being used? How can the user even download a launcher for a platform which we didn't know people were going to use? Do you get everyone to download the code and try compiling that as well?

[Exmirai]

In my opinion end-user launcher should download prebuild binaries from somewhere ( builds.openjk.org ), without any compilers and so on. But if end-user wants to be a developer then, in launcher, they could download dev suite etc. Just wondering because launcher so, as you want will have size about >100mb ( compilers, libraries etc ) which is no good for user that want just to play.

[Didz]

I'm also going to join the unanimous disagreement here to say that this sounds like a solution looking for a problem. I don't think it's wise to have a launcher compiling code for the end-user as an excuse for the developer not to have tested their code on their target platforms. Compilation is always tricky, so spreading the requirement of compilation over multitudes of end users seems quite silly when you know that the package the developer builds will always be proper.