Neue Skins für Gebäude, Ressourcen und Terrain

[Pie]

Nö, der braune Flusssumpf geht ja nur bei Flüssen und dann is das wieder ein Feature, was nur Verwirrung auslöst.
Sumpf kann ja jetzt nun auch ohne Flüssen auf der Karte sein. Das ist schon gut, weil fast ganz Germanien angeblich sumpfiges Gelände war.

Nur +1 Gesundheit für den Bewässerungskanal fänd ich am besten. Wenn ich am SDK bin, möcht ich ja sowieso 2 pro Typ pro Pop als Anforderung haben. Da könnt ich mir auch vorstellen, dass Bewässerungskanäle sogar +2 Gesundheit geben.
Diese Bewässerungskanäle sollen auch was kosten und sollen auch kaputt gemacht werden können. Das wäre dann bei Ploteigenschaften sehr kompliziert das überall zu berücksichtigen (Stadteroberung, Naturkatas).

Winzer: Stimmt. Das ist noch ein altes lustiges Ur-Feature, das kann mit dem neuen Verbreitungsfeature natürlich weggemacht werden. Ich hoffe nur, dass die Griechen dann nicht schon 2000 v. Chr. Wein haben... aber das werden wir ja sehn.

Wein vs. Trauben: Nunja, Wein kann man handeln ohne dass der Gegenpart dann gleich selber einen produzieren kann. Ich würds so lassen.

[BoggyB]

Nö, der braune Flusssumpf geht ja nur bei Flüssen und dann is das wieder ein Feature, was nur Verwirrung auslöst.
Sumpf kann ja jetzt nun auch ohne Flüssen auf der Karte sein. Das ist schon gut, weil fast ganz Germanien angeblich sumpfiges Gelände war.

Ist halt ne ganz hübsche Matsch-Grafik, find ich.

Nur +1 Gesundheit für den Bewässerungskanal fänd ich am besten. Wenn ich am SDK bin, möcht ich ja sowieso 2 pro Typ pro Pop als Anforderung haben. Da könnt ich mir auch vorstellen, dass Bewässerungskanäle sogar +2 Gesundheit geben.
Diese Bewässerungskanäle sollen auch was kosten und sollen auch kaputt gemacht werden können. Das wäre dann bei Ploteigenschaften sehr kompliziert das überall zu berücksichtigen (Stadteroberung, Naturkatas).

Winzer: Stimmt. Das ist noch ein altes lustiges Ur-Feature, das kann mit dem neuen Verbreitungsfeature natürlich weggemacht werden. Ich hoffe nur, dass die Griechen dann nicht schon 2000 v. Chr. Wein haben... aber das werden wir ja sehn.

Wein vs. Trauben: Nunja, Wein kann man handeln ohne dass der Gegenpart dann gleich selber einen produzieren kann. Ich würds so lassen.

Also:
Bewässerungskanäle haben gar keinen Python-Effekt mehr.
Kanalisationen verwandeln Sumpf in Grasland.
Winzer bleibt im XML wie jetzt, erzeugt aber keine Trauben mehr.
Trauben fallen unter der Kategorie Getreide ins Verbreitungsfeature (die bringen ja auch +3 und es wär ziemlich heftig, wenn man in jeder Stadt einmal Trauben, einmal Vieh und einmal Getreide verbreiten könnte). Können nur auf Hügeln verbreitet werden (sonst noch Bedingungen? Nicht zu viel Ebene drumrum?).

Bei der Traubenverbreitung stört mich im Moment eh, dass man (wenn man selbst der ursprüngliche Traubenbesitzer im Osten ist) nicht wirklich einen Anreiz hat, die Trauben zu verkaufen, weil man dem Gegner damit ja die mächtige Möglichkeit gibt, zusätzlich zum Verbreitungsfeature in jeder Stadt (mit 50/50 Chance) einmal Trauben zu verbreiten. Wenn die Trauben ins Verbreitungsfeature fallen und mit anderer Nahrung konkurrieren, ist das weitaus weniger mächtig und man ist auch eher gewillt, mal mit Trauben zu handeln bzw. der Gegner kann mit seinem Händler einfach zu mir fahren und sich die Trauben kaufen

[Flunky]

Wein vs. Trauben: Nunja, Wein kann man handeln ohne dass der Gegenpart dann gleich selber einen produzieren kann. Ich würds so lassen.

Oliven vs. Olivenöl dito. Aktuell kann man sich Olivenöl mit dem Bildnis einer Olive einkaufen und so Olivenbäume pflanzen^^

[Pie]

Boggy:

Flunky: stimmt eigentlich. Müsste ich genauso handhaben wie Trauben. Naja, wenn ich jetzt wieder ein paar Icons frei hab, könnt ich das machen.
Boggy: BONUS_OLIVES wird dann zur Olive (kultivierbar). Olivenöl würde dann neu dazukommen.

[Flunky]

Für die einheitliche Umsetzung würd ich halt Plotressourcen machen (Olivenbäume, Weinreben, Cyperus Papyrus, Spinnerraupen, Färberwaid, ...),
die mit einer passenden Modernisierung (Ölmühle, Winzer, Papyruswerkstatt, Plantage, Plantage, ...)
zu handelbaren Ressourcen (Olivenöl, Wein, Papyrus, Wildseide, Färbemittel, ...) werden.

Wenn man dann Wein (etc.) verbreiten will, muss der Händler schon selbst zu den Reben fahren und welche mitgehen lassen. Das kann gegen Geld bei hinreichenden Beziehungen möglich sein, oder als feindlicher Akt im Krieg. Oliven, Wein und Waid kann verbreitbar sein. Papyrus und die Schmetterlinge eher nicht.

https://de.wikipedia.org/wiki/Koische_Seide

https://de.wikipedia.org/wiki/Seide#Anf.C3.A4nge]Schon[/url] die alte Indus-Zivilisation (etwa 2800 bis 1800 v. Chr.) [...] kannte die Seide. Durch genaue Untersuchungen der Seidenstruktur von archäologischen Funden wurde festgestellt, dass man zur Seidenproduktion im Indus-Gebiet den Seidenspinner der Gattung Antheraea benutzte. Es handelt sich hier um eine sogenannte wilde Seide.

Ein Handel über die Seidenstraße setzte erst im 2. Jahrhundert n. Chr. verstärkt ein. Der Beginn der Seidenstraße wird oft mit ca. 100 v. Chr. angegeben.

Die Seidenstraße erst spät? Mit einer Tech, die die Wildseide veralten lässt? Und als Ertrag liefert das Weltwunder x chinesische Seidenressourcen, wie der Broadway in BtS.

[Pie]

Die Seidenstraße als Projekt kommt eh weg. Das werden nun passiv die Händler machen. Achja, genaue Berechnungen wie, fehlt uns noch, oder Boggy?

[Flunky]

Mhm, nach China kommt man aber (noch) nicht.

[Pie]

Stimmt... ich hab auch mal kurz in mein neues fettes Buch geworfen und muss gerade lesen, dass diese Handelswege vor 600 v. Chr im Mesoland und dann die Königsstraße Persiens eigentlich der Vorläufer der Seidenstrasse sind.... oha. Kommt die spät

Aber egal. Meine Schmöker über Legendäre Handelsrouten, Weihrauchstraße, Bernsteinstraße liegen noch zum Lesen bereit....
Handelsposten werden aber auf jeden Fall ohne dem Projekt baubar sein. Ob ich die Seidenstraße als Projekt drin lasse, weiß ich noch nicht. Eher als Quest: Errichte eine Handelsstraße von Stadt X zu Stadt Y (beide liegen am anderen Ende des Kontinents ), beispielsweise (mit dem Video als Abspann).

[BoggyB]

Achja, genaue Berechnungen wie, fehlt uns noch, oder Boggy?

Ja. Ich bin mir auch gar nicht sicher, ob Civ schon Methoden zur Verfügung stellt, die einem den kürzesten Pfad (auf diesem sollte ja die Handelsstraße verlaufen) liefern. Auf jeden Fall muss es ja so was für die Wegberechnung von Einheiten geben, wenn man dabei noch erhöhte Fortbewegungskosten in Wäldern, Hügeln etc. ignorieren könnte (tun Straßen ja auch), wär's ideal.
In BASE haben (oder hatten) die Araber oder so ne Civeigenschaft, dass neu gegründete Städte sofort ne Straßenanbindung erhalten. Da könnte man ja vielleicht mal nachfragen (unsere Straße soll natürlich Stück für Stück entstehen).

Da wir ja eh schon fadenübergreifend diskutieren , wäre auch noch zu klären, ob Ressis an Civs verkauft werden können, die Ressi schon haben. Flunky war dafür (mit einer Abstufung des Verkaufspreises nach nicht vorhanden/im Handelsnetz vorhanden/in Nähe der Stadt vorhanden) und ich bin mir irgendwie nicht mehr sicher Entscheide du. Wenn man Ressis auch noch in Städten, die die Ressi schon haben, verkaufen könnte, hätte das den Vorteil, dass man einen versehentlichen Kauf einfach korrigieren kann, der Verkaufspreis sollte dabei so groß wie der Einkaufspreis sein. Am technisch einfachsten wär es dann, wenn das in jeder Stadt, die diese Ressi schon im Handelsnetz hat (egal ob in unmittelbarer Nähe oder nicht), so wäre - dann könnte man es sich nämlich sparen, die Ursprungsciv einer Ressi zu speichern, denn wenn man in Städten, die die Ressi im Handelsnetz haben, sowieso nicht (mit Gewinn) verkaufen kann, dann sind alle Städte der Civ, bei der man die Ressi gekauft hat, automatisch "gesperrt".

[Flunky]

Natürlich gibt's diese Methoden^^ Aber k/A ob in Python sichtbar. Ist jedenfalls als A* implementiert, also garnet mal so schlecht^^

[Ramkhamhaeng]

Laut der berühmten Pythonapi-Seite gibt es dafür generatePath( from, to, ...)

[Thorgal]

Handelsposten werden aber auf jeden Fall ohne dem Projekt baubar sein.

Damit wird die Tech, die Handelsposten freischaltet einer der zentralsten Techs des frühen Techbaums. Vielleicht wäre der Handelposten dann auch besser bei einer zentralen Tech wie Warenhandel aufgehoben, anstatt ihn in der Sackgassentech Arithmetik zu verstecken.

Noch ne Idee: Der Handelsposten könnte auch zur Bedingung für den Bau von Händlern werden. Würd doch passen.

[Pie]

Stimmt

[BoggyB]

Natürlich gibt's diese Methoden^^ Aber k/A ob in Python sichtbar. Ist jedenfalls als A* implementiert, also garnet mal so schlecht^^

Laut der berühmten Pythonapi-Seite gibt es dafür generatePath( from, to, ...)

Aber wie nutzen wir das jetzt? generatePath() gibt ja erst mal nur nen Bool zurück, ob ein Pfad zwischen den beiden Plots möglich ist. Wie kommt man jetzt in Python an den Pfad ran? Kann man dafür überhaupt diese Funktion von CySelectionGroup nutzen, ist CySelectionGroup nicht ne Gruppe von Einheiten mit gemeinsamer Befehlsqueue (?), nützt uns das hier überhaupt was?

[Ramkhamhaeng]

Aber wie nutzen wir das jetzt? generatePath() gibt ja erst mal nur nen Bool zurück, ob ein Pfad zwischen den beiden Plots möglich ist. Wie kommt man jetzt in Python an den Pfad ran? Kann man dafür überhaupt diese Funktion von CySelectionGroup nutzen, ist CySelectionGroup nicht ne Gruppe von Einheiten mit gemeinsamer Befehlsqueue (?), nützt uns das hier überhaupt was?

Ich habe da jetzt mal reingeschaut.
Das diese Methoden unter CvSelectionGroup zu finden sind, ist nicht so abwegig, denn intern werden bei Civ4 die Bewegungen „gruppenweise“ gesteuert.
Falls man keine Einheitengruppe zur Hand hat, um einen Pfad zu berechnen muss man intern eine Einheit dafür erstellen.

Du hast aber recht, dass man unter Python nur sehr schwer an die Daten heran kommt. In C++ ist es so, dass man nach Erzeugung eines Pfades mit generatePath() an das Zielfeld mittels [Gruppen-Object].getPathLastPlot() herankommt und sich da mit .parent bis zum ersten Feld des Pfades durchhangeln kann.

Unter Python kommt man aber nur an die Infos getPathEndTurnPlot() und getPathFirstPlot (nutzt uns nix?!) heran.
Man müsste also für eine einschrittige Einheit immer das nächste Feld berechnen und dann wieder von vorne beginnen, um den gesamten optimalen Pfad zu berechnen. Und in jedem Schritt müsste wieder generatePath aufgerufen werden, obwohl es eigentlich ja nur einmal notwendig war. (sofern ich nix übersehen habe)