I bet both Darkplaces and FTEQW does this.

All engines that supports custom protocols already switches to vanilla protocol 15 when playing ID1 demos or connecting to vanilla servers. Engines that supports both QW and NQ protocols will most likely switch between them automatically too. 

DarkPlaces ... doesn't "suck".

It's brilliant.

It has held itself back with a few handfuls of frustrating choices that caused the user grief.

I am expunging those.

https://www.celephais.net/board/view_thread.php?id=62234

I could produce a list of "mistakes" -- but why bother and I'm no scorekeeper -- instead I will just fix them.

I have great gratitude to LadyHavoc (and others .. DP is the work of a number of contributors) for efforts in DarkPlaces.

Ironically, it was LadyHavoc who got me into engine coding.

In 2007, LadyHavoc was one of the players who joined the "Dredd Server" debut (a server Phenom and I started) ... and late into the night .. R00k (Qrack) and LadyHavoc talked engine coder stuff for an hour. I listened intently as they had a very interesting conversation. I started to wonder if I could maybe update ProQuake like adding FitzQuake's video mode switch to it.

I also went to great efforts around that time to integrate DarkPlaces into multiplayer NetQuake community and LadyHavoc made many changes to the engine, I was always astonished by how quickly.

I think 2007 was also the year mh coded a Direct3D wrapper overnight and we ported it into 6 engines.

DarkPlaces can open some doors that will always remain closed doors without it as things stand now. 

DP still has the best netcode out there. just works. 

big shoutout to LadyHavoc 

I remember in 2012 or so using DarkPlaces and I lost my mind in anger.

I was already frustrated with some stuff that I couldn't turn off because I dont know the words.

Then I save a game.

I cannot find the save anywhere. I do a file search of my Quake folder, it is not there.

Far too many times, DarkPlaces did that kind of thing. 

hm, what happened to LordHavoc 

For the first time since so many years playing Quake1, I found a big map that asked for -protocol 999 during game launch (map addy_cl_m4, which is a true jewel, by the way!). What is this protocol? Should I use it as default to play all my other maps, instead of the regular one with QuakeSpasm? 

If it is the case here, but testing Quasm I found that quakespasm2.2 asks another protocol then quakespasm2.4.
It goes to protocol999 from protocol15.

It can be my poor attitide to see the change in update. 

Is an evolution of the stock FitzQuake protocol 666 with added support for extra-precision angles, larger maps, etc. It's been around for about 10 years now.

I personally think you don't need it, and won't get any advantage from it, unless you're playing a map that specifically calls out requiring it. Otherwise 666 is fine, and well-supported. But there are serious limits in stock Quake protocol 15 that make it unsuitable for anything other than very old maps. 

Is there any drawback or issue by playing all maps and mods with protocol 999, instead of 666?
May I find that some maps don't play well with 999, while it's working great with 666? 

999 was designed so that in it's base format it's identical to 666, with the exception of some "protocol flags" bits which servers can use to announce additional features they require. The intent was for servers and clients to negotiate supported features but the design and implementation never got that far.

These features could in theory be anything. A few were baked into the initial implementation as examples, such as increased co-ord ranges which were required for some of the maps that 999 was designed around, but there's nothing to stop an enterprising coder from building an entirely different protocol on top of 999.

The main drawback of 999 is that in it's current implementations it's still an NQ protocol. That means no prediction if playing online, and no delta states so packet sizes can seriously bloat.

Again, the design of 999 allows these to be added by someone who was willing to put in the work, and the original intent of 999 would have allowed graceful (or at least semi-graceful) fallback to default behaviours if a server or client didn't support them.

Maps that might have problems with 999 are those with large entity counts, where the increased co-ordinate range bloats the packet size in excess of the in-built maximum. The AD particle system in many engines is one case where I could see a risk of that happening. 

That doesn't mean "don't use 999 for AD", by the way. Some AD maps do need the larger co-ord range that 999 gives. 

New video goes live tomorrow along with the new release. It's pretty amazing. A huge upgrade from 0.6

https://youtu.be/9MO3GxoNm8o 

I'll be watching that for sure. But a 27 hour wait ... 

Would love to do a Zircon video this summer for sure. 

Explainer Video: https://youtu.be/9MO3GxoNm8o

Download: https://github.com/andrei-drexler/ironwail/releases/tag/v0.7.0 

Did anyone actually try P2ST map compiler yet?
https://celephais.net/board/view_thread.php?id=62217 

There would have to be incredibly compelling reasons for anyone in this community to consider switching from ericw-tools.

