Periodieke treinen

[Dre]

Dag allen,

Ik ben al een tijdje aan m'n eigen dienstregeling aan het bouwen, en heb het volgende probleem. Laat ik eerst de wenselijke situatie uitleggen.

We hebben trein 7024. Deze vertrekt in de periode 12 december 2010 t/m 17 juli 2011 om 7:05 uit Enschede en rijdt richting Deventer (het materieel daartoe komt middels 77024 uit Hengelo). Echter rijdt dezelfde trein 7024 in de periode 18 juli t/m 3 september 2011 slechts vanaf Almelo. Het materieel daartoe wordt ook middels 77024 vanuit Hengelo aangevoerd (dus Hgl-Aml). In de database heb ik daartoe de volgende entry's gemaakt in de tabel "TimeTable" (alleen relevante entry's).

77024mavrwerk0: periode 12-12-2010 t/m 17-7-2011 (Hgl-Es) nummert in Enschede-Kap op ieder spoor om in 7024 (ID Tech = 7024mavrwerk0)

77024mavrvak: periode 18-7-2011 t/m 3-9-2011 (Hgl-Aml) nummert in Almelo op ieder spoor om in 7024 (ID Tech = 7024mavrvak)

77024mavrwerk0: periode 4-9-2011 t/m 11-12-2011 (Hgl-Es) nummert in Enschede-Kap om in 7024 (ID Tech = 7024mavrwerk1)

Uiteindelijk lijkt er wat fout te gaan, want als ik de simulatie laadt om het allemaal te controleren, gesimuleerd op 2 juni 2011 geladen om 7:26, dan worden zowel trein 7024 als 77024 geladen tussen Hengelo en Almelo. 2 juni 2011 is een gewone donderdag, en op die dag zou de 77024 niet meer mogen verschijnen op m'n tableau. Onderstaand heb ik een linkje naar het bestandje geplaatst (waarschuwing, hevig alpha, dus nog niet speelbaar zonder kennis van het bewerken van mdb-bestanden).

Heb ik een fout gemaakt of gaat er iets niet goed met de TimeTable entry's "PeriodStart" en "PeriodEnd"?

Bestand: KLIK HIER

[TjoeTjoe]

Uiteindelijk lijkt er wat fout te gaan, want als ik de simulatie laadt om het allemaal te controleren, gesimuleerd op 2 juni 2011 geladen om 7:26, dan worden zowel trein 7024 als 77024 geladen tussen Hengelo en Almelo. 2 juni 2011 is een gewone donderdag, en op die dag zou de 77024 niet meer mogen verschijnen op m'n tableau. Onderstaand heb ik een linkje naar het bestandje geplaatst (waarschuwing, hevig alpha, dus nog niet speelbaar zonder kennis van het bewerken van mdb-bestanden).

Heb ik een fout gemaakt of gaat er iets niet goed met de TimeTable entry's "PeriodStart" en "PeriodEnd"?

Dre,

met de komende Paasdagen voor de boeg zal ik er niet aan toekomen om je het probleem snel te helpen tackelen.

Als een eerste snelle test heb ik eerst even gekeken welke treinen er nu werkelijk in de sim op de baan worden gezet.

Hiervoor heb ik in het veld Train_ID een voor iedere trein uniek nummer ingevuld.

Het blijkt dat de volgende twee treinen op de rails worden gezet:

1. record 1975 : Train_ID_tech 7024mavrwerk0 , EntryTime 06:57, Periode 12-12-2010 t/m 17-7-2011

2. record 1974 : Train_ID_tech 77024mavrvak, EntryTime 7:10 , Periode 18-7-2011 t/m 3-9-2011

(je kan het bovenstaande ook proberen te bevestigen door van deze treinen één voor één het veld Skip op True te zetten. Dan wordt het record niet door sim geladen. Uiteindelijk boven water moeten komen welk record nu "ten onrechte" geladen wordt)

Het is me zo op het eerste oog even een raadsel waarom die tweede verschijnt, gezien dat daar het tijdvak niet overeenkomt met 2-jun-2011

