Królik Uszasty

Drogi adametsie2, Twoja z pozoru prosta propozycja niesie jednak szereg komplikacji. Najsensowniejsze rozwiązanie bez psucia reszty gry to możliwość zarezerwowania składu i oczekiwanie na peronie na jego przyjazd. Tylko że nie wydaje mi się, aby było to intencją Pierwszego Save'ującego*, na którego się od dłuższego czasu tutaj kreujesz. Przecież to wydłuży czas przejazdu dodatkowo o oczekiwanie nawet do godziny. Przy trasach osobowych to mniej więcej drugie tyle, co cały rozkład. Jeśli natomiast chciałbyś sztucznie przesuwać pociągi wzdłuż linii, no to Twoja imersja zaburzy imersje wszystkich pozostałych graczy na danym odcinku. Nie można tego zbyć słowami, że to tylko problem programistyczny. Pociąg jedzie po zadanej trasie i według zadanego czasu. W przypadku skoku zniknie on najbliższemu dyżurnemu, któremu de facto zmieni się kolejność pociągów na szlaku. Może on nawet nie być świadomy, że szlak się zwolnił (bo gra bez huda). Odrębną kwestią jest teraz, co z tym pociągiem. Czekamy do planowego odjazdu? No to wracamy do pkt 1. Jedziemy wg przesuniętego rozkładu? No to odsyłam do wątków dot. własnego rozkładu jazdy. Trzecie rozwiązanie to pozostawienie na planszy tylko pociągów kierowanych przez graczy, ale to rozwiązanie po części też już było omawiane przy okazji własnego rozkładu jazdy. No i w godzinach nocno-porannych na mapie można nie spotkać żywej duszy, co kłóci się z ideą grania w multi z innymi. Osobnym humorystyczno-ironicznym wątkiem tej dyskusji byłoby ograniczenie możliwości wychodzenia z pociągów podczas jazdy i np. tryb szpitala na leczenie obrażeń, jeśli ktoś jednak zdecyduje się zniknąć z gry przy 200 km/h. Coś, co miałoby jakiś aspekt imersyjny, zdecydowanie odbiłoby się na grywalności - bo kto by chciał grać w grę w pociągi, żeby odleżeć swoje w szpitalu? * żaden przytyk, widzę, że najbardziej i przy kazdej okazji się upominasz o te funkcję. Obecny system scenariuszy singleplayer umożliwia stosowanie elementów losowych w wielu miejscach, więc jeszcze wszystko przed nami 🙂

Na wszystkich to było czy tylko na wybranych?

Skrót myślowy - ostatni ważny na tej linii. Poprawiłem w poście.

A to nie jest tak, że Dańdowka jest ostatnim ważnym i nieobsadzonym posterunkiem na tej linii, od którego wszyscy wymagają cudów? Z uwagi na układ torowy ona łatwo się zapycha, a do tego ruch pociągów towarowych dwutorowo ze Stawisk do Juliusza powoduje blokowanie glowic na długi czas. Do tego południowy, który weźmie sobie 3 pociągi, Kazimierz 2 i jest kaplica.

Pantografy są pneumatyczne. Baterie się włącza po to, żeby w ogóle układ sterowania (analogowy czy cyfrowy) reagował na ruchy przełącznikami. No i bateria służy też do małej sprężarki od pantografów. W mianowniku jest szybko malejącą odległość, obie prędkości są w liczniku w kwadracie. No i pozwolenie przekroczenia prędkości generalnie spoko, tylko czerwone to czerwone 😉 Muszę jeszcze trochę nad tym pomyśleć, kilka pomysłów mam, a przyda się to też do automaszynisty parowozu, żeby np. nie machał przepustnicą jak szaleniec czy też spokojniej dojeżdżał do ograniczeń na wzniesieniu.

@PeVoo Luz, to nie wygląda aż tak źle, jak opisujesz. Logika samouczka jest programowana w języku wysokiego poziomu, więc tam problemów z tym nie ma, żeby coś pozmieniać albo pozabezpieczać. Ot idzie sobie checklista (z ewentualnymi dodatkowymi warunkami lub podlistami zależnie od trybu) i przekazuje dalej komunikat przy pierwszym niezrealizowanym punkcie wraz z informacją, który przełącznik podświetlić. Problem powtarzanego komunikatu to kwestia "mendejów" a nie algorytmów, Krok po kroku będzie naprostowane, jak już będę bliżej ostatecznej formy. Co do hamowania, to mniej więcej tak to działa - wyliczam potrzebne opóźnienie hamowania, sprawdzam obecne opóźnienie hamowania i gdy się różnią za bardzo, idzie komunikat o konieczności hamowania mocniej/słabiej z uwzględnieniem prostego przeliczenia opóźnienia hamowania na wymagany spadek ciśnienia w przewodzie hamulcowym. Nie do końca mi ten algorytm pasuje, ale w sumie ta pomoc przy hamowaniu to bardziej miała być wskazówka, co robić, a nie konkretny trening, że dokładnie tak trzeba robić. Problem przy podejściu opóźnienia to nadmierne zwiększanie się czułości obliczeń przy jeździe blisko prędkości dozwolonej blisko semafora (bo skraca się bardzo szybko mianownik). No i to o czym wspominałem odnośnie nieliniowości sprawia, że ruch nie jest jednostajnie opóźniony. Najlepiej te podpowiedzi się sprawdzają w EN57, bo reakcja hamulców jest prawie natychmiastowa. Mam jeszcze kilka pomysłów, jak do tego podejść, ale chyba nie to jest na teraz najważniejsze w samouczku. ETCSu bym w to nie mieszał, bo tam krzywa hamowania jest wyznaczana specyficznie i w zupełnie innym celu.

