Ist die neue Poleis denn wieder mit der normalen/Debug-DLL spielbar?
Ist die neue Poleis denn wieder mit der normalen/Debug-DLL spielbar?
Ich habe in den vergangenen Tagen zwischen Keine DLL/Debug-DLL-Mit-18-Spielern/Releease-DLL-Mit-18-Spielern hin-und hergewechselt ohne dass
mir ein Problem aufgefallen wäre.
Gab es ein spezielles Problem?
Falls es um ein nicht-technisches Problem ging:
Viele Seevölker-Einheiten machten mir das Leben schwer und da das Spiel bei mir sehr langsam läuft bin ich nicht über Runde 20 gekommen. Aussagekraft ist also nur recht begrenzt ^^
Jetzt hab ich einenSchaue ich mir heute Abend an!
Code:Traceback (most recent call last): File "CvEventInterface", line 23, in onEvent File "CvEventManager", line 326, in handleEvent File "CvEventManager", line 2131, in onEndGameTurn File "PAE_Trade", line 883, in doUpdateCitiesWithSpecialBonus File "CvUtil", line 631, in getScriptData MemoryError
Also ich persönlich spiele nie ohne "New Random-Seed-Option". Wenn es nur zum Testen ist ... schüff ... muss es wohl sein. Ich will euch das Leben ja nicht schwerer machen, als es eh schon ist. Aber bitte!!! Nur zum testen und nachher ja nicht vergessen es wieder einzuschalten. Sonst heule ich und mir wäre das schöne Spiel kaputt.
Zum Scenario Update: Habe fertig.
Soll heißen,
- der Smal Limes Germanicus ist upgedatet und die Römer kommen nun mit ihren Kosten klar.
- der Limes Germanicus ist upgedatet und die Römer kommen nun mit ihren Kosten klar. In dieser Version auch wieder ohne die Furt. Habe mir die Arbeit noch einmal gemacht, damit es dabei ist.
- die PAE_Barbaricum_RiseOfGreekPoleis ist auch upgedatet und noch verbessert.
Ich muss nun nur noch heute Abend alle drei auf die 18´er DLL zurücksetzen. Spiele nur noch mit der 40 ziger und habe daher damit daran gearbeitet. Ist ja nicht viel Arbeit.
Das kann ich bestimmt bis 22.00 Uhr schaffen. Vielleicht schon vorher, aber ich will nicht zu viel versprechen. Reicht das?
Grüße John
Die letzte Version hier im Thread ließ sich mit der 18er nicht laden, weil zu viele Civs eingestellt waren oder so. Hab mich nicht näher mit beschäftigt.Zitat von Ramkhamhaeng
Ein neuer Versuch mit dem neuen Startsave: Markus v.Chr. 283 (Runde 547).
Wenn ich die Fehlermeldung aus Antwort 2227 nocheinmal bekomme dann melde ich mich wieder bevor ich die Fehlermeldung wegklicke.
Markus1978
PAE-Neuling
Storys:
Abgeschlossene Storys: Wo: Civ4 - Einzelspieler-Storys Titel: PAE Julius Caesar - Sieg oder Niederlage Ergebnis: Niederlage
Abgeschlossene Storys: Wo: Civ4 - Einzelspieler-Storys Titel: PAE Szenario: PAE_LimesGermanicusSmall - Chaos ohne Ende wie man es nicht macht! Ergebnis: Sieg
OkJetzt hab ich einen
Code:Traceback (most recent call last): [...]
Klar!
Zu den GreeKPoleis: ziehst du vielleicht in Erwägung auf die wichtigen Modernisierungen Bogenschützen oder Speerkrieger/kämpfer zu stellen. Sieht sonst eigenartig aus, wenn da alles modernisiert ist, wo doch rundherum Barbaren sind. Und man startet da total ungeschützt, obwohl jede Runde Barbaren ins Land kommen...
Pie's Ancient Europe (PAE)
Erlebe mit dieser CIV IV Mod(ifikation) hautnah das Zeitalter der Antike bis ins letzte Detail!
Mit bahnbrechenden Erweiterungen und vielen ein- und erstmaligen Features.
- Pie's Ancient Europe (letztes Update: 22.12.2022)
... im Übrigen bin ich der Meinung, dass Karthago wieder aufgebaut werden muss!
Antworte dir gleich dazu im Threat Scenario PAE Barbaricum RiseOfGreekPoleis.
Grüße John
Hier die Scenario Dateien für die neue PAE Version die wir ja erst noch testen:
Grüße John
P.S. Die Unterstriche die du gerne haben wolltest kopieren sich scheinbar so beim hochladen nicht mit. Aufpassen und die Scenarionamen noch nachträglich wieder damit versehenen Pie.
Da Pie noch einen Wunsch hatte, noch einmal neu eingestellt.
Geändert von JohnDay (19. Juli 2017 um 17:11 Uhr)
Leider kann ich die Fehlermeldung mit dem ersten Spielstand bei mir nicht provozieren. (Da andere Zufallszahlen produziert werden, wenn man die Kampf-Animationen aktiviert, habe ich beide Varianten getestet.) Über die Ursachen, warum ich es nicht nachstellen kann, kann ich wie meistens nur spekulieren...
Hake die Sache daher leider erst einmal als ungelöst ab.
Der Fehler ist auch glitschig wie ein Aal und hängt wahrscheinlich nicht direkt mit dem Code zusammen. Entweder ist nicht genug Speicher vorhanden (unwahrscheinlich, da Fehler früh aufritt) oder es wird auf Speicher zugegriffen, der nicht mehr allokiert ist.Jetzt hab ich einen
Code:Traceback (most recent call last): File "CvEventInterface", line 23, in onEvent File "CvEventManager", line 326, in handleEvent File "CvEventManager", line 2131, in onEndGameTurn File "PAE_Trade", line 883, in doUpdateCitiesWithSpecialBonus File "CvUtil", line 631, in getScriptData MemoryError
Flunky legt im init()-Bereich von PAE_Trade eine Liste von Stadt-Objekten an. Ich könnte mir vorstellen, dass diese Objekte irgendwann, wenn intern mal wieder Speicher aufgeräumt wird, ihre Verbindung zu den DLL-Gegenstück verlieren. Um das Abzufangen sind im Code schon viele „pCity.isNone()“-Abfragen, aber vielleicht reicht das nicht?!
Es ist mir leider nicht gelungen einen Test zu konstruieren, mit dem ich das nachstellen kann, aber folgendes kann ich angeben, um die möglich Gefährlichkeit zu demonstrieren:
Überraschenderweise gibt die letzte Zeile False aus. Intern existiert das Objekt noch und man kann z.B. pCity.getPopulation() aufrufen und bekommt ne Zufallszahl. Beim Schreiben/Lesen vom Stadtnamen passiert (augenscheinlich) nichts.Code:pPlayer = gc.getPlayer(0) pCity = pPlayer.initCity(10,10) pPlayer.raze(pCity) # Abriss print(pCity.isNone())
Ich kann mit isNone() also gar nicht erkennen, dass die Stadt zerstört wurde.
Ich kann sogar ein paar Runden spielen und danach immer noch auf das Objekt zugreifen. Aber irgendwann kommt dann eine Aufräumaktion oder nen Pointer wird neu vergeben und es wird problematisch.
Die Liste ist garnicht unbedingt nötig, die kann auch durch nen Zähler ersetzt werden. Dadurch muss nur ründlich über die Städte auf der Karte iteriert werden, was ja nicht besonders teuer ist.
Das gleiche Problem betrifft auch Einheiten.
Code:pPlayer = gc.getPlayer(0) pUnit = pPlayer.firstUnit(True)[0] print(type(pUnit)) <class 'CvPythonExtensions.CyUnit'> print(pUnit.getUnitType()) 14 print(pUnit.getName()) Bautrupp print(pUnit.isNone()) False pUnit.kill(False, -1) print(pUnit.isNone()) False print(pUnit.getUnitType()) 14 print(pUnit.getName()) Bautrupp // Jetzt habe ich im Spiel eine neue Runde eingeleitet und siehe da... print(pUnit.getName()) Sklaven print(pUnit.getUnitType()) 242 //=> Das Python-Objekt ist jetzt mit einer ganz anderen Einheit verknüpft.
In dem konkreten Fall schon, aber das Problem tritt sicher auch an anderer Stelle auf. Weißt du ob die [Stadt|Einheit].isNone()-Abfrage wirklich mal True zurück gibt? (Ich glaube ja, bin mir aber nicht sicher.)
Evtl. könnte man isNone()-Abfragen durch 'plot().getX() == -1' ersetzen/ergänzen. Letztere sind wahr, nachdem man eine Stadt/Einheit gekillt hat.
Löst aber nicht das Problem, dass die Variable plötzlich auf eine andere Einheit zeigt. Globale Variablen könnten generell problematisch sein.
Also CvUnit hat auch noch ne isDead(), um die Lebenspunkte zu testen.
CvCity/CvUnit.kill() zerstört das Objekt tatsächlich nicht, sondern löscht nur die Referenz aus dem Array. Solang man keine alten Referenzen hält also kein Problem.
Die isNone()-Abfrage ist relevant, wenn man irgendwelche IDs hat und damit Objekte abruft. Die IDs können Schrott sein und der DLL-to-Python-Getter gibt dann eben ein None-Objekt zurück.
€: hab den Umbau ungetestet gepusht.
PAE_Barbaricum_RiseOfGreekPoleis konnte nicht gelesen werden
€: PAE neustarten und den Beschreibungs-Textkey sowie ein paar Leerzeilen löschen haben geholfen. Was davon?
Geändert von Flunky (17. Juli 2017 um 22:21 Uhr)
Berechtigungen
Zitieren