[TAC] Spielgeschwindigkeit, Rundenzahl, Siegbedingungen

**raystuttgart** · 02. Juli 2011, 16:39

@koma:

Ich gebe dir mal ein Beispiel, wie ich die ein oder andere Codestelle anpassen würde.

Stelle bei iRefuseToTalkWarThreshold, wo nur der relative zeitliche Spielverlauf berücksichtigt wird:

Code:

if (isNative())
		{
			iRefuseDuration *= 2;
			int iGameTurns = GC.getGameINLINE().getEstimateEndTurn();
			int iCurrentTurn = GC.getGameINLINE().getGameTurn();

			if (!GET_TEAM(getTeam()).AI_isChosenWar((GET_PLAYER(ePlayer).getTeam())))
			{
				iCurrentTurn += iGameTurns / 2;
			}

			iRefuseDuration *= std::max(0, iCurrentTurn - iGameTurns / 12);
			iRefuseDuration /= iGameTurns;
		}

Anpassung mittels CvGameAI::AI_adjustedTurn(int iTurn) :

Code:

if (isNative())
		{
			iRefuseDuration *= 2;
			int iGameTurns = GC.getGameINLINE().AI_adjustedTurn(GC.getGameINLINE().getEstimateEndTurn());
			int iCurrentTurn = GC.getGameINLINE().AI_adjustedTurn(GC.getGameINLINE().getGameTurn());

			if (!GET_TEAM(getTeam()).AI_isChosenWar((GET_PLAYER(ePlayer).getTeam())))
			{
				iCurrentTurn += iGameTurns / 2;
			}

			iRefuseDuration *= std::max(0, iCurrentTurn - iGameTurns / 12);
			iRefuseDuration /= iGameTurns;
		}

Jetzt hast du an dieser Stelle folgendes:
Lösung, die sowohl den relativen zeitlichen Spielfortschritt berücksichtig, wie auch den potentiellen Wachtumsfortschritt, den ein Spieler in dieser Zeit erreichen kann.

Einverstanden ?
(Oder siehst du einen Denkfehler.)

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

Nehmen wir mal ein paar XML-Einstellungen als Beispiel.

Einstellungsbeispiel 1:
<iGrowthPercent>100</iGrowthPercent>
<iTrainPercent>100</iTrainPercent>
<iConstructPercent>100</iConstructPercent>
<iTurnsPerIncrement>900</iTurnsPerIncrement>

Einstellungsbeispiel 2:
<iGrowthPercent>200</iGrowthPercent>
<iTrainPercent>200</iTrainPercent>
<iConstructPercent>200</iConstructPercent>
<iTurnsPerIncrement>1800</iTurnsPerIncrement>

Eine Spielsituation in Beispiel 1 bei 10 Runden, sollte nun mit einer Spielsituation in Beispiel 2 mit 20 Runden vergleichbar sein.

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

Und ja, mir ist bewusst, dass wir duchgehend von 300 Runden auf 900+ Runden erhöht haben, ohne die anderen Werte entsprechend anzupassen.

Das halte ich aber nach wie vor nicht für kritisch, wenn man dafür sorgt, dass der Spieler auch die volle Spieldauer ausnutzen kann,
sprich man der KI beibringt bei der längeren Spieldauer auch etwas später den Unabhängigkeitskrieg zu suchen.

Die Werte sollen ja lediglich dafür sorgen, das gewisse Faktoren darauf angepasst sind, wie weit das Spiel bereits fortgeschritten ist.

Wenn du aber unbedingt möchtest, dann habe ich auch gegen diese Variante nichts einzuwenden:
(Bitte nach rechts scrollen, da gibt es nochmal eine Änderung in rot.)

Code:

if (isNative())
		{
			iRefuseDuration *= 2;
			int iGameTurns = GC.getGameINLINE().AI_adjustedTurn(GC.getGameINLINE().getEstimateEndTurn() * 300 / GC.getGameINLINE().getGameTurn());
			int iCurrentTurn = GC.getGameINLINE().AI_adjustedTurn(GC.getGameINLINE().getGameTurn() * 300 / GC.getGameINLINE().getGameTurn());

			if (!GET_TEAM(getTeam()).AI_isChosenWar((GET_PLAYER(ePlayer).getTeam())))
			{
				iCurrentTurn += iGameTurns / 2;
			}

			iRefuseDuration *= std::max(0, iCurrentTurn - iGameTurns / 12);
			iRefuseDuration /= iGameTurns;
		}

Hierbei würde sich die KI bei jeder Spieldauer gleich verhalten.
(Mit 300 als durch Vanilla gegebenen Ausgangswert fürs Balancing.)

Die einzig andere Stelle, die ich sehe, die man noch ähnlich anpassen sollte ist folgende:

Code:

iPeaceRand *= GC.getGameINLINE().getGameTurn() + GC.getGameINLINE().getEstimateEndTurn() / 5;
iPeaceRand /= std::max(1, GC.getGameINLINE().getEstimateEndTurn());

Wie ich sehe, hast du ja bereits an diversen Stellen eine Anpassung mit " / 3 " vorgenommen.

Die könnte man aber gegen ein allgemeiner gültiges:

Code:

 * 300 / GC.getGameINLINE().getGameTurn()

austauschen, damit das bei späteren Szenarien auch noch passt.

Da wäre man doch innerhalb kürzester Zeit fast ohne Risiko damit durch ?

(Mit 4-Augen-Prinzip zum Check.)

**koma13** · 02. Juli 2011, 19:00

Ray, danke dir. Aber ich würde es begrüßen, wenn du mir überlässt, welchen Ansatz ich wähle. Ich bin schließlich auch derjenige, der es umsetzen muß.

Wie ich sehe, hast du ja bereits an diversen Stellen eine Anpassung mit " / 3 " vorgenommen.

Die könnte man aber gegen ein allgemeiner gültiges:

Code:

* 300 / GC.getGameINLINE().getGameTurn()

austauschen, damit das bei späteren Szenarien auch noch passt.

Da wäre man doch innerhalb kürzester Zeit fast ohne Risiko damit durch ?

Das geht aber nur gut, solange iGrowthPercent etc. nicht angepasst wird.

Schau dir mal CvGame::setMaxTurns und CvGame::getMaxTurns an. Diese Funktionen werden nur zur Bestimmung der Siegbedingungen genutzt. Wenn wir dort ansetzen, lässt sich die ganze Problematik relativ einfach umgehen. Ein Anpassen der einzelnen Diplomatiewerte, wie es von dir vorgeschlagen wird, wäre dann nicht notwendig.

Hier, CvGame.cpp Z.218:

Code:

if (bValid)
{
     setMaxTurns(getEstimateEndTurn() - getGameTurn());
}

**Writing Bull** · 02. Juli 2011, 19:06

Ich freue mich, dass du hier eifrig und mit konkreten Vorschlägen mitdiskutierst, ray! Das kann uns nur helfen. Das Thema ist ja nicht ganz unwichtig. Und dass an einer Debatte im Projektforum auch Leute beteiligt sind, die nicht selber an der technischen Umsetzung beteiligt sein werden, ist ja auch nicht ungewöhnlich - das ist ja meistens der Fall. Und das trägt mit zur Qualität des Projekts bei.

**raystuttgart** · 02. Juli 2011, 19:08

Zitat von koma13

Ray, danke dir. Aber ich würde es begrüßen, wenn du mir überlässt, welchen Ansatz ich wähle. Ich bin schließlich auch derjenige, der es umsetzen muß.

Ist klar, ich mache ja nur Vorschläge und äußere meine Meinung.
Vorschreiben kann ich dir ja nix.

Dennoch sei mir erlaubt zu sagen, dass es mir nicht gefällt, die Siegbedingungen vom Rundenlimit zu entkoppeln.

(Eine Meinung ist ja erlaubt.

)

Zitat von koma13

Das geht aber nur gut, solange iGrowthPercent etc. nicht angepasst wird.

Dann könnte man da auch AI_adjustedTurn nutzen.

GC.getGameINLINE().AI_adjustedTurn(GC.getGameINLINE().getEstimateEndTurn() * 300 / GC.getGameINLINE().getGameTurn())

P.S.:

Ich bin immer noch der festen Ansicht, dass es verhindert werden sollte, dass in den Formeln sowas passieren kann:
(Das gibt es nämlich bisher nicht.)

Startwert iCurrentTurn in Formel > Startwert iGameTurns in Formel

Wenn das passiert, hat man nämlich nur ein Problem gegen ein anderes getauscht.

**koma13** · 02. Juli 2011, 19:40

GC.getGameINLINE().AI_adjustedTurn(GC.getGameINLINE().getEstimateEndTurn() * 300 / GC.getGameINLINE().getGameTurn())

