Dienstregeling Hengelo 29 januari - 9 juni 2001

[Hobbyman]

Dre,

Dat zijn precies dezelfde zaken waar ik de afgelopen 4 maanden ook tegen aan gelopen ben.

Het aangeven van de passeertijden op tussengelegen haltes is zonder meer noodzakelijk.

Ik heb al meegemaakt dat 2 treinen door het ontbreken van de passeertijden in het TNV venster tussen Hgl en Aml op de verkeerde posities werden geplaatst.

Met als gevolg dat ik de IC onder een cargonummer naar spoor 6 leidde en de cargo als 16xx naar spoor 4 ging.

Het is weliswaar een eenmalig iets bij de start van de sim, maar het behoort gewoon niet te gebeuren.

Initieel zijn er ook veel te weinig pathtemplates aangemaakt.

Maar een pathtemplate toevoegen is niet zo eenvoudig als het lijkt.

Volgens Richard is er geen SDK document voor Hengelo en dus tast ik in het duister voor wat betreft de benamingen van sommige spoorsecties.

Als er in een pathtemplate een spoorsectie ontbreekt zal het wel/niet/minder (?) goed werken.

Bovendien kloppen alle ingevoerde EntrypointTime voor treinen die het nieuwe path gaan gebruiken, niet meer !

Met als gevolg dat treinen meestal 2 maal op het scherm worden gezet.

Het aantal PathTemplates tussen Hengelo en Almelo alleen al bedraagt 15 (mogelijke vertreksporen) x 15 (mogelijke aankomstsporen) = 225

Die zijn natuurlijk niet allemaal benodigd. Als er geen trein rijdt is het pathtemplate ook niet benodigd.

De grote vraag is: waar geven we voorrang aan ?

[Dre]

Initieel zijn er ook veel te weinig pathtemplates aangemaakt.

Maar een pathtemplate toevoegen is niet zo eenvoudig als het lijkt.

Volgens Richard is er geen SDK document voor Hengelo en dus tast ik in het duister voor wat betreft de benamingen van sommige spoorsecties.

Als er in een pathtemplate een spoorsectie ontbreekt zal het wel/niet/minder (?) goed werken.

