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.

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

Poprawione

Poprawione, ale wymaga jeszcze dodatkowych testów po naszej stronie.

Poprawione

To be clear: did you press "Both pantographs down" button again to deactive it?

Przy włączonym hamowaniu ED cylindry będą wyluzowane, żeby nie nakładała się siła hamowania z cylindrów i silników. Zachowanie jest najbardziej poprawne. Lokomotywa odczytuje ciśnienie w przewodzie hamulcowym i zamiast podawać ciśnienie do cylindrów, hamuje silnikami z odpowiednią mocą.

Zaciągnięcie hamulca pomocniczego w czasie jazdy będzie powodować hamowanie nagłe po 4 sekundach lub 700 metrach, zależnie od prędkości jazdy.

Nie zgadzam się. Na siódemkach nie ma takiej blokady, ona jest po stronie czysto elektrycznej. Takie coś występuje np. na ET22.

Wheel-slip condition is calculated individually per axle, including current load on that axle - which changes with tractive effort generated by a vehicle. The "problem" is a result of static adhesion factor, which is assumed as 0.35. To obtain about 75 kN/axle we need to increase it to 0.40. However, it seems to be a bit high value. The solution will come with "adhesion manager", which will be change adhesion factor for vehicles basing on the weather.

Have you used position "fill" before that braking? It looks like you have overpressured brakes in wagons and releasing brakes with "running" makes them not achieve proper pressure in brake pipe, which in that situation is above 5,0 bar. You can jut put brake lever in "fill" for about twenty seconds and then put it back to "running".