Okay so I have a room that is going to turn of all the lights once u pick up the key. Then it will teleport 3 monsters, every 3 seconds from 3 different spots until it has teleported all 9. The lights wont come on until you kill all 9. The problem is, the first 3 monsters teleport in just fine... yet the next 2 pairs teleport in at the exact same time... even though I put a delay of 3 seasons on the relays. They teleport in after 3 seconds, but the 3rd wave instantly teleports in and doesn't delay for some reason- instantly killing the 2nd wave. Any ideas guys? 

Did you accidentally set the third triplet of trigger_teleports to have the same targetname as the second set? Also, uploading the .map file often helps people diagnose what's going wrong. 

trigger_relay
targetname|lightsout
target|roomlights1

trigger_relay
targetname|lightsout
target|wave1
delay|3

trigger_relay
targetname|lightsout
target|wave2
delay|6

trigger_relay
targetname|lightsout
target|wave3 (SHOULD NOT BE wave2)
delay|9 (SHOULD NOT BE 6)

Maybe? Hard to tell without the .map file. 

So the stock misc_particle effects available in the AD fgd are usable in the sense that Quakespasm/Mark V will see a particle style effect, and Darkplaces/Quakespasm Spiked will see a Darkplaces style effect.

Each predefined defined misc_particle has a corresponding Darkplaces style effect that will be seen in QSS/Darkplaces. However, if you make a particle_template and create your own effect using various particle sprites, is there any way to see this effect in QSS/Darkplaces?

It seems the only thing I can do is attach a dpp_name (eg. DPP_ITSPORTALSIDE) and substitute a Darkplaces effect for my custom effect. The custom particles will not appear in Darkplaces or QSS. This is what I did in ad_paradise.

Is there any way to see a custom particle effect in QSS or Darkplaces? 

I tried to use AD's entity state system in my map for disable (NOT remove from world) and later re-enable func_plat. But I get a not working func_plat already when I starting the map (before the player touches the trigger, which disables the my func_plat) :( And removing all added enititirs couldn't help to fix it problem.

How to right use state system for disableenable func* enities. 

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.