Jump to content

Installation instructions


Recommended Posts

I've just updated/completed the installation instructions documentation for OpenJK in the Wiki:




Can't believe we've been missing it for so long...


Anyhow, I've covered all three computer platforms in detail. Let me know if anything's off.


This should help new users set up a build for use from the rolling weekly builds repo.

Smoo and BruceJohnJenner like this
Link to comment

Guys, come on! Homebrew is easy for devs, not for regular users. A regular Mac user wouldn't know where to start with something Terminal-based such as that. They'd panic and freak out, then scream and run down the hallway flailing their arms, and as far away from their computers as they can possibly get.


Doesn't the regular SDL2 installer work just as well -- from their site? I seem to remember using it, and I had no problems.

Link to comment

People need to stop being afraid of computers.

"oh no i have to copy-paste a single line of human-readable text how ever will i live"


Homebrew massively simplifies installing software and dependencies for users (and developers are users too) - it doesn't involve any complex steps, there's no programming involved.

eezstreet likes this
Link to comment

You know what's even easier? Drag and drop :P

Fair point. For your ordinary Mac user we should really just work - it must be possible to include libraries in an app bundle since everything else works, so let's just do that.
Cerez likes this
Link to comment

Homebrew massively simplifies installing software and dependencies for users (and developers are users too) - it doesn't involve any complex steps, there's no programming involved.


I've just tried Homebrew for the first time. To a Linux user it wasn't very daunting, but I can tell you straight away that a regular Mac user (who is not used to using the command-line, but is used to high-end visual interfaces instead) would get stuck at the first step. Installing mencoder using Homebrew posed a few challenges for me, too. It wasn't exactly a straight-forward, single step process. I had to figure out how Homebrew works, first.


That being said, I don't contest to it being a fantastic and easy to use tool for Mac software administration/development.


There has been a lot of talk lately regarding instructions, installers, updaters, launchers, mod managers..

Let me know, guys, when changes are done, and I'll be happy to update the install documentation. We should probably start with the installers/bundles, and then move on to updaters and mod managers later. The primary focus should be to make the installation process as straight-forward and simple to use as possible. On a Mac, ideally that's a simple drag-and-drop bundle. On Windows, it's a simple install wizard. For Linux, a single command in the Terminal to install (with interactive options)?




Although, if it's not too much trouble to maintain, I would always keep a manual install of the files an option -- for those who prefer to be in full control and set it up themselves, as opposed to relying on an installer to do the job for them.


Personally, I hate it how MBII is now all installer and launcher interface based, and I have no access to individually controlling the process and/or mods/packages. I'm sure I'm not alone in that...

Link to comment

The argument is that without some form of updater/version check people will never update, so that's kind of important to have asap.

What's the main reason for updating? If a user is truly interested, they will download a newer version of the binaries. Why should users be forced to update? If the current version works well and to their needs, what's the point?


(Please don't do what the MBII project has done, keeping things always on the cutting edge, and forcing all users to update. That's awfully useless and annoying. It's the reason I deleted MBII from my computer -- it was a time and bandwidth hog.)


I agree with an optional updater for convenience, to be run/used by choice. But a nagger, automatic downloader, or forced updater I think is a horrible idea.

Link to comment

At best I see OpenJK using an MSI/simple installer with maybe a launcher to check for updates if the user prefers. No need to keep the user on the bleeding edge of updates unless it's a massive security loophole or critical bug being corrected.

Cerez likes this
Link to comment

I think the best use of an 'updater'/launcher(?) would be to have some option to revert back and forth to early or later builds. A method of announcing a new update and giving the user the option would still promote latest builds but have the ability to revert if anything went wrong, its literally the replacement of 3 files right? Just set the path to jka install and boom.

And a checkbox to create an updated alias on the desktop which is a pain in the ass to replace every time you update or replace openjk builds!


And maybe reference something like this for SDL on mac your for those who need a step by step to install the proper way? As drag and drop would be the go-to method for most, ..at least I had issues with it, something wasn't 'linked' in the terminal stuff. This is still the guaranteed right way though.

minilogoguy18 and Raz0r like this
Link to comment
  • 2 weeks later...

I would imagine for the most part it wouldn't auto update without testing first. I would also be interested in seeing a multiple release strategy with channels like other popular software but that would take a lot of planning and effort to build.

Link to comment

Because at best, people will use an outdated not official release of OpenJK and complain when it doesn't work.

Versioning should be made a bit clearer to the end user, and bug reports should always be accompanied with a version number.


It's much better solution than forcing users into keeping up with the latest. I understand the need to regulate/minimise the support requests, but there's no reason to be so aggressive about it.


If versioning is well organised, and simple to follow, a user can easily be told to download the latest version where this particular bug has been fixed, or new feature has been implemented. Simple, easy, hassle-free to both the developer and to the end user.


I am entirely for the updater being optional (default: on, with a checkbox)

I'm okay with this, as long as there is a working option for me to turn the (bloody) updater off -- permanently!


I don't want it doing anything without my consent -- not even nag me about the latest update.

Raz0r likes this
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...