Virtuální železniční dílny - OR nastavení pro modely

Acatus

Provozní technik
Pomocí trakční charky se dají zachránit některé věci.
To sice ano, ale to by tu nesměli mařit tyto snahy teoretici bez znalostí praxe a brzdit tyto počiny.
Navíc je ta default křivka adheze nastavena moc strmě a dá se využít u některých mašin jen v části TCharky. Já ji mám u goril 003 a 015 využitu v rychlostech kolem 110 - 140 km/h, kde ovšem funguje spolehlivě. Zbytek je bohužel jen na znalosti hráče, kam až může klopit Ametry.
 

Josef Vogeltanz

Pomocník strojvedoucího
Bohužel bez upravené verze OR se nedá přesně nastavit adheze a jízdní odpory. To, co vyplivne paskvil Fcalc za Davis koeficienty, je mírně řečeno mimo realitu. Pomocí trakční charky se dají zachránit některé věci.
Pokud vůbec trakční charka je. Ale to není zrovna případ žabotlamy. Když se podívám do manuálu OR k tomuto problému, stále tam stojí (v překladu): "V současné době používají výpočty fyziky dieselových a elektrických lokomotiv výchozí fyziku motoru. Výchozí fyzika motoru jednoduše používá parametry MaxPower a MaxForce k určení tažné síly motoru, upravené pozicemi páky směru a kontroléru. Fyziku lokomotivy lze nahradit trakčními charakteristikami (rychlost v mps vs. síla v Newtonech), jak je popsáno níže."
Obrázek o tom, jak asi bude vypadat "výchozí fyzika" pro nepřebernou škálu vozidel, si může udělat každý sám.
A to nemluvím o skutečnosti, že se oficiálně kolem parametru ORTSTractionCharacteristics ve vývojářské komunitě ORTS stále mlčí. Není nikde uveden a všichni tváří jako by neexistoval.
 

Josef Vogeltanz

Pomocník strojvedoucího
To sice ano, ale to by tu nesměli mařit tyto snahy teoretici bez znalostí praxe a brzdit tyto počiny.
Navíc je ta default křivka adheze nastavena moc strmě a dá se využít u některých mašin jen v části TCharky. Já ji mám u goril 003 a 015 využitu v rychlostech kolem 110 - 140 km/h, kde ovšem funguje spolehlivě. Zbytek je bohužel jen na znalosti hráče, kam až může klopit Ametry.
Praxe čeho?
 

Icik

Pomocník strojvedoucího
Podívejte se například na adhezi kocoura 742. Podle výpočtu OR červená křivka je proti realitě zelená křivka úplně mimo. Pak se nemůžeme divit, že Josefovo ladění, ač dle správné Tcharky, se chová kocour jako pikovláček. Na rozjezd za sucha dáte plný knedlík a jdete na kafe. Fuj, nuda!
Pokud si ale jemně doladíte hodnoty a do kódu OR zanesete další pomocný koeficient, dostanete křivku přesně kopírující reálný průběh. To je panečku pak něco jiného a kocour je najednou pěkně divoký při neopatrném ovládání.
1.jpg
 

Josef Vogeltanz

Pomocník strojvedoucího
Takže problém je poněkud někde jinde než v trakčních charakteristikách. Problém je v aplikovaných mezích adheze a v jejich nesprávném výpočtu. Tohle téma je ve vývojové diskuzi ET připomínáno často. Bohužel s nějakým řešením tam zatím nikdo nepřišel.
Zelený průběh i odpovídá mezi adheze zakreslené do trakční charakteristiky
obrázek_2021-03-05_184156.jpeg
 

Icik

Pomocník strojvedoucího
A přitom tam Josefe stačí doplnit jednoduše pár řádků kódu. Ale vnucovat se jim nebudu. Takových minel mám napraveno celkem dost a zanedlouho i vydám svou verzi OR.
 

Josef Vogeltanz

Pomocník strojvedoucího
A přitom tam Josefe stačí doplnit jednoduše pár řádků kódu. Ale vnucovat se jim nebudu. Takových minel mám napraveno celkem dost a zanedlouho i vydám svou verzi OR.
Rusové šli stejnou cestou. Neměli prostě trpělivost se s vývojáři věčně dohadovat (a často i ignorovat jen proto, že jsou z východu).
Je obrovská škoda, že to není řešitelné jen pomocí scriptů jako jsou zabezpečovače. Byl to nakonec Dodo, kdo mě přesvědčil k jejich aplikaci (bohužel je taky jediný kabinář, který je používá). Připravené nastavení 363 od Pikka s novou kabinou od Doda již scriptů zabezpečovače používá.
 

Icik

Pomocník strojvedoucího
Chvíli se mi zdálo, že Jindra se svým ARR chce dělat takový most mezi neveřejnými úpravami a oficiální verzí OR, ale teď je nějak už dlouho klid.
 

Josef Vogeltanz

