German Railroads Forum

Man könnte jetzt eine aufwändige Testreihe starten, ob dieser angezeigte Fehler eine Auswirkung hat oder nicht und wenn ja welche!
Man kann aber auch einfach jeder Begrifflichkeit eine eigene Zeile widmen und fertig is.
Wenn sich mal die Dateien anschaut, die das MSTS-Programm selbst erstellt - also nicht händisch - ( z.B. *.s-, *.cvf-, *.act-Dateien ), so sind diese viel stringenter aufgebaut und man findet keine 2 Begriffsdefinitionen in einer Zeile.

Bei *.eng-, *.wag-, *sms-Dateien herrscht i.d.R. nicht nur keine einheitliche Ordnung in der Reihenfolge der Elemente, sondern auch solche Zusammenfassungen bzw. Auseinanderziehungen von Begriffen.
.
Beispiel für Zusammenfassung:
Wagon ( PF_EFW_212_381-8
...
Type ( Chain )
Spring ( Stiffness (1e6N/m 5e6N/m) Damping (1e6N/m/s 1e6N/m/s) Break (3.1e8N 3.1e8N) r0 (0cm 10cm)) CouplingHasRigidConnection () Velocity (0.1m/s))
Buffers ( Spring ( Stiffness (1e6N/m 5e6N/m) Damping (1e6N/m/s 1e6N/m/s) r0 (0m 1e9)) Centre (0.5) Radius (1) Angle (0.5deg))

Hier werden nicht nur Begriffe in eine Zeile gequetscht, sondern auch auf die Spaces vor bzw. hinter Klammern verzichtet.
.

