Forum posts

-low / -high only modifies the priority of the process. This probably won't help you much as the scheduler will still give the compile tools all the processor time they ask for, if there aren't any other CPU intensive applications running at the same time. You could try limiting the number of threads by using the -threads # parameter. I.e. -threads 1 to limit it to one thread only. Use a value lower than a number of logical cores of your CPU.

There are many other ways to limit the CPU usage - either globally or on a per-process basis. On Windows (I assume that's what you are running) you can change the "maximum CPU frequency" or "maximum CPU state" in Control Panel -> Power Options (this is a global setting).

No matter what method you use, the compilation process will of course take longer than it did before.

80 °C certainly isn't an ideal temperature to have the CPU running at, and depending on the model of your CPU it may or may not be within the allowed range. Either way you should fix or replace your cooling solution if possible (unless this is caused by an abnormally high ambient temperatures or something).

The formatting there is a bit broken, but the described method will work. All you have to do is restore the cl_rollangle and cl_rollspeed CVARs (hud.cpp) and then tweak the V_CalcRoll() in V_CalcViewRoll() (view.cpp). Use the DMC source code as a reference.

I don't think VGUI1 has a ready-to-use combo box. But it should be possible to build one using the existing components (list panel etc.). Header files for all the UI components are in "utils\vgui\include".

You want to multiply the matrix before you start concatenating the transformations, so put it before the last last for loop in that function.

The scale value is networked and you can get it from the m_pCurrentEntity->curstate structure. Something like this should do the trick:

for ( int i = 0; i < 3; i++ )
	for ( int j = 0; j < 3; j++ )
		( * m_protationmatrix )[ i ][ j ] *= m_pCurrentEntity->curstate.scale;

The Garg effect (kRenderFxExplode) is hardcoded in the engine and in CStudioModelRenderer::StudioFxTransform().

The Studio model renderer that comes with the vanilla HL doesn't account for the networked scale variable (pev->scale). If I recall correctly all you have to do is multiply the bone rotation matrix in CStudioModelRenderer::StudioSetupBones() by the scale value. That's probably the easiest way to get this working. It will scale the model, but if scaled NPCs are what you are after, you will have to make more changes.

Depending on the situation, custom animation or bone controller might be a better option as Bruce suggested.

Your sprite doesn't show up quite correctly in some tools but it works perfectly fine in-game for me. It's rather difficult to see the interlacing effect though, but that's caused by a bug in the engine not by your sprite (see this thread). Try again in software mode, it should be easier to see the difference there... If it still doesn't work the file must be in a wrong folder or something.

All you need is a sprite with 4 frames (one frame per damage direction - top, right, bottom and left). Then put it into the "sprites" folder and name it "640_pain.spr". You can also create a low-res version named "320_pain.spr" that will be used for screen resolutions smaller than 640x480 if you feel it's necessary, but I wouldn't bother, the Steam version doesn't even support such low resolutions properly. You don't have to touch the hud.txt file as there is no definition for the pain indicators in there, the game loads the sprite file directly.