You don't make textures in TB actually. You can create textures in Wall or TexMex and most likely QuARK.

General info here:

http://www.celephais.net/stuff/texturefaq.htm 

It's also possible to make any texture technically fullbright by turning the brush it's applied to into a func_wall and using the necessary (and usually compiler-dependent) entity fields to make the func_wall still cast a shadow and be lit properly on the other faces, but have the one face you want ignore lighting and display at a constant brightness.

Granted, this is only really a solution for smaller details (computer screens, gauges, eldritch runes, etc) as turning giant parts of an actual wall into func_walls so you have holes going everywhere is generally not a great idea for vis time and framerates. 

I made func_breakable to the my AD map, then connected trigger to it. Breakable object has breaks by trigger, but also player can make breaks it by his weapons.

How to make a ban for the break object by the player's weapons? I can make greater health value (eg 65000), but is there any other way? 

Set the spawnflag to 2 (= nodamage) so player can't damage it. 

Thanks. 

After some though, I realized that making the texture fullbright isn't the solution to my problem. I need to make the brush (some lava) give off light.

Is there a way that this can be done? 

Haven't tried this functionality myself yet, but ericw's compilers seem to support this kind of surface lighting : https://ericwa.github.io/ericw-tools/ (check bottom of the page.)
Not sure if it'll work right with a large surface. 

Thanks mate. 

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.