A rather heavy update is coming in the next 2-3 days. I've stalled a bit on doing an update because I want the update to have what I want rather than do it in pieces.

(I've also had trouble merging code together with QuakeDroid ... some of merging it hasn't been entirely pleasant.)

Amongst other things, I have controller support which is causing me to debate whether or not do 2 player/4 player split-screen now.

(Except that would push things back maybe a week and I really want to do an update this week ...) 

THEN prioritize your split screen addition. I suggest this for selfish reasons. I've basically switched to using Mark V as my go-to engine over the past few weeks. I'd like to do a video on Mark V as part of my tutorial series and would love to do that over the upcoming weekend. (if the release is ready and stable ofc)

My 2 cents. I'll be doing a QuakeDroid video as well when that is updated. 

Split screen is a significant enough feature. If you're going to do it, if you're going to do it right, then it's worth a release in it's own right and IMO you shouldn't hold up what might otherwise be a significant essential release for the sake of it. 

Good to hear about a new release coming in for a landing!

Controller support is pretty cool. I'm in a phase of playing some couch/TV Quake, and Quakespasm is great for that but it's a little tedious to not have a level-select menu there.

Of course the complete set of "controller support" features would include a menu-y way to also choose the mod and any necessary game switches like hipnotic/rogue/quoth/nehahra... just putting that out there. :-) I know there are reasons that this has not been done by most engines, especially as a top-level menu item. 

Just fyi, my short list of things I consider must have in the release is fixing the unpacking bugs that you pointed out in a couple of .zip files that were packed differently than traditional .zip file releases. 

Ah interesting, yeah please let me know if you make changes in that regard (or just point me at the relevant sourcecode). I want to make sure my little batch file installer continues to work.

If you want to see the current list of things that it works around, you can have a look in https://github.com/neogeographica/quakestarter/tree/release/1.8/installers

There's three kinds of situations where I do something to change/fix files after doing the Mark V install:

1) The special case of making sure that quoth2pt2full gets put in a folder just named "quoth".

2) If the install puts things under id1, I move them into their own mod folder instead. Various reasons for that, but this is not necessarily a problem with the installer (unless there was a start.bsp, like with QUMP for example).

3) If the install fails to extract all the necessary stuff, or extracts some things with a truncated filename because of assumptions about folder structure.


Cases of #2 with a start.bsp: mapjam6, qump, rmx-pack

Cases of #3: arcanum, apsp3, dm4jam, func_mapjam1, func_mapjam2, mapjam6, nehahra, warpspasm 

Very helpful.

I think what I'm going to do is get an update out with what I have done now (I have 2 qmaster items I need to wrap up) and then next do a release with robust installer that handles edge cases and then go from there.

@mh - Yeah, I think I'll just get out what I've got rolling and due to the scope of 2 player/4 player split screen, do it separately. 

if the release is ready and stable ofc

The next release is going to need tire kicking before I'm satisfied that it is "stable".

But the next release should be incredibly robust and might even solve real old mysteries like killpixel's issues with WinQuake version lag (I hope).

I'll be doing a QuakeDroid video as well when that is updated.

Ironically, there is no way to do a QuakeDroid video myself. My phone ... which I love ... is an Android version that can't support video without rooting (which I'm not willing to do).

