DLL kreieren - Probleme, Hilferufe und Erfahrungsberichte

[Elwood]

, schön, dass du eine Lösung gefunden hast, aber für mich bist du jetzt im Bereich manigfaltiger böhmischer Dörfer , derartige Fragen sind was für koma oder ray, die sind beide richtig fit.

[Writing Bull]

Bei mir fällt der Kommentar leider noch extremer als beim Kollegen Elwood aus. Mir fällt dazu leider nur ein verstörtes "Häh?!" ein ...

@Elwood: Ja, neu aufsetzen geht auch. Darauf lief es bei mir leider auch hinaus. Ist nur eine verdammte Zeitverschwendung, wenn im Prinzip nur die richtige Projektdatei gleich dabei sein könnte

Wenn ich dich richtig verstehe, dann wärst du aber jetzt (oder in Bälde) in der Lage, ein DLL-Paket für TAC-2.03-Modder zu schnüren, oder? Das wäre doch super, dann hätten es künftige Generationen von TAC-Moddern nicht mehr so schwer wie du jetzt. Wir könnten das dann in den Tutorialthread für Modder packen. Was meinste?

[Ramkhamhaeng]

Das schüren des Paketes ist leider noch nicht mgl. Theoretisch ja, praktisch nein
Ich will euch nicht mit Details nerven, aber bei meiner derzeitigen Lösung muss sehr oft der gesamte Quelltext neu kompiliert werden. Das dauert dann mal eben 5 Minuten. Wäre alles richtig eingestellt, wären es nur ein paar Sekunden....
Ich bin mir aber sicher, dass in den letzten 8 Jahren dieses Problem schon behoben wurde. Muss es nur noch finden


@Ray, Koma: Habt ihr ein Makefile, welches die Klassen-Abhängigkeiten korrekt erfasst und bei der Änderung von Headern die betroffenen
Dateien neu kompiliert? Bei mir meckert der Linker, weil er immer noch gegen die alten Methoden linken möchte.

[raystuttgart]

@Ray, Koma: Habt ihr ein Makefile, welches die Klassen-Abhängigkeiten korrekt erfasst und bei der Änderung von Headern die betroffenen
Dateien neu kompiliert? Bei mir meckert der Linker, weil er immer noch gegen die alten Methoden linken möchte.

Ehrlich gesagt versteh ich dein Problem gar nicht.

Neue Methoden-Definition in den .cpp, entsprechende Methoden-Deklarationen in den .h, DLL neu kompilieren, gut ist.
Was da für Abhängigkeiten nicht erfasst werden sollen, ist mir schleierhaft.

[Ramkhamhaeng]

Na beispielsweise werden die Änderungen an Headerfiles überhaupt nicht erfasst, wenn man auf normalem Wege neu kompiliert. Dein Beispiel "neue Methoden-Definition + Deklaration" würde also schon mal gar nicht funktionieren, wenn man nicht alles komplett neu kompiliert.


Neues Problem: Ich habe mal versucht neue Yields einzufügen und bin nach dieser Anleitung vorgegangen:
http://forums.civfanatics.com/showthread.php?t=319070
Leider schmiert das Programm mit der Debug-Dll ab und ich lande im Asseblercode, weil er für den Bereich keinen Quellcode vorliegen hat.
Gibt es noch einen Trick zu beachten, der in dem Tutorial nicht erwähnt wurde?

[raystuttgart]

Es kommt extrem darauf an, was für einen neuen Yield du einführst.
Ist es ein Rohstoff (z.B. Tabak), eine produzierte Ware (z.B. Zigarren) oder ein abstraktes Konzept (z.B. Bildung).

Warum siehst du dir nicht einfach die bestehenden Waren im Source-Code an ?

Das bringt dich wahrscheinlich weiter als irgendwelche Tutorials.
(Die hab ich mir übrigens nie angesehen. Die werden nie und nimmer alle Abhängigkeiten aufführen, die es in einer anderen Mod - die sie gar nicht kennen - gibt.)

[Ramkhamhaeng]

@Ray: Die Waren habe ich mir nat. schon im Code angeschaut. Es soll sich wie eine produzierbare Ware verhalten und beim Kopieren der Codeteile habe ich mich an YIELD_EDUCATION orientiert. Das wäre dann zwar ein abstraktes Konzept, aber so viel Unterschiede habe ich da im Code eh nicht gefunden.
Angepasst hatte ich dann CvEnums.h, CyEnumsInterface.h, CvPlayer.cpp, CvPlayerAI.cpp, CvCity.cpp, CvCityAI.cpp und CIV4YieldInfos.xml. ( In CvGameTextMgr.cpp findet sich YIELD_EDUCATION auch, aber da sind ihmo keine Änderungen notwendig.)
Der größte Teil der Änderungen bestand ja nur daraus, die switch-Anweisungen um das neue Yield zu erweitern.

Habe ich eine Datei übersehen?

[raystuttgart]

Der größte Teil der Änderungen bestand ja nur daraus, die switch-Anweisungen um das neue Yield zu erweitern.

Ja, aber das muss richtig gemacht werden.
Außerdem muss natürlich auch das XML dazu 100% passen. (z.B. Reihenfolge der Yields)

Um Python Änderungen (falls notwendig) kannst du dich auch nachträglich kümmern.
(Solange da kein Gebäude ins Spiel kommt, sollte es noch nicht krachen.)

Habe ich eine Datei übersehen?

Normalerweise solltest du mit deiner Entwicklungsumgebung alle relevanten Stellen im Source-Code aufstöbern können.
(Falls du das Yield, dass du als Vorlage benutzt, richtig gewählt hast.)

Mit sowas wie Notepad++ solltest du im XML und im Python alle Stellen aufstöbern können, die du anpassen musst.

[Ramkhamhaeng]

Um das zuende zu bringen: Wie sich herausgestellt hat, lag der Crash an einer anderen Änderung, die ich am Tag zuvor gemacht hatte. (Laden von neuem Terrain-Feature führte zum Crash). D.h. beim Einfügen von neuen Yields gibt es doch keinen Trick, den man beachten müsste. Man muss nur alle Textstellen einer ähnlichen Ressource heraussuchen und für seine Ressource kopieren.

[Ramkhamhaeng]

Schneller als erwartet stehe ich vor der nächsten Hürde
Seitdem ich die die neuen Ressourcen eingefügt habe, stimmen die Symbole für Stärke, Bewegungspunkte usw. nicht mehr. An den GameFonts-Dateien habe ich aber gar nichts geändert.
Auf dem Screenshot z.B. unten rechts zu erkennen. Ich bin sicher nicht der erste mit dem Problem

[raystuttgart]

An den GameFonts-Dateien habe ich aber gar nichts geändert.

Das musst du aber leider.
Der Mechanismus, wie Icons aus den Gamefonts zugwiesen werden ist ziemlich bescheuert.

Pass aber auf den Alpha-Kanal (Marker-Pixel) auf.

Ich bin sicher nicht der erste mit dem Problem

Das Problem ist alt bekannt.
Ich hab damals für Kakao auch ziemlich mit den Gamefonts gekämpft.

Einen neuen Yield einbauen kann ziemlich fieselig werden.
DLL, XML, Gamefonts, manchmal Buttons, manchmal Python (CityScreen, AdvisorScreens, ...)

Das gute daran:
Hast du es ein paar Mal gemacht ist es kinderleicht.

[Writing Bull]

An den GameFonts-Dateien habe ich aber gar nichts geändert.

Falls du die GameFonts-Datei ändern musst, dann nimm dieses Tool. Extrem leicht und schnell zu bedienen, einwandfreie Ergebnisse.

[raystuttgart]

Falls du die GameFonts-Datei ändern musst, dann nimm dieses Tool. Extrem leicht und schnell zu bedienen, einwandfreie Ergebnisse.

Jupp, das Tool ist super.

Beim simplen Austauschen von Icons kann da eigentlich nichts schiefgehen.

Beim Hinzufügen / Erweitern kann es aber dennoch passieren, dass Reihenfolgen der Icons verrutschen.
(Kommt extrem drauf an in welcher Zeile und wie viele man hinzufügt.)

Zusätlich DXTBmp ist meiner Meinung nach ein Muss, wenn es um größere Arbeiten in den Gamefonts geht.
(Da sieht man den Alpha-Kanal und Marker-Pixel richtig schön.)

Mit irgendwas anderem als dem GameFontEditor und DXTBmp würde ich die Gamefonts nicht anfassen.

[Ramkhamhaeng]

Das musst du aber leider.

Ich hab doch als erstes sofort die Version aus dem SVN wiederhergestellt. So einfach ist die Lösung leider nicht.

[raystuttgart]

Ich hab doch als erstes sofort die Version aus dem SVN wiederhergestellt.

Versteh leider nicht, was du damit meinst bzw. was du wann wo getan hast.
(Ich hab ja mit eurem SVN und eurer Entwicklung nichts zu tun.)

Wenn du auf den kompletten alten TAC-Stand zurückgegangen bist, kann ich nicht nachvollziehen, warum du Probleme mit Icons haben solltest ...