Eventual merge and option to toggle extension advertisement to the mod so particles could be either pixelly or DP??? Maybe hopefully someday. 

Seems when I updated to "Quakespasm-0.93.0-rc1" that when I walk up to a pedestal(sorry hate the word: PLINTH) the screen no longer goes dark making the text easier to read.

Is it just my setup? 

Hi! Seeing that people complain about this issue in unrelated places, I've made the patch, which automatically switches to protocol 999 when map bounds exceed -16384..16384 range (not sure this is a correct range, but that's easily fixable :) ). 

I wasn't aware this was an engine specific issue but this does make things easier.

So If I want something coded I just need to name my post "Not a request" - cool! 

I need to experiment with this a bit; one potential problem is a map like telefragged.bsp is right on the edge of the protocol 666 signon buffer limit, and won't load under protocol 999 in QS (signon buffers are larger with 999 since coordinates are 4 bytes instead of 2). I think that map has world geometry extending past +-4096 too.

Maybe checking if hull1 bounds exceed +-4096 would be a more robust heuristic? It would avoid false positives that work properly in 666, where the playable area is +-4096 but scenery extends beyond. 

For the most part, FTE+QSS doesn't use the signon buffer. Ambient sounds are QSS's last hold-out (excluding things the QC might explicitly write, but tbh I don't think I've ever seen a mod that actually does).
This basically obsoletes the signon buffer size limit, allowing for pretty much unlimited entities etc.
Additionally the revised entity networking doesn't need to send coords with every single packet either (and even if the mod forces it [eg: AD's sprite particles], it can do so over multiple packets, which avoids overflow issues with the datagrams too).
Port that part of my code over and it becomes a non-issue.

The real problem is when exactly 999 should actually be used...
Even small maps will benefit from increased angle precision on rotating things, so arguably the answer is 'always'.
In FTE's case I aim for network compatibility which means I try to auto-enable to as infrequently as possible (while fte supports multiple protocols simultaneously, it still can't cope with primitives changing sizes for different clients). Thankfully for QS, it doesn't really need to care about any of that.

Some maps have non-interactive geometry outside the 4k range in the form of a skyroom or whatever. Some might even have monsters (ready to be teleported in).
So perhaps the real solution here is to just create two new worldspawn fields - one to specify required origin range, and one to specify required angle precision.
The server would then be free to upgrade as desired, or not (if the default setting causes overflows/etc).
That or just upgrade everything so that it can be used by default/unconditionally (like DP does or FTE/QSS could). 

How does this sound for worldspawn keys?
"_maxcoord" "10000" if you need +-10000
"_anglebytes" "2" for requesting 16-bit angles

Yeah - this would be more robust than trying to guess based on looking at the bsp, which would also be a mess if different engines had different heuristics.

re: signon - yeah, I need to check out QSS's code for this again. 

I think I'd rather anglebits instead of bytes. Maybe I'm just weird. It doesn't really make any difference unless some crazy engine dev decides to splurge bits instead of bytes (like q3 does...).
And now I'm wondering what interpretations engines might make if they support different sized angles in different places... (client->server angles changing can be problematic, though 666 already uses 16bit angles there anyway).

Side note: in multiplayer situations, consider giving any out-of-order unreliables time to arrive before protocols are switched.

Could also be worth adding it to your qbsp too, if only to warn when large maps are not explicit about it.

Oh, I just remembered the issue with certain bsp entities with an erroneous angle of -1 breaking on engines with 16bit coords. that makes defaulting to 16bit angles messy too. Explicit limits are nice...

re signons: QSS+FTE dynamically allocate lists of the objects instead of storing raw network data, which allows them to selectively support extensions (although with baselines that data is already known anyway). This is overkill if your only aim is to remove signon limits. It would be easier to just create a list of signon buffers and allocate a new one when the previous one gets a little full. Its not as fancy but it'll get the job done. Really it just depends on whether you know what your clients will be given before they even connect... 

For the most part, FTE+QSS doesn't use the signon buffer. Ambient sounds are QSS's last hold-out (excluding things the QC might explicitly write, but tbh I don't think I've ever seen a mod that actually does)

I think that ne_marb does this when you activate the dais mechanism if you're ever after a test case.... 

I vaguely remember that Marcher sends sound messages from qc 

A map pack has 12 maps. One of the maps has large coordinates.

The start map does not have large coordinates.

Are you going to switch to protocol 999 when you walk through the teleporter to the map that needs large coordinates?

Or ...

Someone types "record mydemo; map verybigmap"

The demo is already recording before the map loads. Are you going to switch the protocol from 666 to 999 during the demo?

Someone wants to see how their map works under protocol 666 and types "sv_protocol 666; map my_new_map". Are you going switch to protocol 999 against their will?

John and Harry are playing coop. John types "changelevel verybigmap". Now what happens? 

Are you going to switch to protocol 999 when you walk through the teleporter to the map that needs large coordinates?
The demo is already recording before the map loads. Are you going to switch the protocol from 666 to 999 during the demo?
Yes. Going through a changelevel trigger does a Host_Changelevel_f which calls SV_SpawnServer, which sends the protocol version in SV_SendServerinfo, so it will already change protocols in QS e.g. if you load start.bsp with sv_protocol 666, change the sv_protocol cvar to 15, then walk through the teleporter to e1m1, e1m1 will start in protocol 15. Recording a demo of this and playback seems to work fine, and I confirmed that the demo file has two "FITZQUAKE 0.85 SERVER (24778 CRC)" headers with different protocol numbers after.

