I'll have to play with it more later and try to narrow it down. Thanks though. 

what does it mean the console output

disabling rendering/network isolation 

Its a slight rework to host_maxfps.
Its enabled when above host_maxfps is above 72(or 0), and ensures that c2s packets as well as the server itself are throttled to no more than 72 fps without throttling the client too.

This means you can set host_maxfps to whatever you want and no longer get any physics issues because of it. Like all the other engines that already fixed it...

I should probably just remove the prints, at least once I'm sure it all works properly. I don't really expect any issues, I'm just paranoid. 

btw. for some reason i got this rendering borkage (the grey screen)while i'm running the frogbot mod with qss
http://quaketastic.com/files/screen_shots/spasm0000.JPG 

You should advertise that in the main post or something.

-Attention all those who own a fancy-schmancy high fps monitor! QSS/FTE now have a fix for high framerate physics bugs! Rejoice-

I would test in glee, except my poor-man monitors are stuck in the 90's. 

If it works flawlessly, would definitely join the tier 1 level of enhancements that improved the Quake experience.

It is a great thing that Spike has become more and more immersed in the world of traditional single player Quake.

(And this implementation is the least complicated one I've seen. I saw something about "bf" timing. Ironically, mh's implementation for allowing high fps normal physics had lots of comments addressing bonus flashes, I can't recall if he addressed that -- I think he did and it required an extra clock at a minimum.)

/I read the code 2-3 hours ago because I had a "WTF??" moment when reading that. 

I tested it a little bit last week on a 165Hz monitor and it looked/felt amazing. Agreed, this is a big deal! Check it out of you have a >60Hz monitor. (host_maxfps 0 = uncapped.)

The particle production rate was visibly a bit off @165Hz, but this is a well know issue discussed on insideqc. 

I ran it through a few input scenarios that I thought might be able to "mess it up" but not seeing any juttering with some stuff that used to very subtley trip up DirectQ's implementation.

Also did a quick test connecting to an online server to see how it behaved.

Everything looked and felt completely normal and fine.

Spike+++++++++ 

my IRC update code gets called from the _host_frame code in host.c

Is it likely that I'm going to have to significantly change the way I'm calling this when the physics and framerate are separated? 

A friend of mine would like to run Quake on 144hz monitor, but with 72fps physics. Using QSS by default the game run @ 144fps, and that does changes physics a lot. How to set original Quake physics while having 144fps ? 

Hm,so the code works when written in Notepad but not in the actual editor? I had the exact opposite thing happen to me recently when trying to add entity information to a config file in a Doom mapping program I use, so I wonder, was this program originally written for Unix compliant OSes (Linux Mac etc) or Windows? The text parser might be expecting DOS-format end of line characters and not getting them, either that or there's a bug in the code that is searching for the end of comment delimiter, I haven't looked at the code yet so I'm not sure which is the case but that is probably where I would check first. Then again I am a pretty inexperienced coder so maybe you shouldn't take my advice 😂😂 

@Shamblernaut
The specific patch is quite small, and if you're doing something that's sensitive to framerates that that would exist regardless of the rate at which the server runs at. So no, just the usual potential-but-trivial merge conflicts.

@nemo
QSS ALWAYS limits its physics to 72fps or less, regardless of video framerates, so its nothing to worry about with the latest QSS.
Just set host_maxfps to 0 and enable vsync and you're fine (usually - nvidia drivers seem to have issues with vsync and otherwise-high framerates).
If physics feels different then it'll be purely down to the interpolation (or if you're more familiar with higher rates - which are generally considered buggy).
I didn't add any settings to limit physics to eg 20fps as is the default on many dedicated servers. my aim was purely to smooth out the single player experience, and I personally hate 20fps anyway.

