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. 

I had a short out-of-state vacation interrupt my participation.

When I returned I had to double down on engine coding before reading any forums because I am not happy if unreleased code is on my hard drive, moddb was down some messing with that.

btw .. nice video. Ironwail looks really user friendly and I knew it would be if the developer interacted with you, haha!

Very pleased to see the mouse driven menu and what looked like Quaddicted install. 

Sure, it needs to get closer to final form and it will.

You really excel at doing videos. 

 

lots of work over 3 months! 

hi, there was this one small rusty industrial vertical SP map, described as innovative on quadicted. any idea which one it could be pls? thanks 

ok https://www.quaddicted.com/reviews/aes_lrod.html srry