Here's how ILike80sRock did this for progs_dump: Allows for multiple pages. Would be interested in your feedback... just cuz.

https://github.com/progs-dump-dev/progs_dump/blob/main/qc/intermission.qc 

Hi dumptruck! It all looks good to me. It's aiming slightly higher by allowing for multiple pages of intermission text in a sequence. That explains why the code is a bit more complex than mine, and why the design requires a separate entity type to hold the pages.

That said, I'm proud of my solution as far as it goes. It wanted to be concise enough to fit into a func_ post, so I didn't add any bonus features. And I tried to create it as a "patch" that could be integrated into nearly any mod, so I aimed to make the edits:
- at as few points as possible
- at points easy to find regardless of how much the mod changes client.qc
- as small as they could be 

Thanks Preach that looks awesome, I'll try it out as soon as I can.

Respect. 

Your insights are greatly appreciated. 

Hi there, I got a small problem. I've been working on my own gameplay mod that adds onto the gameplay changes Copper adds, one of them being that the Grenade Launcher and Rocket Launcher uses their own ammo types (Grenades and Rockets).

I have the ammo working perfectly but I wanted the Orges to only drop the new Grenade ammo and *not* Rockets. So when I went to change the ammo they drop and tested it out, they don't drop a backpack at all. I tested other ammo types and got similar results... it only seems like they only like dropping backpacks if they ammo is set to Rockets. Any help I could get with this? 

Hi wuunds.

I'd take a look at the DropBackpack function - one of Quake surprisingly consistent details is that the same function is used for both monsters and players dropping all their ammo. The very first check in that function is whether the total ammo of monster/player is zero or not. You will need to modify this to include the count of grenades.

This should make the ogre drop the backpack. However, you will probably also need to make related changes throughout the backpack code. Make sure that the number of grenades is copied into the backpack when it spawns. Also make sure that when a backpack is collected it makes the second transfer from the backpack to the player.

As a general tip, try doing a global search for ammo_rockets in the codebase, and see what you find. You may discover there are more spots where you need to add a case looking at ammo_grenades to avoid a bug. 

Hi!
I am starting a new adventure in coding, the MOD will be primarly MP but with SP too.
Question is, instead of starting from scratch all the times with 1.06, and then getting crazy to add CTF or bots to it, is there some solid QC code which already contains the basics for Multiplayer, so I can mod that one directly?
I am sure there are already codes to run servers with CTF + ROcket Arena + Bots + whathave you.
Can anybody point me in the right direction? 

Hello,
I'm having trouble trying to make entities rotate around their own axes instead of the world's in QC, for example if they're pointing straight forward using only angles_y to rotate it works just fine, but what about when they're tilted (angles_x or angles_z != 0), how can it be done? I tried using v_up, sin, cos and crossproduct to no avail. If it's actually possible, how do I do it?
Any help will be appreciated. 

There is a mod called "extras_r4" from Hipnotic, that uses rotating models with usefull info.

Here is a link from Khreator.
https://github.com/khreathor/extras_r5/blob/master/progs.src

Also I put a link on quaketastic with some info.
There is also a rotatetut.zip.

https://www.quaketastic.com/files/rotate.html

Hope it's of any help. 

but they do use their own rotations... just note that bmodels normally have their origin (aka pivot) at 0,0,0 - I assume that's what you're referring to?
if so just throw in an 'origin'-textured cube brush and its midpoint will become your bmodel's new origin/pivot and then you can vectoangles or whatever however you want.

also, angles are pitch, yaw, roll, with a bug where mdls have the wrong sign for their pitch(x) values, which vectoangles (but not makevectors) replicates.
so if you are using vectoangles to compute a bmosel's angles then you must flip (*-1) the _x part of vectoangles return value.

mathematically, the eular angles rotate(yaw, y) around the up(z) axis, the rotate(pitch, x) around the right(y) axis, and then finally rotate(roll, z) around the forward(x) axis... the fact that these operations are all ordered make life a real pain.

some engines provide a two-arg form of vectoangles which takes a up vector as an extra arg beyond the normal forward vector, which allows it to compute the correct roll angles instead of just pitch+yaw.
this allows the qc to do use makevectors to provide a 3x3 matrix with forward/left/up rows, transform those vectors in weird ways and then vectoangles2 then back to usable angles (remembering to then fix up the pitch... stoopid bug). its still really messy of course, but still easier than figuring out all the ordering mess of eular angles! 

Thanks guys, made a bit of progress. Turns out I may need a rotation matrix, need to figure out how to multiply them in QC.

I forgot to be more specific: I'm experimenting with making a spaceship combat mod, and some ships have turrets mounted on them, and to make it simpler those turrets can only yaw (relative to the ship), they work fine when there's nothing to attack and they just match the ship's angles, but when they're turned elsewhere, especially when the ship is tilted, they look funny because I initially tell them to always match the ship's X and Z angles, and the Y angle is different because the turret is looking at an enemy.

I hope I explained it well... 

Something like this:
void rotatevectorsbyangle(vector angle)
{
vector oldx=v_forward, oldy='0 0 0'-v_right, oldz=v_up;
angle_x = -angle_x;
makevectors(angle);
vector angx=v_forward, angy='0 0 0'-v_right, angz=v_up;

v_forward_x = angx_x*oldx_x + angx_y*oldy_x + angx_z*oldz_x;
v_forward_y = angx_x*oldx_y + angx_y*oldy_y + angx_z*oldz_y;
v_forward_z = angx_x*oldx_z + angx_y*oldy_z + angx_z*oldz_z;
v_right_x = angy_x*oldx_x + angy_y*oldy_x + angy_z*oldz_x;
v_right_y = angy_x*oldx_y + angy_y*oldy_y + angy_z*oldz_y;
v_right_z = angy_x*oldx_z + angy_y*oldy_z + angy_z*oldz_z;
v_up_x = angz_x*oldx_x + angz_y*oldy_x + angz_z*oldz_x;
v_up_y = angz_x*oldx_y + angz_y*oldy_y + angz_z*oldz_y;
v_up_z = angz_x*oldx_z + angz_y*oldy_z + angz_z*oldz_z;

v_right = '0 0 0'-v_right;
}
IIRC the initial v_forward/v_right/v_up must be the parent's vectors (from makevectors - beware pitch sign). the 'angle' arg is the child's angles relative to its parent ent.
You can then use vectoangles2 to compute your child model's angles, but if its an older engine then it'll ignore the up vector and give you a roll angle of 0 which will be glitchy if your parent is freely pitching/rolling.

actual 6dof stuff will require you to make clientside changes so the player's view angles don't get bounded weirdly etc. 

Many thanks, works like a charm!