Als je minder spoorsecties gebruikt zal de simulatie minder precies kunnen berekenen waar een trein bij het opstarten van de simulatie is. Zou je bij voorbeeld een pad Hengelo-Almelo slechts samenstellen uit de spoorsecties 148AT, 130AT, Hengelo-Almelo_9, Hengelo-Almelo_0, A122T en A92T, dan kan de simulatie de trein niet laden in een sectie tussen Hengelo-Almelo_0 en Hengelo-Almelo_9 (bijvoorbeeld bij Borne, dat in Hengelo-Almelo_7 ligt). Je moet aan de andere kant ook voorkomen dat treinen op wissel geladen worden, dus als je wil dat een trein in Almelo via spoor 5b naar 4a gaat, dan moet je het pad niet compleet maken met 'A94T-83BT-81AT-A66T', maar slechts de hele spoorsectie aangeven (dus alleen A94T (=5b) en A66T (=4a). Helemaal onderaan heb ik even een linkje naar een txt-bestand gezet met alle spoorsecties binnen de simulatie Hengelo (aanvankelijk wilde ik het in een code-tag zetten, maar daarvoor is de lijst te lang).

Bovendien kloppen alle ingevoerde EntrypointTime voor treinen die het nieuwe path gaan gebruiken, niet meer !

Met als gevolg dat treinen meestal 2 maal op het scherm worden gezet.

Voorlopig kun je daar wat aan doen door een aantal 'momenten' aan te geven waarop je de sim kunt starten. Naar mate de dienstregeling meer en meer ingevuld wordt krijg je dan uiteindelijk de situatie dat er op elk moment gestart kan worden. Momenteel moet je er ook vanuit gaan dat je de simulatie ook al op heel veel momenten kunt starten zonder dat er ook maar een vuiltje aan de lucht is, m.n. als er geen "speciale" (=treinen buiten het reguliere partroon) worden geladen. De meeste treinen die in de sim worden geladen (d.w.z. ergens op het tableau) hebben over 't algemeen wel een 'eigen' path dat goed is.

Het aantal PathTemplates tussen Hengelo en Almelo alleen al bedraagt 15 (mogelijke vertreksporen) x 15 (mogelijke aankomstsporen) = 225

Volgens mij hoef je niet het begin altijd daadwerkelijk aan te geven, als een trein vanaf een spoor in de sim laadt (dus niet uit een spawnpoint komt) dan wordt deze geladen uit de kolom ExtraordinaryTrack. Voor treinen die uit Hengelo vertrekken hoef je niet apart voor elk spoor een pathtemplate te maken, je kunt volstaan door een algemeen pad dat begint bij A130T (= eerste sectie van het rechterspoor richting Almelo).

De grote vraag is: waar geven we voorrang aan ?

Een goed werkende basisdienstregeling die bij de sim geleverd wordt lijkt me meer prioriteit te hebben dan een uitbreiding daarop. Simtechnische zaken merk je als gebruiker direct als je de simulatie speelt. Dat een materieelomloop niet helemaal conform de toen opgestelde dienstregeling is, merk je niet als je daar geen weet van hebt. Het doet niet direct afbreuk aan het speelplezier.

Spoorsecties Hengelo:

SimData Post T Hengelo 1.6.1.9925

[TjoeTjoe]

Maar een pathtemplate toevoegen is niet zo eenvoudig als het lijkt.

Volgens Richard is er geen SDK document voor Hengelo en dus tast ik in het duister voor wat betreft de benamingen van sommige spoorsecties.

Als er in een pathtemplate een spoorsectie ontbreekt zal het wel/niet/minder (?) goed werken.

Een SDK voor Hengelo is er inderdaad niet. Wil niet zeggen dat we daar met wat trial-and-error kunnen proberen, eventueel met hulp van het Signalsoft team, om een en ander wel gedocumenteerd te krijgen. En de beste plek daarvoor is natuurlijk de SignalWiki. Overigens, de uitdraai van de Sim-data is naar mijn inzicht niet compleet. Lees: de sim data export functie genereert geen totaal overzicht. En dat is waarschijnlijk waar Leo op doelt.

Kijk maar eens naar de platform definities van de haltes, zoals bijvoorbeeld Borne. Deze zijn gedefinieerde aan spoor (track) 'Hengelo-Almelo_7' resp. 'Almelo-Hengelo_6'. In de track definities aan het begin van de Sim data vindt je dergelijke benamingen niet terug. Vreemd. De lijst met tracks is dus niet compleet, en ja, dan wordt het lastig om een volledig en correct Path Template te definieren.

Bovendien kloppen alle ingevoerde EntrypointTime voor treinen die het nieuwe path gaan gebruiken, niet meer !

Met als gevolg dat treinen meestal 2 maal op het scherm worden gezet.

Hmmm. Deze relatie begrijp ik eerlijk gezegd niet helemaal. Misschien heb je wat meer uitleg voor me zodat het kwartje bij mij ook valt, wat dit genoemde verschijnsel betreft.

Ik zie het verband even niet

De grote vraag is: waar geven we voorrang aan ?

Ik sluit me aan bij Dre zijn woorden. De drgl zou functioneel zo correct mogelijk moeten zijn. een 100% correcte materieel-omloop zou bij mij persoonlijk iets minder hoog op de lijst staan.

Wat ik wel belangrijk vind is dat de sim-technische mankementjes o.a. de seintechneut in Wierden en aansluiting Aadorp er binnenkort wel eens uit mogen.

Tot slot, om toch nog even terug te komen op de PathTemplates: mijn verwachting is dat de noodzaak van het definieren hiervan NA de update van Hgl een mindere rol gaat spelen. In Asd hebben deze immers ook geen rol (of bijna niet) .Volgens mij werkt het Asd zo, dat de PathTemplates alleen voor de AI dispatcher van belang zijn. Op het paneel zelf rekent de sim de treinen door het netwerk heen op basis van de drgl v.d. trein

Erwin

[Dre]

Een SDK voor Hengelo is er inderdaad niet. Wil niet zeggen dat we daar met wat trial-and-error kunnen proberen, eventueel met hulp van het Signalsoft team, om een en ander wel gedocumenteerd te krijgen. En de beste plek daarvoor is natuurlijk de SignalWiki. Overigens, de uitdraai van de Sim-data is naar mijn inzicht niet compleet. Lees: de sim data export functie genereert geen totaal overzicht. En dat is waarschijnlijk waar Leo op doelt.

Kijk maar eens naar de platform definities van de haltes, zoals bijvoorbeeld Borne. Deze zijn gedefinieerde aan spoor (track) 'Hengelo-Almelo_7' resp. 'Almelo-Hengelo_6'. In de track definities aan het begin van de Sim data vindt je dergelijke benamingen niet terug. Vreemd. De lijst met tracks is dus niet compleet, en ja, dan wordt het lastig om een volledig en correct Path Template te definieren.

Die kun je complementeren met:

Spawnpoints:

SPAWN_AADORP_0

SPAWN_AKZO_0

SPAWN_AMLG_0

SPAWN_BENTHEIM_0 (spoor Bentheim-Oldenzaal)

SPAWN_BENTHEIM_1 (spoor Oldenzaal-Bentheim, Fdl HBTH belt niet om te vragen of T Hgl ermee akkoord gaat dat de trein op VS wordt aangenomen!)

SPAWN_DELDEN_0

SPAWN_DEVENTER_0 (spoor Rijssen-Wierden)

SPAWN_DEVENTER_1 (spoor Wierden-Rijssen)

SPAWN_DOLLEGOOR_0 (machinist belt met de vraag of hij mag oprijden naar sein 36)

SPAWN_GRONAU_0 (Fdl EGRN belt om mee te delen dat een trein onderweg is op spoor Enschede-Gronau)

SPAWN_HGL4C_0

SPAWN_MARIENBERG_0

SPAWN_NIJVERDAL_0

SPAWN_TC1_0

SPAWN_TC2_0

Vrije baan (begint altijd van links te tellen, dus _0 ligt altijd links van _1, ongeacht of het spoor Almelo-Hengelo of Hengelo-Almelo is) :

Deventer-Wierden_0 t/m _2

Wierden-Almelo_0

Almelo-Wierden_0

Marienberg-Vroomshoop_0 t/m _4 (_4 = Geerdijk)

Vroomshoop-Vriezenveen_0 t/m _2 (_0 = Daarlerveen)

Almelo-Hengelo_0 t/m Almelo-Hengelo_9 (_0 = Almelo de Riet, _6 = Borne)

Hengelo-Almelo_0 t/m Almelo-Hengelo_9 (_0 = Almelo de Riet, _7 = Borne)

Delden-Hengelo_0 en _1

Hengelo-Enschede_0 t/m _2 (_2 = Enschede Drienerlo)

Enschede-Hengelo_0 t/m _2 (_1 = Enschede Drienerlo)

Hengelo-Oldenzaal_0 t/m _5 (_0 = Hengelo Oost)

Oldenzaal-Hengelo_0 t/m _5 (_0 = Hengelo Oost)

[Hobbyman]

Dre, bedankt voor het overzicht, samen met de bestaande pathTemplates moet er wel uit te komen zijn.

De relatie met de EntrypointTime ligt als volgt:

Als voorbeeld nemen we trein 82700 EPT 5.22; Hgl v 5.30; Aml a 5.43

In Aml wordt de trein gesplitst in 31011 en 31013.

Als het pathtemplate juist werkt krijgen deze 2 laatste treinen een EPT van 5.42.

Het resultaat is dan:

Start de sim om 5.42 en 82700 wordt op het spoor Hgl-Aml geladen.

Start de sim om 5.43 en 82700 wordt niet meer geladen.

Door de negatieve overlap van 1 min worden dan wel de opvolgende treinen geladen.

Dus 31011 en 31013 staan dan op het scherm.

Omdat het path er initieel nooit is geweest en pathtemplate 13 ook niet correct werkt krijgen we echter de volgende situatie:

Start de sim om 5.29 en 82700 wordt op zijn vertrekspoor geladen.

Start de sim om 5.30 en 82700 wordt nu niet meer op het spoor gezet.

Dus hebben 31011 en 31013 nu een EPT van 5.29.

Start de sim om 5.30 en ziedaar:

82700 wordt niet meer geladen en de opvolgende treinen 31011/13 worden wel geladen.

Krijgt 82700 nu een correcte PathTemplate dan zal voor de daaruitvolgende treinen de EPT gewijzigd moeten worden.

Vooral de bugs die bij de laatste update zijn ontstaan worden steeds irritanter:

Op de kopsporen in Es worden de koppelopdrachten genegeerd in plaats van de keeropdrachten.(zie ook elders in het forum)

En mcn die na het ontkoppelen niet op de trein zitten, maar wel via telerail vragen om rangeeropdrachten uit te voeren die op dat moment niet uitgevoerd moeten/kunnen worden.

Het toevoegen van de doorrijdtijden van Esd en Hglo is vandaag al gereed.

Dat gaat lekker snel.

Morgen eens kijken of Amri en Bn ook zo makkelijk zijn toe te voegen.

Dat het belang van de pathTemplate afneemt lijkt mij vrij onwaarschijnlijk.

Het belang van de pathtemplate zal in Hengelo denk ik niet afnemen.

Dat komt vooral omdat de aard van het paneel Amsterdam iets anders is als het paneel Hengelo.

Amsterdam kent eigenlijk geen paden op het paneel. Alleen voor de treinen van/naar Dgr wordt de positie op het paneel berekend.

Voor alle andere treinen wordt geen positie op het paneel berekend en zijn er eigenlijk ook geen paden.

Alle paden voor de AI-dispatcher beginnen en eindigen aan de rand van het paneel.

Over welk perronspoor een trein gaat staat hier niet in het Pathtemplate.

Groetjes,

Leo

[Dre]

Dat komt vooral omdat de aard van het paneel Amsterdam iets anders is als het paneel Hengelo.

Amsterdam kent eigenlijk geen paden op het paneel. Alleen voor de treinen van/naar Dgr wordt de positie op het paneel berekend.

Voor alle andere treinen wordt geen positie op het paneel berekend en zijn er eigenlijk ook geen paden.

Anders gezegd, het Path_ID geeft voor de simulatie aan waar binnen het paneel een trein geladen moet worden voor het geval deze op dat moment tussen 2 stations onderweg is. Hoe preciezer het pad gedefinieerd is hoe beter de simulatie in staat is die plaats te bepalen. Als je dan ook nog eens de doorkomsttijden bij haltes langs de vrije baan invoert kan de simulatie bepalen hoe twee treinen t.o.v. elkaar binnen één het hetzelfde baanvak geplaatst dienen te worden.

Tot slot, om toch nog even terug te komen op de PathTemplates: mijn verwachting is dat de noodzaak van het definieren hiervan NA de update van Hgl een mindere rol gaat spelen. In Asd hebben deze immers ook geen rol (of bijna niet) .Volgens mij werkt het Asd zo, dat de PathTemplates alleen voor de AI dispatcher van belang zijn. Op het paneel zelf rekent de sim de treinen door het netwerk heen op basis van de drgl v.d. trein.

Maar de trein heeft nog steeds informatie nodig waar deze geladen moet worden. Aan de hand van de dienstregelingsgegevens kan de sim niet bepalen op welk spoor een trein geladen moet worden. Stel dat je trein 1787 bij Wierden dienstregelingsmatig laat roestrijden over wissel 21, dus tussen Wdn en Aml via linkerspoor. Dat kan de trein uit de dienstregeling (Wdn spoor 101, Aml spoor 202a/ niet afleiden. Daarom geef je 'm een PathTemplate mee zodat de simulatie weet dat je de trein van spoor 101 laat wisselen naar spoor Almelo-Wierden en vanaf daar via wissel 71/73 terug naar het 'normale' spoor.

Overigens m.b.t. de update: Is die binnen afzienbare tijd te verwachten? Ik las in het Engelse Q&A-forum dat er momenteel nog aan de update Hengelo gewerkt wordt (naast alle Duitse simulatoren). Ik zit namelijk een beetje te dubben of het zin heeft mijn dienstregelingsbestand nog tussentijds te updaten voor versie 1.6.1.9925/1.6.1.9930 of te wachten tot de versie mét o.a. DarkTerritory.

En dan nog een vraag geheel terzijde: Zit er nog een Nederlandse (GRS-NX, -AR of -CTC) simulatie in het vat? (aangezien de Duitse SpDrS60-sims elkaar vrij snel hebben opgevolgd) Ik heb hier en daar al wat gehoord over Post T Deventer, maar zijn daar al wat zaken concreet? Verder dan een tekening van het tableau op Sporenplan.nl kom ik voorlopig niet.

Geheel terzijde is het SimData-bestand nu geüpdate met spawnpoints en secties op de vrije baan, de link in mijn vorige bericht verwijst nu naar de nieuwe versie.

[signalsoftRC]

de update van Hengelo heeft in zodanige vorm invloed op de drgl:

- in Marienberg wordt het station een stukje van de simulatie (net als Halfweg of Koeln Nippes b.v.). Hierdoor krijgen de treinen VAN Marienberg geen spawnpoint meer (wordt gewist) en de treinen NAAR Marienberg krijgen een rangeeropdracht om te keren en om te nummeren. Da's een snelle verandering van oud naar nieuw.

- op spoor 4c in Hgl wordt het opstellen net als in Amsterdam Westelijk Eiland. (ook een snelle verandering)

- tractie blijft gelijk zoasl het nu is.

- de rest van de drgl heeft GEEN wijzigingen nodig! :-)

[Dre]

Daarvoor hebben we dan wel weer nieuwe spoorsecties in de simulator waar de rangeeropdracht uitgevoerd moet worden. In Mariënberg wordt het eenvoudig "in Mariënberg op ieder spoor" (al zal er een spawnpoint moeten blijven voor de treinen van/naar Emmen), maar 4d, 22 en 23 krijgen naar ik aanneem aparte sectienamen. Je kunt treinen er niet meer eenvoudigweg heensturen en verwachten dat ze van het randje van de wereld afvallen.

Rest blijft zoals het is. Aml 11-20, Hgl 8-19, Aadorp, Akzo en Dollegoor blijven dus niet zichtbaar? Vraag blijft dan wel, als Hgl4c zichtbaar wordt, is het dan ook mogelijk een trein daar heen te sturen en de rangeeropdracht te geven om na aankomst te Hengelo-Opstel op 4d/22/23 wisselgrendel 197 te nemen en via spoor 305b naar Akzo te rijden?

[signalsoftRC]

Aadorp zal ook veranderen, in die zin, dat het een "onzichtbare", want aansluiting, wordt. Maar dat heeft geen invloed op de drgl.

De rest zijn vrijgave rangeren. dat blijft zo als het nu is.

wisselgrendel 197 gaat dan ook werken. want dat wordt dan een linkje in de infra :-)

[TjoeTjoe]

Daarvoor hebben we dan wel weer nieuwe spoorsecties in de simulator waar de rangeeropdracht uitgevoerd moet worden. In Mariënberg wordt het eenvoudig "in Mariënberg op ieder spoor" (al zal er een spawnpoint moeten blijven voor de treinen van/naar Emmen), maar 4d, 22 en 23 krijgen naar ik aanneem aparte sectienamen. Je kunt treinen er niet meer eenvoudigweg heensturen en verwachten dat ze van het randje van de wereld afvallen.

Je mag er rustig vanuit gaan dat voor Mariënberg inderdaad separate spoorsecties gedefinieerd worden. Als vervanger van de huidige Spawn points.

Een spawn van/naar Emmen is inderdaad nodig voor de goederentreinen. Dan zou je ook nog kunnen denken aan de richting Zwolle, maar dat kan denk ik rustig vergeten worden.

We bevinden ons immers al buiten het beheersgebied van Hgl, dus dit is eigenlijk een technisch extraatje.

Mijn persoonlijke hoop voor wat betreft het Generieke paneel deel was en is dat de vrije baan tussen Aml-Hgl, Hgl-Es en Hgl-Odz gevisualiseerd zou worden.

Geen halszaak, maar wellicht voor beginners maar ook ervaren trdl's een handig hulpmiddel als ze even helemaal kwijt zijn wat zich waar bevindt.

