neue funktion is_migrant(unit*)

noch mit krötenhack
This commit is contained in:
Katja Zedel 2001-02-11 09:42:58 +00:00
parent 93192b01ff
commit 0047482a8e
2 changed files with 73 additions and 17 deletions

View File

@ -1,6 +1,6 @@
/* vi: set ts=2:
*
* $Id: study.c,v 1.5 2001/02/04 13:20:12 corwin Exp $
* $Id: study.c,v 1.6 2001/02/11 09:42:57 katze Exp $
* Eressea PB(E)M host Copyright (C) 1998-2000
* Christian Schlittchen (corwin@amber.kn-bremen.de)
* Katja Zedel (katze@felidae.kn-bremen.de)
@ -70,6 +70,20 @@ getmagicskill(void)
/* ------------------------------------------------------------- */
boolean
is_migrant(unit *u)
{
if (u->race == u->faction->race) return false;
if (is_familiar(u)) return false;
if (u->race == RC_TOAD) return false;
return true;
}
/* ------------------------------------------------------------- */
static int
study_cost(unit *u, int talent)
{
@ -446,11 +460,11 @@ learn(void)
continue;
}
}
if (u->race != u->faction->race
if (is_migrant(u)
&& (i == SK_MAGIC || i == SK_ALCHEMY || i == SK_TACTICS
|| i == SK_HERBALISM || i == SK_SPY))
{
if (is_familiar(u) || (nonplayer(u) && get_skill(u, i) > 0)) {
if ((nonplayer(u) && get_skill(u, i) > 0)) {
} else {
sprintf(buf, "Migranten können keine kostenpflichtigen Talente lernen");
mistake(u, u->thisorder, buf, MSG_EVENT);

View File

@ -1,32 +1,72 @@
Was ist das hier?
Dieses File ist eine Sammlung von kleinen Artikeln zum Code - Designgedanken, hauptsächlich, keine Anleitungen.
Dieses File ist eine Sammlung von kleinen Artikeln zum Code -
Designgedanken, hauptsächlich, keine Anleitungen.
- Die Variable buf
wird an zu vielen Stellen im Source benutzt. Können wir zumindest in Zukunft versuchen, auf sie zu verzichten? Mir ist nie sehr wohl, wen ich die irgendwo sehe.
wird an zu vielen Stellen im Source benutzt. Können wir zumindest in
Zukunft versuchen, auf sie zu verzichten? Mir ist nie sehr wohl, wen ich
die irgendwo sehe.
- Bibliotheken, module
Jedes Verzeichnis in common/ erzeugt eine Bibliothek. Je nach Bedarf muss aber nicht jeder Server die ganze Bibliothek linken (die ist eher was für den mapper), sondern kann die Files auch einzeln linken.
Jedes modul, item, attribut, usw. sollte eine Funktion zur Verfügung stellen, die seine typen initialisiert, also it_register respektive at_register o.ä. aufruft. Jede Biliothek hat ein File, das ihren Namen trägt (z.b. items.txt) mit einer eigenen init_-Funktion, die alle init_funktionen der enthaltenen objekte enthält. (init_items, init_attributes, usw).
Neue Files hinzufügen heißt also bitte, die Registrierung in den "bibliotheks-file" zu machen.
Jedes Verzeichnis in common/ erzeugt eine Bibliothek. Je nach Bedarf
muss aber nicht jeder Server die ganze Bibliothek linken (die ist eher
was für den mapper), sondern kann die Files auch einzeln linken. Jedes
modul, item, attribut, usw. sollte eine Funktion zur Verfügung stellen,
die seine typen initialisiert, also it_register respektive at_register
o.ä. aufruft. Jede Biliothek hat ein File, das ihren Namen trägt (z.b.
items.txt) mit einer eigenen init_-Funktion, die alle init_funktionen
der enthaltenen objekte enthält. (init_items, init_attributes, usw).
Neue Files hinzufügen heißt also bitte, die Registrierung in den
"bibliotheks-file" zu machen.
- KI
Beim Anblick des enums mit Rassen-Flags sieht man schnell, das die in mehrere Kategorien fallen. Eine davon ist die KI-Steuerung, und könnte man die vielleicht getrennt von den anderen speichern?
Beim Anblick des enums mit Rassen-Flags sieht man schnell, das die in
mehrere Kategorien fallen. Eine davon ist die KI-Steuerung, und könnte
man die vielleicht getrennt von den anderen speichern?
- Worüber man nachdenken sollte, ehe man etwas neues hinzufügt
90% aller Erweiterungen sind eigentlich optional. Ein Eressea ist z.B. auch ohne die Rasse Troll denkbar. Leider ist die rasse Troll an derart viele Stellen hartgecodet, das man Eressea ohne Trolle nie übersetzen könnte (Im Kampfsystem bekommen z.B. Trolle -1 beim Reitenbonus).
Immer drüber nachdenken, ob man hartcoden muß, oder ob es auch einen anderen Weg gibt (in diesem Fall z.B. ein at_skillmod attribut an der Rasse Troll).
90% aller Erweiterungen sind eigentlich optional. Ein Eressea ist z.B.
auch ohne die Rasse Troll denkbar. Leider ist die rasse Troll an derart
viele Stellen hartgecodet, das man Eressea ohne Trolle nie übersetzen
könnte (Im Kampfsystem bekommen z.B. Trolle -1 beim Reitenbonus). Immer
drüber nachdenken, ob man hartcoden muß, oder ob es auch einen anderen
Weg gibt (in diesem Fall z.B. ein at_skillmod attribut an der Rasse
Troll).
- RC_SPELL
Es gibt einen Zauber (Ferne Vision) der Einheiten vom Typ RC_SPELL erzeugt, aber 36 Stellen, an denen auf diesen Typ abgetestet werden muß (vielleicht sogar mehr?). Können wir das mal auf einen curse umstellen? Am besten in Kombination mit einem allgemeinen "diese Einheit/Region soll in den Report der PArtei x", das man dann auch für Spionage usw. benutzen kann, und das im Fall von Antimagie oder Zauberende durch einen Trigger am entsprechenden curse mit zerlegt wird?
Es gibt einen Zauber (Ferne Vision) der Einheiten vom Typ RC_SPELL
erzeugt, aber 36 Stellen, an denen auf diesen Typ abgetestet werden muß
(vielleicht sogar mehr?). Können wir das mal auf einen curse umstellen?
Am besten in Kombination mit einem allgemeinen "diese Einheit/Region
soll in den Report der PArtei x", das man dann auch für Spionage usw.
benutzen kann, und das im Fall von Antimagie oder Zauberende durch einen
Trigger am entsprechenden curse mit zerlegt wird?
- Wie komplex macht man einen Curse?
siehe vorangegangener Absatz. Generell gilt hier: Lieber zwei vielseitige Dinge machen, als ein unflexibles - der curse sollte lediglich der container seiin, der die wirkung aufrechterhält (das attribut an der region überwacht, und per trigger-funktion bei ende des curse oder antimagie entfernt). die eigentliche wirkung kann man in ein separates attribut stecken, dann ist sie auch in anderen kontexten als zauberei verwendbar (gebaüde oder items mit der gleichen wirkung, z.b.). Tests sollten so wenig wie möglich auf einen curse gehen (in fact, eigentlich nur bei der antimagie) sondern immer auf die wirkung (das attribut).
siehe vorangegangener Absatz. Generell gilt hier: Lieber zwei
vielseitige Dinge machen, als ein unflexibles - der curse sollte
lediglich der container seiin, der die wirkung aufrechterhält (das
attribut an der region überwacht, und per trigger-funktion bei ende des
curse oder antimagie entfernt). die eigentliche wirkung kann man in ein
separates attribut stecken, dann ist sie auch in anderen kontexten als
zauberei verwendbar (gebaüde oder items mit der gleichen wirkung, z.b.).
Tests sollten so wenig wie möglich auf einen curse gehen (in fact,
eigentlich nur bei der antimagie) sondern immer auf die wirkung (das
attribut).
- wie benenne ich Sourcedateien?
lang drüber nachgedacht, bin ich zum schluss gekommen: kleinbuchstaben, keien unterstriche. Es kann sich nie jemand merken, ob testplayer oder test_player jetzt richtig ist, und wir kommen sicher selten in die situation, das wir zwischen opium_bringen.c und opi_umbringen.c unterscheiden müssen.
lang drüber nachgedacht, bin ich zum schluss gekommen: kleinbuchstaben,
keien unterstriche. Es kann sich nie jemand merken, ob testplayer oder
test_player jetzt richtig ist, und wir kommen sicher selten in die
situation, das wir zwischen opium_bringen.c und opi_umbringen.c
unterscheiden müssen.
- wie benenne ich variablen?
da gilt das gleiceh wie bei den files, mit einer ausnahme: typspezifikation, also zum beispiel at_ für attributstypen, mit einem unterstrich. dann ist auch klar, was at_work ist: ein attribut, das was mit arbeit zu tun hat, keine boolean-variable die sagt ob man auf der arbeit ist.
da gilt das gleiceh wie bei den files, mit einer ausnahme:
typspezifikation, also zum beispiel at_ für attributstypen, mit einem
unterstrich. dann ist auch klar, was at_work ist: ein attribut, das was
mit arbeit zu tun hat, keine boolean-variable die sagt ob man auf der
arbeit ist.
- faction::units
Die Variable funktioniert und kann benutzt werden. folgendes:
@ -36,4 +76,6 @@ for (u=f->units;u;u=u->nextF) {}
und ja, es wird garantiert, das das funktioiniert, und regionsreihenfolge einhalten tut es auch. weshalb wahlloses erzeugen von einheiten per calloc und ohne createunit() aufruf schon seit längerem ein NoNo ist.
- buffer length
Namen von attributen, hashcodes für items, usw. sollten kurz sein. schliesslich landen sie im Datenfile. Eine Funktion, die sie einlädt, sollte mit 32 byte speicherbedarf rechnen.
Namen von attributen, hashcodes für items, usw. sollten kurz sein.
schliesslich landen sie im Datenfile. Eine Funktion, die sie einlädt,
sollte mit 32 byte speicherbedarf rechnen.