neue funktion is_migrant(unit*)

noch mit krötenhack

src/common/gamecode/study.c

@@ -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);

src/doc/coding.txt

@@ -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.