"Clearly it makes no sense to change this behaviour except to keel to the whim of a single individual."

Uh, no.

I've laid out clear, concrete reasons why it "makes sense," which have nothing to do with my whims.

And I'm going to count at least 3 people here that might prefer it the way I am advocating for. Make that 5:

Myself
Pritchard
mankrip (for a command line parameter to allow the option)

And I will count:
FTE
Darkpalces

(their creators obviously preferred this functionality)


You see me arguing for it, but I am arguing as "the user" and not just for myself. This would make it easier for every user.... It's just that every user doesn't read this forum. Do as I have suggested -- make a poll on Quakeone where there are more users, and see what everyone else actually thinks. 

Count me in with mankrip re: the command line switch to change the behavior. Why not give the user the option? I don't see the downside. 

I hadn't really considered the "versioning" aspect of pak files, but it certainly does make it easier when, on the rare occasion, I update the contents of the FvF client pak file, to know that all the user will have to do is replace their pak file with the new one and they will be correctly updated. If I were handing them the mod as unpacked files, that could be messy and tricky if I ever removed some of the files.... I'd have to give special instructions to delete certain files during the copying of the new files.

So that's another reason why I use a pak file for FvF -- easier/more foolproof updates for the user.


And I too would be happy with a variable to alter the file/pak precedence. That would still make it easier for people, because I could tell them, "you need to set this variable to let your replacement model work correctly." 

A command line option doesn't seem objectionable. I'll consider it without making a promise as to when.

So it is very likely to happen, unless it somehow interferes with something else. Which doesn't seem likely.

Having the option available would be nice, there are sometimes it is nice to change things on the fly easily.

I just don't like that as normal default behavior. 

Excellent. Thanks for considering it.

I'd also hope it will includes a console variable for easy setting, even knowing that would be something like, "this setting will not take effect until you restart Quake/the map/whatever is required."

I wouldn't dare suggest a menu setting, knowing how much you hate menus ;)

But then again, a menu setting would make it easy for the low-brow derps who Mark V is intended for!

*Throws an FvF ninja bomb and runs away* 

I'm disappointed Baker. 

Stuffcmd("screenshot")

Nice denial of service you have going there.

You see Gunter - you need to think beyond what you immediately want. 

Yes, I already agreed that abuse was possible. I just said so.

But do you remove all the potential valid, good uses of the command because of hypothetical bad uses? (Has your example ever actually been used in a mod?)

Hey Baker, I think mh is asking you to prevent screenshot from being used in a stuffcmd!

Mark V already protects your cfg file getting messed up by stuffcmds.

I can't think of a legitimate reason to allow stuffcmd screenshots.... So that's something that could be prevented.

But removing the whole stuffcmd functionality would be throwing out the baby with the bath water. 

There's no simple way to implement a cvar for it, because config files are only loaded after the filesystem is initialized. It's impossible to make a cvar change the filesystem initialization behavior.

Now, if such a cvar would be used to change the filesystem behavior on the fly, that would open a can of worms, specially on engines that supports changing the game directory on the fly: Set a mod dir, change the precedence, and add another mod dir; the precedence of the previous paths gets screwed. 

And that's why you wouldn't make a good engine coder.

In the end, Baker is interested in improving his engine for the users, and not just winning an argument for the sake of winning an argument.

Actually, that's why I post here too -- not to "win arguments" but to improve Mark V for the users, of which I am one!

My ideas of what might be an improvement may not be the same as other people's ideas, so we argue about it, but it is not personal, not even with mh for me (he's done great things for Mark V), though sometimes I can't tell if he gets caught up in just wanting to win the arguments or not ;)

In the end it would be silly to stubbornly refuse something that several people are stating a preference for, if the only reason is "don't give in to Gunter." Baker is not that petty!

And I'm certainly glad other people do speak up to state their preferences here, so that mine is not the only voice. 

It's not about whether I would make a good engine coder. I probably wouldn't but not for the reasons you gave.

It just appeared, from an observers POV, that you basically bullied and harassed Baker into adding a feature after he gave you plenty of well-reasoned answers as to why it wasn't a good fit for the engine.

I mean, I have asked him to include stuff from time to time but I am in awe of the relentlessness of your stubborn pleas.

Maybe I am just better at taking no for an answer. 

There were wins here.

Gunter did argue annoyingly hard.

Then again, he did eventually suggest a viable solution -- which no one has ever done before -- in the idea of making off by default but with ability to opt-in.

mh signaled he had complicated feelings on the subject and I've used DarkPlaces before for some deep modding where the functionality was helpful.

I've also seen DarkPlaces beg and scream for help because they messed up something so terribly bad and no ones wants to reply to them because usually it's a super-newb who barely can find their Quake folder so they get the "leper treatment" or insightful advice like "delete your Quake and reinstall".

So ... I think I'll have a beer and hope to laugh about this in the future. ;-)

/Gunter has found some very, very obscure bugs in the past. And spotted inconsistencies few would notice, allowing them to be resolved. 

You surrendered like a Frenchmen! D:< 

"Gunter did argue annoyingly hard."

I do everything annoyingly hard!

(That's what she said!) 

Fifth's joke was better. 

I shall prepare a PowerPoint Presentation to prove it was not.... 

Is 64-bit Linux support coming? That would be awesome. 

There is a Linux version available on the Mark V page for those interested in provided feedback and willing to experiment.

A few people have said it works very well. One person had some audio issues with their sound system. Tested on Ubuntu, told it works fairly nicely with Debian.

Your mileage may vary. 

No makefile for linux. :( 

I may have missed something in the avalanche of posts, but when Gunter started talking about having to unpack the id1 pak0.pak and pak1.pak files I started to wonder if there's a fact being overlooked...

The pak file precedence over loose files only applies within a game directory, right? I believe it is the case that a loose file in a game (mod) directory takes precedence over any file in id1, regardless of whether the id1 file is in a pak or not, correct? Is everyone on the same page about that? 

Post #874 has compile instructions. 

I believe you understand correctly how it works.

But say you want to only replace the player.mdl when paying standard Quake... with the one contained in this pack:

http://quakeone.com/forums/quake-mod-releases/works-progress/9573-authentic-model-improvement.html

That becomes rather annoying to do, since it's not as simple as just dropping the replacement model into progs\id1\, because the pak file will override it.

So you end up having to create whole new "mod" folder just to use one replacement model, then you have to create a batch file to run quake -game whatever, or you have to type "game whatever" in the console if your quake engine supports it....

What happened with me is that a player took that model and applied the FvF skins to it, so I wanted to try it out. The problem is that FvF already contains a reskinned player.mdl in its pak file in my FvF mod folder.... So again it was not so easy to just drop in the player.mdl and try it out.

So Spike suggested "stop using pak files" and that's why I described having to unpack the id1 pak0 and pak1 files too, because even if I'm not playing FvF (or any other mod with a pak file) I'd still have the same problem if I were trying to just replace the player.mdl (or some other model) for standard Quake. 

OK I'm going to try this one more time.

The way Quake has always loaded content goes like this:

- Gamedir 1/PAK files/Loose Files
- Gamedir 2/PAK files/Loose Files
- Gamedir 3/PAK files/Loose Files
- Etc.

(And yes, even stock ID Quake can load more than one extra gamedir; try -rogue -hipnotic -game XXX").

Here is the Quaddicted Single-player maps archive: https://www.quaddicted.com/reviews/

This is a repository of content all authored under the implicit assumption that certain Quake engine behaviours are consistent.

I say "implicit" because I'm absolutely certain that none of these authors (or at best very few of them) ever sat down and actually thought about this. But nonetheless the assumption is there, so please don't try to play silly buggers about it.

Change the content loading order and do you know what is going to break in those maps? Because I sure as hell don't. So they'll have to be tested, somebody's going to have to go over them and check that there's nothing in them that breaks.

What you have is one case, and it's not even a gameplay case - it's a test case. And you're behaving as though you believe that one case should take priority over everything else. You're jumping up and down shouting "I WANT I WANT I WANT" like a child, and not showing any awareness whatsoever that there is a whole body of existing content and Thou Shalt Not Break Existing Content.

One test case in FvF does not get to take priority over the body of existing content.

Feature requests are always more likely to be listened to and taken seriously if the person making the request gives some indication that they've thought it through and that they understand the implications. I'm not seeing that from you. 

I don't think anyone has put much thought into that compatibility angle before.

Considering the volume of single player releases, it would require an enormous amount of effort to find the ones with conflict situations. 

This is the kind of thing I've been bitten by before.

Even what seems like quite simple changes, say something related to behaviour of the viewsize cvar, can explode spectacularly if a mod uses it in an unexpected manner.

I think the key phrase there is "in an unexpected manner". The definition of an unexpected manner is that you actually cannot predict in advance what the impact is going to be, so it's no good someone asking for a list of disadvantages to a proposal.

"When in doubt do what ID Quake did" is a good maxim for certain classes of changes. With the SP community having converged around FitzQuake and derivatives, "when in doubt do what FitzQuake does" is also a good maxim.

We're not just talking about engines either. I've seen enough content made with buggy tools that just happens to work because engine behaviours or quirks accept it. I've been in a "put the bugs back" situation more than once.

The onus is on the person asking for a change to demonstrate that the change is benign, or at least that's the way it should be. Changes to very fundamental behaviours of core subsystems should always be approached with extreme caution.