FC-Dateien

In Dateien mit der Extension ".fc" werden die Feedbackeinheiten von Gebäudegrafiken definiert.
Wenn man deren Eigenschaften verändern will (und so wie ich über keinerlei Grafikbearbeitungskompetenz verfügt), muss man diese Dateien zunächst konvertieren und dann mit einem Texteditor die gewünschten Parameter und Werte eintragen.
Unter dieser Adresse findet sich dazu ein hilfreiches Tutorial (das allerdings beträchtliche Vorkenntnisse erfordert).

Trotz dieses Guides und trotz zusätzlicher Informationen, mit denen mich Lion_053 dankenswerterweise versorgt hat, scheitere ich an folgender Aufgabenstellung:
Eine Mod bringt ein neues Produktionsgebäude ins Spiel und verwendet dafür eine Vanilla Grafik, die bislang "nur" zu einem Ornament gehört hat. Das ist zwar grundsätzlich kein Problem, hat aber den unschönen Effekt, dass die zur Gebäudegrafik gehörenden Feedbackeinheiten (z.B. Personen, Tiere, ..) verschwinden, sobald die Produktion startet und der Spielstand neu geladen wird. Dank Lion habe ich gelernt, dass es zu jeder Animation in den fc-Dateien ein Variablenpaar (k, v) gibt, das dieses Verhalten steuert. Gemäß der Instruktionen habe ich jeweils k=1 (für Produktionsmodus) gesetzt und v unverändert belassen.
Leider funktioniert es trotzdem nicht, und ich vermute, dass hier noch weitere Änderungen erfolgen müssen.

Kann mir diesbezüglich jemand helfen?
( lion_053: Wenn Du das liest, kannst Du mir auch gern wieder per PM antworten. )

Zunächst mal danke allseits!

Taubenangriff

Interessantes Tool!
Allerdings für mich noch ohne Happy-End.

Der Reihe nach:
FantasticFeedback heruntergeladen, installiert, gestartet.
Meine fc-Datei (nennen wir sie x.fc) geöffnet (direkt). Den ersten Deiner beiden Screenshots konnte ich herbeiführen durch Klick auf "File". Dort unter "Supported Sequences" zusätzlich "work" ausgewählt.
Danach hat es aber geklemmt: Zu Screenshot 2 gelange ich nicht. D.h., mir werden keine "Actor Properties" angezeigt. Zwar kann ich links den Actor auswählen, wodurch darunter "Sequence 0" aufklappt. Aber dann geht es nicht weiter. Rechts bleiben die "Supported Sequences" stehen und auffällig ist auch, dass bei mir sowohl "Add Sequence" als auch der Papierkorb dauerhaft deaktiviert sind.
Dennoch habe ich mal in diesem Zustand abgespeichert und Anno gestartet. Ernüchterndes Ergebnis: Noch während des Ladens erfolgte der CTD.

Was mache ich falsch?

Edit:
Noch eine Auffälligkeit: Wenn ich nur eine fc-Datei öffne, gar nichts verändere und zurück speichere, nimmt die Dateigröße um ca. 50% zu.

Taludas

Bei meinen Ornamenten enthalten die cfg-Files überhaupt keine Sequence-Einträge.
Und, wie Taubenangriff schreibt, hätten diese ja auch gar nichts mit den fc-Dateien zu tun.

Kurzes Update zum für mich noch nicht ganz fantastischen FantasticFeedback:

Inzwischen habe ich gelernt, wie man bis zu den "Actor Properties" vordringen kann: Man darf die Buttons nicht zentral anklicken, sondern nur am Rand.
Ok, Mappings eingetragen, gespeichert, .....
.... Savegame gestartet und ... peng! ... wieder CTD bereits während des Ladens.

Ist es ein Fehler, direkt mit fc-Files zu arbeiten?
Sollte ich besser mit FileDBReader hin- und herkonvertieren?

