2001-01-25 10:37:55 +01:00
|
|
|
|
/* vi: set ts=2:
|
|
|
|
|
*
|
2003-07-29 11:48:03 +02:00
|
|
|
|
* Eressea PB(E)M host Copyright (C) 1998-2003
|
2001-01-25 10:37:55 +01:00
|
|
|
|
* Christian Schlittchen (corwin@amber.kn-bremen.de)
|
|
|
|
|
* Katja Zedel (katze@felidae.kn-bremen.de)
|
|
|
|
|
* Henning Peters (faroul@beyond.kn-bremen.de)
|
|
|
|
|
* Enno Rehling (enno@eressea-pbem.de)
|
|
|
|
|
* Ingo Wilken (Ingo.Wilken@informatik.uni-oldenburg.de)
|
|
|
|
|
*
|
|
|
|
|
* based on:
|
|
|
|
|
*
|
|
|
|
|
* Atlantis v1.0 13 September 1993 Copyright 1993 by Russell Wallace
|
|
|
|
|
* Atlantis v1.7 Copyright 1996 by Alex Schr<EFBFBD>der
|
|
|
|
|
*
|
|
|
|
|
* This program may not be used, modified or distributed without
|
|
|
|
|
* prior permission by the authors of Eressea.
|
|
|
|
|
* This program may not be sold or used commercially without prior written
|
|
|
|
|
* permission from the authors.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <config.h>
|
|
|
|
|
#include "eressea.h"
|
|
|
|
|
#include "message.h"
|
|
|
|
|
|
2001-02-24 13:50:51 +01:00
|
|
|
|
/* kernel includes */
|
2004-06-21 18:45:27 +02:00
|
|
|
|
#include "building.h"
|
2001-01-25 10:37:55 +01:00
|
|
|
|
#include "faction.h"
|
|
|
|
|
#include "item.h"
|
2004-06-21 18:45:27 +02:00
|
|
|
|
#include "order.h"
|
|
|
|
|
#include "plane.h"
|
|
|
|
|
#include "region.h"
|
|
|
|
|
#include "unit.h"
|
2001-01-25 10:37:55 +01:00
|
|
|
|
|
2001-02-24 13:50:51 +01:00
|
|
|
|
/* util includes */
|
2004-06-21 18:45:27 +02:00
|
|
|
|
#include <util/base36.h>
|
|
|
|
|
#include <util/goodies.h>
|
|
|
|
|
#include <util/message.h>
|
|
|
|
|
#include <util/nrmessage.h>
|
|
|
|
|
#include <util/crmessage.h>
|
|
|
|
|
#include <util/log.h>
|
2001-02-11 21:56:20 +01:00
|
|
|
|
|
2001-02-24 13:50:51 +01:00
|
|
|
|
/* libc includes */
|
2001-01-25 10:37:55 +01:00
|
|
|
|
#include <stddef.h>
|
|
|
|
|
#include <stdarg.h>
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
#include <string.h>
|
|
|
|
|
#include <ctype.h>
|
|
|
|
|
#include <assert.h>
|
|
|
|
|
|
|
|
|
|
typedef struct msg_setting {
|
|
|
|
|
struct msg_setting *next;
|
2001-02-24 13:50:51 +01:00
|
|
|
|
const struct message_type *type;
|
2001-01-25 10:37:55 +01:00
|
|
|
|
int level;
|
|
|
|
|
} msg_setting;
|
|
|
|
|
|
|
|
|
|
/************ Compatibility function *************/
|
|
|
|
|
#define MAXSTRLEN (4*DISPLAYSIZE+3)
|
|
|
|
|
#include "region.h"
|
|
|
|
|
#include "eressea.h"
|
|
|
|
|
|
2003-07-29 11:48:03 +02:00
|
|
|
|
messageclass * msgclasses;
|
|
|
|
|
|
|
|
|
|
const messageclass *
|
|
|
|
|
mc_find(const char * name)
|
|
|
|
|
{
|
|
|
|
|
messageclass ** mcp = &msgclasses;
|
|
|
|
|
if (name==NULL) return NULL;
|
|
|
|
|
for (;*mcp;mcp=&(*mcp)->next) {
|
|
|
|
|
messageclass * mc = *mcp;
|
|
|
|
|
if (!strcmp(mc->name, name)) break;
|
|
|
|
|
}
|
|
|
|
|
return *mcp;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const messageclass *
|
|
|
|
|
mc_add(const char * name)
|
|
|
|
|
{
|
|
|
|
|
messageclass ** mcp = &msgclasses;
|
|
|
|
|
if (name==NULL) return NULL;
|
|
|
|
|
for (;*mcp;mcp=&(*mcp)->next) {
|
|
|
|
|
messageclass * mc = *mcp;
|
|
|
|
|
if (!strcmp(mc->name, name)) break;
|
|
|
|
|
}
|
|
|
|
|
if (!*mcp) {
|
|
|
|
|
messageclass * mc = calloc(sizeof(messageclass), 1);
|
|
|
|
|
mc->name = strdup(name);
|
|
|
|
|
*mcp = mc;
|
|
|
|
|
}
|
|
|
|
|
return *mcp;
|
|
|
|
|
}
|
|
|
|
|
|
2001-04-16 16:34:19 +02:00
|
|
|
|
static void
|
2005-06-10 00:10:35 +02:00
|
|
|
|
arg_set(variant args[], const message_type * mtype, const char * buffer, variant v)
|
- Neue Messages fertig
Messages werden jetzt in einem anderen Meta-Format (message* of
message_type*) gespeichert, das man in beliebige Formate (CR oder NR)
rendern kann. crmessage.c und nrmessage.c sind die render-engines dafür.
Die Messagetypen werden in res/{de,en}/messages.xml gesammelt, ultimativ
kann das aber durchaus eine einzelne Datei sein. Die ist derzeit nicht
wirklich xml (Umlaute drin, keine Definitionsdatei), aber gut lesbar.
- make_message
Diese Funktion ersetzt new_message, und ist etwas einfacher in der Syntax:
make_message("dumb_mistake", "unit region command", u, r, cmd) erzeugt
eine neue Nachricht, die dann einfach mit add_message wie bisher an die
Nachrichtenliste gehängt werden kann.
TODO: Messages könnte man durchaus reference-counten, und in mehrere Listen
einfügen, solang sie a) mehrfachverwendet (Kampf!) und b) vom Betrachter
unabhängig sind. Das spart einigen Speicher.
- CR Version erhöht.
Weil die MESSAGETYPES Blocks anders sind als früher
- OFFENSIVE_DELAY
Verbietet Einheiten, deren Partei eine Reigon niht bewachen, den
Angriff in der Region, wenn sie sich in der Runde zuvor bewegt haben.
Status der letzten Runde wird in neuem Attribut at_moved gespeichert.
- SHORT_ATTACKS
ein define, das angibt ob Kämpfen grundsätzlich keine lange Aktion ist.
- XML Parser
xml.[hc] enthält einen XML-Parser, dem man ein plugin mit callbacks
übergibt, die nach dem Parsen eines tokens aufgerufen werden.
2001-04-12 19:21:57 +02:00
|
|
|
|
{
|
|
|
|
|
int i;
|
2001-04-16 16:34:19 +02:00
|
|
|
|
for (i=0;i!=mtype->nparameters;++i) {
|
|
|
|
|
if (!strcmp(buffer, mtype->pnames[i])) break;
|
|
|
|
|
}
|
2004-06-21 18:45:27 +02:00
|
|
|
|
if (i!=mtype->nparameters) {
|
|
|
|
|
args[i] = v;
|
|
|
|
|
} else {
|
2002-07-23 09:23:28 +02:00
|
|
|
|
fprintf(stderr, "invalid parameter %s for message type %s\n", buffer, mtype->name);
|
|
|
|
|
assert(!"program aborted.");
|
|
|
|
|
}
|
2001-04-16 16:34:19 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct message *
|
2004-06-21 18:45:27 +02:00
|
|
|
|
msg_feedback(const struct unit * u, struct order * ord, const char * name, const char* sig, ...)
|
2001-04-16 16:34:19 +02:00
|
|
|
|
{
|
- Neue Messages fertig
Messages werden jetzt in einem anderen Meta-Format (message* of
message_type*) gespeichert, das man in beliebige Formate (CR oder NR)
rendern kann. crmessage.c und nrmessage.c sind die render-engines dafür.
Die Messagetypen werden in res/{de,en}/messages.xml gesammelt, ultimativ
kann das aber durchaus eine einzelne Datei sein. Die ist derzeit nicht
wirklich xml (Umlaute drin, keine Definitionsdatei), aber gut lesbar.
- make_message
Diese Funktion ersetzt new_message, und ist etwas einfacher in der Syntax:
make_message("dumb_mistake", "unit region command", u, r, cmd) erzeugt
eine neue Nachricht, die dann einfach mit add_message wie bisher an die
Nachrichtenliste gehängt werden kann.
TODO: Messages könnte man durchaus reference-counten, und in mehrere Listen
einfügen, solang sie a) mehrfachverwendet (Kampf!) und b) vom Betrachter
unabhängig sind. Das spart einigen Speicher.
- CR Version erhöht.
Weil die MESSAGETYPES Blocks anders sind als früher
- OFFENSIVE_DELAY
Verbietet Einheiten, deren Partei eine Reigon niht bewachen, den
Angriff in der Region, wenn sie sich in der Runde zuvor bewegt haben.
Status der letzten Runde wird in neuem Attribut at_moved gespeichert.
- SHORT_ATTACKS
ein define, das angibt ob Kämpfen grundsätzlich keine lange Aktion ist.
- XML Parser
xml.[hc] enthält einen XML-Parser, dem man ein plugin mit callbacks
übergibt, die nach dem Parsen eines tokens aufgerufen werden.
2001-04-12 19:21:57 +02:00
|
|
|
|
va_list marker;
|
|
|
|
|
const message_type * mtype = mt_find(name);
|
2005-06-10 00:10:35 +02:00
|
|
|
|
char paramname[64];
|
- Neue Messages fertig
Messages werden jetzt in einem anderen Meta-Format (message* of
message_type*) gespeichert, das man in beliebige Formate (CR oder NR)
rendern kann. crmessage.c und nrmessage.c sind die render-engines dafür.
Die Messagetypen werden in res/{de,en}/messages.xml gesammelt, ultimativ
kann das aber durchaus eine einzelne Datei sein. Die ist derzeit nicht
wirklich xml (Umlaute drin, keine Definitionsdatei), aber gut lesbar.
- make_message
Diese Funktion ersetzt new_message, und ist etwas einfacher in der Syntax:
make_message("dumb_mistake", "unit region command", u, r, cmd) erzeugt
eine neue Nachricht, die dann einfach mit add_message wie bisher an die
Nachrichtenliste gehängt werden kann.
TODO: Messages könnte man durchaus reference-counten, und in mehrere Listen
einfügen, solang sie a) mehrfachverwendet (Kampf!) und b) vom Betrachter
unabhängig sind. Das spart einigen Speicher.
- CR Version erhöht.
Weil die MESSAGETYPES Blocks anders sind als früher
- OFFENSIVE_DELAY
Verbietet Einheiten, deren Partei eine Reigon niht bewachen, den
Angriff in der Region, wenn sie sich in der Runde zuvor bewegt haben.
Status der letzten Runde wird in neuem Attribut at_moved gespeichert.
- SHORT_ATTACKS
ein define, das angibt ob Kämpfen grundsätzlich keine lange Aktion ist.
- XML Parser
xml.[hc] enthält einen XML-Parser, dem man ein plugin mit callbacks
übergibt, die nach dem Parsen eines tokens aufgerufen werden.
2001-04-12 19:21:57 +02:00
|
|
|
|
const char *ic = sig;
|
2005-06-10 00:10:35 +02:00
|
|
|
|
variant args[16];
|
|
|
|
|
variant var;
|
- Neue Messages fertig
Messages werden jetzt in einem anderen Meta-Format (message* of
message_type*) gespeichert, das man in beliebige Formate (CR oder NR)
rendern kann. crmessage.c und nrmessage.c sind die render-engines dafür.
Die Messagetypen werden in res/{de,en}/messages.xml gesammelt, ultimativ
kann das aber durchaus eine einzelne Datei sein. Die ist derzeit nicht
wirklich xml (Umlaute drin, keine Definitionsdatei), aber gut lesbar.
- make_message
Diese Funktion ersetzt new_message, und ist etwas einfacher in der Syntax:
make_message("dumb_mistake", "unit region command", u, r, cmd) erzeugt
eine neue Nachricht, die dann einfach mit add_message wie bisher an die
Nachrichtenliste gehängt werden kann.
TODO: Messages könnte man durchaus reference-counten, und in mehrere Listen
einfügen, solang sie a) mehrfachverwendet (Kampf!) und b) vom Betrachter
unabhängig sind. Das spart einigen Speicher.
- CR Version erhöht.
Weil die MESSAGETYPES Blocks anders sind als früher
- OFFENSIVE_DELAY
Verbietet Einheiten, deren Partei eine Reigon niht bewachen, den
Angriff in der Region, wenn sie sich in der Runde zuvor bewegt haben.
Status der letzten Runde wird in neuem Attribut at_moved gespeichert.
- SHORT_ATTACKS
ein define, das angibt ob Kämpfen grundsätzlich keine lange Aktion ist.
- XML Parser
xml.[hc] enthält einen XML-Parser, dem man ein plugin mit callbacks
übergibt, die nach dem Parsen eines tokens aufgerufen werden.
2001-04-12 19:21:57 +02:00
|
|
|
|
memset(args, 0, sizeof(args));
|
* möglichen Exploit beseitigt:
GIB xyz EINHEIT
GIB 0 ALLES SILBER
--> ALLE Befehle der übergebenen Einheit werden gelöscht.
* neue Funktion (convenience): ucansee(f, u1, u2)
liefert u1, wenn cansee(f,u1), sonst u2
* neue mistakes eingefügt uns übersetzt
* message bugfix:
u->htisorder kann gelöscht werden (z.b. NACH). Daher muss ein pointer auf
einen befehl in einer message immer auf den u->order Eintrag zeigen, damit er
zeit der auswertung noch existiert.
findorder(u, u->thisorder) tut das. Ist an mehreren Stellen nicht benutzt
worden. assert eingebaut, das das prüft.
* RESERVE_DONATIONS
Gegenstände, die von einer anderen Partei übergeben wurden, werden nicht
reserviert.
* TWOPASS_GIVE:
GIB Befehle werden zuerst an fremde Einheiten, danach in einem zweiten
Durchlauf an eigene Einheiten, ausgeführt.
* msg_message
An einigen messages ausprobiert, ob man die gleiche Message mehreren
Parteien einhängen kann - klappt, spart Speicher.
Allerdings fehlt dazu ein ordentliches memory-management (refcounter)
2001-05-10 07:50:52 +02:00
|
|
|
|
|
2004-06-21 18:45:27 +02:00
|
|
|
|
if (ord==NULL) ord = u->thisorder;
|
- Neue Messages fertig
Messages werden jetzt in einem anderen Meta-Format (message* of
message_type*) gespeichert, das man in beliebige Formate (CR oder NR)
rendern kann. crmessage.c und nrmessage.c sind die render-engines dafür.
Die Messagetypen werden in res/{de,en}/messages.xml gesammelt, ultimativ
kann das aber durchaus eine einzelne Datei sein. Die ist derzeit nicht
wirklich xml (Umlaute drin, keine Definitionsdatei), aber gut lesbar.
- make_message
Diese Funktion ersetzt new_message, und ist etwas einfacher in der Syntax:
make_message("dumb_mistake", "unit region command", u, r, cmd) erzeugt
eine neue Nachricht, die dann einfach mit add_message wie bisher an die
Nachrichtenliste gehängt werden kann.
TODO: Messages könnte man durchaus reference-counten, und in mehrere Listen
einfügen, solang sie a) mehrfachverwendet (Kampf!) und b) vom Betrachter
unabhängig sind. Das spart einigen Speicher.
- CR Version erhöht.
Weil die MESSAGETYPES Blocks anders sind als früher
- OFFENSIVE_DELAY
Verbietet Einheiten, deren Partei eine Reigon niht bewachen, den
Angriff in der Region, wenn sie sich in der Runde zuvor bewegt haben.
Status der letzten Runde wird in neuem Attribut at_moved gespeichert.
- SHORT_ATTACKS
ein define, das angibt ob Kämpfen grundsätzlich keine lange Aktion ist.
- XML Parser
xml.[hc] enthält einen XML-Parser, dem man ein plugin mit callbacks
übergibt, die nach dem Parsen eines tokens aufgerufen werden.
2001-04-12 19:21:57 +02:00
|
|
|
|
|
|
|
|
|
if (!mtype) {
|
2004-01-04 19:14:20 +01:00
|
|
|
|
log_error(("trying to create message of unknown type \"%s\"\n", name));
|
- Neue Messages fertig
Messages werden jetzt in einem anderen Meta-Format (message* of
message_type*) gespeichert, das man in beliebige Formate (CR oder NR)
rendern kann. crmessage.c und nrmessage.c sind die render-engines dafür.
Die Messagetypen werden in res/{de,en}/messages.xml gesammelt, ultimativ
kann das aber durchaus eine einzelne Datei sein. Die ist derzeit nicht
wirklich xml (Umlaute drin, keine Definitionsdatei), aber gut lesbar.
- make_message
Diese Funktion ersetzt new_message, und ist etwas einfacher in der Syntax:
make_message("dumb_mistake", "unit region command", u, r, cmd) erzeugt
eine neue Nachricht, die dann einfach mit add_message wie bisher an die
Nachrichtenliste gehängt werden kann.
TODO: Messages könnte man durchaus reference-counten, und in mehrere Listen
einfügen, solang sie a) mehrfachverwendet (Kampf!) und b) vom Betrachter
unabhängig sind. Das spart einigen Speicher.
- CR Version erhöht.
Weil die MESSAGETYPES Blocks anders sind als früher
- OFFENSIVE_DELAY
Verbietet Einheiten, deren Partei eine Reigon niht bewachen, den
Angriff in der Region, wenn sie sich in der Runde zuvor bewegt haben.
Status der letzten Runde wird in neuem Attribut at_moved gespeichert.
- SHORT_ATTACKS
ein define, das angibt ob Kämpfen grundsätzlich keine lange Aktion ist.
- XML Parser
xml.[hc] enthält einen XML-Parser, dem man ein plugin mit callbacks
übergibt, die nach dem Parsen eines tokens aufgerufen werden.
2001-04-12 19:21:57 +02:00
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2005-06-10 00:10:35 +02:00
|
|
|
|
var.v = (void*)u;
|
|
|
|
|
arg_set(args, mtype, "unit", var);
|
|
|
|
|
var.v = (void*)u->region;
|
|
|
|
|
arg_set(args, mtype, "region", var);
|
|
|
|
|
var.v = (void*)ord;
|
|
|
|
|
arg_set(args, mtype, "command", var);
|
2001-04-16 16:34:19 +02:00
|
|
|
|
|
- Neue Messages fertig
Messages werden jetzt in einem anderen Meta-Format (message* of
message_type*) gespeichert, das man in beliebige Formate (CR oder NR)
rendern kann. crmessage.c und nrmessage.c sind die render-engines dafür.
Die Messagetypen werden in res/{de,en}/messages.xml gesammelt, ultimativ
kann das aber durchaus eine einzelne Datei sein. Die ist derzeit nicht
wirklich xml (Umlaute drin, keine Definitionsdatei), aber gut lesbar.
- make_message
Diese Funktion ersetzt new_message, und ist etwas einfacher in der Syntax:
make_message("dumb_mistake", "unit region command", u, r, cmd) erzeugt
eine neue Nachricht, die dann einfach mit add_message wie bisher an die
Nachrichtenliste gehängt werden kann.
TODO: Messages könnte man durchaus reference-counten, und in mehrere Listen
einfügen, solang sie a) mehrfachverwendet (Kampf!) und b) vom Betrachter
unabhängig sind. Das spart einigen Speicher.
- CR Version erhöht.
Weil die MESSAGETYPES Blocks anders sind als früher
- OFFENSIVE_DELAY
Verbietet Einheiten, deren Partei eine Reigon niht bewachen, den
Angriff in der Region, wenn sie sich in der Runde zuvor bewegt haben.
Status der letzten Runde wird in neuem Attribut at_moved gespeichert.
- SHORT_ATTACKS
ein define, das angibt ob Kämpfen grundsätzlich keine lange Aktion ist.
- XML Parser
xml.[hc] enthält einen XML-Parser, dem man ein plugin mit callbacks
übergibt, die nach dem Parsen eines tokens aufgerufen werden.
2001-04-12 19:21:57 +02:00
|
|
|
|
va_start(marker, sig);
|
|
|
|
|
while (*ic && !isalnum(*ic)) ic++;
|
|
|
|
|
while (*ic) {
|
2005-06-10 00:10:35 +02:00
|
|
|
|
char * oc = paramname;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
while (isalnum(*ic)) *oc++ = *ic++;
|
- Neue Messages fertig
Messages werden jetzt in einem anderen Meta-Format (message* of
message_type*) gespeichert, das man in beliebige Formate (CR oder NR)
rendern kann. crmessage.c und nrmessage.c sind die render-engines dafür.
Die Messagetypen werden in res/{de,en}/messages.xml gesammelt, ultimativ
kann das aber durchaus eine einzelne Datei sein. Die ist derzeit nicht
wirklich xml (Umlaute drin, keine Definitionsdatei), aber gut lesbar.
- make_message
Diese Funktion ersetzt new_message, und ist etwas einfacher in der Syntax:
make_message("dumb_mistake", "unit region command", u, r, cmd) erzeugt
eine neue Nachricht, die dann einfach mit add_message wie bisher an die
Nachrichtenliste gehängt werden kann.
TODO: Messages könnte man durchaus reference-counten, und in mehrere Listen
einfügen, solang sie a) mehrfachverwendet (Kampf!) und b) vom Betrachter
unabhängig sind. Das spart einigen Speicher.
- CR Version erhöht.
Weil die MESSAGETYPES Blocks anders sind als früher
- OFFENSIVE_DELAY
Verbietet Einheiten, deren Partei eine Reigon niht bewachen, den
Angriff in der Region, wenn sie sich in der Runde zuvor bewegt haben.
Status der letzten Runde wird in neuem Attribut at_moved gespeichert.
- SHORT_ATTACKS
ein define, das angibt ob Kämpfen grundsätzlich keine lange Aktion ist.
- XML Parser
xml.[hc] enthält einen XML-Parser, dem man ein plugin mit callbacks
übergibt, die nach dem Parsen eines tokens aufgerufen werden.
2001-04-12 19:21:57 +02:00
|
|
|
|
*oc = '\0';
|
2005-06-10 00:10:35 +02:00
|
|
|
|
|
|
|
|
|
for (i=0;i!=mtype->nparameters;++i) {
|
|
|
|
|
if (!strcmp(paramname, mtype->pnames[i])) break;
|
|
|
|
|
}
|
|
|
|
|
if (i!=mtype->nparameters) {
|
|
|
|
|
if (mtype->types[i]->vtype==VAR_VOIDPTR) {
|
|
|
|
|
args[i].v = va_arg(marker, void*);
|
|
|
|
|
} else if (mtype->types[i]->vtype==VAR_INT) {
|
|
|
|
|
args[i].i = va_arg(marker, int);
|
|
|
|
|
} else {
|
|
|
|
|
assert(!"unknown variant type");
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
log_error(("invalid parameter %s for message type %s\n", paramname, mtype->name));
|
|
|
|
|
assert(!"program aborted.");
|
|
|
|
|
}
|
|
|
|
|
while (*ic && !isalnum(*ic)) ic++;
|
2001-04-16 16:34:19 +02:00
|
|
|
|
}
|
|
|
|
|
va_end(marker);
|
|
|
|
|
|
2005-06-10 00:10:35 +02:00
|
|
|
|
return msg_create(mtype, args);
|
2001-04-16 16:34:19 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
message *
|
|
|
|
|
msg_message(const char * name, const char* sig, ...)
|
|
|
|
|
/* msg_message("oops_error", "unit region command", u, r, cmd) */
|
|
|
|
|
{
|
2006-01-29 02:55:36 +01:00
|
|
|
|
va_list marker;
|
|
|
|
|
const message_type * mtype = mt_find(name);
|
|
|
|
|
char paramname[64];
|
|
|
|
|
const char *ic = sig;
|
|
|
|
|
variant args[16];
|
|
|
|
|
memset(args, 0, sizeof(args));
|
|
|
|
|
|
|
|
|
|
if (!mtype) {
|
|
|
|
|
log_warning(("trying to create message of unknown type \"%s\"\n", name));
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
va_start(marker, sig);
|
|
|
|
|
while (*ic && !isalnum(*ic)) ic++;
|
|
|
|
|
while (*ic) {
|
|
|
|
|
char * oc = paramname;
|
2005-06-10 00:10:35 +02:00
|
|
|
|
int i;
|
2006-01-29 02:55:36 +01:00
|
|
|
|
|
2005-06-10 00:10:35 +02:00
|
|
|
|
while (isalnum(*ic)) *oc++ = *ic++;
|
2006-01-29 02:55:36 +01:00
|
|
|
|
*oc = '\0';
|
|
|
|
|
|
2005-06-10 00:10:35 +02:00
|
|
|
|
for (i=0;i!=mtype->nparameters;++i) {
|
|
|
|
|
if (!strcmp(paramname, mtype->pnames[i])) break;
|
|
|
|
|
}
|
|
|
|
|
if (i!=mtype->nparameters) {
|
|
|
|
|
if (mtype->types[i]->vtype==VAR_VOIDPTR) {
|
|
|
|
|
args[i].v = va_arg(marker, void*);
|
|
|
|
|
} else if (mtype->types[i]->vtype==VAR_INT) {
|
|
|
|
|
args[i].i = va_arg(marker, int);
|
|
|
|
|
} else {
|
|
|
|
|
assert(!"unknown variant type");
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
log_error(("invalid parameter %s for message type %s\n", paramname, mtype->name));
|
|
|
|
|
assert(!"program aborted.");
|
|
|
|
|
}
|
|
|
|
|
while (*ic && !isalnum(*ic)) ic++;
|
|
|
|
|
}
|
|
|
|
|
va_end(marker);
|
|
|
|
|
|
|
|
|
|
return msg_create(mtype, args);
|
- Neue Messages fertig
Messages werden jetzt in einem anderen Meta-Format (message* of
message_type*) gespeichert, das man in beliebige Formate (CR oder NR)
rendern kann. crmessage.c und nrmessage.c sind die render-engines dafür.
Die Messagetypen werden in res/{de,en}/messages.xml gesammelt, ultimativ
kann das aber durchaus eine einzelne Datei sein. Die ist derzeit nicht
wirklich xml (Umlaute drin, keine Definitionsdatei), aber gut lesbar.
- make_message
Diese Funktion ersetzt new_message, und ist etwas einfacher in der Syntax:
make_message("dumb_mistake", "unit region command", u, r, cmd) erzeugt
eine neue Nachricht, die dann einfach mit add_message wie bisher an die
Nachrichtenliste gehängt werden kann.
TODO: Messages könnte man durchaus reference-counten, und in mehrere Listen
einfügen, solang sie a) mehrfachverwendet (Kampf!) und b) vom Betrachter
unabhängig sind. Das spart einigen Speicher.
- CR Version erhöht.
Weil die MESSAGETYPES Blocks anders sind als früher
- OFFENSIVE_DELAY
Verbietet Einheiten, deren Partei eine Reigon niht bewachen, den
Angriff in der Region, wenn sie sich in der Runde zuvor bewegt haben.
Status der letzten Runde wird in neuem Attribut at_moved gespeichert.
- SHORT_ATTACKS
ein define, das angibt ob Kämpfen grundsätzlich keine lange Aktion ist.
- XML Parser
xml.[hc] enthält einen XML-Parser, dem man ein plugin mit callbacks
übergibt, die nach dem Parsen eines tokens aufgerufen werden.
2001-04-12 19:21:57 +02:00
|
|
|
|
}
|
|
|
|
|
|
* möglichen Exploit beseitigt:
GIB xyz EINHEIT
GIB 0 ALLES SILBER
--> ALLE Befehle der übergebenen Einheit werden gelöscht.
* neue Funktion (convenience): ucansee(f, u1, u2)
liefert u1, wenn cansee(f,u1), sonst u2
* neue mistakes eingefügt uns übersetzt
* message bugfix:
u->htisorder kann gelöscht werden (z.b. NACH). Daher muss ein pointer auf
einen befehl in einer message immer auf den u->order Eintrag zeigen, damit er
zeit der auswertung noch existiert.
findorder(u, u->thisorder) tut das. Ist an mehreren Stellen nicht benutzt
worden. assert eingebaut, das das prüft.
* RESERVE_DONATIONS
Gegenstände, die von einer anderen Partei übergeben wurden, werden nicht
reserviert.
* TWOPASS_GIVE:
GIB Befehle werden zuerst an fremde Einheiten, danach in einem zweiten
Durchlauf an eigene Einheiten, ausgeführt.
* msg_message
An einigen messages ausprobiert, ob man die gleiche Message mehreren
Parteien einhängen kann - klappt, spart Speicher.
Allerdings fehlt dazu ein ordentliches memory-management (refcounter)
2001-05-10 07:50:52 +02:00
|
|
|
|
static void
|
|
|
|
|
caddmessage(region * r, faction * f, const char *s, msg_t mtype, int level)
|
2001-01-25 10:37:55 +01:00
|
|
|
|
{
|
|
|
|
|
message * m = NULL;
|
* möglichen Exploit beseitigt:
GIB xyz EINHEIT
GIB 0 ALLES SILBER
--> ALLE Befehle der übergebenen Einheit werden gelöscht.
* neue Funktion (convenience): ucansee(f, u1, u2)
liefert u1, wenn cansee(f,u1), sonst u2
* neue mistakes eingefügt uns übersetzt
* message bugfix:
u->htisorder kann gelöscht werden (z.b. NACH). Daher muss ein pointer auf
einen befehl in einer message immer auf den u->order Eintrag zeigen, damit er
zeit der auswertung noch existiert.
findorder(u, u->thisorder) tut das. Ist an mehreren Stellen nicht benutzt
worden. assert eingebaut, das das prüft.
* RESERVE_DONATIONS
Gegenstände, die von einer anderen Partei übergeben wurden, werden nicht
reserviert.
* TWOPASS_GIVE:
GIB Befehle werden zuerst an fremde Einheiten, danach in einem zweiten
Durchlauf an eigene Einheiten, ausgeführt.
* msg_message
An einigen messages ausprobiert, ob man die gleiche Message mehreren
Parteien einhängen kann - klappt, spart Speicher.
Allerdings fehlt dazu ein ordentliches memory-management (refcounter)
2001-05-10 07:50:52 +02:00
|
|
|
|
|
|
|
|
|
unused(level);
|
2001-01-25 10:37:55 +01:00
|
|
|
|
switch (mtype) {
|
|
|
|
|
case MSG_INCOME:
|
|
|
|
|
assert(f);
|
2001-05-20 23:47:56 +02:00
|
|
|
|
m = add_message(&f->msgs, msg_message("msg_economy", "string", s));
|
2001-01-25 10:37:55 +01:00
|
|
|
|
break;
|
|
|
|
|
case MSG_BATTLE:
|
|
|
|
|
assert(0 || !"battle-meldungen nicht <20>ber addmessage machen");
|
|
|
|
|
break;
|
|
|
|
|
case MSG_MOVE:
|
|
|
|
|
assert(f);
|
2001-05-20 23:47:56 +02:00
|
|
|
|
m = add_message(&f->msgs, msg_message("msg_movement", "string", s));
|
2001-01-25 10:37:55 +01:00
|
|
|
|
break;
|
|
|
|
|
case MSG_COMMERCE:
|
|
|
|
|
assert(f);
|
2001-05-20 23:47:56 +02:00
|
|
|
|
m = add_message(&f->msgs, msg_message("msg_economy", "string", s));
|
2001-01-25 10:37:55 +01:00
|
|
|
|
break;
|
|
|
|
|
case MSG_PRODUCE:
|
|
|
|
|
assert(f);
|
2001-05-20 23:47:56 +02:00
|
|
|
|
m = add_message(&f->msgs, msg_message("msg_production", "string", s));
|
2001-01-25 10:37:55 +01:00
|
|
|
|
break;
|
|
|
|
|
case MSG_MAGIC:
|
|
|
|
|
case MSG_COMMENT:
|
|
|
|
|
case MSG_MESSAGE:
|
|
|
|
|
case MSG_ORCVERMEHRUNG:
|
|
|
|
|
case MSG_EVENT:
|
|
|
|
|
/* Botschaften an REGION oder einzelne PARTEI */
|
2001-05-20 09:46:13 +02:00
|
|
|
|
m = msg_message("msg_event", "string", s);
|
* möglichen Exploit beseitigt:
GIB xyz EINHEIT
GIB 0 ALLES SILBER
--> ALLE Befehle der übergebenen Einheit werden gelöscht.
* neue Funktion (convenience): ucansee(f, u1, u2)
liefert u1, wenn cansee(f,u1), sonst u2
* neue mistakes eingefügt uns übersetzt
* message bugfix:
u->htisorder kann gelöscht werden (z.b. NACH). Daher muss ein pointer auf
einen befehl in einer message immer auf den u->order Eintrag zeigen, damit er
zeit der auswertung noch existiert.
findorder(u, u->thisorder) tut das. Ist an mehreren Stellen nicht benutzt
worden. assert eingebaut, das das prüft.
* RESERVE_DONATIONS
Gegenstände, die von einer anderen Partei übergeben wurden, werden nicht
reserviert.
* TWOPASS_GIVE:
GIB Befehle werden zuerst an fremde Einheiten, danach in einem zweiten
Durchlauf an eigene Einheiten, ausgeführt.
* msg_message
An einigen messages ausprobiert, ob man die gleiche Message mehreren
Parteien einhängen kann - klappt, spart Speicher.
Allerdings fehlt dazu ein ordentliches memory-management (refcounter)
2001-05-10 07:50:52 +02:00
|
|
|
|
if (!r) {
|
|
|
|
|
assert(f);
|
2001-05-20 09:46:13 +02:00
|
|
|
|
m = add_message(&f->msgs, m);
|
|
|
|
|
} else {
|
2001-05-27 16:02:12 +02:00
|
|
|
|
if (f==NULL) add_message(&r->msgs, m);
|
2001-05-20 09:46:13 +02:00
|
|
|
|
else r_addmessage(r, f, m);
|
* möglichen Exploit beseitigt:
GIB xyz EINHEIT
GIB 0 ALLES SILBER
--> ALLE Befehle der übergebenen Einheit werden gelöscht.
* neue Funktion (convenience): ucansee(f, u1, u2)
liefert u1, wenn cansee(f,u1), sonst u2
* neue mistakes eingefügt uns übersetzt
* message bugfix:
u->htisorder kann gelöscht werden (z.b. NACH). Daher muss ein pointer auf
einen befehl in einer message immer auf den u->order Eintrag zeigen, damit er
zeit der auswertung noch existiert.
findorder(u, u->thisorder) tut das. Ist an mehreren Stellen nicht benutzt
worden. assert eingebaut, das das prüft.
* RESERVE_DONATIONS
Gegenstände, die von einer anderen Partei übergeben wurden, werden nicht
reserviert.
* TWOPASS_GIVE:
GIB Befehle werden zuerst an fremde Einheiten, danach in einem zweiten
Durchlauf an eigene Einheiten, ausgeführt.
* msg_message
An einigen messages ausprobiert, ob man die gleiche Message mehreren
Parteien einhängen kann - klappt, spart Speicher.
Allerdings fehlt dazu ein ordentliches memory-management (refcounter)
2001-05-10 07:50:52 +02:00
|
|
|
|
}
|
2001-01-25 10:37:55 +01:00
|
|
|
|
break;
|
|
|
|
|
default:
|
2001-04-14 14:11:45 +02:00
|
|
|
|
assert(!"Ung<EFBFBD>ltige Msg-Klasse!");
|
2001-01-25 10:37:55 +01:00
|
|
|
|
}
|
2001-05-20 23:47:56 +02:00
|
|
|
|
if (m) msg_release(m);
|
2001-01-25 10:37:55 +01:00
|
|
|
|
}
|
|
|
|
|
|
* möglichen Exploit beseitigt:
GIB xyz EINHEIT
GIB 0 ALLES SILBER
--> ALLE Befehle der übergebenen Einheit werden gelöscht.
* neue Funktion (convenience): ucansee(f, u1, u2)
liefert u1, wenn cansee(f,u1), sonst u2
* neue mistakes eingefügt uns übersetzt
* message bugfix:
u->htisorder kann gelöscht werden (z.b. NACH). Daher muss ein pointer auf
einen befehl in einer message immer auf den u->order Eintrag zeigen, damit er
zeit der auswertung noch existiert.
findorder(u, u->thisorder) tut das. Ist an mehreren Stellen nicht benutzt
worden. assert eingebaut, das das prüft.
* RESERVE_DONATIONS
Gegenstände, die von einer anderen Partei übergeben wurden, werden nicht
reserviert.
* TWOPASS_GIVE:
GIB Befehle werden zuerst an fremde Einheiten, danach in einem zweiten
Durchlauf an eigene Einheiten, ausgeführt.
* msg_message
An einigen messages ausprobiert, ob man die gleiche Message mehreren
Parteien einhängen kann - klappt, spart Speicher.
Allerdings fehlt dazu ein ordentliches memory-management (refcounter)
2001-05-10 07:50:52 +02:00
|
|
|
|
void
|
|
|
|
|
addmessage(region * r, faction * f, const char *s, msg_t mtype, int level)
|
|
|
|
|
{
|
2005-06-10 00:10:35 +02:00
|
|
|
|
caddmessage(r, f, s, mtype, level);
|
* möglichen Exploit beseitigt:
GIB xyz EINHEIT
GIB 0 ALLES SILBER
--> ALLE Befehle der übergebenen Einheit werden gelöscht.
* neue Funktion (convenience): ucansee(f, u1, u2)
liefert u1, wenn cansee(f,u1), sonst u2
* neue mistakes eingefügt uns übersetzt
* message bugfix:
u->htisorder kann gelöscht werden (z.b. NACH). Daher muss ein pointer auf
einen befehl in einer message immer auf den u->order Eintrag zeigen, damit er
zeit der auswertung noch existiert.
findorder(u, u->thisorder) tut das. Ist an mehreren Stellen nicht benutzt
worden. assert eingebaut, das das prüft.
* RESERVE_DONATIONS
Gegenstände, die von einer anderen Partei übergeben wurden, werden nicht
reserviert.
* TWOPASS_GIVE:
GIB Befehle werden zuerst an fremde Einheiten, danach in einem zweiten
Durchlauf an eigene Einheiten, ausgeführt.
* msg_message
An einigen messages ausprobiert, ob man die gleiche Message mehreren
Parteien einhängen kann - klappt, spart Speicher.
Allerdings fehlt dazu ein ordentliches memory-management (refcounter)
2001-05-10 07:50:52 +02:00
|
|
|
|
}
|
|
|
|
|
|
2004-06-21 18:45:27 +02:00
|
|
|
|
void
|
|
|
|
|
mistake(const unit * u, struct order * ord, const char *comment, int mtype)
|
2001-01-25 10:37:55 +01:00
|
|
|
|
{
|
2004-06-21 18:45:27 +02:00
|
|
|
|
if (u->faction->no != MONSTER_FACTION) {
|
|
|
|
|
ADDMSG(&u->faction->msgs, msg_message("mistake",
|
2006-01-02 23:41:36 +01:00
|
|
|
|
"command error unit region", ord, comment, u, u->region));
|
2004-06-21 18:45:27 +02:00
|
|
|
|
}
|
2001-01-25 10:37:55 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2004-06-21 18:45:27 +02:00
|
|
|
|
cmistake(const unit * u, struct order *ord, int mno, int mtype)
|
2001-01-25 10:37:55 +01:00
|
|
|
|
{
|
* möglichen Exploit beseitigt:
GIB xyz EINHEIT
GIB 0 ALLES SILBER
--> ALLE Befehle der übergebenen Einheit werden gelöscht.
* neue Funktion (convenience): ucansee(f, u1, u2)
liefert u1, wenn cansee(f,u1), sonst u2
* neue mistakes eingefügt uns übersetzt
* message bugfix:
u->htisorder kann gelöscht werden (z.b. NACH). Daher muss ein pointer auf
einen befehl in einer message immer auf den u->order Eintrag zeigen, damit er
zeit der auswertung noch existiert.
findorder(u, u->thisorder) tut das. Ist an mehreren Stellen nicht benutzt
worden. assert eingebaut, das das prüft.
* RESERVE_DONATIONS
Gegenstände, die von einer anderen Partei übergeben wurden, werden nicht
reserviert.
* TWOPASS_GIVE:
GIB Befehle werden zuerst an fremde Einheiten, danach in einem zweiten
Durchlauf an eigene Einheiten, ausgeführt.
* msg_message
An einigen messages ausprobiert, ob man die gleiche Message mehreren
Parteien einhängen kann - klappt, spart Speicher.
Allerdings fehlt dazu ein ordentliches memory-management (refcounter)
2001-05-10 07:50:52 +02:00
|
|
|
|
static char ebuf[20];
|
2004-12-19 17:39:51 +01:00
|
|
|
|
unused(mtype);
|
* möglichen Exploit beseitigt:
GIB xyz EINHEIT
GIB 0 ALLES SILBER
--> ALLE Befehle der übergebenen Einheit werden gelöscht.
* neue Funktion (convenience): ucansee(f, u1, u2)
liefert u1, wenn cansee(f,u1), sonst u2
* neue mistakes eingefügt uns übersetzt
* message bugfix:
u->htisorder kann gelöscht werden (z.b. NACH). Daher muss ein pointer auf
einen befehl in einer message immer auf den u->order Eintrag zeigen, damit er
zeit der auswertung noch existiert.
findorder(u, u->thisorder) tut das. Ist an mehreren Stellen nicht benutzt
worden. assert eingebaut, das das prüft.
* RESERVE_DONATIONS
Gegenstände, die von einer anderen Partei übergeben wurden, werden nicht
reserviert.
* TWOPASS_GIVE:
GIB Befehle werden zuerst an fremde Einheiten, danach in einem zweiten
Durchlauf an eigene Einheiten, ausgeführt.
* msg_message
An einigen messages ausprobiert, ob man die gleiche Message mehreren
Parteien einhängen kann - klappt, spart Speicher.
Allerdings fehlt dazu ein ordentliches memory-management (refcounter)
2001-05-10 07:50:52 +02:00
|
|
|
|
|
2001-01-25 10:37:55 +01:00
|
|
|
|
if (u->faction->no == MONSTER_FACTION) return;
|
* möglichen Exploit beseitigt:
GIB xyz EINHEIT
GIB 0 ALLES SILBER
--> ALLE Befehle der übergebenen Einheit werden gelöscht.
* neue Funktion (convenience): ucansee(f, u1, u2)
liefert u1, wenn cansee(f,u1), sonst u2
* neue mistakes eingefügt uns übersetzt
* message bugfix:
u->htisorder kann gelöscht werden (z.b. NACH). Daher muss ein pointer auf
einen befehl in einer message immer auf den u->order Eintrag zeigen, damit er
zeit der auswertung noch existiert.
findorder(u, u->thisorder) tut das. Ist an mehreren Stellen nicht benutzt
worden. assert eingebaut, das das prüft.
* RESERVE_DONATIONS
Gegenstände, die von einer anderen Partei übergeben wurden, werden nicht
reserviert.
* TWOPASS_GIVE:
GIB Befehle werden zuerst an fremde Einheiten, danach in einem zweiten
Durchlauf an eigene Einheiten, ausgeführt.
* msg_message
An einigen messages ausprobiert, ob man die gleiche Message mehreren
Parteien einhängen kann - klappt, spart Speicher.
Allerdings fehlt dazu ein ordentliches memory-management (refcounter)
2001-05-10 07:50:52 +02:00
|
|
|
|
sprintf(ebuf, "error%d", mno);
|
2004-06-21 18:45:27 +02:00
|
|
|
|
ADDMSG(&u->faction->msgs, msg_message(ebuf,
|
2005-06-11 10:09:55 +02:00
|
|
|
|
"command unit region", ord, u, u->region));
|
2001-01-25 10:37:55 +01:00
|
|
|
|
}
|
|
|
|
|
|
2001-02-14 02:38:51 +01:00
|
|
|
|
extern unsigned int new_hashstring(const char* s);
|
|
|
|
|
|
2005-05-07 15:38:46 +02:00
|
|
|
|
void
|
|
|
|
|
free_messagelist(message_list * msgs)
|
|
|
|
|
{
|
|
|
|
|
struct mlist ** mlistptr = &msgs->begin;
|
|
|
|
|
while (*mlistptr) {
|
|
|
|
|
struct mlist * ml = *mlistptr;
|
|
|
|
|
*mlistptr = ml->next;
|
|
|
|
|
msg_release(ml->msg);
|
|
|
|
|
free(ml);
|
|
|
|
|
}
|
|
|
|
|
free(msgs);
|
|
|
|
|
}
|
|
|
|
|
|
2001-02-24 13:50:51 +01:00
|
|
|
|
message *
|
|
|
|
|
add_message(message_list** pm, message * m)
|
2001-01-25 10:37:55 +01:00
|
|
|
|
{
|
2005-04-23 11:47:03 +02:00
|
|
|
|
if (!lomem && m!=NULL) {
|
2001-02-24 13:50:51 +01:00
|
|
|
|
struct mlist * mnew = malloc(sizeof(struct mlist));
|
|
|
|
|
if (*pm==NULL) {
|
|
|
|
|
*pm = malloc(sizeof(message_list));
|
|
|
|
|
(*pm)->end=&(*pm)->begin;
|
|
|
|
|
}
|
2001-05-20 23:47:56 +02:00
|
|
|
|
mnew->msg = msg_addref(m);
|
2001-02-24 13:50:51 +01:00
|
|
|
|
mnew->next = NULL;
|
|
|
|
|
*((*pm)->end) = mnew;
|
|
|
|
|
(*pm)->end=&mnew->next;
|
|
|
|
|
}
|
|
|
|
|
return m;
|
2001-01-25 10:37:55 +01:00
|
|
|
|
}
|
|
|
|
|
|
2002-01-05 17:14:38 +01:00
|
|
|
|
|