 |
Crossfire Server, Trunk
1.75.0
|
Go to the documentation of this file.
36 void look_at(
object *op,
int dx,
int dy);
119 void play_sound_map(int8_t sound_type,
object *emitter,
int dir, const
char *action);
New face structure - this enforces the notion that data is face by face only - you can not change the...
void send_image_info(socket_struct *ns)
Sends the number of images, checksum of the face file, and the image_info file information.
void SockList_AddInt(SockList *sl, uint32_t data)
Adds a 32 bit value.
void send_image_sums(socket_struct *ns, char *params)
Sends requested face information.
void reply_cmd(char *buf, int len, player *pl)
This is a reply to a previous query.
void print_ext_msg(socket_struct *ns, int color, uint8_t type, uint8_t subtype, const char *message)
Draws an extended message on the client.
void SockList_AddInt64(SockList *sl, uint64_t data)
Adds a 64 bit value.
void init_connection(socket_struct *ns, const char *from_ip)
Initializes a connection.
void request_info_cmd(char *buf, int len, socket_struct *ns)
request_info_cmd is sort of a meta command.
void esrv_map_scroll(socket_struct *ns, int dx, int dy)
Socket structure, represents a client-server connection.
void init_server(void)
This sets up the listening socket.
void esrv_new_player(player *pl, uint32_t weight)
Tells the client that here is a player it should start using.
void esrv_send_inventory(object *pl, object *op)
Sends inventory of a container.
static event_registration c
void SockList_AddString(SockList *sl, const char *data)
Adds a string without length.
#define PRINTF_ARGS(x, y)
Used for printf-like functions, mostly LOG and draw_ext_info_format.
void do_server(void)
This checks the sockets for input and exceptions, does the right thing.
void esrv_send_pickup(player *pl)
Sends the "pickup" state to pl if client wants it requested.
void mark_item_cmd(uint8_t *data, int len, player *pl)
Client wants to mark some object.
void draw_ext_info_format(int flags, int pri, const object *pl, uint8_t type, uint8_t subtype, const char *format,...) PRINTF_ARGS(6
void play_sound_player_only(player *pl, int8_t sound_type, object *emitter, int dir, const char *action)
Plays a sound for specified player only.
void send_new_char_info(socket_struct *ns)
Sends information related to creating a new character to the client.
void free_all_newserver(void)
Free's all the memory that ericserver allocates.
void play_sound_map(int8_t sound_type, object *emitter, int dir, const char *action)
Plays a sound on a map.
static const flag_definition flags[]
Flag mapping.
void send_map_info(socket_struct *ns)
Send information on available start maps.
void esrv_update_spells(player *pl)
This looks for any spells the player may have that have changed their stats.
void send_exp_table(socket_struct *ns)
This sends the experience table the sever is using.
void send_account_players(socket_struct *ns)
Upon successful login/account creation, we send a list of characters associated with the account to t...
void esrv_add_spells(player *pl, object *spell)
This tells the client to add the spell *spell, if spell is NULL, then add all spells in the player's ...
void SockList_AddLen16Data(SockList *sl, const void *data, size_t len)
Adds a data block prepended with an 16 bit length field.
void toggle_extended_infos_cmd(char *buf, int len, socket_struct *ns)
void SockList_Reset(SockList *sl)
Resets the length of the stored data for writing.
void esrv_send_item(object *pl, object *op)
Sends item's info to player.
size_t SockList_Avail(const SockList *sl)
Returns the available bytes in a SockList instance.
short GetShort_String(const unsigned char *data)
void account_password(char *buf, int len, socket_struct *ns)
Handles the account password change.
void send_skill_info(socket_struct *ns, char *params)
This sends the skill number to name mapping.
void account_login_cmd(char *buf, int len, socket_struct *ns)
Handles the account login.
void look_at_cmd(char *buf, int len, player *pl)
Client wants to look at some object.
void set_title(const object *pl, char *buf, size_t len)
Sets player title.
void esrv_remove_spell(player *pl, object *spell)
void final_free_player(player *pl)
Sends the 'goodbye' command to the player, and closes connection.
void esrv_send_face(socket_struct *ns, const Face *face, int nocache)
Sends a face to a client if they are in pixmap mode, nothing gets sent in bitmap mode.
void esrv_update_stats(player *pl)
Sends a statistics update.
void ext_info_map_except2(int color, const mapstruct *map, const object *op1, const object *op2, int type, int subtype, const char *str1)
Writes to everyone on the map except op1 and op2.
bool handle_client(socket_struct *ns, player *pl)
Handle commands from a client.
void SockList_AddShort(SockList *sl, uint16_t data)
Adds a 16 bit value.
void void ext_info_map(int color, const mapstruct *map, uint8_t type, uint8_t subtype, const char *str1)
Writes to everyone on the specified map.
void SockList_AddChar(SockList *sl, unsigned char c)
Adds an 8 bit value.
int metaserver2_init(void)
This initializes the metaserver2 logic - it reads the metaserver2 file, storing the values away.
TIPS on SURVIVING Crossfire is populated with a wealth of different monsters These monsters can have varying immunities and attack types In some of them can be quite a bit smarter than others It will be important for new players to learn the abilities of different monsters and learn just how much it will take to kill them This section discusses how monsters can interact with players Most monsters in the game are out to mindlessly kill and destroy the players These monsters will help boost a player s after he kills them When fighting a large amount of monsters in a single attempt to find a narrower hallway so that you are not being attacked from all sides Charging into a room full of Beholders for instance would not be open the door and fight them one at a time For there are several maps designed for them Find these areas and clear them out All throughout these a player can find signs and books which they can read by stepping onto them and hitting A to apply the book sign These messages will help the player to learn the system One more always keep an eye on your food If your food drops to your character will soon so BE CAREFUL ! NPCs Non Player Character are special monsters which have intelligence Players may be able to interact with these monsters to help solve puzzles and find items of interest To speak with a monster you suspect to be a simply move to an adjacent square to them and push the double ie Enter your message
void send_background_music(player *pl, const char *music)
Sends background music to client.
void draw_magic_map(object *pl)
Creates and sends magic map to player.
void send_tick(player *pl)
with a maximum of six This is not so if you are wearing plate you receive no benefit Armour is additive with all the supplementry forms of which means that it lasts until the next semi permanent spell effect is cast upon the character spell
void set_sound_cmd(char *buf, int len, socket_struct *ns)
void ask_smooth_cmd(char *buf, int len, socket_struct *ns)
Tells client the picture it has to use to smooth a picture number given as argument.
void account_add_player_cmd(char *buf, int len, socket_struct *ns)
Handle accountaddplayer from server (add a character to this account).
uint32_t tag_t
Object tag, unique during the whole game.
void create_player_cmd(char *buf, int len, socket_struct *ns)
We have received a createplayer command.
void new_player_cmd(uint8_t *buf, int len, player *pl)
This handles the commands issued by the player (ie, north, fire, cast, etc.).
void account_play_cmd(char *buf, int len, socket_struct *ns)
We have received an accountplay command.
void SockList_Init(SockList *sl)
Initializes the SockList instance.
TIPS on SURVIVING Crossfire is populated with a wealth of different monsters These monsters can have varying immunities and attack types In some of them can be quite a bit smarter than others It will be important for new players to learn the abilities of different monsters and learn just how much it will take to kill them This section discusses how monsters can interact with players Most monsters in the game are out to mindlessly kill and destroy the players These monsters will help boost a player s after he kills them When fighting a large amount of monsters in a single attempt to find a narrower hallway so that you are not being attacked from all sides Charging into a room full of Beholders for instance would not be open the door and fight them one at a time For there are several maps designed for them Find these areas and clear them out All throughout these a player can find signs and books which they can read by stepping onto them and hitting A to apply the book sign These messages will help the player to learn the system One more always keep an eye on your food If your food drops to your character will soon so BE CAREFUL ! NPCs Non Player Character are special monsters which have intelligence Players may be able to interact with these monsters to help solve puzzles and find items of interest To speak with a monster you suspect to be a simply move to an adjacent square to them and push the double ie Enter your and press< Return > You can also use say if you feel like typing a little extra Other NPCs may not speak to but display intelligence with their movement Some monsters can be and may attack the nearest of your enemies Others can be in that they follow you around and help you in your quest to kill enemies and find treasure SPECIAL ITEMS There are many special items which can be found in of these the most important may be the signs all a player must do is apply the handle In the case of the player must move items over the button to hold it down Some of the larger buttons may need very large items to be moved onto before they can be activated Gates and locked but be for you could fall down into a pit full of ghosts or dragons and not be able to get back out Break away sometimes it may be worth a player s time to test the walls of a map for secret doors Fire such as missile weapons and spells you will notice them going up in smoke ! So be careful not to destroy valuable items Spellbooks sometimes a player can learn the other times they cannot There are many different types of books and scrolls out there Improve item have lower weight
void move_cmd(char *buf, int len, player *pl)
Moves an object (typically, container to inventory).
void send_class_info(socket_struct *ns, char *params)
Send information on the specified class.
void look_at(object *op, int dx, int dy)
Prints items on the specified square.
void esrv_del_item(player *pl, object *ob)
Tells the client to delete an item.
void version_cmd(char *buf, int len, socket_struct *ns)
Client tells its version.
void send_plugin_custom_message(object *pl, char *buf)
GROS: The following one is used to allow a plugin to send a generic cmd to a player.
void SockList_Term(SockList *sl)
Frees all resources allocated by a SockList instance.
void metaserver2_exit()
Stop metaserver updates.
A buffer that will be expanded as content is added to it.
void set_face_mode_cmd(char *buf, int len, socket_struct *ns)
void send_race_list(socket_struct *ns)
Send the list of player races to the client.
void esrv_send_animation(socket_struct *ns, const Animations *anim)
Need to send an animation sequence to the client.
void free_newsocket(socket_struct *ns)
Frees a socket.
void ext_info_map_except(int color, const mapstruct *map, const object *op, uint8_t type, uint8_t subtype, const char *str1)
Writes to everyone on the map except *op.
void inscribe_scroll_cmd(char *buf, int len, player *pl)
void SockList_AddData(SockList *sl, const void *data, size_t len)
Adds a data block.
void esrv_move_object(object *pl, tag_t to, tag_t tag, long nrof)
Move an object to a new location.
void send_class_list(socket_struct *ns)
Sends the list of classes to the client.
void toggle_extended_text_cmd(char *buf, int len, socket_struct *ns)
void metaserver_update(void)
Updates our info in the metaserver Note that this is used for both metaserver1 and metaserver2 - for ...
void write_cs_stats(void)
This represents one animation.
void update_players(void)
Send updates to players.
void SockList_AddLen8Data(SockList *sl, const void *data, size_t len)
Adds a data block prepended with an 8 bit length field.
void esrv_update_item(int flags, object *pl, object *op)
Updates object *op for player *pl.
void esrv_draw_look(object *pl)
Send the look window.
void reset_stats(struct CS_Stats *stats)
void send_file(socket_struct *ns, const char *file)
Sends the desired file to the client.
void examine_cmd(char *buf, int len, player *pl)
Client wants to examine some object.
void magic_mapping_mark(object *pl, char *map_mark, int strength)
Creates magic map for player.
void SockList_ResetRead(SockList *sl)
Resets the length of the stored data for reading.
void send_skill_extra(socket_struct *ns, char *params)
Send extra skill information.
void send_spell_paths(socket_struct *ns)
This sends the spell path to name mapping.
void account_new_cmd(char *buf, int len, socket_struct *ns)
Handles the account creation This function shares a fair amount of the same logic as account_login_cm...
void map_newmap_cmd(socket_struct *ns)
Sound related function.
Player Stats effect how well a character can survie and interact inside the crossfire world This section discusses the various stats
====Textual A command containing textual data has data fields separated by one ASCII space character. word::A sequence of ASCII characters that does not contain the space or nul character. This is to distinguish it from the _string_, which may contain space characters. Not to be confused with a machine word. int::A _word_ containing the textual representation of an integer. Not to be confused with any of the binary integers in the following section. Otherwise known as the "string value of integer data". Must be parsed, e.g. using `atoi()` to get the actual integer value. string::A sequence of ASCII characters. This must only appear at the end of a command, since spaces are used to separate fields of a textual message.=====Binary All multi-byte integers are transmitted in network byte order(MSB first). int8::1-byte(8-bit) integer int16::2-byte(16-bit) integer int32::4-byte(32-bit) integer lstring::A length-prefixed string, which consists of an `int8` followed by that many bytes of the actual string. This is used to transmit a string(that may contain spaces) in the middle of binary data. l2string::Like _lstring_, but is prefixed with an `int16` to support longer strings Implementation Notes ~~~~~~~~~~~~~~~~~~~~ - Typical implementations read two bytes to determine the length of the subsequent read for the actual message, then read and parse the data from each message according to the commands described below. To send a message, the sender builds the message in a buffer, counts the length of the message, sends the length, and finally sends the actual message. TIP:Incorrectly transmitting or receiving the `length` field can lead to apparent "no response" issues as the client or server blocks to read the entire length of the message. - Since the protocol is highly interactive, it may be useful to set `TCP_NODELAY` on both the client and server. - If you are using a language with a buffered output stream, remember to flush the stream after a complete message. - If the connection is lost(which will also happen if the output buffer overflowing), the player is saved and the server cleans up. This does open up some abuses, but there is no perfect solution here. - The server only reads data from the socket if the player has an action. This isn 't really good, since many of the commands below might not be actual commands for the player. The alternative is to look at the data, and if it is a player command and there isn 't time, store it away to be processed later. But this increases complexity, in that the server must start buffering the commands. Fortunately, for now, there are few such client commands. Commands -------- In the documentation below, `S->C` represents a message to the client from the server, and `C->S` represents a message to the server from the client. Commands are documented in a brief format like:C->S:version< csval >[scval[vinfo]] Fields are enclosed like `< this >`. Optional fields are denoted like `[this]`. Spaces that appear in the command are literal, i.e. the<< _version > > command above uses spaces to separate its fields, but the command below does not:C->S:accountlogin< name >< password > As described in<< _messages > >, if a command contains data, then the command is separated from the data by a literal space. Many of the commands below refer to 'object tags'. Whenever the server creates an object, it creates a unique tag for that object(starting at 1 when the server is first run, and ever increasing.) Tags are unique, but are not consistent between runs. Thus, the client can not store tags when it exits and hope to re-use them when it joins the server at a later time - tags are only valid for the current connection. The protocol commands are broken into various sections which based somewhat on what the commands are for(ie, item related commands, map commands, image commands, etc.) In this way, all the commands related to similar functionality is in the same place. Initialization ~~~~~~~~~~~~~~ version ^^^^^^^ C->S:version< csval >[scval[vinfo]] S->C:version< csval >[scval[vinfo]] Used by the client and server to exchange which version of the Crossfire protocol they understand. Neither send this in response to the other - they should both send this shortly after a connection is established. csval::int, version level of C->S communications scval::int, version level of S->C communications vinfo::string, that is purely for informative that general client/server info(ie, javaclient, x11client, winclient, sinix server, etc). It is purely of interest of server admins who can see what type of clients people are using.=====Version ID If a new command is added to the protocol in the C->S direction, then the version number in csval will get increased. Likewise, the same is true for the scval. The version are currently integers, in the form ABCD. A=1, and will likely for quite a while. This will only really change if needed from rollover of B. B represents major protocol changes - if B mismatches, the clients will be totally unusable. Such an example would be change of map or item sending commands(either new commands or new format.) C represents more minor but still significant changes - clients might still work together, but some features that used to work may now fail due to the mismatch. An example may be a change in the meaning of some field in some command - providing the field is the same size, it still should be decoded properly, but the meaning won 't be processed properly. D represents very minor changes or new commands. Things should work no worse if D does not match, however if they do match, some new features might be included. An example of the would be the C->S mark command to mark items. Server not understanding this just means that the server can not process it, and will ignore it.=====Handling As far as the client is concerned, its _scval_ must be at least equal to the server, and its _csval_ should not be newer than the server. The server does not care about the version command it receives right now - all it currently does is log mismatches. In theory, the server should keep track of what the client has, and adjust the commands it sends respectively in the S->C direction. The server is resilant enough that it won 't crash with a version mismatch(however, client may end up sending commands that the server just ignores). It is really up to the client to enforce versioning and quit if the versions don 't match. NOTE:Since all packets have the length as the first 2 bytes, all that either the client or server needs to be able to do is look at the first string and see if it understands it. If not, it knows how many bytes it can skip. As such, exact version matches should not be necessary for proper operation - however, both the client and server needs to be coded to handle such cases.=====History _scval_ and _vinfo_ were added in version 1020. Before then, there was only one version sent in the version command. NOTE:For the most part, this has been obsoleted by the setup command which always return status and whether it understood the command or not. However there are still some cases where using this versioning is useful - an example it the addition of the requestinfo/replyinfo commands - the client wants to wait for acknowledge of all the replyinfo commands it has issued before sending the addme command. However, if the server doesn 't understand these options, the client will never get a response. With the versioning, the client can look at the version and know if it should wait for a response or if the server will never send back. setup ^^^^^ C->S, S->C:setup< option1 >< value1 >< option2 >< value2 > ... Sent by the client to request protocol option changes. This can be at any point during the life of a connection, but usually sent at least once right after the<< _version > > command. The server responds with a message in the same format confirming what configuration options were set. The server only sends a setup command in response to one from the client. The sc_version should be updated in the server if commands have been obsoleted such that old clients may not be able to play. option::word, name of configuration option value::word, value of configuration option. May need further parsing according to the setup options below=====Setup Options There are really 2 set of setup commands here:. Those that control preferences of the client(how big is the map, what faceset to use, etc). . Those that describe capabilities of the client(client supports this protocol command or that) .Setup Options[options="autowidth,header"]|===========================|Command|Description|beat|Ask the server to enable heartbeat support. When heartbeat is enabled, the client must send the server a command every three seconds. If no commands need to be sent, use the `beat` no-op command. Clients that do not contact the server within the interval are assumed to have a temporary connection failure.|bot(0/1 value)|If set to 1, the client will not be considered a player when updating information to the metaserver. This is to avoid having a server with many bots appear more crowded than others.|darkness(0/1 value)|If set to 1(default), the server will send darkness information in the map protocol commands. If 0, the server will not include darkness, thus saving a minor amount of bandwidth. Since the client is free to ignore the darkness information, this does not allow the client to cheat. In the case of the old 'map' protocol command, turning darkness off will result in the masking faces not getting sent to the client.|extended_stats(0/1 value)|If set to 1, the server will send the CS_STAT_RACE_xxx and CS_STAT_BASE_xxx values too, so the client can display various status related to statistics. Default is 0.|facecache(0/1)|Determines if the client is caching images(1) or wants the images sent to it without caching them(0). Default is 0. This replaces the setfacemode command.|faceset(8 bit)|Faceset the client wishes to use. If the faceset is not valid, the server returns the faceset the client will be using(default 0).|loginmethod(8 bit)|Client sends this to server to note login support. This is basically used as a subset of the csversion/scversion to find out what level of login support the server and client support. Current defined values:0:no advanced support - only legacy login method 1:account based login(described more below) 2:new character creation support This list may grow - for example, advanced character creation could become a feature.|map2cmd:(1)|This indicates client support for the map2 protocol command. See the map2 protocol details above for the main differences. Obsolete:This is the only supported mode now, but many clients use it as a sanity check for protocol versions, so the server still replies. It doesn 't do anything with the data|mapsize(int x) X(int y)|Sets the map size to x X y. Note the spaces here are only for clarity - there should be no spaces when actually sent(it should be 11x11 or 25x25). The default map size unless changed is 11x11. The minimum map size the server will allow is 9x9(no technical reason this could be smaller, but I don 't think the game would be smaller). The maximum map size supported in the current protocol is 63x63. However, each server can have its maximum map size sent to most any value. If the client sends an invalid mapsize command or a mapsize of 0x0, the server will respond with a mapsize that is the maximum size the server supports. Thus, if the client wants to know the maximum map size, it can just do a 'mapsize 0x0' or 'mapsize' and it will get the maximum size back. The server will constrain the provided mapsize x &y to the configured minumum and maximums. For example, if the maximum map size is 25x25, the minimum map size is 9x9, and the client sends a 31x7 mapsize request, the mapsize will be set to 25x9 and the server will send back a mapsize 25x9 setup command. When the values are valid, the server will send back a mapsize XxY setup command. Note that this is from its parsed values, so it may not match stringwise with what the client sent, but will match 0 wise. For example, the client may send a 'mapsize 025X025' command, in which case the server will respond with a 'mapsize 25x25' command - the data is functionally the same. The server will send an updated map view when this command is sent.|notifications(int value)|Value indicating what notifications the client accepts. It is incremental, a value means "all notifications till this level". The following levels are supported:1:quest-related notifications("addquest" and "updquest") 2:knowledge-related notifications("addknowledge") 3:character status flags(overloaded, blind,...)|num_look_objects(int value)|The maximum number of objects shown in the ground view. If more objects are present, fake objects are created for selecting the previous/next group of items. Defaults to 50 if not set. The server may adjust the given value to a suitable one data
int GetInt_String(const unsigned char *data)
Basically does the reverse of SockList_AddInt, but on strings instead.
void lock_item_cmd(uint8_t *data, int len, player *pl)
Client wants to apply some object.
void draw_ext_info(int flags, int pri, const object *pl, uint8_t type, uint8_t subtype, const char *message)
Sends message to player(s).
void SockList_AddStringBuffer(SockList *sl, StringBuffer *sb)
Deallocates string buffer instance and appends its contents.
int is_valid_faceset(int fsn)
Checks specified faceset is valid.
int SockList_ReadPacket(int fd, SockList *sl, int len)
This reads from fd and puts the data in sl.
void set_up_cmd(char *buf, int len, socket_struct *ns)
This is the Setup cmd - easy first implementation.
void send_race_info(socket_struct *ns, char *params)
Sends information on specified race to the client.
Statistics for the last CS_LOGTIME seconds on the server.
void add_me_cmd(char *buf, int len, socket_struct *ns)
The client has requested to be added to the game.
void draw_client_map(object *pl)
Draws client map.
void send_query(socket_struct *ns, uint8_t flags, const char *text)
Asks the client to query the user.
void Send_With_Handling(socket_struct *ns, SockList *sl)
Calls Write_To_Socket to send data to the client.
Contains the base information we use to make up a packet we want to send.
void apply_cmd(char *buf, int len, player *pl)
Client wants to apply some object.
void SockList_NullTerminate(SockList *sl)
Adds a NUL byte without changing the length.
void send_face_cmd(char *buff, int len, socket_struct *ns)
Client has requested pixmap that it somehow missed getting.
void rangetostring(const object *pl, char *obuf, size_t len)
Get player's current range attack in obuf.
void SockList_AddPrintf(SockList *sl, const char *format,...)
Adds a printf like formatted string.
in that case they will be relative to whatever the PWD of the crossfire server process is You probably shouldn though Notes on Specific and settings file datadir Usually usr share crossfire Contains data that the server does not need to modify while such as the etc A default install will pack the and treasurelist definitions into a single or trs file and the graphics into a face(metadata) and .tar(bitmaps) file
void player_update_bg_music(object *player)
void init_listening_socket(socket_struct *ns)
This opens *ns for listening to connections.
1.8.17