Seite 2 von 2
Re: zur Neuen Version 3.84R2
Verfasst: Sonntag 30. Dezember 2007, 00:53
von Rolf R
Bekommst Du denn die Meldung, dass die Abfahrt ausgefallen ist?
Gruß
Rolf
Re: zur Neuen Version 3.84R2
Verfasst: Sonntag 30. Dezember 2007, 08:11
von Jan Eisold
Hallo,
@Timm: Vielleicht kannst du uns das Netz mal zur Verfügung stellen. Das würde die Fehlersuche wahrscheinlich erleichtern. [img]icon_confused.gif[/img]
MfG Jan
Re: zur Neuen Version 3.84R2
Verfasst: Sonntag 30. Dezember 2007, 08:56
von Seb144
Hallo,
das Problem hatte ich bei mir auch. Es liegt daran, dass am Taktpunkt die Umlaufnummer geändert wird (n=max). Danach ist sie z.B. 999 und nicht mehr 2, und in der neuen Version ist dann der Taktpunkt nicht mehr gültig(wegen der Bedingung u=2), wärend es bisher funktioniert hat.
Abhilfe sollte schaffen:
*(z=So:19:30-Mo:8:00,u=2+900-999,N=MAX)
(Falls mit N=MAX eine Umlaufnummer im Bereich 900 bis 999 zugewiesen wird.)
Tschüss,
Sebastian
Re: zur Neuen Version 3.84R2
Verfasst: Sonntag 30. Dezember 2007, 09:55
von Timm
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Hallo,
das Problem hatte ich bei mir auch. Es liegt daran, dass am Taktpunkt die Umlaufnummer geändert wird (n=max). Danach ist sie z.B. 999 und nicht mehr 2, und in der neuen Version ist dann der Taktpunkt nicht mehr gültig(wegen der Bedingung u=2), wärend es bisher funktioniert hat.
Abhilfe sollte schaffen:
*(z=So:19:30-Mo:8:00,u=2+900-999,N=MAX)
(Falls mit N=MAX eine Umlaufnummer im Bereich 900 bis 999 zugewiesen wird.)
Tschüss,
Sebastian</tr></td></table>
Hallo!
@Sebastian: Vielen Dank für den Tipp! [img]icon_biggrin.gif[/img]
Aber trozdem sollte das geändert werden, da sonst die Züge auch bei nem Linienwechsel nicht mehr halten dürften...
Viele Grüße
Timm
Re: zur Neuen Version 3.84R2
Verfasst: Sonntag 30. Dezember 2007, 12:38
von Matches
Guten Tag!
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Aber trozdem sollte das geändert werden, da sonst die Züge auch bei nem Linienwechsel nicht mehr halten dürften... </tr></td></table>
Linien werden aber weiterhin geändert und bleiben danach bis zur Abfahrt am Taktpunkt stehen.
Nun möchte ich noch ein Problem schildern: Bei Neubau eines Depots, wenn man alle Angaben über Name, Geschwindigkeit und die Ausrückrichtung angegeben hat und alles bestätigt und erneut das Dialogfenster öffnet, muss ich feststellen, dass die Ausrückrichtung wieder auf ihren Ursprung zurückgekehrt ist. Sollte meines Wissens ja nicht passieren oder?
STN, Matches
Re: zur Neuen Version 3.84R2
Verfasst: Sonntag 6. Januar 2008, 13:15
von Jan Eisold
Tagchen,
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Nun möchte ich noch ein Problem schildern: Bei Neubau eines Depots, wenn man alle Angaben über Name, Geschwindigkeit und die Ausrückrichtung angegeben hat und alles bestätigt und erneut das Dialogfenster öffnet, muss ich feststellen, dass die Ausrückrichtung wieder auf ihren Ursprung zurückgekehrt ist. Sollte meines Wissens ja nicht passieren oder? </tr></td></table>
Nein, das Problem habe ich bei mir bisher nicht beobachten können. Aber ich habe festgestellt, dass alle Depot-Daten übernommen werden, wenn man ein Depot umsetzt - auch, wenn man vor dem Bestätigen ("Depot x ex. schon, soll es umgesetzt werden ?") am neuen Standort bereits andere Daten eingegeben hat.
MfG Jan
Re: zur Neuen Version 3.84R2
Verfasst: Sonntag 6. Januar 2008, 20:53
von Jan Bochmann
Guten Abend,
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Hallo,
das Problem hatte ich bei mir auch. Es liegt daran, dass am Taktpunkt die Umlaufnummer geändert wird (n=max). Danach ist sie z.B. 999 und nicht mehr 2, und in der neuen Version ist dann der Taktpunkt nicht mehr gültig(wegen der Bedingung u=2), während es bisher funktioniert hat.
</tr></td></table>
Ja. Bisher hat das zwar funktioniert, aber dafür hat es nicht funktioniert, wenn mehrere Intervalle für unterschiedliche Zugnummern angegeben waren.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">
Abhilfe sollte schaffen:
*(z=So:19:30-Mo:8:00,u=2+900-999,N=MAX)
(Falls mit N=MAX eine Umlaufnummer im Bereich 900 bis 999 zugewiesen wird.)
</tr></td></table>
Oder noch viel besser: Den Wechsel auf einen Datenwechselpunkt verlegen, der hinter dem Taktpunkt eingebaut wird. Solche Kombinationen verschiedener Funktionen führen immer wieder zu Problemen und Störungen, und sie werden das auch in Zukunft tun.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">
Hallo!
@Sebastian: Vielen Dank für den Tipp! [img]icon_biggrin.gif[/img]
Aber trozdem sollte das geändert werden, da sonst die Züge auch bei nem Linienwechsel nicht mehr halten dürften...
</tr></td></table>
Der Linienwechsel an gleicher Stelle funktioniert, weil sich der Taktpunkt die aktuelle Linie des Zugs bei dessen Ankunft merkt, solange dieser dort steht. Der Taktpunkt müßte sich also analog dazu die Zugnummer bei der Ankunft merken. Dazu müßte aber das Datenformat der Netzdateien erweitert werden, es ist also erst mit einer neuen Programmversion wirklich zu korrigieren.
Dennoch bleibt es unzuverlässig, wenn auch in seltenen Fällen. Beispiel: Ein Zug kommt als Linie 1 an und wechselt auf die Linie 2. Während der Zug noch wartet, löscht der Nutzer die Linie 1.
Ein ähnlicher Fall ist z.B. der Wechsel der Zugkategorie auf s (Sonderzug). Dann müßte der Zug gleich weiterfahren. Das macht er aber nicht, weil der Zugtyp bei der Ankunft ausgewertet wird.
Viele Grüße
Jan B.
Re: zur Neuen Version 3.84R2
Verfasst: Montag 14. Januar 2008, 12:57
von Jan Bochmann
Guten Tag,
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Guten Tag!
Nun möchte ich noch ein Problem schildern: Bei Neubau eines Depots, wenn man alle Angaben über Name, Geschwindigkeit und die Ausrückrichtung angegeben hat und alles bestätigt und erneut das Dialogfenster öffnet, muss ich feststellen, dass die Ausrückrichtung wieder auf ihren Ursprung zurückgekehrt ist. Sollte meines Wissens ja nicht passieren oder?
STN, Matches</tr></td></table>
Sollte nicht passieren, aber es gibt hier zwei Situationen:
1. Es ist ein wirklich neues Depot. Dann funktioniert es, jedenfalls ist kein Fehler bekannt.
2. Man gibt den Namen und die Gleisnummer eines Depotgleises ein, das schon existiert. In diesem Fall wird das vorhandene an die neue Position verschoben (nach Rückfrage). Dabei war es in BAHN 3.84r1 so, daß die neu eingegebenen Daten übernommen worden sind, d.h. die alten gingen verloren. Das ist insbesondere bei einer verknüpften Signalanlage ärgerlich, und deshalb wurde es in 3.84r2 geändert: Die neu eingegebenen Daten werden ignoriert und stattdessen die des alten Depotgleises übernommen. Wenn dieses allerdings eine Ausrückrichtung hat, die beim neuen gar nicht zum Grafikelement paßt, dann wird für das neue die Standardrichtung eingestellt.
Die Übernahme der neu festgelegten Richtung wird in Zukunft noch ergänzt, bei den anderen Daten bleibt es aber bei der Methode von 3.84r2. D.h. um diese zu ändern, muß das Depotgleis ein zweites Mal bearbeitet werden.
Gruß
Jan B.
Re: zur Neuen Version 3.84R2
Verfasst: Donnerstag 17. Januar 2008, 00:12
von Olli_K
also die ewige warterei bei den signalanlagen nervt schon ein bissl
das erstellen von signalanlagen dauert bei mir mind 8 und max 15 sec(bis jetzt) das abreißen eines elementes dagegen 15-20sec
da wird das bauen eines primitiven streckenblocks zum dauerlutscher
ansonsten läufts schon schön schnell
-------
Systeminfo:
AMD Athlon(tm) XP 2600+
ASUSTeK Computer INC. A7N8X - nForce2
2x Siemens HYS64D64329GU-6 512MB DDR-SDRAM
Dateianhang/Attachment
downtowninfo.txt
Re: zur Neuen Version 3.84R2
Verfasst: Freitag 16. Mai 2008, 17:39
von Jan Bochmann
Guten Tag,
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">also die ewige warterei bei den signalanlagen nervt schon ein bissl
das erstellen von signalanlagen dauert bei mir mind 8 und max 15 sec(bis jetzt) das abreißen eines elementes dagegen 15-20sec
da wird das bauen eines primitiven streckenblocks zum dauerlutscher...
</tr></td></table>
Das wurde in 3.84r3 etwas optimiert.
MfG
Jan B.
Re: zur Neuen Version 3.84R2
Verfasst: Mittwoch 4. Juni 2008, 12:54
von LVT771
Hallo
habe mir mal die Datei Anderstadt runtergeladen, da die ganzen selbstgebauten Dateien alle nicht mehr gelaufen sind.
Auch Anderstadt läuft nur mit Geschwindigkeit 19 und alles drunter ein einheitliches Stocken und die Züge schleichen bleiben stehen fahren voll und wieder von neuen ????
Kann mir jemand eine Erklärung geben, danke im Vorraus
Volker
Re: zur Neuen Version 3.84R2
Verfasst: Mittwoch 4. Juni 2008, 13:26
von micha88
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Hallo
habe mir mal die Datei Anderstadt runtergeladen, da die ganzen selbstgebauten Dateien alle nicht mehr gelaufen sind.
Auch Anderstadt läuft nur mit Geschwindigkeit 19 und alles drunter ein einheitliches Stocken und die Züge schleichen bleiben stehen fahren voll und wieder von neuen ????
Kann mir jemand eine Erklärung geben, danke im Vorraus</tr></td></table>Versuche mal, den Bremsfaktor zu verändern. Falls es noch aktiviert ist, kannst du auch "Zeitsteuerung über MS-Windows-Timer" ausstellen. Diese Einstellungen erreichst du im Menü unter Optionen -> Geschwindigkeit.
Re: zur Neuen Version 3.84R2
Verfasst: Mittwoch 4. Juni 2008, 14:32
von LVT771
DANKE mit der Bremskurve gespielt und unter 119 läuft das Spiel wieder
Volker