Svenska 3D-Tåg - Forum - Visa ett inlägg - HB Signalsystem

blomsson · 2020-10-28, 17:28

Det var ju länge sedan jag skrev något om mitt Signalsystem så jag tänkte berätta lite om hur den närmaste framtiden är tänkt att se ut, med en gigantisk brasklapp för okända händelser och ytterligare idéer!

Hade jag vetat att Vägskyddssystemet skulle ta en sådan hiskeligt lång tid att göra så hade jag antagligen arbetat med de olika systemen parallellt. Fördelen med att enbart arbeta med vägskyddet var dels att det faktiskt blev färdigt och att jag hade, så att säga, en tom målarduk att arbeta med där jag kunde sätta min egen prägel på hela projektet. Under arbetet med vägskyddet så lärde jag mig mängder med saker och en hel del kommer att finna sin väg in i Signalsystemet.

Jag kommer inte att redovisa mängder med detaljer eller bilder om hur det kommer att bli eller vilka förändringar som kommer att införas utan mera på ett övergripande vis berätta hur tankarna går. När saker har scriptats och gjorts iordning kommer det att redovisas i signalsystemstråden.

Texten nedan är uppdelad i avsnitt för respektive kategori av objekt, i vissa fall kan informationen och kategorierna överlappa.

Det som jag har skrivit tidigare gäller ännu, det är mest på detaljnivå som förändringarna syns.

Vad har gjorts hittills?
Tanken var att ta en paus efter slutförandet av Vägskyddet men det fanns redan färdiga ideér om hur vissa problem i signalsystemet skulle lösas så jag kastade mig in i den processen direkt.
Huvudfokuset har legat på att göra koden "TRS19 vänlig", även fast det inte behövs om man håller sig till versionsnumret som objektet är skapat för, så är det lika bra att göra jobbet direkt ifall systemet skulle uppgraderas till nyare versioner av Trainz.
Fokuset ligger också på att göra funktioner stabilare och i samma anda som hos vägskyddssystemet, men framförallt att lösa/undvika problemen med "Timeout errors", vilket nu är åtgärdat både vid skapande av rörelsevägar och redovisande av desamma. Exempelvis så fick jag ut knappt 300 st tågvägar tidigare nu har jag manuellt stannat processen vid 10000 st! Antagligen så blir det en maxgräns för hur många rörelsevägar som är tillåtna.

Efter dessa lösningar tog jag en liten paus men är nu igång igen även fast det går lite långsamt!

Signaler
Som beskrivits tidigare så är signalerna indelade i olika asset-grupper beroende på hur eller var de används, det kan tänkas att de indelas i något fler än vad som har redovisas tidigare.

Följande signaltyper kommer garanterat att finnas:

2 - 5-skens huvudljussignal
Huvuddvärgsignal - även med stor röd lykta (eventuellt samma asset för bägge typerna)
Stopplykta (olika funktioner)
2 och 3-skens försignal
Dvärgsignal
Repetersignal

Kommer att finnas med i mån av tid:

Skred(för)signal (kräver ytterligare funktionalitet, grunden är redan skriven)
A-signal (Tågvägsberoende via TKL-hus)
Kontrollykta (Tågvägsberoende via TKL-hus)

Dessa signaler kräver ytterligare funktionalitet, kan finnas med utan specifik funktionalitet och i så fall i mån av tid:

Brosignal (kräver kontroll på rörlig bro)
Portsignal (kräver specifik portfunktion i enlighet med redovisning i linjebok)

Signalerna går inte att släppa separat eftersom de kräver TKL-funktionalitet.

Eventuellt blir det en liten överraskning med signalerna som märks när det märks...

Växlar
Tanken är fortfarande att växlarna ska vara fristående, som tavelpaketet är, men jag får se om det blir så att det släpps innan resten av signalsystemet. Växlarna är ett av de objekt som jag började scripta tidigt vilket betyder att det finns mycket som behöver fixas till för att det ska hålla samma standard som det övriga systemet.

Växelomläggningsanordningarna(!) kommer att vara av egen tillverkning.

