Re: Zusi Fehlermeldung

[F(R)S-Bauer]

...

Ok, hätte man Nachschauen können...

mfG

Ralf

[Klaus Schollas]

Hallo Johannes.
Bitte nicht böse sein, ich finde diese von Dir gezeigte Datei nicht. Und worauf müsste ich achten?

Klaus

[Carsten Hölscher]

Sein Einwurf bezog sich nur auf Ralfs Beitrag.

Carsten

[F(R)S-Bauer]

@Johannes,

da bist du aber in einer VM bzw Wine, oder?
Bist du sicher das das auch für Normale Windows System gilt und auch beachtet wird?.
Ich habe jedenfalls auf Anhieb keine Eintrag in W10 gefunden um das zu prüfen.
Bei VM kann man es für die virtuelle Maschinen Abschalten, und ob Wine das unterstützt weis ich nicht.

erledigt.

mfG

Ralf

[F. Schn.]

@Ralf: Das ist der schon häufiger erwähnte Process Explorer. Ausweislich des Screenshots ist das Windows in einer VM, also ein vollwertiges Windows-Betriebssystem, kein Wine. Und bei mir sind die Werte übrigens auch gleich, du kannst also davon ausgehen, dass die Randomization bei Zusi auch tatsälich abgeschalten ist. Generell habe ich bei Stichproben erst mal eine hohe Korellation zwischen 32-bit-Software und Disabled festgestellt.

@Anfragesteller: Siehe Alwins Beitrag.

[Jan]

Jenseits von irgendwelchen exotischeren Formen von Ressourcenmangel könnte es doch vielleicht einfach sein, das Zusi da an die 2 GB-Speichergrenze gerät? Ich hatte den Fehler in der Fahrtrichtung und Gegend neulich auch mal wieder - leider habe ich nicht gedacht, nochmal auf die aktuelle Speicherbelegung von Zusi zu schauen, aber von früheren Vorfällen habe ich noch in Erinnerung, dass Paderborn - Altenbeken - Kassel den Speicherbedarf durchaus an die 2 GB-Grenze bringen kann, insbesondere wenn man die Sichtweite leicht hochgeschraubt hat oder einfach das Pech hat, dass in der eigenen Rechnerkonfiguration irgendwelche Treiber oder sonstwas etwas mehr Adressraum blockieren, während andere mehr Glück haben und gerade noch ohne Speichermangel durchkommen.
Falls das tatsächlich die Ursache ist, wäre man damit wieder beim Wunsch nach einer 64 bit (oder zumindest LARGEADRESSAWARE)-Version von Zusi.

[F. Schn.]

Carsten betont zwar immer wieder, dass Delphi kein so schlechter Compiler ist, aber das ist beides mit ihm in der offenbar aktuell verwendeten Version nicht mit vertretbarem Aufwand möglich. Und wie ich hier schon mal geschrieben habe: Wenn das Miniatur-Wunderland schon 4 Wochen für eine Umstellung für einen kleineren Versionsunterschied gebraucht hat (womöglich waren da allerdings Hardware-Nahe Sachen dabei, kann ich nicht einschätzen), wie lange wird das dann für Zusi brauchen...

2-GB-Grenze muss übrigens mit dem ProzessExplorer untersucht werden, der Taskmanager liefert da irreführende Werte.

[Jan]

2-GB-Grenze muss übrigens mit dem ProzessExplorer untersucht werden, der Taskmanager liefert da irreführende Werte.

Keine Sorge, der ist bei mir standardmäßig im Einsatz. Ja, zumindest under Windows 7 liefert der Taskmanager nur das, was beim Process Explorer als WS Private auftaucht.

[Johannes]

Carsten betont zwar immer wieder, dass Delphi kein so schlechter Compiler ist, aber das ist beides mit ihm in der offenbar aktuell verwendeten Version nicht mit vertretbarem Aufwand möglich.

