We need convenience

[duh]

Odamex seems to be the port of choice. I recommend a testing session on the build below (revision 5426, reports as 5420), since it records vanilla demos properly and does not have weird weapon bobbing glitches, and it is network compatible with the current Odamex release.

https://mega.nz/#F!E0JSHC7Y!oHDdNtYjvGgB-Nlatg1frg

We should decide which install script we should work upon, although I did one script, it does not obey the current github directory structure, as you can see here:

https://github.com/freedoom/freedoom/issues/110#issuecomment-139375658

These are some annoying bugs affecting the latest builds, keep an eye on them, I guess.

http://odamex.net/bugs/show_bug.cgi?id=1148
http://odamex.net/bugs/show_bug.cgi?id=1150

To help boost Freedoom's popularity (a little), we need to make things convenient for the newcomers, and that means supplying a package with a selection of source-ports. I know I know, freedom, impartiality and all that stuff, an insignificant number of people cares. The newcomers wants to download and play right away.

So I suggest the following: we bundle Freedoom with (with no folder hierarchy)

* Doom Explorer (we use -appdir command for portability)
* ZDaemon
* Zandronum
* Odamex

and add a link to download the pack on the main site. We should not expect the source-port developers to get in sync with our release cycle, nor should they adapt to ours, or even the naming convention.

(uploading the bundle)

[fabian]

I like the idea in general!

But I don't think we should package more than one source port with the data. The first questionto hit my head if I wouldn't know about Doom and just downloaded this for convenience would be "what the heck is the *right* one". More than one .exe will most probably not add to convenience.

Also, please keep in mind that the selection of the source port should fit with Freedoom's philosophy and license. Also again, I think for a beginner's package, the port should focus on single-player and leave multi-player (with all its own options and features) as a more advanced excercise.

[soner du]

Why 3 ports from the same "family" (ZDoom) ?

We probably should stick to the 2 recommanded ports, Odamex and PrBoom+...
And maybe Chocolate Doom (to play with Vanilla PWADs or FreeDM).

[fabian]

I'd even say Chocolate Doom would be our best guess if Freedoom wasn't cursed with this silly and unnecessary Boom-compatible requirement...

[duh]

The initial idea is exactly the multiplayer part. Personally, I would pick Odamex only, but then comes those shitty political implications.

[soner du]

fabian said:

I'd even say Chocolate Doom would be our best guess if Freedoom wasn't cursed with this silly and unnecessary Boom-compatible requirement...

FreeDM is Vanilla-compatible and small-sized, it's useful for playing vanilla PWADs on Chocolate Doom
(or limit-removing PWADs with Crispy Doom, Scythe 2 and Arcadia Demade run fine)

[andrewj]

