Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Bekannte Fehler in 0.88
#11
Tag zusammen!

Alle Beobachtungen mit pak64 und GDI auf W2k.

Ein paar Kleinigkeiten, die man mal bei Gelegenheit beheben könnte:

Das LMT merkt sich mal wieder seine Einstellungen nicht (Fenstergröße).
(Scheint ein Evergreen zu werden... )

Selbst bei Karten mit relativ geringer Städteanzahl (nicht mehr wie 10) bekomme ich regelmäßig doppelte Städtenamen generiert.

In jedem Fabrikinfofenster findet sich noch die Bezeichnung 'Supplier'.
Bitte in "Versorger" o.ä. ändern - Danke.

Im Fahrzeugdepotfenster sollte man vielleicht die Anzeige der Fahrzeuginfos alle vereinheitlichen. Bei den Anhängern findet sich an 3. Position der Eintrag "Zuladung" und an 5. "Höchstgeschwindigkeit". Die beiden einfach mal tauschen, dann liest sich das viel flüssiger. (Macht sich im Bus-Menü besonders bemerkbar)

Die Zeitrafferfunktion >> verursacht sehr oft bei mir ein Einfrieren von ST (scheint sich aber nach ein paar Minuten wieder zu fangen). Soweit ich das sagen kann, oft gegen Ende (24:00 Uhr) eines Tages (und mehrmaligem An-Aus).
Oder ist mein Rechner etwa dafür zu langsam?
Wie schnell soll die Zeit dort eigentlich durchlaufen? Mit welcher manuellen Zeitbeschleunigung ist das vergleichbar?
Simutrans braucht mehr Dynamik...
Zitieren
#12
Zitat:Original von blackbox
Tag zusammen!
Ja, gute Nacht wohl eher Smile

Zitat:Original von blackbox
Die Zeitrafferfunktion >> verursacht sehr oft bei mir ein Einfrieren von ST (scheint sich aber nach ein paar Minuten wieder zu fangen). Soweit ich das sagen kann, oft gegen Ende (24:00 Uhr) eines Tages (und mehrmaligem An-Aus).
Oder ist mein Rechner etwa dafür zu langsam?
Wie schnell soll die Zeit dort eigentlich durchlaufen? Mit welcher manuellen Zeitbeschleunigung ist das vergleichbar?
Stockung beim Monatswechsel ist je nach Rechner schon bei T=1 möglich; >> hat meiner Beobachtung nach keinen festen T-Wert, sondern immer die Geschwindigkeit, bei der noch 5 sim loops möglich sind, wäre also rechnerabhängig.
Zitieren
#13
Beim Monatswechsel wird viel aktualisiert (Routen usw.), deshalb wohl erhöter rechenaufwand.
Zitieren
#14
Das mit dem Linienmanagementfenster geht schief, weil wegen des eingeführten Spielerwechsels es jetzt mehrere Fenster geben muss. Daher kann es sich seine Einstellungen nicht mehr adhoc merken. (Hätte aber durchaus eine Idee, wie man das Ändern kann). Nur, diese quick and dirty-Lösungen mit statischen Fenster klauen jede Menge Speicher und Rechenzeit.

Die Zeitrafferfunktion macht immer abwechselnd eine Bildschirmupdate und dann einen Step, so schnell die beiden halt gehen. Dauert der Step länger, ruckelts. Priorität hatten beim schnellen Vorlauf die Berechnungen, nicht die Grafik.
Zitieren
#15
Vielleicht hatte ich mich etwas unglücklich ausgedrückt. Mit Monatswechsel hat das nichts zu tun. Das ST da etwas mehr Rechenzeit braucht, ist mir ja bekannt und dieser Effekt ist bei mir auch nicht sonderlich gravierend.

Dauert der Step länger, ruckelts.
Wenn es nur "ruckeln" würde, hätte ich nichts gesagt. Ich habe es jetzt nochmal etwas genauer untersucht. Es läßt sich zu beliebigen Uhrzeiten reproduzieren. Der Zeitraffer entspricht bei mir ungefähr T = 6 bis 7. Bei mir wird ST für ungefähr 3 Minuten "eingefroren", immer dann, wenn ich den Zeitraffer verlassen will. Hier mal als Beispiel:

- Zeitraffer läuft gerade und wird um 8:00 Uhr deaktiviert
- ST zeigt jetzt für (immer ziemlich genau) 3 Minuten keine Reaktion mehr (CPU unter Vollast)
- ST aktualisiert sich jetzt wieder und steigt bei 20:00 Uhr des selben Tages wieder ein

