I talked Gunter into doing a review of Quakespasm.

He's a very detail oriented guy who plays a coop mod online:

Quakespasm Review by Gunter 

http://triptohell.info/moodles/junk/quakespasm-spike-r3.zip

Uses fte's replacement-deltas protocol extension by default. helm18 is actually playable for me now (the 10k knights map). The limit is now the renderer+server logic now.
Disable with eg: sv_protocol -666, but leaving it enabled won't hurt existing 666 clients.

Don't expect more big changes any time soon, although I'm still open to bugfixes for the things I broke in the hope that this gets stuff finds its way into the official quakespasm.

Why do I constantly feel like there's something I've forgotten to do?.. Feel free to remind me so I can get annoyed about it anew.
Ooo, maybe its multiple things! 

Minor questions for you whenever you have the time ...

I've tried seed at least fundamental information and examples including looking through engine code some ...

1. Is there a way to specify a particle effect should generate even if the particle would not be in view?

I know in the hands of someone who doesn't understand the mechanics this would be undesirable, but unlike deathmatch (Quakeworld uses of a particle system) where particle effects are primarily used for weapons blasts the uses in single player would be more for persistent weather.

If every time you look at the window, it has to restart the rain from nothing that is undesirable.

2. Is there is a method to see what the current particle count is?

So a mapper can measure the effect burden and make sure the author isn't creating situations where the particle count continually increases because the rate of creation exceeds the rate of destruction (die time, etc.)

3. What "attribute" would kill a particle if it hits a liquid?

