Installation instructions

[Cerez]

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

 

https://github.com/JACoders/OpenJK/wiki/Installing-OpenJK

 

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.

[ensiform]

Did you update Mac instructions because I think brew install sdl2 via Homebrew is best option for installing SDL2 on Mac, is it not? @@Raz0r @@Xycaleth @@redsaurus

[mrwonko]

Homebrew is pretty much the go-to package manager on Mac, yes.

[Raz0r]

`brew install sdl2` works perfectly (i.e. downloads and installs to proper/expected directory)

[Cerez]

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.

[Raz0r]

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.

[Xycaleth]

You know what's even easier? Drag and drop

[ensiform]

Only if it functions properly.  You're dragging it wrong.

[mrwonko]

You know what's even easier? Drag and drop

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.

[Circa]

Are there plans for an installer of some kind so it's all done for us? That would be amazing.

[Raz0r]

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

[Cerez]

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)?

 

Edit:

 

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

[mrwonko]

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

[Cerez]

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.

[ensiform]

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

[Raz0r]

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

[eezstreet]

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.

[elias]

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]

Dunno how I missed this thread.

 

The idea of a auto updater with the ability to roll back in case there is an issue is an awesome idea.

[ensiform]

I don't think rollbacks will be happening.

[minilogoguy18]

Well then auto update only is fine assuming someone fixes whatever they broke lol.

[ensiform]

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.

[Raz0r]

It would be fairly easy to switch to tagged releases or stable/development branches.

[Cerez]

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.

[ensiform]

The aggressiveness is because people don't often read that it states certain things and it gets tiresome.