lol, read it in Red Dwarf's Lister's voice 

https://youtu.be/ygfLKfo-Ejc 

Never heard of him before, BicMacDavis that is! c; 

 

There is a curated collection of images and textures for 3D work on the Blender site. The license is CC-0: free to use anywhere, for any purpose.

https://cloud.blender.org/p/textures/ 

Hi!

Me and a friend decided we should put on Quake and play some custom maps and custom campaigns together (and probably we'll have some other people to join us too) and maybe do even some deathmatch from time to time.

My question is... well, I really like the Quakespasm engine.
But I don't know if it's really that great for this purpose.
I know it's the most used and most functional with custom maps though, and so what I want to know is if it's possible to play such levels in co-op with that engine. I mean, we don't want to curse each time we have to host the game, nor using some odd software to do that. So, is Quakespasm good to go, or should I look onto some other engine (any reccomendation if so?)? 

Keep calm and carry on. 

For local Coop (on a LAN) Quakespasm would be fine. But for Online play you'll probably want to use FTEQW.

Keep in mind whoever will be the server needs to poke a hole in their router to allow connections. It's not impossible but info is tough to find. FTEQW has a wiki though and you should be okay. Good luck!

http://fte.triptohell.info/index.php?p=downloads 

Thanks a lot! 

If you really like Quakespasm, but want the networking superiority of FTE, then use Quakespasm-Spiked

It was specifically made for this exact scenario. 

http://triptohell.info/moodles/qss/ 

It was specifically made for this exact scenario.

I was unaware that QSS had any network improvements. I thought it was solely the FTE/DP visual effects. Very interesting and good to know. 

Quoth 2.2 added some stuff to try to support DarkPlaces by turning off all the irregular stuff stuff in DarkPlaces.

Sadly, unless you want to weird up Quakespasm Spiked you better not call your cvar sv_gameplayfix_setmodelrealbox.

Quoth will decide set it to zero, changing the normal behavior of Quakespasm to whatever physics irregularities await for sv_gameplayfix_setmodelrealbox 0 --- which will cause a FitzQuake style engine to not use FitzQuake style bounding boxes.

What will happen? I don't know. 

QSS still has no network prediction. If your players are in different countries then FTE is still a noticeably better choice.
Vs QS, QSS provides proper network nack-compression (using FTE's network protocol) meaning much higher entity limits (at least for mostly static ents like monsters, while dynamic ents [like AD's qc particles] will still have higher limits but at the cost of slight potential lag).
Mods like AD can FTE's/QSS's particle system to perform effects clientside instead of serverside, which has significant reductions.
Note that the visual effects in QSS have defaults that exactly match QS (unless a mod or user explicitly uses the stuff that would be impossible in QS). QSS was never about the visuals, but rather fixing all the bugs and limitations that pissed myself off with QS (primarily networking and QC related). The particles are there just because they are actually useful to mods like AD - and especially so when networked.

@Baker
sv_gameplayfix_setmodelrealbox is the 'correct' name for the feature, and renaming it will just cause problems elsewhere. If quoth needs it on in order to function then quoth shouldn't be turning it off even if it only affected DP. Additionally, if its value actually changes anything then quoth is buggy (and bugged in either vanilla/dp/fte or fitzquake/qs). Presumably if no one noticed then it doesn't matter and might not even be buggy.
Either way, 0 has more predictable results when replacement models are in use, and is potentially faster for dedicated servers, so hurrah for buggy quoth. And boo hiss at fitzquake for being incompatible with quake, and I really wish I could justify setting it to 0 by default in QSS, and renaming the cvar would just mean that noone would remember the new name breaking any mods that do actually need a specific value for that cvar.
So, won't rename. I prefer consistency to randomness. 

That Quakespasm Spiked seems indeed very interesting!
Thanks a lot!

Anyway I don't want to put any graphic bullshit in it, really. lol
I like how Quake looks on its own and Quakespasm with the modern resolution etc. enhanches it a bit already. And it's got very cool visuals, from what I've seen from Custom Gamer.

Perfect!
Dankeschön! 

We're all in the same country anyway, so it's good.
I guess. 

I really wish I could justify setting it to 0 by default in QSS

