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.

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"
First | Previous | Next | Last
either irony or just a barefaced lie, depending on whether you think I was being witty or just a dick.

I do have some tweaks towards an r6, including pk3 support, but I'm too lazy to bother making sure everything else still works, and I still need to do something about that demo issue that sock reported (to fix, I need to rewrite some crappy code that someone else ported over from proquake, and as I said, I'm lazy).

so yeah, there will be an actual qss-r6 eventually, and not just for sock/AD (ooo, a proper readme! okay fine, enough hype...). 

adds pk3 support, a few bugfixes (saved games+demos), and a couple of minor things that smc uses.
the zip is also slightly more end-user friendly, imho, your milage may vary.

its almost certain that I missed something though. 
Really Amazing 
I love the effect, I wish it would be come standardized. 
Its great to have particles and weather in AD without the DP slowness. My r9 290 would go down to 2 fps in some of those levels. 
Ah This Is Great 
It's performance is better even than MarkV at my laptop which was from 2013 with an i3 CPU and integrated graphics core. The frame rate is definitely higher than in MarkV when I am playing AD_TFUMA.

Now if this supports multiple gamedir and using path as game dir (as in "-game ./Addon/CZG07") then I can die in peace. 
New Release - R7 
bigger maps, downloads, voip, more networking choices.


Impressive Changelog 
Quite the changelog there Spike! 
Some light testing ... Very awesome stuff!

It connects to DarkPlaces using DPP7 and appears to work just fine in a vanilla situation.

/Very incredible work in R7, Spike! I will no doubt be making acquisitions some time this year. 
entering "r_wateralpha 0.5" at the console with no map loaded crashes.

This bit in R_SetWateralpha_f seems to need an additional check for cl.worldmodel != NULL:

if (cls.state && !(cl.worldmodel->contentstransparent&SURF_DRAWWATER)

(same for tele/slime/lava) 
Also A Limit Bump Request 
static ents 2048 -> 4096
efrags 4096 -> 8192

IIRC there is a tutorial from MH on making these dynamically allocated, looks like Baker has applied it to MarkV and I should try doing it for QS as well.. 
thanks, although I'd already found the r_wateralpha issue.

if I make another release, I'm sure I'll pull whatever QS updates first, so consider those limit bumps a done deal with any future updates. 
its probably worth noting that sv.signon limits the max static entities to (65536-baselinedata-staticsounds)/sizeof(svc_spawnstatic).
With protocol 999 that's about 23/25 bytes, so about 2730, assuming no baselines (17 or 19 bytes with 666).

or in other words, bumping beyond 2048 is probably pointless in regular quakespasm. qss can benefit due to how I bypassed sv.signon, but regular qs probably just won't be able to use those extra static ents very often.
(note that my qss improvement can break engines that borrowed proquake's mid-map demo recording logic, which depends on assumptions not made in vanilla - that assumption is also in qs, but gone in qss-r6 iirc... pick your poison.). 
Thanks For The Heads Up 
Ah yeah that makes sense regarding >2048 statics.

I was going to at least attempt the unlimited signon buffer patch in QS. So that specifically has a conflict with the proquake mid-map demo recording I should look out for? 
yeah, iirc proquake saves a copy of the message containing the svc_signonnum, which works well enough when its just a serverinfo and a prespawn message, but when you have 50 different messages containing that prespawn data, all that extra stuff won't be saved and naturally won't be written into the demo.
I solved it by regenerating the prespawn data from what was parsed, though you could alternatively make a linked list of all prespawn messages (instead of just copying one). 
Two oneliner fixes for demo playback:
fix for a crash
static ents not appearing in demos

That should be all that's interesting in my git branch.. the other changes are tweaks to get it to compile on my jenkins box, and merging in QS svn.
QS svn has a rewritten Host_Loadgame_f where I eliminated that fixed size buffer, which was overflowing on the DP/QSS extended savegame comments in big maps. 
Quoth / Map Jam 9 Bug 
Barnak reported this in the map jam 9 thread and I was able to reproduce:
- install map jam 9 and quoth
- launch QSS r7 with -game func_mapjam9 -quoth
- launch start.bsp and walk straight ahead through 2 teleporters.
- the loading plaque comes up, (it's loading jam9_kell) then you're kicked to the console with "Host_Error: Illegible server message 110, previous was svc_serverinfo" 
QuakeSpasm-admod Don't Have The Issue 
I'm very curious to know what is happening, since about half the maps are looading without troubles from the start map, while others don't. You can still load them all from the console. 
While We're On The Subject Of Bugs... 
in qss-admod, on some maps when I try to save, the game crashes instantly. I've noticed this in the forthcoming episode jam's start map and some of Qmaster's old maps, and it happens both with quick and hard saves. It doesn’t seem to happen with regular QS. 
< /*ent->v.modelindex = */SV_Precache_Model(com_token);
> /*ent->v.modelindex = */SV_Precache_Model(PR_GetString(ED_NewString(com_token)));

The above fix has been in the 'prer8.diff' file on triptohell for a while now.
QS isn't as mallocey as FTE, which results in precaches being empty strings, which the client interprets as terminating the precache list when the server thought it was just another string. The idea behind the change from QS being so that eg vanilla's func_illusionary could use any model it wants, but I fucked up, and then kinda gave up.
There's also new bugs in 'pre-r8' which I'd need to fix before another actual release, but I can't find the motivation to actually spend time on it. 
I've been poking around with weather effects in QSS for the past couple days, and it's going pretty well so far. I've got a nice little map-specific, texture-emitted effect worked up for what I hope to be an entry to the Xmas Jam, but I'm having a little trouble with something: is there any way to get what I can only call "preroll" on a particle effect with the FTE/QSS system? Currently the particles start spawning when the map starts, and the player can see the effect getting up to speed. I'd love some way to have it already warmed up when the player first spawns, but as far as I can tell from this thread and what documentation I've found, there's no such option.

Does anyone know how I might accomplish something like what I'm after, or am I stuck trying to trap people for a few seconds on map start so the illusion isn't broken? 
Unfortunately there's no way to do that right now. The best I can suggest is to write some QC that spawns those particles for you, however this may run foul of any future 'preroll' feature.

I guess the easiest thing to do is to start the player in a room with a closed door, with any windows being high up, thus giving your snow particles time to drop.
As well as low skies... 
Black Box It 
You could atart the player in a small box func_togglewall textured with BLACK and then target wait, killtarget a func_wall box I mean, after a short delay. This would give the impression of loading. 
If you wanted to experiment with horrific evil, you might set host_frame 9999 on map load and then set it back to 0.

Depending on what mod you are using, there may be a way to execute commands.

Something like cl_forwardspeed 0; host_framerate 9999; wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait; host_framerate 0; cl_forwardspeed 400 
Ha, Spike knows immediately it's a snow effect, well yes, the jam is Christmas themed, I couldn't resist. The existing AD snow effect (or FTE? Not sure of its origins) was a little too jittery for my taste, and didn't have the lifetime I wanted, so I made my own.

I'll have my sky as low as possible, and maybe give people a simple button pushing task to complete while everything gets going. I'd also considered some sort of centerprint backstory about arriving just as the weather was getting worse, but then in engines that don't support these particles it'd sound weird. But maybe that's a writing challenge more than anything.

I appreciate the info and ideas (especially Baker, that's exactly my type of clever, sadistic cvar abuse); thanks for the help! 
FTE Software-like Rendering 
Is there any chance of including the "software" style rendering that FTE has?

I just had a look at this in FTE and it's exactly what I'm after :D 
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 if you do switch then rewriting it would have been pointless.

so no, no chance.
if someone implements it into QS then it'll get merged eventually (and I won't have to deal with extra merge conflicts). otherwise its not something that I'm going to waste my time with.

the point of QSS is to make something that the 'community' might accept that doesn't leave the people creating stuff with their hands tied behind their backs.
that's why it has qc extensions, md3s, removed limits, and better network compatibility.
note that even the particle system is aimed at mods like ad rather than the end-user.

and its actually kinda rude for people to keep asking for only a fraction of my stuff.
Its also a joke that people keep on insisting on using quakespasm because its somehow 'faithful' while being less faithful than the engines that they apparently shun.
Its not just software banding either, and I'm actually getting pissed off about it.
The entire thing is a massive counter-productive joke.
The point of QSS is to try to reduce the stagnation, its there so that people can create without being held back, rather than for the end-user themselves, that's why it does nothing as little as possible to change the feel of the engine, and yet so much for potential creators.

Adding user-centric features like ugly banding is simply not part of that goal.

So no, I won't port the code. I've no problems with merging it from Quakespasm if someone else wants to port it, but I'm not going to spend my time writing all that stuff myself. 
Ok, point taken.

The reason I'm requesting a "software rendered" look in QS isn't because I'm trying to add extra spangles and shininess and bloat to QS; it's quite the opposite.

I think of QS as the ultimate "faithful" quake engine, and I think adding an emulation of the glorious (not "ugly", it's beautiful and glorious) software look is something that fits the "faithful" quake spirit perfectly.

Hell, I'd play everything in an actual software engine in a heartbeat, if one of them could run a modern ad-style megamap at a decent framerate, but alas that's not possible, so emulating the software look in hardware is the way to go.

Anyway, I'm not gonna push it any more, I'l just keep quietly wearing ericw down I guess until he submits :) 
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 
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.