Content-Tool fernsteuern um Rollbandtexturen zu erzeugen?

Da bin ich wieder, während die ganze Welt Bonner B-Wagen fährt sitze ich beim Testen und versuche der Versuchung zu widerstehen.

Nachdem der offizielle Patch mit der Content-Tool-Erweiterung raus ist, war ich natürlich neugierig auszuprobieren, was ich da so vorbereitend zusammengerührt habe. Das Ergebnis war, naja, durchwachsen.

Ich fange mal mit den kleinen Problemen an und arbeite mich zu den großen hoch.

• Das Content-Tool prüft vor dem Texturimport, ob es Objekte mit der vorgegebenen ID schon gibt. Ist für mich etwas unpraktisch, aber kriege ich in den Griff. Ich muss einfach zu Anfang die betreffenden Container aus "MyContent" löschen. Wenn nur die Löschroutine in .NET nicht so unzuverlässig wäre...
• Irgendwas passt mit meinen DDS-Dateien nicht. Wenn ich versuche ein solches Verzeichnis zu importieren, knallt das Content-Tool mit Speicherschutzverletzung weg. Liegt aber nicht am Aufruf aus meinem Programm, wenn ich es manuell versuche, passiert das Gleiche. Komischerweise kann ich einzelne "unabhängige" Texturen aus dem gleichen Verzeichnis problemlos importieren. Muss ich weiter erforschen und setze den Test erst mal mit BMP-Dateien fort. Ich gehe davon aus, dass es nicht am Content-Tool liegt, sonst wäre das schon öfter gemeldet worden.
• Leider telefoniert das Content-Tool nach Hause zu Steam und das bricht der Sache im Moment das Genick. Bei jedem Aufruf kommt die Rückfrage von Steam, ob ich wirklich das gewählte Programm mit den gewählten Parametern aufrufen möchte. Wenn ich schnell bin, kann ich ein Verzeichnis importieren, wenn ich sehr sehr schnell bin, schaffe ich manchmal zwei Verzeichnisse, aber spätestens beim dritten Aufruf sagt mir Steam, dass der Update des Content-Tools fehlgeschlagen ist. Die schnelle Folge von Aufrufen wird vom Steam-Client offenbar falsch interpretiert. Ein schlauer Workaround, das Content-Tool einfach vorher manuell zu starten und offen zu lassen war leider auch erfolglos.
  Alle Texturen in ein einziges Verzeichnis zu packen ist leider auch keine Alternative wegen der +20000/+10000-Regeln an manchen Fahrzeugen.

Ich bin also im Moment etwas ratlos.

Ideen die mir so durch den Kopf gingen:

• Wenn es eine Art "Offline-Modus" gäbe, bei dem das Content-Tool einfach startet ohne zu telefonieren, wäre das Problem zumindest für BMP-Dateien wohl beseitigt.
• Alternativ könnte ich natürlich auch versuchen, die LTX-Dateien (und später die Container) direkt zu schreiben, ohne Content-Tool. Ist aber nicht so einfach. Zwar kann ich raten, dass eine LTX-Datei vermutlich eine komprimierte Bitmap mit Lotus-Header und -Footer ist, aber um etwas brauchbares zu erzeugen, reicht das Raten nicht. Gleiches gilt beim Container, den ich als eine Art ZIP oder RAR mit Manifest vermute, aber eben auch nur rate.

Am Besten, ich schau mir jetzt doch erst mal den B-Wagen an. Ich glaub der hat ein Rollband...

Dann kommen erst mal die Probleme dran, für die ich schon weiß was ich machen muss und dann sehen wir weiter.

Grüße,

Helmut

Hallo Marcel,

anstelle eines Timers habe ich schon einen WaitForExit drin, aber scheinbar läuft jenseits meines Aufrufs etwas asynchron. Aber selbst wenn ich hier das Programm noch zusätzlich stark verlangsame, hätte das ein gewisses Potential für Panikanfälle, denn bei 4 Verzeichnissen pro Fahrzeug multipiliziert mit der steigenden Anzahl von Fahrzeugen klickt man sich zu Tode an den Steam-Meldungen.