Edit:
Inzwischen habe ich eine ganze Testserie durchgeführt mit einem halben Dutzend (Vanilla) fc-Files.
Das Ergebnis war immer gleich: Nach jeder Bearbeitung mit FantasticFeedback, egal welcher Art, bringt das Resultat das Spiel zum Absturz. Das passiert sogar dann, wenn gar nichts geändert, also nur geladen und gespeichert wird. Auf das Anschwellen der Dateigröße hatte ich zuvor schon hingewiesen. Der Crash erfolgt entweder beim Laden, wenn das betreffende Objekt bereits gebaut war, oder unmittelbar nach dem Bauen.

Taubenangriff

Mit dem Hinweis auf Dein Tool hast Du mich ja auch zum Testen aufgefordert: "..Braucht also sowieso mal Tester - probier dich gern dran".
Nun, das habe ich inzwischen reichlich getan, mehr als ich eigentlich wollte.
Mit dem ernüchternden Fazit, dass es nicht funktioniert. Denn, wie bereits erwähnt, bringt jede mit FantasticFeedback gespeicherte fc-Datei das Spiel augenblicklich zum Absturz, sobald das betreffende Gebäude ins Spiel kommt. Dies passiert sogar dann, wenn die Datei nur geöffnet und wieder gespeichert wurde.

Inzwischen habe ich noch ein wenig weiter ermittelt:
Wenn nicht im fc-, sondern im xml-Format gespeichert wird, kann man sehen, dass in den generierten CDATA-Blöcken kein Hex-Code, wie wohl zu erwarten wäre, sondern "normale" ASCII-Zeichen enthalten sind. Und genau an diesem Punkt spuckt FileDBReader beim Versuch, manuell von xml zu fc zu konvertieren, eine ganze Litanei kryptischer Fehlermeldungen aus und bricht die Konvertierung ab.
In einem Hexeditor wiederum lässt sich erkennen, dass beim direkten Speichern von fc-Files durch FantasticFeedback in die CDATA-Elemente Zeilenumbrüche eingefügt werden. Diese scheinen für die Abstürze verantwortlich zu sein, denn wenn man sie entfernt, bleiben die Crashs aus. Die Feedbackunits allerdings auch.

Vielleicht kannst Du mit diesen Resultaten und Erkenntnissen ja etwas anfangen.
Es wäre jedenfalls schön, wenn Du Dich dazu wieder meldest, und noch schöner, wenn wir die Kuh vom Eis kriegen.

In der Zwischenzeit versuche ich, eine Notlösung für mein Problem zu basteln:
Mit Hilfe von Serps genialer Hilfsmod "shared_OncePerSessionPerSaveLoad" möchte ich eine Mechanik erstellen, die bei jedem Laden eines Savegames die von der Problematik betroffenen Gebäude gegen Dummy-Klons aus- und sofort wieder zurücktauscht. Das hat den gleichen Effekt wie ein Neubau durch den Spieler und macht die Feedbacks im idle-Modus wieder sichtbar.

Hi,

1. Der Pfad ist korrekt eingetragen.

2. Damit ich das nicht missverstehe: Ist es korrekt, die fc-Datei direkt in FF (FantasticFeedback) zu öffnen und dann ebenso direkt wieder als fc-File zu speichern?

3. ta.zip
=> 2 Dateien:
- shaman_camp.fc (Vanilla Datei, weiß ad hoc nicht, wie die im Original heißt) vor dem Öffnen in FF
- shaman_camp_nach_ff.fc nach dem Speichern

4. bei den GuidVariationLists

Die FF Requirements sollten auch erfüllt sein:
- .net 6.0
- FileDBReader 3.0.1

Kein Happy-End in Sicht!

Es lag nicht an der Version von FileDBReader, ich hatte ohnehin die aktuelle und lediglich die Versionsnummer falsch ausgelesen.

Die Datei, die Du mir zurückgeschickt hast, crasht das Spiel ebenfalls.
War das die Original-Vanilla-Datei (10 KB), die Du durch FF geschleust hast? Deren Ursprungsname lautet übrigens "data/dlc06/graphics/buildings/ornamental/africa_ornaments_2x2_01.fc" .
Kannst Du evtl. mal testen, ob Du dieses Ornament nach dem FF-Durchlauf bauen kannst?
Hast Du eine Erklärung dafür, dass bei jedem FF-Erstdurchlauf die Dateigröße um ca. 50% anschwillt?

FF bietet ja auch an, die Dateien im xml-Format zu speichern. Was genau müsste man danach machen, um sie nach fc zu konvertieren?
Ein FileDBReader-Aufruf mit .. hextofc -f <file> provoziert einen Programmabbruch beim ersten CDATA-Block.

Nachtrag:
Auch Deine retour-Datei enthält jeweils einen Zeilenumbruch in den beiden GuidVariationLists-Blöcken und genau die bewirken die Crashs.
Wenn man sie entfernt, läuft das Spiel zwar, aber die Feedbacks erscheinen nicht.

Nur eine Spekulation:
Kann es sein, dass FF für Linux-Systeme geschrieben wurde?
Meine (einzige) Begegnung mit Linux liegt Äonen zurück, aber ich meine mich ganz dunkel zu erinnern, dass unter Linux Zeilenumbrüche anders codiert werden als im MS-Kosmos.

Tja, schade!

Nachdem das hier diskutierte Tool nicht funktionieren mag, zumindest nicht auf meinem System, und weil ich nicht über die Grafikfähigkeiten verfüge, mir eigene FeedbackUnits zu basteln, greife ich nun auf die zwischenzeitlich bereits erwähnte Notlösung zurück:
Mit Hilfe von Serps genialer Hilfsmod "shared_OncePerSessionPerSaveLoad" habe ich eine Mechanik erstellt, die bei jedem Laden eines Savegames die von der Problematik betroffenen Gebäude gegen Dummy-Klons aus- und sofort wieder zurücktauscht. Das hat den gleichen Effekt wie ein Neubau durch den Spieler und macht die Animationen im idle-Modus wieder sichtbar. Zwar nehmen die Gebäude dann die Produktion umgehend wieder auf, aber das würde sich auf die FeedbackUnits erst beim nächsten Savegame-Laden auswirken. Doch da schlägt Serps Triggermechanik wieder zu ..... da capo.
In Kürze wird ein Update meiner Debüt-Mod "Schätze der Mayas" erscheinen, wo ich erstmals von diesem Trick Gebrauch mache.

Ausdrücklich gedankt sei an dieser Stelle Serp für seine einzigartige und allen Moddern zur Verfügung gestellte Sammlung von Hilfsmods und für die zahlreichen Informationen und Tipps, mit denen er mich im persönlichen Dialog bereichert hat.

Hallo,

die gute Nachricht zuerst:
Der neue Schamane, den Du mir geschickt hast, crasht das Spiel nicht mehr, weder wenn sein Lager gebaut wird noch beim Laden, wenn es bereits im Spiel war.

Eine schlechte Nachricht gibt es (noch?) nicht, aber eine Frage:
Die Animation erscheint nur im idle-Modus. Liegt das daran, dass Du meinen ursprünglichen Wunsch, er möge auch im Produktionsmodus durch sein Lager spazieren, noch nicht umgesetzt hast mit FF, oder funktioniert dies nicht?

Auf jeden Fall bin ich, als Beta-Tester , auf die neue Version neugierig.

