ioquake3 tends to not change gameplay of baseq3 in order to preserve the original experience
So, what’s the best thing to do for someone who wants to e.g. fix some minor bugs or add nice little optional features? Where to submit the patches?
Here are some candidates I found:
baseq3a - tries to stay true to the original Quake III Arena look and feel, while adding nice improvements like higher-quality models, improved spawn logic, UI features like demo filtering and sorting
Lilium Arena - created relatively recently, and, according to the description, seems like the best option?
maintain the original Quake 3 gameplay, visuals, and audio experience while also providing a reliable code base for derivative projects
Mint Arena - a lot of patches, but requires a compatible engine
Open Arena - might have gone too far for my liking with gameplay changes. Also seems to have turned into a personal semi-archived project, doesn’t accept contributions.
Non-Quake id Tech 3-based games:
ETLegacy - seems pretty active (14 000 commits), but the license is GPL-3.0-or-later, i.e. requires an upgrade from GPL-2.0-or-later (see Upgrading the license of an ioquake3 based project to GPLv3+). Also the original Wolfenstein: Enemy Territory source code, being a game released after Quake III, has quite some gamecode bug fixes.
I don’t like how scattered the contributions are. A bugfix lands in one mod but doesn’t land in another.
I really wouldn’t like to make another repo with all the patches I would like, because, let’s be real, this idea is just going to turn into xkcd: Standards.
My present view is that I and others “fixed” a lot of things in ioquake3 at the expense of not preserving the original Quake 3 visuals, audio, and gameplay (with it’s flaws).
(The railgun pickup item uses effects color in ioquake3 cgame but is black in original cgame for example. OpenGL2 renderer has incorrect brightness. OpenAL sound fall off, looping sounds, and doppler doesn’t match the original Q3. There is probably many such differences.)
Sometimes how something is phrased can sound like a feature or a bug fix so it can be kind of difficult to decided if it’s a bug that should be fixed. Though in this case it seems to just be different behavior than in Quake Live which is a separate game with separate behavior and flaws. In my opinion this proposed change is a feature not a bug fix.
Perhaps you could focus on creating your own mod with altered behavior and contribute solutions to Quake 3 software errors to ioquake3 that do not change the visuals, audio, or gameplay.
But by this you mean mostly the engine changes, right? Or are you saying that QVM (/cgame and /game) changes are also welcome in ioquake3?
Yes, I agree, this change might have gone too far on my scale of “fixes vs features”. Especially that, as I discovered later, it changes how the damage is dealt (it would take 4 from armor and 1 from health with each of the 22 pellets, as opposed to 7 and 3 times 11, because of this code).
But, perhaps as long as it’s off by default, still might be OK? There is lots of CVARs in vanilla that can change gameplay significantly, e.g. g_speed, g_knockback, g_quadFactor.
But yep, perhaps this can be a bit controversial.
Yes, I have created a few repos where I add changes that can be considered significant. Essentially those are end-product mods.
Yes, it’s clear that if a change matches this description, then it can go to ioquake3.
However, there are lots of gameplay-related bugs (which clearly are bugs), and I’m looking where to funnel fixes for them. To name a few: