PAE - Bonusressourcen

[Flunky]

Dann brauchts ja netmal ne Liste?

Det xml hat nen Eintrag isTradeable und nen Eintrag Nahrung/Luxus/sonstige. Da würd ich einfach sowas hier machen:

define getBaseTradeValue(res)
  if isTradeable(res):
    switch type(res):
    case food: return 10
    case happy: return 30
    case strategic: return 40

define getTradeValue(res, origin, destination)
  value = getBaseTradeValue(res)
  if type(res)==strategic && available(res, destination):
    value /=2
  if locallyAvailable(res, destination):
    value = 0
  value += tradeRouteValue(origin, destination)
  return value

(Ich hab keine Ahnung, wie die Funktionen richtig heißen)

@Methoden oder nicht:
da würd ich dem JIT vertrauen, dass er Overhead durch Methodenaufrufe weitestgehend weglässt. Ich mag Boggys Weg, sobald an mehreren Stellen auf die Liste zugegriffen wird. Weil man eben zentral ändern kann, wenn man das System ändert - z.B. auf SDK, wo Boggys Funktion dann plötzlich ihre Werte aus der DLL bekommen könnte.

Ansonsten hat Pie natürlich recht, Konstanten sollten oben in der Datei definiert werden. Hier also die Definition der Liste (wenn die denn nötig ist) im Init-Block und dann ne Funktion, die nur return x in list beinhaltet, solang wir keine komplexere Funktionalität benötigen.

[Pie]

10.000ster Post und dann das

Also Boggy:

Anderes Beispiel zu a+b

x = iCalc(a,b); Woher willst du nun wissen, ob da addiert, subtrahiert, etc. wird?

bei if i in Liste WEIß ich, dass ich da einen Wert aus einer Liste checke. Mehr brauchts dafür nicht.
bei isTradeable() weiß ich nichts. Da kann ich raten was die Funktion tut und muss extra im Code herumhüpfen, um mir dann die Hände vor den Kopf zu schlagen und zu sagen: da hätte aber das "if i in Liste" oben in der Verarbeitung vollkommen gereicht. Ich programmiere solche Dummheiten dann immer um, wenn ich sowas sehe.

Und initialisert wird IMMER am Anfang eines Codes, egal wo (auch in einer Funktion, wie du weißt). Somit weiß ich als Programmierer, globale Variablen stehen ganz oben.
Natürlich gibt es ein paar Spasstiger, die mitten drin auch noch globale Variablen erstellen, oder eben wie du gemeint hast, globale Variablen überschreiben, dann hast du natürlich Recht. Aber wo soll denn diese Liste überschrieben werden? Also ich weiß nicht, wo ich jemals im Eventmanager die Liste lBonusNoTrade bearbeiten würde.

Aber keine Sorge, deine Methodenprogrammierung nutz ich ja auch, wie du wahrscheinlich bemerkt hast. Aber eben NUR dann, wenn ich sie anderswo ebenfalls aufrufe! Sonst wäre mein Code ein einziger Funktionshaufen und das macht keinen Spaß, wenn du bei jedem Schritt in einer Funktion jedesmal in eine andere Funktion schauen musst, was die nun macht. Nach dem Motto: Warum einfach, wenns auch kompliziert geht!
Da geht mir beim Programmieren zuviel Zeit verloren. Und die Strg-F Taste wird plötzlich dein bester Freund. DAS ist ein NO-GO.

Und da bin ich dagegen. Auch wenns deinem Stil nicht entspricht. Aber meinem. Eine Funktion will ich nur haben, wenn sie auch mehrmals verwendet wird UND wenn sie mehr tut als eine bestehende Befehlsroutine selbst.

So, nicht bös sein, ich bin halt ein alter Veteran, der stur seinen Stil bewahrt, immerhin muss ich mich damit ständig auseinandersetzen und ich weiß, ich bau Schlampigkeitsfehler ein - das kann passieren - aber ich versuche wenigstens einen klar strukturierten, praktischen und optimalen Code zu zaubern. Ich hab ja auch den Charlemagne-Austreibungscode optimiert, weil der ebenfalls - meiner Meinung nach - verdammt schlecht programmiert war. Das können andere halten wie sie wollen

[BoggyB]

Anderes Beispiel zu a+b

x = iCalc(a,b); Woher willst du nun wissen, ob da addiert, subtrahiert, etc. wird?

Das ist doch jetzt ein blödes Beispiel, denn das Problem liegt doch nur darin, dass "iCalc" ein unsinniger Name für eine Funktion ist Der würde man natürlich einen aussagekräftigen Namen geben und das idealerweise () dokumentieren.

bei if i in Liste WEIß ich, dass ich da einen Wert aus einer Liste checke. Mehr brauchts dafür nicht.
bei isTradeable() weiß ich nichts. Da kann ich raten was die Funktion tut

Genau das ist ja mein Punkt, aber von der anderen Seite betrachtet. Du schreibst: Du weißt, was du mit dem "in"-Operator tust, bei der Methode aber nicht. Wenn du aber gerade am Programmieren sitzt, wird aus dem "Wissen" plötzlich ein "Wissen müssen": Du musst wissen, dass du du jetzt checken musst, ob die Ressi in dieser Liste ist. Du musst wissen, dass für die Handelbar-Eigenschaft überprüft werden muss, ob die Ressi in einer Liste ist - es könnte ja auch was ganz Anderes sein, womöglich irgendwas Dynamisches, was sich an die Umstände im Spiel anpasst. Du setzt beim Programmierer also Vorwissen über das Feature und v.a. seine konkrete Implementierung voraus. Gibt es aber eine Methode, MUSST du NICHTS WISSEN. Völlig egal, wie die Implementierung der Eigenschaft "Ist handelbar" ist, du rufst einfach die Methode auf und machst dir um nichts Gedanken. Du kannst jetzt raten, was die Funktion tut, oder du lässt es sein, denn du musst es ja überhaupt nicht wissen.

und muss extra im Code herumhüpfen, um mir dann die Hände vor den Kopf zu schlagen und zu sagen: da hätte aber das "if i in Liste" oben in der Verarbeitung vollkommen gereicht. Ich programmiere solche Dummheiten dann immer um, wenn ich sowas sehe.

Du musst ja eben nicht im Code rumhüpfen, denn um eine Methode aufzurufen, musst du sie ja nicht kennen.

Und initialisert wird IMMER am Anfang eines Codes, egal wo (auch in einer Funktion, wie du weißt). Somit weiß ich als Programmierer, globale Variablen stehen ganz oben.

Ja, das seh ich ja auch so. Das es Unsinn ist, die Liste in der Methode zu initialisieren, ist mir auch klargeworden. Ich würde es so machen, wie Flunky vorschlägt, mit Liste als globaler Variable ganz oben und ner Funktion, die dann einfach nur "is in Liste" zurückgibt.
Mir geht es eben auch darum, dass man von außerhalb der dem Feature zugewiesenen Datei auf diese Eigenschaft zugreifen kann, von einer Stelle, die vielleicht gar nichts direkt mit dem Feature zu tun hat, die dann aber doch aus irgendeinem Grund diese Eigenschaft braucht. In dem Moment will ich mich gar nicht darum kümmern müssen, wie diese Eigenschaft implementiert ist und ob ich da einfach auf ne Liste zugreifen könnte - ich gucke einfach, welche Schnittstellen in Form von Methoden stellt mir das Feature zur Verfügung, aha, da ist eine Methode isTradeable, nutz ich die.

Natürlich gibt es ein paar Spasstiger, die mitten drin auch noch globale Variablen erstellen, oder eben wie du gemeint hast, globale Variablen überschreiben, dann hast du natürlich Recht. Aber wo soll denn diese Liste überschrieben werden? Also ich weiß nicht, wo ich jemals im Eventmanager die Liste lBonusNoTrade bearbeiten würde.

"Wo soll denn diese Liste überschrieben werden?" Eben, nirgendwo. Deshalb würd ich es auch gerne explizit verbieten. Natürlich könnte man sagen "Überschreib ich sie halt einfach nie", aber was nicht geschehen soll, soll auch verboten werden, finde ich. Aber wenn da eine globale Variable ist, könnte die theoretisch immer geändert werden (auch wenn es praktisch nie geschehen wird), das stört mich. Dass Python (laut kurzer Google-Recherche) auch kein const, final oder irgendwas zur Verfügung stellt
Zur Klarheit: Ich bin jetzt trotzdem dafür, die Liste als globale Variable zu initialisieren (wie Flunky vorschlägt), aber trotzdem stört mich das, dass sie einfach so geändert werden kann, auch wenn niemand das jemals tun würde.

Aber keine Sorge, deine Methodenprogrammierung nutz ich ja auch, wie du wahrscheinlich bemerkt hast. Aber eben NUR dann, wenn ich sie anderswo ebenfalls aufrufe! Sonst wäre mein Code ein einziger Funktionshaufen und das macht keinen Spaß, wenn du bei jedem Schritt in einer Funktion jedesmal in eine andere Funktion schauen musst, was die nun macht. Nach dem Motto: Warum einfach, wenns auch kompliziert geht!

Eben, und ich meine halt, dass das durchaus etwas ist, was man theoretisch nochmal irgendwo brauchen könnte Subroutinen, die eine eigene Funktionalität für sich darstellen (hier eben: fragen, ob Ressi handelbar), lager ich gerne in Methoden aus, man weiß ja nie, ob man es mal brauchen könnte. Und wie gesagt: Du musst ja nicht jedesmal, wenn du eine Funktion aufrufst, nachgucken, was die tut. Du kannst dich auch einfach darauf verlassen, dass sie das tut, was dokumentiert ist, und wenn es zu Fehlern kommt, immer noch nachsehen.
Ja, deine Umsetzung ist "einfacher". Du gewinnst ein Stück "Einfachheit", opferst aber eben mMn andere Sachen dafür, und mMn ist es das nicht wert.

Da geht mir beim Programmieren zuviel Zeit verloren. Und die Strg-F Taste wird plötzlich dein bester Freund. DAS ist ein NO-GO.

Und da bin ich dagegen. Auch wenns deinem Stil nicht entspricht. Aber meinem. Eine Funktion will ich nur haben, wenn sie auch mehrmals verwendet wird UND wenn sie mehr tut als eine bestehende Befehlsroutine selbst.

Mehrmals verwendet wird sie ja und im Moment ist es zwar so, dass nur einen einzigen Befehl enthält, aber in dem Moment, in dem du programmierst und dich fragst "Was muss ich abfragen, um zu wissen, ob eine Ressi handelbar ist" ist keineswegs offensichtlich, dass du dafür nur einen Befehl bräuchtest. Deshalb ist die Methode da, damit dir die konkrete Implementierung egal sein kann. Und falls sich an der konkreten Implementierung was ändert, bleibt der Methodenaufruf dennoch der Gleiche.

So, nicht bös sein, ich bin halt ein alter Veteran, der stur seinen Stil bewahrt, immerhin muss ich mich damit ständig auseinandersetzen und ich weiß, ich bau Schlampigkeitsfehler ein - das kann passieren - aber ich versuche wenigstens einen klar strukturierten, praktischen und optimalen Code zu zaubern. Ich hab ja auch den Charlemagne-Austreibungscode optimiert, weil der ebenfalls - meiner Meinung nach - verdammt schlecht programmiert war. Das können andere halten wie sie wollen

Bös bin ich sowieso nicht MMn ist das eben strukturiert, praktisch und optimal, weil dadurch Funktionalität und konkrete Implementierung voneinander getrennt werden, sowie ich bei einer Website Inhalt und Design trenne.

[BoggyB]

Det xml hat nen Eintrag isTradeable und nen Eintrag Nahrung/Luxus/sonstige.

Was meinst du? Mein XML hat keinen solchen Eintrag isTradeable (in BonusInfos).

@Methoden:
Um das vielleicht mal zusammenzufassen: Wenn ich das richtig verstehe, ist Pies Problem, das diese Methode isTradeable() selbst nichts tut, außer eine weitere Funktion (in) aufzurufen, man also an der Stelle im Code, an der man isTradeable(iBonus) schreibt, genauso gut iBonus in List schreiben könnte. Durch die Methode wird keine neue Funktionalität geschaffen, sondern sie fragt einfach nur die Liste ab, die man auch direkt abfragen könnte. Stattdessen sorge die Methode dafür, dass der Code dann nicht mehr an der Stelle steht, an der man ihn braucht, was ihn unübersichtlicher mache.
Du schriebst auch mal, dass du bei einer Änderung nur oben in der Datei die Liste ändern musst. Der Punkt hat sich aber erledigt, wenn man auch in der Methodenvariante die Liste als globale Variable anlegt und in der Methode nur darauf zugreift.

Mein Punkt ist, dass durch die Methode Funktionalität von konkreter Implementierung getrennt wird - mit "iBonus in List" greift man direkt auf die Innereien des Features zu, was ich nicht schön finde. Mit der Methode hingegen nutzt man die vom Programmierer ausgewiesene Schnittstelle dafür. Die tut zwar nichts anderes, als auf die Liste zuzugreifen, aber:
1. Ändert sich irgendwas an der Art und Weise, wie Eigenschaft "ist handelbar" technisch umgesetzt ist, muss man nur diese Methode ändern. Die Eigenschaft ist nur an einer Stelle implementiert, und alles, was darauf zugreift, muss nur wissen: Diese Methode prüft, ob die Ressi handelbar ist. Die Stellen im Code, die die Methode aufrufen, sind nur von Ein- und Ausgabeparametern der Methode abhängig, nicht aber von ihrer Implementierung; deshalb müssen sie auch nicht geändert werden, wenn sich die Methode ändert.
2. Man muss als Programmierer nur wissen: Alles, was ich irgendwie abfragen kann, ist in den Methoden. Bei Pie muss man aber sowohl die Methoden (denn für bestimmte Sachen muss man halt Methoden nutzen) als auch die globalen Variablen berücksichtigen. Man muss sich merken: Will ich wissen, ob eine Ressi handelbar ist, muss ich "iBonus in List" abfragen. Und das muss man sich für alle Sachen merken, die irgendwie mit solchen Listen oder anderen statischen Sachen umgesetzt sind. Hat man alles über Methoden, muss man sich nur merken: Will ich irgendwas wissen, ruf ich eine passende Methode auf. Und das gilt für alles. In diesem Fall, wo die Methode wirklich nur eine Listenoperation durchführt, macht es natürlich scheinbar keinen Unterschied, ob ich mir jetzt den Namen einer Liste oder den Namen einer Methode merke. Aber ich muss ihn mir ja nicht merken. Ich muss mir nur merken: Guck halt bei den Methoden nach, da findest du immer, was du suchst. Ich muss mir nicht mehr merken: Für die und die und die einfache Sache kann ich die und die und die elementare Listen-/sonstwas-Operation verwenden. Bei dir muss ich immer die Methoden und die statischen Variablen checken. Und wenn in so einer Methode mal mehr steht als nur eine Zeile, dann spart man sich sowieso was, das ist ja klar.
Deinen Grundsatz

Eine Funktion will ich nur haben, wenn sie auch mehrmals verwendet wird UND wenn sie mehr tut als eine bestehende Befehlsroutine selbst.

würde ich abändern zu: Eine Funktion will ich haben, wenn sie mehrmals verwendet wird (dann sowieso immer!) ODER wenn sie irgendeine Unterfunktionalität (hier: Abfrage dieser Eigenschaft) enthält, die sich potentiell ändern könnte (hier: irgendwann benutzen wir vielleicht ein anderes, nicht-statisches System dafür, welche Ressis handelbar sind) oder bei der nicht offensichtlich ist, wie man sonst an sie rankäme: bei "ist Ressi handelbar" ist nicht offensichtlich, dass es eine Liste gibt, auf die man nur zugreifen muss. Bei "Was ist 3 plus 4" ist offensichtlich, dass man eine Addition durchführen will, also nutzt man den Plus-Operator. Der Plus-Operator stellt EXAKT das zur Verfügung, was ich haben will, eine Addition. isTradeable() stellt zwar auch exakt die in-Operation dar, aber sie erspart mir den Zwischenschritt, dass ich wissen muss, dass ich den in-Operator verwenden muss.

Wie gesagt, um das "zusammenzufassen" (). Meinen Standpunkt ist eben, dass mMn die Vorteile bei der Methodenvariante überwiegen und dadurch der Code strukturierter wird. Das kann man natürlich anders sehen und ist nur meine Meinung. Aber von meiner Seite ist damit alles gesagt und von deiner, Pies, glaube ich auch. Wenn du also nichts mehr zu ergänzen hast und ich deinen Standpunkt nicht missverstanden hab, wär das Thema damit wohl abgeschlossen, glaub ich.

[Flunky]

TechCityTrade ist der Tag. Erst wenn die genannte Tech erreicht ist, kann die Ressi gehandelt werden. getTechCityTrade() ist die Funktion dazu, die exposed to python ist.

Im SDK wird das dann so abgefragt, ob die Resource handelbar ist:
if (GET_TEAM(getTeam()).isHasTech((TechTypes)(GC.getBonusInfo((BonusTypes)iBonusProduced).get TechCityTrade())))

@Methode: ich hab dir zugestimmt, Boggy

[BoggyB]

TechCityTrade ist der Tag. Erst wenn die genannte Tech erreicht ist, kann die Ressi gehandelt werden. getTechCityTrade() ist die Funktion dazu, die exposed to python ist.

Im SDK wird das dann so abgefragt, ob die Resource handelbar ist:
if (GET_TEAM(getTeam()).isHasTech((TechTypes)(GC.getBonusInfo((BonusTypes)iBonusProduced).get TechCityTrade())))

Verstehe. Aber wenn wir darauf zugreifen, um festzulegen, dass bestimmte Ressis für das Händler-Feature nicht handelbar sind, dann schließen wir diese Ressi doch gleichzeitig vom Handel übers Diplofenster aus, und das wollen wir doch nicht?
Wobei man beim Fisch ja durchaus mit derselben Argumentation greifen könnte, aber regionale Söldner, Musik, Kunstlieder etc. sollten ja schon weiterhin handelbar sein

@Methode: ich hab dir zugestimmt, Boggy

Das hab ich auch so verstanden (abgesehen von der Sache, dass die Liste als Konstante am Anfang definiert werden sollte, wo ich dir aber auch zustimme). Hab ich irgendwas geschrieben, was anders klingt?
Ich fühl mich irgendwie doof, weil wir uns irgendwie dauernd missverstehen

[Flunky]

Wollten wir nicht den Handel übers Diplofenster komplett abschaffen?

Warum sollte Musik handelbar sein? Notenschrift gibt's doch noch nicht?

Fisch etc. kann ruhig handelbar sein, fürs Rollenspiel vielleicht nur mit Salz oder Räucherhütte Garum ist auch Fisch in handelbarer Form Oliven wurden ja auch nicht in der Form, wie sie auf Bäumen wachsen, durch die Gegend gekarrt. Sondern halt als Öl oder eingesalzen. Auch Berichte von regelmäßigen Viehtrieben über die Alpen sind mir nicht bekannt.

@Verstehen: Textkommunikation halt. Geht immer wieder schief^^

[BoggyB]

Wollten wir nicht den Handel übers Diplofenster komplett abschaffen?

Wollten wir? Jetzt wo du's sagst, war mal diskutiert, aber ich glaub nicht, dass sich das durchgesetzt hat Im MP hätte der neue Handel vielleicht sogar Potential, den Diplo-Ressihandel zu ersetzen, man hat die Ressi dann ja ein paar Runden in der Stadt zur Verfügung - geht das halt nur mit regelmäßigem Händlereinsatz und nur in den Städten, in denen der Händler ankommt, was ja aber eigentlich gar nicht mal so unrealistisch wäre Aber allein wegen der KI muss der Diplofenster-Handel drinbleiben, denk ich, sonst kann man sich ja gar keine Ressis mehr gezielt erhandeln.

Warum sollte Musik handelbar sein? Notenschrift gibt's doch noch nicht?

Keine Ahnung Stimmt eigentlich, aber wenn die Ressi nicht handelbar ist, hat man halt auch keinen Grund, mehr als eine davon zu erzeugen.

Fisch etc. kann ruhig handelbar sein, fürs Rollenspiel vielleicht nur mit Salz oder Räucherhütte Garum ist auch Fisch in handelbarer Form Oliven wurden ja auch nicht in der Form, wie sie auf Bäumen wachsen, durch die Gegend gekarrt. Sondern halt als Öl oder eingesalzen. Auch Berichte von regelmäßigen Viehtrieben über die Alpen sind mir nicht bekannt.

Von mir aus könnte Fisch auch, auch im neuen Handelsfeature, handelbar bleiben Pie sprach sich ja dagegen aus, weil Konservierung mit Salz etc. in dem Feature nicht inbegriffen sein sollte. Nur mit Salz und Räucherhütte in der Stadt ergibt ja eigentlich Sinn - wenn wir das so machen, sollte das aber auch genug Ressis betriffen, damit sich das überhaupt lohnt. Fisch, Krabben und Oliven, sagst du. Vieh wär ungünstig, denn das muss ja auch kultivierbar sein und dafür braucht man lebendes Vieh - ergibt keinen Sinn, dass man eine Kuhweide nur anlegen kann, wenn man die Kühe vorher eingesalzen hat

[Flunky]

Mhm, soll die Ressiverbreitung über den Händler laufen? "Viehtrieb" wär auch noch ne Einheit, die man einführen könnte

Wo soll die Reise hingehen? Das wird alles sehr MM-lastig. Ich mag an Civ eigentlich den hohen Abstraktionsgrad.

[BoggyB]

Ich mag an Civ eigentlich den hohen Abstraktionsgrad.

Durchaus Deshalb würd ich den Ressihandel übers Diplofenster auch weiterhin erlauben.
Ja, Kultivierung über den Händler war so gedacht.
Von dem, was bisher geplant/umgesetzt ist, hat sich der MM-Gehalt bereits erhöht, aber noch nicht extrem:

Beim Verbreitungsfeature kommt hinzu, dass man eine Ressi, bevor man sie verbreiten kann, auch einladen muss. Das ist noch nicht so viel MM, denn im frühen Spiel hat man eh noch nicht viel zu tun und im späten Spiel hat man wahrscheinlich schon so viele Ressis verbreitet, dass die Bedingung, sie in einer passenden Stadt einladen zu müssen, leicht zu erfüllen ist. Wenn uns das trotzdem zu viel ist, kann man ja an den Karten schrauben: Bisher ist es ja, glaub ich, so gedacht, dass man jede kultivierbare Ressi max. einmal in seiner Umgebung hat und den Rest verbreiten muss. Wollen wir den Aufwand beim Verbreitungsfeature reduzieren, platzieren wir einfach mehr Ressis auf den Karten - dann muss man immer noch kultivieren, aber nicht mehr so häufig.

Beim Händlerfeature kommt hinzu, dass der Händler nicht mehr aufgelöst wird (nicht wirklich mehr MM, man schickt ihn halt wieder zurück, statt nen neuen zu bauen) und dass man sich das Handelsgut auch selbst aussuchen muss. Fällt mir jetzt schwer zu sagen, ob das irgendwann nervig wird Kommt auch drauf an, wie viele Händler-Einheiten man gleichzeitig besitzen darf. Auf der einen Seite fänd ich es gut, wenn man nicht zu viele handelnde Händler gleichzeitig hat (im Moment sind sie ja auch auf 3 gleichzeitig beschränkt); aber gleichzeitig würde ich das Kultivierungsfeature dadurch nicht zu sehr beschränken wollen. Man könnte auch die Kultivierung wieder auf den Getreidekarren (Viehtrieb ^^) legen, dann könnte man auch unterscheiden zwischen Vieh zur Kultivierung -> braucht kein Salz, Vieh zum Verkauf -> braucht Salz (obwohl, man kann Vieh ja auch lebend handeln ). Andererseits hat man durch zwei Einheiten, die ähnlich fungieren, dann auch wieder mehr MM

[Pie]

Stimmt: Ich meinte eigentlich ODER wegen der Funktionssache. Hast du also verstanden
Weil du ja so gern Funktionen hast und gegen globale Variablen bist, was machst du eigentlich, wenn du in einer anderen Funktion ebenfalls die lNoBonusTrade-Werte brauchst? Ich glaube, das versteht sich dann von selbst, dass meine Methode dann die bessere ist. Anders wirds dann immer komplizierter.
Meine Methodik ist nicht einfacher. Sie ist optimal (für diesen Zweck).

Und wenn sich mal isTradeable() ändert und es mehrere Funktionen gibt, die lNoBonusTrade aufrufen, kommst du einfach nicht hinweg, diese Variable zu globalisieren.
Und wer, wenn nicht der Programmierer selbst, kann eine globale Variable verändern? Ich setze ja nicht Variablen namnes i, n, etc. global (was aber auch wurscht wäre)

Schau dir meine Naturkatastrophen-Funktion an. Alles wissenwerte ist in der Funktion drin. Genauso wie du es möchtest. Und auch genau dort brauch ich das Teil, wo ja pro 100 Jahren EINE Naturkatastrophe geschieht. Da wäre es falsch, die darin verwendenten statischen Variablen zu globalisieren.
Beim Händler aber, initialisiere ich im "schlechtesten" Fall 3x pro CIV pro Runde - also bei bis zu 40 CIVs (max.) - ein und dieselbe Variable (die ändert sich ja nie) 120x anstatt 1x.
Also mir als Programmierer wird da etwas übel.... das geht auf keine antike Kuhhaut (aus meinem Stall!). Andere programmieren so, das ist mir klar und das ist mir wurscht, aber ICH programmiere "anders". Ich hoffe, dass das klar ist, ich BIN penibel, was Codierung angeht. Vor allem, wenn ich damit zu tun hab
Weißt du, ich hab da grad nen super klugen externen Programmierer, der auf Webseiten seine Werte intern mit json aufruft. Da frag ich mich echt, was wohl in seinem Hirn vorgeht. Das ist kompletter Schwachsinn. Mit sowas hab ich tagtäglich zu tun. Ich bin kein casual programmer. Bitte verzeih. Ich bin strenger. Sonst wäre PAE wohl auch nicht das, was es gerade ist.

So. Sorry, für euch Mitleser für die technischen Floskeln hier. Nun wisst ihr, wie "altmodisch" oder "eigen" ich programmieren mag
Hab das bisjetzt auch niemandem verraten (brauchen).

--------------------

Garum wäre sowieso eine neue Bonusresi, die man hinzufügen könnte und die - glaub ich - in einer meiner todo-Listen steht.
Mir ist auch eingefallen, wie ich zu mehr Icons komme: Ich werde die territorialen Söldnerresis (Balearen, Kreta, Mars,...) mit nur 1 Symbol ausstatten. Dann hab ich wieder mehr Platz für andere.
Weil auch eine neue wichtige territoriale Bonuseinheit dazukommen wird: Alemannische Reiter in Westgermanien.

Die Frage ist jetzt nur: wie ich Garum bekommen soll: Nur mit Fisch geht nicht. Nur mit Salz auch nicht. Es bräuchte also eigentlich ein Gebäude, das Fisch und Salz benötigt. Oder?
Ich bin schon solange weg vom modden, dass ich gar nicht mehr die XML-Möglichkeiten von CIV kenne....

@Flunky: stimmt, Musik könnte ich eigentlich rausschmeißen. Eigentlich wollte ich damit die fahrenden Sänger symbolisieren, die den Dörfern Freude bereiten. Anders ging es früher ja nicht. Aber wenn das unklar ist oder nicht so rüberkommt, weg damit.

[BoggyB]

Weil du ja so gern Funktionen hast und gegen globale Variablen bist, was machst du eigentlich, wenn du in einer anderen Funktion ebenfalls die lNoBonusTrade-Werte brauchst? Ich glaube, das versteht sich dann von selbst, dass meine Methode dann die bessere ist. Anders wirds dann immer komplizierter.
Meine Methodik ist nicht einfacher. Sie ist optimal (für diesen Zweck).

Um das nochmal ausdrücklich zu sagen: Ich bin um Gottes Willen nicht gegen globale Variablen (auch wenn es mich stört, dass ich die in Python nicht als unveränderbar deklarieren kann, aber das ist was anderes). Ich befürworte in diesem Fall auch die Erstellung dieser lBonusNoTrade-Liste als globale Variable, und auf eben diese würde ich in einer anderen Funktion zugreifen, wenn ich sie brauche. Von daher versteht sich da nichts von selbst
Ich sage nur, dass zusätzlich zu dieser globalen Liste eine Methode isTradeable(), die "iBonus in lList" zurückgibt, sinnvoll, optimal und richtig ist. Aus den bereits erläuterten Gründen. Wie gesagt: Aus meiner Sicht ist dann, wenn man an der Eigenschaft "Handelbar" irgendwas ändern will, wenn man von außen (in einem anderen Feature) auf Eigenschaften des Features zugreifen will oder wenn sich jemand, der sich mit der Implementierung des Features gar nicht auskennt, an die Programmierung setzt, deine Lösung nicht optimal.

Weißt du, ich hab da grad nen super klugen externen Programmierer, der auf Webseiten seine Werte intern mit json aufruft. Da frag ich mich echt, was wohl in seinem Hirn vorgeht. Das ist kompletter Schwachsinn. Mit sowas hab ich tagtäglich zu tun. Ich bin kein casual programmer. Bitte verzeih. Ich bin strenger. Sonst wäre PAE wohl auch nicht das, was es gerade ist.

Für das Beispiel fehlt mir jetzt leider das Fachwissen

Die Frage ist jetzt nur: wie ich Garum bekommen soll: Nur mit Fisch geht nicht. Nur mit Salz auch nicht. Es bräuchte also eigentlich ein Gebäude, das Fisch und Salz benötigt. Oder?
Ich bin schon solange weg vom modden, dass ich gar nicht mehr die XML-Möglichkeiten von CIV kenne....

Mehrere Boni UND-verknüpft als Bedingung gehen nicht, glaub ich. Mehrere Gebäude als Bedingungen gehen aber, glaub ich. Vielleicht kann man es dadurch oder durch eine Verknüpfung der beiden irgendwie erreichen (z.B. brauch Fisch und irgendein Gebäude, das nur mit Salz gebaut werden kann - kA).