Beispiel für Auseinanderziehen:
.
ScalabiltyGroup( 3
Activation (
ExternalCam ()
Distance (500)
)
Deactivation (
PassengerCam ()
CabCam ()
Distance (500)

)
.

Die Definitionen der Begriffe Activation ( & Deactivation ( lassen sich in einer Zeile darstellen. Auch hier wieder die fehlenden Spaces.

Wie ich bereits anderer Stelle bemerkte, haben wir im MSTS einen großen Bereich alles 100%ig richtig und Fehlermeldung/Absturz. Statt sich der Frage "Was ist, wenn ..." zu widmen ist es wesentlich einfacher alles richtig zu machen.
.
Durch eine einheitliche, stringente Dateistruktur werden *.eng-, *.wag-, *sms-Dateien nicht nur lesbarer, sondern sie lassen sich auch gruppenweise bearbeiten bzw. gruppenweise Werte anpassen.

Hallo,

meines Wissens gab / gibt es die Theorie, dass es im MSTS Arbeitsspeicher sparen würde, wenn man "unnötige" Zeilenumbrüche und Leerzeichen aus den Dateien entfernen würde.

Ich kann der Theorie nicht ganz folgen und bin auch eher ein Verfechter der "Lesbarkeit".

Warum ich der Theorie nicht folgen kann? Nun ja - der MSTS liest Dateien grundsätzlich nicht komplett am Stück ein, um sie anschließend zu verarbeiten.

Ich habe bisher keine Ausnahme bei der Verarbeitung der Dateien im MSTS gefunden. Es betrifft also *.eng-Dateien genauso wie die großen Textur-Dateien (*.ace). Dabei ist es auch völlig unerheblich, in welchem Format (ungepackt, komprimiert, DXT usw.) die Dateien vorliegen. Der MSTS geht beim Einlesen von Dateien von der Festplatte immer wie folgt vor:

1. Öffnen der benötigten Datei, d.h. Anforderung eines Handles (eine Art Zugriffsnummer, die vom Betriebssystem vergeben wird).
   
2. Der MSTS reserviert einen Puffer-Speicher im Arbeitsspeicher von genau 16384 Byte (oder 16 KByte) Größe.
3. Einlesen der ersten 2 Byte der Datei in den Puffer-Speicher. Der MSTS bestimmt an Hand der ersten beiden Bytes, ob es sich um eine Unicode-Datei handelt.
4. Abhängig vom Ergebnis der Unicode-Prüfung liest der MSTS die nächsten 14 oder 32 Bytes in den Puffer-Speicher ein, wobei die bereits gelesenen 2 Byte im Puffer überschrieben werden. Der MSTS erhält somit den sog. Header (beginnend mit der vielleicht bekannten Zeichenfolge "SIMISA"). Somit "weiß" der MSTS anschließend, in welchem seiner Formate die Datei vorliegt und wie diese zu interpretieren ist.
5. Der MSTS lässt sich anschließend die Größe der Datei vom Betriebssystem geben, um am Ende nicht über das Dateiende hinaus Daten anzufordern.
6. Nun liest der MSTS maximal 16384 Byte der Datei in den Puffer-Speicher und überschreibt dabei die bisherigen Daten im Puffer-Speicher. Der Inhalt des Puffer-Speichers wird nun vom MSTS verarbeitet. Er füllt seine internen Datenstrukturen. Sollte eine weitere Datei benötigt werden (zum Beispiel eine Shape-Datei oder Textur), so wird diese auf die gleiche Weise geöffnet und komplett abgearbeitet (mit eigenem 16 KByte-Puffer-Speicher), wie die aktuelle Datei. Anschließend geht es in der aktuellen Datei weiter.
7. Sollte das Dateiende noch nicht erreicht worden sein, geht es wieder zurück zu Schritt 6.
8. Am Ende gibt der MSTS das Handle wieder frei.
9. Falls der Puffer-Speicher nicht direkt für die nächste Datei benötigt wird, wird auch der Puffer-Speicher wieder freigegeben. Der Algorithmus, der bestimmt, ob der Puffer-Speicher wiederverwendet werden kann, scheint nicht ganz perfekt zu sein. Es kann vorkommen, dass der Puffer-Speicher erhalten bleibt und ungenutzt reserviert ist. Dieses "Speicherleck" schlägt zu, wenn man immer wieder eine Aufgabe startet und beendet, ohne den MSTS zwischendurch zu beenden.

Fazit:

Der MSTS benutzt für jede geöffnete Datei einen Puffer-Speicher von 16 KByte Größe - unabhängig davon, wie groß die Datei tatsächlich ist. Geöffnet wird eine Datei nur bei Anforderung und wird anschließend gleich wieder geschlossen. Wenn man die Abhängigkeiten der Dateien untereinander betrachtet, dürften nie mehr als vier oder fünf Dateien gleichzeitig geöffnet sein. Das wären dann maximal 64 bis 80 KByte reservierter Arbeitsspeicher für das Lesen von Dateien im MSTS. Das ist verschwindend wenig.

Diese Technik des häppchenweisen "Lesens" von Dateien ist übrigens keine Spezialität des MSTS, sondern gehört eigentlich zur guten Schule der Anwendungsentwicklung, um die System-Ressourcen zu schonen.

Auch das Entpacken von komprimierten Daten läuft kontinuierlich als Stream, also während des Lese-Vorgangs.

Ob das Betriebssystem die Datei bei Anforderung in einen vom System verwalteten Cache-Speicher lädt, kann der MSTS nicht beeinflussen. Dieser Cache gehört auch nicht zum Speicherbereich der Anwendung (also des MSTS). Zudem ist die Nutzung des Cache-Speichers abhängig von dem zur Verfügung stehenden Arbeitsspeicher im System.

Also - lieber lesbar bleiben...

Hallo,

Zitat von »Karsten Pohl«

Der MSTS benutzt für jede geöffnete Datei einen Puffer-Speicher von 16 KByte Größe - unabhängig davon, wie groß die Datei tatsächlich ist. Geöffnet wird eine Datei nur bei Anforderung und wird anschließend gleich wieder geschlossen. Wenn man die Abhängigkeiten der Dateien untereinander betrachtet, dürften nie mehr als vier oder fünf Dateien gleichzeitig geöffnet sein. Das wären dann maximal 64 bis 80 KByte reservierter Arbeitsspeicher für das Lesen von Dateien im MSTS. Das ist verschwindend wenig.

Gilt das auch für das Öffnen von *.ace-Files?


Dann wäre die Share-Methode der vielen gesplitteten (kleineren) Texturen eher kontraproduktiv, ebenso die gelegentlich feststellbare Angewohnheit, das statische Rollmaterial an den Gegenzügen anzugleichen.
Was IMHO wirklich etwas bringt, sind "korrekt berechnete Aufgaben (Activitys)", da sonst der MSTS irgendwie in einer Schleife hängt und ständig etwas berechnen möchte, was so nicht geht.
Fehlerhafte Fahrzeiten von Verkehrszügen (der Aufgaben-Editor macht das gerne) versuche ich daher zu vermeiden und lasse jede Aufgabe nach dem Abspeichern noch einmal (Neuaufruf) im Editor durchlaufen.
Mit besten Gruß,Marcus

Hallo Marcus,

Zitat von »Marcus«

... lasse jede Aufgabe nach dem Abspeichern noch einmal (Neuaufruf) im Editor durchlaufen.

was versprichst Du Dir davon?

Grüße Cris

@Chris,
nicht beim Abfahren einer Strecke im MSTS, ich schreibe vom Aufgaben-Editor!
+
Mir ist aufgefallen, dass bei vielen Gegenzügen, die ggf. an Bahnhöfen halten, sich die angezeigten Ankunfts- und Abfahrzeiten ändern, wenn nach Erstellen bzw. Ändern der Aufgabe eine Berechnung durchgeführt wird.
+

Bei z.B. den WupperExpress-Aufgaben mit dem sehr umfangreichen S-Bahn-Verkehr und den vielen rasch aufeinander folgenden Stationsaufenhalten ist das recht deutlich zu erkennen, ab einer zunehmenden Komplexität der Aufgabe mit den besagten S-Bahn, RB, RE und IC Verkehr vergrößert sich das Problem der "schwankenden" Fahrplanzeiten der Verkehrseinheiten.
+


Mir ist es schon passiert, dass eine solche Aufgabe beim z.B. probeweisen Abfahren mit der Spieler-Einheit dann sehr stark ruckelte, als ob Fehlberechnungen im Script auch den MSTS beträfe.Daher die Angewohnheit, komplexe Aufgaben im Editor nach dem Abspeichern (im Aufgaben-Editor) wieder neu aufzurufen, die Züge (wiederum im Aufgaben.-Editor) die Routen abfahren zu lassen - und abschliessend zu speichern.

+
Erst dann ist (für mich) die Aufgabe fertig zum Benutzen im MSTS.+

Ist das sonst noch niemanden vorgekommen, dass manche Aufgaben irgendwie "hinken" und erst dann flüssiger laufen, wenn sie im erwähnten Aufgaben-Editor sozusagen noch einmal berechnet und gespeichert werden!
+

mit besten Gruß,
Marcus
+
P.S. warum funktionieren nun die verdammten Leer-Zeilen hier nach dem Zufalls-Prinzip, muss immer 2x "Enter" drücken"

Hallo Marcus,

ja, hatte ich auch so verstanden, daß vom AE die Rede war.

Diese Erfahrungen habe ich nicht gemacht.
Fahrplanberechnung für KIs habe ich nur zu Vor-BIN-Zeiten ausführen lassen, und auch da nur für ausgewählte, z.B. Überholer mit Halt im Überholbahnhof.
Seit es den BIN-Patch gibt, realisiere ich Halts nur noch über Wartepunkte, verzichte gänzlich auf Fahrplanberechnungen und bin gut damit gefahren.
Ich habe immer gestaunt, wie sekundengenau KI-Fahrzeiten zwischen AE und Simulation übereinstimmten.
Das war ja schon für das ordnungsgemäße Funktionieren der Blindzüge Voraussetzung.

Ich klicke allerdings nach jeder Änderung einer Route, eines Dienstes oder im Verkehrsschema auf Speichern sowie auf Berechnen und Speichern.

Es gab Spieler, die meinten, bei meinen Aufgaben vorher irgendwelche Handlungen im AE durchführen zu müssen.
Damit waren sie aber im Irrtum, weil bei Aufgaben immer das zu tun ist, was in der Liesmich steht, und derartiges stand nicht in der Liesmich.

Grüße Cris

Zitat von »Cris«

Seit es den BIN-Patch gibt, realisiere ich Halts nur noch über Wartepunkte, verzichte gänzlich auf Fahrplanberechnungen.

Das funktioniert in der Tat wesentlich einfacher und besser als Fahrpläne für KI-Züge. Zusätzlich kann man durch die Wartepunkte auch noch den Halteplatz des KI-Zuges am Bahnsteig bestimmen, denn insbesondere bei kurzen Zügen sieht es komisch aus, wenn der KI-Zug am Ende der Bahnsteigmarkierung hält, das Empfangsgebäude und die H-Tafel ( für Kurzzüge ) aber 200m weg stehen.

Gruß
Christoph

Hallo,

noch einmal zu den "Abhängigkeiten":

• Nehmen wir an, der MSTS lädt eine Aufgabe. Somit wäre die erste Datei die *.act-Datei (16 KByte Puffer).
  
• In der *.act-Datei wird auf eine *.con-Datei verwiesen. Diese wird geöffnet (zweite offene Datei, 32 KByte Puffer).
  
• In der *.con stößt der MSTS auf eine *.eng (dritte offene Datei, 48 KByte Puffer).
  
• In der *.eng geht es beispielsweise mit einer *.s-Datei weiter (vierte offene Datei, 64 KByte Puffer).
  
• In der *.s-Datei wird auf die erste *.ace-Datei verwiesen (fünfte offene Datei, 80 KByte Puffer).
  
• Diese liest er ein und schließt die *.ace wieder (noch vier offene Dateien, 64 KByte Puffer).
  
• Nun kommt die nächste *.ace (wieder fünfte offene Datei, 80 KByte Puffer).
  
• Nach dem Einlesen schließt wird die *.ace wieder geschlossen (64 KByte Puffer).
  
• Dieses Spiel macht er mit allen *.ace-Dateien in der *.s-Datei.
  
• Dann wird die *.s-Datei geschlossen (noch drei offene Dateien, 48 KByte Puffer).
  
• Nachdem alle Dateien, die in der *.eng auftauchen, nach diesem Muster abgearbeitet sind, wird die *.eng geschlossen (32 KByte Puffer).
  
• Nach dem selben Spiel werden die weiteren *.eng- und *.wag-Dateien in der *.con bearbeitet.
  
• Die *.con wird geschlossen (16 KByte Puffer).
  
• ...
  

Es geht hier rein um das Einlesen der Dateien - also um die Frage, ob sich Leerzeichen und Zeilenumbrüche negativ auswirken.

Wie der MSTS beispielsweise viele kleine oder wenige große Texturen im Arbeits- oder gar Grafikspeicher hält, steht auf einem anderen Blatt. Ich kann hier nur auf Erfahrungen mit der Bodentexturierung zurückblicken. Es macht bei der Performance einen großen Unterschied, ob ich viele kleine,unterschiedlicheTexturen habe oder viele kleine, gleiche Texturen oder eine große Textur, aus der ich Teile ausschneide - und zu allem Überfluss auch noch, ob die Textur nicht komprimiert, komprimiert oder per DXT komprimiert wurde. Die Ergebnisse sind nicht unbedingt vorhersagbar und liegen nicht auf der Hand.

Danke für diese wertvollen Informatinen...
Zurück zum Eingangsproblem...
Conbuilder meckert die zwei Befehle auf einer Zeile zurecht nur an, wenn der zweite Befehl ohne
Leerzeichen oder Space an der schließenden Klammer des ersten klebt.
Ich benutze daher Conbuilder gern, um einfach die fehlerfreie Programmierung der *Eng und *Wag Dateien
zu überprüfen, insbeondere meiner eigenen.
Ob dann die geänderten *Eng, auch richtig fahren und bremsen überprüft er allerdings nicht.
Für die vorbildgerechte Erfüllung des Lastenhefts, ist dann immer noch der "Trottel" vorm Monitor zuständig.
Gruß Baertram

Zitat von »baertram-01«

Conbuilder meckert die zwei Befehle auf einer Zeile zurecht nur an, wenn der zweite Befehl ohne Leerzeichen oder Space an der schließenden Klammer des ersten klebt.

Das hat mich neugierig gemacht.
.
Zur Überprüfung habe ich mal die *.eng-Datei der FCS_101070_AM mal umgeschrieben. Shape & FA in einer Zeile, jeweils mit & ohne Leerzeichen zwischen ) und FreightAnim (.

Das Prüfergebnis war dasselbe.
.

.

Interessant wäre noch der Abschnitt [Shape filename too LONG] . Da scheint der ConBuilder etwas mehr als Dateiname zu werten.
.

Interressant dein Fehlertext...
Habs grad selbst noch mal geprüft, hab seit 2 Monaten ne neue Version des Conbuilders (3.2.22) oder 24
ganz sind sich da die Entwickler wohl nicht einig, welche das auch ignoriert.
Scheint also ne Versionsfrage des Conbuilders zu sein.
Aber eins wird immer noch angemeckert: Wenn hinter Coupling ( irgendwas steht...
Die alte Version war noch ne 2.18 oder so war da jedenfalls gnadenlos...
Gruß Baertram

Zitat von »baertram-01«

... hab seit 2 Monaten ne neue Version des Conbuilders (3.2.22) oder 24

Merkwürdig, da es von ConBuilder - meines Wissens nach - schon lange keine neue Payware-Version erschienen ist.

Die Version,die hier meistens benutzt wird, ist 2.4.7 - das ist die letzte Freeware-Version.
.

.
Nehmen wir die Fehlermeldungen des ConBuilders einfach nur als Hinweis auf Unregelmässigkeiten, die man beheben sollte.
Bei einem stringenten Aufbau von *.eng-, *.wag-, usw.-Dateien hat man jedenfalls keine Probleme und kann diese Dateien kollektiv bearbeiten/ändern.

.