seriously, if markv-2 please just port things over to qss-spiked. or back port to quakespasm
its like overlapping the same codebase with same features?? 

spike is having a heart attack right now

quoting:

"""
QSS exists because of my frustraction with common quake engines totally ignoring mod development, and with mapper-focused engines ignoring multipler and multiplayer engines ignoring maps.
QSS is my attempt to fix that. Being based upon QuakeSpasm it retains the benefits thereof (and singleplayer is still the primary focus). And with my numerous networking fixes it ca actually be used through firewalls or over ipv6, and without flickering when there are too many entites - it should be noted that this makes it better for extreme singleplayer maps too.
Meanwhile it also supports numerous QuakeC extensions, even including Simple CSQC, so mods are no longer limited to hacks. It supports an effects system too, so you can finally create weapons that are actually different - assuming enough players also upgrade.

A secondary aspect of QSS is to provide a 2nd or 3rd implementation of various extensions. Imho, when it comes to extension, 1 implementation is a mess, 2 implementations is an argument, and only 3+ implementations is a standard. More implementations help solidify standards.
QSS is not intended to change the aesthetics from that of QS (beyond more file formats supported). People who want more graphical effects are probably already using an engine that supports them, and implementing them in QSS is likely to drive users away instead.
QSS does change the networking (I consider this a bugfix due to how dire parts of vanilla quake were), but not in any way that should change the normal behaviour of the game's physics nor be visible to existing mods.
""" 

 

I can't port things to other engines, since what features get integrated into those engines is up to the leader/contributors of that engine. As to what I can port into this engine, the goals of the project are stated on the GitHub page. 

But Mark V actually has quite a few unique features QSS doesn't have. Quaddicted integration is just one nifty one.

This is kind of like suggesting why make your own mod if AD has all the features you want already? 

thats my point. Qs has a better renderer than MarkV and Qss has better mod support; so port the things you like from markv into qss.
or back port the best of qss into markV 

i mean baker will be back.. he always takes a break.
I am seriously forking qss and porting some quality-of-life things i am used to in Qrack over to it. i think, for my self, ripping code from qss and porting it to my engine just perpetuates the division of quake clients. Porting into one 'netQuake' code base (even as forks) help the "single-player" engine of choice. 

and ultimately the bumberstick says "just use FTE" but... we are talking about ftizquake variants :D 

*bumpersticker 

Making an updated fork of the Mark V engine (let's call it MarQ W or something) would be good for people who want a software renderer with up-to-date Quake compatibility. IIRC someone told me it doesn't support alphamasked textures properly. 

So with Arcane Dimensions out, is there any chance anybody will take a look at the source code and raise the limits to make sure all new maps are working?

Last time I checked in January, Quakespasm had limits like this: Dynamic lightmaps allocation, BLOCK_WIDTH/HEIGHT 256, MAXALIASTRIS 4096, MAX_STATIC_ENTITIES 4096, MAX_STACK_DEPTH 64, cmd buffer size 256K, MAX_EFRAGS/MAX_MAP_LEAFS limits removed.

I dunno if Spiked went even higher in his port modification, but that's the absolute minimum of what should be done. 

Baker still uses glBegin/glEnd code in MarkV so it will run AD like shite unless the renderer is rewritten. 

Well, maybe AD won't run properly with Mark V any time soon, but at least someone could address the issues with the other addons (still remember last Malice level with its fov warping, that ne_ruins crash with the succubus skin and others). I dunno how some of my reported bugs were fixed and then broke again, but since it is known what was the problem, it should be possible to re-apply those fixes easily.

We have the source for a potential Mark VI uploaded since ages, but sadly nobody seems to be interested in it. Baker surfaces occasionally, teasing how awesome his return will be, only to disappear again for many months without doing a thing. It is frustrating since Mark V is a really good port, but it could be even more if it was continuously updated. I don't want to be forced to use Quakespasm just because anything else doesn't run latest giant maps any more. (And QS/QSS isn't flawless, either, as I recently noticed during a thorough playtesting session.) 

… with most of this post. It would be really nice to have autosave, demo rewind, handy map and demo menus and the countless other features Mark V has in a new updated package.

If it played most releases it would be the best engine hands down. 

I mean, QSS ain't bad. It has the DLLs scattered all around the place instead of having it inside of the exe, but I could live with that.

However, it's missing .vis support, which is a big minus if you don't like to use pre-vised maps. Then there's no Nehahra support - OK, it's just one mod and the rest works, but still. QSS also seems to have some problems with SoA (final cutscene broken) and DoE (lavamen spawning in wrong places). Shrak head gibs are missing their skins (Baker fixed that in Mark V). There's probably more.

Either Mark V development is resumed at some point or at least they port over those features/fixes from Mark V to QS/QSS. 

However, it's missing .vis support, which is a big minus if you don't like to use pre-vised maps.

The hell is this about? 

Jordi's visor? 

http://vispatch.sourceforge.net/

Vispatch support. 

@onetruepurple
Basically .vis files are some kind of diff files which contain information regarding transparent water. If you have those files (which are much smaller than the actual maps), you don't need fully vised maps for transparent water. It's mainly about saving disk space (since usually you don't replace the maps inside of the original pak, but rather load replacements afterwards as some kind of patch). 

I think external .vis files can also contain colored lightmaps. I know there are a few colored lighting packs for Mark V and it's a bunch of maps\*.vis files.

And basically it works like external .ent replacement. 

Colored lights are provided by .lit files, not .vis. I bundled them in my Mark V packs for user convenience. Other than .vis, .lit files are supported by most of the popular ports out there, also QS/QSS. 

Oops, that's right. 

I'm on the fence about translucent water for classic maps. There are cases in id1 where water was used as a vis-blocker, and while performance isn't really an issue with those maps any more, it can be gameplay-affecting. I'm inclined towards the opinion that if a map wasn't designed for translucent water then it shouldn't have it, but on the other hand freely concede the visual improvement. 

Travail was vised without transparent water as an artistic choice. 

Actually Travail looks like crap with vised water. Many structures that reach into the water do not continue below the water surface, making them look cut or floating on top.

Anyway, someone should at least port over some additional functions from Mark V to QS/QSS if Baker's (or anybody else's) development won't resume.