Co do samouczków, zwłaszcza ostatnich - temat niejako naturalnie spadł na mnie przy oprogramowaniu nowych pojazdów (EN57 i ET22). Każdy kolejny jest rozwinięciem poprzedniego, dlatego w Ty2 też będzie kilka ulepszeń w stosunku do poprzednich (w tym wykorzystanie możliwości LUA - wybór funkcji, poziomu trudności jazdy czy słowne podsumowanie). No i kawałek trasy będzie też inny. Z parowozem wyszła tylko taka niedogodność, że temat ciągnie się za długo i część pomysłów z poprzedniego samouczka się zdezaktualizowała, a po drodze weszły dwa z trochę inną koncepcją. Przy moich samouczkach pierwszą i podstawową zmianą jest odejście od sztywnych ram "tutaj się rozpędzaj, a po 2 km wyłączymy podpowiedzi", "od tego miejsca hamujemy" na rzecz "nieustającej pomocy" - samouczek ma prowadzić rozruch i hamowanie, zmianę oświetlenia, podpowiadać o otwarciu drzwi itd. na podstawie jednego włącznika, niezależnie od ustalonej trasy przejazdu czy obciążenia lokomotywy. Dzięki temu potencjalnie mógłby on być np. wykorzystany w innych misjach lub jako opcja "telefon do przyjaciela-instruktora", żeby podpowiedział, co zrobić. W prostym samouczku dla pojazdu nie zawsze jest możliwość, żeby wszystkie możliwe opcje czy uszkodzenia pokazać. Mam nadzieję, że przy parowozie uda mi się uprzątnąć i uwspólnić część rzeczy w środku, żeby następnie pozostałe samouczki były spójne w zakresie logiki działania i oferowanych możliwości. Przy tej okazji by się poluzowało pewne uproszczone reguły związane np. z tym, w jakim trybie kamery bądź miejscu się znajdujemy, żeby móc dla chętnych dopuścić sterowania pociągiem z kamery nr 2. Części problemów jestem świadomy, natomiast np. dla powtarzających się komunikatów jeszcze nie rozgryzałem możliwości załatania tego. Znam dokładnie przyczynę takiego zachowania, tylko czeka w kolejce między innymi rzeczami. Do tej pory koncepcja była taka, że naprowadzanie gracza ma być tekstem pisanym, mową i podświetleniem przełącznika. Jakiegoś celowniczka czy wykresu nikt nie brał pod uwagę. W kwestii samego hamulca problematyczna jest nieliniowość jego działania (w zakresie prędkości jazdy, obciążenia i stopnia hamowania), czas reakcji gracza na komendę oraz dokładność jej wykonania. W zasadzie dotykamy tu tego samego problemu co bot - sterowanie "prawdziwym symulowanym pociągiem" czasem komputerowi nie wychodzi. Z drugiej strony, istniejące teksty i komendy przy sterowaniu hamulcem muszą być krótkie, aby w porę na nie zaregować. Mam nadzieję, że zauważyliście, że w EN57 i ET22 pierwsze i kolejne użycie hamulca (oddzielnie dla hamowania i luzowania) są inne, właśnie po to, żeby za pierwszym razem przy manewrach coś troszkę wytłumaczyć, a potem w czasie jazdy już wymagać zastosowania się krótkim hasłem. 1. Według ostatnich znanych mi planów to tak, natomiast po drodze jest jeszcze kwestia zaległego hotfixa. 2. Nie moja działka. 3. Nie wiem. Rozkładowo Śródmieście jest potrzebne, żeby m.in. nie korkować Wschodniej i Włochów. A tak szczerze, to z trasy DLC to sam się przejechałem do tej pory tylko przy testach manewrów z Retkinii do Pabianic i w innych celach z Widzewa do Gałkówka. Wypowiadam się w zasadzie na tematy, które dotyczą mnie i jestem w stanie coś sensownego napisać. Ale na niektóre tematy się z definicji nie wypowiadam z przyczyn dosyć oczywistych - bo "nie wiem, ale się domyślam", tylko że moje prywatne domysły nie powinny być oklejane naklejką "Zespół SIMRAIL".

Co prawda to forum o "pociągach w komputerze", ale ten wątek jest już i tak o wszystkim, więc w ramach "bawi i uczy" chciałbym przypomnieć, że samo pojęcie urlop oznacza co najwyżej usprawiedliwioną nieobecność w pracy (płatną bądź też nie). Prezentowane wyżej sformułowanie odniesione już np. do urlopu macierzyńskiego jest już daleko krzywdzące. Wiem, że dyskusja tyczyła się urlopu wypoczynkowego (chociaż stricte takie sformułowanie nie padło), ale budujmy wokół siebie szerszą świadomość społeczną takich podstawowych tematów. Kwestie urlopów są uregulowane w ramach kodeksu pracy (ale nie tylko, bo również mówi o tym np. art. 196 ust. 1 ustawy Prawo o szkolnictwie wyższym i nauce) i większość z nich pracodawca jest obowiązany na wniosek pracownika udzielić, więc słowo "rzekomo" jest tutaj nie na miejscu. Terminy brania urlopów wypoczynkowych i zjawisko sezonu urlopowego jest też raczej ogólnie znana i stricte powiązana z tokiem roku szkolnego (przerwy wakacyjne)j i pogody w ramach klimatu naszej części świata. Tak, jak rozumiem rozgoryczenie wywołane faktem, że rzeczy nie idą tak gładko, jak w tytułowej roadmapie, tak jednak po blisko dwustu latach ogólnoświatowej walki o prawa pracownicze (w tym m.in. określenie norm czasu pracy, sprawa pracy dzieci czy zagwarantowanie urlopów) wydawało mi się, że są to rzeczy głęboko zakorzenione w kulturze europejskiej, a więc - oczywiste. Widocznie się mylę. Mimo to nie życzę nam tutaj powrotu do tamtych (słusznie minionych) czasów, bo wtedy na granie w grę wtedy nie będzie ani sił, ani czasu.

How far were you from stop point? Did distance become green? I will look into it, if I can change it easly. Each switch generates its own request with the same code of text, but different switch for outline. I don't uderstand this sentence. Could you rephrase it?

Tak

Przygotowałem po naszej stronie poprawkę, żeby zimne pojazdy też widziały tarcze manewrowe.

To dziwne, bo w tutorialu pojazd się spawnuje pod tarczą manewrową, jest zimny i widzi niebieskie światło. Temat do sprawdzenia w zakresie skanowania.

Myślę, że część problemów rozwiąże Ci opcja pomijania jednoelementowych okien komunikatów.

Najpierw odniosę się do pogrubionego słowa: symulacja to sztuka iluzji i oszustwa, w sumie tak samo jak granie w symulatory. I mimo negatywnych konotacji tego słowa, to w tym przypadku akurat czerpiemy nieszkodliwą społecznie przyjemność z grania w grę i udawania, że robimy coś na kolei, więc nie ma w tym nic złego 😉 Odnośnie samego bota - jeśli chodzi o MaSzynę, to doskonale wiem, co tam jest, jak to działa i jakie za tym idą konsekwencje (dobre i złe). Tutaj podjęliśmy decyzję o uproszczeniu pewnych rzeczy, które same w sobie nie mają wpływu na działania gracza oraz są kompletnie niepotrzebne w oprogramowaniu serwera, bo nic nie wnoszą poza obciążaniem procesora obliczeniami. Na to nałożyły się inne, niestety konieczne ograniczenia i stąd Wasz nieprzychylny odbiór naszego bota od pociągów. Rozwiewając wątpliwości: Bot wbrew pozorom nie ogranicza się do wyliczenia sobie prędkości z jaką ma jechać z jakiejś predefiniowanej krzywej, a jedzie w ramach dostępnych limitów prędkości i granicznej krzywej hamowania. W każdej kolejnej klatce bot podejmuje decyzje, czy przyspieszać, jechać wybiegiem lub hamować. Na tej podstawie jest obliczana prędkość jazdy pociągu. Osiągi pociągu zależą od osiągów poszczególnych pojazdów razem wziętych. Mechanizm nagłego spadku prędkości (tak samo jak cofanie pod S1) ma na celu zmniejszenie koniecznych interwencji w ruch na serwerach. To samo dotyczy wspomagania ruszania na spadkach, które jest konfigurowalne. Nie wiem, jakie mamy teraz ustawienia na serwerach, ale bota można płynnie zaprogramować od pełnego ignorowania pochyleń do pełnego ich uwzględniania (tj. w pełnym zakresie prędkości). Co do magicznego hamowania, mieliśmy na ten temat niedawno wewnętrzną rozmowę powiązaną też z ETCS. Ten mechanizm dałoby się szybko wyłączyć (bo patrz pkt poprzedni - to jest dodatek do bota, a nie podstawa jego działania), zwłaszcza że S1 mamy i tak chronione mechanizmem cofania. Pozostaje tylko kwestia stosowania się do ograniczeń prędkości i wymuszenia tego, żeby gracze nie rozpędzali pociągów ponad możliwości AI i uciekali bez śladu, że to nie oni się wykoleili. Bot nie obsługuje całej fizyki i symulacji pojazdu (sterowanie, hamulec itd), aby nie musieć wykonywać pełnych obliczeń fizyki pojazdu, w tym przede wszystkim całej pneumatyki liczonej znacznie częściej niż fpsy - co również odciąża serwer, który nie musi w ogóle tego liczyć. Uproszczenie to uwalnia nas jednocześnie od całej logiki związanej z nieprawidłowym kierowaniem pojazdem, np. luzowanie przeładowanych hamulców wagonów. Na mapie mamy w okolicach 100 pociągów, z czego część to pociągi towarowe. Wszystkie należy traktować jak w ruchu. To jest parę tysięcy pojazdów, niektóre z nich bardzo daleko od jakiegokolwiek gracza. Taka implementacja bota jednocześnie pozwala uzyskać jego znacznie większą przewidywalność zachowania, czego nie można powiedzieć o wariancie z pełną fizyką - przykładowo miejsce zatrzymania taboru w Maszynie ma większy rozstrzał niż u nas, szczególnie dla pociągów towarowych. A łatwiej jest coś równego potem urealnić jakąś wartością losową niż wartości losowe zmusić do wyrównania. No i ma to swoją zaletę podczas testów stabilności czy w dawnych czasach - przy testowaniu bota z nastawni kierującego ruchem, bo wyniki były deterministyczne. Jest to też o wiele bardziej istotne przy programowaniu i wykonywaniu precyzyjnych manewrów. Mam wrażenie, że przede wszystkim gdyby nie mechanizm cofania przy S1 i automagiczne hamowanie, to Wasze zdanie byłoby lepsze - wszak multimedia pociągu w dużej mierze u bota działają i na pierwszy rzut oka nie widać/słychać, żeby było coś nie tak.

