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

[Josef Vogeltanz]

Jak jsem avizoval včera, nakonec jsem přeci jen zanechal výmluv proč to nejde a pustil se do realizace.
Koupil jsem webhosting a doménu, s pomocí Wordpressu spáchal webové rozhraní a distribuci nastavení zkusím sám. Uvidíme, zda se zvolený model zveřejňování osvědčí. Web je strohý, nepovažuji se za žádného webmastera. Jeho význam vidím jinde než ve vzhledu.
Virtuální železniční dílny - dílny proto že (o)upravuji chování hotových modelů pro použití v Open Rails. Ne náhodou je název domény podobné slovu "vzdor".

Uvidíme, zda se tento model zveřejňování nastavení OR pro vozidla osvědčí. Dva dny jsem si s tím hrál, nahrál tam pár kousků, aby to na začátku nezelo prázdnotou. Další budu dodávat postupně. Je z čeho. Vynechány budou akorát vozidla, která jsem dělal pro někoho na zakázku a nebo jsou už někde s nastavením pro OR dostupná.

Funguje to tak, že vybraný model, který má již nastavení pro OR testuji na dostupnost na webu. Pokud je někde k mání, udělám jen balíček složený z .eng nebo .wag souboru (plus např. náklady, koncovky, stín, fíru atp.), obrázkový náhled. Pojmenování je po originálu. K tomu ještě u hnacích vozidel odkaz na použité zvuky a kabiny.
Pokud je už model z nějakých příčin nedostupný a býval veřejný, půjde balíček vč. modelu.
Protože nastavení dávám zcela volně k dispozici, obsahují balíčky kontrolní součty MD5 pro soubory .eng a .wag. Nevadí mě používání obsahu jinde a jinak, vadilo by mě případné spory o nefunkčnosti modifikovaných souborů.

 

[Dan J.]

Hned budeme zkúšať, jen si musím překopčit ty CALMITZ pro ČSD Uacs.

 

[Josef Vogeltanz]

No hrnu tam ten OR trainset od shora dolů a to je v TotalCommanderu abecedně. Cibuláky pro ČD a ČSD jsou ještě v původní variantě MSTS a čekají ve frontě. A ty máš ČSD Uacs se stejným provedením jako CALMITZ? Rozdíl tam velký nebude, ale přeci ...

 

[bob57_cz]

Virtuální železniční dílny

Pěkný počin.

 

[Howky]

Počin fajn, ale položím otázku do placu. Nebylo by lepší zavést Include soubory? Vím, že jsi psal, že se jim vyhýbáš. Ale pro tyhle úpravy by to bylo ideální řešení.

 

[Josef Vogeltanz]

Ahoj Howky. Jaký by byl důvod? Já se include úplně nevyhýbám. Použil jsem je např. u definic LED světel. Cpát do engu stovky řádek o světlech navic je zhovadilost. Stejně tak mě přijde mimo mísu dělat include soubor kvůli čtyřem řádkům kódu spřáhel. A navíc, potřebuji-li se v engu orientovat (např. při hledání chyb, vadí mě otvírat k tomu další soubory.
Nastavení pro OR píšu nová, od nuly. U těch, které zveřejňuji, měním akorát názvy ve shodě s orig. vydáním.

 

[Howky]

Přiznám se, že zatím používám ENG po staru . U těch Include se mě líbí, že když chceš dělat změny nemusíš každej ENG zvlášť předělávat. A u každého mašiny jej upravovat. Takto šáhneš do jednoho souboru a změní se to pro všechny mašiny Když jsi nakousl ty spřáhla, jasný zatím jsou to 4 řádky, do budoucna se to může změnit Ale nebudu ti tohle téma zasrávat a můžeme to probírat ve vlákně Include

 

[Dan J.]

Špatná cesta, zatím. Až bude editor aktivit podobný ALESPOŇ PODOBNÝ tomu v MSTS, tak pak to má význam. Zatím nestahuji ani vozy i Andreje, jsou nepoužitelné pro tvorbu, taksamo maďarské.

 

[Jacek]

Je to výborný počin. Zveřejnění mých zatím posledních upravených misí a zvuků pro OR předcházela několikaměsíční příprava na balíčku eng/wag souborů. Je to práce snad tří ladičů, ale žádný neměl snahu své dílo dát do nějaké použitelné veřejné podoby. Bohužel další nebyly. Kvůli jedné misi nebo pár zvukům trávit měsíce testováním, nekonečnou e-mailovou korespondencí, přípravou souborů. To se nedá.
Nicméně pro skutečnou použitelnost by bylo třeba, aby *.eng/wag byl v podsložce "Openrails" a v hlavní složce verze MSTS. Třeba původní, naprosto nevyladěný soubor. Jinak prostě takové vozidlo nestráví MSTS editor. I když teoreticky se to týká jen tvůrců misí. Když si pro tvorbu hodím ty soubory do podsložky a uživatel je bude mít v hlavní složce, bude mise fungovat, nebo ne?

 

[Venny]

Přeji Josefovi hodně elánu i trpělivosti do tak rozsáhlé práce.

 

[Acatus]

Nicméně pro skutečnou použitelnost by bylo třeba, aby *.eng/wag byl v podsložce "Openrails" a v hlavní složce verze MSTS. Třeba původní, naprosto nevyladěný soubor. Jinak prostě takové vozidlo nestráví MSTS editor. I když teoreticky se to týká jen tvůrců misí.

CVAK! Teď mi to docvaklo Jacku. Díky

Když si pro tvorbu hodím ty soubory do podsložky a uživatel je bude mít v hlavní složce, bude mise fungovat, nebo ne?

To by neměl být problém. Když je u vozidla podsložka OpenRails, OR si šahá nejdříve do ní. Když není podsložka, šahá po engu/wagu do hlavního adresáře vozidla.

 

[Josef Vogeltanz]

Ono to s tou OpenRails složkou není až tak jednoduché. Existují dvě možnosti:

1. Buďto je v tomto podadresáři celý kompletní soubor nastavení pro OpenRails. Musí mít identické jméno jako má soubor .eng nebo .wag v hlavní složce.
2. Druhou možností je mít v podsložce OpenRails soubor jen s parametry speciálně pro OpenRails. Soubor musí mít stejné jméno jako jeho "základ" v hlavní složce, tedy stejně jako v bodě 1. V tomto případě ale musí zůstat první řádek prázdný a za ním následuje parametr jako např: include ( ..//CSD_313433.eng ). Pozor neplést s include soubory, to je o něčem jiném.

Simulátor přednostně hledá ve podsložce OpenRails (je-li). Řídí se tím, co tam najde. pokud tam najde celý soubor nastavení a shoduje se jeho jméno s tím v nadřazené složce, použije jej celý. Pokud tam najde soubor stejného jména, ale zapsaný podle bodu 2, použije jen parametry zde uvedené a pro zbytek si jde do nadřazené složky.
Více v manuálu OR - 8.16 OR-Specific Include Files for Modifying MSTS File Parameters

Bohužel ani řešení popsané v bodech 1 a 2 není z hlediska chování modelu v simulaci ideální. Proč? Na to téma jsem dnes umístil článek na svém zánovním webu a je to o vzájemných vztazích nastavení simulátoru samotného vůči souboru s nastavením pouze pro OR nebo starým MSTS souborům. V podstatě je tam vysvětleno proč je lepší se držet nastavení modelů napsaných čistě pro OpenRails. I když vím, že si za to pochvalu od aktivitářů pracujících v MSTS Activity Editoru nevysloužím.

Byl bych rád, kdyby někdo potvrdil funkčnost bodu 1. Vlk (OR) by se nažral a koza (MSTS) by zůstala celá pro MSTS AE.

 

[Jacek]

No v podstatě ten bod 1 můžu potvrdit sám. Naposled jsem potřeboval pro vytvoření zvukového projektu pro model HO stvořit zvuky nejdříve pro Openrails a nahráním určitých sekvencí přímo ze hry pak vytvořit zvuk pro model. To vyžadovalo vyladění zkušebního vozidla dle chování modelu. Možná to pak někdy zveřejním a popíšu. Ve složce Openrails jsem vytvořil .eng se speciálním laděním a ovládáním modelu HO. Šlo o rozjezd z nuly na 100 km/h za 25 sekund a ovládání výkonu ve čtyřech stupních. Do hlavní složky jsem naklonoval .eng se stejným názvem souboru a názvy v něm. Editor MSTS vidí jen verzi MSTS s originálním laděním, OR otevře jen svůj soubor z podsložky.

 

[Acatus]

Tak Jacek byl rychlejší. Proto jen doplním ...Jak funguje OR při ad 1 si lze, myslím, lehce vyzkoušet. Připravím si tři nastavení engu nějaké lokomotivy.
První bude s laděním msts a ve stávajícím umístěním pro msts - poznám ho v testovací aktivitě jednoduše dle parametru MaxBrakeForce, který účelově ještě snížím na 20 kN.
Druhý eng vyladím pro OR (umístění v podsložce) s MBF např. 94kN.
Třetí eng pro OR (třeba varianta 2) s MBF 190 kN.
Rozdíly ve zkušební jízdě Lv snadno rozeznám při brzdění přídavnou. 1. eng nebude brzdit takřka vůbec, 2. reálně a 3. přehnaně.
Jednotlivé engy ve složce mezi testy prostřídám a poznám podle účinku brzdění, který si OR právě čte.

V podstatě je tam vysvětleno proč je lepší se držet nastavení modelů napsaných čistě pro OpenRails. I když vím, že si za to pochvalu od aktivitářů pracujících v MSTS Activity Editoru nevysloužím.

Celou dobu funguji na bod 1. Zatím jsem nezaznamenal problém s podadresáři OpenRails ve složkách vozidel msts, ale kdyby to mělo dopadnout tak, že se přejde na výhradní OR nastavení v trainsetech, tak se dá stále aktivita v msts editoru postavit na trainset msts s podsložkami OR a hrát na ten čistě OR. Zabere to u aktivitářů jen dalších 1X giga na disku a snad to nebude až taková překážka (ve vztahu na vzájemné vztahy msts - OR nastavení), aby mise takto nešla postavit.

 

[Acatus]

P. Josefe, komunito ladičů a testovačů,
na stránkách VŽD to žije novými engy, za což za sebe moc děkuji. Nestíhám chladit fantazii s nápady na mise
Měl jsem chvilku ze zvědavosti testnout první elloko a měl bych pár, doufám nekonfliktních, poznatků:
U 121.006 od Pikka jsem si musel přepsat WagonShape zpět na ( cd121_006.s ), nicméně než se tak stalo, tak jsem našel fíru někde na pozici stanoviště u žehličky... viz otisk



To jiskření u sběrače je dobrá vychytávka. U mne zatím jiskří jen nad zadním sběračem bez ohledu, jestli jedu na přední či na zadní, a to ikdyž ten zadní stáhnu. Možná to chce vytahovat prvně ten, na který chci jet, čímž se volba třeba aktivuje. Nevím. Ověřím.

A dotazem do placu je pak parametr MaxCurrent jestli by nevyšel ve výsledku pro zobrazování proudů a celou dynamiku trakce lépe na hodnotě např. (1160A)?? než je tam těch ( 1660A ). Když ji "krmím" na 600 - 700 A (podle budíků), tak to na těch 1660 jede jakoby na jednu Mskupinu a pro trochu výkonu ji musím hnát "za strop" Ametrů. Když zadám parametr 1160 A, tak se na 600 A zvuk převodovek a loko krásně s pěti vozy osobky rozbíhá... Připadne mi ta trakce takto s těmi 5 vozy více reál. Kdyžtak to někdo z fírů testněte, než dosatnu vyhubováno S nákladem ověřím později.

Co se týká trakční charky, tak u V max výkon jen v serioparalelu. Nelze udržovat výkon po skrokování např. na seriový hospodár. To je pls nějaký záměr?

Byl bych rád, kdyby někdo potvrdil funkčnost bodu 1. Vlk (OR) by se nažral a koza (MSTS) by zůstala celá pro MSTS AE.

Msts editor nemá potíže s tím, když je v hlavním adresáři přímo eng či wag OR. Podsložka OpenRails proto nemá opodstatnění, pakliže někdo nejezdí i msts. Vadí mu (editoru) ale zjevně model s DDS texturami.

 

[Josef Vogeltanz]

Jo, chybička se vloudila. Pikkovy modely nepoužívají prefix CD_ , kdežto já jej ve svém trainsetu umíněně používám. U zpětných úprav (zmiňuji dnes v jiném vlákně) se snažím přizpůsobit provedením názvů u originálu. Zde jsem skočil na špek, protože modely výjimečně ten prefix mají i v originálu. Ale koukal jsem teď na tu sestavu, fíra je umístěn dobře.
Parametr MaxCurrent v případě OpenRails, reprezentuje max. vyprodukovatelný proud lokomotivou. Což v praxi stanovuji hodinovým proudem jednoho trakčáku. A protože při sérioparalelu jsou po dvou ve dvou skupinách, dělá to dvojnásobek hodinového proudu trakčáku. Např. při 800A hod. proudu to bude 1600A celkově. Měl by se do toho správně započítat i proudový odběr pomocných pohonů. V některých zdrojích technických dat se uvádí i hodinový výkon loko v kW. Potom je jednoduché celkový hodinový proud spočítat z tohoto.
Ovšem na hodnotu MaxCurrent by měly být zkalibrovány i rozsahy ampérmetrů v kabinách. U sebe to opravuji, ale teď mě napadá že častěji na kabinu odkazuji. A tam úprava nemusí být.
Ale dobrá připomínka. Budu to muset ohlídat.
K dotazu na trakční charakteristiku: Lokomotiva má trvalou rychlost 46,5 km/h, hodinovou 44 km/h a max. 90 km/h. Tomu odpovídá dle grafu trakčních charakteristik tažná síla u série okolo 28 kN a u sérioparalelu okolo 150 kN (odečteno na 45 km/h). Sériový hospodár prostě tu sílu nemá, ani mít nemůže. Motory jdou na poloviční svorkové napětí a tím pádem i na poloviční výkon.

 

[bob57_cz]

Sériový hospodár prostě tu sílu nemá, ani mít nemůže. Motory jdou na poloviční svorkové napětí a tím pádem i na poloviční výkon.

Sériový hospodár tu sílu má také a to při poloviční rychlosti oproti paralelu.
Pokud při jízdě na hospodárný paralel sjedu s kontrolerem na seriový hospodár, tak při stejné rychlosti nebude výkon poloviční, ale bude čtvrtinový.
To je prostě fyzika.

Měl by se do toho správně započítat i proudový odběr pomocných pohonů

V žádném případě se do hodnot trvalého a hodinového proudu nezapočítávají proudy pomocných pohonů. Jsou to hodnoty trakčního výkonu a vycházejí jasně z normálových charakteristik. Vždy jsou uváděny proudy kotevní, pokud se bavíme o stejnosměrném seriovém motoru (případně cize buzeném s uměle vnášenou charakteristikou seriového stroje).

 

[Josef Vogeltanz]

To je spíše otázka, zda je ze strany OR vyžadován max. proudový odběr celkový a nebo trakční. A protože to potřebuje pro kalkulaci trakce a požadavek není nijak blíže specifikován (nebo nedokonale přeložen z AJ), bude platit to druhé. Ostatně ampérmetry na pultu měří proud motorové skupiny, motory ventilátoru chlazení v tom nejsou.

 

[bob57_cz]

Ostatně ampérmetry na pultu měří proud motorové skupiny, motory ventilátoru chlazení v tom nejsou.

Samozřejmě. Pomocné pohony mají vlastní měřák. Vždyť píšu, že se počítá jen trakce. Ani v OR to nebude jinak než u všech ostatních simulátorů.

 

[Josef Vogeltanz]

Už to mám vymyšlené (ehm, vymyslel už dříve Pikku). Do složky s modelem přidat podsložku CabView a do ní .cvf příslušné kabiny. Odkazy na textury potom vedou do původní společné složky common.cab a podsložky původní kabiny. Protože je kabin málo a sdílí je množství různých modelů, bude tak možno upravit "na míru" nastavení kabiny (bude-li to vůbec nutné). Třeba právě rozsahem ampérmetrů, aby vyhověly konkrétnímu typu lokomotivy.
Výhodou je, že se nijak nezasahuje do originálního .cvf souboru.