Äldre Ljussignaler (diskussions tråd).

[MegaCastor]

Ursprungligen postat av korvtiger

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.

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

2010-alla.jpg

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

2010-1.jpg

Slutet på detaljerna för första raden

2010-2.jpg

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

[korvtiger]

Ursprungligen postat av MegaCastor

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.

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.

Ursprungligen postat av MegaCastor

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

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

[MegaCastor]

Ursprungligen postat av korvtiger

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

[blomsson]

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

[korvtiger]

Ursprungligen postat av blomsson

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.

[blomsson]

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å.
Q liten.jpg
Q liten 2.jpg

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.
Timeout bild 1 liten.jpg

Detta timeout meddelande kommer ibland, och då tror jag att signalerna visades korrekt efteråt.
Timeout bild 3 liten.jpg

-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.
Timeout bild 2 liten.jpg

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!

[Nils Blid]

Blomsson: Jag har lagt in moderna ljussignaler i tio stationer men har tröttnat på att tvingas skifta propertyrutans begynnelsebokstäver i ett. Skriver jag in ett "S" ändrar Tane om det till ett "s". Jag har lämnat det moderna signalsystemet och återgått till det äldre.

Nisse

[korvtiger]

Tack för testen!

Ursprungligen postat av blomsson

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å.

Så detta problem uppstår både i Surveyor och i Driver, rätt?
Att det uppkommer varje gång är rätt väntat.
Det verkar mycket riktigt vara samma fel som MegaCastor har.

Ursprungligen postat av blomsson

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.

Så om du inte trycker på bug-symbolen så kommer inte de andra felen upp alls? Verkar signalerna fungera?

Ursprungligen postat av blomsson

-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.

Bra test! Jag gjorde ett test själv där jag satte ut ca 520 stycken osynliga masters utan att namnge dem på en bana, men varken i driver eller surveyor kunde jag återskapa problemet.
Har kollat lite i källkoden också och om jag förstår saken rätt så krävs det att den osynliga mastern är kopplad korrekt med namnet till en scenery-slav för att felet ska uppstå. Detta borde ju vara fallet i ditt test, för om du använde batch replace så borde namnet på mastern att vara intakt när du byter signaltyp fram och tillbaka.

Ursprungligen postat av blomsson

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.

Det är egentligen samma fel som ovan. I Process-metoden där signalernas states utvärderas så anropas flera track search, bland annat denna för att leta efter hinder och den andra för att hitta en blocksignal. Det är själva Process-metoden som tar för lång tid, då den måste anropa flera sådana sökningar, det är bara att den avbryts på olika ställen, oftast i någon av sökmetoderna då dessa tar störst del av tiden.

Ursprungligen postat av blomsson

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.

Ju mer relevant information man får, ju lättare är det oftast att felsöka!

Förstår jag saken rätt om att signalerna inte fungerar alls på den originalrutten (ser ut som julgranar), men att de fungerar på kopian av rutten? Men overflow-meddelandena kommer upp på båda rutterna och ser likadana ut?
Har du även kopierat sessionen, eller har alla inställningarna på signalerna försvunnit på kopian?

Som nämnt tidigare så är det ren slump vilken av ::PathHasObstructions() och ::SearchBlockSignal() som programmet är i när man får Timeouten. Kör du tillräckligt många gånger så borde båda dyka upp.

Ursprungligen postat av blomsson

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?

Nej, det är inte någon som utvecklar det för tillfället. Svenolov som har skrivit alla dessa script och utvecklat hela signalsystemet har tagit en paus, men han har pratat om att komma tillbaka. Vi får se om han får inspirationen åter. Under tiden är det jag som fått ansvaret för att underhålla alla STLs script.