Äldre Ljussignaler (diskussions tråd).

[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

[blomsson]

Hej Nisse.
Jag såg att korvtiger hade svarat på ditt problem med stor/liten bokstav i TANE tråden. Jag kan bara säga samma sak, jag har aldrig upplevt det problemet!
Jag testade att skriva in bägge varianterna och båda behöll sina bokstavs-stilar.
Det verkar nästan som om du "glömmer" att spara emellan ändringarna, fast det tror jag inte du gör, men beteendet på signalen verkar så.
Har du testat att spara banan med ett nytt namn och sedan se vad som händer?

mvh
Håkan

[Nils Blid]

Ursprungligen postat av blomsson

Hej Nisse.
Jag såg att korvtiger hade svarat på ditt problem med stor/liten bokstav i TANE tråden. Jag kan bara säga samma sak, jag har aldrig upplevt det problemet!
Jag testade att skriva in bägge varianterna och båda behöll sina bokstavs-stilar.
Det verkar nästan som om du "glömmer" att spara emellan ändringarna, fast det tror jag inte du gör, men beteendet på signalen verkar så.
Har du testat att spara banan med ett nytt namn och sedan se vad som händer?

mvh
Håkan

Det händer inget, men jag skall försöka förklara vad som händer. Jag har valt en utfartssignal som heter "ny 41", Den är kopplad till en master som heter "Ny 41". När jag klickar på mastern får jag upp en en vit text ovanför mastern som heter "ny 41"-Och så här håller det på fram och tillbaka i såväl mastern som ljussignalen.

När jag ursprungligen lade in samtliga signaler i banan skrev jag in beteckningarna med små bokstäver. Av en händelse upptäckte jag senare att mastern begynnelsebokstav ändrats till stor bokstav. Ytterligare senare upptäckte jag att ljussignals benämning drabbats av samma sjukdom.

I masterns propertyruta skall man ställa signalerna. Funktionen är helsvart. Min gissning är att ingen av signalerna korrekt kopplade. Självklart sparar jag alltid även den minsta ändring.

Nisse

[ekv]

Jag kör fortfarande 2010 och i det spelet verkar det som signalnamnet är känsligt för stor eller liten bokstav. Är det inte exakt lika på signalen och mastern kommer de aldrig att kopplas ihop. Själv har jag som regel att alltid börja med stor bokstav för både master och signal.

[blomsson]

Nu tycker jag visserligen att denna diskussion hör hemma där du startade den, men eftersom du frågar här så svarar jag här, och så får ngn som kan eventuellt flytta på dessa inlägg om de stör!

Så som du beskriver det så funderade jag på om du har missat en detalj i uppraderingen av signalsystemet till TANE.

I propertyrutan så finns det en rad med Tpl-signatur. I den föregående versionen så ändrades den automatiskt när man döpte om mastern, nu gör den inte det.

Om namnet på mastern inte stämmer överens med scenery-signalen så blir tpl-signaturens text vit, klicka på den och skriv in en ny text. Om du skriver samma som mastern har blir texten blå.

Den enda vita texten jag får upp i övrigt, är när jag för muspekaren över master, då visas det inskrivna namnet på master signalen, INTE tpl-signaturen.

Exempel:
-Ny master, får ett löpnummer, t.ex 666
-Öppnar property-rutan skriver in Vr 21, trycker på "ok"
-Muspekar-överkörning visar Vr21
-Lägger in en ny Scenery-signal, varför inte en 5-skenare, mycket roligare...
-Scenery är julgran
-Öppnar property-rutan skriver in (Vr 21), trycker på "ok"
-Tpl-skylten på signalen visar 666
-Öppnar property-rutan på mastern, klickar på den vita texten och skriver in Vr 21, trycker på "ok" och texten blir blå och tpl-skylten ändrar till Vr 21.
-Om jag skulle ändra texten på mastern till vr 21, då blir scenery-signalen svart, och måste då ändras till (vr 21), men tpl-signaturen är fortfarande Vr 21, och måste då ändras till vr 21 i masterns property-ruta om man så vill.

Jag använder mig bara av Aaa konventionen, eftersom det står så på skyltarna och är oxå snyggare...

Om detta inte löser problemet, vad händer om du skapar en ny signal enl ovanstående, var som helst på banan, och sedan ändrar text från på samma vis som förut, blir det samma problem?

Detta är det enda jag kan komma på enl. din beskrivning.

mvh
Håkan

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

[blomsson]

Hej!
Efter ytterligare ett par timmars testande så kommer här ett utlåtande...
Eftersom korvtiger hade lite frågor så började jag med att testa lite igen.

Ursprungligen postat av korvtiger

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.

Julgranarna uppstår endast i surveyor, medans "message owerflow" uppstår även i driver.

Ursprungligen postat av korvtiger

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.

Precis, jag använde "batch replace" och då följde det inskrivna namnet med, dubbel-kollade att det var så för säkerhets skull.

Ursprungligen postat av korvtiger

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?

Stämmer bra.

Ursprungligen postat av korvtiger

Har du även kopierat sessionen, eller har alla inställningarna på signalerna försvunnit på kopian?

Har inte rört sessionen. Signalerna har inte förändrats alla inskrivna data är kvar, och det gäller alltid när jag har provat.
Så ett tips är för dem som håller på med signalsystemet är att inte ta bort mastrar som har data i propertyrutorna inskrivna och har fungerat förut!

Ursprungligen postat av korvtiger

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

Om jag inte trycker på bug-symbolen så vet jag inte vilket problem som flaggas för. Jag har testat mera idag och det ställde till lite huvudvärk!

Eftersom en del av dagens testning påverkar föregående fråga så lägger jag dagens problemforskning här.

Jag började med att testa på samma vis som igår med delvis annat resultat!
Inte lika mycket julgranar men en massa "timeout" och "message overflow".
Testade även kopian som funkade felfritt igår, men inte idag!
När jag tyckte att problemen va liknande som igår så installerade jag in din bug-fix och committade.

Startade originalrutten och hoppades! Tyvärr så kom "message overflow" problemet igen.
Prövade med att klicka bort buggen direkt när den kom och då blev det signalbilder. Testade lite olika varianter på samma tema och började fundera på hur det var innan jag installerade bug-fixen.
Vad göra? Jo installera tebaks den gamla versionen. Och sedan installera tebaks bug-fixen igen för nya tester...
Så här blev det..
Observera att det generellt fungerade lite bättre i dag, alltså inte så mycket julgranar.

Jag gjorde tre typer av tester och alla tester utfördes flera gånger.
Först innan bug-fixen:
Test 1
-Startade rutten
-Julgran (som det ju ska vara i början)
-Bug-symbolen kom
-Spelet fryser till 5s-10s (vertex blir stilla)
-Signalbilder uppstår
-Kollar buggen, visar "Message Overflow", stänger rutan

Test 2
-Startade rutten
-Julgran (som det ju ska vara i början)
-Bug-symbolen kom, öppnar, visar "Timeout", stänger rutan
-Dröjer ca 45s kanske 1min
-Signalbilder uppstår
-Ny bug-symbol kom, kollade buggen, visar "Message Overflow", stänger rutan

Test 3
-Startade rutten
-Julgran (som det ju ska vara i början)
-Bug-symbolen kom, öppnar, visar "Timeout"
-Väntar ca 30s innan rutan stängs
-Signalbilder uppstår
-Ingen ny bug-symbol

Testade nu med bug-fixen installerad:
Test 1
-Startade rutten
-Julgran (som det ju ska vara i början)
-Bug-symbolen kom
-Spelet fryser till 5s-10s (vertex blir stilla)
-Inga signalbilder
-Kollar buggen, visar "Message Overflow", stänger rutan
-Väntar
-Inga signalbilder

Test 2
-Startade rutten
-Julgran (som det ju ska vara i början)
-Bug-symbolen kom, öppnar, visar "Timeout", stänger rutan
-Dröjer ca 40s
-Signalbilder uppstår
-Ingen ny bug-symbol

Test 3
-Startade rutten
-Julgran (som det ju ska vara i början)
-Bug-symbolen kom
-Spelet fryser till 5s-10s (vertex blir stilla)
-Ny bug-symbol kom (syns på att den blinkar till)
-(Spelar ingen roll om man klickar bort buggen)
-Väntar
-Inga signalbilder

Vad betyder allt det här?
Julgrans-fenomenet i detta fallet tror jag uppstår när trainz inte riktigt hänger med, kanske beroende på skräp i minnet, andra processer som pågår, både i trainz och i datorn. Kanske inte i test 1 med bug-fixen, men jag bara spånar.

Dessa problem sker ju bara en gång per öppning av rutten och även fast det är irriterande så går det ju att bygga och lägga in nya signaler och andra objekt. Verkar inte som om det påverkar i Driver (än?).

Jag fick ju visserligen nästan inga julgranar inatt men tror ändå att förslagen nedan är en kortsiktig väg att gå innan det finns en lösning på ett klurigt problem.
I övrigt så verkar det som att om Test 2 i bägge varianterna av script är rätt väg att gå så länge.

Ursprungligen postat av korvtiger

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.

Som du säkert förstår så ligger signalsystemet, med tillhörande komponenter (ATC, tavlor, säo mm) mig ganska varmt om hjärtat. Och även fast jag tycker om att se alla fantastiska lok, vagnar, rutter mm, så är jag nog mera Bruno Kock än Uno Milton (för de som känner till de figurerna). För mig är en viktig del av en trevlig bana ett väl fungerande signalsystem. Jag skulle gärna kunna tänka mig att stoppa in fingrarna i syltburken... även fast jag inte vet om jag är kompetent för att ro iland ett sådant projekt. Jag har inga som helst ambitioner att stjäla någons kod eller att ta cred för någon annan. Det finns flera sätt att lägga upp ett samarbete på och om det låter intressant så får du gärna pm:a mig.

mvh
Håkan

[blomsson]

Funderade på om det är "Timeout" buggen som är det primära problemet, och att "Message Overflow" kommer beroende på den.
När jag ignorerar "Timeout " buggen och jag kollar på "Message Overflow" så kan jag inte se att "Timeout" buggen finns kvar. Jag tror att den gör det, men alla de nya bug-rapporterna gör att "Timeout" försvinner från listan.

Jag har en liten test-bana, två stationer, två blocksträckor och ett vägskydd. Blir runt 20 masters plus vägskyddet och på den rutten finns det inga larm alls.
Det verkar ju som om mängden signaler ger "Timeout" bug som i sin tur ger "Message Overflow".

mvh
Håkan

[korvtiger]

Tack för de testen.

Det verkar alltså som om min fix gjorde saker värre, i enbart 1/3 fall så dök signalbilderna upp?

Jag tycker inte att Timeout borde ha något med Message Overflow att göra. De kanske triggras av samma sak, men jag tror inte att den ena direkt orsakar den andra. Det låter dessutom på er som att det felmeddelendet inte alltid förekommer.

Julgranen innebär ju egentligen bara att signalen inte har initialiserats. Om signalens tråd har kraschat på grund av meddelendekön så är detta inte så konstigt.

Jag börjar få slut på bra idéer att testa. Har letat igenom hela koden och det verkar bara finnas ett enda ställe där STL-koden skickar ett Signal, StateChanged-meddelande och det är när den initialiserar en mastersignal. Och det var det stället som jag försökte fixa i min bugfix. I värsta fall betyder detta att det är underliggande kod som skickar meddelandena och då är det inte säkert att vi enkelt kan göra något åt saken.

Det enklaste skulle nog vara om någon av er skulle kunna skicka sin bana till mig, så att jag kan utföra tester själv. Det är mycket enklare när man har något att testa på, så man kan leta sig fram till felet genom uteslutningsmetoden eller att skriva ut vad för delar av koden som körs.
Skicka mig ett PM, det behöver bara vara banan, huvudsessionen samt eventuellt spår-assets om ni använt något annat än de inbyggda, eller de som finns på STLs hemsida.

[blomsson]

Banan är (förhoppningsvis) skickad.

När jag öppnade banan idag, efter att jag hade gjort iordning den till dig, så kunde jag se alla felmeddelanden, både Tmeout och Message. Men alla signaler visade signalbilder efter en stund.

Det är det som gör det så frustrerande att felsöka, att beteendet inte alltid är detsamma.
Ska bli intressant att se om du kan finna något i banan eller om du bara blir mörkrädd hur den ser ut...

mvh
Håkan

[korvtiger]

Har kikat och provat flera lösningar på att få bort felen, men har inte lyckats komma så mycket närmare en lösning. Har försökt med olika typer av fördröjningar, men antingen så kommer felen bara att dyka upp senare, eller så slutar signalerna att fungera helt.
Problemet är att alla signaler vid start skickar ett uppdateringsmeddelande till alla andra signaler, ungefär samtidigt som att alla växlar framför en signal läggs om två gånger. Detta tillsammans innebär att det blir för många meddelanden att hantera för Trainz, som begränsar antalet meddelanden per objekt till 1024 stycken.

För mig så fungerar det i alla fall att köra på banan efter att alla fel dykt upp, så det är går ju fortfarande att köra även om det är lite tråkigt att saker måste krascha först.

Har dock hittat att växlar läggs om av scriptet som MegaCreator trodde. Dock verkar det inte ha något att göra med udda/jämt utan med linjeplatssignaler, vilket jag inte riktigt förstår vad det är. Funderade på om det hade med Bemannade/Obemannade stationer att göra, men jag kan inte se några sådana kopplingar. Man skulle kanske kunna plocka bort denna del av scriptet, men jag är väldigt osäker på vad som skulle hända och vad för funktionalitet som eventuellt skulle kunna försvinna.