Ich weiß gar nicht, was ich dazu sagen soll. Damit trifften wir immer weiter vom Vanilla-Ansatz ab.

Ich habe hier aber auch keine Zeit stundenlang über diese Problematik zu diskutieren, dazu gibt es noch zu viele andere Probleme in der DLL (z.B. die Söldner).

Solange du mir also keinen handfesten Grund nennst, der gegen meinen Ansatz spricht, habe ich nur wenig Interesse daran weiter über technische Details zu diskutieren. Und als Grund reicht mir dein Bauchgefühl, das etwas schief gehen könnte, nicht aus.

**raystuttgart** · 02. Juli 2011, 19:45

Zitat von koma13

Solange du mir also keinen handfesten Grund nennst, der gegen meinen Ansatz spricht, habe ich nur wenig Interesse daran weiter über technische Details zu diskutieren. Und als Grund reicht mir dein Bauchgefühl, das etwas schief gehen könnte, nicht aus.

Nehmen wir mal das hier:

Code:

if (isNative())
		{
...
			int iGameTurns = GC.getGameINLINE().getEstimateEndTurn();
			int iCurrentTurn = GC.getGameINLINE().getGameTurn();
...
		}

Wenn ich dich richtig verstehe, wären bei deinem Plan solche Kombinationen möglich:

int iGameTurns = 300 (Diesen Wert willst du ja fest machen...)
int iCurrentTurn = 500

Sowas gibt es bisher nicht !

Wenn ich dich richtig verstehe, hat man mit deinem Vorschlag in den Formeln über weite weite Teile Werte drin, wie es sie bisher nie gab.

Bei 900 Runden Spielzeit, wäre in diesem einem Beispiel 600 Runden lange (also 2/3 des Spiels) die Situation gegeben

iCurrentTurn > iGameTurns (aktuelle Runde > max. Spielzeit)

Bisher ist iCurrentTurn immer kleiner iGameTurns.

Wie gesagt,

iCurrentTurn > iGameTurns

als Ausgangswert für die Berechnung der Formeln gibt es bisher keine einzige Runde.

Wenn das nicht zu anderem Verhalten der KI führt, als wir es gewohnt sind, dann weiß ich auch nicht ...
(Die ersten 300 wären vielleicht für alle Gamespeeds gleich, aber was ist mit den restlichen 600 + x ? )

Oder habe ich dich falsch verstanden ?
(Dann möchte ich mich entschuldigen.

)

Ich halte jetzt auch schon meine Klappe.

**koma13** · 02. Juli 2011, 20:12

Sowas gibt es bisher nicht !

Doch, gibt es.

Nach Auslösung ein Siegbedingung wird der Spieler gefragt, ob er weiterspielen möchte oder nicht. Und genau ab da tritt der von dir geschilderte Fall ein.

Schon allein die Tatsache, daß diese Abfrage überhaupt existiert, deutet doch darauf hin, daß in der DLL dieser Fall berücksichtigt wird.

**raystuttgart** · 02. Juli 2011, 20:17

Zitat von koma13

Doch, gibt es.

Nach Auslösung ein Siegbedingung wird der Spieler gefragt, ob er weiterspielen möchte oder nicht. Und genau ab da tritt der von dir geschilderte Fall ein.

Schon allein die Tatsache, daß diese Abfrage überhaupt existiert, deutet doch darauf hin, daß in der DLL dieser Fall berücksichtigt wird.

koma, ich glaube wir haben unsere Meinungen klar geschildert.

Mir ist es wichtig, dass im Normalen Spiel (bis man seine gewählten Siegesbedingungen erfüllt hat) auch über 300 Runden hinaus ein vernünftiges KI-Verhalten existiert.

Es werden auf jeden Fall mit deiner Änderung Werte während der normalen Spieldauer erzeugt, die es sonst vielleicht nur in einem Endlos-Spiel gibt ...
(Ein Endlos-Spiel habe ich noch nie gesehen / ausprobiert.)

Ich bin nach wie vor der festen Überzeugung, dass dein geschildeter Plan ein Fehler ist.
(Aus meiner Sicht beseitigst du vielleicht ein winzig kleines Balancing-Problem in den ersten 300 Runden und führst ein viel größeres in den Runden danach ein.)

Genau die selben Codestellen (im Bereich Diplomatie), die du durch deinen Plan optimieren willst, sehe ich dadurch ab Runde 300 verschlechtert ...
Ist dir das Verhalten nach Runde 300 egal ?

Wenn du meinst, du hast Recht und gehst das Risiko bewusst ein, dann mach das.

Du bist der Modder der das umsetzt und ich bin nur ein Konsument.
Wenn ich dich nicht überzeugen kann, dann lebe ich damit.

**koma13** · 03. Juli 2011, 01:06

Wenn du meinst, du hast Recht und gehst das Risiko bewusst ein, dann mach das.

Die Umsetzung kostet mich keine 20 min (im Gegensatz zur Diskussion hier). Deswegen würde ich das gerne erstmal so probieren wollen. Ihr könnt dann die DLL testen und auf Unstimmigkeiten hinweisen. Dadurch nehmt ihr mir ein Teil der Arbeit ab und ich habe so mehr Zeit für andere Dinge.

Sollte sich bei den Tests ein Fehlverhalten der KI ab Runde 300 abzeichnen, können wir uns immer noch Gedanken über andere Lösungen machen.

**Writing Bull** · 03. Juli 2011, 09:48

Zitat von koma13

Achtung Spoiler:

Um das obenbeschriebene Problem bezüglich der Diplomatiewerte zu lösen, sollte es also ausreichen, die Siegbedingungen vom Rundenlimit abzukoppeln. Damit könnten wir die SG auf Vanilla-Niveau zurückführen und könnten das Zeitlimit für die Siegbedingungen individuell einstellen, z.B auf die jetzt in TAC üblichen 900 Runden.

Dazu würde es sich anbieten in Civ4GameSpeedInfo einen neuen Eintrag "iVictoryTurnLimit" einzuführen, mit dem das Zeitlimit der Siegbedingungen dann festgelegt werden kann.

Vielen Dank für die Erklärungen, koma!

Wenn ich dich richtig verstehe, dann würde das bisherige Rundenlimit weiterhin in der Civ4GameSpeedInfo in den GameTurnInfos festgelegt, aber die "Macht" dieses Rundenlimits wäre reduziert. Es wäre nur noch ein technisches Rundenlimit, ein interner, für den Spieler unsichtbarer Wert, den das Programm für verschiedene Berechnungen nutzt (z.B. dafür, die Auswirkungen mancher Diplomatiewerte zu berechnen). Dieses interne Rundenlimit würden wir bei der Geschwindigkeit TAC-Normal zurück auf den Vanillawert "300" setzen.

Zusätzlich gäbe es jetzt ein zweites Rundenlimit, das ebenfalls in der Civ4GameSpeedInfo justiert wird, aber in einem neuen Eintrag iVictoryTurnLimit. Dieses Siegrundenlimit würden wir bei der Geschwindigkeit TAC-Normal auf den gewohnten Wert "900" setzen. Das Siegrundenlimit würde das interne Rundenlimit bei einer speziellen Aufgabe ablösen, nämlich dabei, die Rundenzahl festzulegen, bis zu der die Unabhängigkeit ausgerufen werden muss, um die Möglichkeit zu behalten, einen Unabhängigkeitssieg erringen zu können. Dem Spieler wird ingame lediglich das Siegrundenlimit, nicht aber das interne Rundenlimit angezeigt.

Ist das so korrekt dargestellt, koma?

Ein paar Fragen/Anmerkungen habe ich noch dazu:

Das Siegrundenlimit müsste natürlich auch für die drei anderen Siegvarianten gelten, also für den Vorherrschaftssieg, den Industrialisierungssieg und den Punktesieg (oder "Zeitsieg"). Insbesondere beim Punktesieg müsste man unbedingt prüfen, dass das Programm nicht nach Ablauf des internen Rundenlimits einen Punktesieger kürt.
Im Infoscreen "Siegbedingungen" (F8) steht ja ganz oben ein Rundenzähler. Bei Spielstart mit der Geschwindigkeit TAC-Normal steht dort z.B. in Runde 1 der Eintrag "Noch 900 Runden!". Was würde dort nach der von dir vorgeschlagenen Änderung stehen? Meines Erachtens nach sollte dort unbedingt das Siegrundenlimit angezeigt werden. Dass es ein internes Rundenlimit gibt, sollte der Normaluser überhaupt nicht erfahren - das würde ihn nur verwirren.
Wird derzeit eigentlich eine Rundenuhr eingeblendet, wenn das derzeitige Rundenlimit zwar abgelaufen, der kurz zuvor ausgerufene Unabhängigkeitssieg aber noch im Gange ist? (Ich weiß das nicht, weil ich das bisherige Rundenlimit nie ausschöpfe.) Sollte es eine solche Rundenuhr geben, dann müsste natürlich sichergestellt sein, dass sie nicht bereits nach Ablauf des internen Rundenlimits anspringt, sondern erst nach Erreichen des Siegrundenlimits.
Ich habe leider immer noch nicht verstanden, welche Angaben das Spiel für die Kalenderjahre und Kalendermonate verwenden wird. (Diese Angaben sind derzeit in den GameTurnInfos justiert, das heißt, sie würden übers interne Rundenlimit ausgelesen.)

