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

We are reading what you write, Baker, but you're just talking vaguely about Darkplaces. I don't use DP. I just happened upon the functionality in FTE, and I liked it -- actually, I didn't even realize it was different; I just knew that FTE did exactly what I wanted/expected it to do -- it used the player.mdl file that I dropped into a folder.

Now you're saying that pak files are good because they let the modder know 100% that the mod will work for the user, but you've previously been talking about how Arcane Dimensions installs everything unpacked, so it doesn't have the issue of pak files overriding user content.... It's like you're telling me I should do it two different ways! Why can't I have both the convenience of putting my mod files in a pak to ensure easy/correct installation, and also have the ease of letting more tinkery users drop in their own content if they want to?

Sure, they might mess things up, but this is the same issue as any other piece of software you give to a user. The user might mess things up. If they do, they can just delete and re-install the thing....

What I'm now hearing from you and mh is, "protecting the user from himself."

Like if the user installs some replacement content, then later derps out and forgets he installed some replacement content, and can't figure out why there is replacement content in his game....

Would not the same thing apply if he were using extra pak files?

Is Quake 1 really a game for derps? Is that the kind of user you are designing Mark V for?

Everyone derps out sometimes, but unpacked replacement content would still be easier for a derp to find/remove than stuff in a pak file, because it's all easily visible unpacked. In a pak it's hidden.... "What is this pak4 thing I have in my folder? I do not know. And why is my player model so weird?" vs. "What is in this progs folder? Oh, there's a player.mdl in it. Oh! That's why my player looks so weird!"


So, mh says for both pro and con, "it makes it easier for the user to change things."

I don't know why you're not having a zen moment about that yourself.... You strike me as the kind of person who would use linux because you'd hate Microsoft always "protecting you from yourself" and not allowing you to change things you want to change.... This reminds me of an old commercial: https://youtu.be/FxOIebkmrqs

So do you think it should be easier or harder for a Quake user to change things? Apparently "harder?" So you're a Windows guy, eh? :D

(I'm actually a Windows guy myself, but I'm a superhacker, so I make it do what I want ;)

Ya know, the whole reason that Quake is still alive after 20 years is because it was relatively easy for users to modify stuff.... Zen moment? Should it be easier or harder for users to modify stuff in Quake?

You also throw in that it's about protecting from malicious/badly designed mods... Uh, isn't that backward? Unpacked file preference would help protect from bad mods, because the user could easily see/change unpacked files or replace stuff in a pak file with their own stuff (a bad autoexec in a pak file, for example).


As far as "expected behavior," well, it's "expected behavior" (how it has "always" been) that you must put the Quake CD in the drive to play the soundtrack. But now we can drop mp3 files into a folder and play the soundtrack.... That "expected behavior" was changed to make it easier for the user. This is the same concept: let the user easily drop in files for Quake to use. Should we not allow that because some derp might drop in the wrong mp3 files and then wonder why Ace of Base is playing when they start Quake? :D

And I have to ask, "expected behavior" of whom, really? Certainly not any new players, or other people who have never messed with this stuff in detail. Heck, I don't regularly mess with it in detail, and I actually expected a player.mdl to be used just by dropping it in a folder! Then I was like, "Wait, why is this not working? Oh crap, the pak file overrides it."

So I ended up having to stick my single replacement model into a pak file.

What a hassle. I can't imagine that's good for anyone, no matter what they expect.

And being that many experienced users will be using other engines like Darkplaces and FTE, well, their "expected behavior" would not conform to the 20-year-old way either.

So maybe some old Quakers are "expecting" it, but I bet if you gave them the option, they would prefer it to work in a different, more convenient, way.


Actually, Baker, if you have links to the multiple discussions of this issue you've had in the past, I'd be glad to look them over to see what else I may be missing.

mh, I'd probably be against you on the stuffcmd issue, heh. It is a useful tool for modders -- aure, abuse is possible, but I use it to bind the FvF chat impulse so players lower their gun and blow smoke while chatting. But I think Mark V has some cfg protection for stuff like that. 

"just stop using paks."

Sounds so easy, but in practice that means I'd have to completely unpack my id1 pak1 and pak0 files. That's a mess of files! (I'm not just talking about my mod, but every mod with a pak, and also standard Quake.)

And just because I might want to use a replacement player.mdl ?

Heck, it's actually easier to complain a lot about it and hope Baker might consider changing it ;)

(But really, it's not just to make things easier for myself, but for other people as well). 

There are low-brow engines and high-brow engines.

Low Brow Engine - Your TV remote has 4 buttons (Mark V)

Favors an uncomplicated and reliably smooth and enjoyable experience and will sacrifice options, capabilities and preferences to get there.

Assumes the user knows nothing, has guard rails. Caters to the user that knows nothing -- protects them. Most features are obviously exposed, few features beyond core feature set.

When no one has any questions or problems, the Baker feels like "Mission Accomplished!" It's reliable and intuitive!

High Brow Engine- Your TV remote has 106 buttons (DarkPlaces/FTE)

FTE/DarkPlaces.

Caters to advanced users. Plenty of settings. Plenty of capabilities. Support for cutting-edge techniques. Boundless depths, options, abilities.

Assumes the user knows everything and caters to the user that knows everything. Has layers and layers of features beyond the obvious ones.

When a user has something sophisticated they want to do and realize that FTE can do it, Spike feels like "Mission Accomplished!" It helped someone with sophisticated needs execute their idea!

(This is why Spike and I seem to argue a lot about some things, but agree about others.) 

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