STL Äldre Ljussignaler (diskussions tråd).
 

För Trainz version 3.1 och uppåt.

Nya ljussignaler (betaversioner) som använder den äldre signaleringsprincipen finns nu inkluderade i STL Aktuellt (JVS Äldre Ljussignaler 3.11). Dessa signaler var den första generationens ljussignaler som började ersätta semaforerna. Skripten till dessa har ännu inte gått igenom någon riktig betatest, så det blir er uppgift att rapportera fel/synpunkter i denna tråd.

Tre av huvudsignalerna har samma egenskaper som semaforerna. Alla signaler ska ha beteckningar enligt avsnittet Äldre Signaleringsprincip i dokumentet Beteckningar på signaltekniska objekt i Trainz R110718.pdf. För närvarande så finns följande signaltyper:

STL Äldre Dvsi x. Motsvarar en växlingsdvärg av modernare typ.

STL Äldre Hsi 1 x. Motsvarar en envingad semafor.
STL Äldre Hsi 1/2 x. Motsvarar en tvåvingad semafor.
STL Äldre Hsi 1/2/3 x. Motsvarar en trevingad semafor.

STL Äldre Hsi 1/2 Sidospår x. En infartssignal med lite modernare funktion. Den kan också (samtidigt med signalbeskedet) visa ett gult sken om tågvägen inte är lagd till huvudspåret.

Alla signaltyperna finns i följande tre varianter (x):
L. Left (trackside vänster).
R. Right (trackside höger).
S. Scenery (kräver en osynlig master).

Som vanligt, ett stort tack till...

Modeller: LAn.
Fakta support: bear och korvtiger.
-

Hej! jag undrar om ljussignalerna från Saltsjöbanan kan vara internsant.
Jag skulle vilja veta hur saltsjöbanans signalsystem funkar.
Det jag vet är att signalsystemet fungerar som äldre signalsystem.

Här nedan är dom huvudljussignalerna som finns på Saltsjöbanan.
Det är dom tre signalerna längst till höger som är intressanta.

Jodå, dom kan vara intressanta. Kanske det kan bli något i framtiden, liksom TUB signalerna. Användningsområdet är ju begränsat så just nu prioriteras dom vanligaste svenska signalerna i tre epoker.

Innan jag ger mig i kast med de här signalerna är det några frågor som kliar i huvudet:

I manualen (del äldre) anges att infartssignalen skall ha fyra sken. Denna ersätts med de tre "ljussignalsemaforerna".som ställs rygg mot rygg mot utfartssignalen. Antar att man kopplar en osynig master till infartssignalen - men vad styrs den emot - för något måste den väl styras emot. Signalmarkers, osynlig klarare?

Försignaler är bra att ha. Kan man "låna" en tvåskens, JVS FSi

Hur var det f ö; fanns blocksignaler när den här tiden begav sig?

Ytterst handlar ovanstående vilket tänkande som gäller; semafor eller modernt signalsystem.

En bra testbangård finns - nämligen Mellerud (BJ, DJ, DVVJ) på 40-talet. I spårplanen finns både semaforer och ljussignaler inritade.'

Nisse

Hej, nu svarar jag utifrån hur det fungerade under betatestningen och hoppas att inte allt för mycket har ändrats sedan dess.

Vad gäller de äldre ljussignalerna så ersätter de rätt av motsvarande semaforer. Antalet gröna ljusöppningar motsvarar antalet vingar på semaforen. Jag har inte hunnit ladda ned en officiella releasen själv ännu men såg att det nu ockå finns trackside versioner av dessa signaler. Dessa har alltså den osynliga mastern inbyggd och är trackside object.

Ja det skall fungera bra att låna de moderna försignalerna.

Vi hade under test och utveckling av signalsystemet ganska mycket diskussioner som vad som var äldre och nyare signalprincip och vad de egentligen skulle innebära. Jag tror inte heller att vi egentligen kom fram till någon exakt definition. Men som det ser ut i mitt huvud är det så här. Sven, Tomas med flera får gärna kommentera om ni har en avvikande uppfattning.

Den äldre signaleringsprincipen är till för att avbilda vad som idag kallas för "System M" eller TAM banor. Dvs en tågklarerare (tkl) ansvarar för en station där möten och eller förbigångar kan förekomma och tillsammans med tkl på angränsande stationer för sträcka mellan dem, således föreligger inte heller inget behov av blocksignaler.

Den moderna signaleringsprincipen är mera komplex och avbildar det som kallas "System H" Dvs Linjeblokering, fullständig signalering, ofta fjärrstyrda stationer. Det är så här alla större och mera trafikerade järnvägslinjer fungerar idag.

Observera att skillnaden mellan signaleringsprinciperna inte handlar om vilken tidsperiod som avbildas utan av vilket säkerhetssystem. Tillexempel så bedrivs trafiken på inlandsbanan fortfarande efter det som vi kallar äldre signaleringsprincip.

Bra svar Bear. Tack!

När det gäller Cab-körning så ställer jag tågvägen manuellt eller från loket. Då fungerar signalmarker bra. Men eftersom det pågående banbygget är tänkt att inom nära framtid läggas ut i Forum bör jag kanske överväga AI-teknik – som jag inte kan ett dugg om. Gissar att man i så fall måste ställa infartssignalerna mot osynlig klarare, som placeras där man vill att AI-tåget skall stanna. Rätt, fel?

I övrigt tycker jag att ditt resonemang om principer låter logiskt.

Nisse

Nu är jag ute på väldigt hal mark, för jag har inte heller hållit på så mycket med de här sakerna. Dessutom vet jag att Sven har tittat på scripta en del funktionalitet som kommer att förändra mycket av hur man hanterar detta. Förhoppningsvis kan någon annan hjälpa till att upplysa oss framöver.

Normalt sett ber man väll AI att köra till ett visst trackmark helt enkelt som med drive to, navigate to trackmark. Jag vet att sven pratade om att det var bättre att använda separata rules för att hantera växlarna och sedan ett driverkomando som bara kör på signalbesked.

Den osynliga klarerarens huvuduppgift är att möjliggöra fungerande AI trafik på stationer som inte har utfartssignaler. Ofta saknades utfartssignaler på mindre stationer och när TKL gav avgång med sin signalspade var det bara att köra vidare, under förutsättning att man hade koll på att eventuella möten har inkommit. För att kunna modellera en sådan station trots att vi behöver en "utfartsignal" som stoppar AI trafiken så har vi "Den osynliga klareraren" som ersätter verkligheten Avgång ifrån tkl och släpper ut tåget på nästa stationssträcka.

Fullständigt rätt av föregående talare bear (båda inläggen).

Nils, för att det ska fungera med AI-trafik så behöver du generellt inte lägga till något alls, om du har signalerna rätt placerade. Det som kan behövas är, som bear säger, en osynlig klarerare av typen hsi som utfartssignal om du inte har någon synlig utfartssignal.

Jag har nu tagit uti på allvar med de äldre ljussignalerna - inte minst beroende på att den osynliga monitorn är fullständigt blockerad av Unassigned - ett ord som jag uppfattar som en grov svordom.

Det är en komplicerad spårplan jag gett mig i kast med; ingående spår från söder (Göteborg), från norr (Falun), från sydväst (Oslo) och nordväst (Bengtsfors). Banan är dessutom bearbetad av Korvtiger för att tidsmässigt få rätt innehåll.

Jag har valt att behålla mellansignalerna före utfartssignalerna, och att leda infartssignalerna mot SM (signalmarker).

Samtliga infartssignaler fungerar bra, så och mellansignalerna före utfartssignal. Problem på vägen beror på mig själv med ett undantag. En av infartsignalerna (huvudtågspår) visar grönt blinkande sken under det fasta gröna ljuset för en vinge upp. Tidigare erfarenhet säger mig att det är något fel spåret. Har dock inte hittat sådanr.

Lappri skulle Kalle Dussin sagt om det inte var för utfartssignalerna. Dessa fungerar inte. Tre av utfartsignalerna visar "Kör 40", den fjärde "Stopp".

Jag har testat allt möjligt. senast att sätta ut en mellansignal med beteckningen me D4 - d v s mot utfartssignalen. Min gissning är att utfartssignalerna uppfattar allt som ett hinder - även om spåret slutar i tomma intet.

Sammanfattning: Mycket bra signaler - bara att jag kunde komma ut på spåren.

Nisse

Jag tar inte ditt inlägg som en fråga, utan som ett allmänt inlägg i debatten. Men jag vill i alla fall kommentera ovanstående.

En motfråga först. Vad är en osynlig monitor? Sen ett svar på den grova svordomen UNASSIGNED. När det gäller mina skript så startar dom alltid med ett odefinierat värde (unassigned) på många parametrar. Det kan handla om en odefinierad signaltyp eller ett namn eller beteckning etc. Så det är ett fel som inte ska ignoreras för det ger garanterat följdfel (ingenting kommer att fungera fortsättningsvis för detta objekt).

Ditt andra påstående läser jag som tårta på tårta. Du har tydligen mellansignaler att tillgå men leder ändå infartssignalen mot en SM. Varför inte leda den mot mellansignalen. En SM ska endast användas om man inte har någon annan signal att referera till.

Till sist en viktig detalj. Ett spår som slutar i tomma intet är ALLTID ett hinder!

Belysning är också en mycket viktig aspekt, behovet av detaljerad och exakt beräkning och planering, ett mycket komplext arbetsflöde!

Fråga om blocksignaler
 

Ett intressant problem som skapat för Svenolov och Korvtiger.

Min nya bana DJ-DVVJ består av en salig blandning signaler. Senare kommer banan att delas upp i två separata banan; dels med äldre signalteknik, dels med modern. Dessutom tillkommer av försvarbart nostalgiska skäl den äldre ljustekniken - en slags hybrid av båda systemen.

Och problemet: I den moderna banan använder jag mig av blocksignaler. Utfartssignalen kan exempelvis betecknas "stn 41" och blocksignalerna L3, L5 o s v. Men i den äldre ljustekniken betecknas utfartssignalen med "stn C" alternativt "stn D" och blocksignaler används inte.

Här uppstår en kollision mellan två system: Hur skall blocksignalerna benämnas i den moderna banan när utfartssignalen tillhör en äldre generation.. Problemet handlar alltså om blocksignalerna som är kopplade till stationen med äldre ljusteknik, Åt andra hållet spelar det ingen roll.

Att byta beteckning på den äldre utfartssignalen går inte därför att den är kopplad till signaler inuti bangården. En möjlig väg skulle då kunna vara att ändra beteckningen på blocksignalerna från "stn L3" till "stn c3".

Alternativ att strunta i blocksignalerna godkänns inte.

Vad sägs?

Nisse

Jag tror att det inte går att blanda äldre ljussignaler med moderna ljussignaler(däribland blocksignaler) då Svenolovs script inte stödjer detta.

Att blanda äldre ljussignaler och semaforer skall dock inte vara något problem, men blocksignaler tror jag att du får klara dig utan, även om det fanns i verkligheten vid samma tid (men de fungerade nog lite annorlunda mot hur de gör nu kan jag tänka).

Jag gillar det inte - men ibland måste man skicka tjurskalligheten till papperskorgen. Det har uppenbarats för undertecknad, med stöd av Korvtiger, att semaforer inte gillar det moderna signalsystemet. Så är det.

Med tungt hjärta tvingas jag inse nödvändigheten av att skippa blocksignaler, som förmodligen inte skapar trivsam samvaro.

Varför Äldre ljussignaler? Anledningen är, att i DJ-delen av banan jag bygger, skildras svenskt signalsystems utveckling under 1900-talets första hälft. En spännande utveckling med Korvtiger som lärare av 1:a klass. Äldre ljussignaler hör hemma i exposén.

Nisse

Är det i detta forum man kan få lite hjälp med signaler för TS 2016?

Byggt Karlskrona C-Emmaboda och har nu kommit till signaler.
Sträckan är enkelspårig med tre "mötesplatser" med dubbelspår - Spjutsbygd, Holmsjö och Vissefjärda.
Försöker få ett AI-tåg att starta i Holmsjö och möta ett annat i Spjutsbygd som startat från Karlskrona ungefär samtidigt.

Får inte rätt på (block-)signalerna, norrgående tåg stannar och väntar in det södergående strax norr om Karlskrona, bl.a beroende på växlar.

Tips vore tacksamt!:confused:

Åke

Tror att du tyvärr är lite vilse. Denna forumdel handlar om spelserien Trainz, med Z på slutet. TS2015 tillhör serien Train Simulator (utan Z på slutet, väldigt lätt att blanda ihop dem...) Om du scrollar upp lite på huvudsidan av detta forum så hittar du nog en rubrik som heter DTG - Train Simulator 2015, och de fem underforumen till den rubriken är nog var du vill posta den här frågan för att få vettigare svar :)

Denna tråd...
 

börjar bli brännhet igen för det finns bara två saker som inte fungerar i TANE och det är:

STL Script Library som har ett skriptfel som smittar av sig på allt som är beroende av det.

Det andra är en liten skitsak med STL Koppels skript där slangarna stannar på fel frame.

Med dessa två saker fixade skulle TANE kanske bli den dröm vi alla drömt om.

Endast Svenolov kan nog fixa detta och vi andra inblandade ställer naturligtvis upp! Eller hur?

Jo, det skulle vara skönt att få igång signalscriptet i TANE också, det är en av få saker som saknas.

STL-koppel fungerar bra i TANE pre-SP1, men det är någon bugg i någon Sniff-metod som även andra koppelscript haft problem med, är detta fixat? (Kollast enklast genom att sätta ut ett par vagnar i QuickDrive och rotera och koppla loss och ihop dem upprepade gånger. Kopplen uppdateras inte alltid korrekt, det är en brist i programmerings-API:t, men det skall inte dyka upp några scriptfel som har något med Sniff att göra.)
Sedan när det gäller animationslängden, varför fungerar inte detta i SP1? Animationer om något borde ju fungera på samma sätt i alla Trainz-versioner, för kopplena fungerar ju perfekt i alla tidigare versioner?

Endast Svenolov ...
 

... kan fixa signalfelet. Det ligger uppenbart i SweSignalMarker.gse som endast Svenolov har källkoden till! Det verkar vara 2 småfel som, om de inte spriider sig, borde vara lätt för Svenolov att fixa. Se bilder.
Nu är det väl så att Svenolov inte gått in i närkamp med TANE ännu men vi hoppas alla att han gör det snart !!!!????

Beteckningar på signaler (äldre signaleringsprincip): udda eller jämnt?
 

Hej, jag bygger i TANE och håller på att experimentera med semaforerna
och de äldre ljussignalerna. Jag skulle behöva hjälp med att reda ut hur signalerna ska benämnas.

Läser dels i Historiskt järnvägsbyggande i Trainz del II (v 3.11), dels i Beteckningar på signaltekniska objekt i Trainz R110718.pdf.

I Historiskt järnvägsbyggande står på sidan 7:
"Vid dubbla bokstäver så är AA, AC, AE... udda och AB, AD, AE jämna"

Beteckningar på signaltekniska objekt säger i Trainz ruta 4 (sidan 9):
"Man kan också ha två bokstäver i beteckninen, AA, AB, AC... (udda) och BA, BB, BC... (jämna).
Kom ihåg att det alltid är första bokstaven i beteckningen som indikerar udda eller jämn riktning."

Det här får jag inte ihop. Är AB udda eller jämnt?
Vilket dokument ska jag följa?

Tacksam för hjälp.
/Magnus

Om du bygger en bana från söder mot norr och kallar första växeln för XXX vx1 (XXX = stationsbenämning) då bygger du i udda riktning. Den motstående infartsväxeln kommer då att heta XXX vx2. Kör du tåg norrifrån och söderut så kör du i jämn riktning.

Principen gäller för semaforer och försignaler, men nu används bokstäver. Döp södra semaforens master till XXX A och norra till XXX B. Semaforerna ska ha samma beteckning men inom parentas.

För att kunna styra semaforernas masters måste signalmarker läggs in på spåren inom stationsområdet. Dessa döps för semafor A till XXX a1 för spår 1, XXX a2 för spår 2 etc. Spåren räknas från stationshuset.

Vill du ha mer hjälp så skicka epostadress till mig.

Nisse

Jag skulle säga att "Beteckningar på signaltekniska objekt i Trainz" är att lita på, då det är Svenolov som skrivit den utifrån sitt script. Det har nog blivit någon miss där i kommunikationen mellan oss!

Tack för att du uppmärksammat detta, ska åtgärda det i min dokumentation. ;)

EDIT: Har kollat med scriptet och Svenolov dokument har rätt, det är alltid första bokstaven som indikerar udda/jämn riktning.

Tack för klargörande svar!

Och tack för ert hängivna arbete med allt ni laddar upp
på STL:s nya hemsida till glädje för oss fåtöljrallare. :tumme_upp:

/Magnus

Signalering av triangelspår
 

Är det möjligt att signalera ett triangelspår med de äldre ljussignalerna?
I så fall, hur ska signaler och växlar benämnas?

Se nedanstående bild av stationen Triangeln med signatur tri.

Bifogad fil 72466

Huvudlinjen löper i nord-sydlig riktning och signaleras med
infartssignalerna A respektive B och mellansignalerna C respektive D
enligt principerna för udda respektive jämn riktning.
Inga problem så långt.

Växlarna tri vx1 och tri vx2 finns på huvudlinjen och leder till var sitt ben i triangeln.
Benen löper samman i växeln som är märkt med en svart 4:a.
Hur ska den lämpligen benämnas?

Hur bör infartssignalen 1 benämnas?
Och mellansignalerna 2 och 3 som leder i samma riktning
men kommer från udda respektive jämn riktning?

Kommer detta överhuvudtaget att fungera?
Eller ska man överge tanken på triangelspår?

Jag vore tacksam om någon kunde hjälpa till att reda ut detta. Korvtiger?
/Magnus

Intressant problem!

Om vi börjar med verkligheten. Jag kan inte på rak arm säga någon station/trafikplats som historiskt sett haft ett triangelspår. Har du något exempel så kan jag se om jag kan hitta någon spårplan eller signalplan som kan ge ledning?

Men detta borde vara ett liknande problem som det man kan få vid vanliga grenstationer med flera linjer som kommer in. Då skulle en nordgående och en sydgående linje kunna komma in från samma håll på bangården, vilket skulle innebära en liknande konflikt. Enligt Banläran (Kungl. Järnvägsstyrelsen 1916) så verkar semaforer i verkligheten inte följa udda/jämt-principen, det är något som Svenolov infört, men växelnumreringsproblemet kvarstår. Banläran ger inte mycket ledning i dessa specialfall. Min egna gissning är att man var konsekvent inom en trafikplats så långt det gick. Detta skulle innebära att om du åkte i jämn riktning på en bibana och körde in på en station med en stambana och du körde in åt det udda hållet för stambanan, så skulle även den första växeln du mötte vara udda eftersom resten av växlarna på stationen skulle vara numrerade åt detta hållet. Hela stationen är således samma, men för bibanan blir det fel för just den stationen.
Detta löser ju dock inte triangelspårsfrågan, men där finns det ju inget rätt svar heller.

I Trainz däremot så tror jag att triangelspår kan ställa till vissa problem med scriptet. Men dessa problem ligger bara i hur scriptet analyserar genomfartstågvägar för tågklarerardelen. Det borde alltså inte vara några problem rent signalmässigt, signalerna refererar ju bara till de signaler som tågvägen går till, hur den än går.
Har för mig att Svenolov diskuterat triangelspår förut. Minns inte riktigt var, men jag ska gräva lite när jag får tid, så får vi se om jag hittar något!

Jag hittade Lundtorp på Öland som ett exempel.

http://www.ekeving.se/b/Oland/Lundtorp.html

Som synes en härlig blandning.

Det var egentligen detta jag undrade mest över.
Kan det uppstå några problem när scriptet genomlöper banan och den inte strikt följer udda-jämn principen?
Jag har haft problem med att scriptet kör vilse och leder till overflow i meddelandekön.
En hypotes var att detta kunde ha med triangelspår att göra.

Tack för snabb respons.
/Magnus

Intressant spårplan!
Enligt denna sida kan vi se att på ÖJ-tiden från början numrerade infartsväxlarna i triangelspåret för 1 respektive 2, så att tåg skulle möta rätt första växel. Hur man gjorde med resten av bangården talas inte om, men för något håll måste udda/jämt numreringen ha vänts, antagligen för tåg gående Färjestaden mot Mörbylånga, då detta spår nog användes minst. Intressant att SJ valde att benämna växlarna x respektive y för att delvis slippa problemet. Det tyder på att Kungliga Järnvägsstyrelsen inte heller kan ha haft några bestämmelser om hur man skulle lösa detta problem!

Angående Trainzdelen av problemet.
Det är möjligt att det är triangelspår som orsakar dessa message stack overflows, men det låter lite konstigt. Jag tror inte att udda/jämt har någonting med saken att göra, det låter snarare som att signalerna råkar ut för oändlig referensloopar. Lite märkligt att detta skulle hända på ett triangelspår, för signalerna borde bara behöva hålla reda på vilken signal som är framför i tågvägen och vilken som är senaste signal i tågvägen. Och det skulle ju inte gå att få några sådana oändliga loopar då på ett triangelspår.

Finns det andra annorlunda saker på banan du fått problemet på som skulle kunna orsaka det? Till exempel slingor, eller öglor? Två linjer som går åt var sitt håll och sedan möts på en station längre fram?

Det mest troliga borde vara att du har en slinga så att A beror på B som beror på C som beror på A som beror på B som beror på C som be.. du fattar.
Om du inte har några sådana slingor så är det säkert triangelspåret som är boven i dramat, det kan ju vara så att signalerna håller koll på fler andra signaler än bara den framförvarande och bakomvarande för stunden. De refererar då varandra på något sätt som leder till en oändlig loop, vilket overflowar meddelandestacken.

Om du råkar ut för felet igen så får du gärna ta en bild på felmeddelandet, särskilt den detaljerade så kan jag se om det går att få ut någonting av det. :)

Jag hade en vändslinga, men tog bort den efter ovanstående inlägg.
Problemet finns dock kvar.

Vid uppstarten av sessionen kommer följande fel:

Bifogad fil 72483

Detaljer för det första felet:

Bifogad fil 72484

Detaljer för det andra felet (början och slutet):

Bifogad fil 72485
(mitten av listan bortplockad)
Bifogad fil 72486

Sedan kommer tre liknande fel till som jag inte lägger upp.

Efter detta kommer inga fler fel utan det går bra att köra tåg.
Banan verkar fungera, fast det kan man ju inte veta säkert.
Det är lite oklart för mig vad felen innebär och vad de kan leda till.

Kan du få ut något av detta?

/Magnus

Jadu, det var inte några fel jag stött på tidigare.

Det verkar inte som att felen är kopplade till varandra i alla fall.

Det första felet är, om jag förstått vissa spekulationer på Trainz forum rätt, att Trainz tycker att scriptet tagit för lång tid på sig att köra. Låter väldigt skumt i mina öron då det är en helt egen tråd som körs och kan avbrytas när som helst.
Men förstår jag dig rätt om detta felet bara dyker upp en gång när du startar och aldrig igen efter det, även om du köra omkring, lägger om växlar osv?
Det är i alla fall kopplat till signaldelen av scriptet och uppkommer när scriptet försöker leta efter nästa blocksignal. Det har inte med några referensloopar att göra i alla fall, då skulle du fått en lång upprepning av samma fel i den detaljerade felrapporten. Jag misstänker dock att detta beror på att du har en spårloop någonstans på din bana, så att sökningen efter nästa signal fastnar i loopen och kör runt, runt, runt.
Verkar signalerna fortfarande fungera och uppdatera sig? För antingen borde du få detta fel om och om igen, eller så borde signalerna sluta att fungera helt om jag förstår scriptet rätt!

