1. Download qc source.
2. Add the following to misc.qc:

void ambient_generic () = {
if (self.noise1 == "") { remove (self); return; } // check that we have a sound
precache_sound (self.noise1); // load sound in memory
ambientsound (self.origin, self.noise1, 0.5, ATTN_STATIC); // start ambient loop with volume 0.5
};

3. Compile using fteqccgui.exe
4. Place the resulting progs.dat in your mod directory (e.g. C:/QUAKE/mymod/progs.dat)
5. Run your map with -game mymod in the commandline. 

Thanks for the info - I think I can attempt to put something like this together! 

I followed your example and have a progs.dat, but how do I add a sound entity into a map? which entity and keys should I use

And where should I place any new sounds inside my mod directory? 

1. Add any point entity.
2. Rename it to ambient_generic
3. Add key|value of noise1|"folder/sound.wav" without the quotes and of course going to the directory under C:/QUAKE/mymod/sounds/folder/sound.wav or wherever your sound is. Don't include the "sounds" folder.
4. Compile and you will have your ambient. 

In world.qc, the different lightstyles are defined using 'a' thru 'z' for brightness in a string. I have questions about limits and compiler:

1. What is the character limit for the string?

2. Is there a limit on different lightstyles?

3. Does the compiler create a different saved lightmap for each letter a,b,c, etc?

4. Are lightstyles hardcoded into the compiler?

5. Does anyone know of a mod that makes their own lightsyles, e.g. Spastic Lightning or a Flash and Fade, etc.? 

1. Max string length is MAX_STYLESTRING = 64 which looks like it includes a null terminator, so 63 characters
2. MAX_LIGHTSTYLES = 64
3. No, the compiler bakes (and writes to the bsp) lighting at 100% brightness, which is level "m", I think. Whatever level QC requests is generated by scaling the 100% brightness lightmap to the requested brightness.

Each face can have up to 4 different lightmaps baked for it (bsp format limit), and each lightmap is linked to a lightstyle number.

more detail: the engine looks up the current brightness levels (a-z) of the (up to) 4 lightmaps that were baked for that face. Each of the baked lightmaps is scaled to the right brightness, they're added together, and the result is used as the lightmap for that frame.

4. No. There's not much hardcoded in the light compiler except it knows if a light has "targetname" set, it allocates one of the 64 style numbers for that targetname. It knows if a light has "style" set to use that as the style number for when that light hits faces.

5. Hmm.. I'm not sure. "The Middle Evil" had a lightning effect. ne_ruins might do some tricks with lightstyles, I forget?

The system could be pushed further with a bit of QC, e.g. switchable lights could be extended so they can be animated while on. Could have fade in/out transitions. 

1: 63 chars (more depending on engine). chars outside the a-z range still have meaning but may result in numerical overflows (at least in surface caches), so avoid capitals etc.
there is an extension that allows styles of the form of "=0.5" to set a specific value with greater precision (1 is about equivalent to m - quake has overbrights), which allows for smoother style changes.
fte has an additional extension that allows you to pass an extra arg for rgb values.
the style strings are dynamic state, the qc is free to change them whenever it wants. however its the engine's choice which char it uses from the string at any particular time so if you want fancy qc-based animations its best to stick to a single char per lightstyle string (or the = thing, if your target engine supports it).

2: the bsp format (including bsp2) is limited to 255 different light styles (0-254, 255=no more). Many engines still limit to 0-63 however (higher requires saved game changes).

3: the map compiler is unaware of the style strings themselves. triggered lights will automatically be assigned a (shared-by-matching-targetname) style index.

4: styles 32+ will typically be used for triggered lights. lower indexes can freely be (re)defined by the QC mod, but existing mods will expect the same style strings that they were made for, so beware of that if you try changing the existing styles.

5: my recommendation would be to create some new trigger_lightstyle entity or something that allows you to (re)define the styles from the map itself, because awesomesauce. Bonus points if it can be triggered to enable/disable/recolour/etc all lights with the same style. Note that this should probably not be baked into the individual lights. 

