macht der gallische Späher alleine auch nicht
macht der gallische Späher alleine auch nicht
Ein Fall für Galileo Mystery.
Pucc's Lets Plays BASE 6.0: #1 #2 #3 #4 #5
Download von BASE 6.4 [D]: HIER (klick mich!) (Stand: 08.07.2022)
idee: bewegung wird nur eingeschränkt wenn keine Stadt nur ein feld luftlinie entfernt ist.
Pucc's Lets Plays BASE 6.0: #1 #2 #3 #4 #5
Download von BASE 6.4 [D]: HIER (klick mich!) (Stand: 08.07.2022)
ich stelle mir gerade folgende frage: angenommen, eine umweg-einheit würde nicht von der russischen eigenschaft gebremst werden. dann könnte diese ja auf jeden fall die stadt angreifen. macht dann der stack ebenfalls den umweg oder greift er die stadt dann ohne straßennutzung an? dürfte er eigentlich nicht, weil sich dann der stack im falle eines rückzugs spalten würde. d.h. der kommandopanzer würde die stadt angreifen und der reststack würde mitfahren ohne angreifen zu können. in der nächsten runde nutzt der kommandopanzer dann wieder die straße und der reststack fährt wieder mit und kann wieder nicht angreifen.
daraus folgt: es ist eben doch ohne russische eigenschaft problematisch und es muss dann auch im original civ4 problematisch sein, wenn man kommandoeinheiten mit nicht-kommandoeinheiten mischt.
werds nachher mal testen, wenn ich wieder zuhause bin.
Pucc's Lets Plays BASE 6.0: #1 #2 #3 #4 #5
Download von BASE 6.4 [D]: HIER (klick mich!) (Stand: 08.07.2022)
Ich habe das Problem nie anders gesehen, aber im Zusammenhang mit der russischen Eigenschaft ist es noch viel schlimmer. Ich schaue es mir noch heute genau an.
Klar ist es schlimmer, aber eben nicht nur mit Russland problematisch. Vorausgesetzt, der Stack verhält sich so (bleibt immer zusammen).
Pucc's Lets Plays BASE 6.0: #1 #2 #3 #4 #5
Download von BASE 6.4 [D]: HIER (klick mich!) (Stand: 08.07.2022)
Pucc's Lets Plays BASE 6.0: #1 #2 #3 #4 #5
Download von BASE 6.4 [D]: HIER (klick mich!) (Stand: 08.07.2022)
Ich bin bisher nur auf den Spuren des entsprechenden Codes.
CvSelectionGroup::groupPathTo(int iX, int iY, int iFlags) enthält eine Funktion generatePath(plot(), pDestPlot, iFlags)), aber dann wird auf eine nicht SDK-Funktion zugegriffen.
Zur Not bekommt Russland eben freies Uran anstelle der Verlangsamung. Der Schaden bei Bewegung kann ja bleiben.
Nerven würde das Problem aber weiterhin in Kommandomischstacks.
Pucc's Lets Plays BASE 6.0: #1 #2 #3 #4 #5
Download von BASE 6.4 [D]: HIER (klick mich!) (Stand: 08.07.2022)
Es sieht bisher nicht danach aus, dass man irgend was mit der Wegfinungsroutine machen kann. Ich schau noch mal morgen drüber, aber alle genutzten Funktionen greifen früher oder später auf nicht SDK-Funktion zu, so das man nicht die Routine anpassen kann.
Geändert von rucivfan (15. Juni 2013 um 08:42 Uhr)
Vielleicht müsste man mal testen, ob das Problem auch in BTS auftritt.
Pucc's Lets Plays BASE 6.0: #1 #2 #3 #4 #5
Download von BASE 6.4 [D]: HIER (klick mich!) (Stand: 08.07.2022)
Edit: Also das Problem existiert auch in BTS! Dann muss man damit wohl einfach leben. Schlage deshalb vor:
Wenns keine Einwände gibt, wäre der Patch dann soweit fertig.- Russisches Reich: Feindliche Angriffe und Bewegungen sind nicht mehr auf 1 pro Runde beschränkt; Schaden auf 3% (Max 15%) erhöht; freie Ressource Uran bei Erforschung von Kernspaltung hinzugefügt
Geändert von Cybah (15. Juni 2013 um 02:23 Uhr)
Pucc's Lets Plays BASE 6.0: #1 #2 #3 #4 #5
Download von BASE 6.4 [D]: HIER (klick mich!) (Stand: 08.07.2022)
Kann man den Schaden nicht je Bewegungsfeld machen? So wäre Kav nicht im Vorteil. Den Schaden müsste man dann nicht erhöhen.
http://forums.civfanatics.com/showthread.php?t=418050
Der Link bestätigt, was ich weiß und auch was ich noch nicht wusste.
Das ist die Initialisierung der Pathfinders. Es werden Pointer zu den Funktionen pathDestValid, pathHeuristic, pathCost, pathValid, pathAdd, routeValid übergeben. Vielleicht liegt das Problem in den Funktionen. Diese liegen zum Glück in der CvGameCoreUtils.cpp. Ich würde Russlands-Änderung aber erstmal so nehmen. Russland kann später seinen alten Bonus wiederbekommen, wenn ich was finde. pathCost scheint mir die beste Anlaufstelle, weil die Kosten für eine Bewegung nicht korrekt sind, aber auch routeValid wäre ein Kandidat.Code:void CvMap::setup() { PROFILE("CvMap::setup"); gDLL->getFAStarIFace()->Initialize(&GC.getPathFinder(), getGridWidthINLINE(), getGridHeightINLINE(), isWrapXINLINE(), isWrapYINLINE(), pathDestValid, pathHeuristic, pathCost, pathValid, pathAdd, NULL, NULL); gDLL->getFAStarIFace()->Initialize(&GC.getInterfacePathFinder(), getGridWidthINLINE(), getGridHeightINLINE(), isWrapXINLINE(), isWrapYINLINE(), pathDestValid, pathHeuristic, pathCost, pathValid, pathAdd, NULL, NULL); gDLL->getFAStarIFace()->Initialize(&GC.getStepFinder(), getGridWidthINLINE(), getGridHeightINLINE(), isWrapXINLINE(), isWrapYINLINE(), stepDestValid, stepHeuristic, stepCost, stepValid, stepAdd, NULL, NULL); gDLL->getFAStarIFace()->Initialize(&GC.getRouteFinder(), getGridWidthINLINE(), getGridHeightINLINE(), isWrapXINLINE(), isWrapYINLINE(), NULL, NULL, NULL, routeValid, NULL, NULL, NULL); gDLL->getFAStarIFace()->Initialize(&GC.getBorderFinder(), getGridWidthINLINE(), getGridHeightINLINE(), isWrapXINLINE(), isWrapYINLINE(), NULL, NULL, NULL, borderValid, NULL, NULL, NULL); gDLL->getFAStarIFace()->Initialize(&GC.getAreaFinder(), getGridWidthINLINE(), getGridHeightINLINE(), isWrapXINLINE(), isWrapYINLINE(), NULL, NULL, NULL, areaValid, NULL, joinArea, NULL); gDLL->getFAStarIFace()->Initialize(&GC.getPlotGroupFinder(), getGridWidthINLINE(), getGridHeightINLINE(), isWrapXINLINE(), isWrapYINLINE(), NULL, NULL, NULL, plotGroupValid, NULL, countPlotGroup, NULL); }