Króliczy pamiętnik - manewry

[Królik Uszasty]

 

WERSJA POLSKA <- KLIKNIJ TUTAJ

ENGLISH VERSION<- CLICK HERE

DEUTSCHE VERSION <- KLICK HIER

ČESKÁ VERZE <- KLIKNĚTE ZDE

VERSION FRANÇAISE <- CLIQUEZ ICI

 

[Królik Uszasty]

 

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.

 

 

[Królik Uszasty]

 

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.

 

 

[Królik Uszasty]

 

 

 

 

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.

 

 

[Królik Uszasty]

 

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é:

1. Správné zobrazení a nastavení návěstidel pro posun a jejich správná interpretace
2. Změna směru jízdy vlaku či soupravy, jízda vpřed a vzad
3. Spojování a rozpojování vlakových souprav
4. 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:

1. 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),
2. 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),
3. 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.

 

[RealMiko]

 

 

 

 

Manœuvrer est le fait de déplacer des véhicules dans le cadre de l'exploitation ferroviaire, à l'exception de la conduite des trains.

 

Résumé - il n'y a pas ici d'informations sur la sortie d'une mise à jour. Le sujet doit simplement donner un aperçu de l'état actuel du développement.

Ces derniers jours, j'ai surtout été occupé à corriger des bugs et à compléter la mécanique du jeu en ce qui concerne les manœuvres au sens large (points 1-3, voir ci-dessous). C'est pourquoi j'ai décidé d'écrire quelques mots sur mes réflexions à ce sujet et de faire une mise à jour sur les progrès réalisés. Voici donc un petit aperçu sans aucune capture d'écran 🙂

Le thème de la manœuvre est vaste dans la mesure où il repose sur plusieurs aspects qui peuvent être mis en œuvre séparément :

    1) L'affichage et la gestion correcte des signaux de manœuvre et leur interprétation correcte,

    2) La modification du sens de marche d'un train ou d'une manœuvre,

    3) L'attelage et le dételage de convois, et, pour couronner le tout, :

    4) La programmation d'une meilleure synchronisation en multijoueur et l'introduction d'un plan de manœuvre.

Point 1.

La possibilité de mettre en place des routes de manœuvre était présente dans le jeu dès le début, mais elle a été désactivée sur les serveurs publics - certains d'entre vous se souviennent peut-être des événements de la phase de play-test, où des trains étaient envoyés en route libre en tant que route de manœuvre. En mode solo, les manœuvres fonctionnent et sont présentes dans plusieurs scénarios. En ce qui concerne l'interprétation des signaux par le bot, plusieurs erreurs que le train ne pouvait pas gérer correctement ont entre-temps été corrigées. Le bot applique désormais correctement tous les signaux qu'il rencontre, en tenant compte du fait qu'il est en train ou en manœuvre. Il en va de même pour le joueur, pour lequel une distinction est également faite selon qu'il est train ou manœuvre. Ainsi, le passage d'un signal W5 (panneau d'arrêt de manœuvre) ou d'un signal de manœuvre avec un signal Ms1 (bleu, arrêt de manœuvre) ne pose pas de problème pour le train, alors qu'il a le même résultat pour la manœuvre que le passage d'un signal S1 indiquant l'arrêt.

Point 2.

De grands progrès ont été réalisés en matière de changement de direction. Le bot et le joueur reçoivent désormais des informations correctes sur les signaux qui se trouvent devant ou derrière le train, en fonction du sens de circulation. Par conséquent, tous les scénarios qui ont été créés il y a longtemps et qui prévoient un changement de direction devraient désormais fonctionner correctement. Il ne devrait plus y avoir de problèmes liés par exemple à une mauvaise interprétation des signaux et à des différences entre le comportement d'un train et ce qui est affiché dans le HUD - le meilleur exemple étant une erreur selon laquelle un signal indiquant la marche ne pouvait pas être franchi en marche arrière.

Point 3.

En ce qui concerne l'attelage et le dételage de véhicules dans un train, il y avait quelques problèmes internes à résoudre lorsqu'il s'agissait de diviser un train en deux ou de combiner deux trains en un seul. A titre de comparaison : Dans MaSzyna, il n'y a pas de convois fixes, chaque train est un groupe de véhicules, les fonctions pertinentes sont par exemple implémentées dans les algorithmes des bots. Dans notre système, chaque véhicule d'une formation de train est programmé de manière fixe, ce qui a ses avantages, mais aussi un inconvénient fondamental - la synchronisation. Alors que le travail le plus passionnant est terminé avec la base ; on peut séparer une formation de train ou la compléter et les signaux et les réactions à ceux-ci sont corrects, il y a encore beaucoup à faire ici. Cela nécessite des tests fastidieux à la recherche des moindres erreurs résultant du passage d'un véhicule d'une formation de train à une autre, et croyez-moi, il y en a beaucoup.

Pour résumer les points 1 à 3, avec ce qui est possible dans le jeu :       

1) La conduite en tant que manœuvre dans une gare, à partir d'un groupe de voies ou de voies de garage sans changement de direction (par exemple, un elfe des voies de garage de KŚ vers les quais),

2) Le changement de direction (par exemple, train de voyageurs à destination de Sędziszów avec changement de direction à Sosnowiec Główny),

3) La possibilité d'atteler ou de dételer des véhicules au convoi (par exemple, dételer une locomotive à Łazy ou Staszic).

Nous voulons d'abord avoir terminé la mécanique et la physique des véhicules et des manœuvres de manière globale, afin de ne pas devoir revenir en arrière plus tard pour se demander si le principe de base fonctionne vraiment ainsi.

Point 4.

Eh bien - pourquoi je ne mentionne pas de jeu en solo ici ? Parce que ce qui est conduit ne dépend que du créateur du scénario et que le trajet sera toujours contrôlé humainement par un scénario plus ou moins flexible. Le problème n'existe donc pas de facto, puisqu'il s'agit de programmer à l'avance certains déplacements, signaux ou ordres pour le train du joueur (et éventuellement les obstacles et les trains de décoration).

Pour le multijoueur, quatre cas de figure sont à envisager, dans lesquels le régulateur et le conducteur de train sont respectivement un humain et un bot. Chacun d'entre eux doit être en mesure d'établir une route ou d'effectuer une manœuvre et de communiquer avec l'autre. En outre, nous voulons en principe un mécanisme suffisamment universel pour ne pas devoir créer un horaire nouveau ou modifié pour chacun des milliers de trains que nous faisons circuler chaque jour sur chaque serveur.

En outre, toutes les modifications commandées par le client (changement de direction ; modifications spontanées ou prédéfinies de la composition des trains) doivent être synchronisées sur le serveur. Ce sujet est traité par un autre collègue, pour lequel je ne m'exprimerai pas. Un sujet similaire est le bot sur le poste d'aiguillage, qui doit être en mesure d'effectuer une manœuvre raisonnable. Plus les manœuvres en multijoueur sont difficiles, plus la logique l'est aussi. C'est pourquoi il a été annoncé ici et là que le retournement des trains automoteurs électriques serait mis en œuvre en premier dans le multijoueur.

Parmi les autres questions auxquelles nous devons répondre, il y a par exemple :

 - Que faire si un train ne circule pas comme prévu (retard ou déraillement) ? Ou encore : que faire d'un train dont la locomotive déraille pendant le changement de train ?

- Quelle doit être la durée des temps de retournement ?

- Qu'en est-il des trains qui commencent et finissent à l'intérieur des limites de notre carte, sans possibilité d'extension naturelle en dehors de la carte ?

- Combien de manœuvres plus complexes pouvons-nous nous permettre en multijoueur sans détruire le plaisir du jeu - le déplacement de locomotives, la conduite sur des voies de garage, l'attelage et le dételage de convois de trains ?

Ce ne sont que quelques exemples, mais ils donnent déjà une idée de ce qui doit être pris en compte dans le mode multijoueur. Je pense que tout le monde dans l'équipe souhaite vous offrir autant de possibilités de classement que possible, mais nous tenons également à ne pas diluer les fonctions déjà existantes. C'est pourquoi je n'écris pas sur notre vision, ni même sur la mienne, de "que pourrions-nous faire de plus ?", car il est préférable de vous le dire lorsque nous serons prêts à mettre en place une partie spécifique sur les serveurs.

Pour finir, un petit détail : nous allons introduire une autre fonction comme effet secondaire des mécaniques mentionnées ci-dessus. Il sera possible de spawner des locomotives/trains électriques à l'envers, c'est-à-dire que par exemple en multijoueur ou dans un scénario, il sera possible de spawner une locomotive avec la cabine de conduite 2 en avant.