server/doc/coding.txt

Was ist das hier?
Dieses File ist eine Sammlung von kleinen Artikeln zum Code -
Designgedanken, haupts<74>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.

- 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<72>gung stellen,
die seine typen initialisiert, also it_register respektive at_register
o.<2E>. aufruft. Jede Biliothek hat ein File, das ihren Namen tr<74>gt (z.b.
items.txt) mit einer eigenen init_-Funktion, die alle init_funktionen
der enthaltenen objekte enth<74>lt. (init_items, init_attributes, usw).
Neue Files hinzuf<75>gen hei<65>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?

- Wor<6F>ber man nachdenken sollte, ehe man etwas neues hinzuf<75>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 <20>bersetzen
k<EFBFBD>nnte (Im Kampfsystem bekommen z.B. Trolle -1 beim Reitenbonus).  Immer
dr<EFBFBD>ber nachdenken, ob man hartcoden mu<6D>, 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<6D>
(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<72>lt (das
attribut an der region <20>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<62>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<64>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.

- faction::units
Die Variable funktioniert und kann benutzt werden. folgendes:
for (r=regions;r;r=r->next) for (u=r->units;u;u=u->next) if (u->faction==f) {}
schreibt sich viel einfacher so:
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<6E>dt,
sollte mit 32 byte speicherbedarf rechnen.

- FL_MARK und FL_DH:
Der unterschied zwischen diesen beiden Flags ist:
FL_DH sollte man vor der Benutzung auf einen Wert setzen, den man coraussetzt
(man kriegt keinen wert garanteirt).
FL_MARK ist immer 0. jede routine die es setzt, muss es am ende wieder auf 0
zur<EFBFBD>cksetzen. code-beispiel ist z.b. die SORTIERE-funktion.