Wenn ich aber der einzige hier bin, bei dem dieser Effekt auftritt, schieben wir das eben solange auf meinen Rechner.

zum LMT:
ST und die leidigen Fenster - eine wohl nie endende Geschichte. Gerade beim LMT wird es schnell lästig, immer und immer wieder die Fenstergröße nachzujustieren, da ich es sehr oft nutze. Darum hatte ich mich damlas schon dafür eingesetzt, daß dieses Fenster seine Eigenschaften beibehält. Bitte, finde dafür irgendeine vertretbare Lösung, ich wäre dir überaus dankbar dafür.
Simutrans braucht mehr Dynamik...
Zitieren
#16
Zitat:Original von blackbox
Wenn ich aber der einzige hier bin, bei dem dieser Effekt auftritt, schieben wir das eben solange auf meinen Rechner.
Ich muss dieses Verhalten leider bestätigen - auch auf einem schnellen Rechner. Besonders ein versehentlicher Doppelklick auf den >>-Button endet oft so.
Dirk Burkholz

"Geschäftsführer" (Forum-Administrator / Webmaster)

Simutrans bei MyMiniCity
Zitieren
#17
Vom Stillstand nach >> sind schnelle Rechner wohl noch mehr betroffen als langsame; habe einen AMD 600MHz mit 192 MB RAM (Linux), >> ist bei meiner 64x64-Karte etwa T=2 - 2,5.
Schaltet während der >>-Phase mal die Anzeige ein und schaut auf die sim-Werte: die explodieren beim Abbremsen regelrecht (bei mir nach einem Monat etwa 600), beim Einschalten gabs auch schon stark negative Werte (einige Hunderttausend).
Der Stillstandseffekt stellt sich bei mir nicht ein oder vielleicht erst, wenn ich >> länger laufen lasse und sich noch mehr sims aufgestaut haben, müsste das noch testen.
Zitieren
#18
Auch nach längerem Laufenlassen (12000 aufgestaute sims) kann ich den Fehler nicht reproduzieren, auch nicht mit schnellem beschleunigen/abbremsen

Getestet habe ich es mit diesem Spiel (pak128), probiert mal, ob es damit bei euch auch auftritt; ihr benötigt auch die beiden zugkraftverstärkten Lokomotiven. Dann sehen wir, ob es an der Kartengrösse oder am OS liegt.


Angehängte Dateien
.sve   COM65.sve (Größe: 133,43 KB / Downloads: 381)
.pak   vehicle.BR103.pak (Größe: 12,02 KB / Downloads: 387)
.pak   vehicle.Re620.pak (Größe: 12,47 KB / Downloads: 419)
Zitieren
#19
Die Werte sind in der Anzeige sind beliebig, die stimmen nur sehr bedingt mit den tatsächlichen Werten überein. Der Beschleunigungsfaktor beim schnellen Vorlauf hängt im wesentlichen von der Anzahl der Haltestellen und Konvois ab und kann von 60 bis 0,5 reichen.

Das mit dem Einfrieren passierte bei mir nur nach Doppelklick. Da versuchte dann Simutrans eine negative Zeit einzuholen oder so. Konnte die Ursache noch nicht richtig finden.
Zitieren
#20
Hier mal 'ne kleine Testkarte: pak64 - 64x64 - 1 Stadt

Hiermit kann ich den Effekt fast zu 100% reproduzieren.
Vielleicht tust du dich mit der Karte leichter, den Fehler zu finden.

Der ReInit dauert mit der Karte zu Beginn nur ~5 Sekunden. Es ist mir mit der Karte bisher nur gelungen, den Zeitraffer sauber zu deaktivieren, wenn ich ihn mindestens ca. 30 Sekunden laufen lasse. Kürzere Abstände führten hier fast immer zum sicheren Hänger.

Noch eine Beobachtung: Um so häufiger man den Zeitraffer benutzt, umso länger scheinen die ReInits zu dauern - bin jetzt schon bei 20 Sekunden, obwohl ich keine Änderungen an der Karte vorgenommen habe.
Nachtrag: Wenn man ST komplett schließt und wieder die Karte neu einlädt, bleiben die längeren ReInits erhalten...


Angehängte Dateien
.sve   x1.sve (Größe: 19,86 KB / Downloads: 381)
Simutrans braucht mehr Dynamik...
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste