PAE - Bonusressourcen

[BoggyB]

Welcher? Von der Einheit? Joa, die sollten eigentlich alle gleich gut handeln können. Nebenbei ist's fies für die Keftion- und Gaulos-Civs, wenn die Dinger plötzlich veralten und durch das teurere, schwächere Handelsschiff ersetzt werden. Keftion und Gaulos als UU zum Handelsschiff?

Gute Frage - ich ging davon aus, Pie meint den XML-Wert iTradeMultiplier, der nutzlos ist, wenn die Einheit keine BtS-Handelsmission ausführen kann.
Keftion und Gaulos als Handelsschiff-UU, die zum selben Zeitpunkt wie jetzt kommt, gefällt mir Aber ergibt das auch Sinn, dass man Keftion und Gaulos auch im späten Spiel noch bauen kann?
Allerdings müsste man Keftion und Gaulos dann auch an das "Nationale Einheiten"-Limit binden, damit man nicht beliebig viele bauen kann, während jeder andere Spieler nur drei Handelsschiff gleichzeitig haben kann. Auch irgendwie doof

[Pie]

Nein, die bleiben so wie sie sind und sollen auch nicht mehr einbringen als Handelsschiffe, die vom technischen Standard schneller sein sollten. Ich wollte eigentlich nciht, das diese frühen Schiffe mehr einbringen (Gaulos: 6/15, Handelschiff 44/12). Ich dachte, zweiteres bringt mehr. Na egal. Der Vorteil ist sowieso, dass sie schon viel früher Seehandel betreiben können und somit mehr Gold scheffeln können als andere CIVs. Das soll Vorteil genug sein.

[Flunky]

Ich glaub, das Handelsschiff bringt ein bissl mehr Geld ein - aber die frühen Schiffe können kämpfen, Einheiten transportieren und handeln. Für weniger als ein Handelsschiff.

[Thorgal]

Wäre es vielleicht möglich, den Winzer irgendwie an ein lokales Traubenvorkommen zu koppeln? Ist doch auch seltsam, wenn ein Winzer ohne Weinberg gebaut werden kann.

Mit nem Python-Callback ginge das wahrscheinlich. Ob's das wert ist*, ist ne andere Frage.

*Schwer zu sagen, wie sehr das die Rundenzeiten beeinflusst. Ist keiner von den "schlimmen" Callbacks, die so häufig aufgerufen werden, dass man sie auf keinen Fall aktivieren sollte. Trotzdem würde er jedes Mal, wenn irgendwas für Gebäudebedingungen gecheckt wird, aufgerufen - kA, wie oft genau, müsste man nachsehen. Und das nur für ein Gebäude?
Andererseits: Man fragt ja direkt am Anfang des Callbacks ab, ob es um den Winzer geht und bricht sonst ab, der Rechenaufwand an den Stellen, an denen er nicht gebraucht wird, ist also wirklich minimal und nach dem Traitupdate, das ein paar Callbacks aktiviert hat, gab es auch keine Leistungseinbrüche (wobei sich natürlich auch schwer sagen lässt, dass jetzt durch das und das verursacht wurde).

Mir ist das hier nicht aus den Kopf gegangen und ich hab dazu noch eine Idee. Vorausgesetzt das Callback ist wirklich nicht so arg, wäre das eine Möglichkeit, das Kultivierungsfeature noch interessanter zu machen. Neben dem Winzer könnten noch alle anderen Gebäude, die auf Nahrungsressourcen aufbauen, von lokalen Vorkommen abhängig gemacht werden:

Winzer von Trauben.
Olivenpresse von Oliven.
Räucherhütte von Fisch, Kuh, Schaf oder Schwein.
Kornspeicher von Getreide.
Reisspeicher von Reis.
Brauerei von Getreide.

Bei allen Gebäuden würde das mMn Sinn machen, die an lokale Vorkommen zu koppeln. Schließlich bringt man z.B. ja keine Fische in eine fremde Stadt, um sie dort räuchern, sondern man produziert vor Ort. Auf die zwei Speicher trifft das zwar nicht ganz zu, aber dennoch braucht man Speicher zuallererst direkt vor Ort.

