Auskommentieren von nicht benötigten Schemen

[Leutnant Triebisch]

Moin Fans,

um beim Laden von Sudden Strike & Co. wertvolle Ressourcen zu sparen, kann man ja u.a. als Einsparmaßnahme nicht benötigte Schemen (z.B. Wüste, Winter, Asien) in der Sudtest.ini vorher auskommentieren.

Ich habe das mal wie in meinem Screenshot zu sehen getan. Wäre das so korrekt auskommentiert oder muss man das anders machen ?


Schönen Gruß von
Leutnant Triebisch

[zarathustra]

Dies hat keinerlei Auswirkungen auf die Probleme in anderen Schaltkreisen!
Beim Laden eines Spiels oder Editors werden allgemeine Dateien (Menüs, Design usw.) und Archive eines bestimmten Schemas gelesen - dasjenige, in dem die Mission kompiliert wird.
Eine andere Sache ist wichtig. Zum Beispiel werden Archive nacheinander gelesen:
... color_s2a.sue;color_s2a.sue; ... russ1.sue; ...
Wenn beispielsweise in allen (oder sogar in zwei) Archiven eine bestimmte Datei tank.pck\tank.col vorhanden ist, wird die zuerst gelesene verwendet. Gleichzeitig wird der Rest des Spiels nicht mehr benötigt, aber sie verwenden immer noch die Köpfe und wirken sich beim Zählen auf die Gesamtzahl der Dateien aus.
Wenn Sie sich erinnern, hat HS auf einmal die Links zu den allgemeinen Parametern von Waffen und Ausrüstung in den Schreibtischen vollständig entfernt und diese Informationen in alle Dateien für bestimmte Einheiten übertragen (dupliziert) - dies ist eine typische Technik, um die Anzahl der Dateien im Spiel zu verringern.

[Leutnant Triebisch]

Grüzi,

Wenn Sie sich erinnern, hat HS auf einmal die Links zu den allgemeinen Parametern von Waffen und Ausrüstung in den Schreibtischen vollständig entfernt und diese Informationen in alle Dateien für bestimmte Einheiten übertragen (dupliziert) - dies ist eine typische Technik, um die Anzahl der Dateien im Spiel zu verringern.

???
1.) Kannst du dazu einen Screenshot noch senden?! Dann kann ich deinen Satz bestimmt besser verstehen. Wäre echt super.

2.) Aber meine "-" Auskommentierungen sind richtig gesetzt...oder etwa doch nicht? Oder kann man auch die ganzen Zeilen mit dem "-"- Bindestrich einfach löschen?


Beste Grüße von
Leutnant Triebisch

[zarathustra]

1.) Kannst du dazu einen Screenshot noch senden?! Dann kann ich deinen Satz bestimmt besser verstehen. Wäre echt super.

Ich denke, ich kann nicht - wir haben einfach lange keine solche "Schande". So sieht die Datei aus RWG:

sudtest.jpg (62.35 KiB) 2385 mal betrachtet

Die Logik ist einfach:
Alle gängigen Dateien (für alle Schemata) werden in Abschnitt "Data" gelesen
Die Schemaarchive enthalten keine einzige Datei, die für dieses Schema nicht benötigt wird.

2.) Aber meine "-" Auskommentierungen sind richtig gesetzt...oder etwa doch nicht? Oder kann man auch die ganzen Zeilen mit dem "-"- Bindestrich einfach löschen?

Wenn Sie diese Schemata nicht benötigen, können Sie dies natürlich tun. Für das Spiel ist dies nicht wichtig: Es existieren auch nicht alle auskommentierten Zeilen dafür.

[Gareth]

Wenn Sie sich erinnern, hat HS auf einmal die Links zu den allgemeinen Parametern von Waffen und Ausrüstung in den Schreibtischen vollständig entfernt und diese Informationen in alle Dateien für bestimmte Einheiten übertragen (dupliziert) - dies ist eine typische Technik, um die Anzahl der Dateien im Spiel zu verringern.

???
1.) Kannst du dazu einen Screenshot noch senden?! Dann kann ich deinen Satz bestimmt besser verstehen. Wäre echt super.

Zarathustra meint damit, dass man in den Einheiten-Beschreibungen auf die Include-Dateien verzichtet hat. In diesen Einheiten-Beschreibungen (engl. description, kurz desc, von den Russen oft mit k am Ende geschrieben: desk; Google-Übersetzer übersetzt das dann als Schreibtisch) kann man ja mit # eingeleitete Verweise auf andere Dateien setzen. So kann man z.B. die Einträge für eine Kanone, die in mehreren Panzern verbaut war, zentral in einer Datei unterbringen, während die Beschreibungen der Panzer dann nur auf diese Datei zurückgreifen, wenn es um die Waffenwerte geht. Der Vorteil ist, dass man bei Änderungen an den Waffenwerten nur die Desc-Datei der Kanone ändern muss. Die Panzer übernehmen dann durch den #-Link die geänderten Werte automatisch. Nachteil ist eben, dass jede dieser "ausgelagerten" Dateien als eigene Datei zählt. Wenn man also auf solche Verweise verzichtet, dann muss SuSt auch weniger Dateien laden und kommt nicht so schnell an die Grenzen. Dafür muss man dann bei Änderungen der Waffenwerte eben die Desc-Dateien aller Panzer mit dieser Waffe entsprechend ändern.

[zarathustra]

Alles ist richtig. Die Frage ist: Was ist Ihnen wichtiger?
Deshalb verwenden wir unseren eigenen "Ansatz": Wir haben eine Basis für alle Waffen und Standardeinstellungen, Unit Desks haben Links zu den notwendigen gemeinsamen Dateien. Wenn wir einen Mod erstellen, kompilieren wir ihn jedes Mal. Daher müssen wir nicht in allen Dateien das Gleiche reparieren und im Mod selbst haben wir keine "zusätzlichen" Dateien.

[Leutnant Triebisch]

@zarathustra: Vielen Dank, hoffe jetzt habe ich das verstanden, was du gemeint hattest!

@Gareth: Vielen Dank, ja diese Google-Übersetzer sind doch mitunter schwer zu verstehen! => Frage dich mal direkt an wegen unvorhergesehener Instabilitäten lange nach einem Start eines MP-Games: Da ich bei mir absolut kein Muster und damit keinen Reim machen kann, was der wahre Grund für Abstürze ist. Wenn das Spiel startet, heißt das für mich, dass jegliche Modding-Änderungen gelungen sind und alles o.k. ist, sonst müsste ja sofort ein BtW kommen. Das Spiel hat also alles akzeptiert, weil der Modder gut gearbeitet hat. Aber dann der Mist wenn es nach Stunden anfängt abzustürzen - sehe da weder eine Logik (entweder 1 = es geht oder 0 = es geht nicht) noch ein Muster. Klar, wenn man z.B. eine neu eingefügte Einheit im Spiel anklickt und bums,...sogleich stürzt der Bildschirm ab - das wäre nachvollziehbar. Dann weiß man ja, welche Einheit das verursacht.

Genauso ist es ja auch wenn die maximale Anzahl an zu ladenden Datei-Files überschritten wäre, nach Infos hier im Forum soll das ja bei > 4.000 Dateien sein. Dann lädt ja das Spiel erst gar nicht mehr. So eine Sache wäre mir verständlich, dass es eben zu Beginn schon nicht mehr weiter laden tut. Aber in meinem Fall verstehe ich das nicht. Habe sogar schon zur Vorbeugung nicht benötigte Grafikfiles von nicht verwendeten Einheiten ganz aus meiner *.common.sue herausgenommen...! Bin da echt am Ende meines Lateins!


Greetings from
Leutnant Triebisch

[zarathustra]

