Modernisering av svenskt signalpaket

[ADDE]

alla mina filer får nya filnamn och hamnar under SummerADDE/SwedenV2.

Järnvägskorsningen som jag snickrar ihop kommer fungera väldigt annorlunda i editorvyn.

Nu har jag kommit så långt att alla 4 bommar och X-signaler, samt 2st V är på plats och fungerar... Det som återstår är då följande:
-Trimma parametrar så anläggningen simulerar som i på verkligheten.
-Fixa VF-signaler som ska fungera med korsningen. (De gamla järnvägskorsningsdelarna kommer INTE funka ihop med denna och vice versa.)

På tal om det så letar jag efter assets likt det jag har skapat ovan. Tips på järnvägsövergångar från 3:e part jag kan ladda ner? i Discord så sa de att sjaelland ska ha vägskydd med VF-motsvarande, men vart laddar jag ner det?

[mibl]

- felpost -

[ADDE]

Alla objekt på plats. scriptning återstår.

To-do list:
1. Programmera in VF-signalerna
2. Lösa problem med att de vita lamporna inte blinkar när bommarna är inaktiva. (kan även påverka VF-blink)
3. se om jag kan få till en fördröjning på vänster-bommarna.
4. Se om trigger kan bli hastighetsbaserad istället för att ha en fast avstånd.

Sen är det tags att ta fram varianter av denna.

[Hgv]

Det är ju viktigt att ringsträckan kan göras flexibel om man vill få en realistisk korsning. IRL sker det ju när tåget passerar en spårledning som sitter på väldigt olika avstånd beroende på hastighet, typ av vägskydd m.m.

Den bästa lösningen är nog om signaleringen kan sättas igång av en länk på spåret, ungefär så som sker idag med VF-signalerna. Då kan den placeras på lämpligt avstånd vilket förstås varierar från korsning till korsning. Däremot kanske länken inte behöver vara direkt kopplad till VF-signal då ju många korsningar saknar VF och länken måste vara placerad någon kilometer eller mer från signalen. Kanske länken kan kopplas till ett signalskåp som placeras ut vid länken (lättare att hitta än en begravd VF-signal)?

Nu till nåt helt annat:
Att använda Approach Control-funktionen för att få en signal att bete sig på olika sätt var en väldigt smart idé. Från början fattade jag nog inte riktigt att det "bara" är ett sätt att kunna välja olika egenskaper för signalen utan jag trodde det hade något specifikt med just "approach control" att göra. Tack för tipset!

Jag provkörde ett scenario på Malmbanan och låg bakom ett långsamt malmtåg då jag höll på att köra mot rött när mellansignalen visar "kör" med utfartsblocket i "stopp". Dvs "kör vänta kör" i infartssignalen, nästa signal som är en H2 visar "kör" och nästa H2 efter bara ca 300 m visar "stopp". Så kan man ju inte ha det tänkte jag, så jag såg till att göra nåt åt saken!

Min första tanke var att skapa en ny variant av H2 och H3 med ändrat script som ställer signalen till stopp när nästa signal visar stopp. Men det skulle bli många signaler att byta ut! Då kom jag på att Approach Control-funktionen kanske kunde lösa problemet. Resultatet blev en smärre ändring i scripten för H2 och H3, vilket innebär att man inte behöver byta ut några signaler och befintliga signalers funktion påverkas bara om man går in och bockar för "Approach Control" i signalens egenskaper.

Jag lade till de här raderna i scripten:

	elseif Call ( "GetLinkApproachControl", gConnectedLink ) ~= 0 and gExpectState == STATE_STOP then
		newSignalState = STATE_STOP

Alltså, OM "Approach Control" är valt så kommer signalen gå till stopp när nästa signal är i stopp.

Jag har nu "utrustat" alla mellansignaler som står före utfartsblocksignaler på Malmbanan på detta sätt och provkört, och det fungerar fint. Nästa steg blir att utrusta Jönköpingsbanan på samma sätt.

Tänker också att "Approach Control", "Limited Aspect" och "GetLinkFeatherChar" kan vara användbara om man vill göra signalers funktion mer flexibla som du redan varit inne på Adde! Det gäller bara att komma fram till i vilken utsträckning man behöver göra nya signaler och i vilken utsträckning man kan uppdatera scripten så att redan utplacerade signaler kan ges ny funktionalitet vid behov, utan att påverka de signaler som man inte vill ska ändras.

