Królik Uszasty

Byk na pierwszej pozycji osiąga ponad 55 kN sił pociągowej, opory ruchu całego pociągu wychodzą w okolicach 40 kN, więc pozostaje drobna nadwyżka. Wzrostu oporów ruchu przy samym ruszaniu (po chwili postoju) nie mamy, bo jeszcze nie myślałem, jak to sensownie zamodelować. W MaSzynie jest proste podniesienie składowej stałej oporów ruchu o 1/4 przy prędkości pojazdu równej dokładnie 0, natomiast taki ostry warunek nie do końca oddaje samą naturę zjawiska, które pojawia się i zanika płynnie, a nie skokowo.

Nie, brakujące odniesienia do zasilacza i rozdzielacza radiotelefonu w samouczku dla EU07.

Tak, EP08-013 ma nowy radiotelefon Koliber.

Poprawiona wersja samouczka została przygotowana i będzie wgrana w kolejnym paczu.

Możecie sprawdzić, czy na tylnej ścianie kabiny A jest włączony zasilacz i rozdzielacz (tak jak w tutorialu dla ET22)?

Rzeczywisty procent masy hamującej całego zestawionego pociągu (łącznie z lokomotywą).

Prace nad nowym rozkładem przewidujemy wraz z rozszerzeniem trasy o Łódź i Kraków. Rozkład będziemy budować od nowa w oparciu o istniejące wzorce tras w stałym cyklu: podstawowym 1h oraz dodatkowych 0,5h i 2h. (Na marginesie - też bym chciał rozkład niecykliczny, natomiast mówimy wtedy o położeniu i dograniu rozkładów dla przeszło 1000 pociągów, a nie kilkudziesięciu stałych wzorców oraz całe obiegowanie taboru, żeby to miało ręce i nogi.) Doba będzie podzielona na dzień, noc i ewentualnie okresy szczytowe dla osobówek, gdzie mogą pojawić się dogęszczenia. W nocy ruch pasażerski będzie zmniejszony, za to zwiększony ruch towarowy. Jeśli nie wystarczy przepustowości, to na pewnych odcinkach może być mniej pociągów towarowych. Otwarcie linii do Łodzi dodatkowo pozwoliłoby odciążyć CMK od części pociągów TLK i towarowych oraz wydłużyć pociągi do Wrocławia/Łodzi. Kwestia zmiany czoła na stacji końcowej lub wyjeżdżania poza mapę zostaje jeszcze do sprawdzenia. Zasadniczo przynajmniej co któryś pociąg w obiegu musi wyjeżdżać poza mapę, żeby w przypadku wykolejenia przyjechał skład zastępczy. Trasowanie w obrębie stacji końcowych będzie zrobione tak, aby w miarę płynnie działało to i przy kończeniu na mapie, i przy kończeniu poza nią (ewentualnie z dłuższym postojem). Na chwilę obecną jesteśmy na tym etapie, że rozmawiamy o szczegółowych założeniach nowego rozkładu jazdy, więc więcej konkretów nie mogę podać - nie wiemy jeszcze, jak te pociągi leżą i ile konfliktów będzie do rozwiązania. Na tym etapie może się jeszcze okazać, że coś się nie mieści/nie dojeżdża na czas/nie przechodzi i trzeba by się było wycofywać z obietnic. Do sprawdzenia w praktyce będzie również kwestia wydajności serwerów i określenia limitu obsługiwanych pociągów. Co do zasady chcielibyśmy zwiększyć liczbę dostępnych pociągów, natomiast też nie można przesadzić - dojdą też nowe nastawnie. Przepustowość niektórych szlaków już jest na wyczerpaniu, więc na pewno będą robione jakieś roszady i przetrasowania, żeby to miało ręce i nogi. No i tak jak już pisałem przy manewrach - wolę chwalić się czymś, co już działa.

Dziękuję za porcję uwag. Z racji tego, że obecnie pracuję nad czymś innym, mogę się na szybko odnieść do paru punktów. Możliwe, że w ramach optymalizacji zostało to wyłączone w lokomotywowni. Na scenerii normalnie animuje się całość od drąga stawidłowego przez kulisę do korbowodów dla całego zakresu napełnień. To akurat tyczy się nie tylko parowozu. Nie mamy tej mechaniki. Na obecnym etapie nie mamy na scenerii żurawia i wodowania, natomiast sama animacja jest przygotowana. Biorąc pod uwagę przebiegi dobowe i faktyczną prędkość jazdy parowozów towarowych 150 kilometrów powinno wystarczyć każdemu. Teoretyczny zasięg Ty2 może być nawet większy - 30 m3 wody przy zużyciu pary poniżej 10 t/h daje zapas wody na 3 godziny jazdy z prawie pełną mocą, co przy prędkości 80 km/h przekładałoby się się na 240 km jazdy. Natomiast faktem jest, że na testach prędkość jazdy z ciężkim składem oscyluje w zakresie 25-40 km/h, co drastycznie wpływa na zasięg parowozu bez wodowania. Palacz steruje pracą inżektorów i klap popielnika oraz dodaje węgiel na ruszt zależnie od życzenia maszynisty. Dodatkowo otwiera zawory zasilające, jeśli coś ktoś zamknie.

