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

Honestly I'd forgotten that Mark V does that... hmm.

For almost any episode-ish thing that has a start or hub map, they use start.bsp for that purpose. On the other hand if it's just an unconnected collection of maps then I always just select the map I want explicitly through the levels menu or a launcher or whatever.

It's true that there are some older id1/vanilla maps that have a startmap+othermap combo for selecting skill, and since they expect you to place it in id1 they call their startmap something other than start.bsp. Like Adamantine Cruelty having an acstart.bsp map. If you put that in its own mod folder then it could be useful to have Start New Game infer that it is a start map, but since I'd forgotten about that behavior I always just explicitly pick the map in those cases too.

Sorry, no real opinions. I'm not sure in what situations the "guessing" behavior would be worse than not-guessing, since the worst case either way is that you end up launching the wrong map. 

I suppose one way in which it could be worse is if it guesses wrong but you don't realize for a while that you are in the wrong map. (Because you haven't played those maps before.)

Out of curiosity, do you remember an example of it guessing wrong? 

I believe that the guessing feature doesn't activate when everything is running from id1 (so it becomes useless when maps are installed in id1, as I assume a lot of custom maps packs are).

Issues I have run into include (more detailed info was upthread):

( #1251 )
Having a modified DM6 map included in my mod, and since that is the only map, Mark V assumes it should be run when I go to start a single player game. This is completely wrong....

Or, if I want to install extra maps in my mod folder (FvF can be used with custom maps, as can some other mods), then one of them will get guessed and selected when I want to start a new single player game, and it will always be the same map, either going alphabetically or looking for cues in the map name (like with your "acSTART.bsp" -- that would be selected). But that's almost never going to be what I want when I have many maps installed and I go through the menu to start a default single player game.

Baker's intent is to make it easy to launch single-player map/mod releases by using the menu; see #1253 (and you could read 2 posts later where I examined the map packs that had been mentioned to see how useful it would be in practice -- maybe 50% useful).

But I think the Levels menu is already the ideal solution for that. And it could still show the maps near the top of the list that it guesses are most likely the intended starting maps....

So to me it just seems that a feature which sometimes works, sometimes doesn't, and sometimes causes problem -- that's a feature that should not be activated by default with no way to disable it.

And it sounds like people may not even be using it anyway.... I'd assume that most people, like me (and you, it seems), would just assume that default of starting a new single player game in the menu will behave as Quake always did, and start the default game, and if we want to start a custom map we'll use that wonderful Levels menu. 

LOL at the whole "mobile gaming is the future and I'm the next Steve Jobs" nonsense. Sober up, Baker. 

Well, we can allow him a few rambling rants when he's on a few beers, as long as he becomes reasonable and rational at some point afterwards ;) 

As long as Baker doesn't turn Mark V into a mobile exclusive port, he may rant as much as he wants. 

Larger update than the norm for Mark V. 46 modifications plus some major revisions.

Download: Windows - Direct X | WinQuake (Direct X is fast!!)

Alternate Builds:
1. WinQuake GL (killpixel)
2. SDL "zero dlls" build with mp3 sound track + all controllers support

In this version:

1) Xbox Controller Support. PS4 + Steam Controller will happen later. (based on ericw help in the implementation in Quakespasm)
2) Perfect "install" unpacking for non-traditional zips (johnnylaw)
3) r_shadows 3 issue with higher vert models fixed (NightFright)
4) Big Sepulcher Support (pulsar, killpixel, qmaster reminders/nudges)
5) Multiplayer save game menu integration (qmaster)
6) Possible fix for input lag (killpixel, dabblingsquidward). Verification needed.
7) Alternate "joy_" prefixed game controller names (conversation amongst Spike, gunter, ericw)
8) DirectX 9 hipnotic decal workaround per mh (dabblingsquidward)
9) Dynamic scaling for scr_showfps 1 and friends (gunter)

10) And 36 other small or moderate enhancements including things like 64-bit killer buttons fix via ericw, small Linux enhancements and implementing tweaks from comments from many different users.

----
Next Version: Split-screen support!! (video

Now ... here's the catch ... will it be 2 weeks or next winter?

I'm a winter coder and we had a frigid April in Ohio/USA. I tend to vanish for months in warm weather. And I'm a bit burnt out.

But if there is enough user feedback, I also kind of feel like doing this sooner rather than later. I need a bit of convincing there are actually people who are actually going to use the split-screen with 2 people or more playing on the same screen sitting on the same couch. 

@iriyap - It's supposed to be funny as self-deprecating comedy through going the opposite direction. / Anyways the start of Cinco de Mayo is serious business. No time for beer rants! Peace out! 

Coolness.

Can you shed a bit more light on the functional difference between mark_v.exe and the SDL build? 

Also a heads-up... I tried "install mapjam6" as a test just now, and it went a little haywire. It put bsp files and lits directly into id1, and also discarded various other things from the .zip.

"install qump" went a bit better, but it still put the maps into id1\maps (rather than qump\maps) even though a start.bsp is among them.

Haven't tested other installs yet. 

Mark_V.exe has mh DirectX 9 uber-speed.

The SDL build serves 3 purposes:

1) Any game controller support instead of just Microsoft Xbox compatible. I don't have a PS4 controller to available to do the kind of coding/test for pure native Windows API at the moment. (I made phone calls and it was Xbox, Xbox, Xbox, Xbox. "Ok what about your friends? Xbox? Really?" What kind of luck is that? Especially since PS4 selling extremely well ...)

(Short version: Mark_V.exe all the way)

2) To see if gunter's foobared Windows XP machine can play mp3s with that because I use an entirely different direct Windows API method. I still hope he spills coffee on it, but it has been great for testing -- especially the extreme compatibility mh has offered with the Direct X 9 version (mh is simply incredible).

3) Poke Quakespasm a bit to go "no dlls". The same way Spike sometimes pokes at me about X, Y or Z (or how sometimes I poke at Spike a bit) or the same way mh occasionally pokes at me about X, Y, Z. Friendly developer "Aw come on dude!" peer pressure and all that.

Let me know how it goes with the install capabilities. I felt like I couldn't do a release without getting it right so I rewrote half of it to be very precise.