If you want to be able to programmatically change the lighting strings you can use the basic idea from the following tutorials (a long and involved series of posts)

https://tomeofpreach.wordpress.com/2013/03/28/text-manipulation-in-quake-i-the-basics/

The crucial change you need to make is to use

float SVC_LIGHTSTYLE = 12;

as the header byte instead of SVC_CENTERPRINT when you send the characters. This may be overkill but it's nice to know there's a way to do it if you need. If you just want a way to translate a float into a light level it's a fairly compact way to do it without some kind of 26 line long if statement.

This trick will be employed in an upcoming project I'm working on... 

a mod that makes their own lightsyles

I remember JPL's "FortDriant" used a recompiled light index for making a long stairway of repulsing light on a long range of 32.

Don't know if its included in the map. 

 

Rubicon 2 has custom light styles 

i've done this
void () execute_changelevel =
{
local entity tmp;
local float bcount;

intermission_running = 1;
intermission_exittime = (time + 5);
lightstyle(0, "f");// R00k: -added- dim light on intermission

oddly I assume the world uses lightstyle 0 looking in the misc.qc for the lights i cant find any reference for the actual numerical value, yet in world.qc, lightstyle (0,"m"); etc.. 

wait ya, .style entity field is a lightstyle thus the world entity inits with self.style = 0; 

It's basically that, except it's the style field on the light entities which matters, not the style of the world entity. When you don't set a style, the field defaults to 0 - even in the light compiler. 

okay so basically all default lights use lighstyle 0 which is why altering
that to a lower value makes it look like nighttime? i set
that for intermissions and on any map it dims the screen
so the scoreboard shows up better ;) pr_lightstyle calls the svc_ to broadcast to all connected clients. 

so I wanted to implement cell shading in my game, and I'm using the makaqu engine because it has cell shading support but more importantly it can be compiled for the dreamcast (I'm making a game for it). When I asked the developer how to implement the cell shading he told me to edit defs.qc and add the line:

float EF_CELSHADING = 16384;

and add this to the model script:
self.effects = self.effects | EF_CELSHADING;

problem is, when I compile it using fteqccgui and place it in my mod pak it still doesn't have cell shaded graphics. I want to add the effect to the player model and the dog, so how would I do this? 

and add this to the model script:
self.effects = self.effects | EF_CELSHADING;

Can you give us a bit more of the context surrounding this line of code, like which function you've added it to? It wants to be in the function which is setting the model of the entity you want cell-shading on. 

I’m looking for QuakeC code for creating cutscenes for a commercial project. I plan to ask whoever originally wrote the code for permission to use it for this, and it’s for a Dreamcast and PC game using the makaqu engine. If anyone can point me in the direction of code for this, I’d like to homogenenise it with my current code (I’m using a little bit of modified code since I can really only read C and C++) to play the beginning of a level. Is there anyone who can suggest some good code for this that’s relatively easy to use? 

Also, I’m putting commands in the world.c code for specific levels, but for some reason it’s not using them. I’m using cvar_set and localcmd. I need these for the game to work. 

NehQC:
http://www.fileplanet.com/dl.aspx?/nehahra/neh_devkit.zip

Are you putting those localcmd's inside worldspawn or startframe? If you use main() it might not work. 

Thanks for your answer! Another question, when I start a demo when the level starts, then the demo exits the level, the game crashes. However, it doesn’t crash the menu screen if I put in startdemo instead of startdemos it goes into the next level which I want this one to do. Is it because I have different cvars coded into both levels? I’m currently at work so I can’t test it yet, but just getting a second opinion. 

I’m using localcmd to start the demo in the start level, which the demo is supposed to spawn the player in e1m1 after the demo plays. 

the typical way to chain demos to maps is to insert an svc_stufftext into the end of the demo to get the client to issue a 'map' console command at the end.
you can't use the changelevel command etc, so all weapons etc will be forgotten. you can work around that with cvars (again eg nehahra) but this makes a mess when it comes to saved games (and potentially restarting the map). 

So just straight up type in svc_stufftext map e1m1 into the console when I want the demo to end? Or do I have to code a timer?