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