@Flunky: stimmt, Musik könnte ich eigentlich rausschmeißen. Eigentlich wollte ich damit die fahrenden Sänger symbolisieren, die den Dörfern Freude bereiten. Anders ging es früher ja nicht. Aber wenn das unklar ist oder nicht so rüberkommt, weg damit.

Musik entsteht, glaub ich, durch ein Gebäude, das nur mit dem griechischen Kultur-Kult gebaut werden kann, glaub ich. Wenn es jedenfalls fahrende Sänger symbolisieren soll, kam bei mir nicht rüber, nein Kann von mir aus auch weg.

[Pie]

Um das nochmal ausdrücklich zu sagen: Ich bin um Gottes Willen nicht gegen globale Variablen (auch wenn es mich stört, dass ich die in Python nicht als unveränderbar deklarieren kann, aber das ist was anderes). Ich befürworte in diesem Fall auch die Erstellung dieser lBonusNoTrade-Liste als globale Variable, und auf eben diese würde ich in einer anderen Funktion zugreifen, wenn ich sie brauche. Von daher versteht sich da nichts von selbst
Ich sage nur, dass zusätzlich zu dieser globalen Liste eine Methode isTradeable(), die "iBonus in lList" zurückgibt, sinnvoll, optimal und richtig ist. Aus den bereits erläuterten Gründen. Wie gesagt: Aus meiner Sicht ist dann, wenn man an der Eigenschaft "Handelbar" irgendwas ändern will, wenn man von außen (in einem anderen Feature) auf Eigenschaften des Features zugreifen will oder wenn sich jemand, der sich mit der Implementierung des Features gar nicht auskennt, an die Programmierung setzt, deine Lösung nicht optimal.

Ich finds nicht richtig. Das musst du jetzt akzeptieren. Es geht hier nur um eine Abfrage, ob etwas in einer Liste ist. Sonst nix. Dafür braucht man keine eigene Funktion zu schreiben.

Ich versteh es nur, wenn du mit isTradeable dann auch gleich überprüfst, ob die CIV überhaupt die Tech hat, die Resource handeln zu können. Dann macht die Funktion natürlich Sinn und dann ist es natürlich richtig. Hast du das etwa vor? Dann is gut.

Aber wenn du es lieber übers SDK machen willst, wieso dann nicht gleich? Ich weiß eh nicht, ob es sich auszahlt noch einen reinen Python-patch rauszubringen oder gleich ne PAE SDK Version.

------

Ja das mit Garum ist blöd. Vielleicht fällt euch ja was ein. Das ginge dann auch mit SDK

[BoggyB]

Ich akzeptiere das natürlich, auch wenn ich es schade finde, dass du zu den mMn bei der Methodenvariante bestehenden Vorteilen nie Stellung bezogen hast (warum die deiner Meinung weniger wiegen als die Nachteile). Es geht eben mMn nicht nur um eine Listenabfrage. Aber damit ist jetzt eigentlich von beiden Seiten alles gesagt.

Edit: Ach ja, aber ich "erwarte" hierauf jetzt auch keine Antwort, ganz im Gegenteil. Das Thema ist geklärt und du, Pie, hast mit deiner Zeit sicherlich Nützlicheres anzufangen

Von SDK hab ich nur leider keine Ahnung
---
Was fürs Garum ohne SDK denkbar wär, wär ein weiteres Gebäude dazwischen zu schalten, das nur mit Fisch bzw nur mit Salz gebaut werden kann, und das Garum-Gebäude benötigt dann dieses Vorgebäude und die andere Ressis. Fällt uns da irgendwas ein? Das Vorgebäude sollte natürlich auch allein betrachtet irgendeinen Sinn erfüllen, sonst ist es witzlos

[Flunky]

SDK ist kaum anders als Python. Halt C++-Code, na und? Eklig ist nur das Aufsetzen der Entwicklungsumgebung mit ner modernen IDE^^ Aber da kann Ramk uns sicher weiterhelfen. Ich habs jetzt dreimal gemacht und immer ein paar Stunden gekämpft, bis Visual Studio wieder alle Pfade so hatte, wie Civ es braucht. Könnte aber durchaus persönliche Verplantheit sein. Mal schauen, ob ich mir das Cross-compilen antue, oder trocken mitmach, solang ich kein Windows hab^^

---

Garum könnte man machen mit PrereqBonuses Fish und bWater. Also als Küstengebäude. Ab Konservierung. Salzwasser ist genug da.