Posun je účelný pohyb drážních vozidel v dopravnách či další související činnosti, například za účelem jejich přemístění ve stanici. Shrnutí: V současné chvíli nemáme žádnou informaci o budoucí aktualizaci, kde by mohly být posuny zahrnuty. Toto téma má pouze za cíl pouze ukázat aktuální postup prací. V posledních dnech jsem pracoval primárně na opravě chyb a vývoji herní mechaniky týkající se posunu (viz body číslo 1 až 3 níže). Tato práce mě přiměla napsat něco málo o svých myšlenkách k tomuto tématu, a zároveň představit postup prací. Berme to jako takové nahlédnutí do tvorby bez zveřejnění screenshotů. Posuny jsou celkem obsáhlé téma, které lze rozdělit do několika bodů a jsou si navzájem závislé: Správné zobrazení a nastavení návěstidel pro posun a jejich správná interpretace Změna směru jízdy vlaku či soupravy, jízda vpřed a vzad Spojování a rozpojování vlakových souprav A ten hlavní bod - Programování mechanismu synchronizace ve hře pro více hráčů a zavedení plánu pro posuny Bod č. 1: Ve hře je od samotného začátku možnost stavět posunové cesty, nicméně tato funkce je na veřejných serverech zakázána - možná si někteří z Vás vzpomenou, co se dělo během veřejného testování, kdy některé vlaky byly posílány do vedlejších stanic pomocí návěstidel určených pro posun. Ve hře pro jednoho hráče je posun povolen a funkční, některé mise již samotný posun dokonce obsahují. Co se týče interpretace posunových návěstidel botem, tak zde bylo opraveno mnoho chyb. Některé z nich například znemožňovaly botům zastavit u některých kombinací návěstidel. Nyní umí boti jezdit dle všech typů návěstidel, a zároveň berou v úvahu, zda jedou jako posun, či vlak. Totéž platí i pro hráče - hráči mají hrou interně přiřazený svůj režim jízdy (posun či vlak). Například tedy pro vlak s aktivním jízdním řádem lze projet označník W5 ("Posunovací limit") či návěstidla pro posun ("Ms1/Ms2") bez potíží, nicméně v režimu posun nelze tyto označníky "W5" a návěstidla "Ms1" (modrá návěst pro posun = "Stůj") projet, neboť se počítají jako projetí klasické návěsti S1 - tedy návěsti "Stůj". Bod č. 2: Velký pokrok byl učiněn v jízdě vpřed a vzad. Boti i hráči dostávají správné informace o návěstidlech umístěných za vlakem, nebo před vlakem v závislosti na jeho směru jízdy. To znamená, že některé staré mise, které obsahovaly změny směru jízdy, by měly nyní fungovat bez potíží a správně. Neměly by se tak vyskytovat problémy s chybnou interpretací návěstí a rozdíly mezi chováním samostatného vlaku a zobrazením v grafickém rozhraní - nejlepším příkladem je chyba, kdy nebylo možné projet návěstidlo za vlakem s návěstí jízda povolena. Bod č. 3: Při vývoji se vyskytly interní problémy spojené s rozděláním či spojováním vlakových souprav. Pro srovnání - ve hře MaSzyna* neexistují vlakové soupravy, každá souprava je tedy vedena jako jeden ucelený vlak, sofistikovanější funkce jsou zde implementovány v algoritmech. Ve hře SimRail je každé vozidlo v soupravě samostatné, což je pro nás (vývojáře) velmi výhodné, ale má to velkou nevýhodu - synchronizaci. Nejzajímavější práce se základním mechanismem je hotová - vůz lze od vlakové soupravy odpřáhnout, či nějaký vůz do vlakové soupravy zapřáhnout, a lze samozřejmě těmito vozy i normálně jezdit. Návěstidla a grafické zobrazení funguje správně v obou směrech (viz bod číslo 2), ale je s tím samozřejmě i spousta další práce - tento systém vyžaduje ještě zdlouhavé vyhledávání a testování chyb, které vznikají při této změně ve vlakové soupravě. [* Pozn.: Pro ty, kteří nejsou z Polska, a neznají ho - simulátor MaSzyna je polský vlakový simulátor, který byl vyvinut před více než 20 lety. Někteří naši zaměstnanci se podíleli na jeho vývoji, mezi polskými železničními fanoušky je simulátor velmi dobře známý.] Shrneme-li body číslo 1 až 3, můžeme označit posuny za hotové, pokud lze nasimulovat následující situace: Posun ve stanici mezi dvěma jednotlivými kolejemi, nebo také z odstavných kolejí/vlečky (např. jízda s jednotkou Elf z depa v Katowicích k nástupišti v téže stanici), Změna směru jízdy (např. osobní vlak z Katowic do Sędziszówa přes stanici Sosnowiec Główny - se změnou směru jízdy), Možnost zapřáhnout či odpřáhnout vozidla od soupravy (např. odpřáhnutí lokomotivy od nákladního vlaku ve stanici Łazy či KWK Staszic). Nicméně primárně chceme, aby herní fyzika a mechanika byla kompletně hotová a plně funkční pro všechny tyto úkony, abychom se později nemuseli zabývat, zda tyto základní funkce fungují, či nefungují, a případně je znovu předělávat či dodělávat. Bod č. 4: Proč se zde nezmiňuji o hře pro jednoho hráče? V misích pro jednoho hráče vždy záleží na autorovi mise, jak tento scénář nastaví, a kudy vlak pojede. Vlaková cesta bude tedy vždy řízena hráčem podle jeho požadavků. Problémy zde tedy defacto neexistují, jelikož jsou pohyby vlaku a textové zprávy pro hráče předem definovány, včetně povelů či návěstí pro hráčův vlak (může být samozřejmě uvedeno i pro jiné vlaky). Ve hře pro více hráčů je nejdříve potřeba analyzovat čtyři hlavní případy, kdy výpravčí či strojvedoucí může být hráč, bot nebo i jejich mix. Hráč i bot musí být schopen nastavit trasu vlaku, řídit vlak, či vzájemně mezi sebou komunikovat. Navíc chceme mít flexibilní algoritmus, abychom nemuseli připravovat trasy vlaků ručně pro všechny vlaky zvlášť (v současné době máme na serverech celkem více než 1000 vlaků za 24 hodin). Všechny změny, které bude moci provést hráč, musí být synchronizovány s celým serverem (to zahrnuje například směr jízdy vlaku či složení vlakové soupravy). Totéž platí pro bota výpravčího, který musí umět nastavit správnou a rozumnou trasu pro posun. Toto je však oblast zájmu jiného vývojáře, takže nechci mluvit za jiného vývojáře. Čím složitější je posun ve hře pro více hráčů, tím více a složitějších změn je potřeba v jejich logice. Proto jsme poskytnuli informace o tom, že ve hře pro více hráčů bude nejprve možné změnit směr jízdy vlaků pouze u vlaků vedených elektrickou jednotkou (EMU). Existují i další témata v naší úvaze: Co dělat v případě, kdy má jeden vlak velké zpoždění, nebo dokonce vykolejí, a pro další složení vlaku není dostatek vozů/jednotek? Nebo například nejhorší scénář - lokomotiva vykolejí při objíždění vozů. Jaká je optimální čekací doba mezi dvěma vlaky pro jedno vozidlo? Co s vlaky, které začínají či končí na hranicích mapy, bez možnosti přirozeného prodloužení mimo mapu? Jak moc složité posuny bude možné ve hře pro více hráčů provádět, aniž by se narušila hratelnost a plynulost jízdy ostatních vlaků při objíždění soupravy lokomotivou, výjezd/vjezd z/na vlečku, zapřáhnutí/odpřáhnutí vozidel? Toto není veškerý výčet komplikací, nicméně se o jedná problémy, kterými se stále zabýváme. Myslím si, že se všichni v týmu shodneme na tom, že Vám chceme dodat, co nejvíce různých možností a situací, ale pouze za předpokladu, že nebudou narušovat funkčnost hry. Proto Vám nebudu psát o našich, či mých vizí "co vše bychom mohli ještě udělat", protože je vždy lepší Vám poskytnout informace, až když je něco hotové a funkční. Nakonec tu máme ještě jeden vedlejší efekt celé výše vykonané práce na mechanismu - bude možné spawnout lokomotivu či jednotku obráceně, tedy, bude možné ovládat vlak z druhé kabiny.

Shunting - all the desired movement of rail vehicles and other activities except arriving, departing and passing of a train. Abstract - there is no information about when the patch with shunting is coming. This topic shows actual work progress. During last days I was working mainly on repairing bug and developing the game mechanics regarding shuntin (positions no. 1-3 below). This prompted me to write a bit about my thoughts in this topic and present work progress. It's like a sneak peak without screenshots 🙂 Shunting is a broad topic, it depends on few aspects, which can be done separately: 1) correct showing and setting of shunting signals at semaphores and correct interpretation of them 2) changing the direction of motion of a train/trainset forward and backward 3) issues wit connecting and disconnecting of trainsets, and the culmintation of those three parts is: 4) programming the mechanism of synchronization in multiplayer mode and train maneuvering plan. Ad 1. The posssibility of setting shunting singal are present in the game from the very beginning, but they are disabled on public servers - maybe some of you remember, what wahs happening during the playtests, when trains were sent to another stations with shunting signal. In singleplayer mode the shunting is working, they are present in a few missions. Regarding compliance with shunting signal by bots, a lot of bugs was fixed. They were preventing bots from stopping at some combinations of signals. Nowadays bots drive according to all signals correctly, redarding theiers actual driving mode. The same applies to the player, who has the same driving mode granted internally by the game. It means, that there is no problem with passing "shunting stop" signal with a timetabled train, but when one is shunting, the same signals are treated the same as SPAD (signal passed at danger). Ad 2. There was made a big step forward with driving back and forth. Bots and player are given correct informations about signal placed in front or in back of a train, depending on the direction of motion. It means, that some of the old missions, which included change of the direction of motion, should work properly now. There should not be problems with faulty signals and differences between what a driver sees in GUI and what a train does - the best example is the bug, when it was impossible to pass backward a signal. Ad 3. There were some internal problems connected with dividing and merging trainsets. For comparison - in MaSzyna* there is no trainset, every train is a set/collection of vehicles and more sophisticated functions are implemented in bot-driver algorithms. In SimRail every vehicle belongs to a trainset, what is very convenient for us (developers) but has main drawback - synchronization. The most interesting and enjoyable work with basic mechanic is done - one can disconnect from or connect to a trainset and drive with those carragies or wagons. Signals and GUI work properly in both directions (like in point no. 2), but there is a lot of work to do - tedious work of searching and testing for any bugs resulting from dynamic changing trainset for a vehicle - it's a lot of places. * For those, who are not Poles and are not familiar with it - MaSzyna is another polish, over 20 years old train simulator. Some of our staff was involved in developing it and it is very well known among polish railway enthusiasts. Summing up point no. 1-3, we can mark shunting as done if any of those situations can be simulated: 1) driving at shunting signal between two tracks at one stations or from a siding (e.g. going with elf from depot in Katowice to a platform), 2) changing of direction of motion (e.g. driving with regional train from Katowice to Sędziszów via Sosnowiec Gł.) 3) possibility of coupling or uncoupling vehicles from trainset (e.g. decoupling a locomotive from cargo train in Łazy or KWK Staszic), however we want the game physics and mechanic to be finished for all of these case and we don't want to wonder anymore, if the foundation works. Ad. 4. Why I'm not writing about singleplayer? Well, it depends only on the author of a mission, what will be done, how the trains will be routed. The main train will be always driven by a human player. It means, that it is not a problem with game engine - one has to write proper commands, radio texts for one train (or more, if one wants that for decorational trains too). In multiplayer, there are four cases to analyze, when a dispatcher and a driver can be human, bot or mix of them. Both a player and bot have to be capable of setting a route, driving a train and communicating with each other. Moreover, we want to have flexible, generic algorythm, that we won't be forced to prepare manually train routes for every of our over one thousand trains, which are simulated everyday on every server. All the changes which can be done by a player (direction, consists, trainsets) have to be synchronized with server. This is area of interenst of another developer, so I'm not speaking for him. The same applies to the bot-dispatcher, who has to able to set a resonable train route for shunting. The more difficult shunting in multiplayet, the more changes in logic. Therefore there were provided some informations, that in multiplayer the first case will by with changing direction of motion or a train with EMU. There are also another topics for our consideration: - what to do, if one train derails or delays and there is no railstock for next train? Worst scenario - locomotive derails when going around its carriages. - what is optimal time between trains for one vehicle? - what about trains, which start and finish within borders of our map without possibility of natural elongation out of the map? - how much complicated shunting operations can be done in multiplayer without breaking gameplay and flow of driving - going around of trainset with locomotive, going to siding, coupling/decoupling? These are not all, but the show the problems we have deal with. I think that everyone in team agrees that we want to deliver to you as much cases as possible, but only if they don't interfere with actual functions. So I'm even not writing about our or my visions titled "what more of shunting", because it is better to provide you informations if something is ready. Finally, there is a side effect of all the work done. It will be possible to spawn a locomotive or EMU reversed, so it will be possible to drive a train from second cab.

Rangieren ist das Bewegen von Fahrzeugen im Bahnbetrieb, ausgenommen das Fahren der Züge. Zusammenfassung - hier gibt es keine Informationen zum Release eines Updates. Das Thema soll lediglich einen Überblick über den aktuellen Entwicklungsstand geben. In den letzten Tagen war ich hauptsächlich damit beschäftigt, Fehler zu beheben und die Spielmechanik in Bezug auf das Rangieren im weitesten Sinne zu vervollständigen (Punkte 1-3, siehe unten). Aus diesem Grund habe ich beschlossen, ein paar Worte über meine Gedanken zu diesem Thema zu schreiben und ein Update über den Fortschritt zu geben. So ein kleiner Einblick ganz ohne Screenshots 🙂 Das Thema Rangieren ist insofern breit gefächert, als dass es auf mehreren Aspekten beruht, die getrennt voneinander umgesetzt werden können: 1) die korrekte Anzeige und Steuerung von Rangiersignalen und deren korrekte Interpretation, 2) Änderung der Fahrtrichtung eines Zuges oder einer Rangierfahrt, 3) An- und Abkuppeln von Zugverbänden, und die Krönung ist: 4) die Programmierung der besseren Synchronisation im Multiplayer und die Einführung eines Rangierplans. Punkt 1. Die Möglichkeit, Rangierfahrstraßen zu stellen, war von Anfang an im Spiel enthalten, wurde aber auf den öffentlichen Servern deaktiviert - einige von euch erinnern sich vielleicht an die Ereignisse in der Play-Test-Phase, in der Züge als Rangierfahrt auf die freie Strecke geschickt wurden. Im Einzelspielermodus funktionieren die Rangierfahrten und sind in mehreren Szenarien vorhanden. Was die Interpretation der Signale durch den Bot angeht, wurden mittlerweile verschiedene Fehler behoben, mit denen der Zug nicht richtig umgehen konnte. Der Bot wendet nun alle Signale, auf die er trifft, korrekt an und berücksichtigt dabei, ob er als Zug- oder Rangierfahrt unterwegs ist. Dasselbe gilt für den Spieler, bei dem ebenfalls unterschieden wird, ob er Zug- oder Rangierfahrt ist. So ist die Vorbeifahrt an einem W5-Signal (Rangierhalttafel) oder einem Rangiersignal mit einem Ms1-Signal (blau, Rangierhalt) für die Zugfahrt kein Problem, während sie für die Rangierfahrt dasselbe Ergebnis hat wie die Vorbeifahrt an einem haltzeigenden Signal S1. Punkt 2. Große Fortschritte wurden beim Thema Richtungswechsel gemacht. Sowohl der Bot als auch der Spieler erhalten nun korrekte Informationen über die Signale, die sich je nach Fahrtrichtung vor oder hinter dem Zug befinden. Daher sollten nun alle Szenarien, die vor längerer Zeit erstellt wurden und eine Richtungsänderung vorsehen, korrekt funktionieren. Es sollte keine Probleme mehr geben, die z.B. mit der Fehlinterpretation von Signalen und Unterschieden zwischen dem Verhalten eines Zuges und der Anzeige im HUD zusammenhängen - das beste Beispiel war ein Fehler, dass ein Signal, welches Fahrt zeigte, rückwärts nicht überfahren werden konnte. Punkt 3. In Bezug auf das Kuppeln und Entkuppeln von Fahrzeugen in einem Zugverband gab es einige interne Probleme zu lösen, wenn es darum ging, einen Zug in zwei zu teilen oder zwei Züge zu einem zu kombinieren. Im Vergleich dazu: In MaSzyna gibt es keine festen Zugverbände, jeder Zug ist eine Gruppe von Fahrzeugen, die relevanten Funktionen sind z. B. in den Algorithmen der Bots implementiert. In unserem System ist jedes Fahrzeug in einem Zugverband fest programmiert, was seine Vorteile hat, aber auch einen grundlegenden Nachteil - die Synchronisierung. Während die spannendste Arbeit mit der Basis abgeschlossen ist; man kann einen Zugverband trennen oder ihn ergänzen und die Signale und die Reaktionen darauf sind korrekt, gibt es hier immer noch viel zu tun. Es erfordert mühsame Tests auf der Suche nach den kleinsten Fehlern, die sich aus dem Wechseln eines Fahrzeugs zwischen Zugverbänden ergeben, und glaubt mir - es gibt eine Menge davon. Um die Punkte 1-3 zusammenzufassen, mit dem, was im Spiel möglich ist: 1) das Fahren als Rangierfahrt in einem Bahnhof, aus einer Gleisgruppe oder von Abstellgleisen ohne Richtungswechsel (z.B. ein Elf von den Abstellgleisen der KŚ an die Bahnsteige), 2) Richtungswechsel (z. B. Personenzug nach Sędziszów mit Richtungswechsel in Sosnowiec Główny), 3) die Möglichkeit, Fahrzeuge an den Zugverband zu kuppeln oder zu entkuppeln (z. B. Entkuppeln einer Lokomotive in Łazy oder Staszic). Wir wollen die Mechanik und Physik der Fahrzeuge und des Rangierens erst umfassend fertig haben, damit wir später nicht zurückgehen müssen, um uns zu fragen, ob das Grundprinzip so überhaupt funktioniert. Punkt 4. Nun - warum erwähne ich hier keinen Singleplayer? Weil es nur vom Szenarioersteller abhängt, was gefahren wird und die Fahrt immer von einem mehr oder weniger flexiblen Szenario menschlich gesteuert sein wird. Das Problem besteht also de facto nicht, denn es geht darum, für den Spielerzug (und ggf. Hindernisse und Deko-Züge) bestimmte Fahrten, Signale oder Befehle im Voraus zu programmieren. Für den Multiplayer sind vier Fälle zu berücksichtigen, in denen der Fahrdienstleiter und der Lokführer ein Mensch bzw. ein Bot sind. Jeder von ihnen muss in der Lage sein, eine Fahrstraße zu stellen oder eine Rangierfahrt durchzuführen und miteinander zu kommunizieren. Außerdem wollen wir prinzipiell einen Mechanismus, der universell genug ist, damit wir nicht für jeden der Tausenden von Zügen, die wir täglich auf jedem Server fahren, einen neuen oder geänderten Fahrplan erstellen müssen. Außerdem müssen alle vom Client befohlenen Änderungen (Richtungsänderung; spontane oder im Voraus festgelegte Änderungen im Zugverband) auf dem Server synchronisiert werden. Mit diesem Thema beschäftigt sich ein anderer Kollege, für den ich nicht sprechen werde. Ein ähnliches Thema ist der Bot auf dem Stellwerk, der in der Lage sein muss, eine sinnvolle Rangierfahrt zu machen. Je schwieriger die Rangierfahrten im Multiplayer werden, desto schwieriger wird auch die Logik. Daher wurde hier und da angekündigt, dass im Multiplayer zuerst das Wenden von Elektrotriebzügen umgesetzt wird. Zu den weiteren Fragen, die wir beantworten müssen, gehören zum Beispiel: - Was ist zu tun, wenn ein Zug außerplanmäßig nicht verkehrt (Verspätung oder Entgleisung)? Oder: Was ist mit einem Zugverband, dessen Lokomotive während des Umsetzens entgleist? - Wie lang sollen die Wendezeiten sein? - Was ist mit Zügen, die innerhalb der Grenzen unserer Karte beginnen und enden, ohne die Möglichkeit einer natürlichen Ausdehnung außerhalb der Karte? - Wie viel komplexere Manöver können wir uns im Multiplayer leisten, ohne den Spielspaß zu zerstören - das Umsetzen von Lokomotiven, das Fahren in Abstellgleise, das Kuppeln und Entkuppeln von Zugverbänden? Dies sind nur einige wenige Beispiele, die jedoch bereits eine Vorstellung davon vermitteln, was im Mehrspielermodus berücksichtigt werden muss. Ich denke, jeder im Team möchte Ihnen so viele Rangiermöglichkeiten wie möglich bieten, aber wir legen auch Wert darauf, die bereits vorhandenen Funktionen nicht zu verwässern. Deshalb schreibe ich auch nicht über unsere oder gar meine eigenen Visionen von "was könnten wir noch tun?“, denn es ist besser, es euch zu sagen, wenn wir bereit sind, einen bestimmten Teil auf die Server zu bringen. Zum Schluss noch eine Kleinigkeit: Wir werden als Nebeneffekt der oben genannten Mechaniken eine weitere Funktion einführen. Es wird möglich sein, Lokomotiven/Elektrotriebzüge rückwärts zu spawnen, d.h. zum Beispiel im Multiplayer oder in einem Szenario wird es möglich sein, eine Lokomotive mit Führerstand 2 voraus zu spawnen.

WERSJA POLSKA <- KLIKNIJ TUTAJ ENGLISH VERSION<- CLICK HERE DEUTSCHE VERSION <- KLICK HIER ČESKÁ VERZE <- KLIKNĚTE ZDE VERSION FRANÇAISE <- CLIQUEZ ICI

Manewry - wszelkie zamierzone ruchy pojazdów kolejowych oraz związane z nimi czynności na torach, z wyjątkiem wjazdu, wyjazdu i przejazdu pociągów. Streszczenie - nie ma tutaj informacji o dacie aktualizacji z manewrami. Temat przedstawia spojrzenie na aktualny postęp prac. W ostatnich dniach zajmowałem się w dużej mierze naprawą błędów i uzupełnieniem mechaniki gry w zakresie szeroko rozumianych manewrów (punkty 1-3 poniższej listy). Na tej podstawie postanowiłem napisać kilka słów o moich przemyśleniach w tym temacie i przekazać informacje o postępach. Taki sneak peak bez screenów 🙂 Temat manewrów jest o tyle szeroki, że opiera się o kilka aspektów, które mogą być realizowane oddzielnie: 1) prawidłowe wyświetlanie i sterowanie sygnałami manewrowymi na semaforach/sygnalizatorach oraz prawidłowa interpretacja takich sygnałów, 2) zmiana kierunku jazdy pociągu/składu manewrowego do przodu i do tyłu, 3) kwestie związane z łączeniem i rozłączaniem składów, natomiast zwieńczeniem tego jest: 4) zaprogramowanie mechanizmów synchronizacji w multiplayer i planu manewrów. Ad 1. Możliwości podawania sygnałów manewrowych są w grze od samego początku, natomiast zostały wyłączone na serwerach publicznych - być może część z Was pamięta, co się działo na etapie Play testów, gdzie pociągi były wysyłane na szlak manewrem. W trybie singleplayer manewry działają, są obecne w kilku misjach. W zakresie interpretacji sygnałów przez bota zostały usunięte różne błędy, które uniemożliwiały zakończenie jazdy przy niektórych kombinacjach sygnałów. Obecnie bot stosuje się do wszystkich napotkanych sygnałów prawidłowo z uwzględnieniem aktualnego trybu jazdy, w którym się znajduje, czyli jazdy pociągowej lub manewrowej. To samo dotyczy gracza, który też ma wewnętrznie przypisany tryb jazdy, w którym się znajduje. Dzięki temu przejechanie wskaźnika W5 (bochenek - koniec manewrów) lub tarczy manewrowej z sygnałem Ms1 (niebieski) nie jest problemem przy jeździe pociągiem, zaś przy manewrach będzie skutkowało tym samym, co przejechanie semafora wskazującego sygnał S1 (stój). Ad 2. W temacie jazdy do przodu i do tyłu zostały poczynione duże postępy. Zarówno bot jak i gracz otrzymują poprawne informacje o sygnałach znajdujących się i z przodu, i z tyłu pociągu zależnie od kierunku jazdy. W związku z tym wszelkie powstające już dawno temu misje, które były przygotowywane z myślą o zmianie kierunku jazdy, powinny działać prawidłowo. Nie powinno być już problemów związanych np. z nieprawidłowym interpretowaniem sygnałów i różnicami pomiędzy tym jak się zachowuje pociąg, a co jest wskazane w GUI - najlepszym przykładem był błąd, który uniemożliwiał przejechanie tyłem tarczy manewrowej/semafora wskazujących sygnał zezwalający. Ad 3. W kwestii łączenia i rozłączenia pojazdów w składzie pociągu było do rozwiązania kilka wewnętrznych problemów związanych z rozbiciem składu na dwa lub połączeniem dwóch w jeden. Dla porównania - w MaSzynie nie ma czegoś takiego jak skład, każdy pociąg jest zestawem pojazdów, a co ciekawsze funkcje są realizowane np. w algorytmach bota-maszynisty. U nas każdy pojazd jest częścią jakiegoś składu, co ma swoje wygodne plusy i podstawowy minus - synchronizację. O ile najciekawsze praca z podstawą jest zakończona - można się odłączyć od lub dołączyć do składu i z tymi wagonami jechać, a wskazania semaforów i reakcje na nie są poprawne, o tyle jest tu wciąż wiele do zrobienia - żmudnego przeszukiwania i testowania w poszukiwaniu najdrobniejszych błędów wynikających z dynamicznego przerzucania pojazdu między składami, a uwierzcie - jest tego sporo. Podsumowując punkty 1-3, o ile jako manewry moglibyśmy zaliczyć w zasadzie rozwiązanie któregokolwiek z powyższych aspektów: 1) jazda "na sygnał manewrowy" między torami na stacji, z grupy lub torów postojowych bez zmiany kierunku (np. wyjazd elfem z bazy KŚ w perony), 2) zmiana kierunku jazdy (np. jazda pociągiem osobowym do Sędziszowa ze zmianą czoła w Sosnowcu Głównym), 3) możliwość przyłączenia lub odłączenia pojazdów ze składu (np. odpięcie się lokomotywą w Łazach lub w Staszicu), o tyle mechanikę i fizykę w środku chcemy mieć gotową kompleksowo, aby nie wracać do tego tematu i nie zastanawiać się, czy podstawa działa. Ad. 4. Przewrotnie - dlaczego nie wspominam o singleplayerze tutaj? Bo to tylko od autora scenariusza zależy, co będzie wykonywane, a jeździć będzie zawsze człowiek sterowany przez mniej lub bardziej elastyczny scenariusz. Stąd problem de facto nie istnieje, bo to kwestia zaprogramowania konkretnych przebiegów i komend na radiu dla jednego pociągu gracza (i opcjonalnie przeszkadzajek i pociągów-dekoracji). W zakresie multiplayera są do rozpatrzenia cztery przypadki, w których dyżurnym i maszynistą jest odpowiednio człowiek i/lub bot. Każdy z nich musi być zdolny do układania przebiegu lub jazdy po drodze manewrowej i wzajemnej komunikacji. Co więcej, w zasadzie chcemy mechanizm na tyle uniwersalny, aby nie musieć przygotowywać z nowym lub zmienionym rozkładem jazdy rozpiski przebiegów dla każdego z tysiąca pociągów, które uruchamiamy codziennie na każdym serwerze. Oprócz tego wszelkie zmiany, którymi dowodzi klient-gracz (kierunek, zestawienie pociągu, zmiany składów) muszą być sychronizowane na serwerze. Temat raczej kolegi obok, za którego nie będę się wypowiadać. Podobnież kwestia ma się z botem na nastawni, które musi być w stanie sensownie podać przebieg manewrowy. Im trudniejsze manewry na multi, tym więcej zmian w logice. Stąd też zapowiadane były tu i ówdzie informacje, że na multi raczej pierwsze będą zmiany czoła przez EZT w ramach obiegu. Z innych rzeczy do rozwiązania, na które musimy sobie odpowiedzieć to np.: - co zrobić, gdy wypadnie pociąg z obiegu (spóźni się lub wykolei)? Co gorsza - co ze składem, którego lokomotywa wykolei się podczas oblotu? - jak długie mają być przejścia? - co z relacjami, które będą się zawierać wewnątrz mapy bez możliwości naturalnego przedłużenia? - na jak bardzo skomplikowane manewry możemy sobie pozwolić w multi - oblot lokomotywą, zjazd w tory postojowe, dzielenie/łączenie składów? To jedynie kilka z nich, natomiast już dają obraz tego, co trzeba wziąć pod uwagę w multiplayerze. Myślę, że każdy z zespołu chciałby dostarczyć Wam jak najwięcej możliwości manewrowania, ale też priorytetowo nie chcemy zepsuć już istniejących funkcji. Stąd też nie piszę o naszych czy nawet moich własnych wizjach pt. "co by tu jeszcze pomanewrować", bo lepiej poinformować o tym, gdy będziemy gotowi daną część wprowadzić na serwery. Na sam koniec jeszcze taka drobnostka. Przy okazji dostaniemy inną funkcję, która jest skutkiem ubocznym prawidłowego działania powyższych mechanik. Będzie możliwe spawnowanie tyłem lokomotyw/ezt, czyli np. w multiplayerze lub w misji można będzie ustawić lokomotywę do przodu kabiną 2 w wybranych relacjach.

It's not trivial in Unity (for me, but it's not my area of work), as Update function (once per frame) and FixedUpdate (step with const delta of time) are working in the same loop, but FixedUpdate is called from 0 to infinity times per frame to match the time between two frames. But maybe I will have a small surprise for you 🙂

Poprawiłem swoją wiadomość - 135A jest w pozycji naprzód I.

W pozycji naprzód II jest większe przyspieszenie (prąd rozruchu 175A), w pozycji naprzód I jest niższe przyspieszenie (prąd rozruchu 135A). Dodatkowo wzorując się na rozwiązaniach z rzeczywistości w EN71 wprowadziliśmy tryb górski - jazda w pozycji naprzód I jest tylko przy silnikach połączonych szeregowo (pozycja R jest "martwa"), ale za to można używać normalnie bocznikowania (B1-B3), co pozwala na lepsze możliwości sterowania jazdą w zakresie do 40-60 km/h.

Yep, framerate plays a role, because the most of moving range is smooth, so one click moves the lever for speed * deltaTime during one frame.

Fixed in our translation system.

Problem znalazłem - nie odblokowywał się przekaźnik rozrządu AWR w drugim silnikowym, bo był zatkany przewód główny do członu SB. Przy spawnie "na ciepło" (tak jak w multi) przewód główny w członie SB był napełniony i przekaźnik pozwalał na rozruch.