Rest blijft zoals het is. Aml 11-20, Hgl 8-19, Aadorp, Akzo en Dollegoor blijven dus niet zichtbaar? Vraag blijft dan wel, als Hgl4c zichtbaar wordt, is het dan ook mogelijk een trein daar heen te sturen en de rangeeropdracht te geven om na aankomst te Hengelo-Opstel op 4d/22/23 wisselgrendel 197 te nemen en via spoor 305b naar Akzo te rijden?

Afgaande op wat Richard zegt, zal het antwoord op deze vraag Nee zijn. Kan me dit ergens ook wel voorstellen: is heel veel extra werk, zowel simulatie technisch als drgl technisch, voor maar een relatief klein aantal treinbewegingen.

Wisselgrendel 197 ligt in beveiligd gebied, en wisselgrendel zou dus moeten kunnen werken. Weet niet zeker of dit nu al zo is, denk het niet. Weet wel dat zulke functionaliteit een complexe materie is om sim-technisch goed voor elkaar te krijgen. In de Sp Dr S 60 sims Roisdorf en Kleinstadt zit iets vergelijkbaars (Schlüsselweiche vergelijkbaar met OTC sectie) ne daar is het nog niet functioneel.

Edit: cross-posting met Richard, zie zijn antwoord over dit onderwerp ;-)

Tot slot: dank voor de aanvullingen mbt spoor definities. Ik zal deze informatie zsm een plekje geven in de Developper hoek in de Wiki

Erwin

[Hobbyman]

Inmiddels zijn alle treinen voorzien van de passeertijden op de haltes.

Nieuwe Pathtemplates aangemaakt voor Hgl-Es en ook voor Hgl-Aml.

De laatste heeft me 2 dagen zoekwerk gekost om het goed te laten functioneren.

Moet je ook maar niet gaan kopieren he

In PathTemplate 8 zijn de perronsporen van Aml niet voorzien van het vinkje in IsPlatform !

En als dat het doel is dan werkt het niet naar behoren.

Maar nu werkt het voortreffelijk: afhankelijk van de drgl worden de treinen op het spoor Hgl-Aml keurig op de juiste positie geladen bij het starten van de sim.

In de tabel TimeTablePathTemplates bevat record ID 69 tweemaal Enschede.

Dat moet zijn Enschede en Enschede Drienerlo

Leo

[TjoeTjoe]

En dan nog een vraag geheel terzijde: Zit er nog een Nederlandse (GRS-NX, -AR of -CTC) simulatie in het vat? (aangezien de Duitse SpDrS60-sims elkaar vrij snel hebben opgevolgd) Ik heb hier en daar al wat gehoord over Post T Deventer, maar zijn daar al wat zaken concreet? Verder dan een tekening van het tableau op Sporenplan.nl kom ik voorlopig niet.