Pomocník strojvedoucího
Taky jeden z příkladů, kdy proklamovaná podpora zůstala jen u slibů. Pamatuji si na to, když tam funkci ARR oznámil.
 

Jindřich

Pokladník
Ahoj.
Ale no tak.. Momentálně probíhá implementace ARR jak do MG NY, tak do ofiko verze. Musíte vydržet.
Až to bude, navrhnu další změny. Zatím ode mě všechno berou, nebo vysvětlí, že už to někde je. A pokud to už někde je ale není dle mých představ, tak argumenty berou a úpravu kódu taky.
Co se týče trakce, tu mám v plánu komplet překopat. Ale jak říkám, musíte vyržet.
J.
 

paashi

Pokladník
Chlapci, zřejmě vám unikly souvislosti všech vlastností OR, ale není to vaše chyba, je to chyba dokumentace.

Ad adheze: Curtius-Kniffler je empirický vztah a používal se hlavně v našich zeměpisných šířkách. Tak jsem to tenkrát naprogramoval obecně, tedy na úroveň obecné hyperboly s tím, že koeficienty si můžete dát v ENGu jaké chcete. Klidně podle Kothera. Výsledek by měl odpovídat deklarovanému limitu z lokomotivy, pokud tedy sedí hmotnost lokomotivy a hlavně POKUD MÁTE NASTAVENOU NÁROČNOST NA 1.0!!!! Tenkrát mě ale málem ukamenovali, protože s nastavením MSTS se jim ty americké plečky nechtěly rozjet. Tak jsme tam dali tuhle fičuru, kde si můžete nastavit náročnost modelu adheze posuvníkem a naštěstí to zabralo a model adehze zůstal. Takže hodnota 1.0 odpovídá realitě (neuvažuje se ale součinitel využití adhezní tíhy, čemuž stejně málokdo rozumí).

Ad trakční charakteristiky - jsou tam a jsou k dispozici. Problém je v tom, jak je vytvořit pro loko se stupňovou regulací. Buď se najde dobrá duše, která je odečte z obrázku a zapíše do tabulky, anebo máme parametry trakčních motorů (nebo aspoň normálovou charakteristiku) parametry odporníků (trafa) a můžeme počítat. Má to ale dva háčky:
1) Kontrolér v ORTS je lineární a neumožňuje si "odskočit" na shunty.
2) Ampérmetr v ORTS neukazuje proud, ale normovanou tažnou sílu vynasobenou měřítkem cabu. Ve skutečnosti je ale síla produktem dvou proudů, kotevního a budícího. V celkové tažné síle taky není vidět zapojení trakčních motorů, takže zobrazované proudy budou odpovídat pouze jedné konfiguraci trakčního obvodu. S tím bohužel musíme žít.
 

Josef Vogeltanz

Pomocník strojvedoucího
Ahoj,
můžeš tu hodnotu 1.0 upřesnit? Faktor korekce adheze v nastavení OR má posuvník 10% až 200%. O amerických loko mě povídej :) Chvíli jsem se jim věnoval a byl jsem tou nízkou úrovní hodně překvapen a to i v koupeném komerčním balíčku, protože o solidní free modely nebo repainty je tam docela nouze ( o tratích nemluvě).
 

paashi

Pokladník
Ahoj,
můžeš tu hodnotu 1.0 upřesnit? Faktor korekce adheze v nastavení OR má posuvník 10% až 200%. O amerických loko mě povídej :) Chvíli jsem se jim věnoval a byl jsem tou nízkou úrovní hodně překvapen a to i v koupeném komerčním balíčku, protože o solidní free modely nebo repainty je tam docela nouze ( o tratích nemluvě).
Jo, 1.0 znamená 100%, tzn. koeficient adheze 0.33 bude 0.33. Když nastavíš 200%, bude to 2.0krát větší.
 

Josef Vogeltanz

Pomocník strojvedoucího
Aha. Ovšem souvislost jsem netušil. Těch 100% jsem začal používat, když jsem se dostal do obdobného (ale kultivovanějšího) sporu ohledně klouzání 742 (Jacek a Icík). Tehdy jsem těch 100% začal používat, abych měl jistotu, že nebude nic zkreslené a podmínky stejné. Stejně tak jako doporučuji v nastavení uvádět rychlost plnění brzdového potrubí 1000psi/s, abych OR donutil akceptovat hodnoty zapsané v parametru .engu.
Ale píšu hlavně proto, že všechna tato nastavení už nějakou dobu doporučuji zapsáním přímo do engu aby byla vidět při načtení vozidla OR:

obrázek_2021-03-07_150537.jpeg

Jestli to někdo akceptuje nebo, to už bohužel neovlivním.
 

Icik

Pomocník strojvedoucího
Zrovna dneska jsem upravoval kód v axle.cs, kde máš Paashi natvrdo zadáno CurtuisKnifflerA, B i C. To zapříčiňuje to, že uživatelsky nastavené hodnoty zohlední jen při nové hře, ale pokud dáš načíst pozici, máš nazpět natvrdo zadané hodnoty.
 

