News | Forum | People | FAQ | Links | Search | Register | Log in
Mark V - Release 1.00

* Nehahra support -- better and deeper link
* Mirror support, "mirror_" textures. video
* Quaddicted install via console (i.e. "install travail")
* Full external texture support DP naming convention
* Enhanced dev tools texturepointer video inspector video
* IPv6 support, enhanced server capabilities
* Enhance co-operative play (excels at this!)
* Software renderer version (WinQuake)
* "Find" information command (ex. type "find sky")

Thanks to the beta testers! NightFright, fifth, spy, gunter, pulsar, johnny law, dwere, qmaster, mfx, icaro, kinn, adib, onetruepurple, railmccoy

And thanks to the other developers who actively provided advice or assistance: Spike (!), mh, ericw, metlslime and the sw guys: mankrip and qbism.

/Mac version is not current yet ...; Linux will happen sometime in 2017
First | Previous | Next | Last
Oh, something else....

I found that my player.mdl in \fvf\progs\wasn't even loading in Mark V, because there is a player.mdl in the fvf pak0.pak file.....

But the replacement player.mdl did load in FTE when running FvF.

I believe, no matter what the original default was in this case, that if a user has replacement content in a folder, unpacked, it should override anything in a pak file.

FTE seems to have made that choice, and it's a good choice.

I remember the complaints about "toxic settings" in an autoexec or other file inside a PAK file, and how that completely takes control away from the user (and placing those settings inside a pak is like the worst case scenario). Well, giving preference to any unpacked files, rather than what's in a pak file, would fix that issue too.

It seems obvious that if a user places some files into folders in their mod/id1 directory, they want to use THOSE files rather than anything that might be in a pak. And a pak is the hardest thing for a user to actually modify... so it's hard to work around. 
If You Don't Like Mushrooms, Don't Order The Pizza With Them ;-) 
Is your current mission to make FvF no longer work with traditional style engines?

If you want the best of both worlds, do what Arcane Dimensions does and simply not use pak files at all!

Then you won't even have the issue you are describing, haha ;-)

Do you see what I mean? You are mixing pak files and free standing files, but no one is making you use pak files at all! That's a choice.

The logical thing is to not use pak files if you don't like Quake's loading order.

Sock never has this problem because he doesn't use pak files.

All you have to do is make a FVF2 folder with everything unpacked, and you can play around as much as you like.

You could be living the high life in 5 minutes! 
It's not an FvF issue. It's a Quake issue.

The same problem exists if someone wants to use a replacement model in their id1 folder. The pak file overrides the unpacked replacement stuff, and that's not what should happen, because if a users puts a new model in his id1\progs folder, he WANTS to use THAT one. Why make it more difficult for him?

Would your suggested solution here also be to unpack all the id1 pak files, then remove the pak files, so only the unpacked files exist in id1, so a user can then use replacement content?

Or make them run a separate mod just for 1 replacement model?

What a hassle. FTE does it correctly, in my view, and allows the user-content to take precedence. Can you explain why is it better for pak files to take precedence? They are the most difficult for the user to modify. I can understand why they may have made it that way back in 96 -- maybe they didn't want the user to be able to easily mess with Quake.... But we are way beyond that now. People created programs to get to the goodies in those pak files. There's no reason to make it so difficult anymore for people to drop in replacement things.

When a mod has a lot of files, sticking then into a pak file is the most convenient and tidy way for a modder to package the mod. If a modder chooses not to do that, it may be for the very issue I'm describing here!

Of course a pak file does take control away from the user, though, which is mostly fine, because that's what mods do -- they change stuff. But then if a user WANTS to change something himself, it would be nice if he could easily do that -- like in this case, if he just wants to replace a certain model by dropping it in (a player created a new player.mdl just for FvF).

In summary:

giving precedence to unpacked files
pros = More convenient for the user to drop in replacement content. Protects against toxic settings in a pak file overriding user cfg files.
cons = None ?

giving precedence to pak files
pros = None ? Slightly helped id keep Quake from being altered back in 1996?
cons = prevents easy drop-in replacement content. You have to use a new pak file instead. If a mod contains toxic settings in a pak file, there is no way to prevent them from being initialized.

Am I missing something? 
If files in a folder override pak files, why have the pak files at all?

Quake for 20 years has had pak files have the precedence.

FVF is fully under your control. If you don't like the behavior of pak files, do them free standing files like Arcane Dimensions.

Arcane Dimensions, because it uses no pak files, doesn't have the issue.

If you don't like the behavior of pak files with your mod, then don't put the files in a pak.

1) Doesn't require anyone to do anything.
2) Compatible with every engine! 
...Quake for 20 years has had pak files have the precedence...

To me this reads as:
...Quake for 20 years has done things the wrong way...

It seems pretty obvious to me that whatever is included with the game (pak0.pak, pak1.pak) should be overridden by any new content.

It's 100% true that if you really want to solve this problem in your own mods which use their own folders, you should not use .pak files. There's no changing the way that some engines will behave at this point.
But why make using them so difficult in engines which are under active development? pak files keep things neat and make it harder for unwitting users to break your mod and so on, but the penalty a mod author incurs when using them is unnecessarily great. 
Where do you stop?

DarkPlaces loads every single .pak file found in a folder. And loads .pk3. And loads the pak files in alphabetical order. And supports a rainbow of file format from .tga to .jpeg to .png and probably others like .dss. And a rainbow of model formats.

Others want things simple.

Like the Quake way. 
Spike will say with pride that FTE loads external replacement textures from, I believe, 132 different possible folders -- supporting all the various replacement texture schemes. There are also different replacement model schemes.

A conservative engine wants 1 folder where something goes and one set of rules where that set of rules = QUAKE.

There isn't a right or wrong. Just an approach.

A conservative engines wants to stick with simple. 
It's Quake.

For every one person who wants something done one way, there's going to be five others who want it done five different ways.

The only thing you get by asking multiple people is multiple answers.

The closest thing to any kind of community consensus is "do it the way [Popular Engine X] does".

Gunter in particular has a very bad habit of "what I want for my mod is more important than anything else", then causing drama and outrage over it. I'm not certain that's useful feedback.

Quake already has an established way of allowing standalone content take precedent over pak files - put it in a gamedir of it's own. Multiple gamedir support is trivial to add to engines (and far more useful than arguing the toss back and forth over things like this).

A general-case solution that's more useful to everyone is always better than a special-case solution that just keeps one person happy. 
The PAK file precedence is part of Quake's copy protection. One of Quake's selling points was: if you want to play custom content, you must buy the game.

PAK0.PAK has its CRC value verified by the engine. If the proof-of-purchase file (from PAK1.PAK) isn't found in the path, Quake refuses to load anything but the unmodified PAK0.PAK file, which contains the shareware episode.

The PAK file precedence also served to prevent users from creating custom maps using the same names of the original maps and complaining that the original maps didn't work anymore... And to prevent users from going full "FreeQuake" and replacing the episodes 2-4 with custom maps.

id Software already had people selling shareware Doom CDs full of custom content, and they decided to prevent that from happening to Quake. 
Cracked Quake Torrent When? 
Is there any particular reason why this behavior should be continued today in engines, aside from respecting id's desire to, y'know, actually sell a game and make some money from their hard work? In the modern world of filesharing, it's such a lackluster form of copy protection that it may as well not be there at this point. 
DarkPlaces has its own set of special rules for content, which you have to learn. Many modders for DarkPlaces struggle to make Quake compatible mods because they have habits that don't work with Quake. 
(you Knew This Was Coming! :D) 
"Where do you stop?"

You stop at making unpacked files take precedence over pak files. That's it. Don't use a fallacious "slippery slope" argument like, "but if I make a reasonable change, then I'll also have to make every unreasonable change everyone else wants!" This has nothing to do with supporting all the formats Darkplaces or FTE uses. You still haven't explained the benefit of leaving it "the way Quake has done it for 20 years?" That's not a reason. How many other non-optimal Quake behaviors have you already changed?

"It's Quake. For every one person who wants something done one way, there's going to be five others who want it done five different ways."

Well, so far you've got more than one person wanting unpacked files to take precedence, and NO ONE wanting it the other way, other than people just saying, "that's the way it has always been" without providing any benefit for that approach.... How many other non-optimal Quake behaviors have you already changed?

Will anyone step forward and say they prefer pak files to take precedence, and give an actual functionality reason for that?

"Gunter in particular has a very bad habit of 'what I want for my mod is more important than anything else', then causing drama and outrage over it. I'm not certain that's useful feedback."

Oh, bite me, mh :P

I just said this isn't an FvF issue -- it's a Quake issue. This would be better for everyone. I have laid out my actual arguments for why, and you have not provided a single counter argument to support your position other than, "I don't like when people want different things and I don't like Gunter because he always out-argues me" ;)

"A general-case solution that's more useful to everyone is always better than a special-case solution that just keeps one person happy."

I completely agree with you, mh! But that supports my (and others') position in this case that the behavior should be changed, because it would indeed be a general solution that would be useful to everyone!

I am dramatically outraged that you would think otherwise!! :D

Can you explain who it's useful for to leave pak file preference in place? Modders who want to inflict unavoidable toxic settings on the user?

I'm aking the same question as Pritchard here, "what benefit is there to keeping this behavior?"

Nobody is answering except to say, "it's always been that way and I don't like the complicated things Darkplaces does."

We're not taking about Darkplaces. We're talking about this ONE behavior. That's where it stops (in regard to this issue). This isn't a change that's going to cause any compatibility problems either....

Please describe the benefits of pak file preference. mankrip did a pretty good job of describing the benefits id saw back in 1996.... Now what is the benefit in the modern day? Isn't the whole point of engine development to improve on the original things that might not have been optimal for the users? I mean, why didn't we keep id's original network code? ;) Would it still serve any useful purpose today, or would it just make things more difficult for the user?

In regard to why I, as a mod author, use a pak file to distribute the FvF client files? Because it's the most tidy, convenient way to distribute a mod, instead of using multiple files and folders. AND it also keeps the user from easily being able to nose around in the files to swipe them for their own use! Heh. So yeah, a pak file still serves as a slight (very slight, really) deterrent for pillaging my content, however, I don't mind if the user wants to use other replacement content on top of mine, and I see no reason to make that a difficult process for them.

Again, this isn't just for FvF -- it's for anyone who wants to use replacement content for Quake with or without mods.

If you're looking for some form of consensus, why not run a poll on Quakeone? Then maybe someone would give an actual functionality reason for preferring pak file precedence.... 
You are new to a discussion about this topic.

I've read or even participated in this same exact discussion 6-8 times, including a couple of times at Inside3D and a couple of times at QuakeOne.

I used DarkPlaces before I ever engine coded and experienced firsthand the pros and cons of the functionality. I also like DarkPlaces as a total conversion engine and both Mark V, and before it, ProQuake acquired several gems from DarkPlaces.

It is safe to say my opinion of that DarkPlaces feature is due to knowing a lot about it works.

Typically, the those arguing for the DarkPlaces way of doing things is inexperienced with using the the feature, and unable to describe the downsides because they don't have the experience to understand the other side of the coin.

And perhaps I'll try to explain again. But probably not today.

Seems like no one is reading or making an effort to understand what I am trying to communicate in my replies.

I may be typing this post just "for fun" as it seems the other ones went unread.

But I hope it does get read ... 
OK, I'll bite.

The upside of having loose files take priority is that the user can easily replace PAK file content.

The downside of having loose files take priority is that the user can easily replace PAK file content.

Think about that - and if you don't have a Zen moment when it becomes clear, you haven't thought about it enough, so think about it some more.

This isn't just about copy protection, it's also about protecting users from malicious (or just plain old badly designed) mods and from themselves.

Whether you like it or not, the way Quake has done it for 20 years is the EXPECTED behaviour. Mods are made and released on the assumption that this is the way it behaves, experienced players run Quake on the assumption that this is the way it behaves, experienced players help out struggling newbies on the assumption that this is the way it behaves.

If it's in a PAK file it takes priority. This isn't about advantages of one vs advantages of the other. PAK files taking priority may even be the inferior option but that doesn't actually matter (I have an opinion too but it's irrelevant). It's about what everybody expects to happen.

