You could do like Blaster Disaster and support two people on the keyboard, one person on a multi-button mouse, and one person on a joystick/gamepad.

Downsides: keyboard players would be stuck with oldschool no mouselook. All players would probably only be able to change weapons via cycling up or down except for maybe one of the keyboard players. Mouse player might need to steel a couple keys for strafing (laptop users would definitely be crowded). 

Boring stuff: sv_gameplayfix_setmodelrealbox for Quake Rally or other old mods that need original Quake bugged setmodel.
------------

I've got a video of the four-player uploading now. Sadly, the video is 1 GB and it says 1 hour, 17 minutes remaining on the YouTube upload.

@ericw -- I went full retard. Never go full retard. I literally posted the screenshot 2 minutes after I got the prototype working.

------------
With any luck, the new version will out today or tomorrow. 

Just opened up ol Blaster Disaster and it let you have up to 8 players:3 keyboard, 1 mouse, 4 joysticks. 

@qmaster - I'll solve the input solution with some thought. Spike, R00k and myself have had numerous conversation about FTE split-screen in the past. 

Wow, that's pretty cool.

I think you will definitely need joystick/gamepad support for that to be usable.

Perhaps the simplest thing to get it working at first, may just be to have one joystick configuration (button 1 = jump, button 2 = fire, etc., however the user sets it up), and just copy that behavior for gamepad 1, 2, 3, and 4, with each gamepad sending its input to player 1, 2, 3, 4.

Otherwise each gamepad will need to be configured separately. Which would probably be ideal in the long run, but just having one configuration for joystick input may be easier just to get it working.

Keyboard input should probably always be for player 1 (the one in control of the computer, which would often be the "server," in effect). Hm, but I hope it be able to connect all the extra players to an online server too....


But I'm already imagining hooking my netbook to the large TV screen and playing couch-coop splitscreen Quake! I have plenty of PS3 gamepads (which are basically just USB gamepads in Windows). 

There's a video I posted in the General Abuse thread. Read the names of the players in the scoreboard. 

Hah, neat. Reposting that on the fvf forum....



Thinking more about gamepad input, due to the limited number of buttons on a gamepad as compared to a keyboard, you may need to implement a "shift" key functionality.

Example:
Pressing Button 1 alone causes you to attack.
Pressing Button 2 does nothing by itself, -- it's a "shift" key.
Pressing Button 1 while holding Button 2 causes some alternate action, like changing your gun.

That's how they did the Playstation port of Diablo.


This could be added into Mark V as a standard feature -- not just for gamepads.


Perhaps something like:

bind ctrl +attack
bind alt @shift
bind @ctrl +jump

Now the ctrl key can be used to attack, or to jump if you are holding down alt at the same time.

Yeah, it doesn't seem as useful when you could just use alt to jump, since there are plenty of other keys on the keyboard, but you could bind lots of other keys or mouse buttons to shift their behavior too, like:

bind mouse2 +moveup
bind @mouse2 +movedown
bind mouse3 (next weapon impulse)
bind @mouse3 (previous weapon impulse)


etc....

It would give more options, which would be more useful for a gamepad.

I suppose you could even add more than one "shift" key, so ctrl could be @shift and alt could be #shift or something.

Then you have even more overly-complcated things to bind!

bind ctrl @shift
bind alt #shift
bind mouse1 +attack
bind @mouse1 +jump
bind #mouse1 "say I can do 3 confusing things all with one mouse button!" 

Is pretty damn near perfect btw. 

I have all the major console controllers to test with 

Hello, first of all great job on the engine, it's definitely my favourite.
I'm playing Scourge of Armagon and Dissolution of Eternity for the first time and using the winquake executable of Mark V for the original look. I've noticed that in both expansion packs the hud icons for new weapons are not displayed properly. In Dissolution the weapon in use should have a "lava glow" and in Armagon there should be unique weapon icons. These effects are completely missing. I'm using the GOG version of the games.

Should these icons be working properly in Mark V? 

@ zbikey -- Theory ... make sure you started the command line right

cmdline: -game hipnotic -hipnotic
cmdline: -game rogue -rogue
(The -hipnotic activates the hipnotic HUD)

If you prefer to switch to the gamedir in the console instead, it is basically the same:

In console: game hipnotic -hipnotic
In console: game rogue -rogue

Let me know if that was the issue!

@fifth, when the time comes I'll definitely need your help with the gamepad support.

My first priority is getting out the new release, getting feedback on it to see if there are any outstanding issues to make sure Mark V can finally become non-beta for the first time in a few years.

Then I can confidently proceed to make split-screen a standardized feature and add controller support. 

Everything is working perfectly. Sorry, I should've looked for the solution myself, didn't think there would be a command line for this. Thanks so much! 

It's a common problem. 

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.