@anon
fteqcc accepts windows, unix, and supposedly also mac line endings, which is meant to match scintilla's behaviour also.
note that support for mac endings means that rogue's sourcecode does not compile as-is due to a mac line ending appearing in the middle of a single-line comment, and these being line endings means the next line contains uncompilable gibberish.
this is why I've configured fteqcc's text editor parts (a third party widget called scintilla) to display explicit line ending chars if they appear to be mixed.
While fteqcc attempts to support various types of unicode encoding, it only considers the ascii chars as whitespace, so chars like non-breaking spaces that you might have pasted in will confuse the compiler but might be invisible in the editor.
Any non-ascii codepoints are pretty much ignored - they're accepted in names, and any non-ascii chars inside strings will be treated the same way as they always have - needing eg com_parseutf8 1 in order to display them properly in-game (instead of as multiple random red glyphs). As an english speaker that's also quite lazy, this hasn't got much real-world testing, just specific cases that required annoying copy+pasted glyphs that I can't even read, so it wouldn't surprise me if the unicode crap is completely unworkable as-is.
It'd be nice to have an actual copy of a bugged file so that I can figure out which chars are actually in there, otherwise I have absolutely no idea how to progress (and I'm too lazy/paranoid to try fiddling with my system locale etc to try to reproduce it). 

Because I can't use the CSQC without using the new compiler version and I really like being able to edit within FTEQCCGUI for quick simple fixes so testing to help us fix this....

If I compile code that has a warning for a variable that isn't used anywhere, then // it out inside FTEQCCGUI, then compile, I get the warning about EOF in a comment on that line:
•If I then A close FTEQCCGUI, reopen and recompile, the file change is not saved (add popup warning to save edits?).
•Or If I then B manually save the file with // added within FTEQCCGUI from FTEQCCGUI's File->Save, close FTEQCCGUI, reopen, recompile, I no longer have the EOF warning.

Hmm...
If I open the same file within FTEQCCGUI and delete the // for that variable, then recompile, I get the EOF error again. I could have sworn the older version auto-saved any in-FTEQCCGUI edits before compiling, but it seems like something is screwy with that......

AHH!! THAT'S IT!
If I change the file within FTEQCCGUI, SAVE IT!!, then compile, then I get no errors. That's the bug, auto-save-all before compile is disabled. Can you please add that back or at least add a warning or prompt to "Save files before compiling?"

Still wierd how if I don't save before compiling, then compile, get error, then save, then compile, the error is still there. 

What is the proper way to compile big maps for quakespasm-spiked ? The default world size limit in Quake 1996 is 4096 units. Quakespasm/jackhammer is 8192 units (beyond that limit some bugs occurs in the game, even in QSS). If I go with higher limits (16384, 32768, 65536, 131072, 262144) ericw tools don't want to compile the map. Thanks 

ter-shibboleth world is 65536 units,

not sure, but prolly you have to add -bsp2(or something) switch to your command line 

-bsp2

Create the output BSP file in BSP2 format. Allows the creation of much larger and more complex maps than the original BSP 29 format). 

sv_protocol 999
gl_farclip 100000 (or whatever you need)

does bsp2 have anything to do with this, other than indirectly? (i.e. bigger maps - more leafs, clipnodes etc.) 

BSP2 has nothing to do with the bounds. 

 

Node bounds in bsp29 are int16_t so all of the coordinates have to be within -32768 to 32767; bsp2 changes these to float.

Not all engines use this value (fitzquake family doesn't) but winquake/glquake do use it for culling, and it would totally break rendering in those engines if you overflowed the coordinates, so it should probably be a hard qbsp error.

(talked to nemo on discord and I think he solved the issue, was too many verts on a sky polygon) 

thanks for the replies, i got it all !
huge maps are so cool... 

Just installed QSS and im getting errors in the console about ammo crate bps misaligned lumps. No idea what that means, and I didn't get those errors in original QS... 

Which level? I don't see any with id1 / e1m1, for example.

I get some for breakables in ad 1.70 patch 1 (maps/ad_brk/wood01-4.bsp)

It indicates a bug with the qbsp or other tool that wrote the .bsp file. 

Yeah, it's custom bsp's I had installed for the ammoboxes, regular Quakespasm seems fine with them, as does QSS, except QSS pastes the error in the console 

the warning is new to QSS and won't get displayed in QS.

if its your map/bmodel then update your tools, otherwise just ignore it. it won't affect the vast majority of people so w/e.

(any maps/bmodels that get warned about will give crashes if you try running them on android/ios/rpi, or really ANY non-x86 cpu. which means that its really easy to fail to notice when tools write out buggy files - I was guilty of it too with fteqcc a while back).