You may have a different expectation but don't be so arrogant as to presume that your expectation should overrule 20 years of everybody else's experience. 
The way Quake works, if you have a mod with a pak0.pak in the folder (let's say -game zer) you have 100% assurance the mod will behave properly.

With the DarkPlaces way, a user will say "I don't know what is wrong? I have pak0.pak in place, but some weird model is showing up!"

Later they will say ... "Oh, sorry. I was doing XYZ and forgot to delete it."

The DarkPlaces way takes away the security of knowing a pak file containing a mod is a complete and full assurance of proper installation and running. 
I should add.

I do understand your frustration to a certain extent. I am the person who fought, and lost, the stuffcmd wars a few years ago, and stuffcmd is actually potentially dangerous to your PC, never mind just being a squabble-fest over file loading order. 
just stop using paks. you complain that paks taking precedence makes it hard for users to replace files, but you forget that any paks make it hard for the user to know which files they need to replace (and the form of that data too).

that's not to say that I agree with Baker, frankly I see his argument as user-hostile that further discourages people from grouping their content thereby making it MORE likely that people will be stuck with content that they forgot to delete on account of not being able to separate it so easily.

quakeworld downloads often REQUIRE files outside of paks, or at least maps.
The singular exception is when you have md3s or q3bsps that depend upon shaders and external textures that the client won't know to auto-download. In these cases, pk3 is a superior format that offers compression and is easier for people to open. Essentially, such content should be treated basically like q3 content is treated. But until then, just don't use paks. 
PAK files also serves as a versioning system.

If your mod is fully contained in a PAK0.PAK file, you can make an update for it by storing the updated files in a PAK1.PAK file. And then, you can revert to the previous version by simply removing the PAK1.PAK file. I've actually done this in one of my mods, because it gives the advantage of knowing that the PAK0.PAK will likely always be the same, no matter the version of the mod.

Loose files doesn't use a cascaded versioning filesystem, so they require you to remove all previous versions of the files, which makes it impossible to rollback a bad update.

Anyway, a command-line parameter to control the precedence could be nice for development purposes. 
Why Is This Getting So Much Attention? 
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:

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). 
Low Brow Vs. High Brow @spike Mostly 
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)


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:

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

And I will count:

(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 Wouldn't Have Submitted 
I'm disappointed Baker. 

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. 
I Dunno Man 
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. 
@ Johnny Law 
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:

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:

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. 
Ok, I see it is IS personal for mh. I think he just dislikes me because I consistently out-argue him. Well, he's going to like me even less after this.

mh, you are just being a crybaby now, but let me address your actual "arguments."

"The way Quake has always loaded content"

Yes, that's been pointed out repeatedly. But as Pritchard said, that's like saying, "Quake for 20 years has done things the wrong way" Or, if not strictly "wrong," then certainly in-optimal.

"Change the content loading order and do you know what is going to break in those maps? Because I sure as hell don't."

I do know: Not a single damn thing. Nothing. Do you know what kind of contrived situation would have to exist for the loading order to break map packs? The mod would have to install both a pak file AND unpacked files with the same names, yet with the files in the pak being the only ones that are supposed to be used, because for some reason the unpacked files with the same name are not the same files....

Seriously, HOW ELSE could the file load order mess up a map pack? You probably can't even come up with a realistic situation where it would, without your user do really weird stuff (which could happen no matter the load order). Maybe if the map installs as a pak file in your id1 folder and you already, for some reason, have different maps with the exact same name unpacked in your id1/maps folder??

The fact that you don't see it wouldn't cause a problem except in an extremely contrived circumstances shows that YOU are the one who isn't thinking this through.

Your flimsy argument amounts to trying to whip up fear of a boogeyman which would never actually occur unless you intentionally tried to make it happen. "But something might break! You just don't know!! Think of the children!!!"

You're grasping at straws.

Seriously, are there any maps/mods on Quaddicted that say, "this will not work with Darkplaces or FTE for some reason"? No? I'm not surprised.

"What you have is one case, and it's not even a gameplay case ... One test case in FvF"

Uh, no. I said it could impact anyone playing any mod or standard Quake if they wanted to easily use replacement content. I've pointed that out repeatedly. Do you not comprehend?

"Not even a gameplay case?" What? This isn't some hypothetical thing I came up with out of nowhere -- I never would have brought up the issue if it had not IMPACTED MY ACTUAL GAMEPLAY. Do you not comprehend?

You characterize me as crying like a child, but it's you, mh, being the crybaby. You're just being ANGREH. You don't have actual good points to support your position -- just hypothetical boogeymen which it's clear you didn't even think through (or you would have realized how ridiculously improbable it would be to actually break any of the maps from Quaddicted).

"When in doubt do what ID Quake did"

See, that's rich, because in the past when I have argued for using Quake's Default Behavior instead of some change Baker has implemented (centerprint position, or start map guessing), you have thrown the same whiny bitchfit over it. So it seems it doesn't matter whether I'm advocating for Default or not -- you're just against whatever I suggest.

(Normally I like Default presentation to the user, but this is behind-the-scenes, to make replacements easier)

"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 can only laugh at this :D

You're not seeing a LOT of things, mh.

So don't even worry about it. If some weird, obscure issue pops up because of this change, you can bet *I* will be the one to find it! I'm the one who has been finding the weird, obscure bugs that result from the changes Baker has made, because I have an extreme eye for detail and a meticulous mind for thinking on many different levels. So just because you "sure as hell" can't see what might beaffected, don't worry -- I can. ;)

