Go to the documentation of this file.
32 #include <unordered_map>
38 std::unordered_map<std::string, std::string>
bells;
43 static std::unordered_map<std::string, Region *>
regions;
56 if (
line[0] ==
'\0' ||
line[0] ==
'#') {
67 if (strcmp(
line,
"region") == 0) {
77 for (
size_t i = 0; i <
count; i++) {
78 if (strcmp(
split[i],
"*") == 0) {
101 auto god =
found->second->bells.find(god_name);
102 std::string
msg = god ==
found->second->bells.end() ?
found->second->fallback : god->second;
103 auto r =
msg.find(
"%god");
104 if (
r != std::string::npos) {
105 msg.replace(
r, 4, god_name);
112 pl =
pl->contr->next ?
pl->contr->next->ob : NULL;
static void ring_bell(void)
Install Bug reporting Credits so make sure you have version or later There are files involved in the automatic convert convertall and filelist py GuildList has the list of guilds for the server GuildLocations is what is used by the install script for setting up the maps It has columns in the first is the name of the no spaces The second is the region of the the third is the destination folder for the the fourth is the exit the fifth and sixth are the x and y coords within the exit the seventh eighth and ninth are the exit location for the storage hall If field seven is then it uses the same exit map as for the guild hall itself filelist py has a list of which files to process for each guild hall convert py takes all the files in filelist py and customises them to the specific guild then outputs them into a in the same order that they are listed in GuildLocations convertall py reads the lines from GuildLocations and runs line by line
size_t bufferreader_current_line(BufferReader *br)
void LOG(LogLevel logLevel, const char *format,...)
void get_tod(timeofday_t *tod)
std::unordered_map< std::string, std::string > bells
event_registration events_register_global_handler(int eventcode, f_plug_event hook)
Crossfire Protocol most of the time after the actual code was already omit certain important and possibly make life miserable any new developer or curious player should be able to find most of the relevant information here If inconsistencies are found or this documentation proves to be consider the latest server side protocol code in the public source code repository as the authoritative reference Introduction If you were ever curious enough to telnet or netcat to a Crossfire chances are you were sorely disappointed While the protocol may seem to use plain text at it actually uses a mix of ASCII and binary data This handbook attempts to document various aspects of the Crossfire protocol As consult the README file to find out how to get in touch with helpful people via mailing and more History the communications plan was set to be a text based system It was up to the server and client to parse these messages and determine what to do These messages were assumed to be line per message At a reasonably early stage of Eric Anderson wrote a then the data itself you could send many data and after the other end could decode these commands This works fairly but I think the creation of numerous sub packets has some performance hit the eutl was not especially well so writing a client for a different platform became more Eric left to work on other products shortly after writing his which didn t really leave anyone with a full understanding of the socket code I have decided to remove the eutl dependency At least one advantage is that having this network related code directly in the client and server makes error handling a bit easier cleaner Packet Format the outside packet method the byte size for the size information is not included here Eutl originally used bytes for the size to bytes seems it makes a least some sense The actual data is something of the nature of the commands listed below It is a text followed by possible other data The remaining data can be binary it is up to the client and server to decode what it sent The commands as described below is just the data portion of the packet If writing a new remember that you must take into account the size of the packet There is no termination of other than knowing how long it should be For most everything that is sent is text This is more or less how things worked under except it packed the ints into bytes in a known order In some we handle ints as in they are sent as binary information How any command handles it is detailed below in the command description The S and C represent the direction of the we use MSB as well as any ints or shorts that get sent inside the packets All packets are defined to have at least one word of followed by a space
const char * determine_god(object *op)
void events_unregister_global_handler(int eventcode, event_registration id)
void add_hook(const char *name, collectorHook hook)
void cfcitybell_init(Settings *settings)
std::vector< char * > disabled_plugins
std::vector< region * > all_regions
unsigned long event_registration
static std::unordered_map< std::string, Region * > regions
size_t split_string(char *str, char *array[], size_t array_size, char sep)
static event_registration global_handler
region * get_region_by_map(mapstruct *m)
Crossfire Architecture the general intention is to enhance the enjoyability and playability of CF In this code
static std::vector< std::string > split(const std::string &field, const std::string &by)
static int clock_listener(int *type,...)
static void load_bells(BufferReader *reader, const char *filename)
char * bufferreader_next_line(BufferReader *br)