I have considered this in the past (I'm sure others have too), but the problem is that FreeDoom contributors are unlikely to reach consensus on which source port to use, and supplying more than one may confuse users and just make more work than necessary.

Plus it puts a burden on the project to handle bug reports, create documentation, etc... about the source port or ports which are bundled with it. So the convenience would come with a cost, and I wonder if the project can afford that cost.

[duh]

It is currently a mess, but that is because I couldn't find the Odamex equivalent to the PATH command. But yeah, the user is supposed to double-click on "play.bat", let it "search" the files (found no way to preconfigure DoomExplorer, so Bond, help) and it is set. Also, something I just remembered AFTER packaging, Odamex is not 100% Boom compatible, nor ZDaemon AFAIK. Does ALL levels works with it?

https://mega.co.nz/#!UABQALSB!iWwlRzz-u6a7_Bnaum5LDuSPV0rlA8sAtJdUwpMTDs8

Regarding the consensus part, it becomes easier when you set the objectives, which can be set with a few questions:

"prediction" (multiplayer), so the experience is smoother?
Odamex, Zandronum and ZDaemon

which ports have infrastructure to list servers/rooms?
Chocolate/crispy-doom, Odamex, Zandronum, ZDaemon and Doomsday

which ports supports Boom maps?
Zandronum, prboom+, zdoom and gzdoom (eternity?)

which ports records and plays Doom2 1.9 demos?
Odamex, prboom+ and chocolate/crispy-doom

that's it, so far.

[EDIT]
And these are the cfgs files used, I tried to make it as seamless between each port as possible.

https://mega.co.nz/#!wRRA0a7I!leoVKckBbWGHxK-5H7MEMpfXE58eZY_pebUXskwDT2Q

[chungy]

fabian said:

I'd even say Chocolate Doom would be our best guess if Freedoom wasn't cursed with this silly and unnecessary Boom-compatible requirement...

Chocolate Doom is a good and easy port, but the low resolution is probably off-putting. Crispy Doom would probably fare better, but still maybe not enough. The project in recent history is recommending Odamex, although it has some pretty bloated configuration menus.

Beyond that, I do agree that the Boom requirement is more of a burden than any assistance it provides for mappers. I've talked a lot in IRC how we might just have to take a strangle and force everything (including Phase 1+2) to be vanilla compatible. Sure, limits and less features to exploit, but the gain is huge: pretty much any port can play vanilla maps.

I've posted a comment on the issues thread XCOPY made, partly overlapping with this one.

[Jewellds]

I've noticed a lot of hating of the Boom-compatible requirement, but I don't think the advantages outweigh the disadvantages.

Removing this requirement would mean severe editing of the maps to remove Boom sector effects and triggers. Going with Chocolate Doom would be even worse as we'd have to go through all the maps until they didn't break the visplane limit. This would be a big ask, particularly with a project that is short on mappers.

There isn't exactly a shortage of Boom compatible ports either. Those who like Crispy Doom might want to take a look at Doom Retro, a port based on Chocolate Doom which recently added Boom compatibility.

[wesleyjohnson]

If this project was not at least using Boom features, I would not be bothering with it.
That will happen when degrading any project to the lowest common denominator.

There is only one port, PrBoom, that would be reasonable. It is the closest standard engine for the wad features used. The reference port, Boom, requires a DosBox to run.

Choosing any other port is just going to be catering to one set of players or another on the basis of how many there are, or how much they complain. Immediately there will be complaining about it not being exactly what some sub-group wants for their hardware and OS choices. There will be calls for a different engine on the basis that everybody that some sub-group knows is using that engine, so why should Freedoom be using something else.

You will not be having any ports for Linux, or Mac.
With the lack of ports for Linux, or Mac, it will appear that FreeDoom is now developed for Windows, with other ports being on their own.

DoomLegacy already recognizes Freedoom wads, and advertises about getting it.
I would not bundle them. Why makes things more complicated. The only integration needed is to point to a good directory where put the FreeDoom wad, so the engine can find it.

If you put out a text file that listed for every engine where to put the FreeDoom wad, you would accomplish nearly the same. What else would be provided, the appearance that FreeDoom and some engine are one product and are maintained as a unit, or just catering to the laziness of people who cannot be bothered to download two files instead of one.

The only other useful information to share would be a batch file or script file that provides the "best" option choices. But so many of the Windows users do not know how to run a batch file, it would do them no good. This is really requiring that you supply altered port engines that default to running FreeDoom at the optimum settings, because that is all the lazy people that this caters to can be expected to deal with. Otherwise, you will be endlessly explaining options, and directories, and other details for every port engine choosen. You have now become a maintainer.

I would rather see this split off as a separate effort from FreeDoom so FreeDoom can continue without any inferences rubbing off, or any redirection of our effort.
I think it will quickly die off or become obsolete, except for one or two ports.
Both engine releases and bug fixes, and FreeDoom releases and changes, will require that someone spend the time making up another combined release, for every port.

[duh]

"If you put out a text file that listed for every engine where to put the FreeDoom wad, you would accomplish nearly the same."

You are forgeting something: people are lazy. Accept it.

[fraggle]

There's great value in distributing an installable bundle of Freedoom packaged with a source port, but I don't see any point in distributing more than one source port. We should just pick one, and Odamex seems like a good choice that can work as both a single player and multiplayer port. Including more than one source port will just make things needlessly convoluted, and the goal here should be simplicity.

I don't think Chocolate Doom is a good choice for Freedoom. While I'm touched that it's being recommended it doesn't fit in with what Freedoom is aiming for. Even if Freedoom was entirely Vanilla compatible, things like the 320x200 resolution, and the deliberate bug compatibility, are the opposite of what we should be aiming for with Freedoom.

wesleyjohnson said:

If you put out a text file that listed for every engine where to put the FreeDoom wad, you would accomplish nearly the same.

I totally disagree with this. Freedoom's current install process is needlessly convoluted and users should be able to download and play without even needing to learn what a "source port" is. This stuff is a massive barrier to entry for players who just want to play the game (and might not have even played Doom before). We should absolutely be "catering to the laziness of people" because there is no good reason why we should be forcing them to jump through pointless arbitrary hoops just to get the game up and running.

[duh]

So be it: Odamex.

[Arctangent]

To be quite a bit snarky, if you're picking Odamex for both newbie-friendly singleplayer and multiplayer then you should probably instead be picking PrBoom for all the same newbie-friendly singleplayer and multiplayer options without tossing in any needless deceptions. :v

[soner du]

On lots of linux systems, I think FreeDoom is more-or-less dependent on PrBoom(+) ?
(IIRC)

[fraggle]

In Debian systems, Freedoom depends on prboom-plus or boom-engine - which is provided by prboom, prboom-plus and doomsday. So PrBoom+ is sort of the defacto standard port there, but it's really just an accident from the fact that there aren't that many source ports packaged for Debian.

[chungy]

Arctangent said:

To be quite a bit snarky, if you're picking Odamex for both newbie-friendly singleplayer and multiplayer then you should probably instead be picking PrBoom for all the same newbie-friendly singleplayer and multiplayer options without tossing in any needless deceptions. :v

PrBoom is a great port, but it overwhelms users with millions of options. It is not newbie-friendly at all.

[duh]

In any case, it is ready, I guess. https://github.com/freedoom/freedoom/issues/110#issuecomment-139375658

[soner du]

I did my own almost-vanilla package for windows : https://drive.google.com/file/d/0B8B6JH_5YJHDMFZXUEc2ZzZLWUU/view?usp=sharing
- Old-school frontend (good old .bat)
- Crispy Doom engine
- Vanilla IWAD : FreeDoom2 assets + SLIGE maps
- SLIGE + ZenNode
- Sample vanilla mini-megaWADs : Demonfear, Zone 300, Congestion 384
- Sample limit-removing PWADs : Ruma, Arcadia Demade, Chord G

Still under construction... I'm not sure about the WADs, and not sure about the engine (maybe I'll switch back to Chocolate Doom).
I'll try to keep the package under 32MB (unzipped).