Der Effekt wäre dabei, dass diese Standardgebäude, die man bisher überall baut, nicht mehr so beliebig sind, sondern erst mithilfe der Kultivierung in den meisten Städten freigeschaltet werden, und dass die Kultivierung damit einen direkten Einfluss auf den Gebäudeplanung hätte (man muss erstmal Getreide vor Ort kultivieren und z.B. auch abwägen, ob man Oliven oder Trauben kultiviert). Zudem würde das zumindest ansatzweise auch die durch diese Gebäude eingrenzen und deren deutlich wertvoller machen (zumindest bis man im großen Stil kultiviert hat).

Im Anschluss wäre es dann noch interessant, den Getreidekarren (falls er denn überhaupt noch im Spiel ist) und seine möglichen Varianten erst mit diesen Gebäuden zum Bau freizugeben. Also dass man z.B. den Karren nur mit einem Kornspeicher bauen kann.

[Pie]

Gute Idee. Kannst du das testen, Boggy? Wie es mit der Rundenzeit wirkt?

Wegen Getreidekarren: stimmt. Vielleicht sollte der Getreidekarren ja doch drin bleiben. Aber nur als Überbringer von getrocknetem Getreide. Also nix Handel und nix Verbreitung. Lediglich zum Beschleunigen vom Stadtwachstum. Der Getreidekarren ist ja auch an kein Limit gebunden und den würd ich dann als Geschenk von Statthaltern und Vasallen beibehalten. Ein Händler war ja blöd.

[Thorgal]

Das war ja auch mal der Ausgangspunkt für die Einheit. Vielleicht fällt uns da ja auch noch was ein, das besser einzubinden und das historische Vorbild Getreidelieferungen aus den Provinzen in die HS abzubilden.

Vielleicht als Quest. Hungersnot in der HS (die Stadt produziert keine Nahrung mehr). Liefere x Getreidekarren aus den Provinzen in die HS. Belohnung: Die HS wächst um 1 und produziert wieder Nahrung.
Oder auch ohne Hungersnot: Die Einwohner der HS verlangen nach Brot. x unzufriedene Bürger in der HS bis die Quest erfüllt ist.

Nur stellt sich hier die Frage, ob die Lieferungen überhaupt zählbar sind.

[BoggyB]

Jo, ich guck mal.

Hab jetzt nochmal probiert, alles in eine Klasse zu packen. Das steht am Anfang:

class Trade:
    def __init__(self):  
        self.lBonusNoTrade = [ gc.getInfoTypeForString("BONUS_CELTIC"), gc.getInfoTypeForString("BONUS_ROMAN"), gc.getInfoTypeForString("BONUS_NUMID"),
                      gc.getInfoTypeForString("BONUS_NUBIA"), gc.getInfoTypeForString("BONUS_GREEK"), gc.getInfoTypeForString("BONUS_PERSIA"),
                      gc.getInfoTypeForString("BONUS_GERMAN"), gc.getInfoTypeForString("BONUS_INDIA"), gc.getInfoTypeForString("BONUS_BALEAREN"),
                      gc.getInfoTypeForString("BONUS_TEUTONEN"), gc.getInfoTypeForString("BONUS_BAKTRIEN"), gc.getInfoTypeForString("BONUS_KRETA"),
                      gc.getInfoTypeForString("BONUS_KILIKIEN"), gc.getInfoTypeForString("BONUS_MARS"), gc.getInfoTypeForString("BONUS_THRAKIEN")]
        self.lCorn = [
            gc.getInfoTypeForString("BONUS_WHEAT"),
            gc.getInfoTypeForString("BONUS_GERSTE"),
            gc.getInfoTypeForString("BONUS_HAFER"),
            gc.getInfoTypeForString("BONUS_ROGGEN"),
            gc.getInfoTypeForString("BONUS_HIRSE"),
            gc.getInfoTypeForString("BONUS_RICE")
        ]
        self.lCattle = [
            gc.getInfoTypeForString("BONUS_COW"),
            gc.getInfoTypeForString("BONUS_PIG"),
            gc.getInfoTypeForString("BONUS_SHEEP")
        ]
        self.lSpice = [
            gc.getInfoTypeForString("BONUS_OLIVES"),
            gc.getInfoTypeForString("BONUS_DATTELN")
        ]
        self.lCamel = [ gc.getInfoTypeForString("BONUS_CAMEL") ] 

Aber wenn ich die Listen ingame ausgeben, steht immer nur die entsprechende Anzahl -1 drinnen
Vielleicht ist zu dem Zeitpunkt, zu dem initialisiert wird, das XML noch nicht geladen und getInfoTypeForString() funktioniert noch nicht? Aber was tu ich dagegen?

[Pie]

Stimmt!

mach statt gc -> CyGlobalContext()
Oder du schreibst den import nach dem gc = CyGlobalContext() im EventManager.

[BoggyB]

Stimmt!

mach statt gc -> CyGlobalContext()
Oder du schreibst den import nach dem gc = CyGlobalContext() im EventManager.

Äh, zwei Zeilen über "class Trade" steht bei mir natürlich auch schon gc = CyGlobalContext() (dachte, das lass ich im Post weg, weil's mir nur um die __init__-Methode ging), das ändert also nix.

[Pie]

Und wenn du lBonusNoTrade gar nicht erst in der class lädst, sondern schon ausserhalb? isses dann immer noch leer?

Zur Handelsstraßenerzeugung ist mir gestern eingefallen, wie ich das berechnen kann und werde: mit CyMap.getPathDistance(). Damit kann man schonmal was anfangen!
Ich schreib die Funktion mal schnell (mit all seinen Besonderheiten).
Achja, und bereite mir eine Variable für den Händler vor (ScriptData) für x,y beim Ausladen eines Händlers aus dem Schiff (zB plotUnloaded). Sollte bei onUnitMove gehen, wo du beim OldPlot nach isWater prüfst. (nur beim Händler natürlich).

[BoggyB]

Achso, das Problem ist inzwischen gelöst, hatte das auch im Python-Thread gestellt. Benutzt jetzt ne statische init()-Methode, die ich in onLoadGame (bzw. onStartGame - muss noch ausprobieren, ob onLoadGame auch bei nem neuen Spielstart aufgerufen wird) aufrufe.
Meinst du nicht, die vorimplentierte SDK-Lösung ist da effizienter? Aber ich will dich nicht aufhalten (Meinst du calculatePathDistance()? get gibt's nicht)

Davon abgesehen muss ich das jetzt endlich mal fertig machen, ist es ja eh schon fast

[Pie]

Achja, das heißt calculatePathDistance.
Genau das mein ich. Solang ich noch nicht im SDK handfest bin und angefangen hab, mach ich es im python. Sonst vergess ichs

Checke aber bitte auch, dass deine Programmierug auch im Multiplayermodus geht! Also alle Ausführungen im EventManager (denk ich). Oder hast du dafür keine Möglichkeit?

[BoggyB]

Alles läuft über den EventManager und wenn im Interface was passiert, wird das mit onModNetMessage an den EventManager geschickt. Sollte eigentlich funktionieren. Ich wollte es auf jeden Fall auch auf OOS testen, denke aber, ich lad's vorher schon hoch, damit andere auch testen können.
Ich hab jetzt auch mal alles ausgemistet und denke, ich bin fertig Nur noch ne Kleinigkeit. Dann werd ich nochmal sehen, was ich abseits des Handels-/Kultivierungsfeatures noch reinpacken kann (z.B. Thorgals Vorschlag mit den Ressibedingungen bei Gebäuden) und vielleicht kann ich es morgen hochladen

Achtung Spoiler:

Empirisch gesehen sollte mir aber niemand mehr irgendwas glauben, wenn ich sage, ich bin bis zu irgendeinem Zeitpunkt damit fertig

[Flunky]

Ich denk die Ressi-Gebäude-Interaktion können wir jetzt noch besser umsetzen. Also dass z.B. ne Bronzeschmiede nur Bronze produziert wenn Kupfer und Zinn oder Blei vorhanden sind.

[BoggyB]

Statt das Gebäude abzubauen, wird halt kein Bronze mehr produziert, wenn die Ressi fehlt

Wo wir grad bei Thorgals Vorschlag (z.B. Kornspeicher nur baubar, wenn Getreide in der Nähe) waren: Das tut man doch auch besser ins SDK, oder? Ist ja ne Eigenschaft, die man für viele Gebäude gebrauchen kann, also besser ins XML damit. Dann bau ich das jetzt nicht in den Python-Callback ein.