Äldre Ljussignaler (diskussions tråd).

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

[jgloket]

OBS Utan att veta någonting om script så måste jag fråga om signalerna måste vara så avancerat programmerade.

Jag vill gärna själv välja signalbild och STH beroende på kommande signal. Och det är klart att en signal måste veta om det är fritt till nästa signal och vad den signalen visar. Men om man läser er tråd så verkar alla signaler skicka små meddelanden till alla andra.

Är det möjligen så att Svenolovs script är för avancerat för spelet?
Kan man kanske göra ett nytt enkelt script?

Bara undrar, för programmering är ingenting jag kan.

[blomsson]

Ursprungligen postat av korvtiger

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.

Varför måste växlarna läggas om, och två gånger dessutom?

Ursprungligen postat av korvtiger

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.

Samma här, är ju dock irriterande med buggen i nedre kanten!

Ursprungligen postat av korvtiger

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.

Linjeplats är en plats på linjen med växel eller rörlig bro i tågspåret. Den förreglas i linjeplatssignal, utfartssignal eller blocksignal med linjeplatsfunktion.
Min bana har dock inga sådana inställningar i signalerna så verkar konstigt om det skulle påverka funktionen.
Bör inte ha något med stations funktionen att göra, eftersom det sker på linjen, dock skulle det kunna ha med linjeblocket att göra som ju inte fungerar!

mvh
Håkan

[blomsson]

Ursprungligen postat av jgloket

OBS Utan att veta någonting om script så måste jag fråga om signalerna måste vara så avancerat programmerade.

Jag vill gärna själv välja signalbild och STH beroende på kommande signal. Och det är klart att en signal måste veta om det är fritt till nästa signal och vad den signalen visar. Men om man läser er tråd så verkar alla signaler skicka små meddelanden till alla andra.

Är det möjligen så att Svenolovs script är för avancerat för spelet?
Kan man kanske göra ett nytt enkelt script?

Bara undrar, för programmering är ingenting jag kan.

Jag har kollat en del i svenolovs script (det som går att se) och tycker också att det ser väldigt komplicerat ut.
Däremot så kan du ju välja vilka signalbilder som signalen kan visa till vilket objekt. Dock är det inget beteende som jag tycker om, eftersom det går att kringgå signalens inbyggda säkerhetssystem. Och man måste göra mycket jobb som istället borde hanteras i scriptet av programmeraren.

Jag håller på och försöker att programmera ett modernt signalsystem baserat på reglerna och föreskrifterna i Säo (numera TTJ). Om det finns ett intresse för detta kan jag starta en ny tråd och tala om mina tankar och ideér och få lite input utifrån!

mvh
Håkan

[korvtiger]

Ursprungligen postat av jgloket

OBS Utan att veta någonting om script så måste jag fråga om signalerna måste vara så avancerat programmerade.

Jag vill gärna själv välja signalbild och STH beroende på kommande signal. Och det är klart att en signal måste veta om det är fritt till nästa signal och vad den signalen visar. Men om man läser er tråd så verkar alla signaler skicka små meddelanden till alla andra.

Är det möjligen så att Svenolovs script är för avancerat för spelet?
Kan man kanske göra ett nytt enkelt script?

Bara undrar, för programmering är ingenting jag kan.

Nja, det behöver inte vara riktigt så avancerat. Om man vill ha enklare signaler så finns ju STWs gamla, men de är kanske för enkla istället. De borde fungera relativt bra för modern signaleringsprincip, men äldre signaleringsprincip är nästan omöjligt att få till som man vill utan Svenolovs script. Grejen med Svenolovs script är att jag tror att det är utvecklat under väldigt låg tid och massor av nya funktioner har lagts på allt eftersom. Och när man inte tänker på allt sådant från början är det lätt att det blir rörigare och rörigare när ny funktionalitet tillkommer. Men den största grejen är väl att Svenolovs script är så brett, på gott och ont. Det tar hand om både modern och äldre signaleringsprincip, Bemannad/Obemannad, dela in trafikplatser i stationer och lastplatser, hanterar öppningsbara broar, treskensspår, spårkors, det finns förberett för autopilot och ATC och så vidare. Man behöver inte ha all denna funktionalitet, men det är ju lite häftigt att allt finns där, i ett scriptbibliotek!

