Here is a collection of quick hints and tips that various people have asked me, but I cant be bothered to write a whole article about...
The code for getting a monster to follow you when you use the "Use" key is all encapsulated in the CTalkMonster class. In the Standard version of Half-Life, only the CScientist and CBarney classes inherit from here - so you'd need to inherit your new monster from this class, instead of CBaseMonster.
The code is in the CTalkMonster::FollowerUse() method. This calls other methods such as DeclineFollowing(), StartFollowing(), StopFollowing() etc.
Find a maths book, and read about Vectors. Most of the things that you'll need to do are standard physics/applied maths problems (like scaling, rotating objects, finding intersection points etc.). There are two vector classes used by half-life: Vector, and Vector2D, that you can use to store + manipulate vectors. You'll find that the Vector Dot Product is very useful too, so read about that. There are some sites on my "links" page that have vector tutorials.
The zoom is controlled by the Players "Field of view", which is accessed through the CBasePlayerItem:m_pPlayer->m_iFOV member variable.
e.g. Create a new weapon, inherit from CBasePlayerWeapon, and set m_pPlayer->m_iFOV = 0 (normal vision) or m_pPlayer->m_iFOV = 20 (zoomed in)
There's plenty of tutorials around at Wavelength etc. about this. Basically, you do the following:
HSPRITE m_hRadarSpr;
m_hRadarSpr = LoadSprite("sprites/radar1.spr"); // Load the sprite into memory
SPR_Set( m_hRadarSpr, 255, 255, 255);
// Set the sprite ready to display
SPR_DrawHoles( 0, x, y, NULL);
//
Draw the current "SPR_Set" sprite at position x,y on the screen
Of course, you really should do things like precache the sprite, use the
GetSprite / GetSpriteRect functions to read the dimensions from HUD.TXT etc. but this code
will get the basic thing on the screen.
The code for handling input devices is in the input.cpp and inputw32.cpp files in the client.dll. The joysick function is IN_ReadJoystick().
There are two things that affect latency in network code, which are:
1. Lag (this is the amount of time it takes for one packet to get from you to the server).
2. Network traffic (the amount of data sent between you and the server).
There isnt much you can do about (1), although the HL network code goes someway towards this with client side prediction..
(2) is mostly down to keeping the number and size of BEGIN_MESSAGEs sent to a minimum. This can include - only ever sending messages via timed code (e.g. once per sec), splitting any calculations between server and client side to minimise the amount of data etc.
(Also D.Flor - coder for The Opera - wrote some interesting code on bit-packing to reduce the size of messages, which I'm hoping he'll let me publish here).
Message names that are 12 chars or longer don't get registered. Working on a message to show a sprite when a flag is held, I made a:
REG_USER_MSG( "ShowBlueFlag", 2 );
It drove me crazy when it kept saying something about a "bogus message type ( 0 )". Then, I changed "ShowBlueFlag" to "ShowBlue" and it worked fine!
I believe that ClientPrint goes from the server (hl.dll), to the client (client.dll) via some callback mechanism. The client.dll then calls the engine to print the message on the screen.
On the other hand, ALERT() calls the engine directly - so it'll get printed on the screen straight away.
An entity can get information about itself by using its pev member variable e.g. pev->origin will return it's own coordinates. The pev member variable is declared on CBaseEntity.
Information about other entities in it's vicinity can be found by using the UTIL_FindEntityInSphere() and UTIL_EntitiesInBox() functions. This will return the entity, which you can then it turn do pEntity->pev to get that entities information (see my radar tutorial for an example, and look in util.cpp for more useful funcs).