Der Speichermanager von Delphi ist so designt, dass er vom Programmierer problemlos austauschbar ist. Der Speichermanager von Delphi >= 2006 (https://github.com/pleriche/FastMM4" target="_blank, Mozilla Public License) ist als solches austauschbares Modull fuer Delphi ab Version 4 verfuegbar und kann LARGEADDRESSAWARE.

Es kann natuerlich sein, dass andere Komponenten (32-Bit-DirectX? DLLs?) Probleme mit Pointern jenseits der 2-GB-Grenze haben. Das kann ich nicht beurteilen. Aber prinzipiell sollte es moeglich sein.

[F. Schn.]

Ok, also ist LAA doch mit vertretbarem Aufwand möglich. x64 allerdings weiterhin nicht.

[Alwin Meschede]

Es kann natuerlich sein, dass andere Komponenten (32-Bit-DirectX? DLLs?) Probleme mit Pointern jenseits der 2-GB-Grenze haben.

DirectX 9 ist noch gerade eben jung genug, dass Microsoft seinerzeit alle Teile LA-aware gemacht hat. Sobald Zusi das nutzt und die Strecken es auch erfordern, ist aber natürlich die Konsequenz, dass die verbliebenen paar Leute mit 32-Bit-Betriebssystemen nur noch gepflegt kacken gehen können, denn zumindest der Raum Kassel wird auf ihren Kisten nicht mehr laufen. Wenn man der monatlichen Hardware-Erhebung von Steam folgt, setzen allerdings nur noch 2,64 % aller Spiele-Rechner ein 32-Bit-Windows ein. 97,36 % der Rechner hätten kein technisches Problem damit, wenn Zusi diesen Schritt ginge.

Sobald am Knoten Kassel Erweiterungen vorgenommen werden, gehe ich davon aus dass wir nicht mehr ohne 64 Bit oder LA-aware auskommen werden:


Das rote ist Zusis standardmäßiger Laderadius für Module von 7000 m, zentriert auf die Stelle mit der höchsten Speicherauslastung im Rbf Kassel. Das grüne sind die derzeit existierenden Streckenmodule. Die schwarzen Strecken innerhalb des roten Bereichs sind Streckenmodule, die noch nicht gebaut sind (innerhalb der Blase befinden sich an noch nicht gebauten Modulen Speele, Ahnatal, Oberzwehren, Niederzwehren, Unterstadt, Bettenhausen). Im Moment haben wir noch die Situation, dass mit den derzeitigen Fahrplänen und bei vernünftig gewählten Simulatoreinstellungen das Ding so gerade eben noch nicht abstürzt (bei nicht ganz so günstigen Begleitumständen, wenn man z.B. mit viel Zeitraffer nach Kassel reingefahren ist, kann man es bereits jetzt zum Knallen bringen). Das dürfte sich ändern, sobald in diesem Gebiet noch 1-2 Streckenmodule hinzukommen. Ich sage hiermit schonmal an, dass der Lückenschluss Ersrode - Wilhelmshöhe als künftiges Bauprojekt derzeit bei mir hoch im Kurs steht, nachdem Erfurt und der Hl-Signal-Demonstrator bei Güterglück durch sind. Bis dahin hat Carsten noch Zeit, seinen Simulator entweder per 64 Bit oder LA-aware für die Zukunft fit zu machen

[Michael_Poschmann]

Hallo Alwin,

ein vergleichbares Bild ließe sich vermutlich für den Moloch Hagen zaubern, da halte ich Verhältnisse für noch kritischer als in Kassel.

Grüße
Michael

[F. Schn.]

ein vergleichbares Bild ließe sich vermutlich für den Moloch Hagen zaubern, da halte ich Verhältnisse für noch kritischer als in Kassel.

Hier könnte Ihr Witz über die Streckenbauproduktivität (nicht qualität!) von Alwin verglichen mit der der oberen Ruhrtalbahn stehen.

Gruß

F. Schn.

PS: Und hier könnte dann ein Witz über die Streckenbauproduktivität der Oberen Ruhr verglichen mit der Fst-Bauproduktivität der 360 stehen...

[Michael Springer]

Alwin baut meistens Strecken von 1994-2017, Michael von 1970-1985.... damals gab es auch noch die dreifache Anzahl an Gleisen.

Ist doch ganz klare Logik

[F. Schn.]

...was ist für Zusi aufwendiger zu laden: Gleise oder Büsche auf Schotterflächen...?

(Nein, eigentlich baut Alwin den leistungsfähigsten Zustand, den er findet, während Micheal den GWB zwischen Kassel Hbf und Kassel-Wilhelmshöhe oder zwischen Kassel-Rbf und Niedervellmar zurückbaut, weil seine Vor-GWB-Unterlagen genauer sind, als die vorhanden Vorbildbilder seit dem Einbau des GWB. Zu dem Thema S-Bahn Köln->Düren, die ja weniger Gleise als zu Diesel-Zeiten (4 < 2) hat, oder das Thema Blockabstand Unterlüß, finden sich ja hier schon genug Themen. Aber gerade für die vielen Güterbahnhöfe auf einzelnen Haufen im Raum Kassel oder Hagen trifft das mit den Gleisen sehr wohl zu. Wobei man aber auch nicht vergessen darf, dass Weichenrückbau je nach Örtlichkeit auch mit einer Erhöhung der Geschwindigkeit der verbleibenden Weichen verbunden seien kann. Dann ist es auf einmal gar nicht mehr so einfach, einen leistungsfähigsten Zustand zu ermitteln. Vermutlich hatten wir den Fall aber noch nicht.)

[Wolfgang Hüttner]

Vielleicht kann man für solche Knoten ja auch noch etwas an der Ladelogik ändern. Wenn ich Richtung Warburg unterwegs bin müssen ja Module in Richtung Göttingen oder Gießen nicht geladen werden, auch wenn sie innerhalb des Radius liegen würden. Insofern sollten selbst bei weiteren Erweiterungen im Raum Kassel nicht mehr Module gleichzeitig geladen werden müssen, wie auch schon beim derzeitigen Streckenumfang. Und wie F.Schn. schon bemerkte, das Problem ist nicht auf Kassel oder Hagen beschränkt, es wird bei jedem größeren Bahnknoten entstehen.

Gruß
Wolfgang

[Alwin Meschede]

Vielleicht kann man für solche Knoten ja auch noch etwas an der Ladelogik ändern. Wenn ich Richtung Warburg unterwegs bin müssen ja Module in Richtung Göttingen oder Gießen nicht geladen werden, auch wenn sie innerhalb des Radius liegen würden.

Ich stelle es mir schwierig vor, das praxistauglich hinzubekommen. Beispiel: Das Modul Niedervellmar liegt zwar nicht im Fahrweg von Kassel nach Warburg, allerdings fährt man in ca. 50 Meter Entfernung von der Modulgrenze her und würde in den himmelblauen Abgrund blicken, wenn dieses Modul nicht geladen würde.

[Wolfgang Hüttner]

So schwierig wäre das m.E. auch nicht. Man könnte ja z.B. mit zwei Radien arbeiten.
Alles, was dann im engeren Radius von beispielsweise 2000m liegt, wird auf jeden Fall geladen. Im größeren Radius dann nur das, was im Bereich des aktuellen Fahrwegs liegt.
Damit würde dann im konkreten Fall Niedervellmar geladen, aber Ihringshausen und alle weiteren in diese Richtung nicht.

Gruß
Wolfgang

[Carsten Hölscher]

Das mit der Fahrwegvorausschau ist hoch komplex, vor allem auch weil sich ja die anderen Objekte auch bewegen können.
Man könnte auch den Laderadius bei hoher Speicherlast dynamisch reduzieren, was dann aber die Gefahr mit sich bringt, dass man in leere Landfschaft fährt. Wichtig ist vor allem aber, dass wir mit den Polygonen und vor allem Texturen haushalten. Ich erzähle das seit Anfang an, hab aber immer wieder den Eindruck dass man es nicht gerne hört.

Carsten

[Matthias H.]

Wichtig ist vor allem aber, dass wir mit den Polygonen und vor allem Texturen haushalten

Es gibt sicher ein paar Beispiele für verschwenderischen Umgang mit Polygonen, d. h. übertrieben viele Polygone ohne optischen Mehrwert. Allgemein würde ich aber nicht sagen, dass für Zusi übertrieben detailliert gebaut wurde und wird.

Mit den Texturen könnte man, z. B. für Wohnhäuser - zumindest zukünftig - effizienter umgehen, ohne Qualitätseinbußen. Im Bestand haben z. B. die meisten Häuser eine eigene Textur, obwohl zu großen Teilen die selben Flächen verwendet werden und teilweise Bereiche frei bleiben. Ohne das jetzt genau angeschaut zu haben, behaupte ich mal, dass man im Bestand mit einer einzigen Textur 1024x1024 "Wohnhaus Fassade weiß" 20 einzelne kleinere Texturen à la "Hauptstrasse xy" ersetzen könnte.

Das wird aber allgemein das Problem nicht lösen. Die Bildschirme sind größer geworden. Eine 256x256 Textur, die vor 10 Jahren auf 17 Zoll noch vernünftig aussah, sieht auf der 24 Zoll Kiste matschig aus.
Also nehme ich als Objektbauer heute gleich die 512x512. Und die übrige Welt hat sich, was die Grafikqualität angeht, auch weitergedreht. Man sieht, was möglich ist und was die durchschnittliche Hardware hergibt. Da fällt es mir schwer, nach Maßstäben von 2006 zu bauen.
Und die Ansprüche steigen, siehe neue HD-Führerstände. Die alten sahen vor ein paar Jahren auch noch gut aus.

Gruß
Matthias