Linjeblock
Linjeblockeringen är en fundamental del av ett modernt signalsystem och ska därför vara hundraprocent fungerande redan från början. Linjeblocket kommer att finnas i två varianter, dels den som är scriptad hittills med grundläggande funktionalitet men utan finnesser och en variant som är baserad på spårledningar med exakt likadan funktionalitet som verklighetens linjeblock.
Bägge kommer att fungera precis som i verkligheten, men den med spårledningar kommer antagligen vara snabbare och effektivare eftersom den inte genomför några sökningar för att kolla ifall spåret är fritt/belagt.

Baliser
Balisgruppen som finns idag kommer att införlivas med samtliga typer av grupper som finns, antagligen också några "hjälp-grupper" för att underlätta för byggarna. Koden till balisfunktionerna, som ligger i scriptbiblioteket, kommer att uppdateras eftersom jag inte är riktigt nöjd med en del användarfunktioner och att datan inte alltid uppdateras direkt vid byte mellan balisgrupperna.

ATC
ATC är egentligen det stora frågetecknet i version 1 av signalsystemet, ska det finnas (och i så fall hur mycket) eller ska det skapas till nästa version. Jag har ingen aning om hur lång tid det tar att programmera ATC-systemet men ambitionen är att alla funktioner och beteenden som finns i systemet även ska finnas i den slutgiltiga versionen.
Problemet med att "plocka ut russinen" ur ATC är att det kan skapa problem senare när ytterligare funktionalitet ska läggas till och redan skriven kod behöver ändras, och dessutom vilka russin som ska väljas. Det är då bättre att bygga ett riktigt system direkt från grunden och sedan lägga till specifika delar senare vid behov. Nackdelen med ett riktigt grundläggande system är att det antagligen tar en väsentligt längre tid att programmera än ett mindre potent system.

Många verkar tro att ATC bara handlar om att stanna ett tåg vid stoppsignal men det innehåller så många fler funktioner än så och det är hela konceptet jag vill återskapa i slutänden, med allt vad det innebär!

Jag är väldigt sugen på att programmera ATC:n

Strukturell information
Utan att gå in på så mycket detaljer kan jag ändå delge lite grundläggande funderingar kring hur ATC är tänkt att fungera för användaren.
Min idé är att ATC-panelen (med samtliga funktioner och indikeringar) syns som en HUD hos lokföraren, alltså ingen egen panel i lokhytten. Fördelen med en HUD är att panelen även syns om man kör utanför hytten.

Visst skulle det vara snyggt med korrekt fungerande ATC-paneler i hytterna, men då krävs det att varje hytt skrivs om för att fungera med mitt system. Tanken är att mitt ATC-system ska ha publika funktioner för de som vill skapa hytter med ATC-funktionalitet så att HUDens information och interaktivitet även ska fungera hos en panel som finns i hytten.
Det här är absolut inget som finns inplanerat i en basversion av ATC-systemet men är enligt mig en önskvärd utveckling av ATC-systemets användarvänlighet.

TKLHus och TKL-funktionalitet
TKL-huset har genomgått en del förändringar och fler kommer det att bli! Vägskyddsystemets utformning har påverkat hur TKL-huset arbetar, redovisar och ser ut. Detaljer redovisas senare i signalsystemstråden när flera förändringar har blivit införda.

Planen är att införliva System M/TAM-sträcka och kanske även System S/VUT-sträcka i den första versionen av signalsystemet, bägge dessa system hör mera till Tkl-funktionerna och med interaktion från föraren än till signalfunktionaliteten, men är ju ändå en stor del av ett modernt signalsystem.

Kommandon
Kommer antagligen att finnas i begränsad form, eventuellt egna varianter av redan befintliga kommandon för att AI ska fungera korrekt. Kommandon för hobbykörning som nämns i första inlägget kommer att finnas, dock är den inte till för att användas i sessioner.

Sessioner
Antagligen inte något stöd eftersom det är tidskrävande, men förhoppningen är att kunna göra någon enklare variant ändå!
Målet är att det ska gå att göra väldigt avancerade sessioner och det ligger mig väldigt varmt om hjärtat men är antagligen väldigt komplext och dokumentationen är ju som vanligt dålig!

