Mark V supports external vis which allows, for instance, true transparent on id1 maps without vispatch
Thanks, I'll have to check this feature out

I do wonder if using such brushes would improve maps... It's another layer of work on top of what is already required but with some bigger maps it could be worthwhile.
If you do it correctly then yes. Problem is if you have big open spaces, then it won't help you much... although in my case I used it to cut portals behind big building standing in center of open space.

I like this "tutorial". Explains it properly:
http://omnicide.razorwind.ru/wiki/index.php/Tutorials:Understanding_a_VIS_and_Hint_brushes 

What did more modern engines such as Source do to improve their VIS? Half Life 2 has plenty of huge open spaces that run well. 

Half Life 2 (Source) is using PVS and occlusion culling for outdoors. 

So how is PVS (Potentially Visible Set) different from VIS? The Valve Dev wiki describes PVS as a collection of visleaves which might be visible from a given location. Isn't that just how VIS works? 

VIS is just a tool/process of creation of PVS, so to be 100% correct with nomenclature, we shouldn't use it to describe PVS ;)

Anyway we are OT a little, maybe we should move with this conversation to Mapping Help, before Baker gets mad :P 

For the curious: https://developer.valvesoftware.com/wiki/Visibility_optimization

By the way, Source uses vvis.exe. 

I needed to look at a modified FvF player model in a mirror today, but could not do so because Baker took away the mirror control from the user....

"The Id1 Mirror Texture Only Works With Id1 -- It's Intended Behavior
...
if someone is playing Soul of Evil or Travail or something and some random texture is pointlessly a mirror because it is window02_1, that would be annoying as hell ... "

But r_mirroralpha is a user-controlled variable, and if a user wants it on, it should be on, no matter what mod they are running. It should also be defaulted to "off" ("1"), so if it IS on, then it's definitely intended to be on.


I had to load up FTE to look at myself in a mirror in FvF, and even that engine wouldn't let me activate it in Multiplayer mode, telling me it was a cheat. Boo! (I'm the server operator -- I am the one who should decide what is or isn't a cheat on my server, and I don't feel mirrors are a cheat). But at least I could use mirrors to look at the modified player.mdl in FTE Single Player mode.

I dislike when engines decide for me what settings I am allowed to use in what modes. 

I may end up coming up with a method to allow a gamedir mod to enable that as choice. 

Does Mark V supports scrolling textures? What's the name convention? 

Yeah, type "find scroll" in the console.

It's only in the GL build. 

sv_cheats 1; restart;
then you can do whatever you want.
and so can other users on your server, so have fun with that.
unfortunately nq doesn't do serverinfo, so that'll only work with an fte server.

use mirror_* for mirror textures in future. those should always be mirrors, and need not be considered cheats. window02_1 on the other hand is present on many maps, and in many of those it potentially exhibits serious graphical glitches that allow it to act as a wallhack or whatever. so yes, its generally considered a cheat unless the mapper explicitly intended it.

for similar future needs, you might want to consider using chase_active or equivalent (most engines support it to some extent), or maybe try fte's splitscreen.
its generally easier to look at it from other angles then. 

His server coops existing maps. He doesn't have any choice in what the texture names are so he doesn't have the option to change the texture names to mirror_ * 

I've tried to test it by entering "r_texprefix_scrollx wizmet", but it didn't work. I'm using the version 1.36. 

That feature was slated for removal, looks like is broke. I probably was working on mirrors and removed it, but forgot to nuke the cvar and friends.

It works in this ancient build binary + source.

The reason that feature is slated for removal is largely because:

1) I can't imagine a scenario where it could be turned into a standard.
2) This method has no ability to control the speed.
3) You can do animated textures in maps using the +[texture name] animated textures method in regular Quake and it works on everything, although it is jerky and has a 10 frame limit.
4) Low interest in porting scrolling to WinQuake, hehe.

There's also probably better ways to do it too.

Was a nice experimental feature back at the time, I just wanted to see what it would look like. 

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. 

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!