Handel - ein Überblick

Der Handel ist wichtig. Er wird oft auch von erfahrenen Eressea-Spielern unterschätzt. Er ist eine Silberdruckmaschine. Seine Einnahmen übersteigen regelmässig die Einkunftsmöglichkeiten aus Steuern und Unterhaltung, bis die Burgen gut ausgebaut sind.

Zentrale Figur des Handels ist der Händler (// script Handeln). Er fordert jede Runde Waren zum Verkauf an und bezieht sie direkt von den Transportern und Depots. Sind die Waren in der Region nicht verfügbar, versucht der TransportManger, diesen Bedarf überregional zu decken.

Als besondere Parameter sind für den Händler "Vorrat" und "Prognose" zu beachten, die normalerweise für die ganze Insel bzw den ganzen Report per SetScripterOption gesetzt werden. Der Prognose-Parameter sollte bei etablierten Inseln höher gesetzt werden, damit die Händler für weitere Runden im Vorraus Waren anfordern. Dies lastet die Transporter besser aus und verbessert die allgemeine Verteilung der Waren, sodaß selbst kleine Regionen "hinter" großen Regionen (gesehen von einer Warenquelle aus) häufiger Waren erhalten.

Der normale Händler ermittelt für sein Gebiet (TradeArea) den Bedarf mit einer einfachen Überschußrechnung: Wieviel kann von einem Gut gekauft und wieviel verkauft werden - daraus ergibt sich die Einkaufsmenge aller Händler des Gebietes. Soll aus script-fremden Gründen eine manuelle Menge festgelegt werden, dient dazu die Option menge.
Jedoch kann die Rechnung weiter beeinflusst werden, insbesondere von Vorräten. Vorräte werden meist für eine manuell eingerichtete Handelsrouten in andere Gebiete oder Inseln angelegt. Bei ihnen wird festgeleget, welche Menge eines Gutes pro Runde zusätzlich im Gebiet gekauft werden soll, um einen angegebenen Vorrat zu erreichen. Diese Menge erhöht natürlich die von den Händlern einzukaufende Menge.
Sollte das Transportsystem versagen ist eine Situation denkbar, in der die Handler weiter einkaufen aber die Güter nicht transprotiert werden. Übersteigt die Menge im Depot das Dreifache des geplanten Regionseinkaufes, so gilt das Lager als in der Region als voll und es wird nicht mehr überkauft. Es kommt somit auch dann zu keiner "Blasenbildung".
Oft soll aber auch ein gewisser Puffer im System etabliert werden, quasi immer ein wenig mehr eingekauft werden als gebraucht. Dies kann ab Version 0.48 mit dem TA-Vorratsfaktor eingestellt werden (über SetScripterOptions). Liegt der bei 150%, werden Vorräte in den Regionen erst berücksichtigt, wenn sie 150% des wöchentlichen gebietsweiten Einkaufes übersteigen.

ToDo: maximaler Überkauf, TradeAreaConnections (erledigt, s.u.)

Fiete, 22.12.2010

Handel zwischen Inseln

Das regionale Grundkonzept des Handels in FFTools2 ist nicht die Insel, sondern das TradeArea (TA). Im Normalfall entspricht aber jede Insel auch genau einem Tradearea. In exotischen Fällen (Große Insel mit sehr schmalem Verbindungssteg zwischen beiden Teilen, Insel durch unfreundliches Gebiet unterbrochen bzw geteilt) können auch mehrere TAs auf einer Insel eingerichtet werden. (Sie dazu auch entsprechende Option beim Händler)

Insofern müsste die Überschrift hier eigentlich heißen: Handel zwischen TradeAreas. Automatische Transporter werden grundsätzlich nur in ihrem TA aktiv. der Handel zwischen TAs ist vordefiniert auf Schiffsverkehr zwischen festgelegten Regionen und sogar anhand festgelegter Einheitennummern. Die benötigten Schritte werden hier zusammenfassend dargestellt:

1. Verbindung definieren
Pro Region gibt es stationäre Einheiten, sei es der Wahrnehmer, ein Tarner, welche als Referenz für eine feste Verbindung zu einem TA genutzt werden können. Um die Warenströme ein wenig auseinander zu halten, empfiehlt es sich, nicht das Depot oder den Händler dafür zu nutzen. Denn die für die Verbindung zwischen TAs, den TradeAreaConnections (TAC), genutzten Einheiten werden benutzt, um die notwendigen Vorräte für die Handelsverbindung anzulegen. Dazu werden ganz klassische Scriptkommandos automatisch erzeugt, hauptsächlich natürlich der Vorratsbefehl.
Die eigentliche TAC wird zwischen 2 Einheiten definiert, die sich permanent in den jeweiligen anlandefähigen Regionen der TAs aufhalten. Einer der beiden Einheiten wird der setTradeConnection-Befehl erteilt, in welchem auf die andere Einheit als Zieleinheit verwiesen wird. Welcher der beiden Einheiten den Befehl erhält, ist völlig egal, nur muss jeweils die andere Einheit als Ziel genannt werden.

// script setTradeAreaConnection Ziel=abcd Name=Insel1-Insel2

Der genutzte Name ist dabei nicht Makulatur, sondern als Referenz für diese TAC bei weiteren Befehlen zu benutzen. Er sollte daher eindeutig und tippfehlerunanfällig sein.

2. Auswirkungen einer Installierten TAC
Bei beiden genutzten Einheiten erscheinen in den Befehlskommentaren entsprechende Hinweise, dass die TAC erfolgreich eingerichtet wurde:

; Verbindung zum TA: Rigel(Name: Orion-Rigel)

Recht früh im Scriptablauf analysiert FFTools2 die Versorgungssituation der TAs insgesammt, derzeit lediglich in Hinsicht auf das Angebot und die Nachfrage nach Handelsgütern. Dazu werden pro TA alle mit TACs verknüpften weiteren TAs berücksichtigt und versucht, auftretende Unterversorgung in einem TA durch Überschüsse in einem verbundenen TA auszugleichen. Dabei wird nicht das komplette Netzwerk untersucht, sondern lediglich die direkten Verbindungen genutzt. Ein Handelsausgleich zwischen 2 TAs über ein drittes Hinweg ist nicht vorgesehen, eine direkte Verbindung ist notwendig. Sehr wohl wird aber bei der Optimierung der Abstand der Regionen berücksichtigt und die daraus resultierende Anzahl von Runden, die für einen Transportweg benötigt werden. Dabei werden übrigends 6 Regionen/Runde als Geschwindigkeit angenommen.
Überschüsse ergeben sich aus tatsächlich vorhandenen sehr großen Lagerbeständen (bei Depots) und nicht genutztem Überkaufpotential. Die Ausgleichsrechnung liefert den Transportbedarf zwischen den TAs pro Runde. In einer ersten Übersicht werden die aktuellen Überschüsse und Bedürfnisse der angeschlossenen TAs zusammengefasst:

; Weihrauch (925)<->: Rigel(-183) Delta(1660) I2F(1348)
; Seide (11411)<->: Rigel(-183) Delta(-346) I2F(-203)
; Öl (2251)<->: Rigel(-183) Delta(7375) I2F(1302)
; Myrrhe (3245)<->: Rigel(14712) Delta(2729) I2F(1536)
; Juwel (-315)<->: Rigel(73191) Delta(-97) I2F(1446)
; Gewürz (4461)<->: Rigel(32100) Delta(299) I2F(-203)
; Balsam (-315)<->: Rigel(5402) Delta(-346) I2F(-203)

Negative Zahlen stellen Bedarf dar, positive Zahlen stellen einen Überschuss dar. Mit dem aktuellen TA ("Orion") sind 3 weitere TAs verknüpft: Rigel, Delta und I2F. Ganz Links ist die Versorgungssituation des aktuellen TAs dargestellt, Orion hat ausser bei Juwelen und Balsam eine Überschusssituation. Das Ergebnis nach der Optimierung beinhaltet dann ausschliesslich die resultierenden Warenströme, wiederum pro Runde berechnet:

; Weihrauch (742)<->: ->Rigel:183
; Seide (10882)<->: ->Rigel:183 ->Delta:346
; Öl (2068)<->: ->Rigel:183
; Myrrhe (3245)<->:
; Juwel (0)<->: <-Rigel:315
; Gewürz (4258)<->: ->I2F:203
; Balsam (0)<->: <-Rigel:315

Ganz Links sind die resultierenden Versorgungsstände nach dem berechneten Transport dargestellt - einige Überschusse wurden kleiner, die Mängel werden durch Lieferungen anderer TAs ausgeglichen (haben jetzt den Wert 0). So erhält Orion von Rigel pro Runde 315 Juwelen und 315 Balsam, gibt aber an Rigel je 183 Seide, Weihrauch und Öl ab. Diese Zahlen spiegeln sich auch direkt in den angelegten Vorräten wieder. Die Information dazu hat auch die genutzte Einheit in ihren Befehlen:

; TAC: Vorratsscript hinzugefügt: [source=TAC, Ware=Öl, Summe=732, proRunde=183, prio=50, prioTM=99]
; TAC: Vorratsscript hinzugefügt: [source=TAC, Ware=Weihrauch, Summe=732, proRunde=183, prio=50, prioTM=99]
; TAC: Vorratsscript hinzugefügt: [source=TAC, Ware=Seide, Summe=732, proRunde=183, prio=50, prioTM=99]

Die TACs nach Delta und I2F nutzen ganz offensichtlich andere Einheiten als Referenz, denn ein Vorrat für Gewürz wird bei dieser Einheit nicht angelegt. Die Höhe des Mehreinkaufes pro Runde entspricht genau der Liefermenge (183), die Gesamtsumme des Vorrates entspricht in diesem Fall dem 4-fachen der Transportmenge pro Runde, ein derzeit fester Schlüssel, der aber bei steigender Entfernung zwischen den TACs auch steigt. Die Priorität, die dem Transportmanager (TM) mitgeteilt wurde, ist fixiert auf 99. Sie liegt damit knapp unterhalb der Untergrenze des Standardbereiches für Handelstransporte, der ja 700-100 beträgt. Dies bewirkt, dass Waren erst dann für den Handel zwischen den TAs transportiert werden, wenn der Transportbedarf innerhalb des TAs gedeckt ist.
Im TA Orion werden nun die Händler systematisch 183 mehr Öl, Weihrauch und Seide einkaufen und diese Mehrmengen werden ihren Weg zu unserer Einheit finden, denn bei dieser ist der entsprechende Vorrat definiert. Doch wie kommen die jetzt auf ein Schiff?

3. Ein Schiff der TAC zuordnen
Ein Schiff muss explizit einer TAC zugeordnet werden, damit es Warenströme dieser TAC transportieren kann. Dabei ist der Kapitän selbst für die Route des Schiffes verantwortlich, denn so können bestimmte Wege und Zwischenstationen definiert werden. Er wird nur jeweils in den Zielregionen einer TAC Güter gemäß der obigen Optimierung anfordern, in anderen Regionen wird er lediglich seine Ladung zu bewahren versuchen (mit geringer Prio). Sollte also in einer als Zwischenstation genutzen Region Bedarf an seinen transportierten Waren bestehen, wird er sie auch abgeben.
Die Funktionalität der Warenübernahme einer TAC wird durch folgenden Befehl eines Kapitäns aktiviert:

// script onTradeAreaConnection name=Orion-Rigel

Mehr ist es nicht. Damit wird dieses Schiff genau der benannten TAC zugeordnet. Entscheidend ist weiterhin, wieviel Gewicht dieses Schiff für die TAC reservieren soll. Dort sei auf den Befehl setKapa verwiesen, der dies genau festlegt. Der Standardfall (Kapitän ist allein auf dem Schiff und hat keine mauellen Sonderaufträge) wird natürlich so aussehen:

// script setKapa gewicht=schiff

Damit wird die gesamte freie Kapazität des Schiffes als Beladungsgrenze des Kapitäns genutzt - zuerst wird er sie für Lohn einsetzen, dann vielleicht noch für Material, anschliessend bleibt Raum für die TAC. Eine entsprechende Rückmeldung findet sich in den Befehlen des Kapitäns:

; SetKapa: erkannte Kapazität: 2970 GE
; setKapa Schiff auf: 3000 GE

Damit der Kapitän errechnen kann, wieviel des Transportbedarfes auf ihn entfällt, berücksichtigt er weitere Schiffe, die dieser TAC zugeordnet sind. Sollte er das einzige Schiff auf dieser TAC führen, würde sich ein Bild ähnlich diesem ergeben:

; TAC: 630 Balsam nach Orion mit Prio 51 angefordert
; TAC: 630 Juwel nach Orion mit Prio 51 angefordert
; TAC: Anteil der Unit nach Kapa:100,00%
; GE insgesammt benötigt: 2928 (1464GE -> Rigel,945GE -> Orion; Dist: 1)
; Summe Transporter 2970GE: Mannen (kjb8) in Wassernase (-51, 33)(2970)

(Das Schiff befindet sich derzeit in der Hafenregion auf Rigel (s.o.), es sind 315 Balsam und Juwel pro Runde zu transportieren. Bei einer Fahrdauer von 1 Runde pro Richtung ist das Schiff alle 2 Wochen vor Ort und muss somit 630 Stück der Güter laden.)
Die benötigten und verfügbaren Gewichtseinheiten sind aufgeführt und somit ist ersichtlich, ob genügend Schiffe zugeteilt worden sind, oder zu viel Schiffsraum existiert.
In den jeweiligen Zielregionen fordert der Kapitän die berechneten Summen mit prio 51 an und entnimmt somit den Vorräten die gelagerten Mengen - sofern die Waren da sind. Er wird auch mit weniger Ladung, ja sogar komplett ohne Ladung losfahren - ein "Warten auf Ladung" ist nicht implementiert.

Die oben angesprochene notwendige Reiseroute des Schiffes wird üblicherweise mit genau diesem Befehl festgelegt, und so ergibt sich als Standard-Befehlssatz eines Kapitäns eines Schiffes auf einer TAC:

// script material
// script Lohn 3
// script setKapa gewicht=schiff
// script onTradeAreaConnection name=Orion-Rigel
// script ROUTE -48,30 -51,33 

(wobei Material hochgradig optional ist, nur "meine" Matrosen haben Waffentalent und tragen Ausrüstung..., und Lohn muss angepasst werden, bei weiten Strecken sollte der Wert ruhig höher sein)

Der mithin grösste Unterschied im Handel zwischen TAs zum Handel innerhalb eines TAs ist derzeit, dass die Transportrouten für TACs manuell definiert und festgelegt werden. Automatische Transporter bewegen sich innerhalb ihres TAs komplett frei und suchen sich ihre Be- und Entladestellen selber - soweit ist der Handel zwischen TAs noch nicht.

4. Manuell MEHR über eine TAC transportieren
Bisher beschränkt sich das automatische Beladen auf Handelswaren. Manuell ist aber auch die Ausweitung auf andere Güter möglich. Sollen z.B. Kräuter (in der Itemgroup Kraut zusammengefasst) mit transportiert werden, so muss eine Einheit manuell die Kräuter anfordern und sammeln und der TAC muss dieser zusätzliche Transportaufwand mitgeteilt werden, natürlich mit Art, Menge und Prio:

// script Vorrat Ware=Kraut menge=100000 prio=110
// script UseTradeAreaConnection name=Orion-Rigel Ware=Kraut Menge=10000 prio=120

Die mit dem Vorratsscript gesammelten Waren werden dann mit Hilfe der Schiffe auf der TAC "Orion-Rigel" abtransportiert. Die Reihenfolge der Berücksichtigung der Waren geschieht wie üblich nach Priorität, wobei alle Waren der automatischen Vorratsscripte mit Prio 51 angefordert werden. (Die Vorräte selbst fordern regionsintern mit 50 an, regionsextern über den TM mit 99.) Der Kapitän meldet die zusätzliche Berücksichtigung spartanisch mit folgender Zeile:

; TAC-Usage: 10000 Kraut nach Rigel mit Prio 120 angefordert

Es sei nochmal darauf hingewiesen, dass dem Kapitän lediglich der Name der TAC und die Reiseroute sowie die Gewichtsbeschränkung "mitgegeben" werden muss. Die Inhalte der TAC werden aus der Optimierung des Handels zwischen des TAs und ggf manuellen "Mitgaben" mittels UseTradeAreaConnection generiert - nicht per direkten Befehlen beim Kapitän
(Natürlich können dem Kapitän zusätzliche Befehle inkl Requests erteilt werden, diese werden auch innerhalb des normalen Warenpools berücksichtigt.)

5. Zusammenfassung
Die Gelddruckmaschine Handel kann über die Grenzen von TAs hinaus installiert werden. Mit setTradeAreaConnection werden Verbindungen fest definiert, die von Kapitänen mit onTradeAreaConnection genutzt werden. Zusätzliche Transporte können mit useTradeAreaConnection hinzugefügt werden. Ergebnis ist ein funktionierender Warenaustausch zwischen den TAs.

Fiete, 31.03.2012