Nie, po uruchomieniu z obu szaf wystarczy już aktywować kabinę prowadzącą. Spojrzę na to. W drugim członie pantografy są podniesione (z kamery 2), co nie?

Czy na pewno sprawdzasz przyspieszenie w ustawieniu kierunku "naprzód II"? EN71 w ustawieniu "naprzód I" ma ustawioną konfigurację górską - jazda tylko na układzie połączeń szeregowym z bocznikami, bez jazdy równoległej. Czy uruchamiasz EN71 z obu członów silnikowych? De facto EN71 należy traktować jak dwa oddzielnie EN57 pozbawione członów rozrządczych pomiędzy. W takim przypadku jest możliwe, że druga połówka jest po prostu martwa i nie ciągnie.

It's side effect of fixing another bug. Partially fixed - waiting for soundtrack.

Do odblokowania przekaźnika nadmiarowego musisz ustawić kierunek na 0.

Nastawianie prędkości tempomatu w ED250 działa dokładnie tak samo jak w rzeczywistości - z tą różnicą, że nie trzeba potwierdzać prędkości naciśnięciem przycisku. Co do hamulca, rozważam usunięcie wyróżnionych pozycji pełnego hamowania ed i pierwszego stopnia hamowania pn - wtedy działanie byłoby płynne w całym zakresie hamowania służbowego, podobnie jak w EU07.

Poprawione