So you basically copied e1m1 effects from seven and his smc from here:
http://quakeone.com/forums/quake-mod-releases/finished-works/11595-a-5.html#post168861
But you forgot the slipgate fog. 

I mimicked Seven a little ;-) Seven is awesome and the best thing since sliced bread and all that and he knows I think that too, hehe. --- I put his name in the map title, press TAB and check it.

That said, I drew from a few different sources.

1) Tried to mimic an old feature I saw in a (past?) Quakeworld engine, but get the effect subtle.
2) Imitated an effect from ancient Rygel's Texture Pack.
3) One of the effects, I tried to imagine what it might look like if made to look right for Travail.
4) For another, I tried to imagine what it might look like in ijed's Space Hulk 256 with broken monitors.

Most engines BLARE an effect in your face --- that that's NOT right. Effects must add to the ambience, not dominate.

My interests are subtle effects that would fit in conservative engine base map. Although one effect might be more suited towards a medieval theme.

Tried to provide a solid foundation for others to use/modify/etc as a base. 

How do I run this? I unzipped everything to a quakespasm folder and ran quakespasm-spike.exe

It says "application was unable to start correctly". I'm on Windows 10 64 bits 

Try dropping spike's exe into a 32bit qs install, you might have win64 qs. The DLLs are different / incompatible 

Is there any plans to add these graphical features to Quakespasm OS X ? 

I was happy to see the source included compiled with no issue on Linux and ran fine also. ^_^

Neat stuff. 

Is there any thought of adding multiple gamedir support to "QuakeSpasm Spiked"?

I find it terribly useful to use in shortcuts or from the terminal with darkplaces when it comes to mods, add ons & content replacements. 

if I were to do that, I'd probably end up feeling compelled to rewrite much more of its filesystem code, which would make eventual reunification with vanilla quakespasm even less likely. so no, I'm not going to even try that.

when it comes to content replacements, I personally favour just dropping in a pk3 and not having to faff around with commandlines and other bullshit. this is more friendly in networked scenarios too.
hence why it'd end up with many more changes. 

Really neat effects. Loved them. 

@adib - Glad you liked. The area near the envirosuit benefits from ambience.

What's going on at the bridge would be well suited to some of the modern base map styles.

e1m1 is a bit of a "boxmap" compared to some of the more recent base maps that are fully decked out.

But wanted to provide a simple example using a map everyone knows.

Since it needs no QuakeC at all, it is quite easy to implement.

Just use "viewpos" to determine effects placement and then put a func_illusionary there to emit the effect.

@xage

Nice to know Spikes modded Quakespasm is easy to compile on Linux. ;-) Too bad compiling on a Mac isn't easy at all (thinking of Barnak). 

your "_texpart_notexture" is evil, and I won't support that moving forwards. instead I'll get it to just implicitly try particles/map_e1m1.cfg

r_effect is going to change slightly.
r_effect "modelname" "effectname" forward replace
will mean to use that effect, but project the particles forward (with veladd+orgadd), and make the model that they're emitted from invisible.
this should be interesting when combined with MF_ROTATE...

your progs/v_foo.mdl stuff makes me want to shoot you, a bit. obviously this doesn't apply to AD, but I'm very tempted to auto-precache inside setmodel inside spawn functions where the model is already set as the entity's .model field (which give all mods support for custom models).
combine this with FTE's "model" "*foo" muting warnings/errors about "*foo" not being loadable, and it should be possible to have whatever invisible models you want emitting particles without needing them on disk.

anyway, I think that's the way forwards with those hacks.

I also got submodels to generate surface particles. I have doors randomly firing railgun trails now... in both fte+qss.
and now all I can think of is how to cleanly get mdls to do it too... but meh. 

your "_texpart_notexture" is evil, and I won't support that moving forwards

Yeah, it was very evil. I knew you'd hate it. I needed something to make it run automatically, I found a hacky way to make it happen. But yeah, it's gotta go.

Why "map_e1m1.cfg" ... instead, please do 1 of the following:
1) id1/particles/e1m1.script // Nice name

A .lit is e1m1.lit, an .ent is e1m1.ent, I'm just thinking name consistency.

your progs/v_foo.mdl stuff makes me want to shoot you

Haha, it was quite hideous, but good clean demonstration without QuakeC support required it since I can't misc_model with standard id1 progs 1.06.

With Quoth or Arcane Dimensions, would have been non-issue.

Yeah it presents problem #2.

There should be a way to emit --- say -- sparks without a mapper having to come up with a new null.mdl each time.

FitzQuake supports a .alpha field that was unnatural, for instance. Perhaps invisible emitters (point entities?) that a mapper can place around (info_null or whatnot)?

{
"classname" "info_null" // is that right classname?
"origin" "120 23 128"
"angle" 90 // Please support angle!
"emit_effect" "smoke_2"
}

@submodels support = nice - that's going to open up some nice things.

Thought: remove "high.cfg" as a special random name to search for missing effects?

/Raw thoughts. 

 

Exactly! 

A .lit is e1m1.lit, an .ent is e1m1.ent, I'm just thinking name consistency.
They're also in the maps/ directory.
Using the same prefix and file extension means that those configs can be included from other maps etc (less useful if r_effect is abused for things).
really though, map_foo being auto-loaded should only be useful for map-specific r_effect lines, its not needed for rain/snow/etc, where it can just use the full effect name.

there is a traileffectnum field, and it should be possible to hackily convert "traileffect" "conf.name" into a precache for that (somewhat like "angle" is translated). Adding an emiteffectnum (and load-time emiteffect) to continuously spew particles forward should also be possible, which would help remove the need for r_effect. 

@spike

Yeah I figured you might say that and I do understand your stance, but I was curious. I mainly use darkplaces which supports multiple game dirs and I pretty much always launch from the terminal.

You've added some interesting features for the Quakespasm users. 

so don't die.
...in E1M1?!?