Het vat zit vol genoeg bij het SignalSoft team :-) Ik heb vorig jaar al eens een scherm afbeelding van het Deventer paneel mogen ontvangen, dus wat dat aangaat durf ik best te zeggen dat deze er best gaat komen. Maar dan moet ik wel meteen even aansluiten op je opmerking over de snelheid waarmee de Duitse SpDrS60-sims uitkomen.

Allereerst wil ik benadrukken dat de simulatie-engine van alle Post T simulaties verschikkelijk goed doordacht is. Daar heb ik de mannen van Signalsoft in het verleden al meerdere malen mijn complimenten voor gegeven (ik heb het voorrecht gehad om te zien hoe de code en de tools in elkaar zitten, werkelijk indrukwekkend). Door deze gezonde en doordachte basis is het mogelijk om redelijk "eenvoudig" en snel simulaties te ontwikkelen. En dat hebben we het afgelopen jaar zeker kunnen terugzien in de hoeveelheid, vooral Duitse sims, die verschenen zijn.

Een van de hoofdredenen waarom het met de Duitse sims allemaal wat sneller gaat en vooral kan is de wijze van paneelbouw. Wat wij als gebruiker niet kunnen zien, maar wat wel zo is, is dat alle interlocking-logica ingebakken zit in ieder tegeltje van een Sp Dr S 60 paneel. Een beetje oneerbiedig en te simpel gezegd, maar het is voor de ontwikkelaars bijna een kwestie van de "Domino" steentjes naast me elkaar leggen, en voila, weer een paneel klaar. Zit uiteraard nog wel het nodig handwerk aan, maar verklaart wel in grote lijnen waarom dergelijk panelen zo snel achter elkaar uitgebracht kunnen worden

En dat is nu net een van de wezenlijke verschillen met de Nederlands GRS-NX panelen. Deze panelen zijn letterlijk custom-made. NS wees een plek aan waar een gat in het paneel geboord moest worden voor een knop of een lampje etc. Was in de werkelijkheid een hoop handwerk, en datzelfde geldt ook voor het als simulatie na maken. Richard heeft me wel eens uitgelegd hoeveel extra werk hij moet doen ten opzichte van de Duitse sims, en dat is echt significant meer werk. (Zijstapje: Als ik hun er ergens in bij kon staan wat betreft dat veel data-handwerk, zou ik het zo doen. Lijkt mij persoonlijk fantastisch als we zoveel mogelijk Nederlandse seinhuis-historie gesimuleerd kunnen hebben)

Een Integra tableau nabouwen is voor hem tijd-technisch gezien veel makkelijker. Voor dergelijke panelen kan hij hetzelfde Domino-steen-principe toepassen als voor de SpDrS60. Eenmaal goed opzetten en elk Integra tableau is relatief eenvoudig na te bouwen

Dus ja, er staat heus nog wat op stapel. Hoop dat met bovenstaande beknopte beschrijving heb duidelijk kunnen maken dat de NL-panelen iets meer tijd vergen dan voor bijvoorbeelde de Duitse panelen

Erwin

[TjoeTjoe]

De laatste heeft me 2 dagen zoekwerk gekost om het goed te laten functioneren.

Moet je ook maar niet gaan kopieren he