Det andra felet:
Verkar bero på scriptfunktionaliteten som kopplar dubbla växlar. Meddelandekön innehåller massor med meddelanden ifrån växlar som har lagts om (toggled) som scriptet inte hunnit med att kontrollera om de är kopplade med någon annan växel. Det konstiga är att alla dessa växlar av någon anledning måste ha lagts om precis vid sessionens startande för att generera alla dessa meddelanden. Dessutom förekommer samma växlar om och om igen i listan vilket är märkligt.
Du verkar ha många a och b-växlar, men det dyker inte upp några c och d-växlar i meddelandekön. För det måste väl vara i dubbla engelsmän som du använder sådana växelkopplingar och då borde du väl även ha massor av c och d-växlar?

Får jag fråga hur stor den här banan är? Hur många stationer, signaler och kopplade växlar handlar det om på ett ungefär?

Låter rimligt. Det första felet dök upp i TANE och är inget som jag har stött på i gamla TS2010.
Det kan ju röra sig om en ny kontroll i TANE:s underliggande system som visar sig på detta sätt.

Korrekt.

Det låter också rimligt.
Men det är ändå lite konstigt för banan saknar blocksignaler. Har det någon betydelse?

Strukturen är ganska enkel med en dubbelspårig huvudlinje och
några enkelspåriga sidolinjer som slutar i ändstationer.
Jag har experimenterat med vändslingor i slutet på dessa linjer men
de är numera bortplockade.
Det blir ingen skillnad i beteendet med och utan dessa slingor. Skumt.

Det första felet visar sig bara vid starten.
Därefter fungerar signalerna, i alla fall så långt det går att se när man kör på banan.

En hypotes:
Jag misstänker att detta kan ha att göra med att scriptet behöver
analyserar banan i uppstarten av sessionen.
Om skriptet behöver bygga upp en intern datastruktur som beskriver
banans layout så behöver scriptet söka igenom banan med TrackSearch
och notera var olika objekt som signaler och växlar finns.
Varje växel blir då ett vägval som leder till en ny del av banan.
Då behöver scriptet lägg om växlarna i tur och ordning och söka
igenom varje del för sig.

Flertalet av dessa a- och b-växlar är två enkla kopplade växlar till
exempel vid övergång från det ena spåret till det andra på en
dubbelspårig sträcka eller vid infarter till stationer.
Det är bekvämt att bara behöva lägga om den ena växeln trots att båda
läggas om samtidigt. Det finns några få engelsmän så det blir inte många
c- och d-växlar.

50 km huvudlinje och ett tiotal stationer varav några är lite större :).
Jag återkommer om antalet signaler och kopplade växlar. Måste räkna lite.

/Magnus

Räknat färdigt:
463 signalobjekt (masters, signal markers, klarerare)
474 växlar varav 16 ingår i 4 dubbla korsningsväxlar (a,b,c,d) och 134 ingår i kopplade växelpar (a,b).

/Magnus

En uppdatering från felsökningen:

Som ett experiment ersatte jag alla länkade växlar med vanlig växlar.
Inga a,b,c,d i slutet på växelnamnen alltså.

Resultatet blev oförändrat. Felen finns kvar vid starten av sessionen.
Det verkar inte som om länkningen av växlar påverkar detta.

/Magnus

Uppstår Message overflow-felet i TS2010?
Sökningen skulle som du säger mycket väl kunna vara någon begränsning de lagt till i TANE av någon anledning.

Det låter lite märkligt, vet faktiskt inte om det äldre systemet stödjer någon form av blocksignaler, men antagligen. Tror tillochmed att man hade semaforer som blocksignaler längs stambanorna utanför Stockholm, även om det fungerade på ett lite annorlunda sätt på den tiden.
Har kikat på koden och hittat en märklig sak. Svenolov har (som alla vettiga programmerare borde) lagt till en begränsning som gör att sökningen aldrig överstiger ett vist maxavstånd. Detta avstånd är valt till 10km. Detta gör det hela väldigt skumt, för alla spårloopar borde bara resultera i att sökningen terminerar, men av någon anledning pågår sökningen så länge att TANE får nog.
Det skumma är att anropet till sökningen verkar göras för varje signal en gång per sekund, vilket borde innebära att felet uppstår på nytt varje sekund, eller att felet skulle krascha hela signalbiblioteket, så att ingen signal fungerar. Inget av detta inträffar vilket är märkligt.

En ganska vettig hypotes, men för att söka av spåret behöver inte växlarna faktiskt läggas om, utan scriptet borde själv klara av att hitta vidare på de två spåren. Men jag är ganska säker på att scriptet i början analyserar tågvägar på varje station för att hitta genomfartstågvägar, så det skulle kunna har något med det att göra. Men det borde vara så att den nöjer sig med att använda den lagda tågvägen från signal A till B som genomfartsväg. Ska kika och se om jag kan hitta någon sådan del av koden.

Låter vettigt. Trodde att det var en enkelspårig bana med tanke på att du använde det gamla signalsystemet. :D


Det är ganska många signaler, men det verkar ju fungera fint när allt väl går igång! Det är också en väldigt hög andel kopplade växlar, men det hjälpte ju inte att ta bort kopplingen, så det är ju inte där felet ligger heller.

