Äldre Ljussignaler (diskussions tråd).

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