Someone wants to see how their map works under protocol 666 and types "sv_protocol 666; map my_new_map". Are you going switch to protocol 999 against their will?
No.. I guess to avoid breaking this scenario, sv_protocol would need to default to some other placeholder like "auto" or "666+" or something. Then "sv_protocol 666" would mean "force use of 666".

John and Harry are playing coop. John types "changelevel verybigmap". Now what happens?
Should just work as I was describing above, since the changelevel sends new serverinfo that may include a different protocol (?)

Btw appreciate the questions as I had to go and test the demo thing. I don't mean this is set in stone, and it's not implemented, but it would be nice to have automatic support for large maps if it can be done without negative side effects. 

It appears you meticulously walked through everything in great detail.

Which is how it should be done.

I haven't looked at the protocol 999, but I would assume it properly maps

WriteCoord (MSG_BROADCAST, player.origin_x);
WriteCoord (MSG_BROADCAST, player.origin_y);
WriteCoord (MSG_BROADCAST, player.origin_z + 16);

To the appropriate WriteCoord16/24/32 function. 

sv_test_protocol for the second scenario Baker alludes to, so it's crystal clear what it's used for. 

@Preach+metlslime
Those are not examples of MSG_INIT / signon buffer. Maps can't use it without QC, and marcher uses MSG_ALL (and breaks for new clients as well as saved games).

Yes if a mod uses writeshort instead of writecoord then you'll have issues if the engine switches protocols randomly. On the other hand, most people can't be bothered to do the *8 or the *256/360 thing, so mods that actually break in that way are rare, plus they'd be broken in DP too (like so many other things).

@Baker
there's not much difference between a demo and a regular network connection. I don't see any reason at all for that to break any differently from single-player breaking.
Besides, you can already switch protocol for the next map.

@ericw
Easiest is to just default to 999 and add a separate cvar to override the primitives. eg fte's sv_bigcoords cvar. Empty=auto(default), 0=shorts, 1=floats.
This would provide .scale support, even with 16bit coords...
The risk being people's configs that override things, and outdated clients. Forcing 666 up to 999 when using bigger coords is frankly the safer choice for those outdated clients, but hey. 

Why have a sv_protocol cvar if no matter what value the user selects, it will never be honored?

I pick 15 ---> nope you get 999
I pick 666 --> nope you get 999
I pick 999 --> you are lucky because I was going to give you 999 anyway.

If you see the humor.

What would work is honoring the sv_protocol cvar, but defaulting it to an automatic setting.

Spike would make the automatic setting "0", because Spike likes a value of zero to do wildcard things.

Spikeworld: Would you like 1 lump of sugar or two?
User: zero
Spikeworld: Then 12 lumps of sugar it is!

But a better default value would be "auto", which happens to have an atof value of 0 ;-) 

How does this sound for worldspawn keys?
"_maxcoord" "10000" if you need +-10000


The bounding box of the worldmodel would be superior method.

The bsp already has that data.

Would not require older maps to be recompiled. 

re-read #2976 

Here's a minor bug.

Quakespasm.pak doesn't load when using -basedir. It has to be copied to the actual Quake root folder. Maybe change it so Quakespasm loads it from wherever quakespasm.exe is?

Trying to make Quakespasm and vkQuake work with the same installation of Quake. Their DLLs are different versions and break each other, so I have to get creative.

Also, what's the deal with the vid_ stuff being ignored in autoexec.cfg? 

Is the greater than 72fps a limit of the network protocol? 

Is there a way to allow QC to refer to gfx.wad textures by name for certain "slots" in the hud inventory?

Not sure if there is a way to use WriteByte to send a string of commands to the engine to signal updating a specific hud "slot" to use a specified texture by name. QSS feature? 

I think it's more a limitation of how the physics simulation is designed.

Spike was saying that the results of physics after one 72fps timeslice can be different than after two 144fps timeslices. 

Is there a way to allow QC to refer to gfx.wad textures by name for certain "slots" in the hud inventory?

No. 

The HUD is absolutely and totally hardcoded into the engine.

DarkPlaces, FTE give you additional options (csqc). I don't believe Spiked Quakespasm has any csqc support.

I think with csqc you need to self-draw the HUD. Nahuel at QuakeOne had a open source implementation of a CSQC HUD.

http://www.mediafire.com/download/3tzacatwdazo4r6/HUD_v4.81_Nahuel_Dresk_Smith.zip

http://quakeone.com/forum/quake-mod-releases/finished-works/10604-csqc-hud-v4-8-rt-lights-edit-tool

http://forums.insideqc.com/viewforum.php?f=16

Providing information only so you can decide on options, altering the HUD is impossible in vanilla Quake.

If you were to make a CSQC custom HUD, it could work for DarkPlaces/FTE and other engines would simply ignore the csqc progs.dat just use the regular HUD. 

I have a small request, please bring back m_filter.