Kopieren is in sommige gevallen strafbaar. En zie hier: een voorbeeld van zelf-strafrecht ... LOL

Maar nu werkt het voortreffelijk: afhankelijk van de drgl worden de treinen op het spoor Hgl-Aml keurig op de juiste positie geladen bij het starten van de sim.

Je inspanningen mbt de dienstregeling Hgl en Asd worden zoals altijd ten hoogste gewaardeerd. Bedankt Leo!

Erwin

[Dre]

@Erwin: Dank voor de uitleg omtrent het verschil tussen SpDrS60- en GRS-NX panelen. Altijd leuk om wat van 'achter de schermen' te horen. Dat de simulatie goed in elkaar steekt, daar waren we natuurlijk al achter doordat de sim vrij eenvoudig te bewerken is (dat een dienstregeling compatible is met MS Access is immers niet zo gewoon als het wellicht lijkt, evenals scenario's die eenvoudig d.m.v. xml-bestandjes geschreven kunnen worden. De vraag kwam enkel uit nieuwsgierigheid.

@Leo: Wederom dank voor de update van de bijgeleverde dienstregeling. Ik ga dit weekend weer aan de slag om het een en ander te verwerken zodat 'mijn' database ook weer helemaal 'bij' is. Overigens een kleine opmerking m.b.t. de update, in de PathTemplates zie ik dat je de spawnpoints ook hebt opgenomen voor een pad dat naar het spawnpunt toeleidt (bijvoorbeeld voor de 31000 naar Mariënberg eindigt het pad vanaf Vroomshoop na Marienberg-Vroomshoop_0 in SPAWN_MARIENBERG_0. Zover ik kan zien kan geen kwaad, maar eigenlijk is het overbodig, het spawnpunt moet je zien als de isolerende las die de vooraankondiging regelt. De andere kant op werkt 'ie niet. Post T Hengelo merkt bijvoorbeeld ook niets van de vooraankondiging in spoor Oldenzaal-Bentheim bij km 27.407 (dan krijgt de Fahrdienstleiter Bad Bentheim het signaal dat een trein uit Odz komt en sein (Sbk) 933 bediend moet worden zodat de trein Duitsland in kan).

[Hobbyman]

Dank voor alle lovende woorden.

Maar dit is net iets teveel eer voor mij.

De initiele vulling van de database is ongetwijfeld door Richard of door iemand anders van zijn team verzorgd.

Tot nog toe heb ik alleen (al wat langer geleden) het path tussen Almelo en Vriezenveen bewerkt.

En deze week de nieuwe toegevoegd.

Het opnemen van het Spawnpunt is dus geen uitvinding van mij.

Het heeft er altijd al zo gestaan.

Ik zal eens kijken of het verschil maakt bij het laden van een trein op het laatste deel van zijn route.

Leo

[TjoeTjoe]

Spoorsecties Hengelo:

SimData Post T Hengelo 1.6.1.9925

Work in Progress : SignalWiki - SDK:Hengelo

Moet nog het nodige gedaan worden aan opmaak en overzichtelijkheid van deze pagina. Maar het begin is er. Dank voor een ieder zijn bijdrage tot dusver.

Eventuele aanvullingen voor deze Wiki pagina, naast de Sim data zelf, is latijd welkom.

Denk dat een apart topic daarvoor handig is

Fijne feestdagen

Erwin

[Dre]

Je mag er rustig vanuit gaan dat voor Mariënberg inderdaad separate spoorsecties gedefinieerd worden. Als vervanger van de huidige Spawn points.

Een spawn van/naar Emmen is inderdaad nodig voor de goederentreinen. Dan zou je ook nog kunnen denken aan de richting Zwolle, maar dat kan denk ik rustig vergeten worden.

We bevinden ons immers al buiten het beheersgebied van Hgl, dus dit is eigenlijk een technisch extraatje.

Een spawn van/naar Zwolle is in Mariënberg niet nodig, aangezien je niet vanaf Ommen rechtstreeks naar Almelo kunt zonder kop te maken en in principe gaan er geen treinen van Zwolle naar Almelo via Mariënberg, goederentreinen gaan altijd via Deventer, omdat Herfte aansluiting - Mariënberg enkelspoor is en zich overdag niet leent voor veel extra treinen en voor vervoer 's nachts heeft men geen ontheffing (net zoals bijvoorbeeld Zwolle-Wierden en Zutphen-Hengelo)

Mijn persoonlijke hoop voor wat betreft het Generieke paneel deel was en is dat de vrije baan tussen Aml-Hgl, Hgl-Es en Hgl-Odz gevisualiseerd zou worden. Geen halszaak, maar wellicht voor beginners maar ook ervaren trdl's een handig hulpmiddel als ze even helemaal kwijt zijn wat zich waar bevindt.

Dat is inherent aan de simulatie anno 2000. Waar je naartoe wil is een simplistische versie van het Track & Trace-systeem, dat onderdeel is van Post 21-treindienstleiding. In het daadwerkelijk T&T is de positie van een bepaald materieelnummer gekoppeld aan een treinnummer weergegeven op een landkaart, waarmee dus ook zichtbaar is waar een trein zich precies op de vrije baan zichtbaar is. In principe maakt de trdl daar geen gebruik van. Eventueel heb ik wel een overzicht van P-seinen op de vrije baan tussen Aml-Hgl-Es en Ddn-Hgl-Odz-Bh. Mocht het Signalsoft-team een generiek paneel voor Hgl met dergelijke informatie willen implementeren, dan geef daarvoor maar een seintje (wat een heerlijke dubbelzinnigheid weer )

Een voorbeeldje daarvan voor Oldenzaal-Oldenzaal Grens (een stukje van de aankondiging van Post T Hengelo voor spoor Bentheim-Oldenzaal bevindt zich in Duitsland en is tegelijk de aankondiging voor overweg Bentheimerstraat (km 32.793) (feitelijk wordt de overweg Zandhuizerweg (km 32.985) aangereden vóórdat een trein uit Bentheim op het tableau verschijnt):

Eventueel kan er nog wat uitleg bij:

• Sein 933 is geen automatisch sein, maar wordt door de Fdl Bentheim bediend. Ten behoeve hiervan bevindt zich in spoor OS (Oldenzaal-Bentheim) t.h.v. km 27.407 een vooraankondiging.
  
• De seinen P929, P932, P934 en V936 stralen normaal groen licht uit. Wanneer de seinen 274/933 niet bediend zijn stralen de seinen P930 en P931 geel licht uit.
  
• Wanneer vanaf sein 274 een rijweg naar de sporen 502 t/m 505 is ingesteld en vanaf daar verder richting Hengelo dan toont sein 274 het seinbeeld 'groen knipper' en sein P930 derhalve 'geel 4'.
  

Overwegen:

27.2 = Koppelboerweg

28.3 = Rhodondendronlaan/Stadsweg

29.0 = Fleerderhoekpad

29.2 = De Visscherij

30.1 = Lossersestraat

31.8 = Lossersedijk

32.7 = Bentheimerstraat

32.9 = Zandhuizerweg

[Raymond]

Mijn persoonlijke hoop voor wat betreft het Generieke paneel deel was en is dat de vrije baan tussen Aml-Hgl, Hgl-Es en Hgl-Odz gevisualiseerd zou worden.

Geen halszaak, maar wellicht voor beginners maar ook ervaren trdl's een handig hulpmiddel als ze even helemaal kwijt zijn wat zich waar bevindt.

Is het dan niet makkelijker implementeerbaar om de (uitgebreide) treinlocatiegegevens uit te breiden in het treinenoverzicht? Bijvoorbeeld door de negen trajectdelen van Almelo - Hengelo ook als zodanig weer te geven, in combinatie met het aantal kilometers dat globaal nog afgelegd moet worden tot aan Hengelo/Almelo? Omdat er toch maar één trein per blok kan zijn en je in het treinoverzicht makkelijk op status kunt sorteren kan je dan snel genoeg zien welke trein zich waar ongeveer bevindt (als TNV niet al voldoende informatie biedt). Dan krijg je dus bijvoorbeeld: (Hengelo - Almelo) (3 km tot Aml). In feite dus een aanvulling op de informatie die je al te zien krijgt wanneer de trein in de blokken van de stations Bn, Amri, Hlgo en Esd is.

[Hobbyman]

als ik, zeg maar, 30 treinen overkopieer van tabel 1 naar tabel 2, worden ze gewoon onderaan toegevoegd en krijgen een nieuwe autoID.

Soms vallen dingen wat later pas op zijn plaats.

Vandaar alsnog dit antwoord.

Bij het importeren van records kan het autoID (bijv 10000 en hoger) wel meegaan naar de nieuwe tabel.

Zo heb ik ook MO nummer 1 weer ingevoegd in de tabel, toen deze ten onrechte verwijderd was.

Leo