[TAC] Bugdokumentation & Allgemeines Brainstorming

[koma13]

koma hat wahrscheinlich mittlerweile sowieso eine Lösung gefunden, um sowohl Bug zu beheben, wie auch den Exploit zu verhindern

Zu der hier diskutierten Lösung mit dem Exploit (die ich jetzt so erstmal umgesetzt habe) gibt es aus meiner Sicht nur zwei Alternativen:

1) Die Angriffsfähigkeit der Karacke und Galeone wieder entfernen. Das wär das einfachste. Zumal die KI mit dieser Doppelfunktion aus Militär- und Transportschiff erstmal nichts anfangen kann.

2) Für die Karacke (und Galeone) einen eigenen UnitAI-Typ erstellen. Damit könnte man genau definieren, wie die KI den Einheitentyp verwendet (z.B keine Verkäufe an die Ureinwohner). Das wäre auch der reguläre Weg, wenn man die Idee, einem Transportschiff die Möglichkeit zum Angriff zu geben, richtig hätte umsetzen wollen...

[raystuttgart]

Ich persönlich empfinde diesen "Exploit" (Hinterhalt von Karacken oder Galeonen in Ureinwohnerdorf) als sooo extrem harmlos, dass ich da nichts weiter ändern würde.

1. Auf die Idee werden die meisten User gar nicht kommen.
2. Die genannten Einheiten sind zu schwach, um daraus wirklich einen vernünfigen Effekt zu erzielen.
3. Ich sehe auch keine vernünftige / passende / authentische Alternative.

Meine Meinung:
Passt so.

[Writing Bull]

der Exploit ist im Vergleich zum Bug - meiner Meinung nach - vernachlässigbar.

[Der Kantelberg]

Ich persönlich empfinde diesen "Exploit" (Hinterhalt von Karacken oder Galeonen in Ureinwohnerdorf) als sooo extrem harmlos, dass ich da nichts weiter ändern würde.

Wenn das für alle Schiffe mit Frachtraum gilt, können das auch Kaperfahrer. Und ob man die vor feindlichen Fregatten bei Indianern verstecken kann oder nicht, ergibt in bestimmten Spielsituationen durchaus einen Unterschied. Ich hab oft ne recht große Kaperflotte, die vor feindlichen Küsten patroulliert.

[Ronnar]

Nein, Kaperfahrer sind sowieso ausgenommen glaube ich. Da greift die Funktionalität isHiddenNationality() => Alle Einheiten mit versteckter Nationalität können gar keine fremde Häfen anlaufen, damit auch keine Ureinwohnerdörfer.
Ich gehe davon aus, an dem Teil des Codings hat koma nichts verändert.

[raystuttgart]

Ronnar hat da meines Wissens Recht.

Kaperfahrer können bei (neuen Versionen von) TAC keine Ureinwohnerdörfer mehr betreten.

Ich glaube, das hat koma vor einer Weile korrigiert.
Ich erinnere mich da dunkel an einen Bug.
Soviel ich weiß, geht das in Vanilla und älteren TAC-Versionen noch.

@koma und W.B.:
Wann war denn das nochmal ?
Oder täusche ich mich komplett ?

@Kantelberg:
Danke fürs Mitdenken.

[Writing Bull]

Alle Einheiten mit versteckter Nationalität können gar keine fremde Häfen anlaufen, damit auch keine Ureinwohnerdörfer.
Ich gehe davon aus, an dem Teil des Codings hat koma nichts verändert.

Ronnar hat da meines Wissens Recht.

Kaperfahrer können bei (neuen Versionen von) TAC keine Ureinwohnerdörfer mehr betreten.
Ich erinnere mich da dunkel an einen Bug.

Im pdf-Handbuch von TAC 2.01 steht:

Fixing: Kaperfahrer können nun unabhängig von ihrem Standort ohne Kriegserklärung in
fremde Territorien segeln

Wenn ich mich richtig erinnere, konnte es früher passieren, dass Kaperfahrer zwar von feindlichem Territorium aus in ein Ureinwohnerdorf fahren konnten, aber nicht mehr zurück in das feindliche Territorium. Sie steckten fest. Das haben wir auf die oben zitierte Weise gefixt. Das heißt, dass Kaperfahrer trotz ihrer versteckten Nationalität sehr wohl Ureinwohnerdörfer befahren können. Ich habe das schnell mit der aktuellen Arbeitsversion getestet, es ist tatsächlich so.

[raystuttgart]

Das heißt, dass Kaperfahrer trotz ihrer versteckten Nationalität sehr wohl Ureinwohnerdörfer befahren können. Ich habe das schnell mit der aktuellen Arbeitsversion getestet, es ist tatsächlich so.

Ok, da hab ich mich echt getäuscht.
Dann war das was komplett anderes.
(Sorry fürs verwirrt sein .)

Wenn Kaperfahrer aber früher schon Ureinwohnerdörfer betreten konnten, dann hat das mit komas Bugfix eh nichts zu tun.
(Daran hat der Fix für den Performance-Bug dann ja nichts geändert.)

Passt ja alles.

[Ronnar]

Stimmt, das war schon vor dem Fix so. Hab's gerade getestet. Aber früher war das mal anders, oder?
Dann wird meine Kaperfahrerstrategie gegen die KI künftig noch wirksamer

[raystuttgart]

Zum Thema

* Bürgerautomatisierung soll bei Stadtgründung ausgeschaltet sein

Wie ist denn die Default-Einstellung bei "Bürgerautomatisiserung"?
(Also die Voreinstellung.)

Falls diese auf "Ein" steht, könnte man folgendes überlegen:
(Falls auf "Aus", sollte sich das Thema ja erledigt haben.)

Die DEFAULT-Einstellung ist einfach "Bürgerautomatisiserung aus".
(So könnte man die bei Wunsch pro Stadt einschalten.)

Allerdings weiß ich nicht, wie der Rest der Community das lieber will ?

Default = ein oder Default = aus ?

Hi Leute,

leider funktioniert das so nicht.

Es gibt KEINE Defaulteinstellung.

"Bürgerautomatisiserung ein/aus" ist eine AKTION und kein ZUSTAND der Stadt.

Was heißt das:

Die Einstellung (Klicken des Buttons) wirkt sich NUR auf die im Moment in der Stadt tätigen Einheiten aus. (Die werden gesperrt und können von der KI nicht mehr versetzt werden.)

Alle weiteren Einheiten, die nachher dazu kommen, können weiterhin von der KI versetzt werden.

Es ist also KEINE globale Stadteinstellung, sondern nur eine Einstellung für die im Moment in der Stadt tätigen Einheiten.
(Für alle Einheiten, die nachher dazu kommen, hat das KEINE Auswirkung.)

Es wäre theoretisch möglich, daraus eine globale Einstellung zu machen, nur bin ich mir nicht sicher, ob das gut ist.
Ehrlich gesagt, glaube ich das Gegenteil.

Stellt euch vor jemand spielt so:

Er optimiert am Anfang die ersten Siedler.
Die sperrt er dann.
Bei den nächsten, will er aber, dass sie von der KI nach Bedarf gesetzt werden, weil er sich um die Stadt nicht mehr kümmern will.

Würde ich einen Zustand daraus machen, zerstöre ich sowas.

@W.B.:
Streich den Punkt bitte von der Liste.
Ich möchte hier nichts umsetzen, wo ich Spielverhalten von bestimmten Spielern kaputt mache.
Da bleibt dann meiner Meinung nach das Mikromanagement lieber so wie es ist.

Der jetzige Zustand erlaubt ein viel feineres Einstellen für einzelne Einheiten.
Ich dachte zuerst selber, das wäre eine Einstellung für die gesamte Stadt, wie die Produktionsautomatisierung.
Dem ist nicht so.

[BeckerC1972]

Stellt euch vor jemand spielt so:

Er optimiert am Anfang die ersten Siedler.
Die sperrt er dann.
Bei den nächsten, will er aber, dass sie von der KI nach Bedarf gesetzt werden, weil er sich um die Stadt nicht mehr kümmern will.

Nur muss er sich gerade WEGEN des Eingreifens der KI wieder um Stadt kümmern - denn gerne verschiebt die KI ja gerade wieder irgendeine Einheit, wenn zum Beispiel eine Kathedrale fertig wird.

Würde ich einen Zustand daraus machen, zerstöre ich sowas.

Man könnte ja auch beide Varianten anbieten. Ist ja auch so schon angesprochen worden. Genau wie bei den automatisierten Pionieren.

Da bleibt dann meiner Meinung nach das Mikromanagement lieber so wie es ist.

Wie, hier jetzt mal keine Abstimmung? ^^

Der jetzige Zustand erlaubt ein viel feineres Einstellen für einzelne Einheiten.

Wieso?

[raystuttgart]

Man könnte ja auch beide Varianten anbieten. Ist ja auch so schon angesprochen worden. Genau wie bei den automatisierten Pionieren.

Wenn jemand das Thema angehen will, hab ich nichts dagegen.
Ist mir persönlich nur zuviel Aufwand, für zu wenig Nutzen.
Ich selber, werde da keine Zeit mehr reinstecken.