[ADDE]

Ursprungligen postat av Hgv

Det är ju viktigt att ringsträckan kan göras flexibel om man vill få en realistisk korsning. IRL sker det ju när tåget passerar en spårledning som sitter på väldigt olika avstånd beroende på hastighet, typ av vägskydd m.m.

Den bästa lösningen är nog om signaleringen kan sättas igång av en länk på spåret, ungefär så som sker idag med VF-signalerna. Då kan den placeras på lämpligt avstånd vilket förstås varierar från korsning till korsning. Däremot kanske länken inte behöver vara direkt kopplad till VF-signal då ju många korsningar saknar VF och länken måste vara placerad någon kilometer eller mer från signalen. Kanske länken kan kopplas till ett signalskåp som placeras ut vid länken (lättare att hitta än en begravd VF-signal)?

Jadu, jag står inför ett vägval efter om jag ska gå efter realism eller om jag ska göra som alla andra och skapa något enklare. Fördelen med det senare är att jag behöver inte skapa så många varianter då.

Ursprungligen postat av Hgv

Nu till nåt helt annat:
Att använda Approach Control-funktionen för att få en signal att bete sig på olika sätt var en väldigt smart idé. Från början fattade jag nog inte riktigt att det "bara" är ett sätt att kunna välja olika egenskaper för signalen utan jag trodde det hade något specifikt med just "approach control" att göra. Tack för tipset!

Jag provkörde ett scenario på Malmbanan och låg bakom ett långsamt malmtåg då jag höll på att köra mot rött när mellansignalen visar "kör" med utfartsblocket i "stopp". Dvs "kör vänta kör" i infartssignalen, nästa signal som är en H2 visar "kör" och nästa H2 efter bara ca 300 m visar "stopp". Så kan man ju inte ha det tänkte jag, så jag såg till att göra nåt åt saken!

Min första tanke var att skapa en ny variant av H2 och H3 med ändrat script som ställer signalen till stopp när nästa signal visar stopp. Men det skulle bli många signaler att byta ut! Då kom jag på att Approach Control-funktionen kanske kunde lösa problemet. Resultatet blev en smärre ändring i scripten för H2 och H3, vilket innebär att man inte behöver byta ut några signaler och befintliga signalers funktion påverkas bara om man går in och bockar för "Approach Control" i signalens egenskaper.

Jag lade till de här raderna i scripten:

	elseif Call ( "GetLinkApproachControl", gConnectedLink ) ~= 0 and gExpectState == STATE_STOP then
		newSignalState = STATE_STOP

Alltså, OM "Approach Control" är valt så kommer signalen gå till stopp när nästa signal är i stopp.

Jag har nu "utrustat" alla mellansignaler som står före utfartsblocksignaler på Malmbanan på detta sätt och provkört, och det fungerar fint. Nästa steg blir att utrusta Jönköpingsbanan på samma sätt.

Tänker också att "Approach Control", "Limited Aspect" och "GetLinkFeatherChar" kan vara användbara om man vill göra signalers funktion mer flexibla som du redan varit inne på Adde! Det gäller bara att komma fram till i vilken utsträckning man behöver göra nya signaler och i vilken utsträckning man kan uppdatera scripten så att redan utplacerade signaler kan ges ny funktionalitet vid behov, utan att påverka de signaler som man inte vill ska ändras.

Jomen precis! Intressant lösning där. Jag har ju fasstnat på "GetLinkFeatherChar" och får inte det att fungera som tänkt, men ska ta nya tag och testa mig fram när plankorningen är klar.

[Totte]

Går det med 4-spårskorsning i Säffle? Det är omöjligt att fixa där. Har försökt i fyra dagar.
Titta efter via google maps
Bara en V-signal.

[ADDE]

Vet du hur man sätter upp plankorsningarna på Bergensbanen?

Det är så det kommer bli med dessa!

dvs. oändligt antal spår, stoppar biltrafiken, stör ingen annan signalverksamhet och du kan flytta och gömma undan individuella objekt.