Leider ist die Spiel-Engine auch nach so vielen Jahren noch weitgehend eine "Black Box" für uns

[Gareth]

sehe da weder eine Logik (entweder 1 = es geht oder 0 = es geht nicht) noch ein Muster.

Auch wenn der Rechner nur mit 0 und 1 arbeitet, heißt das ja nicht, dass alles so binär abläuft. Der Gedanke "entweder 1 = es geht oder 0 = es geht nicht" ist schlicht falsch. Ich erkläre es mal am Programmieren und versuche dann die Parallelen zum Modding zu verdeutlichen.
Die einfachsten Fehler sind Syntaxfehler: Ich habe einen Befehl falsch geschrieben oder bei einem Funktionsaufruf zu viele oder zu wenige Werte an die Funktion übergeben oder den falschen Datentyp verwendet (z.B. eine Kommazahl, wo nur ganzzahlige Werte erlaubt sind). Das sind Fehler, die der Compiler beim Übersetzen in das lauffähige Programm finden kann und bei denen er dann sofort meckert. Beim Modding können die gleichen Ursachen zu Fehlern führen, nur liefert SuSt halt nicht immer eine aussagekräftige Fehlermeldung, wie das bei einer Programmiersprache wäre. Oft gibt es einfach nur einen Absturz. Trotzdem findet man falsch geschriebene Parameternamen oder ähnliches recht schnell.
Schwieriger zu finden sind Fehler, bei denen der Compiler zwar ein lauffähiges Programm erzeugen kann, aber das Programm anschließend stumpf abstürzt, oft immer an der gleichen Stelle. Hier gibt es manchmal noch eine brauchbare Fehlermeldung, oft nicht. Das ist, glaube ich, die Art von Fehler, an die du denkst, denn du schreibst ja:

Wenn das Spiel startet, heißt das für mich, dass jegliche Modding-Änderungen gelungen sind und alles o.k. ist, sonst müsste ja sofort ein BtW kommen.

Diese Art von Fehlern gibt es natürlich beim Modding auch. Es gibt aber tatsächlich auch noch eine weitere Art von Fehlern und das ist wahrscheinlich die Art, die dir gerade die Schwierigkeiten macht. Das sind Fehler, die nur unter ganz bestimmten Umständen auftreten, die meist nur schwer reproduzierbar oder auf jeden Fall schwer nachvollziehbar sind. Das liegt häufig daran, dass sie nicht unbedingt immer auf eine simple Ursache zurückzuführen sind, sondern mehrere Ursachen haben können, die einzeln unproblematisch sind und nur im Zusammenwirken das Problem verursachen. Oder das Problem hat zwar nur eine Ursache, der entsprechende Fall tritt aber nur unter sehr speziellen Bedingungen auf. Es gab z.B. mal einen Fehler in der Programmierung der Lagekontrolle eines Kampfjets, der über Jahre nicht aufgefallen ist und erst bei Flügen auf der Südhalbkugel stellte man fest, dass das Programm wegen der Überschreitung des Äquators einen Vorzeichenfehler machte und dadurch das Flugzeug "auf den Rücken legte". Deshalb hat zarathustra auch den Rat gegeben, das Problem einzugrenzen: Genau beobachten, was gerade passiert, wenn die Mission abstürzt; überlegen, was beim Modden zuletzt verändert wurde. Was könnte man dabei übersehen haben? Die Dateien hängen ja vielfach verzahnt zusammen. Mir sind da bei meinem Private Little Mod auch schon interessante Fehler begegnet, die ich auch nicht immer lokalisieren konnte. Ich habe schon einige Male die Arbeit von Stunden oder sogar Tagen wegschmeißen müssen, weil ich einen Fehler nicht finden konnte und natürlich gerade dann schon längere Zeit kein Backup gemacht hatte.
Einen konkreten Rat habe ich da auch nicht, ich gebe zarathustra aber völlig recht. Anders als durch genaue Beobachtung der Umstände, unter denen die Mission abschmiert, wird man den Fehler nicht lokalisieren können. Schon gar nicht durch Ferndiagnose, denn wir wissen ja nicht, was du zuletzt an Änderungen eingebaut hast, welche Änderungen dein Mod schon mit sich bringt usw. usf. Da aus der Ferne eine Fehlerursache finden zu wollen, ist ohne Kristallkugel kaum möglich.