Wie gesagt, leider funktioniert das hier komplett anders.
Sowas wie eine "Default-Einstellung" gibts halt nicht.

[BeckerC1972]

Wenn jemand das Thema angehen will, hab ich nichts dagegen.
Ist mir persönlich nur zuviel Aufwand, für zu wenig Nutzen.
Ich selber, werde da keine Zeit mehr reinstecken.

Wie gesagt, leider funktioniert das hier komplett anders.
Sowas wie eine "Default-Einstellung" gibts halt nicht.

Ok, deutliche Botschaft.

Einen Beitrag von BeckerC1972 zum Thema Gründerväter habe ich in den Thread zu Gründervätern verschoben. - W.B.

[Writing Bull]

Ich kann mir gut vorstellen, dass es schon in mittlerer Zukunft TAC-Kartenszenarien mit fixen Völkern und individuellen Events gibt. Mir juckt's da in den Fingern, sowas zu basteln. Solche Szenarien wären dann nicht mehr kompatibel mit der TAC-Grundversion, sondern müssten separat heruntergeladen und installiert werden.

Das ist ja eine gute Idee! Es wäre doch bestimmt möglich, für einzelne Szenarien Hauptbildschirme zu entwerfen, die vom speziellen Motiv her zum jeweiligen Szenario passen.

An so etwas habe ich auch schon oft gedacht. Mein Traum wäre eine Art RFC für TAC.

Schön, dass ich nicht der einzige bin, der sich für sowas begeistern kann.

Ehrlich gesagt, habe ich seit TAC 2.02 den Eindruck, dass wir beim Spielen auf Zufallskarten allmählich auf Grenzen stoßen, was unsere Spielräume für Verbesserungen betrifft. Es gibt eigentlich nur noch zwei Sachen, die mir für Zufallskarten richtig fehlen: die neue Handelsroutenverwaltung, die koma versprochen hat, und das Neubalancing der Ureinwohner-Oberhäupter, das Pfeffersack durchführen wird. Alles andere, was auf der To-Do-Liste steht, läuft für mich bestenfalls unter nice to have. Die Betonung liegt auf "bestenfalls" - denn ich bin fest davon überzeugt, dass ein Spiel nicht besser, sondern schlechter wird, wenn man es mit hübschen, aber unwichtigen Features inflationär zukleistert.

Ich könnte mir gut vorstellen, dass wir nach dem Release von TAC 2.03 einen Schlussstrich unter diesen Teil des Projekts ziehen und sagen: "So, das ist unsere Mod fürs Spielen mit Zufallskarten." Danach kommt noch ein finaler Patch mit Bugfixings (falls notwendig), aber mehr nicht.

Dann könnten wir (wie bei Gründung des Projekts geplant) die zweite Etappe starten und Szenarien bauen. Beispiele: ein Wildwest-Szenario in Nordamerika - der Kampf um Brasilien - die Niederwerfung der Azteken oder Inka - die europäischen Kolonialkriege um die nordamerikanische Ostküste usw.

Diese Szenarien hätten (zumindest in Teilen) spezifische Völker, Oberhäupter, Achievements, Events, Quests, Gebäude, Einheiten, Interfacegrafiken usw. Formal würden wir jedes Szenarium separat zum Download anbieten. Es gäbe jeweils zwei Downloadpakete zur Auswahl:
* ein Komplettpaket aller Dateien mit einem Installer
* ein Teilpaket der für dieses Szenarium veränderten Dateien, das man manuell über eine Kopie von TAC 2.03 drüberinstallieren müsste

Was denkt ihr darüber?

[Stöpsel]

Ich könnte mir gut vorstellen, dass wir nach dem Release von TAC 2.03 einen Schlussstrich unter diesen Teil des Projekts ziehen und sagen: "So, das ist unsere Mod fürs Spielen mit Zufallskarten." Danach kommt noch ein finaler Patch mit Bugfixings (falls notwendig), aber mehr nicht.

Das löst bei mir im ersten Moment zwar etwas Unbehagen aus, aber eines dürfte klar sein:

Die Szenarien dürften so komplex sein, dass es nicht vernünftig wäre, an mehreren Projekten gleichzeitig zu arbeiten. Das oberste Ziel jedes Szenario-Projektes sollte sein, dass es so ausgeklügelt und abwechslungsreich ist, dass man es noch nach dem zehnten Spiel spannend findet. Möglicherweise passen bestimmte Punkte der To-Do-Liste zu bestimmten Szenario-Projekten.


Edit: Was ist RFC?