4. It looks like models emitting effects is disabled in the particle system (like ability for a pent to emit stardust or what not --- I've seen this effect in DarkPlaces)? I could see that be used to make broken panels that emit sparks in a base map, for instance.

Was there a certain reason that you felt that was undesirable in an engine like Quakespasm or would it have introduced a code burden?

5. What method controls the particles count cap? How do you set that limit?

------

Very awesome feature set Spike! 

1. surface emittence is based on the distance from the view rather than frustum. so keep emitters away from teleporters and use short-lived particles you should be fine. snow will always be problematic in that regard.

2. r_partinfo

3. you can only do it on initial spawn. overwater or notoverwater will filter that effect. use the +foo stuff if you want the particle system to spawn one sort above water and one underwater.

4. using countextra/countabsolute for static effects on trails or emitters is evil and framerate dependant. that makes it undesirable. use r_effect if you want something to emit particles constantly. use r_trail if you want it to emit particles as it moves.
the previous build lacked any protocol extensions for entity fields. the replacement deltas stuff fixes that in r3, so you can resume using flawed stuff for compat with dp.

5. r_part_maxparticles or r_part_maxdecals. Changes to these cvars should take effect on map changes. 

Random stuff:

1. The delta compression should be a big help for coop.
2. Looks like you added makestatic so someone could, for example, make deadbodies from monsters into static entities.

(Is there a way in QuakeC to know if a monster's dead body is in on a lift (i.e. died on a brush entity, not worldmodel)? Specifically to not makestatic those particular dead bodies?)

3. In a previous reply to ericw, you had talked about implementing a mechanism to send multiple packets in the event they exceed 1542 +/- bytes for coop --- is that implemented? I can't tell from the readme if that was implemented.

4. DP_QC_GETSURFACE, so broken vanilla skies stop being broken -- raises this question --- what is a broken vanilla sky?

5. SOLID_CORPSE. Memory block, even reading the DarkPlaces description of SOLID_CORPSE, I can't recall the main use of the feature -- even though I remember it is useful.

6. Sprite groups. spritegroups will now animate properly - this was a vanilla glquake bug Are you aware of an existing mod that used sprite groups? Hipnotic? Rogue? 

(No one will care except Spike but I meant to type 1442, not 1542) 

Could particles be cached in their current state (i.e. paused/frozen), when out of view and then resumed when in view? 

2. makestatic was a vanilla thing. I've not touched it. I probably should do for extra fields, but that would mean that I'd have to actually add support for that.
either way, if the corpse isn't moving then the protocol changes mean that it'll only be retransmitted when it first appears/disappears, there's actually little need for makestatic now.

use tracebox to see if its sitting on a lift or something. or failing that a traceline. or just check thecorpse.groundentity

3. that's in this build, it probably ought to stick to a single packet due to burst, but I didn't include any prioritisation for players and skipping the player every other packet would make it a bit too jerky without better lerping, so it just spams.

4. those solid skys that give particle effects when shot, that affects some percentage of the vanilla maps.

5. so one tracelines and projectiles will hit corpses and yet monsters and players will just walk through them.

6. dpmod is one such mod. go on, get it to run in markv or something. 

"Why do I constantly feel like there's something I've forgotten to do?"

Everyone forgets to add support for 4 players and splitscreen... (FTE doesn't count cause I cant get it to work properly) 

I asked Gunter if he'd be willing to give your Spikespasm a test drive as a replacement for ProQuake server on his coop mod server fvf.servequake.com

I explained the benefits like the automatic server browser.

Something that immediately occurred to me, though ...

1) Quakespasm can't actually serve a protocol 15 game (i.e. standard Quake). The sign-on packet wrongly busts the standard Quake limit, causing the client to immediately disconnect.

2) Gunter asked if it would have ProQuake rcon. I said I'd bring that up.

/I could probably easily obtain more server operator volunteers, but Gunter has run a server for a while and he's already getting familiar with Quakespasm. ;-) 

I didn't make it clear: He said he'd be willing

I explained the single port server advantage, the ipv6 support, and automatic server heartbeat advantages.

(Although Polarite is the one actually in control of the server. I haven't talked to Polarite yet.) 

RCON

* To anyone that doesn't know what RCON is, if someone has a server, the owner can connect to the server and do "rcon changelevel e1m3" from the client.

It is a way to give yourself the ability to issue console commands to the server like change the map. 

I had the idea to make low lying fog using a skip-textured 32 unit high brush whose top surface was textured with a circular fuzzy edged {fogtexture (using pink transparency index), setting this brush to be func_illusionary, and topping it off with a .alpha value of like 0.2 or 0.3 for subtlety.

This looks somewhat passable at 0.7 even, however there is a bug. I can't set .alpha lower than 0.67 or else it doesn't draw the face at all.

??? 

@FifthElephant, as much as I enjoy encouraging people to use fte, this probably isn't the right topic. poke me on irc or give a proper bug report in the afterquake topic or something.

@Baker, it'd be good to get it to use vanilla-compatible packet sizes, at least where practical. The signon buffer size can trivially be reduced to 8000 now thanks to baselines being splurged over multiple packets too, but iirc there's issues when recording demos mid-map due to clientside assumptions someone made, and I'm too lazy to re-splurge the data back out there too (so I just left it using large signons despite it being trivial to split it, to try to sidestep the issue), either way I suspect its not just quakespasm that would have an issue with that.
iirc, vanilla needs 1024-byte unreliables too, which is more of an issue without proper deltas, though I suppose if you're trying to use vanilla protocols then you get what you deserve. Obviously none of these limitations need apply to qs[s] clients connecting to the same server... Can we not just get everyone to upgrade?.. :P
The master thing is kinda irrelevant as not many clients will bother to check it at this time anyway, so he'll still need to manually get it added to whatever server listings proquake etc currently use.

@Qmaster, the engine sets up the alphatest value once and then forgets about it:
glAlphaFunc(GL_GREATER, 0.666);
that line needs to scale by the entity's alpha value in each place where its actually needed, which is probably quite a few places. 

>Can we not just get everyone to upgrade?.. :P

Protocol 15 is what DarkPlaces, Qrack, Super 8 and everything else can speak. And your single port server means that no client --- not even GLQuake will have NAT issues.

It was my thought to get the server real live tested, since few people (or even anywhere) here seem to coop even on a LAN.

And then after that works, push for a "Spikespasm coop server" that exclusively uses the new client.

/That was my line of thinking. 

(Anyway, I wasn't trying to get you to do anything of substance. I made Mark V support protocol 15 with just a couple of tweaks, I wasn't aware that getting "Spikespasm" to support protocol 15 would be difficult.) 

( When I made Mark V support protocol 15 -- which FitzQuake 0.85 never quite did --- I just kept track of the protocol upon map start and set a global. I adjusted the signon buffer and then the packet size. http://forums.insideqc.com/viewtopic.php?f=3&t=5593 ) 

haze.cfg --- assigned the te_quad_sparkfan effect to progs/quaddama.mdl

Loaded dm3

When I pull up the console. The effect spams continually. Obvious the "die" time cannot happen when the console is up. But new particles shouldn't spawn.

Oddly this does not seem to happen with rain/snow. So far only te_quad_sparkfan seems to have this problem. 

Baker, protocol 15 might be the only commonality between all engines, but if you ignore vanilla, all the other engines have boosted what their engines are willing to receive to at least ethernet's limits.
requiring everyone to upgrade basically includes to every single notable engine with the exceptions of vanilla and proquake. One of which you(baker) can fix with a new revision.
The alternative is to cripple dp,qrack,fitzquake,markv,etc clients that give no way to identify what they support.
These clients would also need to be limited to 600 entities too, etc.
Its not that its a big change, its more that its really limiting. 

I think what've you done here is incredible as is.

Spike: you(baker) can fix with a new revision.

Heheheheh. Should the day ever come when I have time, hehe ;) Probably won't be within the next 12 months.

No one expected to get particles because you seemed down on it. The stuff on top of the particles was unexpected and a bonus.

The particle stuff by itself is quite the enhancement and I hope it gets put to good use by Sock and possibly others. 

if I'm not critical of something, I can't easily spot the flaws in it.
At the end of the day, if someone does something stupid with the particle system then that's their own damn fault, and not something that should hold back eg Sock.

Regarding protocol 15, if clients can tell the server that its not crippleware, then its only the crippleware engines that will suffer from being crippleware.
I made some tweaks, and r4 will (bug-willing) do protocol 15 properly. I even made it reduce the number of usable sounds/models if the serverinfo packet is too big, which seemed to get AD going with a proquake client, although it did feel a little empty with half the entities missing (like I said, limiting)...
I guess I also ought to do something about makestatic too now though. Stupid cans of worms... :(
Also got the server part of proquake-compatible-rcon working, although I wouldn't personally recommend using it because the password is still sent as plain text, which sucks.
Also found a nice reliable way to crash proquake servers. Hurrah.

yay polish?.. 

Question:

I don't understand your objection to the FitzQuake "game travail" or "game warp -quoth"

Is it because it doesn't use gamedir like Quakeworld and DarkPlaces and JoeQuake? I used to dislike the slightly different naming, but I've gone from disliking it to prefering it because I type it in the console a lot for single player.

Is your dislike just because the name? Or is there something else I'm not seeing?

/Slightly surprised you decided to do the protocol 15 thing, I did look through all the mega-tons of changes you did and I can see your POV. rcon on the other hand is barely a cut and paste, relatively speaking ... even easy stuff is slight PITA. 

until some rcon command crashes the server and fails to even tell the (rcon) user what happened. Blind copy+paste is never a good idea.
no feedback on errors = bad
plain text passwords = bad
client only supporting one rcon command at a time even when its just a single packet = bad
modifying the system-specific code for something common to all = bad
willingness to exceed proquake's own mtu resulting in 'bad read' errors instead of results = bad
not giving any feedback at all when the server is a listen server = bad
copy+paste = bad. :)


I dislike 'game' because it differs from the command name that id themselves used with quakeworld. that said, quake2 used 'game' so I can't really justify that much further (although q2 used a cvar, which has its own set of issues, which an engine that also supports q2 needs to be able to deal with).
What I really *really* hate about it is the '-quoth' part, which limits it to only a few base-mods that are hardcoded into the engine. This also affects the choice of hud, and even the network protocol. Each of those 3 things are unacceptable to me.
So yeah, I feel justified in disliking it, even if I ignore that qw+fte even existed.
The deltas stuff deals with the protocol change. The hud lumps can be auto-detected. The hardcoded list of 'permitted' mission-packs is just plain stupid. Oh, and quakespasm doesn't support more than those 2(+id1) either.
But yes, I should do something about the server announcing the correct gamedir to use, but probably I'll just leave that until someone else wants to actually fix up the 'game' mess and add auto-downloads and deal with the versioning fallout resulting from that. 

Scenario:

Someone is using DarkPlaces as a listen server.
They decide to coop.
They use multi-game dir for replacement content.

Problems:
(1) So does the client need to download all of that person's replacement content when connecting?
(2) Make sure content are the right models with CRC check etc? How do you do that when the loaded model is a replacement model?
(3) Download doesn't download the replacement textures that the replacement content needs to look right.

Multiple gamedir support is mostly a mechanism for using replacement content.

Within that context --- the support for a small set of mods (rogue, hipnotic, quoth, possibly -ad in the future) is not much of a problem.

And is probably a major benefit. I don't know how many single player users require the Quake Injector to play a custom map, but its probably no small number.

When I first wanted to try custom single player, I was not used to the installation instructions or using -game in the command line. Figuring out where things go and the startup procedure is a big challenge to most people.

Shorter version: I think a finite list of double gamedir like "game -quoth" is fine, Preach knows what's he's doing, Sock knows what he's doing ... other than Preach and Sock and some of the power mappers that really know their stuff (czg, necros, tronyn, etc.) --- there aren't a lot of people that are going to be making an expansion pack level add-on for immersive content.

When DarkPlaces added double-gamedir support, the thought wasn't of "hey, make sure feature is properly architected and well designed" but rather for modder convenience.