[Leutnant Triebisch]

Moin Gareth,

vielen Dank für deinen Post.

1.)

Schwieriger zu finden sind Fehler, bei denen der Compiler zwar ein lauffähiges Programm erzeugen kann, aber das Programm anschließend stumpf abstürzt, oft immer an der gleichen Stelle.

- Hast du für so eine Art von Fehler ein Beispiel im Sudden Strike/ Hidden Stroke?

2.)

Einen konkreten Rat habe ich da auch nicht, ich gebe zarathustra aber völlig recht. Anders als durch genaue Beobachtung der Umstände, unter denen die Mission abschmiert, wird man den Fehler nicht lokalisieren können.

Ja, wir beobachten immer schon wie die Luchse mit Argusaugen. Da ich ja weiß, welche beiden Einheiten ich zuletzt gemoddet/ angefasst habe beobachten wir genau deren Verhalten beim Bewegen/ Schießen und Anklicken - Nichts!! Es ist ja vor allem so, dass man gerade zuletzt im MP-Match diese 'neuen' Einheiten mit der Maus auf dem Bildschirm gar nicht bewegt hatteß?!! Sondern man hatte ganz reguläre Einheiten bewegt oder es waren leichte Gefechtstätigkeiten, mehr nicht.

Ich gehe davon aus, dass eigentlich nur der Server-Rechner, also derjenige PC, welcher das MP-Match eröffnet hatte für einen Absturz am Ende ursächlich ist, da ja der Mitspieler lediglich ein Client ist. Hoffe das ist so richtig. Beide haben ja eh die geänderten *.sue-Dateien drauf.

3.) Nach deiner Meinung: Welche Dinge sind neben der Anzahl an Einheiten; Brücken etc. noch eine empfindliche Sache bei Sudden Strike & Co. ?! Worauf reagiert nach deiner Erfahrung das Spiel auch noch äußerst sensibel bzw. was sollte man noch beachten ?

4.) Da ich auch gerne in die Tiefe in Themen gehe - Was du wegen deiner Kenntnisse in Programmieren angeht: Gab es denn schon mal Versuche endlich diesen alten und verhexten Qellcode der Sudden-Engine zu dekompilieren, zu entschlüsseln und damit lesbar zu machen?

Man, was wäre das für ein Aufatmen und eine Erleichterung! Aber mal ehrlich, gibt es denn gar keine Möglichkeit an den Programmcode zu kommen? Immerhin ist die Engine ja in einem Alter, wo das längst der Öffentlichkeit zur Verfügung gestellt werden sollte. Geld wurde ja damit genug verdient und zeitgemäß ist der Code ja auch nicht mehr, d.h. damit kann man in 2021 keinen Pfifferling mehr an Gewinn rausholen, ist sicher klar. Muss doch zigfache Kopien davon geben, und größer als eine CD (750 MB) ist dieser sicher nicht.
Sowas liegt doch nicht in einem Panzerschrank, und bei den Russen kriegt man doch sonst auch alles (dort müsste der Code irgendwo ja sein) - Möchte echt mal wissen wo der Quellcode von Sudden Strike 2 bzw. SS-RW rumliegt!! Menschenskind, sowas kann ja nach über 20 Jahren kein Staatsgeheimnis mehr sein, oder?!!

Als Beispiel steht da z.B. 'Battlefield 2' von einem schwedischen Entwickler, der Quellcode dafür wurde auch schon freigegeben wie ich las und das Spiel ist wesentlich jünger als Sudden Strike.