Enige wat ik zo even kan verzinnen, is dat de sim niet goed overweg kan met jaarovergangen. Misschien 12-12-2010 vervangen door 1-1-2011 en kijken wat er gebeurd

Ga voor je speuren en kom er later, als de paaseieren op zijn zo snel mogelijk op terug

Groeten

Erwin

[Dre]

Dag Erwin,

Eerst maar eens even de data gewijzigd van 12-12-2010 naar 1-1-2011, dat had geen effect (had ik ook niet verwacht, in de database van Arnhem worden periodieke treinen (de D-treinen die na mei '65 als TEE door het leven gingen) ook over de jaargrens heengetrokken

Volgens mij geven de kolommen "PeriodStart" en "PeriodEnd" an sich de problemen (d.w.z. de entry's daarin worden genegeerd). Als ik een simulatie op dezelfde datum twee minuten eerder laadt (dus om 7:24), dan wordt de 7013 maarliefst drie keer geladen tussen Enschede en Hengelo (alle treinen voor de periode 1-1-2011 t/m 17-7-2011, 18-7-2011 t/m 3-9-2011 en 4-9-2011 t/m 11-12-2011 worden tegelijk geladen).

Bij de 77024 heb ik het nog effe gecheckt door de Skip-functie, zodra "77024mavrvak" wordt geladen verschijnt deze, ongeacht de datum binnen de simulatie, tussen Hengelo en Almelo (waar deze zich in het pad van de 7024 drukt, die vervolgens op 161AT wordt geladen.

Voorlopig los ik het maar even op door het hele jaar door één enkele trein te laten rijden (die enkel op de zaterdag anders rijdt dan doordeweeks), de vakantiedienstregeling wordt dan iets wat op m'n to do-lijstje komt.

Groeten,

Andreas

[TjoeTjoe]

Volgens mij geven de kolommen "PeriodStart" en "PeriodEnd" an sich de problemen (d.w.z. de entry's daarin worden genegeerd). Als ik een simulatie op dezelfde datum twee minuten eerder laadt (dus om 7:24), dan wordt de 7013 maarliefst drie keer geladen tussen Enschede en Hengelo (alle treinen voor de periode 1-1-2011 t/m 17-7-2011, 18-7-2011 t/m 3-9-2011 en 4-9-2011 t/m 11-12-2011 worden tegelijk geladen).

Ben bang dat ik jouw bevindingen alleen maar kan bevestigen. Heb van alles geprobeerd (bijv jaartal wijzigen naar 2000, vanwege feit dat sim op dat tijdvak gebaseerd is). Facultief gemaakt, kijken of dat wat uitmaakte, maar ook die waarde (IsFACtrain) lijkt bij tijd en wijle genegeerd te worden. Gledt ook voor type mcn.

Niet dat je er iets aan hebt, maar de PeriodStart en PeriodEnd werkt wel in de MovementOrders tabel

Voorlopig los ik het maar even op door het hele jaar door één enkele trein te laten rijden (die enkel op de zaterdag anders rijdt dan doordeweeks), de vakantiedienstregeling wordt dan iets wat op m'n to do-lijstje komt.

Hoop wel dat Richard hier zijn licht over willen laten schijnen, want vreemd is het wel.

En in Amsterdam lijkt de PeriodStart en PeriodEnd wel te werken

[Dre]

Ben bang dat ik jouw bevindingen alleen maar kan bevestigen. Heb van alles geprobeerd (bijv jaartal wijzigen naar 2000, vanwege feit dat sim op dat tijdvak gebaseerd is). Facultief gemaakt, kijken of dat wat uitmaakte, maar ook die waarde (IsFACtrain) lijkt bij tijd en wijle genegeerd te worden. Gledt ook voor type mcn.

Dat factultatieve treinen bij tijd en wijle genegeerd worden is nog niet zo'n ramp. In mijn database betreft dat enkel goederentreinen. Daar zou een 'Chance of loading' (kans dat een facultatieve trein geladen wordt) ook wel een leuke feature zijn. In de spoorwegwereld kennen we immers ruwweg twee soorten faculatatieve treinen, de FZ (Faculatief, Zonder lok en personeel) en FM (Facultatief Met lok en personeel). De eerste groep zijn eigenlijk treinen die vrijwel nooit rijden, treinen waarvoor een pad is gereserveerd voor het uitzonderlijke geval ze rijden. De tweede groep rijdt echter veel vaker (lijkt eerder op regulier vervoer dat niet altijd benodigd is en zodoende kan uitvallen).

Maar zoals gezegd, voorlopig heb ik er al m'n handen aan vol om een reguliere dienstregeling op poten te zetten, daarbij zijn die periodieke treinen in de 7000-serie en een paar 'bijzondere ritten' (die maar op 1 à 2 unieke dagen plaatsvinden, denk aan overbrengingen, voetbal- of festivaltreinen) peanuts bij...

[martin1325]

Ben bang dat ik jouw bevindingen alleen maar kan bevestigen. Heb van alles geprobeerd (bijv jaartal wijzigen naar 2000, vanwege feit dat sim op dat tijdvak gebaseerd is). Facultief gemaakt, kijken of dat wat uitmaakte, maar ook die waarde (IsFACtrain) lijkt bij tijd en wijle genegeerd te worden. Gledt ook voor type mcn.

Niet dat je er iets aan hebt, maar de PeriodStart en PeriodEnd werkt wel in de MovementOrders tabel

Hoop wel dat Richard hier zijn licht over willen laten schijnen, want vreemd is het wel.

En in Amsterdam lijkt de PeriodStart en PeriodEnd wel te werken

Misschien is het probleem al opgelost maar ik heb ook even gekeken en heb de getallen die onder IsFACTrain staan veranderd van 0 naar -1, dit geldt alleen voor de regels waar een periode in staat, sindsdien gaat het goed en kom ik ook geen dubbele of driedubbele treinen meer tegen.

[TjoeTjoe]

Misschien is het probleem al opgelost maar ik heb ook even gekeken en heb de getallen die onder IsFACTrain staan veranderd van 0 naar -1, dit geldt alleen voor de regels waar een periode in staat, sindsdien gaat het goed en kom ik ook geen dubbele of driedubbele treinen meer tegen.

Nou nee, er is naar mijn weten geen tussen-update van Hengelo geweest die dit zou oplossen.

Huidige versie is naar mijn weten nog altijd 1.6.1.9925 (sommigen wehshoppers hebben 1.6.1.9930)

Hoe dan ook, de periodieke treinen zouden ook zonder de IsFacTrain setting moeten werken. Net als in de simulatie van Amsterdam CS. Het is een wezenlijk verschil of een trein uitsluitend in een bepaalde periode rijdt of dat het een facultieve trein is.

in het geval van Dre zijn probleem, gaat het eigenlijk om "dezelfde" trein, echter deze rijdt in verschillende periodes verschillende diensten op verschillende tijden.

[Dre]

Personentreinen die facultatief zijn? Als dat realiteit is, dan is het maar goed dat het spoorboekje in papiervorm niet meer bestaat, want dat was dan papierverspilling geweest. Zover mij bekend komt facultativiteit alleen voor bij goederentreinen en wil zeggen dat je een treinpad reserveert maar er niet zeker van bent of die trein ook daadwerkelijk gaat rijden. Voor een periodieke trein kan het pad van één en hetzelfde treinnummer per wijzigingsblad verschillen, maar één ding is zeker de trein rijdt.

[TjoeTjoe]

Personentreinen die facultatief zijn?

Nee, inderdaad, daar zijn we het over eens. Dat zou niet kloppen.

Ik vermoed en verwacht dat als de update voor Hengelo eindelijk daar is, dat dit probleem wel uit de wereld is.

Zoals gezegd, in Amsterdam functioneert het wel correct, en Hengelo zal die functionaliteit na die update gewoon hebben.

[Dre]

Die update brengt weer heel andere problemen met zich mee voor mijn dienstregeling. Nu 'verdwijnen' de treinen in Hengelo eenvoudigweg als ze naar tractie of Hgl4c worden gestuurd. Aangezien ik aanneem dat onbeveiligd gebied (zoals in Amsterdam CS) ook in Hengelo weergegeven gaat worden, moet ik dan ook nog nachtovergangen in gaan bouwen (met dus een heel koppel/splistcircus op de sporen 4d, 23, 34 en 336). Godzijdank maken de Syntus-treintjes het daar niet moeilijker op... (Oldenzaal-Zutphen blijft alleen in de nacht van maandag op dinsdag in Hengelo overnachten, materieel voor Almelo-Mariënberg gebruikt spoor 22 en de Grensland Express dumpen we wel ergens op tractie, da's toch de meest saaie omloop ooit).

[TjoeTjoe]

Die update brengt weer heel andere problemen met zich mee voor mijn dienstregeling.

O ja, je bedoelt uitdagingen

Nu 'verdwijnen' de treinen in Hengelo eenvoudigweg als ze naar tractie of Hgl4c worden gestuurd. Aangezien ik aanneem dat onbeveiligd gebied (zoals in Amsterdam CS) ook in Hengelo weergegeven gaat worden, moet ik dan ook nog nachtovergangen in gaan bouwen (met dus een heel koppel/splistcircus op de sporen 4d, 23, 34 en 336).

Tja, de onbeveiligde gebieden zijn daar net even te klein om om dat circus heen te kunnen.

Voor Amsterdam (en uiteraard later ook alle andere sims) komt er een soort hocus-pocus-pilatus-pas MO order waarmee bepaalde complexe rangeeropdrachten sterk vereenvoudigd kunnen worden. Zeker voor iemand als Hobbyman, kan hij ook eens met deze mooie dagen van de zon genieten, in plaats van uren sleutelen aan de timetable database

Kortom, misschien wel wat meer werk voor het samenstellen van een mooie 'alternatieve' dienstregeling. Maar dankbaar zal men zijn als deze functionaliteit ook in Hengelo zal verschijnen. Schitterend toch dat deze al reeds sterke simulatie nog beter wordt en nog meer mogelijkheden zal bieden!

[Dre]

O ja, je bedoelt uitdagingen

Zo'n dienstregeling is één grote uitdaging... maar soms wordt dat nogal problematisch (gelukkig heeft Hengelo heel wat ruimte om materieel op te stellen).

Tja, de onbeveiligde gebieden zijn daar net even te klein om om dat circus heen te kunnen.

Het is nu niet echt "hogeschool-rangeerwerk" wat daar plaatsvindt. 77061 (SGM-III+SGM-III) komt uit Enschede en wordt op 23 of 4d gesplist in 77024 en 77022. 77065 (SGM-II+SGM-III) komt uit Almelo en gaat naar het naastgelegen spoor en wordt de 77018. Later komt de 77069 (SGM-III) leeg uit Deventer en die wordt de 77020. In het weekend blijft er wat materieel overstaan (de combinatie SGM-II+SGM-III komt in het weekend niet in actie), ik zit erover na te denken er een 89000 Hgl-Dv en Dv-Hgl in te gooien om dat stelletje uit te wisselen met een stel uit het westen (het zou immers niet realistisch zijn dat één en dezelfde SGM-II wekenlang in de omloop 77018a Hgl-Aml, 7018a, 7017v, 7054a, 7053v, 7066a, 7065a, 77065a Aml-Hgl zou zitten).

Kortom, misschien wel wat meer werk voor het samenstellen van een mooie 'alternatieve' dienstregeling. Maar dankbaar zal men zijn als deze functionaliteit ook in Hengelo zal verschijnen. Schitterend toch dat deze al reeds sterke simulatie nog beter wordt en nog meer mogelijkheden zal bieden!

Het maat het realistischer, je moet er werkelijk over nadenken hoe je de treinen het onbeveiligd gebied instuurt, want ze moeten er ook nog weer eens uit. Dat je Tc1 om materieel kunt vragen is eigenlijk ook helemaal niet de bedoeling. Tractie in Hengelo heeft over 't algemeen weinig materieel staan om bijsturing te faciliteren. Nu kun je een trein richting Hgl4c, of Tc1/Tc2 sturen zonder de zorgen te hebben hoe het er de volgende ochtend uit komt. Zo werkt dat in de realiteit natuurlijk niet.