**koma13** · 03. Juli 2011, 10:52

Wenn ich dich richtig verstehe, dann würde das bisherige Rundenlimit weiterhin in der Civ4GameSpeedInfo in den GameTurnInfos festgelegt, aber die "Macht" dieses Rundenlimits wäre reduziert. Es wäre nur noch ein technisches Rundenlimit, ein interner, für den Spieler unsichtbarer Wert, den das Programm für verschiedene Berechnungen nutzt (z.B. dafür, die Auswirkungen mancher Diplomatiewerte zu berechnen). Dieses interne Rundenlimit würden wir bei der Geschwindigkeit TAC-Normal zurück auf den Vanillawert "300" setzen.

Zusätzlich gäbe es jetzt ein zweites Rundenlimit, das ebenfalls in der Civ4GameSpeedInfo justiert wird, aber in einem neuen Eintrag iVictoryTurnLimit. Dieses Siegrundenlimit würden wir bei der Geschwindigkeit TAC-Normal auf den gewohnten Wert "900" setzen. Das Siegrundenlimit würde das interne Rundenlimit bei einer speziellen Aufgabe ablösen, nämlich dabei, die Rundenzahl festzulegen, bis zu der die Unabhängigkeit ausgerufen werden muss, um die Möglichkeit zu behalten, einen Unabhängigkeitssieg erringen zu können. Dem Spieler wird ingame lediglich das Siegrundenlimit, nicht aber das interne Rundenlimit angezeigt.

Ist das so korrekt dargestellt, koma?

Das Siegrundenlimit müsste natürlich auch für die drei anderen Siegvarianten gelten, also für den Vorherrschaftssieg, den Industrialisierungssieg und den Punktesieg (oder "Zeitsieg"). Insbesondere beim Punktesieg müsste man unbedingt prüfen, dass das Programm nicht nach Ablauf des internen Rundenlimits einen Punktesieger kürt.

Das sollte kein Problem sein. Das Rundenlimit für die Siegbedinungen wird an einer einzigen Stelle definiert und dann auf alle Siegbedingungen angewendet.

Im Infoscreen "Siegbedingungen" (F8) steht ja ganz oben ein Rundenzähler. Bei Spielstart mit der Geschwindigkeit TAC-Normal steht dort z.B. in Runde 1 der Eintrag "Noch 900 Runden!". Was würde dort nach der von dir vorgeschlagenen Änderung stehen? Meines Erachtens nach sollte dort unbedingt das Siegrundenlimit angezeigt werden. Dass es ein internes Rundenlimit gibt, sollte der Normaluser überhaupt nicht erfahren - das würde ihn nur verwirren.

Zur Zeit wird dort nur das Rundenlimit ausgelesen. Das müsste über Python also angepasst werden.

Wird derzeit eigentlich eine Rundenuhr eingeblendet, wenn das derzeitige Rundenlimit zwar abgelaufen, der kurz zuvor ausgerufene Unabhängigkeitssieg aber noch im Gange ist? (Ich weiß das nicht, weil ich das bisherige Rundenlimit nie ausschöpfe.) Sollte es eine solche Rundenuhr geben, dann müsste natürlich sichergestellt sein, dass sie nicht bereits nach Ablauf des internen Rundenlimits anspringt, sondern erst nach Erreichen des Siegrundenlimits.

Es gibt ja jetzt schon eine eigene Variable für das Zeitlimit der Siegbedinungen (iMaxTurn). Diese Variable wird auch für die Berechnung der Rundenuhr verwendet. Wenn diese Variable in der DLL nicht mehr mit dem Rundenlimit gleichsetzt wird, sondern wie geplant über einen XML-Wert definiert werden kann, sollte es damit keine Probleme geben.

Ich habe leider immer noch nicht verstanden, welche Angaben das Spiel für die Kalenderjahre und Kalendermonate verwenden wird. (Diese Angaben sind derzeit in den GameTurnInfos justiert, das heißt, sie würden übers interne Rundenlimit ausgelesen.)

Entscheidend ist hier iMonthIncrement. Wenn wir also die Vanilla-Werte übernehmen, kehren wir auch wieder zu den dort verwendeten Kalendereinstellungen zurück.

**Writing Bull** · 03. Juli 2011, 11:22

Zitat von Writing Bull

Würde das bedeuten, dass nach Ablauf der 300 Runden das mit Kalenderjahr und -monat angezeigte Datum "einfriert"?

Zitat von koma13

Nein. Man würde gar nicht merken, daß das offizielle "Rundenlimit" abgelaufen ist.

Zitat von Writing Bull

Ich habe leider immer noch nicht verstanden, welche Angaben das Spiel für die Kalenderjahre und Kalendermonate verwenden wird. (Diese Angaben sind derzeit in den GameTurnInfos justiert, das heißt, sie würden übers interne Rundenlimit ausgelesen.)

Zitat von koma13

Entscheidend ist hier iMonthIncrement. Wenn wir also die Vanilla-Werte übernehmen, kehren wir auch wieder zu den dort verwendeten Kalendereinstellungen zurück.

Verstehe ich dich richtig, dass dann in Zukunft bis Runde 300 exakt die Kalenderangaben der Vanilla-Version verwendet werden und dann ab Runde 301 der Kalender im selben Tempo fortläuft? Das würde ja dann bedeuten, dass wir irgendwann mit Kürassieren durchs 21. Jahrhundert reiten. Den Rest deines Konzepts finde ich überzeugend (

) - aber hier bräuchten wir noch einen rettenden Einfall.

Ich weiß, derzeit ist es seltsam, dass die Revolutionen meist atmosphärisch zu früh stattfinden. Die meisten Spieler bringen ihre Neue Welt bei TAC irgendwann im Laufe des 17. Jahrhunderts zur Unabhängigkeit. Das ist meist ein paar Jahrzehnte zu früh. Aber das ist allemal weniger störend als eine Karavelle, die das Millennium erlebt.

Im Zweifelsfall wäre es hier wohl am einfachsten, auch den Kalender an das Siegrundenlimit zu koppeln.

**koma13** · 03. Juli 2011, 11:33

Das würde ja dann bedeuten, dass wir irgendwann mit Kürassieren durchs 21. Jahrhundert reiten. Den Rest deines Konzepts finde ich überzeugend ( ) - aber hier bräuchten wir noch einen rettenden Einfall.

In Civ4 werden Jahresabstände mit steigendender Rundenanzahl ja immer geringer. Das funktioniert bestimmt auch bei Colonization. Dazu sollte es reichen, den Eintrag in GameTurnInfos in mehrere Einträge aufzuteilen. Schau dir einfach an, wie das bei Civ4 in der Civ4GameSpeedInfo.xml gelöst ist.

**Writing Bull** · 03. Juli 2011, 22:23

Interessante Idee.

Unabhängig, ob das auf diese Weise klappt oder nicht: Selbst wenn der Kalender in der DLL an das interne Rundenlimit und nicht an das Siegrundenlimit gekoppelt ist, kann man ja über die xml beliebige Kalenderwerte eintragen. Das heißt: Setz das ruhig um. Für den Kalender finden wir immer eine xml-Lösung.

The Joker · 04. Juli 2011, 07:38

Zitat von koma13

Doch, gibt es.

Nach Auslösung ein Siegbedingung wird der Spieler gefragt, ob er weiterspielen möchte oder nicht. Und genau ab da tritt der von dir geschilderte Fall ein.
Schon allein die Tatsache, daß diese Abfrage überhaupt existiert, deutet doch darauf hin, daß in der DLL dieser Fall berücksichtigt wird.

Kurze Zwischenfrage:
Kann man eigentlich den Text "XY hat die Siegbedingungen in der Katerogie Unabhängigkeit erreicht" verschwinden lassen?
Denn wenn ich tatsächlich noch "eine" Runde weiterspielen möchte, dann habe ich den weißen Schriftzug die ganze Zeit vor der Nase.

Umfrageergebnis anzeigen: Nutzt ihr die Spielgeschwindigkeit "TAC ExtraLager"?

Thema: [TAC] Spielgeschwindigkeit, Rundenzahl, Siegbedingungen

Themen-Optionen

Berechtigungen