If your func_plat has a targetname, it needs to be triggered first. 

Thanks. I enabled the flag "start lower" and it worked, 

@#19191, I will answer my own question:

No you can't see a custom particle style effect in QS Spiked or Darkplaces. Unless through the action of some obscure cvar I don't know about.

In this case it is pointless to use the particle_template system, as probably no one will see the effect. With the release of QS Spiked and the popularity of Darkplaces, I consider it a worthless novelty to use this effect.

Just going to go with the included particle effects that work across all source ports. Back to mapping... 

Since I'm no texture artist I try to use textures from an online source which start really large(1024X1024}. If I convert to the Quake palette and then shrink down to 128X128 they of course look like poop. But 256X256 is often doable.

Thing is, then in the editor I have to adjust scale by .5(X and Y) to get back to 128X128. I've read that scaling up is bad but scaling down also has an impact on the lightmaps correct?

My questions are: How detrimental/noticeable is this to gameplay and is there a way to have the lightmaps not affected by texture scale? 

It might not look too bad if your scale is something like 0.75, 0.5 should be noticeable. If, however, all the textures in your level are scaled to 0.5, then you are fine.

Half-Life 2 used all the textures scaled to 0.25. Wierd huh?

Not sure if lightmaps would scale down with texture size...my gut instinct is no. 

A texture scale of 0.5 also doubles the lightmap resolution; they're linked by a hardcoded ratio of 1 "luxel" (lightmap pixel) : 16 texels.

The other side effect is qbsp chops faces on a smaller grid as you lower texture scale. e.g. on large surfaces, a texture scale of 0.5 will create 4x as many faces (2x on each axis) compare with texture scale 1. You can see this with r_drawflat 1 or r_showtris. 

Title says it all ;) 

Does this mean you could get better resolution lightmaps by scaling all of your textures to say, 0.5 and them doubling the texture resolution?

Someone should make a tool to do that automatically. I'm sure having way more faces is no problem for even semi-modern GPUs. 

1. Hmm...so on surfaces with tiled textures, do the faces get broken up to a 1:1 texture ratio such that for every repeat of the texture there are 2 tris? In otger words, a 10 times tiled texture on a large wall, for inatance, has 20 tris minimum?

2. Are faces sharing textures technically submeshes or part of one total mesh fir the level?

3. Does each texture require a separate mesh (VBO I suppose) sent to the GPU? 

1. AFAIK the reason surfaces are split up is to do with the internals of the software renderer and how it blends the lightmap and texture (the surface cache). It's not about texture repeat; one tri/quad/etc. can span multiple repeats of the texture both in software and GL engines.

2/3. I guess it depends on the engine. What Quakespasm does is store the vertices / texcoords / lightmap coords of all BSP faces (main map + submodels + external .bsp files) in one VBO which is sent to the GPU at map load time. To draw a face, it sends the indices of the vertices that make up the triangles that form that face. These are grouped into batches of texture and then lightmap texture. They are separate draw calls, I'm not sure whether these are considered meshes. 

Re: #1

Large surfaces are divided every 240 texels in each direction by qbsp. I think this is because 16x16 is the max size of a lightmap, and if you put a sample at t=0, and another sample every 16 texels, the 16th sample is at t=240. 

unlike vanilla, quakespasm should allow -subdivide up to 1984ish.
fte+dp go up to 4080ish.

such sizes can hinder lightmap atlasing, so its probably best to keep them somewhat sane in size.
this is especially true for weird shaped surfaces where much of the block isn't actually used - more divisions doesn't always mean more lightmap data. that said, if you've a lot of 256*256 texel surfaces and you're targetting at least qs then bump the subdivision size by a little, to avoid those 256*256 surfaces getting split into 4 separate surfaces. 

Maybe some or all of these questions are laughably basic, but I don't know the answers and I'd like to.

--> Is it important always to stay on-grid in Quake? (I don't mean as a rule of thumb or as a general guideline for newbies, but really always.)
--> If so, why exactly/ If not, then when is it important?
--> And does it apply to modern compilers and engines, or is it something that is (partly?) related to the limits of the original compilers and engine?
--> And does it apply to e.g. detail brushes as well as worldspawn?
--> What is the practical difference between on- and off-grid brushes when compiling and when playing?
--> And finally, what does staying on-grid actually mean? Is it that each brush has to have all vertices on-grid, or is it enough if e.g. four out eight vertices are on-grid? Is it relevant whether brush faces pass through points of the grid? 

early exporters always rounded coords to the nearest unit. modern stuff doesn't really require that, but legacy and all that... probably your map editor has an option in its export settings. note that rounding could uglify various maps...
the vanilla qbsp truncates on load, rounding towards 0 instead of to nearest.

rounding verticies to the grid also means you can avoid floating point precision problems that result in micro-cracks and associated leaks that prevent the map from being vised, in such a way that can be horrible to track down.
this also goes for axial surfaces too, of course.

rounding verticies is one way to avoid excess texinfo entries in the final bsp. note that this is really more of a size thing than any real performance issue. note that this is only really an issue with 'valve' map files. quake's vanilla texture alignment stuff sucks enough that they'll all get merged regardless.

note that constantly converting from/to verticies and planes will accumulate inprecision. rounding avoids that.

the engine itself doesn't really care if something was on or off grid - it can bug out regardless. The engine internally uses 1/8th precision for standard networked coords (though recent engines have [optional] support for full floats). either way, the server physics is always full floats.

so yeah, the only real issues are
1) accumulation of inprecision.
2) cracks (which have many other causes, so why care?). csg carve sucks anyway.
3) old editor/qbsp compat.

