Królik Uszasty

Według nie tak dawnych wytycznych obciążenie maksymalne dla EU07 wynosiło 2200 ton i tyle powinno się dać wyciągnąć z KWK Staszic do Sosnowca. Po linii 62 obciążenie max ok. 1500 ton (różni się na poszczególnych szlakach). Na sucho można próbować więcej, przy czym wyjazdy ze stacji mogą być dosyć toporne, zwłaszcza w deszczu.

Duplicate

Duplicate of invalid: Second locomotive on 424046 should be cold and off. The real problem is that bot should not rise pantograph. It is not game breaker, so it will be fixed in June, when I'll be back.

10 groszy to udział w kapitale zakładowym Spółki, który ma się z reguły gdzieś pomiędzy "nijak" a "totalnie nijak" do rzeczywistej wartości akcji/firmy. Akcje możesz próbować zakupić od jednego z właścicieli akcji, nie widziałem, żeby była notowana na giełdzie.

Można użyć, zwłaszcza w długim z hamulcem klockowym, bo ma duży pobór powietrza. W krótkich składach i przy hamulcu tarczowym nie ma takiej potrzeby. Inna sprawa, że lokomotywy trasie jak traxxa czy dragon same używają małej asymilacji w pozycji jazdy.

Przyspiesza wyluzowanie tylnej części składu pociagu poprzez podniesienie ciśnienia w przewodzie głównym (zwłaszcza w przedniej części) ponad standardowe 5 barów. Dzięki temu powietrze szybciej dopływa do ostatniego wagonu.

Błąd znany i zgłaszany, poprawka czeka na najbliższy bugfix.

Błąd znany i zgłaszany, poprawka czeka na najbliższy bugfix.

Żeby się nie powtarzać, odsyłam do swojej wcześniejszej odpowiedzi. Sytuacja się trochę zmieniła, ale w gruncie rzeczy jest to dalej aktualne.

To jest prawidłowe działanie lokomotyw EU07 typu 4E (niskie numery) z oryginalnymi obwodami sterowania. Lampka gaśnie dopiero po zamknięciu ostatniego stycznika oporowego, czyli na pozycjach bezoporowych.

Automatycznego palacza będzie można wyłączyć i sterować wszystkim samodzielnie. No i nawet najlepszy automat nie pomoże, gdy maszynista zabiera za dużo pary w czasie jazdy.

No. In EN57 and EN71 there is difference im motor current surfing acceleration (forward 1 is min. 135A, forward 2 is min. 175A). Additionally in SimRail EN71 has modification for driving on mountainous region with lower speed - in forward 1 there is no parallel connection, only series. Position R does nothing special, but shunting works in series connection. Normally it is impossible to do motor shunting in series connection in EN57.

Forward 2 is normal driving position. Forward 1 is special position - first motors in drive direction have weakened field for better traction in low adhesion condition.

ET22s don't work multitraction (only two of them were equipped with this connection for testing purposes).

Ad. 1. W przytoczonym przez Ciebie punkcie jest ładny obrazek, który pokazuje, że przejście jest jednak trochę płynne: --> obrazek <--. Generalnie obliczenia numeryczne nie lubią nieliniowości, a już tym bardziej, gdy coś zmienia się skokowo. Czasem trzeba różne rzeczy wygładzać, żeby obliczenia pozostały stabilne. De facto nie ma, wartości oporów ruchu są tarciem kinetycznym. Jednym z ciekawszych zagadnień w starszych wagonach z łożyskami ślizgowymi jest utrata poduszki smarnej (wyciskanie smaru) pomiędzy panewką i osią. Obecnie stosowane łożyska toczne są znacznie mniej podatne na to zjawisko. Ad 2. Każdy wagon ma oddzielną liczoną sprężystość sprzęgów, więc cały skład się spręża bądź rozpręża. Gdyby np. zahamować mocno lokomotywą, a nie składem, to ostatni wagon będzie sprężynować po zatrzymaniu.

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.