PAE - Bonusressourcen

[Pie]

Ist eigentlich nicht nötig, weil nur Ressis eingeladen werden können, die im Umkreis der Stadt mit Modernisierung angeschlossen sind. Söldner etc. fallen also sowieso raus. Ein paar Gebäuderessis können auch noch eingeladen werden, wenn das Gebäude in der Stadt steht (Bronze, Messing, Terrakotta etc.).

Nunja, du musst ja sowieso die Plots und danach die Gebäude in einer Routine durchlaufen. 2x: Im PopUp und danach wieder im onModMessageZeugs, sonst weisst du ja nicht, was wirklich ausgewählt wurde. Das geht mit dem besch..eidenen Zeugs ja nicht anders. Und wenn du da jedesmal alle Sachen extra mit ifs berücksichtigen willst und "hardcoden" willst, anstatt es dynamisch zu machen, hab ich keine Freude damit, weil es mir im Nachhinein doppelt soviel Arbeit macht. Und das muss net sein, weils ja net notwendig ist und man es auch so programmieren kann, dass es "nachhaltiger" ist Um auch Modmods zu berücksichtigen!
Aber vielleicht ist deine Lösung ja eh eine gute und ich kenn sie einfach nicht. Wie würdest du es denn technisch machen?

Soll Meereszeug wirklich ausgeschlossen werden? Ich hab es jetzt so gemacht, dass auch Fisch, Muscheln, Krabben und Perlen eingeladen werden können, wenn im Umkreis der Stadt die entsprechende Ressi angeschlossen ist.

Genau. Bis auf Fisch und Krabben bin ich auch voll dafür. Rohes Fleisch und Fisch wurden nunmal nicht über weiter Distanzen transportiert. Es sei denn in Salzlake eingelegt. Aber so verarbeitetes Fleisch/Fisch hab ich nicht im Programm.

Find ich jetzt nicht so gut. AITradeModifier ist ein Wert, den man als Spieler ingame überhaupt nicht einsehen kann,

Das kann man mit dem anderen auch nicht, es sei denn, wir haben im Python Code die statischen Werte. Was aber gar nicht modmod-freundlich ist.
Ich hab sowieso vor, ein extra PopUp zu machen (der Button dafür soll oben links bei den kleinen runden Buttons sein (wo Siegesbedingungen und Spionage sind), wo die Liste der Resis und deren Wert aufscheinen. Gehört auch zu diesem Feature.

und Gesundheit und Zufriedenheit sind auch komisch, weil manche Ressis erst mit Gebäuden Zufriedenheit/Gesundheit bringen - Gold oder Silber z.B. bringen an sich gar nichts. Und militärische Ressis oder Marmor/Stein müsste man sowieso irgendwie separat berücksichtigen.

Und eben damit kann man bei AITradeModifier den Wert super steuern. Aber dein nächster Punkt ist da natürlich auch möglich:

Da fänd ich es besser, die Ressis in ein paar Kategorien aufzuteilen und denen einen bestimmten Basiswert zuzuordnen. Von Civ selbst werden Ressis ja sogar schon unterteilt in Nahrung, Luxusgüter und Allgemein (militärischer Kram plus Steine, Marmor), man könnte auch einfach die Einteilung übernehmen. Z.B. Nahrung wenig (10), Luxusgüter viel (30), militärische Güter besonders viel, wenn die Civ sie nicht zur Verfügung hat (40) und sonst mittel (20).

Na klar, geht das. Ich will nur sowenig wie möglich if i == BONUS_XY drin haben. Sondern nur allgemeine Variablen. Nur wie willst du eben diese sonstigen Güter filtern OHNE jede in eine eigene Liste schmeissen zu müssen?

Also: Ja, bei Pop 1 beginnen wär sinnvoller. Das sollte aber ein stark spürbarer Effekt sein, wenn die Distanz ganz rausfällt, sogar der Haupteffekt. Ich würd also auf 3 oder 4% pro Pop gehen. Wenn wir von Maximalgrößen ~Pop 15 ausgehen, ergibt das bis zu 50% Bonus

Einverstanden . +3% pro Pop.

Wieso sollte man eigene Güter nicht in eigenen Städten verkaufen können? Binnenhandel halt. V.a. kann man dann auch innerhalb seiner Civ eine Handelsstraße forcieren, hast du auch selbst am Anfang so gesagt:

Ja, aber da hab ich es noch nicht gewusst, sondern ich musste es mir noch genau überlegen! Hab ja mittlerweile über Handelswege einige Bücher angesammelt und vorgeschnuppert (muss sie noch alle fertig lesen). Und überlegt, hab ich mir das nun. Ich will diese wertvolle Straße nicht so billig machen. Diese berühmten Straßen sind ja zu 99% über mehrere Länder hinausgegangen. Und diese autarkten Städte (MinorCivs) die Thorgal und ich uns vorstellen, gehen (noch) nicht und das ist sowieso ne andere Geschichte.
Also da ich nicht möchte, dass man im eigenen Land mit eigenen Resourcen auch noch zusätzlich Geld verdienen soll, fällt das sowieso weg.

Kann ich dann natürlich auf Luxusgüter einschränken, wenn du meinst.

Ja, da dachte ich eben NUR an Bernstein, Weihrauch und Seide. Vielleicht auch Salz, Silber und Gewürze. Das waren nunmal die wichtigsten Waren die gern über weite Distanzen gehandelt wurden. Aber ich sags ja grad: "über weite Distanzen". Ich möchte daher nicht, dass man im eigenen Land mit den eigenen Gütern auch noch zusätzlich Geld verdient werden soll. Klingt auch etwas unlogisch.

Wissenstransfer findet nur Stadt, wenn der Händler in einer fremden Stadt steht. Find ich sinnvoll.

Stimmt

Im Moment hab ich es so, dass Güter, die eine Stadt selbst im Einflussbereich (also im Radius von 2 um die Stadt) hat, an diese Stadt gar nicht verkauft werden kann (die Güter, die man in einer Stadt kaufen kann, können dort also nicht verkauft werden). Ansonsten geht es. Ertragsmalus, wenn eine Stadt die Ressi nicht in ihrem Einflussbereich, aber im Handelsnetz hat (also z.B.: Nachbarstadt hat Gold, die Stadt selbst aber nicht), wär natürlich sinnvoll. -30%?

Ich weiß nicht recht... ich wär irgendwie dagegen. Das ist wieder etwas, wo man kaum durchblickt. Logischer und einfacher ist es: Nachbar hat bereits Silber, also brauch ich mit ihm mein Silber nicht handeln. Überm Button würde stehen: Das klingonische Reich ist bereits im Besitz von XY.
Ausserdem: wieso sollte man teuer Silber kaufen, wenn man selber eins hat?

Distanzberechnung: genau. Weg damit. Muss (noch) net sein.

[BoggyB]

Nunja, du musst ja sowieso die Plots und danach die Gebäude in einer Routine durchlaufen. 2x: Im PopUp und danach wieder im onModMessageZeugs, sonst weisst du ja nicht, was wirklich ausgewählt wurde. Das geht mit dem besch..eidenen Zeugs ja nicht anders. Und wenn du da jedesmal alle Sachen extra mit ifs berücksichtigen willst und "hardcoden" willst, anstatt es dynamisch zu machen, hab ich keine Freude damit, weil es mir im Nachhinein doppelt soviel Arbeit macht. Und das muss net sein, weils ja net notwendig ist und man es auch so programmieren kann, dass es "nachhaltiger" ist Um auch Modmods zu berücksichtigen!
Aber vielleicht ist deine Lösung ja eh eine gute und ich kenn sie einfach nicht. Wie würdest du es denn technisch machen?

Ich hatte es bisher so gemacht, dass einfach alle Plots durchgegangen und die angeschlossenen Ressis genommen werden. Zwei Probleme, die das hat und die mir erst seit gestern aufgefallen sind:
1) Das beruht natürlich auf der Annahme, dass alle Ressis auf Plots handelbar sind, davon ging ich auch bisher aus (auch bei Fisch, Konservierung durch Salz o.Ä. war mein Gedanke). Aber selbst wenn man den Fisch außer Acht lässt, gibt es ja noch die regionalen Söldnerressis (Balearen, Kreta etc.), die auf keinen Fall gehandelt werden dürfen. Die hatte ich bisher ganz vergessen.
2) Ressis durch Gebäude gibt's natürlich auch noch, das ist mir erst beim Post gestern eingefallen (hab ich also noch nicht programmiert). Wenn ich dich richtig verstehe, würdest du alle Gebäude durchlaufen, und wenn eine Gebäude eine Ressi erzeugt, die nicht in lNoBonusTrade ist, wird die hinzugefügt.
Problem ist halt auch hierbei, dass so eine Liste in Python letztendlich ja auch hardcoded ist. Ich würd es jetzt so mit dieser Liste machen (irgendwo ne Methode isTradeable(iBonus), in der diese Liste steht und die True/False zurückgibt) und sobald wir ans SDK gehen, fügen wir für Ressis ein eigenes Attribut im XML bIsTradeable ein, auf dass dann in Python zurückgegriffen wird. Das wär das Schönste.

Genau. Bis auf Fisch und Krabben bin ich auch voll dafür. Rohes Fleisch und Fisch wurden nunmal nicht über weiter Distanzen transportiert. Es sei denn in Salzlake eingelegt. Aber so verarbeitetes Fleisch/Fisch hab ich nicht im Programm.

An so was in der Art dachte ich halt. Aber wenn du meinst, dann nicht.

Das kann man mit dem anderen auch nicht, es sei denn, wir haben im Python Code die statischen Werte. Was aber gar nicht modmod-freundlich ist.

Es wären ja nur die drei Kategoren Nahrung/Luxus/Sonstiges, die ja auch in BtS vorkommen. Jede neue Ressi fällt ja auch in eine dieser Kategorien, von daher wäre das schon modmod-freundlich.

Ich hab sowieso vor, ein extra PopUp zu machen (der Button dafür soll oben links bei den kleinen runden Buttons sein (wo Siegesbedingungen und Spionage sind), wo die Liste der Resis und deren Wert aufscheinen. Gehört auch zu diesem Feature.


Und eben damit kann man bei AITradeModifier den Wert super steuern. Aber dein nächster Punkt ist da natürlich auch möglich:


Na klar, geht das. Ich will nur sowenig wie möglich if i == BONUS_XY drin haben. Sondern nur allgemeine Variablen. Nur wie willst du eben diese sonstigen Güter filtern OHNE jede in eine eigene Liste schmeissen zu müssen?

Letztendlich läuft es ja darauf hinaus, dass wir entweder die Ressis kategorisieren und jeder Kategorie einen Wert geben oder für jede Ressi den Wert individuell festlegen (natürlich nicht hardcoded, sondern z.B. mit AITradeModifier, was ja auch nichts anderes ist, als jeder Ressi separat einen Wert zuzuweisen).
Vorschlag: Sobald wir am SDK sind, bekommt jede Ressi ein eigenes Attribut für den Preis (kann man dann besser steuern als mit AITradeModifier) im XML und ingame kriegt der Spieler eine Liste im Popup mit allen Werten. Bis dahin als Übergangslösung eine Kategorisierung über die drei BtS-Kategorien. Dann bringt halt Eisen so viel wie Steine, wie gesagt, Übergangslösung und relativ simpel.

Ja, aber da hab ich es noch nicht gewusst, sondern ich musste es mir noch genau überlegen! Hab ja mittlerweile über Handelswege einige Bücher angesammelt und vorgeschnuppert (muss sie noch alle fertig lesen). Und überlegt, hab ich mir das nun. Ich will diese wertvolle Straße nicht so billig machen. Diese berühmten Straßen sind ja zu 99% über mehrere Länder hinausgegangen. Und diese autarkten Städte (MinorCivs) die Thorgal und ich uns vorstellen, gehen (noch) nicht und das ist sowieso ne andere Geschichte.
Also da ich nicht möchte, dass man im eigenen Land mit eigenen Resourcen auch noch zusätzlich Geld verdienen soll, fällt das sowieso weg.


Ja, da dachte ich eben NUR an Bernstein, Weihrauch und Seide. Vielleicht auch Salz, Silber und Gewürze. Das waren nunmal die wichtigsten Waren die gern über weite Distanzen gehandelt wurden. Aber ich sags ja grad: "über weite Distanzen". Ich möchte daher nicht, dass man im eigenen Land mit den eigenen Gütern auch noch zusätzlich Geld verdient werden soll. Klingt auch etwas unlogisch.

Gut, dann mach ich das so. Ressis können nur verkauft werden, wenn der Ursprung der Ressi nicht derselbe ist wie der Käufer (also auch: Wenn ich beim Perser Gewürze kaufe, kann ich die nicht wieder dem Perser verkaufen).

Ich weiß nicht recht... ich wär irgendwie dagegen. Das ist wieder etwas, wo man kaum durchblickt. Logischer und einfacher ist es: Nachbar hat bereits Silber, also brauch ich mit ihm mein Silber nicht handeln. Überm Button würde stehen: Das klingonische Reich ist bereits im Besitz von XY.
Ausserdem: wieso sollte man teuer Silber kaufen, wenn man selber eins hat?

Deine Begründung - wieso kaufen, wenn man es schon hat? - funktioniert im Civ-Sinne, in dem alle Städte zusammen eine Nation bilden und zusammen agieren. Eigentlich ist es ja aber so:
Die Stadt Susa hat Silber, Persepolis jedoch nicht. Wenn die beiden Städte verbunden sind, kann Persepolis trotzdem Silber nutzen - es fahren also, im abstrakten Sinne und für den Spieler nicht zu sehen, Händler zwischen Susa und Persepolis hin und her und verkaufen Silber aus Susa in Persepolis. Dasselbe können wir ja aber auch tun: Wir nehmen unsere Einheit Händler, laden Silber ein und fahren nach Persien. In Susa können wir das Silber nicht verkaufen, da ist ja schon welches. Wir können aber nach Persepolis fahren und es dort verkaufen, damit ersetzen wir quasi die Händler aus Susa. Den geringeren Ertrag, den man dabei erhält, weil Persepolis schon Silber in seinem Handelsnetz (aus Susa) hat, könnte man sogar damit begründen, dass ein stärkeres Angebot (verglichen mit einer Stadt, die kein Silber von irgendwoher bekommt) besteht und deshalb der Preis sinkt. Wenn wir aber sagen, in Persepolis kann kein Silber verkauft werden, weil Persien schon welches hat, bewegen wir uns ja wieder ein Stück weit in Richtung "Städte bilden eine homogene, gemeinsam agierende Civ", von der wir ja eigentlich ein bisschen wegkommen wollen. Die Händler sind ja an sich auch keine vom Staat ausgesandten (auch wenn das Geld am Ende in der Staatskasse landet...).
Letztendlich aber deine Entscheidung.

[Pie]

-) Solang wir nicht SDK haben, müssen wir es so machen. Wobei ich aber sagen muss, wenn wir es mal so haben, dann brauchen wir es im SDK nicht mehr, weil es so kaum Rechenleistung braucht.

-) isTradeable kannst du auch verwenden. Das bedeutet, dass es mit ner Modernisierung auch ans Handelsnetz angeschlossen ist.

-) 3 Kategorien: auch ok.

Gut, dann mach ich das so. Ressis können nur verkauft werden, wenn der Ursprung der Ressi nicht derselbe ist wie der Käufer (also auch: Wenn ich beim Perser Gewürze kaufe, kann ich die nicht wieder dem Perser verkaufen).

Genau.

Die Stadt Susa hat Silber, Persepolis jedoch nicht. Wenn die beiden Städte verbunden sind, kann Persepolis trotzdem Silber nutzen

Genau. Wieso dann doppelten Bonus für diesen Handelsweg nutzen, der ja passiv da ist? Ich bin dagegen, dass im eigenen Reich mit eigenen Resourcen noch extra Geld gemacht wird. Verbreiten: JA. Geld verdienen/erhandeln: Nein.

[BoggyB]

-) Solang wir nicht SDK haben, müssen wir es so machen. Wobei ich aber sagen muss, wenn wir es mal so haben, dann brauchen wir es im SDK nicht mehr, weil es so kaum Rechenleistung braucht.

Es ist halt einfach, meine ich, viel schöner und übersichtlicher, wenn so eine Eigenschaft einer Ressource (ob sie im Handelsfeature einbezogen ist) auch bei den anderen Eigenschaften der Ressource in BonusInfo.xml steht. Dann vergisst man auch bei einer neuen Ressource nie, diese Eigenschaft festzulegen, was bei der reinen Python-Lösung leicht passieren kann.
Und Rechenleistung sollte hier eigentlich auch keine Rolle spielen, es geht ja nur um die Abfrage einer einzigen Ja/Nein-Eigenschaft. Das wird im SDK nicht länger dauern, denk ich.

-) isTradeable kannst du auch verwenden. Das bedeutet, dass es mit ner Modernisierung auch ans Handelsnetz angeschlossen ist.

Damit meinte ich jetzt, eine Methode isTradeable selbst im Python zu schreiben (bin mir nicht ganz sicher, was du meinst ). Also einfach:

def isTradeable(iBonus):
   lNoBonusTrade = [ ... ]
   return (iBonus in lBonusTrade)

Also die Lösung mit der Liste, die du vorgeschlagen hast.

-) 3 Kategorien: auch ok.

Ok, dann mach ich (als Basiswert) Nahrung: 10, Allgemeines: 20, Luxus: 30.

Genau. Wieso dann doppelten Bonus für diesen Handelsweg nutzen, der ja passiv da ist? Ich bin dagegen, dass im eigenen Reich mit eigenen Resourcen noch extra Geld gemacht wird. Verbreiten: JA. Geld verdienen/erhandeln: Nein.

Häh? Es geht ja nicht darum, dass der Perser Silber nach Persepolis liefert (der kann das nicht), sondern z.B. der Assyrer oder irgendwer.
Aber wenn du meinst, dass nur Ressis, die nicht schon im Handelsnetz der Stadt sind, verkauft werden sollen, das ist eigentlich auch die Abfrage, wo die Ressi herkommt, unnötig. Wenn ich bei mir selbst Silber einlade, kann ich es in meinen Städten ja sowieso nicht mehr verkaufen, wenn die schon Silber in Handelsnetz haben.

[Pie]

Es ist halt einfach, meine ich, viel schöner und übersichtlicher, wenn so eine Eigenschaft einer Ressource (ob sie im Handelsfeature einbezogen ist) auch bei den anderen Eigenschaften der Ressource in BonusInfo.xml steht.

Na klar, geb ich dir da recht. Aber das ist jetzt im Moment nicht relevant. Und ich würds auch nicht umschreiben, wenn die python-Lösung genauso einfach, praktisch und schnell ist.

Damit meinte ich jetzt, eine Methode isTradeable selbst im Python zu schreiben (bin mir nicht ganz sicher, was du meinst ). Also einfach:

def isTradeable(iBonus):
   lNoBonusTrade = [ ... ]
   return (iBonus in lBonusTrade)

Also die Lösung mit der Liste, die du vorgeschlagen hast.

Aaachso. naja, wäre meiner Meinung nach nicht notwendig. Solang in einer Funktion keine extrigen Berechnungen gemacht werden, finde ich Funktionen unnötig.
Ich würd die Liste ganz oben bei den Haupt-Init-Variablen hinzutun und einfach im Resi-Feature ein "iBonus not in lNoBonusTrade" einbauen. Erspar ich mir einige unnötige Zeilen.

Ok, dann mach ich (als Basiswert) Nahrung: 10, Allgemeines: 20, Luxus: 30.

Passt.

Häh? Es geht ja nicht darum, dass der Perser Silber nach Persepolis liefert (der kann das nicht), sondern z.B. der Assyrer oder irgendwer.
Aber wenn du meinst, dass nur Ressis, die nicht schon im Handelsnetz der Stadt sind, verkauft werden sollen, das ist eigentlich auch die Abfrage, wo die Ressi herkommt, unnötig. Wenn ich bei mir selbst Silber einlade, kann ich es in meinen Städten ja sowieso nicht mehr verkaufen, wenn die schon Silber in Handelsnetz haben.

Achso. Fragen wir die Community!

Soll Eisen mit einem Volk gehandelt werden können, das selber schon Eisen hat?

A) Ja
B) Nein
C) mit -x % Einkommenseinbuße

Für die KI Programmierung sind A,B viel einfacher. Bei C muss man dann genau das immer berücksichtigen, dass das eben nicht soviel einbringt, wie wenn man was anderes einlädt.
Da spar ich mir viel Herumgesülze.

Da kommt dann auch gleich die Möglichkeit auf: Was man bereits eingeladen hat, kann man um den Einkaufspreis im gleichen Kaff wieder ausladen oder MUSS man es woanders loswerden?
(zB tritt auf, falls man sich mit den Waren geirrt hat)

[BoggyB]

Aaachso. naja, wäre meiner Meinung nach nicht notwendig. Solang in einer Funktion keine extrigen Berechnungen gemacht werden, finde ich Funktionen unnötig.
Ich würd die Liste ganz oben bei den Haupt-Init-Variablen hinzutun und einfach im Resi-Feature ein "iBonus not in lNoBonusTrade" einbauen. Erspar ich mir einige unnötige Zeilen.

Naja, es sind zwei zusätzliche Zeilen (die def- und die Rückgabe-Zeile), denn die Liste muss man ja sowieso irgendwie definieren. Mit der Funktion ist es aber einfacher, von außen darauf zuzugreifen.

A) Ja
B) Nein
C) mit -x % Einkommenseinbuße

Für die KI Programmierung sind A,B viel einfacher. Bei C muss man dann genau das immer berücksichtigen, dass das eben nicht soviel einbringt, wie wenn man was anderes einlädt.
Da spar ich mir viel Herumgesülze.

In der Funktion, die den Handelsertrag berechnet, wäre diese Einkommensbuße ja schon enthalten - vom Programmieraufwand hat man an der Stelle, an der man die KI schreibt, also eigentlich nicht mehr Gesülze als bei Option A. Bisschen mehr Rechenzeit.

Da kommt dann auch gleich die Möglichkeit auf: Was man bereits eingeladen hat, kann man um den Einkaufspreis im gleichen Kaff wieder ausladen oder MUSS man es woanders loswerden?
(zB tritt auf, falls man sich mit den Waren geirrt hat)

Ist in der Tat blöd, wenn man sich verklickt. Aber was will man machen? Extra eine Möglichkeit einzuprogrammieren, eine Ressi, die man jetzt gerade eingeladen und sich seitdem nicht mehr bewegt hat, wieder verkaufen zu können, ist auch ziemlich viel Rumgesülze für ne Kleinigkeit. Und jedesmal ein "Sind Sie sicher?"-Button nervt auch.

Andere Möglichkeit: Man kann in jeder Stadt jede Ressi verkaufen, völlig egal, ob sie diese Ressi schon hat; aber wenn die Stadt die Ressi schon hat (ob im Umkreis oder im Handelsnetz kommt darauf an, ob wir uns für A, B oder C entscheiden), erhält man nur den Preis, den man in dieser Stadt als Einkaufspreis hat. Heißt: Ich mache keinen Profit damit, Ressis an Civs/Städte, die diese Ressi schon haben, zu verkaufen (für den Handel an sich ist es also quasi so, als wäre das Verkaufen gar nicht möglich, weil es nichts bringt); aber wenn ich mich verklicke, kann ich das ohne Verlust rückgängig machen. Klingt eigentlich sinnvoll, find ich

[Pie]

Naja, es sind zwei zusätzliche Zeilen (die def- und die Rückgabe-Zeile), denn die Liste muss man ja sowieso irgendwie definieren. Mit der Funktion ist es aber einfacher, von außen darauf zuzugreifen.

Ich schreibe so statische Werte immer gern ganz oben in den Code, in den ___init___ wo ich sowas auch finde und schnell bearbeiten kann.
In irgendwelchen Funktionen schau ich da nicht extra. Sonst müsste ich jedesmal alle Funktionen durchgehen, wenn ich mal was hinzufüge. Das ist mühsam. Wenn die Funktion sonst nix kann, halte ich es für unsinnig. Das wäre wie eine eigene Funktion für ne A+B Addition.

Also bitte keine eigene Funktion, wenn derselbe Output auch ohne Funktion zu bekommen ist. Das ist meine Art zu Programmieren, diesen Grundsatz möcht ich bewahren, bitte

In der Funktion, die den Handelsertrag berechnet, wäre diese Einkommensbuße ja schon enthalten - vom Programmieraufwand hat man an der Stelle, an der man die KI schreibt, also eigentlich nicht mehr Gesülze als bei Option A. Bisschen mehr Rechenzeit.

Ja schon. Ich meinte mit A nur, ohne Buße.

Ist in der Tat blöd, wenn man sich verklickt. Aber was will man machen? Extra eine Möglichkeit einzuprogrammieren, eine Ressi, die man jetzt gerade eingeladen und sich seitdem nicht mehr bewegt hat, wieder verkaufen zu können, ist auch ziemlich viel Rumgesülze für ne Kleinigkeit. Und jedesmal ein "Sind Sie sicher?"-Button nervt auch.

Andere Möglichkeit: Man kann in jeder Stadt jede Ressi verkaufen, völlig egal, ob sie diese Ressi schon hat; aber wenn die Stadt die Ressi schon hat (ob im Umkreis oder im Handelsnetz kommt darauf an, ob wir uns für A, B oder C entscheiden), erhält man nur den Preis, den man in dieser Stadt als Einkaufspreis hat. Heißt: Ich mache keinen Profit damit, Ressis an Civs/Städte, die diese Ressi schon haben, zu verkaufen (für den Handel an sich ist es also quasi so, als wäre das Verkaufen gar nicht möglich, weil es nichts bringt); aber wenn ich mich verklicke, kann ich das ohne Verlust rückgängig machen. Klingt eigentlich sinnvoll, find ich

Genau ->

Was halten andere von dieser Sache?

[Flunky]

Entfernung einbeziehen

Gold = A*(X+Y)

mit
A: Basiswert dieser Ressource
X: 0/50/100% für vorhanden/nicht vorhanden
Y: Handelswegmodifikator zwischen Ursprungs- und Zielstadt aus der DLL. Der sollte exposed to python sein.

[BoggyB]

Ich schreibe so statische Werte immer gern ganz oben in den Code, in den ___init___ wo ich sowas auch finde und schnell bearbeiten kann.
In irgendwelchen Funktionen schau ich da nicht extra. Sonst müsste ich jedesmal alle Funktionen durchgehen, wenn ich mal was hinzufüge. Das ist mühsam. Wenn die Funktion sonst nix kann, halte ich es für unsinnig. Das wäre wie eine eigene Funktion für ne A+B Addition.

Also bitte keine eigene Funktion, wenn derselbe Output auch ohne Funktion zu bekommen ist. Das ist meine Art zu Programmieren, diesen Grundsatz möcht ich bewahren, bitte

Mit der Begründung dürfte es überhaupt keine Funktion geben, weil du immer auch ohne Funktion rankämst Ich meine halt, wenn es wichtig ist und man es öfter braucht, kann man auch ne Funktion dazu machen - wär's im XML, wie es sowieso besser wär, würd ich es ja auch mit einer Funktion abfragen.

Edit: Um es mal anders zu sagen: Ich sehe das so, dass ich alles, was ich an "Schnittstellen" zur Verfügung habe, über Methoden umgesetzt sehen will (von meinem Stil her). Jemand will irgendwas von außen vom Feature abfragen (in diesem Fall: ob eine Ressi im Feature inbegriffen ist), also benutzt er eine Methode dafür. Da soll er nicht noch auf irgendeine Liste mit allen betroffenen Ressis, die da als globale Variable rumliegt, zugreifen oder - worst case - die, wenn sie da als globale Variable rumliegt, sogar ändern können (keine Ahnung, hat Python Zugriffsmodifikatoren? Damit bin ich in Java sehr penibel ).
Ist in diesem Fall natürlich so, dass die Abfrage, ob eine Ressi handelbar ist, in den meisten Fällen von "innen", innerhalb des Features und innerhalb der dem Feature zugewiesenen Datei erfolgen wird. Aber trotzdem würde ich alles, was keine elementare Sache ist (die Abfrage, ob die Ressi in der Liste ist, ist zwar auch nur ein Befehl mit in, aber man muss ja erst mal wissen, dass es so ne Liste gibt), als Methode implementieren; sodass ich, wenn ich wissen will, was möglich (also bereits programmiert) ist, mir nur die Methoden ansehen muss. Was da noch für Variablen sind, soll mich nicht interessieren. Datenkapselung und so, mein ich.
Aber wenn du es anders haben willst, ok, Stilsache

Entfernung einbeziehen

Gold = A*(X+Y)

mit
A: Basiswert dieser Ressource
X: 0/50/100% für vorhanden/nicht vorhanden
Y: Handelswegmodifikator zwischen Ursprungs- und Zielstadt aus der DLL. Der sollte exposed to python sein.

HW-Modifikator einbeziehen find ich nicht gut - das ist dann im Endeffekt ja wie bei den momentanen Händlern, die in fast jeder Stadt denselben Ertrag bringen, weil der Modifikator fast immer 1 ist.

X: 0/50/100% für vorhanden/nicht vorhanden

Drei Werte für zwei Möglichkeiten. Ich bin verwirrt

[Flunky]

vorhanden (im Stadtradius)/vorhanden (im Handelsnetz)/nicht vorhanden

Mhm, in BtS bringen Händler sehr verschieden viel, je nach Strecke. Und die nutzen die HW-Modifikatoren. Ich denk eher, die PAE-Händler haben momentan einen hohen Basiswert und einen kleinen Multiplikator für den HW-Wert.

[BoggyB]

vorhanden (im Stadtradius)/vorhanden (im Handelsnetz)/nicht vorhanden

Mhm, in BtS bringen Händler sehr verschieden viel, je nach Strecke. Und die nutzen die HW-Modifikatoren. Ich denk eher, die PAE-Händler haben momentan einen hohen Basiswert und einen kleinen Multiplikator für den HW-Wert.

Großer Händler in BtS: iBaseTrade 500, iTradeMultiplier 200
Händler in PAE: iBaseTrade 40, iTradeMultiplier 8

Das Problem sind jetzt aber gar nicht unbedingt die XML-Werte an sich, will ich sagen. Meines Wissens ist die Formel ungefähr so, dass man iBaseTrade immer kriegt und zusätzlich iTradeMultiplier mal den Ertrag, den ein HW zwischen Zielstadt und HS bringt. Und HW-Erträge werden halt immer ganzzahlig abgerundet und sind in der Phase, in der Händler in PAE relevant sind, eigentlich immer 2. Ne Änderung von iTradeMultiplier würde daran nichts ändern - dann hat man nen höheren Goldertrag, aber trotzdem überall denselben.

In BtS hat man halt früher größere Städte und größere HW-Boni. Aber auch da find ich es sehr störend, dass der Goldertrag sich immer nur in 200-Sprüngen ändert, davon würd ich auf jeden Fall loskommen wollen. Wenn kleinere Schritte erlaubt sind, gibt es auch mehr Möglichkeiten, zwischen verschiedenen Zielstädten zu differenzieren (Stadt A ist 1 größer als Stadt B, da bringt der Händler jetzt 5 mehr o.Ä.).

[Pie]

Mit der Begründung dürfte es überhaupt keine Funktion geben, weil du immer auch ohne Funktion rankämst Ich meine halt, wenn es wichtig ist und man es öfter braucht, kann man auch ne Funktion dazu machen - wär's im XML, wie es sowieso besser wär, würd ich es ja auch mit einer Funktion abfragen.