Schönen Gruß von
Leutnant Triebisch

[Gareth]

@1: Hast du bestimmt auch schon mal erlebt. Man hat ein neues Fahrzeug eingefügt und auf einer Testmap platziert. Die Map startet auch problemlos, aber sobald das neue Fahrzeug ins Bild kommt, geht‘s btw. Kann mich nicht mehr erinnern, was da bei meinen Versuchen damals die Ursache war. Weiß auch nicht, ob ich mir das im Eifer der Fehlerbehebung notiert hatte. Einmal habe ich auch einfach das letzte Backup wieder eingespielt. Der Effekt ist mir auch von irgendeiner All Units Test Map in Erinnerung, vielleicht von RCM 2.6.
@2: Es können auch programminterne Abläufe sein, die den Absturz verursachen und die man naturgemäß gar nicht beobachten kann.
Ich glaube, es könnte sehr schwierig werden, den Fehler einzukreisen.
@3: Frag lieber, worauf SuSt nicht empfindlich reagiert. Ich habe beim Modden manchmal das Gefühl, durch ein Minenfeld zu laufen. Brücken sind ja eher beim Mappen ein Problem. Was mir schon ganz oft Probleme gemacht hat, sind fehlerhafte oder fehlende Verweise in Desc-Dateien und Listen wie Units, Avia und dergleichen. Da gibt es zu viele Möglichkeiten, um sie alle aufzuzählen.
@4: Die Versuche gab es und gibt es. Im Forum von modplanet wird z.B. von einem Versuch berichtet. Weiß aber nicht, ob da noch was läuft. Kannst du dir ja mal anschauen, dann bekommst du einen ganz guten Eindruck, was das für eine elende Pfriemelarbeit ist. Und da geht es nur um die Entschlüsselung der n2cad-dll, um eine höhere Auflösung zu erreichen. Auf dem Weg rechne ich nicht mit größeren Durchbrüchen.
Was das Freigeben oder wenigstens die Lizensierung des Quellcodes angeht, habe ich auch nicht viel Hoffnung. Denk mal daran zurück, wie wirr der Untergang von Fireglow damals abgelaufen ist. Da kann der Quellcode durchaus verschütt gegangen sein. Wäre nicht das erste Programm, bei dem das passiert ist. Ein Staatsgeheimnis ist der Code sicher nicht, aber es kann durchaus sein, dass er nicht mehr existiert oder dass niemand mehr weiß, wo vielleicht noch eine Kopie rumliegt.
Im Steam-Forum zu SuSt 4 haben die Leute von Kalypso auch berichtet, dass sie versucht haben, den Code aufzutreiben. Sie hatten aber wohl auch keinen Erfolg.

[Leutnant Triebisch]

vielen Dank für eure Antworten. Es ist toll wenn man sich hier im Forum nach allden Jahren noch mit einigen Leuten austauschen kann und man dadurch es am Lben erhält und Rat und Hilfe findet!

@Gareth
A.) Gebe es nach deiner Programmierersicht eine realistische Möglichkeit der Erweiterung (vor allem der Sudden-Strike-Ressourcen, denn das ist ja die nervigste Einschränkung!) sowas ähnliches wie eine zusätzliche Injections-Dll zu schreiben, so auf die Art 'Hintertür', welcher die Spielehacker u.a. verwenden. Also ohne den Quellcode zur Verfügung zu haben. Denn wenn Weg A versperrt bleibt, dann eben über B zum Ziel.

Wäre so etwas praktisch machbar?

B.) Hatte man eigentlich bei 'Sudden Strike-Ressource War' im Gegensatz zum 'Sudden Strike 2' den Quellcode geändert um die bekannten Erweiterungen in den Spielefeatures zu ereichen ?! (z.B. Häuser konnten wieder aufgebaut werden, mehr Tore (Gates) standen auf einmal zur Verfügung usw.)

C.) Mir ist noch was eingefallen, was mich auch seit Jahren nervt. Betrifft zwar nicht explizit Modding aber egal: Immer wenn ich Tore für eine MP-Karte setze, kommen sehr oft die Einheiten bei einem der beiden Spieler nicht an dem breiten Tor heraus, sondern z.B. in einer einzelnen Torbreite, wo z.B. der Zug herauskommt??! Die breiten Tore, welche das Spiel ja nehmen soll sind aber korrekt etwa gegenüber und mit A und gegenüber mit B erstellt. Auch wenn ich dann das breite Tor woanders hin lege, z.B. links oder rechts neben das Zug-Tor - hilft auch nichts?!! Man das nervt vielleicht.
Gibt es hierfür einen Rat wie ich das korrekt hinbekomme?

Auch kann man nicht festlegen wo der PLAYER bzw. der GEGNER auf welcher Map-Seite herauskommt. Das ist vor allem dann blöde, wenn nebenan der Zug desjenigen herauskommt. Das Spiel verdreht immer irgendwie die Reihenfolge willkürlich...?! (dadurch weiß ich mir nicht zu helfen und muss jedesmal die Zugskripte so ändern, dass alles für eine Seite wirklich auch nur auf der einen Seite auf die Karte kommt!)


Schönen Gruß von
Leutnant Triebisch

[Gareth]

@1: Man könnte SuSt sicher auf diesem Weg dazu bringen, eigenen Code auszuführen. Aber um SuSt um neue Konzepte zu erweitern, wird das mMn nicht taugen. Man könnte vielleicht Code einschleusen, der Tastendrücke mitschneidet oder Screenshots speichert. Auf solche Arten wird dll injection ja meist benutzt. Für eine Veränderung des Spielgeschehens müsste der eigene Code aber mit den Datenstrukturen und Abläufen von SuSt zusammenarbeiten. Und die kennt man nun mal nicht oder nur in sehr eingeschränktem Umfang. Also auch nur ein schöner, aber wohl nicht realistischer Traum.
@2: Ja, natürlich wurde dazu der Quellcode geändert. Anders bekommt man ein Programm ja nicht um wirklich neue Funktionen erweitert. Das, was beim Modden erreicht wird, ist dagegen ja meist nur eine kreative Nutzung von bereits vorhandenen Programmfunktionen.
@3: Da mich Multiplayer mal so gar nicht reizt, habe ich mich noch nie ernsthaft mit MP-Scripting befasst. Aber Gehtnix hat doch zu allen möglichen Skript- und Mapfragen immer mal was von seinem immensen Wissen kundgetan. Hat er zu den Toren nichts gesagt, was dir weiterhilft? Ich meine, mich an Äußerungen zu dem Thema zu erinnern. Das kann allerdings in beliebigen Threads stehen, nicht nur im Editor- oder Mappingforum.

[Leutnant Triebisch]

Many thanks Gareth,

habe mal wegen der einen Frage den gehtnix angeschrieben, aber ob der noch hier aktiv ist...mal sehen.

P.S.: Hast du eine Ahnung noch von Spielabstürzen, welche mit 'synclost'- (drop Player) ausgewiesen werden. Sowas hatten wir auch kürzlich. Die LAN-Verbindung war es definitiv nicht - das hätte ich verstanden, wenn die nicht 1 GB ist. Andere Programme wie z.B. Firewall oder Antivirensoftware waren bei beiden Rechnern auch nicht aktiv. Und Spieleversion ist auch bei beiden diesselbe... Was könnte die Ursache sein?

Gruß von
Leutnant Triebisch

[Gareth]

Nein, da habe ich keine Idee. Wie ich im vorherigen Post schrieb: MP reizt mich so überhaupt nicht. Daher habe ich auch keine Ahnung, was für Ursachen eine solche Fehlermeldung haben könnte. Bis eben kannte ich nicht mal die Fehlermeldung...