paashi

Pokladník
Zrovna dneska jsem upravoval kód v axle.cs, kde máš Paashi natvrdo zadáno CurtuisKnifflerA, B i C. To zapříčiňuje to, že uživatelsky nastavené hodnoty zohlední jen při nové hře, ale pokud dáš načíst pozici, máš nazpět natvrdo zadané hodnoty.
Good to know. To mi uniklo, ale je to už bratru pěkných pár let. To je na bug report.

Ještě jsem chtěl jednu věc: vozidlové odpory (vzorec pana Davise):
Předně je třeba si říct, na co to soudruzi potřebovali. Oni nechtěli simulovat jízdu vlaku. Oni si chtěli zjednodušit život a výpočty potřebné tažné síly (stanovení normativu, korefáky, atd.). Tenkrát jim přišlo rozumné určit tzv. měrné vozidlové odpory - empiricky zjištěné. Ale už kvůli komplexitě problému určili, že jakési zjednodušení bude dostačující. A tak tu máme předpis V7 s několika málo typy zátěže, přičemž např. T4 jsou ložené čtyřnápravové vozy v ucelené soupravě. Pro prázdnou ucelenou soupravu bude vzorec jiný. Proč? Protože tyto vzorce jsou stanoveny měřením buď prázdných, resp. ložených vozů a následně hodnoty sil jsou vydělené aktuální hmotností vozu, tedy hmotností prázdného, resp. loženého vozu.

V OR se z historických důvodů používá rozměr síly, ne měrného odporu. Samozřejmě při definici nikdo nepočítal s možností změny hmotnosti za běhu simulace. Nedá se ale tvrdit, že použití měrného odporu všechno vyřeší. Poměry tření se totiž se zatížením změní a nebude to lineární změna. Navíc, měrné odpory budete mít k dispozici jen jedny (pravděpodobně pro ložené, pro daný typ vozu).

Co se s hmotností často mění, je valivé tření. Naopak ve velkých rychlostech nejvýraznější tření o vzduch je závislé spíš na ploše a tvaru a na zatížení tedy nebude závislé (pokud se nákladem nezmění plocha a tvar). V podstatě z toho vyplývá, že obecně by každý vůz měl mít sadu vzorců pro různá zatížení.

Co to ale přinese? Valivé tření je na urovni 1 až 2 promile. Když vjedete do oblouku, přidají se řádově další 1 až 4 promile. V podstatě je jedno, jestli máte 1.2 nebo 1.5 promile, protože nejistota ostatních odporů je v podstatě na úrovni toho, co se snažíte dohnat. V rychlostech nad cca 30 km/h začíná převažovat tření o vzduch. Takže po správnosti bychom se měli bavit hlavně o tvaru vozu, ale zároveň i o řazení soupravy. Např. nevhodné řazení vozů různé stavby může zvýšit tření o vzduch i dvakrát. Strojvedoucí pamětníci asi potvrdí, že rychlík z "béček" v parném letním dni s otevřenými okny byl ve 120km/h na ampérmetru poznat.

Můj skromný názor: Bez urážky tvůrců FCalc - pro naše podnebí je vhodnější vzít vzorce pro měrný odpor, vynásobit M*g a dosadit koeficienty v Newtonech přímo do WAGu. Řešit náklad/nenáklad měrným vzorcem je dopuštění se stejné chyby jako u přeprogramování na měrný odpor, jen z druhé strany.

Celým tímto výlevem chci říct, že je to honba za svatým grálem. Pokud to chcete přesně, kupte si engine od Microsoft Flight Simulátoru, který údajně počítá obtékání vzduchu v reálném čase. Doprogramujte ložiskové tření závislé na teplotě ložiska, valivé tření kolo-kolejnice závislé na usazení kola na kolejnici a na deformaci obou, atd. Nemyslím si, že to bude zážitek.
 

Icik

Pomocník strojvedoucího
V naší verzi upravené fyziky OR pro určení jízdního odporu používám společně s kolegou Igorem Hízdo nové rozhodovací podmínky. Základ je Davisovo vzorec. Každý vůz může mít nadefinované v sekci wagon až 3 různé hodnoty odporu dle tíhy na nápravu, které se pak dynamicky účastní ve vzorci. Pokud se vůz naloží, tak dle toho se změní realtime ve hře jeho jízdní odpor. Samozřejmostí u nákladních vozů je přepínání režimu hráčem přímo ve hře prázdný - ložený a dle toho se volí brzdící váha vozu. Ta logicky ovlivní MaxBrakeForce. Každý vůz ji může mít nadefinovanou i pro režimy G, P a R. Ty zase ovlivní kromě MaxBrakeForce i časy plnění a vyprazdňování BV. Takže se dá celkem slušně sestavit nákladní vlak s některými vozy v G i v P.
 
Nahoře