So a video of QuakeDroid would be nice because I simply cannot do it myself. :(

I went WAAAAAYYY out of my way, to make QuakeDroid as potent and usable as possible ... especially the console (<-- !!!) and the menu.

In past mobile Quake engines including other Android Quake engines, the console is microscopic, the menu non-interactive, poor ability to tune settings, etc. etc. 

controller note - a few days ago, I had the DirectQ source code open was about to more or less take the DirectQ controller support and put it in Mark V.

Then I had a funny thought, could the original Quake joystick code work if sufficiently enhanced. The answer was surprising.

I took the original joystick code and bashed it into a form almost indistinguishable to the very nice ericw/Quakespasm controller code, except it uses the original Windows API functions for axis/button reading. 

When the fov cvar is changed, which player will it affect?

Quake has several client-side cvars that were never designed to automatically handle multiple clients. chase_active, cl_forwardspeed, crosshair, r_drawviewmodel, and so on. And they're usually not binded to any keys, so there's no way to track from which client their value came. Also, some mods uses different default values for them, so if you create multiple copies of those cvars with different names for each player, those mods will be broken. 

You'll be able to look through the source code when it is released. 

Thanks to qmaster for the push to do this. I hadn't considered that idea before he brought it up.

In a non-supporting engine like Quakespasm, trying to load a Mark V multiplayer save will gracefully fail rather than crash the engine.

The awesome thing about Mark V multiplayer save games.

If there were 4 players in the save in let's say it a co-operative game, you can load it with only 2 players if you want.

Or load it with 1 player, haha!

Spike can't even do that :D 

/Jokes aside, the reason that Mark V can load a multiplayer saved game with less players than actually the save game is because I force it to always reserve 16 entity slots, this makes it so the player count not being the same isn't a deal breaker to QuakeC. 

huh? so you reserve a fixed number of player slots exactly like QW does, but still limited to less players?
The down side of that is that it makes servers with up to 255 players wasteful if you're running singleplayer or whatever.
So FTE defaults to 32 slots. If a saved game had a different number (like 255) then it just dynamically resizes the svs.clients array, but most of the time it just uses 32.
Frankly, loading a saved game with a different maxplayers limit is trivial.
The real challenge is making sure the players got the right slot, if eg they connected in a different order (or if someone has since disconnected, leaving a gap in the saved game, etc).

But yeah, I'm unsure what 'I' can't do here. Are you alluding to an FTE bug?
Or is the joke the idea that FTE might not be able to do something?.. I'm confused. 

Haha, maybe the joke is on me because I am now rememebering that conversation. Sounds like you told me the solution and then I implemented it -- and proceeded to forget how I got the idea in the first place.

On the plus side, I went out of my way to make sure the multiplayer save games aren't toxic to other engines.

/Yeah, I considered the issue of future higher max player limits (32, 64, 255, etc.) but realistically my main preoccupation is with co-operative play and I cannot imagine cooping a map with more than 6 players and even then players would have to fight each other off just to get kills. 

Might add, that the multiplayer save games store a bucket of cvars that are traditionally used by servers to use to add an extra level of game state preservation above and beyond the norm.

Quite a weakness in the original Quake save game format is the lack of better preservation of game state, which is more likely to be relevant in a multiplayer game. 

hey, maybe in future we'll see maps with 255 coop starts, and 255 deathmatch starts too.
but probably not.

I agree with the cvars, but you do need to balance between useful cvars and fucking over all the server's settings... obscure stuff like samelevel might sound good to save, but loading a multiplayer game then trying to start a singleplayer game could then screw stuff up, in a way that the user might not be aware of nor know how to fix. One solution is to latch the cvars to their saved values, and unlatch on map changes, but latching cvars gets really messy. 

I agree with that and agree with your firewalled system of settings. Someday I will catch up (although I have some disagreements on small issues).

That being said, you are modding an engine egregiously doing WORSE. Quakespasm runs quake.rc on every gamedir change, accumulating all kinds of random crapola ... including nasty stuff that wasn't intentional.

It is also piss poor for anything except a completely crippled luddite single player engine, especially in the long term.

Do I want to nuke all keys and reset them to default when connecting to a co-op server running a mod? Most people want to retain their keys, sensitivity, gamma, contrast, etc. and the old message about running quake.rc was superior to than implementing some very ... well ... half-assed.

Plus supporting gamedirs like quake/i_like_my_mods_in_weird_places_I_guess_I_dont_play_hipnotic_or_rogue_ever_apparently/travail

Considering Quakespasm Spiked is NOT crippled (great stuff you've put into it), what would you have the engine do if some goofus with a gamedir like that hosts a game with downloads enabled?

/Anyway, end of random thoughts on the multiplayer design topic. 

Clarity: the above is not a criticism of ericw, who I think is awesome. And his game controller code is organized so well I give it 6 stars out of 5, and made non-SDL controller code mirror that refinement!

Spike, mh and myself have long discussed vulnerabilities of things like quake.rc, oddball user preferences and I have personally watched the destruction of at least 3 engines before my very eyes.

I have strong feelings about detrimental features that take away choice or control from users or thrust chaos on them.

When users request things, they often don't understand the implications/side-effects or even how it blocks the future.

I'm not saying the user is always wrong or anything like that, but careful consideration has to be given to future implications of a change.

In the above post I outline how nice things in Quakespasm Spiked are impeded by some changes in Quakespasm basic. 

FTE reexecs configs only if it notices one of the files that it would normally exec is now in a different path.
It also saves its config to try to match the default.cfg (or config.cfg or so).
So if you switch to TF, then you get your mod-specific settings, and if you then switch to one of those map packs (that is only a gamedir because it has a new start map) then you get your id1 settings.
Note that when FTE execs default.cfg then it resets all cvars to their engine-set values before execing the rest of the config, which is meant to block undesired accumulation.
(unfortunately, custom cvars don't have engine defaults, so these don't get reset and can accumulate, especially if they were setaed. I assume that it would be okay to wipe them.)

Of course, this isn't an ideal world, so there's lots of mods that include pointless autoexec.cfg/config.cfg/quake.rc files that do more harm than good, etc. These anti-social mods will end up getting isolated.

Unfortunately other engines don't subscribe to the same ideal either, so they write config.cfg files all over the place and strip all sorts of settings, etc, even if you're not doing gamedir switching. The only way to handle these sensibly is to ignore the damn things completely, using a completely different file instead. Which of course breaks other things.
This is likely why you believe FTE's behaviour to be worse.
My solution: use FTE exclusively. :D



I'm not sure what you mean regarding downloads.
The client should have code to block downloading models named stuff like 'config.cfg', which prevents various forms of evil.
FTE will just automatically switch to whatever gamedir the server says, reloading configs only if it actually makes sense. FTE also attempts to download packages rather than files, and these have explicit gamedirs attached to them (but gah, remodelling packages!), unfortunately there's still a LOT of legacy servers that have no support for packages at all (nor the versioning that they can provide).
Regarding QSS, I never actually got around to getting it to automatically switch gamedirs (no mod-isolation code meant that I bottled out of trying), so yes downloads may currently end up being written into the wrong gamedir. :(
It does at least warn if the gamedir is wrong, but yeah, noone pays attention to warnings. 

These anti-social mods will end up getting isolated.

That line of thinking requires too many things that are false to be true.

The day of the curious user sailed long ago, today Quake is a commodity.

That doesn't mean there aren't curious users ... there are!

And if you think for a second, I've managed to do a Pokemon and "catch them all" with Mark V while punting the Steam noobsters off through trickery.

It's the Baker "cream of the crop" thiefdom steal.

And quite deliberate. So I get the brilliant ones and talent ones, while SteamNewbster123-where-is-my-Quake-folder is learning with some other engine.

The "haha funny" is that tomorrow never resembles the past. But tomorrow is easy to predict.

Tomorrow is coop.

When tomorrow comes, there won't be room for engines that suck balls at coop.

I've been saying this for years.

Sometimes I got mocked for saying that in the more distant past (I'd snicker a little and say nothing, in Steve Jobs style because I knew why -- "why" is a useful thing ... if everyone knew "why" the world would be boring and I'd never get to make fun of people for being wrong --I'm made out of a human so yeah, everyone has their faults, I'm a prankster by nature) -- but today everyone sees cooperative play knocking hard on that door.

Users often describe "tomorrow" as "today" thinking tomorrow resembles today. But that kind of "me too" thinking is why no one uses Windows phone, why Steam Machines isn't a thing, why BlackBerry was once king and is now dead.

Tomorrow isn't today. It is like "today", but more aggressive form of today.

What does tomorrow want?

/Question of the day. Someone mocked me for saying I was going to make a Quaddicted install (*cough* Spike!) then proceeded to make his own Quaddicted install in FTE. So yeah, like it or not, I suck because I understand what tomorrow is going to bring with some level of consistency but it isn't magic or even me -- it's just connecting obvious dots in an obivilious world. Not my fault!

A great question is why does this matter for a volunteer engine coding for a 22 year old game? But this rhetorical question is just me being a smart-ass again in a lot of ways -- in my head the answer is that if you can't win the small ones, how could you win the larger scale real-life ones? Which is why I find engine coding entertaining, everyone tries their best to do things right because it is somehow reflective of result generation on a larger scale.

Plus it is fun with those you've known the minds of for years!

/End stupid commentary. My next post is probably an engine release which has been compiled for 4 hours, but I have 4 beers left and we can't have that can we? 

We live in an increasingly mobile world. Mobile phones today have 53% of gaming revenue.

Quake's future will be partially on mobile phones. (Duh? Surprise????) Ok, no really).

Software decoders on phones eat 60-70% cpu. We all know CPU is battery.

That's ok. There are hardware decoders that take precious little cpu.

Clue: Hardware decoders ... 100% mpeg everywhere that means MP3.

Ogg? Uh. That's like 0%.

And if you can't hardware decode a music format on mobile, it has no future.

Now if Quake is to have a future (it does) and if part of the future of Quake is mobile (it is), where does ogg fit into that future?

Well ... under the stupid person's plan you could have ogg on the desktop (oh wait! Quakespasm supports mp3) and mp3 on mobile.

OR?

OR?

OR?

You could have MP3 everywhere.

Gee --- I wonder how this ends?

Ok --- no I don't. I've known how this ends quite a long time.

It ends with MP3 everywhere. It always did.

/Understanding tomorrow means you can extrapolate what to do today 

Ogg made sense when MP3 was still patented and an unencumbered format was required/desired. Where the Free Software world often falls down is in not realising that it's not 1998 anymore; the assumption is that rules and situations that applied in 1998 would continue in perpetuity, but the MP3 patents were always going to expire and Ogg's reason to exist would be reduced.

A technically inferior solution that has high market penetration or better ease of use will always win. The moral of the story is that end users don't give a flying one for technical superiority. They just want something that works and gets out of their way while doing so. 

Baker, you sound like you may be on a few beers too many, but I'm still going to reply with my own rant at your ranting, because you're touching on some of the issues I've had with Mark V:


What does QuakeDroid have to do with Mark V supporting OGG? If QuakeDrioid doesn't support OGG, then it doesn't support OGG (I will probably never bother copying the Quake soundtrack to my android anyway). I play Mark V on my WinXP netbook, not on my android device, and Mark V already can play OGG files (assuming the correct decoder is present on the computer) -- Mark V just doesn't bother to look for OGG files. So I have to rename OGGs to MP3, or hex edit and hack Mark V to look for OGG instead of MP3.

And as I mentioned in #1767, OGG files fix an unsolvable issue my Netbook has with running MP3 files in Mark V -- that being a long delay (sometimes ridiculously long) in loading the file in Quake. We did a massive amount of troubleshooting of my issue in the old topic, where I tried so many different things like installing various decoders, but NOTHING worked... until I tried using OGG files and the problem magically went away.

I've been holding out hoping you would do the utterly simple step of simply ALLOWING Mark V to see the OGGs that it is already capable of playing.... The other option I have thought of is either: offering a pack of OGGs files renamed as MP3 for download for people who want to use the soundtrack in Mark V, or hex editing Mark V and offering my hacked version for download on my site for other users like me who would prefer an OGG soundtrack (without confusing renamed MP3-OGG files).

This is not the future -- this is the now, and people are playing an ancient game using old computers, and those people are asking for OGG support.

You're simply wrong about this one Baker. Stop being so stubborn and LISTEN to the people who are actually using your engine. I think we know what we want... rather than what you're telling us we SHOULD want.



I also agree with Spike that switching gamedir should absolutely exec the configs in that gamedir. Otherwise you are not running the mod correctly. "game fvf" is supposed to replace the need for a command line switch "-game fvf" yet it does not, because it does not exec config files that are set up for that mod.

Yeah, we've been over this before ( #55 #68 #87 #89 ), and you always go with "but what if there are bad settings in those config files?" Then that's how the mod should run, because that is the expected default behavior of Quake when running a mod!

Basically I still need to use a command line "-game fvf" since "game fvf" does not work like "running a mod" is supposed to, and would require at least one extra step. 

Hey, Johnny Law. It looks like you are a real power user with running custom maps.

I'd like to get your opinion on a feature in Mark V (since we're revisiting some of these old issues): If you are running from a gamedir or mod with custom maps, and you use the menu to start a New Single Player game, Mark V guesses at what map to run instead of putting you in the default start.bsp (standard Quake behavior -- though actual mods can alter this to start you wherever they want).

Is this a feature that you actually make use of, or do you run custom maps a different way?


I really like the "Levels" menu that lets me specify any specific custom map I do want to run. (Though I remember there was an issue with the Levels menu being disabled when custom menu graphics are present, though me and someone else suggested it shouldn't be.. up around #1227 ).


But I greatly dislike the "guessing" behavior, and it has given me problems by guessing wrong from what I actually want, and I can't even disable this feature. It takes away user control, doesn't apply or function in some situations, and causes unwanted behavior other times (also discussed in-depth around the same location upthread).

I have to point out that it seems to me to go against Baker's credo, which he just stated:

"I have strong feelings about detrimental features that take away choice or control from users or thrust chaos on them."