I guess that doesn't give much control with a mod, other than just stuffing the list to the clients when they connect....

Beware - this way lies madness. Or at least recreating Nehahra.

The problem with on-connect stuffing is that it doesn't survive save games. So you stuff every frame instead. And then you've recreated Nehahra.

Better options exist, such as saying "this requires an engine that supports .alpha", or forking PQ and modifying it to support protocol 666 (which, if sensibly implemented, could potentially end up being taken back into the main branch). 

.ent files -- could it be made so that having "missing" information in the .ent file would let it fall back to using the original ent information (from the bsp)? For example, what if I made an ent file for e1m1 that ONLY contained the above line add the func_illusionary, without having all the other ent info in there? I know currently it will just cause an error and fail to load the map, because of all the "missing" ent information.... It seems like it should fall back to the original ent info in that case -- only loading modified or additional stuff from the .ent file.


And that transparent func_illusionary doesn't seem to work right for me in DX Mark V (may be related to the previous thing I reported about the weapon model not being transparent UNLESS I have HQ textures enabled -- but in this case that doesn't help). It does make the fake player visible, but it's not transparent, and it's drawn strangely, like from back to front (or would that be front to back...); If I look at him from the front, I can see the gun strapped to his back.... If I set his alpha to "1" then it looks normal.


Ok, so what about having an r_transparentlist for the client to play with? It could just set certain things to always be drawn at 50% alpha.

There are quite a few things in Quake that might look better as transparent, like all the sprites (bubble, light ball, and explosion), all the lightning bolts, the large wall flames (though the torches would be problematic, since they have a wooden handle), possibly the lasers, probably the death knight spikes and scrag barbs, and maybe even the scrag itself.


And for my purposes, it would be nice if I could set one specific frame of the player model to be transparent -- maybe only have that effect kick in if the frame lasts longer than a couple tics in the game so that it doesn't occur during normal animations -- but that's just me thinking of possibilities -- I don't actually think you should add features that are only for specific mods, heh. But having some way for the client to control effects like transparency could be useful to everyone. 

Would a .tga skin with 8-bit alpha work? I bet some clients already support that. 

"Mark V does this for a couple of maps internally (E1M1, E1M2, ..)"

Baker, your anti-z-fighting hack is conflicting with my anti-z-fighting hack, heh.

On e1m1, you seem have have Mark V moving that secret lift down by like 26 units?

That's bad; here's why:

I think this, again, is something you shouldn't change engine-side UNLESS there is a way to turn it off. (Actually, I am all for trying outside-the-box stuff like this, even engine-side, but it's important that the defaults remain the defaults).

Because... I am tweaking things mod-side to eliminate z-fighting by altering door positions VERY slightly (0.15 units, which may just be rounding up to 0.2 units). There are various ways to implement this, with various side effects. The current thing I'm trying moves vertical "doors" (that hidden lift is actually a door that moves up and down) slightly down (and sideways) by 0.15 units. This seems to work great in most cases, but it causes a problem with that lift in e1m1 because you have already adjusted its position by a comparably large amount (you were aiming to make it flush with the ledge it goes up to, right?). So now after I adjust that down by a tiny amount, it's slightly below the ledge it raises up to, which causes the player to be blocked by that tiny lip when he tries to step off the lift!

You really only need to adjust something's position by 0.15 units to avoid the z-fighting.... And any hack like this in the engine needs to be capable of being disabled.

AND, if you're gonna tweak things like this, you should try to fix ALL z-fighting, like I'm doing mod-side, heh. Don't just go half-way!


Currently here's what I'm doing mod-side, just in case you wanna try similar things, heh:

func_plat -- adjust origin UP by 0.15 units. These are visible lifts, so just need to be sure they aren't on the same plane as the floor (e2m3 lift leading to top level).

func_wall -- move their origin perpendicular to their wide side by 0.15 units. Many of these are the "exit" signs that are usually on the same plane as the walls they are near. (e2m2 exit in DM mode, for example). Moving them on their "wide side" makes sure they are offset from those walls. e.g.,:

if (self.size_x > self.size_y) self.origin_y = self.origin_y + 0.15;
else self.origin_x = self.origin_x + 0.15;


fd_secret_use -- fix secret doors just by altering their end position. They already move in 2 directions, so won't be on the same plane as the wall they are on, but their end position may slide their narrow side to be exactly aligned with the wall (start area secret door on e2m3). Fix just by telling the door to not slide quite as far into the wall (the "v_forward * -0.15" is added to this line):

self.dest2 = (v_forward * -0.15) + (self.dest1) + (v_forward * (self.t_length));


Regular doors is where it gets a bit more tricky.

in func_door, just before it sets pos1 and pos2, check if it's a vertical-moving door (like our e1m1 lift), and change its origin by a bit (down, and along its wide side). We can do that safely here because these things don't need to blend into walls, so we won't be making any weird cracks where they shouldn't be:

if (self.movedir == '0 0 -1' || self.movedir == '0 0 1') {
self.origin = self.origin - (v_up * 0.15);
if (self.size_x > self.size_y) self.origin_y = self.origin_y + 0.15;
else if (self.size_x < self.size_y) self.origin_x = self.origin_x - 0.15;
setorigin(self, self.origin);
}

