Before we begin, please be advised that this tutorial is intended for intermediate level scripters. It will not cover any basic concepts and assumes that you know the syntax of Pawn.
A message is essentially the server's way of telling a client about something that should be interpreted and acted upon accordingly by the client dll. In easier terms, it works like this:
Server sends small bit of information. Player's computer reads it, figures out what to do with it, then displays that to the player. In human terms, this could be compared to someone (the server) giving you a recipe (the message) and you (client / player's computer) preparing the meal. The components are not included in the recipe (message), and it is the chef (player's computer) that brings them together.
Messages can serve many purposes. They can do things from make a player implode to make a user think they have more ammo. Thus, the scope of this article is naturally going to be very large and will not cover everything.
The most basic part of a message is the structure. Messages are started with a "message_begin" function call, followed by "write_x" function call(s) (where x is "byte","short","coord","angle","char","string ","long" and one more that I can't remember), and concluded with a "message_end" function call. Thus, the structure is usually some variant of this:
Code:
#define FFADE_IN 0x0000 // Just here so we don't pass 0 into the function
#define FFADE_OUT 0x0001 // Fade out (not in)
#define FFADE_MODULATE 0x0002 // Modulate (don't blend)
#define FFADE_STAYOUT 0x0004 // ignores the duration, stays faded out until new ScreenFade message received
message_begin(MSG_ONE_UNRELIABLE,get_user_msgid("ScreenFade"),{0,0,0},id)
write_short(1<<12) // fade time (1 second = 4096 = 1<<12)
write_short(2<<12) // hold time (how long it lasts after fading) (1 second = 4096 = 1<<12)
write_short(FFADE_IN) // fade type (in/out)
write_byte(255) // r
write_byte(255) // g
write_byte(255) // b
write_byte(150) // alpha / intensity
message_end()
There are a few important things in this that I haven't even touched upon yet. The first one is the params of message_begin.
As found in message_const (in the include directory), the options for the first param are the following:
Code:
/* Destination types for message_begin() */
#define MSG_BROADCAST 0 // Unreliable to all
#define MSG_ONE 1 // Reliable to one (msg_entity)
#define MSG_ALL 2 // Reliable to all
#define MSG_INIT 3 // Write to the init string
#define MSG_PVS 4 // Ents in PVS of org
#define MSG_PAS 5 // Ents in PAS of org
#define MSG_PVS_R 6 // Reliable to PVS
#define MSG_PAS_R 7 // Reliable to PAS
#define MSG_ONE_UNRELIABLE 8 // Send to one client, but don't put in reliable stream, put in unreliable datagram (could be dropped)
#define MSG_SPEC 9 // Sends to all spectator proxies
The most commonly used of these is MSG_BROADCAST, MSG_ONE, MSG_ALL, MSG_ONE_UNRELIABLE, and MSG_SPEC, of which the rest I've never seen in use personally.
This parameter's function is to tell the engine which clients to send the message to. MSG_BROADCAST and MSG_ALL both send to ALL clients, whereas MSG_ONE and MSG_ONE_UNRELIABLE send to one client (but id, the final parameter of message_begin, must be specified in order to use this). Generally, it is better to use MSG_BROADCAST or MSG_ONE_UNRELIABLE. The reason for this is that these both send to the unreliable stream (as opposed to the reliable stream), which avoids the chance of a crash in the event that the message gets dropped. If a message is sent on the reliable channel but fails to make it to the client, the server generally crashes, or at the very best the client gets dropped.
The next parameter is the type of message. There are many options for this. The two generally most used types of messages are events (like the ScreenFade one called, generally with the usage of get_user_msgid), or SVC_TEMPENTITY. Event related messages are used to artificially tell the client that an event has happened, such as the round ending, the player's health changing, weapons changing, etc. SVC_TEMPENTITY (or just temp ents for short) is used to create a temporary entity, usually to make a nice visual effect or so a group of entities don't have to be manually removed.
Note that the get_user_msgid native can be cached in another forward (such as plugin_init) and then called using a variable, like this:
Code:
new g_MsgScreenFade
public plugin_init()
{
//...
g_MsgScreenFade = get_user_msgid("ScreenFade")
//...
}
// ...
{
// ...
message_begin(MSG_ONE_UNRELIABLE,g_MsgScreenFade,...
The next parameter is the origin. Note that this is NOT where the message will appear if it has any visual effects, but is used for scripting so anything catching/reading it knows where the message originated from on the map. This parameter is generally unimportant.
The next parameter, as already talked about, is the id of the player to send this message to. This is only needed when not using MSG_BROADCAST, MSG_ALL or MSG_SPEC, since these messages all target either everyone or a predefined set of people.
Onto the next part - the writing of data. The next function call will always be a write_byte if you're using SVC_TEMPENTITY. This function will tell the engine which type of temp ent you want to make. The list is too long to post, but it can be found in message_const.inc (all of the TE_ defines).
As you can see, it's quite lengthy. For the sake of this tutorial, your and my own sanity, I'm going to pick the first one to use as an example, TE_BEAMPOINTS.
Here's how I'd do it:
Code:
new g_Beam
public plugin_precache()
g_Beam = precache_model("sprites/lightning1.spr")
//...
message_begin(MSG_BROADCAST,SVC_TEMPENTITY)
write_byte(TE_BEAMPOINTS)
// this is where the beginning of the beam is
write_coord(0) // x
write_coord(0) // y
write_coord(0) // z
// this is where the end of the beam is
write_coord(4096) // x
write_coord(4096) // y
write_coord(4096) // z
// this is the sprite index, as we got in plugin_precache)
write_short(g_Beam)
// this is the starting frame, it's generally best to leave this at 1
write_byte(1)
// frame rate in 0.1s
write_byte(10)
// how long it lasts in 0.1 seconds (10 for 1 second)
write_byte(100)
// line width in 0.1s
write_byte(10)
// amplitude (how much it goes off the line)
write_byte(10)
// r, g, b
write_byte(255)
write_byte(255)
write_byte(255)
// brightness
write_byte(255)
// scroll speed
write_byte(100)
message_end()
This will create a beam that starts at the first set of coordinates (first 3) and ending at the second set. This will probably create a very bright, thick and eratic beam (I haven't tested it). The important thing to notice is how coordinates are layed out. Instead of using a vector like almost everything else, each axis (x,y,z) is pushed by a seperate native. It is also important to note that they are not floats, and if the origin was originally a float, you must run floatround on it.
There's also another set of message natives that begin with "e" (i.e. emessage_begin). What these essentially do is instead of bypassing metamod entirely, they are actually passed through it. This means that other plugins can catch the messages you put through. If you do not want this to happen, simply use the normal message natives.
There's really not enough space here to go on further, so I'm going to leave a few helpful links:
Damaged Soul's Message Logging plugin:
http://forums.alliedmods.net/showthread.php?t=7118
Funcwiki entry on messages:
http://www.amxmodx.org/funcwiki.php?go=inc&id=47
Message constants:
http://www.amxmodx.org/funcwiki.php?...id=1#const_msg
As always, if you have any questions, notice something wrong with anything I said here, or have any comments, feel free to post.
Linear Mode