Wie gewünscht hänge ich mal ein kleines Musterverzeichnis von Linienschildern in DDS an. Aber wie schon gesagt, gehe ich davon aus, dass da bei mir in der Konvertierung BMP->DDS noch irgendwas hakt, denn die BMPs gehen ja durch. Aber da bin ich noch am Forschen.

Dazu hat sich noch eine andere Baustelle aufgetan: Es gibt ja auch Busse mit Rollband und die haben einen anderen Film drin als die Straßenbahnen. Also schraube ich gerade an einer Erweiterung mit Projektverzeichnissen.

Dazu kommt, dass Ostern ist, ich Zwangsurlaub habe und ich mich daher momentan mit Paint.Net auseinandersetze, damit es irgendwann mit meinem Fahrzeugbau mal weitergeht.

Grüße aus der Bastelküche,

Helmut

Aua, casesensitive Dateinamen, ich glaub mich tritt ein Pinguin. Darauf muss man erst mal kommen.

Nachdem ich inzwischen auch einen Thread.Sleep drin habe, konnte ich das verifizieren.

Ein Umbenennen wollte ich nicht reinbasteln, aber das MS-Tool das ich da verwende hat einen Parameter, mit dem ALLES klein rauskommt, also Dateiname und Endung, das nehme ich mal übergangsweise.

Damit schnurrt jetzt alles durch wie bei den BMPs.

Es hat allerdings schon einen gewissen Verblödungsfaktor 18 mal OK klicken zu müssen, damit Steam Ruhe gibt. Aber das Problem mit dem vermeintlich gescheiterten Steam Update ist damit jedenfalls weg und es stehen schön viele LTX-Dateien da wo sie sein sollen.

Also wünsche ich mir mal frech für einen beliebigen Lotus-Patch, wie eben Zeit ist, zwei Dinge:

• Beim Importieren von "unabhängigen Texturen" kommt der normale "Datei öffnen" Dialog, dagegen erscheint beim "Texturlisten-Import" ein historischer Win 3.1 Dialog, mit dem es sehr sehr mühsam ist, sich jedesmal quer durch den Verzeichnisbaum zu klicken. Hier wäre sehr schön, wenn man das gleichziehen könnte, denn ab und zu muss man doch auch mal was manuell importieren.
• Zum Packen der Container wäre natürlich Klasse, wenn es auch wieder einen Commandline-Aufruf gäbe. Nachdem dabei keine IDs mehr vergeben werden, kann ich den Klickwahnsinn reduzieren, indem ich die LTX-Dateien vorher einsammle und nur noch ein einziges Verzeichnis packen muss.

Aber alles ohne Streß, es hängt ja kein Leben davon ab.

Damit ist 0:45, Schluß für heute, nur noch ein kleiner Mitternachtssnack, hoffentlich werde ich nicht zum Gremlin.

Bis Bald!

Grundsätzlich ja, allerdings stecke ich momentan in einer Sackgasse.

Der momentane Showstopper ist die Problematik, daß bei jedem Aufruf des Contenttools zum Erzeugen der Lotus-Texturen erst einmal Steam aufgeht - oder auch nicht - und man jedesmal erst wieder den Steamdialog durchklicken muss.

Nach der bisherigen Programmlogik passiert das pro Fahrzeug durchschnittlich vier Mal, je für Frontlinie, Frontziel, Seitenlinie, Seitenziel.

Das multipliziert sich mit der Anzahl der unterstützten Fahrzeuge, derzeit GT6N, GT8, GT8S, B80D und NM68 , womit wir jetzt schon auf ca. 20 Steamdialoge kommen, wobei die kleinen Rollbänder für den NM68 noch gar nicht drin sind. Mit jedem Fahrzeug wird es mehr.

Damit entsteht ein Zwischending aus Frust und Langeweile, das Teil ist einfach im Alltag unbrauchbar.

Derzeit arbeite ich an zwei Fronten.

Einerseits versuche ich, die Anzahl der Aufrufe zu reduzieren, indem ich Texturen gruppiere, damit sie im gleichen Verzeichnis mit nur einem Steam-Aufruf verarbeitet werden. Das ist aber wegen der Logik der Düsseldorfer Züge mit dem +10000 und +20000, was jetzt beim NM68 auch noch ein +30000 erfordert, nicht so trivial. Die Gruppierung der Texturen wiederum hat den Effekt, dass man bei der manuellen Erfassung der Textur-IDs in den Spezial-FISsen völlig den Überblick verliert, weil zu viel für den Import hintereinandergeklatscht wird.

Andererseits habe ich mir das Problem eingefangen, dass die von mir als Eingabe verwendeten Textdateien unbeherrschbar wurden, gerade wegen einer potentiellen Gruppierung, ich brauche also eine Art "Projektdatei", der Einfachheit halber XML, für die ich aber wiederum dann einen brauchbaren Editor liefern muss.

Damit kommt das Thema Oberflächenprogrammierung dazu. Hier schaue ich mir gerade UWP an, weil mir das auch die Update-Verteilung über den Microsoft-Store bringen würde für Leute, die nicht selbst in Seiten wie Github oder AzureDevops suchen wollen. Hab ich aber noch nie gemacht.

Immer wieder flackert natürlich die Idee auf, die Texturen und Container nebst Spezial-FIS direkt zu schreiben, ohne Content-Tool und damit ohne Steam, weil es der scheinbar einfachste Weg wäre. Das wäre aber nicht nur ein gehöriger Aufwand für Reverse-Engineering, sondern auch einfach unanständig gegenüber Janine und Marcel. Mach ich also nicht.

Nachdem ja bereits über eine Möglichkeit zum Export und Import von FIS-Dateien diskutiert wurde, sieht die wahrscheinlichste Lösung so aus:

1) Export der Standard-FIS aus Content-Tool (gibts in Lotus noch nicht)

2) Import in meinen Editor (gibts noch nicht, erst wenige Funktionen zum Herumprobieren, weil ich UWP erst lernen muss)

3) Ergänzen der nötigen Daten für Perlschnüre (grüble ich derzeit an einer Lösung mit mehr als einer simplen Geraden)

4) Ändern der kompletten Logik der Texturerzeugung, damit Texturen in Nummernbänder gruppiert werden können (+0/+10000/+20000/+30000)

5) Möglichst wenige Aufrufe des Contenttools zum Erstellen der Texturen (hier muss auch an der Stabilität was passieren, manchmal wartet man auf Steam lange aber vergeblich, dazu prüft das CT auch ob die IDs schon vorhanden sind, ich muss also im MyContent-Ordner löschen, was wegen Dateikonflikten noch zu instabil ist)

6) Optimierung der Dateisammlung für möglichst wenige Container

7) Aufruf des Contenttools zum Erstellen der Container (geht von Lotus aus noch nicht)

Schreiben von Import-Dateien für den FIS-Editor des Content-Tools (der Brillensmiley ist eine 8 mit Klammer zu, ein Gag der Forensoftware)

9) Manueller Import der Spezial-Fisse im Content-Tool (gibts in Lotus noch nicht)

Wie man sieht, gäbe es da auch einige Baustellen bei Lotus. Es ist aber keineswegs so, daß ich nicht weitermachen kann, weil Lotus etwas nicht kann, was versprochen wäre und nicht geliefert wird und so Blabla wie man es gelegentlich hört. Nö, diese Ausrede gönne ich mir nicht. Genau das Gegenteil trifft zu.

In Lotus gehen momentan sehr viele wichtige Sachen sehr gut voran. Und bevor ich jetzt mit meinem Randthema Leute aufhalte, die was wichtigeres zu tun haben, will ich erst einmal meine Hausaufgaben so weit haben, daß ich auch vernünftige umsetzbare Ideen und Vorschläge besprechen kann, sobald einmal Zeit ist.

Der Ball ist also klar bei mir und der rollt im Moment etwas langsam, weil aus dem vermeintlichen Mittagspausenprojekt, dass ich mal schnell runterschreiben wollte, doch wieder eine Sache wurde, die eine Menge Hirnschmalz erfordert und leider doch wieder eine Lernkurve.

Also lange Rede gar kein Sinn: Es wird noch daran gearbeitet, momentan nicht täglich aber mehrmals die Woche. Aber Release-Termin gibt es keinen.

Zitat von gt670dn

Hm, ne simple .exe wäre doch ausreichend.

