Even software rendered engine that added flashy stuff to be on hardware engine level get ignored in the end. super 8, engoo, makaqu all dead 

 

you mentioned once that CSQC for custom HUDs could be coming for QSS - is this still planned?
I've committed what I have to github. It should mostly work (if you compile it yourself), but its not perfect.

For it to be useful, it needs a clean example/base mod that people can use to do cool stuff without needing to figure it all out from scratch. I don't plan on releasing updated engine binaries only once that's actually done, because I don't see any real point without and it would risk people complaining about obvious already-fixed bugs.
Really it just needs polish. Lots of it. Hence why I haven't bothered to do anything with it for a while now. 

Cheers for the info. I'll have a tinker at some point. 

Get it from here:
http://fte.triptohell.info/moodles/qss/
(linux+mac users will need to compile their own).

This release adds support for a cut-down version of CSQC that allows for mod-created huds (but not fancy 3d stuff). Requires a compatible hud however.



Boring technical junk:
I uploaded a preliminary(read: probably buggy) qc dev-kit to that site too. Inside you can find a simplecsqc/src/csprogs_simple.src file.
Compile that with fteqcc (set up a file association or something) and you'll get a csprogs.dat that'll be understood by QSS+FTE+DP (cl_sbar 0 for a qw hud, or 2 for n64quake style, as an easy way to see that its actually doing something new). You can edit the csqc_hud_vanilla.qc file to do your own mod-specific things.
You can use clientstat from ssqc to register custom stats (starting from slot 32) in order to provide mod-specific fields to your csqc that can then be read with getstatf. You'll probably want to share your constants between both modules... Magic numbers are evil.
(I also knocked up some other files to provide hipnotic/rogue huds too. I guess that might be useful to quoth perhaps but probably noone else will care.)
Alternatively, you can just directly add the csqc_hud_vanilla.qc to the end of your ssqc src. Doing so will not give you a working hud in DP (so I don't recommend this), but will work in QSS+FTE (unless there's an explicit csprogs.dat, which takes precedence). Don't expect to be able to directly poke ssqc data though, it might be the same .dat but its a different qcvm.

Constructive feedback welcome. 

I will give this a rumble as soon as I can.

Just want to say thanks, this really opens up the possibilities. 

Hi, I'm afraid I'm getting a little crashette when I load up AD in this new build and fire the shotgun. I assume particle related? 

It's great to see this updated again. I'm prepping a video on source ports so I will add this to the mix. Questions tho. Is QSS a side project or is it starting to take over FTE? I'd just like to know a bit more history and have more context so I can communicate that in the video. And BTW the video is a few weeks away but on the to-do list. 

@Kinn
Sorry, stupid oversight (due to csqc/ssqc abstraction). I updated the zips to fix that.

@dumptruck_ds
QSS is still just a side project.
It was born out of frustration with engines like QuakeSpasm ignoring everything but vanilla-ish maps, hence QSS's focus on networking+modding capabilities (while otherwise trying to feel the same). 

AWESOME!..I'll have to test this out.

@dumptruck, make sure you emphasize how DarkPlaces is NOT a proper port since it doesn't have the twisty water effect.

Keep em coming! Both of you. ;) 

Man if we throw out every engine that doesn't have twisty water, that's a lot of babies being tossed out with that bathwater. :-)

There's a lot of tradeoffs that come up when you get into engines-talk. Like,
with DP you get hit with changes to lighting and movement if you're interested in vanilla-ish singleplayer, but if you really want to go hog wild with replacement media it's the main vehicle for that.

For singleplayer stuff like dumptruck is focussing on, I'd be tempted to say that most folks should just use whatever engine the mapper created/tested the map on. If you later get into being an enthusiast of tricked-out engines like FTE you can learn to work around the occasional gotcha (like the Quoth thing being discussed on some other thread). 

Hi Spike, slightly different topic but where's the most complete documentation for fteqcc located?

Would it be here? http://fte.triptohell.info/wiki/index.php/Main_Page#FTE_QuakeC_Compiler

Also thanks for the QSS fix, appears to be fine now in AD, cheers :) 

Forgive my ignorance, but how do I disable the fancy effects I get in conjunction with Arcane Dimensions? Renaming the effectinfo.txt seems to work, but I get error messages when any projectile impacts a wall. I don't like switching to normal Quakespasm for that, because it lacks features like set/seta, which are a godsend. 

@Kinn
Sorry, I never got around to writing proper docs for fteqcc. Someone else beat me to it, so there never seemed much point. Admittedly those prior docs are woefully out of date now, but hey...
Basically, C syntax is meant to work, unless it conflicts with existing QC syntax.
The options dialog of fteqcc should document the basic idea of most compiler flags.

@DabbingSquidward
If you set pr_checkextensions to 0, then AD will no longer be able to detect any QC extensions at all, and will thus use its entity-based particles instead (the exact same behaviour as in regular Quakespasm).
(Unfortunately AD has no way to select between entity particles and engine particles - if it thinks that it can use engine particles, it WILL use them.)
IIRC, the other option is to set temp1 to 1024, which will disable AD's engine+entity particles alike. 

Using the provided updated fteqccgui.exe, anytime you edit a .qc file within the program it causes EOF errors.

Reproduce:
Add a variable that isn't used anywhere into a def file.
Compile.
Double click on the warning for no references.
In the subwindow that pops up, comment out a variable.
Compile again.
Witness the ERROR EOF detected in comment of file. 

Using the provided fteqccgui.exe (ONLY one with support for compiling the csqc files which is why I'm considering this a bug report related to QSS), I get multiple erroneous no reference warnings for variables. After commenting out the related variable, I get numerous errors for not having defined that variable.

FYI. 

'EOF inside comment' means that there as a multi-line comment that wasn't terminated.
//single line comment
/*unterminated multiline comment that will hit eof
otherwise I've no idea what you're actually doing, and thus no idea how to reproduce.

Regarding unreferenced variable warnings, I'm going to need a proper example/more info.
If you're using '#pragma sourcefile' then remember that its compiling your code twice, and variables that are unused in your csqc are likely NOT unused in your ssqc (and vice versa).
If you're lazy, you can use the __unused modifier to just mute the warnings, but I wouldn't recommend doing so with fields. 

Eof: Simply using // to comment out variable definitions e.g.:
// .float gorging;
Which then gives me that error for EOF on that line, but only if I add // inside FTEQCC's gui editor. If I add // in Notepad it's fine.

Unreferenced warnings (about 133 for my project) are showing that a variable is not used in this new version while the older version of fteqccgui has 0 warnings. The "unused" variables are clearly used by the code so some check must be either not parsing all files or failing to parse all files to see if they are used.

Tested without csqc and no #pragmas. 

the 'EOF inside comment' error message is specific to multiline comments, and I have absolutely no explanation that would not be accompanied with a 'file contains null bytes' warning.
All I can really say is that there's more going on here than it seems, and I've no idea how to reproduce it.
The second bug is quite probably the same root cause as the first.

If editing your code works in notepad then you may have to just stick with notepad. You can get a commandline-only version of fteqcc here: http://fte.triptohell.info/moodles/fteqcc/
There's also some docs there for fteqcc's extra syntax, if anyone needs it. 

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.