Att alla signaler skickar meddelanden när de slår om är inget man kan göra något åt, det är en del av den underliggande koden i Trainz som sköter. Varje gång man ställer om en signal så kommer den att tala om för alla som lyssnar att den har slagits om. Detta måste den ju göra för att föregående signal ska kunna märka att nästa signal slagits om och att den därför bör utvärdera om den skall slå om till annan signalbild också. Så teoretiskt sett borde man få samma problem med message overflows med andra signaler än de som har Svenolovs script, bara man har tillräckligt många av dem på sin bana.

Svenolovs script fungerar ganska bra skulle jag vilja säga, särskilt för den äldre principen. Problemet är att Trainz begränsar antal meddelanden vilket skiter sig vid uppstart. Men när signalerna väl är igång så är det ju inga problem, då skickas bara enstaka meddelanden när en signal slås om. Det borde teoretiskt sett gå att lösa så att meddelandeköerna inte överflödas om man hittar rätt i hur signalerna initialiseras, så man kan fördröja den första uppdateringen, det är ju vad jag försöker att göra. Gäller bara att hitta hur allt sitter ihop. Jag jobbar vidare på det!

Ursprungligen postat av blomsson

Varför måste växlarna läggas om, och två gånger dessutom?

För att sökningar följer hur växlar ligger vad det verkar. Så för att kolla båda spåren i en växel så måste man först söka på det spåret växeln ligger på, sedan lägga om den en gång för att söka längs det andra spåret och till sist lägga tillbaka växeln för att den ska ha rätt läge vid sessionens start.

Ursprungligen postat av blomsson

Linjeplats är en plats på linjen med växel eller rörlig bro i tågspåret. Den förreglas i linjeplatssignal, utfartssignal eller blocksignal med linjeplatsfunktion.
Min bana har dock inga sådana inställningar i signalerna så verkar konstigt om det skulle påverka funktionen.
Bör inte ha något med stations funktionen att göra, eftersom det sker på linjen, dock skulle det kunna ha med linjeblocket att göra som ju inte fungerar!

Då låter det ju som att denna koden inte borde köras för några signaler när man startar? För visst ställer man in en signal på att vara en linjeplatssignal? I så fall borde varje signal veta om den är en linjeplatssignal och enbart då kolla växlarna. Lyckes jag stänga av den sökningen i onödiga fall så borde det lösa våra problem med message overflows. (Tills ni satt ut 600 signaler till...)

Ursprungligen postat av blomsson

Jag har kollat en del i svenolovs script (det som går att se) och tycker också att det ser väldigt komplicerat ut.
Däremot så kan du ju välja vilka signalbilder som signalen kan visa till vilket objekt. Dock är det inget beteende som jag tycker om, eftersom det går att kringgå signalens inbyggda säkerhetssystem. Och man måste göra mycket jobb som istället borde hanteras i scriptet av programmeraren.

Jag tror att mycket av detta beror på att han ville skapa ett script som kan användas för båda signaleringsprinciperna, även det gamla systemet. Det äldre systemet kräver rätt mycket "fusk" med Signal Markers och liknande som det moderna systemet inte behöver och där är tågvägar ett väldigt centralt begrepp, därav så ser signalinställningarna ut som de gör.

Ursprungligen postat av blomsson

Jag håller på och försöker att programmera ett modernt signalsystem baserat på reglerna och föreskrifterna i Säo (numera TTJ). Om det finns ett intresse för detta kan jag starta en ny tråd och tala om mina tankar och ideér och få lite input utifrån!

Gör det!

[jgloket]

Tack för svaret och tack för ditt engagemang.

[MegaCastor]

Följer diskussionen med intresse och stannade till lite vid linjeplatssignaler.
Jag har en linjeplatssignal på min bana och gjorde ett enkelt experiment.

Först öppnade jag sessionen i Surveyor med linjeplatssignalen på sin plats.
Resultat: timeout på rad 185

185.jpg

Därefter plockade jag bort signalen och öppnade sessionen igen i Surveyor.
Resultat: timeout på rad 104