or something. I'm really just making this stuff up as I go. Here, have a pinch of salt. 

From a purely design viewpoint: Its good practice to stay on grid. I'd say a majority of us build on grid but there are some out there who dont. MFX's ad_swampy has a lot of off grid arches. 

The engine internally uses 1/8th precision for standard networked coords (though recent engines have [optional] support for full floats). either way, the server physics is always full floats.
The weirdest glitch I saw due to off-grid was in ad_swampy and due to this.
An item_health was dropped to the floor (which happened to have an off-grid Z height), then going through the 1/8th precision network moved the mdl into the floor. The mdl rendered black as a result, because the traceline to sample the lightmap started underneath the floor. 

I've been mapping for around a month now and I just remembered what levels are supposed to look like when you noclip out of bounds. they should look like this https://i.imgur.com/g9YjNCm.png but mine looks like this https://i.imgur.com/I1mNEwW.png
I honestly have no idea what that's called (if it has a name) or if it's even important yet but I'd like to know how to do it. 

You've got a leak in the level someplace and qbsp isn't doing its job properly. Basically, the 'play area' of your level isn't completely sealed by the geometry and you've got a gap someplace allowing the playable area to 'leak' to the outside void. This makes the compiler unable to tell what parts of the level should be cut away (normally brush faces facing the void are removed, leaving only the inward-facing ones that the player will see), and it'll cause vis to not work properly so the larger the map gets, the slower it will run.

Just looking at that screenshot, an immediate leak is right in the middle, where the double doors are (assuming you've already made them func_doors)- entities don't seal the map, only solid geometry, so until you build an enclosed area past that doorway, the map will leak. 

https://imgur.com/a/Rj5FQ 

Thanks, spike, ericw and mukor for your responses to my questions.

There's a lot in Spike's answer I didn't initially understand and I had to look up a few terms. I think I have a better grip on it now, but there are still a few technical terms I don't understand, despite searching around on the internet. In particular, the part that ericw also quoted,
The engine internally uses 1/8th precision for standard networked coords (though recent engines have [optional] support for full floats). either way, the server physics is always full floats.:

What is "1/8th precision"?

What are "standard networked coords"?

What does "server physics" refer to? (As I understand it, the client/server thing is central to how Quake works, but it's all completely mysterious to me at this point; I don't understand what clients and servers have to do with single player Quake.)

Embarrassingly, I'm not even clear on what "full floats" mean. As I understand it, integers are numbers like 1, 15 or 123, with no additional fractions, whereas floats are numbers like 1.05 or 1/4, etc. (not entirely sure if I understood that correctly, though. I tried reading up on floating point arithmetic, but it was like trying to read a foreign language).

If someone could shed some more light on the above, I'd be very grateful. 

1/8th precision means that the coords are multiplied by 8, rounded, and then networked (as shorts). This is what results in the 32767/8=4096 +/- maximum bounds.
This is often described as 13.3 fixed point precision - 13 bits above 1 (including the sign bit), and 3 bits for precision below 1.
or in other words, there is a precision of 1/8th quake unit over the vanilla network protocols. that's what's meant by 'standard network coords', because its the lowest common denominator.
note that vanilla rounds coords towards 0 (because integer rounding truncates). whereas a couple of engines round to the closest value instead, because its slightly more precise. yay differences.

server physics is stuff moving around serverside. all the logic in nq is serverside, so there's none of the 1/8th rounding stuff going on.

'full float' means that it just uses 32bit single-precision ieee floats without any annoying extra rounding.
[side note: many gpus support 16bit half-float types nowadays, because gpus are cheap]
note that floats concentrate their precision around 0, the further away your coord gets from 0, the less precise it gets. They're weird in that they're expressed as an exponent, with 1 raised to the power of 8 (signed) bits, then multiplied by 23 of the remaining bits, with the final bit being used for sign. Which is annoying, because it means floats have -0 as a separate value from +0. Of course, the actual logic behind them is typically irrelevant, just remember that any time the exponent changes then the precision that can be expressed also changes.
Whereas 13.3 fixed point has linear precision, and within the 16bit confines of the inner map, floats will still have more precision than can be displayed, so yeah, you won't notice any issues, but the qbsp might if things are non-axial. 

Floating point numbers are essentially numbers with decimal olaces. When people talk about precision, they're talking about how mamy decimal places are stored by the computer.

The more places you store, the more work memory required etc, especially with older computers this could really affect performance, so Quake and other performance focused applications would store as few places as possible to get by.

The side effect of this is that you lose data by reducing the number of decimal places you store. That means that movement is (very subtly) less precise and, in the case of level compilers, data could br thrown away compared to what was actually in the source file.

Hope that helped a bit, and wasn't too incorrect. 

and since no one directly commented on this "I don't understand what clients and servers have to do with single player Quake."

Quake single player is still played on a "server". My guess is this is because of coop.