Now, was any this necessary, mh? Nope. Baker already decided to leave the default behavior in place and add an option for the user to change tit. Yet you still felt the need to make a fuss and post at me with silly arguments and insults, because, apparently, you are a sore loser. And like FifthElephant, you just didn't want to see me get what I want.

Now, I normally do not post at people in such a demeaning manner as I have at you here, but this is certainly how I respond when someone insults me the way you decided to. So, if you don't like this, then refrain from making such petty characterizations of me in the future :p and then I will stick to addressing your actual arguments as I normally do.

Baker, don't let the "compatibility scare tactic" dissuade you from this -- you know if it produces any unexpected negative issues, I WILL find them! ;) 
mh is relating his experiences involving the development of DirectQ. He is not referring to you at all.

I watched some of the DirectQ users "carp" on mh with insisting DirectQ must do certain things.

Something unseen here is that very few engines end up surviving compatibility.

I could tell you things that crash qbism super8 hard. I could tell you things that don't work right in FitzQuake. I can tell you things that don't work in Quakespasm.

mh and I work well together because we view compatibility as #1.

/So please leave mh alone. I already said what I plan to do. 
Might add that I also know single players that have problems with Mark V's automatic impulse 12 support. If you are serious about compatibility, you know your own engine's weaknesses as well. 
Seriously, are there any maps/mods on Quaddicted that say, "this will not work with Darkplaces or FTE for some reason"? 
Remove: "single players"
Substitute: "a couple of (rare) single player mods"

/Premature submit strikes again! 
Now, was any this necessary, mh? Nope. [...] And like FifthElephant, you just didn't want to see me get what I want.

I wish someone wanted my naked body that hard. Now I'll feel jealous of Baker too. 
@Baker "He is not referring to you at all."

Ah, well, then I must have misunderstood when he used my name ;)

But it's no big deal for me, really. I approach internet arguments like a Quake Deathmatch: whether you win or lose, it's all for fun, and it's not worth getting legitimately upset over. :D

@mankrip Yeah, I guess I really should have specified I was talking specifically about compatibility with Darkpalaces due to the unpacked file preference is has. I have no idea about all the many other differences in Darkplaces, and what compatibility issues they may cause.

Actually (side story), I remember several years back I tried using Darkplaces for the FvF server, but I encountered compatibility issues.... I think I emailed LordHavoc about it, and it was something about either checkbottom or some other way to see if something was on the ground, and what I was doing in FvF wasn't working in DP. LH said that code never really worked right in standard Quake or something.... In any case, I went back to proquake server, and I don't know if the problem would have been fixed by now or not.

So yeah, I understand compatibility issues are indeed important, but "compatibility problems have been caused by other things" isn't a valid argument in this specific case. Do we never try to change/improve anything due to fear of incompatibility? No, but of course, we do tread carefully. 
"I wish someone wanted my naked body that hard."

Well, just make a quake player.mdl with a skin of your naked body, and it will be REALLY EASY for people to drop it into their game once Baker makes the setting available!

(And NOW I see the downside!! What have I done!??) 
Ok, now that this is all settled ...

It's June. It's great weather and sunny ... 
It may be sunny now, but not for long!

Anyone else going to catch that full eclipse in August?

It is passing DIRECTLY overhead for me -- I am right in the center of its path.

I guess all those sacrifices to Shub-Niggurath are having an effect! 
I'm in the southern hemisphere, and it's winter now; no snow, though. 
"But it's no big deal for me" - Gunter after 3 scroll pages of bitching.

Please don't include me in your diatribes either, I was poking fun at you light-heartedly. Baker clearly got this. 
Ok, got it. You are allowed to "poke fun" at me, but I'm not allowed to mention what you said. That's a reasonable expectation. 
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.