If there is no "wide side" for most doors, then you probably don't need any sideways adjustment... but otherwise you may need to adjust even for vertical doors, like for the gates blocking the exit on e2m7.


For regular doors you pretty much do the same adjustment as above, but only after the door reaches its open position, in door_hit_top (check to make sure it's NOT a vertical moving door there -- we fixed those above). You don't wanna move a door's origin like we did for the vertical ones, because sliding doors often need to blend in with walls, and moving them can make tiny cracks appear. And only moving the "end" position is safer -- it probably won't cause any weird side-effects.

And I've seen some pretty weird side effect with the various things I've tried tweaking to eliminate z-fighting, heh! But this is my most recent stuff (subject to change/improvement); it seems to work well. The only flaw with the current implementation is that there might be some z-fighting happening WHILE a door is still moving, but it will go away once the door is fully open.

Of course, I don't actually have a full list of all places in Quake where z-fighting occurs so that I can check, but these alterations should theoretically eliminate all of them! It will even prevent z-fighting where it was never occurring in the first place, because it affect ALL the doors, haha! But the idea is to alter them (ALL!) in such a small manner that it won't be noticeable or cause any problems. 

Eh, I posted my (current) full code and explanation for my anti-z-fighting hack over on the FvF forum (guess I didn't need to clutter this thread with it, heh), if anyone would like to really examine or comment on it: http://www.fvfonline.com/forum/viewtopic.php?f=12&t=3795

Yes, I know it's a hack, heh, but it's an effective hack, and easier to implement than many other options (this will work for every client, without having to modify all the individual base maps).

The theoretical potential negative issue is that it's very broad, affecting everything globally to be sure it gets everything it needs to. If I actually had a list of all the instances of z-fighting in Quake, I could probably narrow the focus to make sure I'm only affecting things that need it. But I'm fairly certain it's not causing any significant negative side-effects. And you won't see any (persistent) z-fighting anywhere in FvF! (In theory!) 

An idea to toss out:

All bronze chat text tends to blend together, making it hard to quickly recognize text from each individual person.

What if chat text were automatically color-coded for each chatter? Like if my pants are blue, my chat text is blue. That might be a bit difficult -- each color would need a different image of all the characters, right? I think that's how Quake does its text (like a bitmapped font).

Alternately, what about just putting a color box of the player's color next to his chat text (like the color boxes appear in the scoreboard, with shirt and pants color behind the score for each player). The color box could either be placed in front of the name of the player who's chatting, or it could replace the space after the : after their name. Imagine the [] is the color box:

[]Gunter: color box shows my shirt and pants color

or

Gunter:[]so you can easily recognize my chat lines in the console

or

Gunter[] or maybe just replace the colon itself....

or

Gunter[:] or just put the color box behind the colon.



At least one of those options might look good, heh. 

Unlimited Mirror Support - YouTube

No limit to the number of mirrors, provided they cannot see each other. You could have 10 mirrors on the same wall since mirrors on the same plane cannot see each other.

Engine scans surfaces for mirrors, generates additional visibility @ map load.

Same concept could be used for security cameras or even portals that preview the teleporter destination. 

That's quite a nice showing Baker! There are some really creative opportunities when using mirrors in this way.

Thanks for sharing. 

I remember this being a feature of Glide 

Retexturing In Real-Time

Tool Inspector

Added a "hdfolder" folder command to specify a content replacement folder which you can change in the console to switch to a different set. 

Inspector is a very nice idea! 

:D 

Windows: Open GL | WinQuake (software renderer)
Windows: Direct3D

No new Mac build for now.

***************************
Primary Features
***************************

Mirror support. Worldspawn key "mirroralpha". Textures must be prefixed with "mirror_". Can specify specific texture with r_texprefix_mirror. See the Quake startmap, go to easy hall.

No limit to # of mirrors, provided they cannot see each other (3 in a row on same plane = ok!).

Find command. Type "find sky" or "find speed" and you'll see what I mean. Similar to the DarkPlaces apropros command.

Nehahra Support is complete and fully polished to the absolute maximum. It's like a dream.

Built-In Quake Injector Install now auto-completes 500+ of the best releases. Press CTRL+space to autocomplete or TAB.

Like type "install travail" or "install rapture" in the console, it downloads and installs it. Then type "game travail" and do Single Player->New Game.

"hdfolder" command to specify an optional content replacement folder. Change it in the console.

Zoom key. Bind x +zoom_key -- one size fits all script for sniping scrags across a bridge.

International keyboard support. Needs tested for verification (in_keymap 0 turns it off).

Convenience
-------------
Automatic HUD sizing. See menu. No more using scr_menuscale unless you want to.

Stretching For WinQuake version -- stretching. Play at 320x240 full-screen resolution even if video mode not available.


Co-Op, LAN and Networking Features
------------------------------------
Co-Op ghosting for 5 seconds -- walk through other players/no telefrag for first 5 seconds. No coop spawns? Who cares!

Marcher Fortress can be be played co-operative, engine overrides a Marcher QuakeC oversight.

IPv6 support (from QSS)

connect lan, type that in console and no need to figure out LAN server IP address for playing co-op.

Server browser + single port server. (from Quakespasm Spiked)
"reconnect" -- reconnects to last server connected to.

Multiplayer save game capability. Save a co-op game.


Flexibility
--------------------
Different gun positions available including "side-mounted" (r_viewmodel_offset).

Multiple HUD-support (i.e. Quakeworld HUD, .. see menu)

Texture gamma option. Do vid_hardwaregamma 0, and you can adjust gamma via typing "txgamma 0.7" in the console. No cpu/gpu cost.


Server Connectivity
-------------------------
Disconnecting from a server will discard any aliases the server provided.
Disconnecting form a server will discard any key binds the server sent.
Complete ProQuake support including depot map/model/sound download.


Polishing
--------------------------
Final Malice bug fixed (for NightFright).
Original Quake centerprinting option. scr_originalquake2d
Ability to disable multisample attempt via cmdline -nomultisample. Same with stencil -nostencil. May make older computers be able to use OpenGL version.
Direct3D version can now do transparent weapon with invisibility ring. So can WinQuake build. (from qbism super 8)
Software renderer supports stretch modes.
Ability to have jerk stairs like original Quake. See menu.
sv_gameplayfix_setmodelrealbox for QRally and other ancient mods.

Source code

[Partial list, some other minor features may be in the thread. Source code link will work later in the day.] 

Exe: OpenGL version of Mark_v
Issue: Crashes to desktop
Replication: 100%

How to: Go to options, controls, press return key to bind move forward. 

Testing the mirrors in gloom keep and I got this -

http://imgur.com/a/2cHyW


Also as the reflections are based on vis you tend to get HOM effects if you look at the mirrors from certain angles. 

For some reason I can't seem to pull down the console even though it's bound to tilde. I rebound it to z and it works. 

i can confirm the console bug. 

I think it's about time I reported something that pretty much makes Mark V unusable for me. It exhibits a fairly stable (once per few seconds, with some longer periods of running normally) lag. All three exe files are affected. fitzquake_mark_5.exe dated 2012-07-31 seems to work fine.

I'm using this machine running in a power saving mode due to overheating (maintenance is long overdue). Quakespasm runs fine on it, even when fairly big/complex maps are concerned, but Mark V is stuttering even on start.bsp.

And a minor nitpick: "previous weapon" and "next weapon" commands seem to be swapped, as my autoexec gives me the opposite of what I want. 

Well, the GL version still crashes for me on map load even with -nomultisample -nostencil

The auto text sizes have increments that are too large (jumping right form 1 to 2). It needs 1.5 too (which is close to the maximum 1.55 that still allows player names to be positioned beside the "uncentered" DM HUD). It could even be useful to have 1.75 in widescreen resolutions. Hm, it appears that in proquake, a resolution of 640x480 has the equivalent of sizing things to 1, but at a resolution of 800x600 it automatically sets things at a size of 1.25, so the .25 increments can be useful -- perhaps this scale feature needs a slider bar for fine adjustment.

Hm, those "high" weapon models are too high, methinks.


Tested an old issue: it still crashes if you toggle external_textures when on maps E1M2 or E2M3. 

my irc mod had coloured chat text, you could adapt that.

screenshots are here: https://qexpo2016.com/quakespasm-with-irc-twitch-chat-support/

the code was pretty hacky, but is functional. 

that inspector tool seems waaaay handy for info_null entity hacks. 

The auto text sizes have increments that are too large (jumping right form 1 to 2).

Graphics get rekt a little when you scale them by a fractional number. At least when texture filtering is disabled. 

Frickin' cool feature list there. Looking forward to trying out this release! 

(Can the original post for this thread be updated?) 

Going through my usual settings first....


The lavacolor has gone back to the incorrect value of "255 80 50 150"
Default should be "255 80 0 150"


Hm, I don't think "auto small" is a good default setting. It should probably just default to the "controlled with cvar" one. Even "auto medium" might be better for the default, OR get fancy and have "suto adjusted by resolution" so that the sizes will automatically be set based on your resolution so that the screen elements look approximately the same size no matter the resolution.

Things actually look fine for me at the .25 increments for scaling. Going to weirder values, like 1.55 does cause a bit more distortion, but the .25 ones look good.


scr_showfps still vanishes when you size the screen down (using the default -/= keys).


mwheeldown triggers mwheelup instead of mwheeldown.... This may be the problem dwere mentioned about "previous weapon/next weapon" not working, since the mouse wheel does those things by default?

Uhh, could still use solid dark black shadows for DX, since it can't do the stencils ones right. And of course, if you're hacking shadows, you should just hack them to not be drawn at all if they are more than like 100 units away from the entity, because that causes weird shadows....

You still have bolt1.mdl in the noshadow list... there is no bolt1.mdl in Quake, heh.

And of course I think k_spike.mdl and lavaball.mdl should be added to the noshadow list....