Vägskydd
Förhoppningen är att kunna införa de funktioner som saknas enl. vägskyddsmanualen redan i första versionen av signalsystemet.

STL:s vägskydd kommer inte att få någon koppling till mitt signalsystem eller något ATC-beroende.

Övriga funderingar
Syftet med det här inlägget är att informera om hur tankarna går med en första version av Signalsystemet. Som nämns i det första inlägget har signalsystemet utvecklats (invecklats kanske en del tycker) sedan det första spadtaget till ett mera kompetent men också komplext system med många delar som hör ihop. Även fast systemet till viss del är modulbyggt, så är det ändå svårt att göra en första version med få komponenter.
Det som går att göra är att minska på antalet objekt inom en viss kategori (t.ex. antalet signaltyper) eller att ta bort en hel kategori (t.ex. ATC) för att på så vis minska tiden det tar att skapa både objekt och funktionalitet, dessutom ska allt ju också testas i oändlighet!

En sak som jag aldrig ger avkall på är att allt som ingår i ett system ska fungera hundraprocentigt även om inte alla funktioner finns med från början!

Återkoppling
Jag tror inte att återkoppling är så viktig om man både kunskap om hur det fungerar i verkligheten, då är användarupplevelsen viktigare tror jag, alla fall för mig! Man kan säga att jag har släppt tre koncept hittills (Balisgruppen, Tavelpaketet och Vägskyddssytemet inkl. många egna objekt) och än så länge är återkopplingen i stort obefintlig, skälen vet jag ej men jag tar det som positivt! No news is good news

Den stora frågan är egentligen: Hur viktigt är ATC i en första version av Signalsystemet?

Som vanligt är alla synpunkter intressanta, är det något som saknas, otydligt, som kan tas bort i en första version, några önskemål, ordet är fritt!!

mvh
Håkan

