News | Forum | People | FAQ | Links | Search | Register | Log in
Spiked Quakespasm Modding/Coding Help Thread
Thread for figuring out all the new particle and modding features in the "Spiked" version of Quakespasm.

Actual QSS engine download:


Tutorial on how to enable rain and snow on the Quake start map:

1. Video of snow:
2. Video of rain:


1. Put this start.ent download in c:/Quake/id1/maps folder. Tells it what textures emit snow and rain.

2. Put this weather.cfg download in c:/Quake/id1/particles folder. Indicates spawn information on particles and how they behave.

3. Enter r_particledesc "weather classic"; map start in the console. I assume "weather" is the name of cfg. Also seems to work with just r_particledesc "weather".


Q: How do you find out the name of textures?

With Quakespasm I don't know that you can, but in Mark V just type "tool_texturepointer 1" in the console and look at a surface and it displays the name of any texture you look at on-screen. screenshot

Q: How is the external ent file made and what does it need?

Open up Mark V and type "map start". Now just type "copy ents" and the entities for the entire map is on the clipboard. Open a text editor and paste. Save it as c:/Quake/id1/maps/start.ent

The first few lines of the file look like this, add the 2 bolded lines that tell the particle system that the texture names are "sky1" for snow and "wizwood1_8" for rain.

"sounds" "4"
"classname" "worldspawn"
"wad" "gfx/start.wad"
"_texpart_sky1" "weather.tex_skysnow"
"_texpart_wizwood1_8" "weather.tex_skyrain
"message" "Introduction"
"worldtype" "0"

A devkit is also available HERE with source code examples of how to create your own custom HUD using CSQC. The examples show CSQC recreations of the classic HUD as well as variations for the missionpacks and should serve as a good starting point for your own creations. There's a few other goodies in there too (e.g. particle stuff), so check the readme inside the devkit.
First | Previous | Next | Last
Why not use FTE, really?

Spike is going to burst a vessel one of these days, maybe we can head that off by bullet-listing a few things that are blocking FTE adoption. 
It might be a case of momentum. I mean, AD comes with a recommendation (and link) to use Quakespasm and since AD is basically default Quake now ... 
Why not use FTE, really?

FTE is close, and r_softwarebanding is sublime, but there's a few things that bother me and make QS still my go-to engine:

- In FTE, even in "classic" particle mode, particles are too bright (so are sprites)
- Models are shaded differently and are generally too dark - this looks especially problematic with things like the AD health pickup items.
- I don't know how to turn off coloured rocket, explosion etc. coloured lighting (can I?)
- Underwater sound is all different (is there an option to control this?)
- No controller support (yeah, yeah, I know)

There's lots of other little niggles and nitpicks that I don't really want to bang on about, like the exact details of how the menus and fonts look etc. etc, but you get the idea - point is I'm a purist and I will always tend towards the engine that looks the most accurate in my opinion. 
Just To Clarify 
I am NOT asking spike to implement any of that stuff just to please me (lesson, learned oh boy), I'm just answering Johnny Law's question. 
@Kinn, #116 
I suspect I ought to post this in the FTE thread instead, but I guess its a comparison between engines, so whereever...

sprite lighting differences - these are just drawn fullbright, so I don't see how there can be any difference. that goes for particles too, but to a lesser extent obviously. overbrights are not normally used on either of these, so no idea. comparing screenshots show the sprites at the same lighting level. maybe its just your imagination on account of dlight colours?
note that square particles have more coverage - and the result is more like software's rendering than QS as far as I can tell.

models - software banding applies to models too.
personally I think its QS's modes that are too bright - they're almost unshaded. but yeah, fte's models end up too dark in one direction and fine from the others. ironically fte follows ezquake in qw deathmatch and they all get fullbright... ho hum.
/me does a four-way comparison between various engines... quakespasm has double-brightness models (seriuosly, I check relative to glquake)! what happened to the lighting vectors? no shadows, no sense of depth, urgh.
imho of the three non-sw engines, fte was the closest to software rendering's model light levels - and quakespasm the worst.
so that's another thing to fling at the community when they claim quakespasm is somehow more faithful.

dlight colours - use r_dynamic 2. this should already be part of the appropriate presets. it still seems a little darker than software rendering, but so does qs so that's just an old config that predates the setting being added to the presets I guess.
(note: fte has some code to avoid over-saturation and loss of colour tone, which is kinda significant with eg q2 or bright blue quad glows, so darker is at least justifiable from that perspective)