Total feature parity with ericw-tools would need to be a starting point I would say, and then it would come down to what a new compiler system could offer in addition to that. 

I understand there is a biiiiiiiiiiiiiiig long-in-works update to the ericw-tools coming at some point. 

Some of the features listed in that P2ST thing sound bloody fantastic.

But my personal view is that the best chance of getting any new awesome stuff to be used by the Q1 community, would be to collaborate on ericw-tools, rather than try to push a competing and different set of tools. 

 

Duplicate of my reply in the News' comments just in case.


On Quake lighting Uncle Mike wrote:
"added full support for Quake lights and their specifics" and mentioned all these delay, wait, cone, cone2, etc.
and "introduced -quake key, sets gamma 1.0, -dscale 0.5, -sky 0.0, and enables -lightbalance. Basically this is a preset to make lighting purely Quake-like".
https://csm.dev/threads/p2st-compile-tools-v-096-beta-bezier-curves.39031/


On limit exhaustion:
https://csm.dev/threads/novye-kompiljatory-urovnej-dlja-xash3d.38603/post-951887

You probably know that now I can't sit tight because of Ericw's compilers for Quake called TyrUtils. Can't say that they're better than mine in all aspects, more like the opposite. But they do possess certain features I don't have. Therefore - these should be added. Meanwhile I compare them for effectiveness and speed.

My coplilers
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
entities [variable] 205865/2097152 ( 9.8)
planes 4968/524288 99360/10485760 ( 0.9)
textures [variable] 8852/33554432 ( 0.0)
vertexes 23696/393216 284352/4718592 ( 6.0)
nodes 9839/262144 432916/11534336 ( 3.8)
texinfo 1212/262144 48480/10485760 ( 0.5)
surfaces 17951/262144 502628/7340032 ( 6.8)
clipnodes 16821/262144 201852/3145728 ( 6.4)
leafs 6289/262144 276716/11534336 ( 2.4)
markfaces 21909/327680 87636/1310720 ( 6.7)
edges 42399/1048576 339192/8388608 ( 4.0)
surfedges 83552/2097152 334208/8388608 ( 4.0)
models 215/4096 13760/262144 ( 5.2)
=== Total BSP file data space used: 2.70 Mb ===
World size ( 2560 2304 3968 ) units
original name: maps/ad_metmon.bsp
internal name: Arcane Monstrosity

TyrUtils
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
entities [variable] 204240/2097152 ( 9.7)
planes 4855/524288 97100/10485760 ( 0.9)
textures [variable] 854214/33554432 ( 2.5)
vertexes 30612/393216 367344/4718592 ( 7.8)
nodes 16485/262144 725340/11534336 ( 6.3)
texinfo 1359/262144 54360/10485760 ( 0.5)
surfaces 25385/262144 710780/7340032 ( 9.7)
clipnodes 25845/262144 310140/3145728 ( 9.9)
leafs 10496/262144 461824/11534336 ( 4.0)
markfaces 29568/327680 118272/1310720 ( 9.0)
edges 65668/1048576 525344/8388608 ( 6.3)
surfedges 100675/2097152 402700/8388608 ( 4.8)
models 215/4096 13760/262144 ( 5.2)
=== Total BSP file data space used: 4.62 Mb ===
World size ( 2688 2432 4608 ) units
original name: maps/ad_metmon.bsp
internal name: Arcane Monstrosity

Performing time of my compilers:
4 sec csg + 12 sec bsp
Memory consumption: csg 39.64 Mb, bsp 30.36 Mb (memory not summed up)
TyrUtils:
11.000 seconds elapsed (qbsp)
Peak memory usage: 163320980 (155.8M)

What is intresting:
1. In terms on limit exhaustion my compilers are definitely more optimal than TyrUtils. Nearly 1.5 times more effective. It's unclear why planes are being exhausted faster though. I mean it doesn't matter, they're 32-bit-limited, but anyway.
2. Memory. I was in doubt but nearly 100% sure now, compilers were split to save memory indeed. This is the most simple way besides screwing with correct memory freeing. And the effect is quite noticeable, too, as you can see. We win 2 to 4 times more memory.
3. TyrUtils work in a single thread (qbsp) without any special optimizations and they're still faster. I've got a couple guesses: either SSE optimization of modern IDEs give an effect here, or this is an effect of VHLT's chinese accelerator of BSP tree building, for small trees lagging more than original code but accelerating greatly with increasing polycount. Can't say for sure yet.

And there is another post with statistics on the same page.
Keep in mind that this was early on and he kept working on P2ST throught the next year.