The damage function uses ceil to round up the damage so most of the time any values less than 1 get rounded to one. Since it is nigh impossoble to get 0, 0, 0 (using latest FTEQCC so I expect to have all 3 random()s), and 0, 0, >0 is more likely, I would expect the damage range for an ai_melee call to be 1-9 instead of 0-9. 

(talking out my buttcheeks)
What if one just loaded up the knight's animation frames then determined the length of the longest animation swing, like where the night's sword was FULLY extended. Then that that distance and do a trace from the player to the night. If the distance is greater than the distance of the sword then damage = 0. If the distance is within range then full damage. If the animation frame is between fully extended and the wind-up then take a % of damage based on which frame the knight's attack was in. Like if there are 4 frames between backswing to full extension, then determine the distance, (and if in range), base the damage on closeness and attack frame. this would be consistent and still random by player movement.
Does this make sense? just gibberjabbin over here... :) 

*edit: "Then that that distance " = Then take that distance 

What does crandom() do? Do I get cranberry sauce numbers from it? 

Found it:
return 2*(random() - 0.5);

Now I want cranberries. 

As promised about 8 weeks ago, I've finally got round to reposting my teleporting monster flag code which was lost when Inside3d went down.

https://tomeofpreach.wordpress.com/2017/10/08/teleporting-monsters-flag/

I couldn't resist a spot of refining and fixing it. There's a single line fix here which took several days of bug hunting to work out when it affected Quoth, so benefit of accumulated wisdom I guess. The code's also a lot more self-contained - apart from the three entry points which call the new function, there's only one (optional) change to existing code which needs to be made. That should make it very easy to customise and extend... 

When and if I make time to get into QuakeC this sound dandy. 

Hope this is the right place to ask.

GLHexen 2 has an annoying long standing issue when upscaling the HUD with -conwidth, some HUD elements are tiled and the seams become visible, like so:

https://i.imgur.com/aff3Auj.png

Any idea how can this be fixed? I mostly want to submit a patch for the Hammer of Thyrion source port, I've contacted the author and he's definitely interested in fixing this, but he's no idea what's causing this. We've tried changing GL_CLAMP to GL_CLAMP_TO_EDGE, and it helps with some images, but the others still have those thin lines. I've noticed that FTE seems to have this fixed, how was this done? 

clamp-to-edge is good, but it doesn't affect anything when you're atlasing the texture. In such cases, the atlas should just have the border pixels doubled such that it gets the same value instead of averaging in the texel from the neighbouring image.
beware of mipmaps - eg the smallest mipmap is a 1*1 image that averages the ENTIRE texture instead of just the interesting part. you can use a few mip layers by aligning and capping the mip levels (on desktop gl anyway). or just prescale and avoid mips entirely (with 1 pixel borders).
alternatively you can pinch texture coords inwards by half a texel instead of padding with borders, but beware that the half-texel depends upon the mip level that will be used, so that's still messy.
(sidenote: gles supports npot textures only with clamp-to-edge and no mipmapping)

the other thing to do, especially for the hud images themselves, is to use premultiplied alpha (aka: rgb*=a [or equivalent] before uploading, then draw with blendfunc one,one_minus_src_alpha, you'll need glColor4f(rgb*a,a) for variable transparency). This avoids all discolouration on the edges between opaque/transparent texels, how this works should be well documented elsewhere but basically premultiplied alpha is awesome - USE IT!

also, if you're in contact with the author, can you get him to respond to my bsp2 patch (ideally by merging part of it)?
he doesn't really need to bump all the limits that my patch bumped, so long as the clipnodes are no longer so horribly limited... 

If I was to make a mod to create ambient sound entities that could play custom sounds from a point, how would I go about this?

Also what's the best program to use for this kind of thing?

Can custom ambient sounds be done with Quoth? if so, how? 

Here's a link to a version of the Quoth .fgd(JACK/Worldcraft editing game file) that lists custom ambient sounds.

https://gist.github.com/ItEndsWithTens/200c881f2522af324767be1433c4391e

So it's a simple as placing an entity and then setting the keys for your custom sound, location of course being the most important one.

As far as adding your own custom sounds to a mod, simply look at a mod that has the QC source available(Not Quoth). Though Preach my have a tutorial covering this on his site. Arcane Dimensions is a good current example, so if you play that you already have the QC files to examine.

Download and use FTEQCC GUI, then you can search for "custom sound" to see how it is implemented.

HTH's,
-damage_ 

thanks damage_inc, I'll have a look into this 

If the goal is simply to have custom sounds play on a map, why not just make the map for Quoth or AD. Load the fgd into your editor and you are set, the custom sound entities are documented in the readme files for these mods. This will save you from having to create a new progs just for this one thing. Also it will allow you to use all of the other entities from Quoth or AD. 

You could also use the qc or progs from "extras4" - it has some nice features and custom sounds as well.

In mid 2002 nostalgia and boredom drove me to write some interesting QuakeC hacks. The result is this "Extras" mod, which aims to provide extra stuff for Quake mappers. It features honest to goodness func_water, and func_ladder entities, as well as an insanely customizable emitter/effector based particle system, and advanced trains and switches. So if you ever wanted to dynamically flood a level, or attach water volumes and/or switches to trains, this is the mod for you! Example maps and some snazzy new animated sprites and sound effects are also included.

http://quake.chaoticbox.com/downloads/extras_r4.zip 

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.