If a train passes into 2035, block signals indicate it in the same way as a train passing from 2023 into 2035, there is no risk. However it is highly recommended for a dispatcher to use exit tracks (in this case: 1Z and 2P) as there is no risk that arriving train could crash into shunting train.

Bug found and fixed by ourselves a few weeks ago, we wait for news hotfix-patch.

Jeden regulamin nie rozwiąże kwestii tego, że różni gracze oczekują różnego poziomu "realizmu" i trzymania się przepisów, a jednocześnie wraz z poziomem zaawansowania graczy i przepisowości można im oddawać do dyspozycji więcej możliwości (np. sygnały manewrowe czy rozkazy/pomijanie semaforów). Dosyć szybko się przekonaliśmy, że część osób (świadomie lub nie) potrafiła wysyłać pociągi ze stacji manewrem, jak inne środki zawiodły.

I think that 7000A is on "low" side with voltage between 500 to 1000 V, and 2kV droo is on "high" side of 25kV. In Poland overhead voltage drop is meant to be about 10% (from nominał 3300V to 3000V, however sometimes power points are set as high as 3500-3600V). Max allowed current 600A is limitation of electric motor, so EU07 can draw up to 1200A and ET22 up to 1800A. The most powerful motors in Poland are on EP09, which have nominal current about 500A and maximal 850A, so it can draw up to 1700A (Bo'Bo' locomotive).