[esselfortium]

Vanilla compatibility would be a great idea. I regret being one of the voices speaking against it when this question was first raised 5 or 6 years ago.

[Doctor Nick]

esselfortium said:

Vanilla compatibility would be a great idea. I regret being one of the voices speaking against it when this question was first raised 5 or 6 years ago.

Not feasible. we'd have to modify a shit-ton of boom-compatible maps.

[esselfortium]

How many of those are maps that have been in Freedoom since the dawn of time and ought to be replaced anyway, though? (I haven't kept up with things lately, so I'm not sure if that's still the case.)

[Da Werecat]

Making everything limit-removing would be an okay first step. And this step alone would allow to play Freedoom levels in just about anything but the most strict source ports.

[Doctor Nick]

Da Werecat said:

Making everything limit-removing would be an okay first step. And this step alone would allow to play Freedoom levels in just about anything but the most strict source ports.

Maybe. We'd need a list of all the maps that use boom extensions and how extensively they use them to see if that's feasible. I know a few maps that use Boom's silent teleports for fake room-over-room would break.

esselfortium said:

How many of those are maps that have been in Freedoom since the dawn of time and ought to be replaced anyway, though? (I haven't kept up with things lately, so I'm not sure if that's still the case.)

I don't know. Someone would have to go through and tell us which ones suck and why.

[Blastfrog]

I support switching to limit removing.

[RestlessRodent]

Freedoom personally should have been a replacement for DOOM2.WAD and friends which allows it to be used in Vanilla Doom. This for example would open it up to more ports since not every single port is Boom compatible.

[Death Egg]

There's already a few maps that work well in Vanilla anyway. I just noclipped through the first four maps, and the first three seemed perfectly fine. It was only the fourth one that made the game finally crash. (Probably a visiplane error, that'll be a big issue to get around in making everything vanilla compatible)

[wesleyjohnson]

Same old discussion of trying to take over FreeDoom for the Vanilla camp again.
As said before, make your own Vanilla FreeDoom, copy the Vanilla maps you want, and then wait a few years for the empty slots to be filled in. Can't you afford the disk space for a Vanilla FreeDooom ??
Will you STOP trying to take over an established Boom wad. Many of us spent considerable time making our contributions, because it was a Boom wad.
Please refer back to the numerous other times this has been discussed, it has not changed.

[esselfortium]

For once I'm going to agree with wesley (!) and say that I think a fork of Freedoom would be a great idea. It's probably the only way at this point to clear out all the ancient stuff and junk tradition, and get some creative direction and new leadership in the project.

Most of the base assets for PWAD compatibility already exist and are "good enough", so it would make a good base to fork Freedoom to be a new game (something without "Free" or "Doom" in its title) with new levels and its own stylistic identity based on raymoohawk's artwork. The PWAD-compat stuff can stay as-is since it's already there, and the focus can be on making the built-in campaign itself worthwhile and unique.