2020-10-28, 17:28	#9
blomsson Medlem Reg.datum: Jul 2011 Ort: Vingåker Inlägg: 343	Den närmaste framtiden för HB Signalsystem! Det var ju länge sedan jag skrev något om mitt Signalsystem så jag tänkte berätta lite om hur den närmaste framtiden är tänkt att se ut, med en gigantisk brasklapp för okända händelser och ytterligare idéer! Hade jag vetat att Vägskyddssystemet skulle ta en sådan hiskeligt lång tid att göra så hade jag antagligen arbetat med de olika systemen parallellt. Fördelen med att enbart arbeta med vägskyddet var dels att det faktiskt blev färdigt och att jag hade, så att säga, en tom målarduk att arbeta med där jag kunde sätta min egen prägel på hela projektet. Under arbetet med vägskyddet så lärde jag mig mängder med saker och en hel del kommer att finna sin väg in i Signalsystemet. Jag kommer inte att redovisa mängder med detaljer eller bilder om hur det kommer att bli eller vilka förändringar som kommer att införas utan mera på ett övergripande vis berätta hur tankarna går. När saker har scriptats och gjorts iordning kommer det att redovisas i signalsystemstråden. Texten nedan är uppdelad i avsnitt för respektive kategori av objekt, i vissa fall kan informationen och kategorierna överlappa. Det som jag har skrivit tidigare gäller ännu, det är mest på detaljnivå som förändringarna syns. Vad har gjorts hittills? Tanken var att ta en paus efter slutförandet av Vägskyddet men det fanns redan färdiga ideér om hur vissa problem i signalsystemet skulle lösas så jag kastade mig in i den processen direkt. Huvudfokuset har legat på att göra koden "TRS19 vänlig", även fast det inte behövs om man håller sig till versionsnumret som objektet är skapat för, så är det lika bra att göra jobbet direkt ifall systemet skulle uppgraderas till nyare versioner av Trainz. Fokuset ligger också på att göra funktioner stabilare och i samma anda som hos vägskyddssystemet, men framförallt att lösa/undvika problemen med "Timeout errors", vilket nu är åtgärdat både vid skapande av rörelsevägar och redovisande av desamma. Exempelvis så fick jag ut knappt 300 st tågvägar tidigare nu har jag manuellt stannat processen vid 10000 st! Antagligen så blir det en maxgräns för hur många rörelsevägar som är tillåtna. Efter dessa lösningar tog jag en liten paus men är nu igång igen även fast det går lite långsamt! Signaler Som beskrivits tidigare så är signalerna indelade i olika asset-grupper beroende på hur eller var de används, det kan tänkas att de indelas i något fler än vad som har redovisas tidigare. Följande signaltyper kommer garanterat att finnas: 2 - 5-skens huvudljussignal Huvuddvärgsignal - även med stor röd lykta (eventuellt samma asset för bägge typerna) Stopplykta (olika funktioner) 2 och 3-skens försignal Dvärgsignal Repetersignal Kommer att finnas med i mån av tid: Skred(för)signal (kräver ytterligare funktionalitet, grunden är redan skriven) A-signal (Tågvägsberoende via TKL-hus) Kontrollykta (Tågvägsberoende via TKL-hus) Dessa signaler kräver ytterligare funktionalitet, kan finnas med utan specifik funktionalitet och i så fall i mån av tid: Brosignal (kräver kontroll på rörlig bro) Portsignal (kräver specifik portfunktion i enlighet med redovisning i linjebok) Signalerna går inte att släppa separat eftersom de kräver TKL-funktionalitet. Eventuellt blir det en liten överraskning med signalerna som märks när det märks... Växlar Tanken är fortfarande att växlarna ska vara fristående, som tavelpaketet är, men jag får se om det blir så att det släpps innan resten av signalsystemet. Växlarna är ett av de objekt som jag började scripta tidigt vilket betyder att det finns mycket som behöver fixas till för att det ska hålla samma standard som det övriga systemet. Växelomläggningsanordningarna(!) kommer att vara av egen tillverkning. Linjeblock Linjeblockeringen är en fundamental del av ett modernt signalsystem och ska därför vara hundraprocent fungerande redan från början. Linjeblocket kommer att finnas i två varianter, dels den som är scriptad hittills med grundläggande funktionalitet men utan finnesser och en variant som är baserad på spårledningar med exakt likadan funktionalitet som verklighetens linjeblock. Bägge kommer att fungera precis som i verkligheten, men den med spårledningar kommer antagligen vara snabbare och effektivare eftersom den inte genomför några sökningar för att kolla ifall spåret är fritt/belagt. Baliser Balisgruppen som finns idag kommer att införlivas med samtliga typer av grupper som finns, antagligen också några "hjälp-grupper" för att underlätta för byggarna. Koden till balisfunktionerna, som ligger i scriptbiblioteket, kommer att uppdateras eftersom jag inte är riktigt nöjd med en del användarfunktioner och att datan inte alltid uppdateras direkt vid byte mellan balisgrupperna. ATC ATC är egentligen det stora frågetecknet i version 1 av signalsystemet, ska det finnas (och i så fall hur mycket) eller ska det skapas till nästa version. Jag har ingen aning om hur lång tid det tar att programmera ATC-systemet men ambitionen är att alla funktioner och beteenden som finns i systemet även ska finnas i den slutgiltiga versionen. Problemet med att "plocka ut russinen" ur ATC är att det kan skapa problem senare när ytterligare funktionalitet ska läggas till och redan skriven kod behöver ändras, och dessutom vilka russin som ska väljas. Det är då bättre att bygga ett riktigt system direkt från grunden och sedan lägga till specifika delar senare vid behov. Nackdelen med ett riktigt grundläggande system är att det antagligen tar en väsentligt längre tid att programmera än ett mindre potent system. Många verkar tro att ATC bara handlar om att stanna ett tåg vid stoppsignal men det innehåller så många fler funktioner än så och det är hela konceptet jag vill återskapa i slutänden, med allt vad det innebär! Jag är väldigt sugen på att programmera ATC:n Strukturell information Utan att gå in på så mycket detaljer kan jag ändå delge lite grundläggande funderingar kring hur ATC är tänkt att fungera för användaren. Min idé är att ATC-panelen (med samtliga funktioner och indikeringar) syns som en HUD hos lokföraren, alltså ingen egen panel i lokhytten. Fördelen med en HUD är att panelen även syns om man kör utanför hytten. Visst skulle det vara snyggt med korrekt fungerande ATC-paneler i hytterna, men då krävs det att varje hytt skrivs om för att fungera med mitt system. Tanken är att mitt ATC-system ska ha publika funktioner för de som vill skapa hytter med ATC-funktionalitet så att HUDens information och interaktivitet även ska fungera hos en panel som finns i hytten. Det här är absolut inget som finns inplanerat i en basversion av ATC-systemet men är enligt mig en önskvärd utveckling av ATC-systemets användarvänlighet. TKLHus och TKL-funktionalitet TKL-huset har genomgått en del förändringar och fler kommer det att bli! Vägskyddsystemets utformning har påverkat hur TKL-huset arbetar, redovisar och ser ut. Detaljer redovisas senare i signalsystemstråden när flera förändringar har blivit införda. Planen är att införliva System M/TAM-sträcka och kanske även System S/VUT-sträcka i den första versionen av signalsystemet, bägge dessa system hör mera till Tkl-funktionerna och med interaktion från föraren än till signalfunktionaliteten, men är ju ändå en stor del av ett modernt signalsystem. Kommandon Kommer antagligen att finnas i begränsad form, eventuellt egna varianter av redan befintliga kommandon för att AI ska fungera korrekt. Kommandon för hobbykörning som nämns i första inlägget kommer att finnas, dock är den inte till för att användas i sessioner. Sessioner Antagligen inte något stöd eftersom det är tidskrävande, men förhoppningen är att kunna göra någon enklare variant ändå! Målet är att det ska gå att göra väldigt avancerade sessioner och det ligger mig väldigt varmt om hjärtat men är antagligen väldigt komplext och dokumentationen är ju som vanligt dålig! Vägskydd Förhoppningen är att kunna införa de funktioner som saknas enl. vägskyddsmanualen redan i första versionen av signalsystemet. STL:s vägskydd kommer inte att få någon koppling till mitt signalsystem eller något ATC-beroende. Övriga funderingar Syftet med det här inlägget är att informera om hur tankarna går med en första version av Signalsystemet. Som nämns i det första inlägget har signalsystemet utvecklats (invecklats kanske en del tycker) sedan det första spadtaget till ett mera kompetent men också komplext system med många delar som hör ihop. Även fast systemet till viss del är modulbyggt, så är det ändå svårt att göra en första version med få komponenter. Det som går att göra är att minska på antalet objekt inom en viss kategori (t.ex. antalet signaltyper) eller att ta bort en hel kategori (t.ex. ATC) för att på så vis minska tiden det tar att skapa både objekt och funktionalitet, dessutom ska allt ju också testas i oändlighet! En sak som jag aldrig ger avkall på är att allt som ingår i ett system ska fungera hundraprocentigt även om inte alla funktioner finns med från början! Återkoppling Jag tror inte att återkoppling är så viktig om man både kunskap om hur det fungerar i verkligheten, då är användarupplevelsen viktigare tror jag, alla fall för mig! Man kan säga att jag har släppt tre koncept hittills (Balisgruppen, Tavelpaketet och Vägskyddssytemet inkl. många egna objekt) och än så länge är återkopplingen i stort obefintlig, skälen vet jag ej men jag tar det som positivt! No news is good news Den stora frågan är egentligen: *Hur viktigt är ATC i en första version av Signalsystemet?* Som vanligt är alla synpunkter intressanta, är det något som saknas, otydligt, som kan tas bort i en första version, några önskemål, ordet är fritt!! mvh Håkan __________________ Fd. signalreparatör på Banverket. Sjukpensionär bla pga Aspergers syndrom. Använder numera T:ANE på en iMac (Retina, 27", -15), 24GB, OSX Sierra 10.12.6 (25/9-17) Hemsida för nedladdning av mina objekt: https://blomsson4073.se/index.html