Bytte du nummer på dem, så att de matchade udda/jämn riktning eller tog du bara bort a/b? Skulle kunna vara att scriptet blir förvirrat om det försöker hitta tågvägar och växlarna kommer i fel ordning.

Ett annan teori:
Har du några speciella rules som lägger om växlar i början av sessionen som skulle kunna vara inblandade?

Felet uppstår i TS2010 också.

Lite bakgrund:

Banan började byggas i TS2010 med det moderna signalsystemet.
Problemet med message overflow i början av sessionen uppstod
även där. Tendensen var att felet blev värre ju fler signaler jag satte upp.
Först en enstaka rad i felrutan, sedan flera med växande antal signaler.

Vad värre var, problemet tycks nästan växa exponentiellt så att det vid
en viss punkt "exploderar" och fyller felrutan med liknande message overflow-
meddelanden. Då hänger hela systemet upp till 10 sek i början av sessionen
innan man kan titta på felmeddelandena. Sedan kan man köra tåg och då
tycks signalerna i de flesta fall fungera, även om jag ibland har sett
skumma beteenden hos några enskilda signaler.

Några bilder som visar felutskrifterna:

Översikt

Bifogad fil 72524

Början på detaljerna för första raden

Bifogad fil 72525

Slutet på detaljerna för första raden

Bifogad fil 72526

Och så fortsätter det...

Edit: Jag har också 76 MB JetLog.txt om det skulle vara av intresse.

Samma signal tycks ge upphov till en massa message overflows.
Det var ungefär i detta läge som jag gick över till TANE...

/Magnus

Jag bytte nummer för att följa udda-jämn-principen.

Nej, inget sådant heller.

/Magnus

Men om du för över denna banan i TANE, får du exakt samma fel då? Har denna bana flera signaler än den ifrån TANE som du visade växelfelmeddelandena ifrån?

Det här felet är ju inte samma som det andra, utan ett helt annat. För i det här fallet så overflowas alla signaler på banans message queues. Det verkar som att alla signaler i början av sessionen ungefär samtidigt skickar ett broadcast-meddelande (alltså ett meddelande som alla som lyssnar på signalen kan fånga upp) och talar om att deras signal state har ändrats. (Antagligen för att de alla initialiseras på samma gång och då sätter sitt signal state) Eftersom alla signaler också verkar lyssna på alla andra signaler på banan så kommer alla signalers message queues att innehålla samma meddelanden. En specifik signal (Hoc 52) råkar vara den som får samtliga signalers meddelandeköer att overflowas, därav att det namnet förekommer på alla rader i felmeddelandeöversikten som du visar i första bilden.

Orsaken till det här är att det är fler signaler på banan än vad Trainz klarar av att hantera. Särskilt gamla TS2010 som inte är flertrådad har en tråd där alla signaler initialiseras och får meddelandeköerna att overflowas för att varje signal inte har tid att ta hand om meddelandena. Potentiellt så skulle TANE kunna klara av detta för att den är bättre multitrådad och kan låta signalerna ta hand om meddelandena samtidigt som nya signaler initialiseras.

Det borde gå att få reda på hur många signaler som är maxgränsen. Om du tar valfri signals detaljerade lista och räknar hur många rader med meddelanden som redan är i kön (alltså antal rader som börjar med "router"), så kommer du att få det maximal antalet signaler som går att ha i TS2010. Min gissning är att det är 256.

Själva meddelandet "Signal, StateChanged" är ett standardmeddelande inbyggt i Trainz som det verkar, så jag tror inte att vi kan påverka det på något sätt.
En potentiell lösning skulle vara att leta reda på den loop som initialiserar alla signaler på banan och se till att den bara initialiserar ett 10- eller 100-tal signaler åt gången, och efter varje grupp med signaler tar en kort paus för att lämna över CPU:n till alla signaltrådar så de kan få tid att uppdatera sig och gå igenom meddelandeköerna. Men det förutsätter att detta görs i Svenolovs script och inte är Trainz egna, underliggande signalscript.

Naaae, men tack för erbjudandet! Har nog att göra så det räcker i alla fall! ;)

Trodde nog det men det skadar ju inte att fråga :)

Hur som helst, tack för informationen. Det finns en hel del att begrunda
och undersöka men jag hinner nog inte med det de närmaste dagarna.

/Magnus

Hej!

Kan informera om att samma problem uppstår i TANE! Vad jag kan se så är det ungefär samma typ av felmeddelanden. Dock så sker det inte alltid, inte med samma visnings problem med signalerna, vilket gör det lite lurt att åtgärda. Det sker bara vid uppstart av rutten, när signalerna skapas , så är inte på korvtigers resonemang oxå. Fast efter detta problem har hänt så funkar det att lägga in nya objekt och de skapas som vanligt och all den gamla informationen verkar finnas kvar på de tidigare signalerna.