underwater sound - switch audio driver to alsa or directsound, or anything other than openal (the menus should give many driver+device options). openal's reverb effects are nice and all (which is how come I got harassed into setting it by default), but yeah, openal sounds different from vanilla.

controller support - wut? fte has controller support. on windows set in_xinput 1;in_restart. its actually the default (now, since a few months ago, hurrah for lingering config settings). splitscreen without controller support would be awkward.

menus - not clunky enough? too small? or what? mouse support! zomg! or just so cluttered that noone has a clue what's actually in there... if it helps I hate designing UIs. Users always have different impressions of how its meant to be used... hence presets, so they don't have much of a choice. mwahahaha. But yeah, I admit that the options menu is a little hard to navigate on account of all the somewhat random options, and yes I personally tend to just use the console instead of trying to find whatever option it is... the apropos (aka: find, yes baker.) command is often faster, at least if you know part of the name... and yes I do unfortunately have to admit to grepping the sourcecode to find cvar names sometimes. :(

fonts - try r_font_linear 0;vid_reload, probably. personally I think that's ugly (especially with high res fonts, but whatever, if its what you're used to then its what you're used to, but I guess if you're trying to mimic sw there too then remember that software had clean scaling [while QS's defaults are not] so no half pixel weirdness[which linear sampling helps to hide]). it'd be nice if people would use truetype fonts so this stuff becomes (mostly) irrelevant, but oh well. linear filtering is at least the safer bet still, and legibility beats all else when it comes to text. 
Yeah I don't think you should worry about "banging on" :-) ... I did ask, and I think it's worth getting particulars out in the open if people (not just Spike) are going to keep saying that FTE should be used as the go-to engine for SP. And there's some people (not Spike) who rant about a conspiracy or at least a circlejerk keeping everyone holding onto Quakespasm, but I'm pretty sure that's not the whole story. 
(#119 was for Kinn obv) 
sprite lighting differences - these are just drawn fullbright, so I don't see how there can be any difference. that goes for particles too, but to a lesser extent obviously. overbrights are not normally used on either of these, so no idea. comparing screenshots show the sprites at the same lighting level. maybe its just your imagination on account of dlight colours?

These shots show what I mean - all particles are brighter and sprites get their colours blown out.

quakespasm has double-brightness models (seriuosly, I check relative to glquake)

glquake has dull models. FitzQuake (and descendents) changed the model lighting to resemble the original software quake. However.....

The above is really interesting - it shows QS is pretty close to vanilla software quake (but is actually a little bit too bright), but FTE is a bit too dark in comparison and the models do disappear into the scenery. I don't mind it too much, but some custom models that are designed with QS in mind (like some of the AD models, e.g. pickup items) tend to disappear a bit sometimes.

But what about from the back?

FTE is very close now (in accordance to what you said about the models only being too dark from certain angles). QS is like the front shot - close but actually a little bit too bright.

I'll answer the rest of your points tomorrow (I have to go bed now) but I still can't get the dynamic lights non-orange, or the controller to work (which I'm sure is more my fault than yours) 
Historic Note.

It would appear that Fitzquake, and therefore Quakespasm, (in its emulation of the original Winquake), ended up making overbright models slightly too bright than intended. 
WinQuake uses a variable amount of ambient lighting, plus a fixed amount of directional lighting.

The amount of directional lighting is very small, just enough to give the model some depth without evidencing the direction of the light. They made it this subtle because since the lightmaps doesn't store any angles, there was no quick way to rotate the directional lighting of the models towards the origin of the lights.

Plus, WinQuake also ensures a minimum ambient light value of 20 to viewmodels only. I don't remember if this minimum value is clamped or added, though. 
There's something on the FTE website that my ISP doesn't like. I have to use a proxy to even visit. It gets flagged as dangerous from Virgin. 
dlight colours - use r_dynamic 2

Doesn't seem to make any difference - it's still orange. All I'm talking about is an option of reverting to the white light of vanilla quake. Minor quibble, but the orange just feels a bit out of place in classic maps.

underwater sound - switch audio driver to alsa or directsound, or anything other than openal

Thanks - setting it to directsound via the menu seemed to fix that. Is there a command I can put in my config file for that?

in_xinput 1;in_restart

Didn't know about that, but in any case I can't get it to work with my XBox 360 controller. All that does is make the screen vibrate crazily and lock my view to the floor.

menu / fonts - I may talk about that another time, it's not terribly important. 
Found A Bug In FTE 
Tried to use delete to remove binds but it hard crashes to desktop.

Why doesn't FTE use an external .cfg file? I want to know what I am editing.

I also get the same problem as Kinn. My view shakes and locks to the floor. Control input is broken as far as I can tell. When I try to rebind in the menu it doesn't allow it. 
FTE Controller Binds 
DPAD = movement up/down/left/right

Left Stick =
moving left or right throws the view down, if you push up or down very lightly you can turn left or right.

Right Stick = pulling back moves diagonal forward, pushing forward moves diagonal back. RS also controls swim up/down respectively.

Right Trigger = Stops the view shaking

Nothing is bound to shoot, jump, change weapon, view center (centerview command is also not recognised despite being a default game command).

Yeahhhhhh.... Maybe steal EricW's controller input and allow binding for separate pads in the rebind menu? 
Why doesn't FTE use an external .cfg file

I just discover FTE dumps a ton of cfg stuff in C:\Users\[you]\Documents\My Games\FTE QuakeWorld

instead of the traditional place where you installed your quake 
FTE Hangups 
That last one is particularly egregious. I hate it when software thinks it's ok to hide data in other folders.

Does FTE support fence textures?
Does FTE support Orl maps?
Does FTE support AD Sepulchre and Swampy?
Does FTE have an option to use standard Quake physics instead of Quakeworld physics?

I thought QS and this QSS were the only engines that supported AD fully and the Orl megamaps? 
Non-base Directories 
I dislike that behavior that too. maybe -nohome or -disablehomedir 0 will do the trick. 
I Meant -disablehomedir 1 
FTE Feedback 
Hopefully the controller feedback can be taken on-board. Splitscreen is one of those things that I have been wanting to use for years.

I just have no idea how this is supposed to work with pads in FTE, what am I doing wrong here?
If I am not doing anything wrong then how can it be fixed? 
if you want to use fte's features then use fte.
if you don't do so then you're showing that it doesn't mean much to you.
and its actually kinda rude for people to keep asking for only a fraction of my stuff.

I really know that feeling.

I was really happy when QBism forked Makaqu 1.3 into Super8, and actively worked on it. That kind of thing is very rare to happen.

More often than not, other coders just looked at the engine from the surface, and only copied the features that were too evident to miss. There are tons of little improvements that are too subtle to be noticed without analyzing the code or which belongs to parts of the engine that most people don't care enough to notice.

And then we get people trying to solve things which we had already solved in our engines, but they didn't know because the only thing they cared about in our engines was just a couple of features.

After years of seeing this happen, I've realized that there was no reason to try to code my improvements in a minimalistic way to ensure ease of portability to other engines, because the truth is that almost no one will ever care.

When the Quake engine source code was released, everyone was curious to know how many kinds of cutting-edge features people could add to it, to make it not seem old in comparison to more modern games. Nowadays, what people want in comparison to vanilla Quake is for the engines to handle larger amounts of the same things that vanilla Quake handled.

There isn't much of an audience for technological innovations in Quake anymore. Rather than getting excited by them, people will usually get annoyed.

menus - not clunky enough? too small? or what? mouse support! zomg! or just so cluttered that noone has a clue what's actually in there... if it helps I hate designing UIs.

Well-designed UIs can have lots of options without feeling cluttered. The key is to figure out how to better categorize the information and organize its flow so the user don't get lost.

But yeah, designing UIs is an art form in itself, which requires lots of boring practice. 
Nowadays, what people want in comparison to vanilla Quake is for the engines to handle larger amounts of the same things that vanilla Quake handled.

That's an excellent observation and I think it's spot on. The community has transitioned from adding flashy stuff to Quake to wanting original flavor Quake - but in larger doses. Huge maps, fast rendering, quicker compiling, and so on, while still maintaining the software rendered look that makes Quake what it is.

I guess it's somewhat like car enthusiasts who covet classic cars. Eventually things become old enough that you get people who want the original again. 
It feels like a natural progression.

The Commodore 64 scene progressed in the same way. Initially there were add-on boards and such that added speed and memory to the base computer but, over time, demo scene coders transitioned back to the base machine and starting extracting as much power as they could from it.

There's stuff being done today on that machine that I never would have guessed possible. 
FTE, And Stuff 
@FifthElephant, Kinn
I had PrimalLove take a look at the xinput stuff (I don't have a controller myself, hence the prior b0rkedness). Hopefully it should be more acceptable now.
Note that you may still need to do 'cvarreset joy*' if any previous settings got saved to a config. Be sure to use a test release (ie: 5197+).

I found a bug in the defaultmodel.glsl code where it was computing a value and then discarding it, resulting in extra darkness, so that should be fixed now. It should be much closer to sw rendering (especially with r_softwarebanding enabled).

The double-brightness particles+sprites I couldn't reproduce.
the r_dynamic 2 setting not working is only a thing with the 'stable' build from 6 months ago - give the testing build a go instead, where its actually supported.

In other news (that's actually on topic), I have a QSS build that can run CSQC.
It has a number of intentional limitations that make it simpler to implement, but it should be ideal for custom huds/scoreboards/intermission/menus (read: 2d-only CSQC_DrawHud entry point, instead of CSQC_UpdateView with all its 3d nonsense).
When I get around to releasing it, I'll include an example hud, with some extra code to deal with DP's different expectations (FTE will be promiscuous).
For now though, there's still a number of issues that I need to resolve, primarily in the input handling stuff (for custom menus - quakespasm's mouse logic is not being too friendly). The current issue is how/whether to deal with fte's splitscreen feature - not that this is really a Quakespasm issue of course, I just want to avoid shooting myself in the foot as it were.
Probably nothing will come of it due to whatever, but without hope all we have is despair, or something *starts mumbling*. 
Cheers, I've just tried the latest FTE test build and the models look identical to WinQuake now (I even did a super-pedantic screenshot test). Sprites and particles also appear correct too. So, right now, I can make FTE look closer to WinQuake than any other hardware-powered engine I think!

I'll have a look at the controller stuff when I get home. 
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. 
QSS R9 Released - Simple CSQC 
Get it from here:
(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. 
Sorry, stupid oversight (due to csqc/ssqc abstraction). I updated the zips to fix that.

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?

Also thanks for the QSS fix, appears to be fine now in AD, cheers :) 
Disable QSS-specific Effects 
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. 
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.

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.

Add a variable that isn't used anywhere into a def file.
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. 
BUG Report 
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.

'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:
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. 
I See 
btw. for some reason i got this rendering borkage (the grey screen)while i'm running the frogbot mod with qss 
Wait What!! 
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. 
High Fps Normal Physics 
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.

Regarding Future Implementation In QS Vanilla 
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 ? 
@spike @Qmaster Re: Code Parsing Fuckups 
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 😂😂 
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.

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.

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). 
More Testing 
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.

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......

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. 
World Size Limit 
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 
@ericw Tools Says 

Create the output BSP file in BSP2 format. Allows the creation of much larger and more complex maps than the original BSP 29 format). 
Escaping The +- 4096 Bounds 
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. 
Yeah Thought So. 
There Is A Bound Limit On Bsp29 
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... 
Misaligned Lumps 
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... 
With A Mod? 
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). 
Projectile Reflection 
I'm a beginner at QuakeC, and I want to make a weapon that works like the airblast from Pyro's flamethrower from Team Fortress 2.
The airblast can reflect projectiles and launch players away depending on where the player's aiming it, here's how the hit detection is done in TF2:

I suppose it would be easy to replicate this in QuakeC, I'd just need to spawn an entity with its center offset to the player and in the direction he's aiming. But this has its problems (and they're present in TF2 and shown in the video), from what I've read Quake doesn't rotate hitboxes, and this will produce some really strange situations if the player is reflecting at an angle.
Is it possible to check collisions in a cone in QuakeC? If it is, I suppose I'll have to implement the math by myself.
Are there any other alternatives? 
findradius will get things within a sphere, that might be less bad than an AABB

you could also math it up yourself to get a cone, by testing angle between the airblast's forward vector and the vector from the airblast's origin to the incoming projectile.

However, a sphere might be better and i would size it big enough to be more forgiving to the player -- false positives are better than false negatives in this case i think. 
Not sure if the source is out there but there was a weapon called the AirFist in the Painkeep mod. It was also a stand alone mod released as a promotion for Painkeep IIRC. It's been over 20 years. But it was very cool back in the day.

+1 for making new stuff for Quake 
Yah AirFist was the first thing I thought of too. :-) We ran that for a while on one of the servers back in the day.

Looks like it can still be got here:

...and that does include the QuakeC source code.

(not sure if there was ever another release after version 1) 
BTW Torgo, that's just nostalgia coming through... we're not trying to dissuade you from making something new along those lines.

It's always cool to be able to look through a relevant codebase though, especially if you're just starting out with something as idiosyncratic as QuakeC. 
I agree with Johnny. I am new to QuakeC too so any existing code to look at is a godsend! 
Thanks for the help guys, I'm really against discovering the wheel again, so existing code helps a lot.

Also, I really appreciate your videos dumptruck_ds, it's actually the reason I started messing with Quake. 
You Might Need... 
Extras_r4 has some fancy particle effects, in particular it turns nails and rockets into 'particle' objects that react to forces. That mod has a cool gravity well thing that pulls nails and rockets away. Could be used to do the reverse. 
Thanks for saying that, makes my day!

There's a newer version of extras now that Khreathor fixed up. I'd suggest that. The source is included in uwjam. See here: 
just curious why on the first post it is raining inside?

2. Video of rain: 
maybe baker was curious as to whether the floor entity thing would cause the splash effect too (not my video, and I don't remember what state I left my examples in). 
Traceline And Texture Questions 
I'm trying to check what texture is below the player when he walks, then I'll change the sound of his steps depending on the texture.
I found this function in fteextensions:

string(entity e, float s) getsurfacetexture

So I thought that I should use traceline to get an entity below the player to get its texture:

traceline (self.origin, self.origin + '0 0 -40', 0, self);

But trace_ent always returns world.
I'm almost positive I'm doing everything wrong here, that traceline only interacts with entities and not the map itself.
Any ideas? 
Yeah, I was completely wrong.
Just do this:

local float surfnum = getsurfacenearpoint(world, self.origin + '0 0 -40');
local string s = getsurfacetexture(world, surfnum);
sprint(self, s); 
Missing Textures On Models 
Textures for models used with DP do not affected in QSS. Models still grey.
How to solve an issue? 
Spiked Particle Effects 
i was playing through lost sepulcher months back, and i was using the ad spiked mod, and i had the particle effects working.

i downloaded the most recent version of spiked, extracted the contents to the root quake folder, ran the exe, tried out vanilaa quake, but i cannot see the partical effects.

i must admit, i'm out of the loop here, so any advice would be appreciated! 
Qss Effects 
the particle stuff in qss were added for use by mods or maps, rather than forcing it on all users (retaining the quakespasm feel by default).
ad uses them, vanilla does not.

if you want to use custom effects, either use the r_particledesc cvar to tell the engine where to load the particle effects from, or do the equivalent via the particleeffectnum/pointparticles/trailparticles qc builtins, or use worldspawn keys of the form "_texpart_TEXTURENAME" "CONFIG.EFFECT" in your own map creations.
Without one of those, you'll get the same results as you would with unmodified quakespasm. 
Are you saying that the version of spiked released for AD has particles forced ON in the engine, and all other versions of spiked don't? 
Kinn (you Forgot To Log Out) 
No, they are opt-in only, and AD has opted in basically, it calls the various particles effects in the qc etc.
As far as I know there is no version of QSS specific for AD anyways? But AD is probably one of the only mods that uses these features? 
Learning Curve 
ah, i'm not really at the level where i can grasp a lot of this.

i was talking to rob martens, and he mentioned what i think you mentioned first (i quote):

1.) From a copy of Arcane Dimensions, copy the particles directory and the effectinfo.txt file over to your ID1 directory.

2.) In the QSS console, enter r_particledesc "effectinfo" to enable the use of the effectinfo file instead of the classic particles.

i'll give that a go.

cheers spike. 
Ah I'm confused because i thought the question sounded like "AD run with the spiked exe released for AD has particles, but if you replace with newer version of spiked exe no particles appear".

That's how I took the original situation, but if I'm totally wrong then disregard. Probably my crap reading comprehension. 
oh LMAO, sorry just read the original post #196 and he's talking about them not appearing in vanilla.

So yeah ignore me. 
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.