 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Retroquad uses the [ and ] characters to prefix parameters for scrolling.
[ is negative ] is positive The first of them in the texture name indicates horizontal scrolling. The second one indicates vertical scrolling, and it's optional. The second one must be followed by a number indicating the speed. The first one only must be followed by a number if the second one is omitted. If the speed value is omitted in the first one, both will use the same speed: ]1 horizontal scrolling, 1x speed [1 horizontal scrolling, -1x speed ]0]1 vertical scrolling, 1x speed []1 diagonal scrolling, -1x horizontal & 1x vertical speed ]1[2 diagonal scrolling, 1x horizontal & -2x vertical speed Retroquad's texture naming parser can also recognize parameter prefix characters anywhere in the texture name, allowing for multiple effects to be combined. The water in this video uses 20 textures named from *watersa]0]1+00 to *watersa]0]1+19 . The parser reads it as: *water it's a water texture sa the texture's individual name ]0 zero vertical scrolling ]1 horizontal scrolling at 1x speed +00 to +19 animated frame index The only thing I couldn't decide is whether the speed value should be in units per second or in loops per second. In the first case, big textures would need big numbers to fully scroll, and in the second case, small textures would need fractional numbers to scroll slowly. However, the first case also makes it easier to sync multiple scrolling textures with different dimensions. The reason for all these is to make texture naming as economical as possible while still being flexible, since vanilla Quake only allows 15 characters per texture name. 4) Low interest in porting scrolling to WinQuake, hehe.
Getting it to work properly in the software renderer takes a lot of work, so it's understandable. A cheap way would be to scroll the texture per-texel in the surface cache. WinQuake uses a similar method to scroll the sky overlay, which is why its movement is so jerky. This would only look good on fast scrolling textures, but at least it would work. 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 The naming convention you are using seems quite sensible. In my config file, I use:
r_texprefix_scrollx z_exit 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 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 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 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.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |