Your video certainly looks very nice. 

By the way, Retroquad animates sky & liquid texture frames at 15 fps, rather than the default 5 fps of regular animated textures. Alphamasked "fence" textures are animated at 20 fps. This was hardcoded just for that demo, but a standard for custom timing of texture frame animations would also be a good thing.

However, the 15 character limit for textures makes it a pain to add more customization. The name "*watersa]0]1+19" is 15 characters long already, and even if we remove the "sa" characters from it, there would be no room to define a 15 fps interval, which would require a special character plus two numeric characters (e.g. *water]0]1+19,15). 

By the way, sorry for hijacking the thread, but I'm just trying to encourage more coders to implement such features, and maybe define some standards for them. 

Engine issues and engine support of mapping enhancements are always on-topic. Not sure what you are apologize for.

Your results look nice and are smooth.

It seems wrong to put the timing in the text name, yet with Quake we do water, alpha masking, animated textures, etc. by the name .. so ...

The naming convention you are using seems quite sensible. 

In my config file, I use:

r_texprefix_scrollx z_exit

...just for the nifty effect (scrolling EXIT signs).

Though in some places where the mapper uses the texture somewhere else (like the start of terra4) it looks... odd. Like only the fullbright part is scrolling, and not the rest of the texture. Not that I'm complaining -- I like experimental features to play around with (as long as they default off!)



And yeah, I used chase_active, but I wanted to see myself from the front too. Mirrors were (well, they should have been...) the quickest way for me to do that, heh. I did not know about the various FTE features (splitscreen, eh?). 

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. 

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. 

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. 

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

@gunter
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. 

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.