Noch ein Wort zu den Workarounds:
1. Diese wurden ja nicht primär wegen FF erforderlich, sondern weil ich unfähig bin, fc-Files selbst zu generieren oder zu ändern.
2. Deshalb hatte ich große Hoffnungen in FF gesetzt. Weil diese einerseits nicht erfüllt wurden, ich mich aber andererseits inzwischen so sehr in das Thema verbissen hatte, dass ich auf funktionierende FeedbackUnits nicht mehr verzichten wollte, habe ich in jene Trickkiste gegriffen.
3. Zwar wurde dies nur möglich mit Hilfe von Serps Konzept und Mechanik (s.o.), dennoch bin ich nun sogar ein wenig stolz darauf, es überhaupt hingekriegt zu haben.
4. Deshalb bleiben sie auch erst mal im Spiel (bei den "Mayan Treasures"), zumindest so lange, bis ich (hoffentlich) gelernt haben werde, die Animationen mit einem dann wohl funktionierenden FF selbst wunschgemäß zu domestizieren.

Apropos offene Fragen:
In einem anderen Thread hatte ich mich mal nach der Möglichkeit selbst definierter Erfolge erkundigt.
Du hast dies damals bejaht, mit der Einschränkung, dass sie nur sichtbar seien, solange die betreffende Mod aktiv ist.
Ok, zum Testen hab ich mir eine ganz billige Erfolgsstory gebastelt (Gebäude A 5x gebaut) und dazu ein Vanilla Achievement (aus der Enbesa Gruppe) geklont, doch der Erfolg erscheint nicht, weder ausgegraut noch eingefärbt nach Aufgabenerfüllung.
Die noch offene Frage lautete, ob dies etwas mit der Property "AchievementUPlayID " zu tun haben könnte. Falls ja, welcher Wert müsste hier eingetragen werden?
(Falls die Antwort irgendwie Arbeit macht, lass es gut sein - so wichtig ist die Spielerei auch wieder nicht.)

Leider kann ich immer noch kein "fantastisches Feedback" geben -
der Reihe nach:

Nach dem Test mit der Datei, die Du mir geschickt hast, habe ich die neue FF-Version herunter geladen und mit FileDBReader verknüpft.
Anschließend den Vanilla-Schamanen damit bearbeitet (Sequence-Typ "Work" hinzugefügt) und hoffnungsvoll das Spiel gestartet => Crash beim Laden.
Weitere Tests haben das gleiche Bild wie zuvor ergeben:
Jede fc-Datei, die ich durch FF schleuse, egal ob verändert oder nicht, bringt das Spiel zum Absturz, entweder schon beim Laden oder wenn das zugehörige Gebäude erstmals gebaut wird.
Im Anhang findest Du eine Datei, die FF unbearbeitet durchlaufen hat - wenn DU die laden kannst, hätten wir ein systemabhängiges Problem.

Zwischenfrage:
Warum ist das Spiel bei Grafikdateien derart zimperlich? Die kleinsten Fehler, etwa auch in cfg-Files, führen zum Crash. Bei Asset-Codes hingegen werden z.T. haarsträubende Fehler einfach ignoriert ...

Was meinst Du mit "Trickkiste ausmustern.."? Keine Helper-Mods mehr wie jene von Serp? Nur in Bezug auf Anno 117, oder soll sich da auch noch was bei 1800 ändern?

Licht am Ende des Tunnels!

Tatsächlich hatte ich wohl noch einmal eine alte Version installiert, allerdings von der gleichen URL, die Du hier verlinkt hast, und wo ich jetzt die richtige Version (Beta 0.5.6) gefunden habe. Im Programm selbst wird die Versionsnummer ja nicht angezeigt.

Ok, sofort getestet und ... hurra:
Der Schamane spaziert durch sein Camp und bestaunt die eigene Produktion (Liebespulver!). Und das persistiert auch nach dem nächsten Laden.
Eine (für mich) marginale Macke hat er allerdings noch: Im idle-Modus haut er sofort ab (also sobald seine Zaubertrankküche stillsteht). Damit kann ich gut leben, denn mein Ziel war ja, dass er nicht im Verborgenen arbeitet.

Nun werde ich das Ganze noch mit weiteren Feedbacks testen und, wenn die auch funktionieren, alles in meine Maya-Mod implementieren (= "Trickkiste ausmustern").

An dieser Stelle schon mal vielen Dank für ein fantastisches Tool und Deine Unterstützung!