It's a common problem.
The command line or the people who ask without looking first? 

Multiplayer save games working.

/Never looked at either DarkPlaces or FTE. I think DarkPlaces might have feature; FTE is known to have feature. 

 

Hm, this is a bit beyond the type of thing I usually ask for... but is it even possible to allow some kind mod-side support for drawing things transparently? Like, client-side (similar to the way you draw the viewmodel transparent when the player is invisible), even if the server isn't using a protocol that sends alpha information....

I guess the problem would be that the server doesn't send much information to each client other than like the model, location, and frame of another entity, right?

So, for example, you couldn't just draw something transparent based on a .field of an entity....

It would have to be something like a

r_transparentlist progs/wizard.mdl,progs/bolt.mdl,progs/laser.mdl

Or perhaps somehow allowing only certain frames to be transparent, like progs/wizard.mdl:5-7,


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

What I was hoping to achieve would be transparent observers.... I suppose if I could make one certain frame of the player.mdl designated as transparent, I could just avoid using that frame during any other animation, and have observers only use that frame when they are flying around (that frame being 71, heh)....


Just brainstorming here..... 

It both can and cannot be done.

FitzQuake protocol 666 supports .alpha on entities.

Do this:
1) Start E1M1
2) Console type: copy ents
3) Open text editor, paste it. Save as c:quakeid1mapse1m1.ent
4) Add this at bottom of e1m1.ent text file, then save again.
{
"classname" "func_illusionary"
"model" "progs/player.mdl"
"origin" "430 574 24"
"alpha" "0.5"
}
5) Load E1M1. You will see what I am talking about.

So it can be done automatically with FitzQuake protocol 666.

FitzQuake 0.85 obv, Quakespasm, Mark V, Qrack, Super8, FTE all support FitzQuake 666 protocol.

DarkPlaces doesn't. ProQuake doesn't. Those clients would not be able to connect, but both of those are by far the 2 most likely clients someone connecting to your server would be using.

If you were to run FitzQuake 666 protocol, this would mean you would need to run something different as your server executable (couldn't be ProQuake, no .alpha support).

In addition, if you were to use something non-ProQuake as the server, if you use qccx hacks to mask ip addresses that stuff would have to be stripped out your QuakeC source because it depends on fixed memory structures/memory addresses that only an adamantly retro-compatible engine like ProQuake can possibly support. 

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.