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! 
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.