When you use shunting, the field is weakened for this value of electric current, but total field in motor remains... nearly constant and rather dependent on motor speed. Why is that? Overhead voltage (supply) is divived into two parts - voltage loss on resistance in the circuit (typically - motors' resistance after start) and countervoltage generated in motors. However, voltage loss on the motors is not big, it is less than 100 volts for one EE541 motor of EU07 at 600A (!). Compare it to 1500 V on one motor in pair at non resistant position. So the mechanism is like that; 1) you use shunting, 2) field (factor) gradually weakens and decreases countervoltage, 3) it increases difference between supply voltage and countervoltage, so the current flowing through motors (and rotors) increases to compensate that and achieve equilibrium, 4) increased rotor's current and nearly the same field means more torque.

Old polish locomotives are equipped w LSt1 distributor valve, which has a bit unusual configuration. The brake regime applies to the flow at the input, instead of output (brake cylinder). Moreover, brake releaser does not dump pressure form steering tank to the atmosphere but to the input tank (6l). It means that the dumped air goes then to... the brake pipe through the small nozzles. So the input pressure rises above brake pipe and equals to the steering tank. If you close releaser to early, the whole air does not leave steering tank-input pair, so there is still difference, when input falls to brake pipe. When this happens, brake applies.

Obawiam się, że możesz być niepocieszony faktem, że parowóz będzie i jest bliżej jak dalej 😞

Od tamtego czasu z nic nie było w parowozie ruszane, toteż postępów brak. Odnosząc się do punktów: 1. W lokomotywowni była wyłączona animacja całego układu, poprawiłem. 2. Złe odniesienia do pliku tłumaczenia, poprawiłem. 3. Podpisy do zmiany, zobaczymy co da się zrobić z resztą. 4. Obecnie blokada została odciągnięta. Zastanawiam się nad sensownością i używalnością tego w sytuacji, gdy nam się pokrętło od napełnienia nie przestawia samoczynnie. 5. Tak. 6. Poprawione 7. Propozycja niezgodna z wyglądem GUI - raczej skończy się na paseczku z procentami. Z dźwiękiem trzeba będzie trochę pokombinować. 8. Ogrzewanie chwilowo zablokowałem, przy uruchamianiu ogrzewania parowego w wagonach będzie to nareperowane. 9. Do dorysowania. 10. Nie zawsze opisujemy wszystkie pokrętła i dźwignie, które nie są obsługiwane. 11. Póki co tak musi zostać - to się gryzie z samplem sprężarki i jego modulacją. 12. Dodana obsługa zaworów, animacja wypływu wody w toku. 13. W zasadzie można uruchomić, natomiast nie będzie to miało istotnego wpływu na jazdę. 14. Do uruchomienia. 15. Patrz pkt. 10. 16. To nie tyczy się parowozu, a ogólnego modelu przyczepności. Nie mamy tego i raczej nieprędko będzie zrobione w satysfakcjonujący sposób. 17. Tak, hamulec działa. 18. Nie spodziewałbym się, w zasadzie od tego jest GUI. 19. Trzeba przeczesać mapę w poszukiwaniu wskaźnika, może ich nie być. 20. Łopata do łopatowania jest w toku, mechanika ruszania łopatą też. 21. Masz zdjęcie takiego wodowskazu? Co do węgla, to coś nie poszło z animacją otwierania skrzyni węglowej - sprawdzamy. 22. Do dodania. 23. Do dodania, chociaż wydaje mi się, że coś już jest wybite na teksturze. 24. Wody mamy cały kocioł, dlatego w lokomotywowni nie widać, gdzie się kończy słupek - to samo, co ze stawidłem. Pasek będzie dodany, kolor wody jeszcze dobierzemy mniej niebieski. 25. Zrobione 26. Odwadniacz zbiorników - to jakoś mocno nie wpływa na jazdę w czasie spodziewanym w grze. Animacji hamulca tendra nie ma (jeśli masz na myśli dźwignie i cięgna hamulca), bo w zasadzie nigdzie tego nie animowaliśmy jeszcze. 27. To w zasadzie nie wydaje się być potrzebne w czasie jazdy. 28. Patrz 27. 29. Nie do mnie, bardzo wizjonerskie. 30. Zasięg nie powinien być problemem. Animacja - patrz 21. 31. Można kliknąć na okno i się wychylić. Czy do tego jest potrzebny bind? Jeśli coś w kabinie ruszasz, to i tak w większości myszką, więc masz ją w ręce.

Przepustowość Sosnowca Południowego na to nie pozwoli. No i sugerowana trasa jest strasznie na około. A gdyby zdegradować ECE na MPE/TLK to nie byłoby OK?

Fun fact: One of of our customers wanted to have on driver`s monitor most of the tabs from real train, including toilet status, which had to be working (changing percentage of water and fecal level during simulation). The easiest way to deliver this was to implement simple simulator of toilets including real life characteristics of occupancy time and delay between occupancies according to passenger count in the vehicle.

My dream is to have possibility to check tutorial in multiplayer and singleplayer during every scenario, but for now I don't know how hard it would be to implement.