Om du vill ha mer info om detta och TANE så kan jag forska lite mer och lägga upp några skärmdumpar?

mvh
Håkan

Att det bara uppstår ibland beror nog på att TANE är bättre multitrådat. Så medan en processorkärna initialiserar signaler och fyller på alla meddelandeköer kan de andra kärnorna ta hand om dem i de övriga signalerna.

Du får gärna forska mera om detta om du har tid. Jag vet inte om det är något som går att åtgärda, men ju mer information man har ju lättare är det att uttala sig om vad som är fel och vad som kanske kan göras åt det.

Har ett litet experiment som någon av er skulle kunna få göra:

Ta en av era banor som felet uppstår på och gör en kopia av den.
Använd batch replace för att ersätta alla mastrar, SMs och klarerarsignaler på banan med en signal utan massa extra funktionalitet, till exempel:
<kuid:-25:828> Signal BR 3
Använd batch replace till att ta bort alla scenerysignaler också och byt dem mot ett träd eller något som inte är scriptat.
Spara och stäng ned banan.
Kontrollera gärna i CM att banan inte har några STL-signaler eller mastrar som dependencies.
Kör sedan och se vad som händer.
Om samma fel inträffar så är det hela svårt att lösa då begränsningen ligger i Trainz. Om det inte inträffar innebär det antingen att vi kanske kan göra något åt det i scriptet, eller så beror det bara på att signalerna är mer lättviktiga och går snabbare att initialisera, så att Trainz orkar med fler av dem.
Testa gärna detta även i TS2010 om ni har ork/möjlighet.

Hej!
Har nu ägnat mig en timme eller två åt att testa signalerna, bl.a som korvtiger föreslog (hade en ide att göra ngt liknande).

Följande gjorde jag:
-Startade om TANE så att det inte låg ngt gammalt i minnet
-Öppnade rutten via "edit route". Ändrade ingenting i rutten.
-Stängde den via "exit surveyor" utan att spara eventuella ändringar

Detta förfarande gjordes minst tio gånger. Inte en endaste gång blev scenery signalerna korrekt initialiserade, men innehållet i property rutan finns intakt.

De två första bilderna påminner väldigt mycket (är "samma") som Magnus har visat tidigare och det är exakt samma på "invisibleMaster" också.
Bifogad fil 72549
Bifogad fil 72550

Denna bug kommer ibland, upptäckte efter ett tag att om jag klickade på bug symbolen, så att den försvann, så stannade spelet upp i fem/tio sekunder och sedan kom det första problemet även denna gång.
Bifogad fil 72546

Detta timeout meddelande kommer ibland, och då tror jag att signalerna visades korrekt efteråt.
Bifogad fil 72548

-Jag kopierade rutten. Bytte ut all "Osynliga objekten" till "Signal BR 3" dock INTE scenery signalerna. Sparade rutten, gick ur surveyor och gjorde samma manöver som på original rutten.

Vad hände? Gissa, inte en endaste gång kom "overflow message" eller "timeout felen" tillbaka.

-Nästa steg blev att byta tillbaka signalerna till STL och se vad som hände, alla fel kom tillbaka direkt och då är ju inte de ny-inlagda signalerna initierade än.

Verkar väl ganska klart att det är script relaterat eller mycket jobb att läsa in.

När jag labbade idag upptäckte jag ett annat innehåll i "Timeout" meddelandet, antingen är det nytt eller också har det förekommit tidigare och jag har missat det. Är ju dock en annan funktion än det tidigare "Timeout" meddelandet.
Bifogad fil 72547

Hade tänkt labba imorgon men kunde inte hålla mig och var tvungen att testa vad jag hade gjort, hade en ide.
-Gjorde en kopia på original rutten.
-Öppnade rutten via "edit route".
Tids-buggen kom direkt. Klickade bort den, och första chocken kom, signalerna fungerade, inga julgranar, även fast "owerflow" också kom upp.
Kliade på den begynnande flinten! Stängde och öppnade igen, funkade varje gång.
Öppnade original rutten, samma fel som tidigare.
Ibland blir man inte klok på nått...

Återgick till "::PathHasObstructions()" problematiken. Tog bort stationer (kind industry) som är scenery object och ersatte med spår. Då försvann "::Path..." och ersattes med den klassiska "::SearchBlockSignal()".

Kan också meddela att min rutt har (hittills) ca 330 signaler exclusive scenery signalerna och är ungefär 200km lång dock väldigt lite landskap ännu (bl.a beroende på en bug i Mac-versionen av TANE). Bara med den moderna signalerings-principen.

Ursäkta den långa utläggningen, men ville få med så mycket som möjligt direkt.

Jag har dock en fråga som dyker upp emellanåt, och jag undrar om det är någon som aktivt håller på och utvecklar det moderna signalsystemet eller om det ligger i träda?

mvh
Håkan

ps. Uj va tiden går när man har roligt... Får bli så här hoppas det inte är alltför otydligt!