![]() |
Om det här är ditt första besök, se till att gå till vår FAQ (finns även länk till FAQ i navigeringsmenyn ovan). Du kan behöva att registrera dig innan du kan posta (finns även en länk till registrering i navigeringsmenyn ovan). För att titta på inlägg, välj det forum som du vill besöka från de som är listade nedan. |
|
![]() |
|
Ämnesverktyg | Visningsalternativ |
![]() |
#46 | |||||
Medlem
Reg.datum: Jan 2008
Ort: Uppland, Sverige
Inlägg: 2 716
|
![]()
Tack för testen!
Citat:
Att det uppkommer varje gång är rätt väntat. Det verkar mycket riktigt vara samma fel som MegaCastor har. Citat:
Citat:
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. Citat:
Citat:
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. 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.
__________________
-k- |
|||||
![]() |
![]() |
![]() |
#47 | ||||||
Medlem
Reg.datum: Jul 2011
Ort: Vingåker
Inlägg: 343
|
![]()
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. Citat:
Citat:
Citat:
Citat:
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! Citat:
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. Citat:
mvh Håkan
__________________
Fd. signalreparatör på Banverket. Sjukpensionär bla pga Aspergers syndrom. Använder numera T:ANE på en iMac (Retina, 27", -15), 24GB, OSX Sierra 10.12.6 (25/9-17) Hemsida för nedladdning av mina objekt: https://blomsson4073.se/index.html |
||||||
![]() |
![]() |
![]() |
#48 |
Medlem
Reg.datum: Jul 2011
Ort: Vingåker
Inlägg: 343
|
![]()
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
__________________
Fd. signalreparatör på Banverket. Sjukpensionär bla pga Aspergers syndrom. Använder numera T:ANE på en iMac (Retina, 27", -15), 24GB, OSX Sierra 10.12.6 (25/9-17) Hemsida för nedladdning av mina objekt: https://blomsson4073.se/index.html |
![]() |
![]() |
![]() |
#49 |
Medlem
Reg.datum: Jan 2008
Ort: Uppland, Sverige
Inlägg: 2 716
|
![]()
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.
__________________
-k- Senast redigerad av korvtiger den 2016-05-31 klockan 00:25. |
![]() |
![]() |
![]() |
#50 |
Medlem
Reg.datum: Jul 2011
Ort: Vingåker
Inlägg: 343
|
![]()
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
__________________
Fd. signalreparatör på Banverket. Sjukpensionär bla pga Aspergers syndrom. Använder numera T:ANE på en iMac (Retina, 27", -15), 24GB, OSX Sierra 10.12.6 (25/9-17) Hemsida för nedladdning av mina objekt: https://blomsson4073.se/index.html |
![]() |
![]() |
![]() |
#51 |
Medlem
Reg.datum: Jan 2008
Ort: Uppland, Sverige
Inlägg: 2 716
|
![]()
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.
__________________
-k- |
![]() |
![]() |
![]() |
#52 |
Medlem
Reg.datum: Mar 2006
Ort: Ljungby, Kronoberg, Sverige
Inlägg: 22
|
![]()
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. |
![]() |
![]() |
![]() |
#53 | |||
Medlem
Reg.datum: Jul 2011
Ort: Vingåker
Inlägg: 343
|
![]() Citat:
Citat:
Citat:
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
__________________
Fd. signalreparatör på Banverket. Sjukpensionär bla pga Aspergers syndrom. Använder numera T:ANE på en iMac (Retina, 27", -15), 24GB, OSX Sierra 10.12.6 (25/9-17) Hemsida för nedladdning av mina objekt: https://blomsson4073.se/index.html |
|||
![]() |
![]() |
![]() |
#54 | |
Medlem
Reg.datum: Jul 2011
Ort: Vingåker
Inlägg: 343
|
![]() Citat:
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
__________________
Fd. signalreparatör på Banverket. Sjukpensionär bla pga Aspergers syndrom. Använder numera T:ANE på en iMac (Retina, 27", -15), 24GB, OSX Sierra 10.12.6 (25/9-17) Hemsida för nedladdning av mina objekt: https://blomsson4073.se/index.html |
|
![]() |
![]() |
![]() |
#55 | |||
Medlem
Reg.datum: Jan 2008
Ort: Uppland, Sverige
Inlägg: 2 716
|
![]() Citat:
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! ![]() 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. Citat:
Citat:
Gör det!
__________________
-k- |
|||
![]() |
![]() |
![]() |
#56 |
Medlem
Reg.datum: Mar 2006
Ort: Ljungby, Kronoberg, Sverige
Inlägg: 22
|
![]()
Tack för svaret och tack för ditt engagemang.
|
![]() |
![]() |
![]() |
#57 |
Medlem
Reg.datum: May 2011
Ort: Linköping
Inlägg: 32
|
![]()
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 |
![]() |
![]() |
![]() |
#58 | |
Medlem
Reg.datum: Jan 2008
Ort: Uppland, Sverige
Inlägg: 2 716
|
![]() Citat:
__________________
-k- |
|
![]() |
![]() |
![]() |
#59 |
Medlem
Reg.datum: May 2011
Ort: Linköping
Inlägg: 32
|
![]()
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 |
![]() |
![]() |
![]() |
#60 | |
Medlem
Reg.datum: Jan 2008
Ort: Uppland, Sverige
Inlägg: 2 716
|
![]() Citat:
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.
__________________
-k- |
|
![]() |
![]() |