104.jpg

Är ::FindApproachingTrains() ny i detta sammanhang?

Slutsats? Tja, det är skillnad med och utan linjeplatssignal.
Kanske någon annan kan komma fram till något djupare?!

/Magnus

[korvtiger]

Ursprungligen postat av MegaCastor

Följer diskussionen med intresse och stannade till lite vid linjeplatssignaler.
Jag har en linjeplatssignal på min bana och gjorde ett enkelt experiment.

Först öppnade jag sessionen i Surveyor med linjeplatssignalen på sin plats.
Resultat: timeout på rad 185

Därefter plockade jag bort signalen och öppnade sessionen igen i Surveyor.
Resultat: timeout på rad 104

Är ::FindApproachingTrains() ny i detta sammanhang?

Slutsats? Tja, det är skillnad med och utan linjeplatssignal.
Kanske någon annan kan komma fram till något djupare?!

/Magnus

Detta gör egentligen ingen skillnad. Timeout är bara att Trainz efter ett givet antal millisekunder kommer att avbryta en tråd som körs. Eftersom en dator hinner utföra miljontals beräkningar på en ynka millisekund så kan Trainz ha hunnit väldigt olika långt i denna tråds exekvering när den blir avbruten för att tiden gått ut. Så "felet" kommer att kunna uppstå på väldigt olika platser i koden, men själva platsen har ingenting med "felet" att göra, eftersom det bara är tråden som blivit avbruten där den råkade vara i just det ögonblicket.

[MegaCastor]

Ok, ingen egentlig skillnad således.

Jag sökte också på Trainz forum och hittade följande inlägg: About timeout in scripts

Det bekräftar det som korvtiger skrev i inlägg #29 i denna tråd:
att man har begränsat den tid scriptet får köra innan det blir timeout
och att man kortat ned denna tid i TANE jämfört med tidigare versioner
av spelet. Avsikten tycks vara att förmå script-
programmerarna att byta ut ineffektiva rutiner mot effektiva.

Problemet med detta är att vissa uppgifter tar lång tid inte för att scriptet
är dåligt programmerat eller använder ineffektiva rutiner, utan för att
uppgiften i sig är komplex och kräver många beräkningar.

Är det någon som vet om scriptet kan "pausa" på något sätt för att,
så att säga, köpa sig ny tid innan det blir timeout?

/Magnus

[korvtiger]

Ursprungligen postat av MegaCastor

Ok, ingen egentlig skillnad således.

Jag sökte också på Trainz forum och hittade följande inlägg: About timeout in scripts

Det bekräftar det som korvtiger skrev i inlägg #29 i denna tråd:
att man har begränsat den tid scriptet får köra innan det blir timeout
och att man kortat ned denna tid i TANE jämfört med tidigare versioner
av spelet. Avsikten tycks vara att förmå script-
programmerarna att byta ut ineffektiva rutiner mot effektiva.

Problemet med detta är att vissa uppgifter tar lång tid inte för att scriptet
är dåligt programmerat eller använder ineffektiva rutiner, utan för att
uppgiften i sig är komplex och kräver många beräkningar.

Är det någon som vet om scriptet kan "pausa" på något sätt för att,
så att säga, köpa sig ny tid innan det blir timeout?

/Magnus

Spännande, den tråden hittade jag inte själv när jag letade för ett par veckor sedan!

Men då kan vi konstatera med säkerhet (vilket jag redan gjort efter egna tester) att timeout och message overflow inte är kopplade till varandra. Vi vet också varför vi har timeoutbuggen, vilket är ett steg framåt.
Ska fråga på Trainz-forum om vad man bör göra när man faktiskt har script som behöver kanske flera sekunder att initialiseras. Men det borde gå att lösa på ett eller annat sätt att "köpa sig tid" som du säger. Antingen genom att lägga in ett par Sleep(0.001); så att scriptet sover/lämnar över CPU:n till andra trådar om det fungerar. I andra fall så har flera idéer som måste fungera, annars hade vi fått fel på vart och vartannat script. Är nästan säker på att det går att lösa i vilket fall, frågan är bara hur lätt det är att anpassa Svenolovs script utan att ha sönder något.