Mit was kannst du denn heute noch ne simple EXE erzeugen? C++ ist Geschichte. Heute hängst du immer von einer .NET Version ab und bringst alle möglichen Dateien und Einstellungen mit, um sicherzustellen, dass das Programm auch alles hat was es braucht.

Das würde nicht nur heißen, MSI-Paket bauen, sondern auch Downloadseite bereitstellen etc. One Click Install das Gleiche in Grün.

Daher die Idee mit dem Windows Store, auch wegen der automatischen Updates um die man sich nicht kümmern muss. Beim derzeitigen Stand kann aber durchaus sein, dass das eine Ente wird und ich mir was anderes überlegen muss. Bei vielen eigentlich trivialen Problemen erlebe ich immer wieder, dass UWP ein noch schlimmerer Rückschritt ist als es WPF war. Kann also passieren, dass ich zurück auf Windows Forms gehe, aber das sind ungelegte Eier.

Ich kann derzeit nur mit definitiver Sicherheit sagen, dass es NICHTS mit Java zu tun haben wird.

Hoppla, da gerate ich unbeabsichtigt ins religiöse, so war das nicht gedacht.

Nur mal um Motive zu verdeutlichen: Das Projekt ist als "Spaß in der Mittagspause" entstanden, also nutze ich einfach Tools die ich sowieso habe und streßfrei verwenden kann. Als alter Microsoftie bin ich da von C++ in den 90ern bei .NET im neuen Jahrtausend gelandet, wobei Windows Forms noch immer mein Favorit ist, weil da einfach so viel "out of the box" funktioniert. Bei WPF musste man dann schon wieder eine Menge manuell programmieren, was bei Forms einfach da war. Wie ich nun in den letzten Wochen feststellen musste, hat sich dieser Trend bei UWP noch weiter verschärft.

C++ wäre für mich auch ein Rückschritt, weil ich mir viele Erleichterungen wieder abgewöhnen müsste und eigentlich faul bin.

Mit "Geschichte" meine ich, daß in meinem beruflichen Umfeld schon seit > 10 Jahren kein C++-Projekt mehr begonnen wurde und inzwischen auch fast alle damaligen Projekte auf .NET oder Java umgestellt wurden. Heutzutage stellt man in den Firmen leider gerne eine dickere Maschine hin statt auf schnellere Programme zu achten. Ich bin C++ einfach nicht mehr gewohnt.

Delphi bzw. Turbo Pascal habe ich vor langer langer Zeit mal gemacht, was mir heute das Lesen von Lotus-Skripten stark erleichtert, Eine aktuelle Lizenz lohnt sich aber fürs Hobby nicht zu kaufen und Lazarus habe ich mir zwar angesehen, wollte aber für das "Mittagsprojekt" keinen Aufwand in Einarbeitung stecken.

Momentan spricht alles dafür, bei .NET und C# zu bleiben, weil der ganze Code, der die Grafiken für die Rollbandtexturen erzeugt, ja schon vorhanden ist.

UWP war nur für die Oberfläche gedacht und die einfache Verteilung über den Store. Nachdem mich diese Oberflächensache aber immer mehr aufhält, werde ich mir auch mal ansehen, ob man über den Workshop auch Content verteilen kann mit Desktop/Startmenü Icon. Mein Progrämmchen würde ja nicht von Lotus geladen werden, sondern ähnlich wie Content-Tool und Mapeditor daneben liegen.

Das größte Problem, die Steam-Aufrufe und der Klick-Wahnsinn sind aber eh völlig sprachunabhängig, das hat mich kalt erwischt, damit hatte ich nicht gerechnet. Bei meinen zu vielen Eingabedateien, die mir über den Kopf wachsen bin ich auch selbst schuld, hier rächt sich einfach daß ich ohne große Planung einfach entspannt losprogrammiert habe.

Also alles rein subjektiv, aus persönlicher Sicht und Bequemlichkeit und völlig unreligiös.

Religiös werde ich nur bei Java. Das liegt aber auch nicht am Dogma, sondern daran, daß mir dieses ganze Ökosystem beruflich dermaßen Streß und Ärger macht, daß ich das im Hobbybereich nicht mit der Zange anfasse.