FWIW, last time we discussed it in the FitzQuake thread ( http://www.celephais.net/board/view_thread.php?id=60306&start=691&end=714 ), metl confirmed he introduced the change by accident and recommended fixing it as well.

I support changing to vanilla behaviour by default, at least for a "testing" release of qss, and asking for help testing mods that were likely tested only on Fitzquake / Quakespasm. 

What was the changed introduced to fix?

Did it have something to do with blinking Chthon or blinking Shub? Perhaps larger monsters "disappearing" momentarily in very rare circumstances when mostly behind walls on certain maps like end.bsp.

Knowing what the change was intended to address would indicate what the consequences are for reverting it.

Some known mods affected by non-original Quake bounding boxes: Malice, QRally, X-Men. Maybe Shrak for Quake. Malice in particular has an enemy with, if I recall, 2 large parts, and the top part will disappear with FitzQuake bounding boxes. 

Could someone explain to me the effects of

sv_gameplayfix_setmodelrealbox 0

and

sv_gameplayfix_setmodelrealbox 1

I believe at the time I understood the impact, and that it resolved an issue we had with darkplaces setting larger hitboxes on sprites than other engines - vanilla engines set the hitbox to the dimensions of the actual sprite, while darkplaces set them larger by a factor of √2. We had sprites that were solid, and wanted to support mapper supplied sprites, so we couldn't use a pre-computed size.

Obviously we need to balance the need to get that right (because it could make a map unbeatable if the extra large hitbox blocked a critical path in map) with the negative impact setting the cvar on has. I've read the linked thread and this one, and I've got that it's bad, but not a clear explanation of why.

If it helps, until the next version, you can override the Quoth default settings by adding sv_gameplayfix_setmodelrealbox 1 to quoth.cfg 

When you do setmodel on an mdl in vanilla quake (aka realbox 0), the engine ALWAYS does a setsize of +/- 16 (on account of the loader not bothering to calculate the size - note that sprites use [maxwidth,maxwidth,maxheight]/2 for the size).

In QS (aka realbox 1), it instead does the setsize using the mins/maxs values from the mdl.

Note that if the mod calls setsize afterwards then there's no effective difference (unless it uses mins/maxs to do so...).

Hull collisions are biased by the mins+size values, while bbox collisions are affectet by the mins/maxs of both entities.
This means that droptofloor fails quite often, resulting in items getting removed or dropping through floors making maps impossible to complete.
Or entities with their feet inside/above the ground, or biased sideways.
Or tracelines firing from the wrong place.
Or positions being calculated using different offsets...
So yeah, quite a few ways things can go wrong, but as most mods call setsize you tend to not notice any serious issues.

Regarding Quoth specifically, I had a brief scan through some (probably very old) decompiled(eww) code.
I did spot some potential issues, but mostly where the entity was meant to be non-solid anyway.
One issue is misc_explobox but only with replacement mdls.
There's another potential one when developer is 4, or something, which I'm guessing isn't common.
I also spotted one place where .solid was changed without relinking (ie: before setmodel/setsize/setorigin instead of after), but as it had velocity any issues from that would last at most one frame, so probably noone will ever notice it without reading the code.
So I don't think quoth will have any serious issues with either value.
The cvar is not meant to have any effect on sprites (even in DP, which assumes all sprites are round regardless of cvars).

Replacement models are a huge issue (ESPECIALLY when mdls and bsps are quite so interchangeable). As a result, making the behaviour dependant upon the extension rather than the format makes a lot of sense.

Anyway, that's my perspective. 

I wouldn't worry about it too much regarding quoth. You might want to go through your code anyway, but I wouldn't loose any sleep over it at all.

If you want your model's feet to properly sit on the ground, you might still want to provide explicit sizes to ensure that mdls can work fine in both vanilla and for QS.
Note that explicit sizes can help for QS too, such that you can have geometry that extends beneath the ground (like in other frames) while ensuring that the frame you want is actually sized properly (and not biased sideways, either). 

What about misc_model?

(i.e. models that might be anything the mapper wants and are unknown to QuakeC. Hence no setsize because it could be anything the mapper is using). 

I don't see a misc_model anywhere.
If you mean mapobject_custom then yes, it doesn't call setsize.
However, its also both movetype_noclip and not solid. Thus its size is irrelevant to anything else. Therefore, not buggy.

The same is true of a number of other special-case static/semi-static entities.

Note that QC decompilers are utter shite, so take whatever I say on this subject with a pinch of salt, but what I see looks like quoth survives okay with whichever setting that cvar has (at least until someone replaces maps/b_explo*.bsp with an mdl or even a more detailed bsp). 

Maybe this issue shall self-resolve then, given enough time. 

We want to keep vanilla compatibility, so fixing the code to work correctly there and leaving the cvar as it is seems best. I'll add some setsize calls to the exploding boxes as I can see the issue with the replacement models, that shouldn't be allowed to create a difference size hull.

I think from there I can figure out the other possible issues - it would be very annoying if the feature intended to let you visualise the size of the triggers accidentally changed the size of those triggers at the same time...