Boggy! Mach mich net fertig!
"if i in Liste" ist bereits eine Funktion. Wenn ich woanders wissen möchte, was in der Liste steht, mach ich wieder "if hugo in Liste".
Ich such doch nicht extra nach einer eigenen Funktion, wenn ich doch nur in einer Liste nachsehen will, ob der Wert enthalten ist!

Beispiel:
x = makeAddition(a,b);

function makeAddition(a,b) { return a+b; }

Was bringt mir das?!? Solange in einer Funktion keine zusätzlichen Operationen drin sind, bringt mir die Funktion nix. Im Gegenteil, sogar Verwirrung.

Mir ist schon klar, du willst in der Funktion die Liste initialisieren. Aber was bringt mir eine Abfrage einer Funktion, wo bei jeder Abfrage die Variable erneut initialisiert wird und die Funktion sonst nix anderes kann, was ich auch ohne der Funktion machen kann? Nur Laufzeiteinbußen.

Und ich bin es nunmal gewohnt, dass ich statische Variablen im init drin stehn hab.

Deine Version ist natürlich nur dann korrekt, wenn wir es irgendwann mal übers XML+SDK machen sollten und es dann keine Liste mehr gibt, sondern mittels for-Schleife aus der XML ausgelesen werden muss. So ne Funktion ist dann für die Gewinnberechnung ganz wichtig.
Wollen wir das mal im XML alles angeben? Oder reichen uns die Gesundheit, Luxus und normal-Typen? Wenn du meinst, dass wir es im SDK irgendwann ändern sollten, JA, dann mach so ne Funktion.

[Flunky]

5 Gold sind in PAE noch mehr als in BtS halt mal sowas von irrelevant.

Lassen wir die Städte halt größer werden, oder ändern wir die Ertragsformel.

In BtS ist am Anfang:
Inland-Festland 1
Inland-Insel 2
Ausland-Festland 2
Ausland-Insel 3

Aber modifiziert wird das, neben Gebäuden, durch Pop>10 und Friedensdauer. Diese Zahlen kann man doch sicherlich im XML ändern. z.B. zu Bonuserträgen ab Pop6.

200er Schritte sind das, was ich in BtS erwarte. Durch das weiter wegziehen kommt das Gold ja auch später - und in BtS zählt manchmal jede Runde - und der Händler (GP!) ist gefährdet.

Statt 40/8 ginge ja auch 20/10, dann hätten wir beim jetzigen Händler 30er, 40er, 50er, ... Erträge. Das kann man sich merken, da hat man das Gefühl, dass sich das MM gelohnt hat.

€: wie sortiert das Spiel eigentlich momentan in die 3 Typen Gesundheit, Luxus und Strategisch ein?

[BoggyB]

Siehe auch mein Edit in Post #99 oben.

"if i in Liste" ist bereits eine Funktion. Wenn ich woanders wissen möchte, was in der Liste steht, mach ich wieder "if hugo in Liste".
Ich such doch nicht extra nach einer eigenen Funktion, wenn ich doch nur in einer Liste nachsehen will, ob der Wert enthalten ist!

Mein Punkt ist: Ich will ja, ganz am Anfang des Weges (wir tun jetzt mal so, als hätte jemand anders den Code programmiert und wir wollen auf das Feature irgendwie zugreifen), nicht wissen, ob meine Ressi in irgendeiner Liste, die ich gar nicht kenne, liegt. Ich will wissen, ob die Ressi handelbar ist. Woher soll ich wissen, dass da so ne Liste ist? Jetzt kannst du natürlich sagen: Woher soll ich wissen, dass da so ne Methode implementiert ist? Da sehe ich es so, dass Methoden nun mal die Schnittstellen sind, die das Feature zur Verfügung stellt und die man nutzen kann.
Wenn ich also, als "Außenstehender", da stehe und wissen will, ob eine Ressi handelbar ist: Doch, natürlich such ich dann erst mal nach einer Funktion und nicht nach einer irgendwo definierten Variable. Denn die Funktionen sind die Schnittstellen, die ich dafür zu nutzen habe.

Beispiel:
x = makeAddition(a,b);

function makeAddition(a,b) { return a+b; }

Was bringt mir das?!? Solange in einer Funktion keine zusätzlichen Operationen drin sind, bringt mir die Funktion nix. Im Gegenteil, sogar Verwirrung.

Ist mir schon klar, dass diese Addition nichts bringt Der Unterschied zwischen diesem Beispiel und unserem Anwendungsfall (mMn): Wann würde ein Programmierer makeAddition() aufrufen? Wenn er eine Addition durchführen will. Von der weiß er aber, dass sie schon standardmäßig mit + implementiert ist. Wann würde er isTradeable() aufrufen? Wenn er wissen will, ob die Ressi handelbar ist. Kann er wissen, dass wir eine Liste haben, auf die er einfach zugreifen kann? Woher? Wiedermal: Ich finde, dass Methoden die Schnittstellen sind, die dafür zur Verfügung stehen (sollen).

Mir ist schon klar, du willst in der Funktion die Liste initialisieren. Aber was bringt mir eine Abfrage einer Funktion, wo bei jeder Abfrage die Variable erneut initialisiert wird und die Funktion sonst nix anderes kann, was ich auch ohne der Funktion machen kann? Nur Laufzeiteinbußen.

Stimmt, die Liste wird bei jedem Methodenaufruf neu initialisiert, das ist doof Aber auch wenn ich die Liste einmal als globale Variable definiere, würd ich trotzdem noch - obwohl man durch die Initialisierung dieser Liste bereits mit "in" alles, was man will, abfragen könnte - eine Methode zur Verfügung stellen. Was bringt mir das? Ich hab eine Schnittstelle, von der ich weiß und von der dokumentiert ist, dass sie dafür da ist.

Und ich bin es nunmal gewohnt, dass ich statische Variablen im init drin stehn hab.

Das ist fürs Prinzip irrelevant, aber einen Konstruktor gibt es hier auch gar nicht, ist alles statisch. Gibt nichts, was (sinnvoll) instanzierbar ist. Wär also ne globale Variable, glaub ich. Kenn mich da mit Python eigentlich nicht aus.

Deine Version ist natürlich nur dann korrekt, wenn wir es irgendwann mal übers XML+SDK machen sollten und es dann keine Liste mehr gibt, sondern mittels for-Schleife aus der XML ausgelesen werden muss. So ne Funktion ist dann für die Gewinnberechnung ganz wichtig.
Wollen wir das mal im XML alles angeben? Oder reichen uns die Gesundheit, Luxus und normal-Typen? Wenn du meinst, dass wir es im SDK irgendwann ändern sollten, JA, dann mach so ne Funktion.

Ja, das würde ich im SDK dann auf jeden Fall machen

Nochmal: Es geht mir hier, glaube ich, um Datenkapselung. Ums Prinzip. Alles, was beim Feature abfragbar und ausführbar ist und öffentlich zugänglich ist, soll nur über die vom Programmierer festgelegten Schnittstellen, nur über die Methoden geschehen. In diesem Beispiel tut diese Methode natürlich nicht viel, aber trotzdem halte ich sie für richtig und wichtig. Nicht wegen dem, was sie tut, sondern wegen dem, was sie sagt: Hier ist eine Methode, hiermit kannst du xy erreichen, nutze die Methode und mach dir keine Gedanken über die Implementierung. Bei einem direkten Zugriff auf die Liste muss man wissen, dass es diese Liste gibt und was drinsteht.
Zum Thema "Trennen von Nutzen und Implementierung": Bei diesem Beispiel ist das unwahrscheinlich, aber es könnte ja sein, dass wir die Kriterien für Handelbarkeit irgendwann mal ändern. Also nicht nur ein paar Ressis mehr oder weniger, sondern es vom Prinzip her anders machen, sodass man nicht mehr einfach Ja/Nein aus einer Liste abfragen kann. Haben wir eine Methode isTradeable, ist für alles, was von außen darauf zugreift, völlig egal, wie diese implementiert ist. Man ruft sie auf und gut ist. Ändern wir was an dem Konzept, müssen wir nur die Implementierung von isTradeable ändern und alles außerhalb davon funktioniert automatisch. Bei ner Liste müsste man dann überall alles ändern.

Also: Es geht mir nicht darum, dass es sich vom Aufwand lohnt, das auszulagern, laufzeitmäßig ist deine Lösung sicher besser. Das Problem, das ich damit sehe, ist ein theoretisch-konzeptionelles. Ich glaube, essentiell bei der Sache ist:

Solange in einer Funktion keine zusätzlichen Operationen drin sind, bringt mir die Funktion nix. Im Gegenteil, sogar Verwirrung.

Das sehe ich völlig anders. Bei einer Methode geht es mir nicht darum, was sie tut, sondern darum, was sie und ihre Existenz aussagen. Schnittstelle.

Mag noch jemand anders was zu dieser Stildiskussion sagen? Rede ich völligen Schmarrn? Ich find das eigentlich hochinteressant.

Edit:

Boggy! Mach mich net fertig!

Mir diesen Worten beginnt Pies 10.000 Post, ist das nicht geil?

[BoggyB]

5 Gold sind in PAE noch mehr als in BtS halt mal sowas von irrelevant.

Lassen wir die Städte halt größer werden, oder ändern wir die Ertragsformel.

In BtS ist am Anfang:
Inland-Festland 1
Inland-Insel 2
Ausland-Festland 2
Ausland-Insel 3

Aber modifiziert wird das, neben Gebäuden, durch Pop>10 und Friedensdauer. Diese Zahlen kann man doch sicherlich im XML ändern. z.B. zu Bonuserträgen ab Pop6.

200er Schritte sind das, was ich in BtS erwarte. Durch das weiter wegziehen kommt das Gold ja auch später - und in BtS zählt manchmal jede Runde - und der Händler (GP!) ist gefährdet.

Statt 40/8 ginge ja auch 20/10, dann hätten wir beim jetzigen Händler 30er, 40er, 50er, ... Erträge. Das kann man sich merken, da hat man das Gefühl, dass sich das MM gelohnt hat.

Bandbreite von HW-Erträgen erhöhen Aber selbst damit, solange auf ganze Zahlen abgerundet wird, haben wir ja nur ne Handvoll möglicher Erträge (wenn HWs nicht auf einmal richtig viel bringen sollen), die ein Händler überhaupt bringen kann.

€: wie sortiert das Spiel eigentlich momentan in die 3 Typen Gesundheit, Luxus und Strategisch ein?

Wird direkt im XML eingestellt. Muss man dann auch mal aufräumen, z.B. steht Myrrhe unter Nahrung, aber Gold und Silber unter Allgemein.