Pomógł: 8 razy Wiek: 29 Dołączył: 18 Sie 2009 Posty: 128 Skąd: Wyszków
Wysłany: 28-12-2025, 20:55 Loki zmieniające priorytet przy poleceniach jazdy AI
Dobry.
W tym wątku chciałbym zwrócić uwagę na problem, o którym wspomniałem w wątku o sygnalizacji v5. Zaobserwowałem to, gdy próbowałem wykonać sesję z jazdami manewrowymi AI. Zarówno na TRS 2019 i TRS 2022. @Luki_tram wspominał mi również, że chyba widział podobne zjawisko również w TANE.
Przykładem są Tamary by newlacil albo SM42 wujkowa (również te po ostatniej aktualizacji na DLS). Ustawiam priorytet 3, czy to z menu, czy komendą zmieniającą priorytet. Następnie przy użyciu wbudowanych poleceń jazdy: Jedź / Jedź do znacznika, czy innych Autopilot / Autoprowadzenie w momencie ruszenia i mrugnięcia reflektorami, gdy sprawdzam właściwości loka priorytet znowu jest ustawiony na 2, co uniemożliwia jeżdżenie na tarczę itp. manewry. Sygnalizacja również wtedy reaguje na zmieniony priorytet.
Drugim podobnym, ale mniej upierdliwym przypadkiem są skrypty przykładowo w lokomotywach S-200 lub CTL 182 160-2.
Różnica polega na tym, że tutaj odkryłem dodatkowy myk. Kiedy anuluję polecenie jazdy, które priorytet zmieniło na 2, kliknę "Zmień kierunek" i ponownie użyję komendy ustawienia priorytetu na 3, to następne użycie np. Autodrive już nie zmienia priorytetu. Opcja zmiany kierunku okazuje się wtedy operacją naprawczą.
Sprawdziłem to na wbudowanym taborze: jakieś loki z USA, jakiś VT628 z DLS i takich problemów nie ma.
Jeśli potrzeba mogę nagrać, jak to mniej więcej wygląda.
_________________ Pasjonaci nieczynnej linii kolejowej Auranowice Kebab - Biała Pendolińska pełodegie.
Pomógł: 8 razy Wiek: 29 Dołączył: 18 Sie 2009 Posty: 128 Skąd: Wyszków
Wysłany: 29-12-2025, 12:46
Witam ponownie.
Wygląda na to, że przynajmniej na szybko udało mi się znaleźć rozwiązanie tego problemu.
Wystarczy zmienić dosłownie jedną cyferkę w linijce kodu, którego fragment zamieszczam poniżej.
Pod void Controls (jest to gdzieś około 700 / 900-tnej linijce kodu mamy taki fragment:
To akurat fragment skryptu z SM42 wujka.
Wewnątrz .SetTrainPriorityNumber(2); zmieniłem na .SetTrainPriorityNumber(3);
Priorytet przestał zmieniać się automatycznie. Po kilku testach ze zmianami kierunku, priorytetu z komend wygląda na to, że działa. Zmieniłem tę cyferkę w rada182.gs również z sukcesem.
Dajcie znać, jak sprawuje się to u was.
Pozdrawiam.
_________________ Pasjonaci nieczynnej linii kolejowej Auranowice Kebab - Biała Pendolińska pełodegie.
Ostatnio zmieniony przez Sebek07 29-12-2025, 13:53, w całości zmieniany 2 razy
Pomógł: 105 razy Wiek: 41 Dołączył: 19 Lut 2008 Posty: 5344 Skąd: Warszawa
Wysłany: 31-12-2025, 00:51
Zrobienie sobie prywatnie korekty w 5 czy 10 modelach... to można sobie wyobrazić. Natomiast jest bardziej zasadnicze pytanie : czy zgłoszony w tym wątku problem oznacza, że wszyscy użytkownicy oficjalnie dostępnej wersji tych modeli w TS19 i TS22 mają ten problem? Bo jeżeli tak, to z uwagi na liczbę "trafionych" modeli lokomotyw (chłodno oceniam że to będzie spod grubego palca ze 300 modeli albo lepiej), logistyka poprawki jawi się jako zadanie graniczące z cudem... i wówczas pojawia się pytanie - czy jest jakakolwiek inna, systemowa metoda żeby ten problem rozwiązać?
No cóż. Biblioteka skryptów. Na przykładzie sygnalizy - kangury coś popsuły i wystarczyła aktualizacja jednego dodatku, żeby to naprawić.
A akurat Twoje loki są o tyle łatwe do przerzucenia na library, że te skrypty w zasadzie są identyczne, różnią się detalami typu ilość drzwi do kabin. Biblioteki są gotowe, działające a dopracować to tak, żeby nie trzeba było robić jakichś strasznych przeróbek w configach - da się zrobić.
Pomógł: 105 razy Wiek: 41 Dołączył: 19 Lut 2008 Posty: 5344 Skąd: Warszawa
Wysłany: 31-12-2025, 11:48
Radek, nie zupełnie o to mi chodzi (i sprawa zdaje się dotyczy nie tylko moich modeli na Twoich młodszych skryptach - to będzie też dotyczyć też starszego skryptu vsc oraz skryptów w rodzine ST43, T448p, S000, TEM2, ET21, SM41, SM42, SP42, SU42 oraz być może kilka innych; ...co z parowozami?)
Ja problemu spodziewam się gdzie indziej - mam na myśli logistykę i czasochłonność. Moje pytanie to tak naprawdę ciąg pytań z których jedno wynika z drugiego i dopiero kolejne obrazują pełną skalę problemu:
-Czy zgłoszony w tym wątku problem oznacza "trafienie" praktycznie wszystkich naszych lomomotyw w TS19 i TS222 wzwyż?
-Czy chęć naprawy tego oznacza koniecznośc manualnej ingerencji w plik skryptu w każdym modelu? (jeżeli tak, sprawa dotyczy na oko 300 albo lepiej modeli lokomotyw).
-Jeżeli odpowiedź na dwa powyższe pytania jest twierdząca, zachodzi kluczowe pytanie: kto miałby to zrobić, z pełną świadomością jakiej skali jest to przedsięwzięcie? Żeby doprecyzować, taka drobna popraweczka oznacza, że trzeba otworzyć ponad 300 modeli, świadomie rozpoznać różne warianty skryptu dla różnych typów, świadomie wprowadzić poprawki, opanować bezbłędnie korekty numerów kuid2, wgrać 300 modeli z kont różnych (nie zawsze dostępnych) autorów na DLS, wgrać 300 skorygowanych modeli na Trainzart, poprawić opisy 300 modeli na Trainzart. Żeby mniej więcej zarysować jaka jest skala problemu: przeciętna aktualizacja modeli na Trainzart obejmująca tego rodzaju korekty zajmuje kilka godzin w przypadku 10-15 modeli, można sobie więc wyobrazić o jakim przedsięwzięciu mowa mając na uwadze liczbę "trafionych" modeli (i w tym czasie ta osoba nie zrobi nic innego - czyli przez kilka tygodni albo miesięcy ta osoba nie będzie zajmować się niczym innym, robiąc to w całym swoim wolnym czasie). Z tego powodu dostrzegam tu poważny problem natury logistycznej.
I stąd moje pytanie: co z tym można zrobić, ale z dyskretną prośbą o wyjaśnienie krok po kroku konsekwencji i indywidualnego zakresu angażu osób których udział jest niezbędny.
Niestety odpowiedź na oba pytania jest twierdząca. I chyba nie ma innej metody, niż żmudne poprawianie tych 300 czy nawet więcej modeli jeden po drugim. I tak, łącznie z wgrywaniem na serwery itd. Niestety poza moją wiedzą pozostaje "kto".
Niestety systemowej poprawki nie ma, można to ewentualnie olać, ale chyba nie tędy droga.
Dlatego (jako rozwiązanie przyszłościowe) przywołałem temat biblioteki - teraz zrobić to raz, a dobrze, a potem nie martwić się 300 lokami tylko jednym dodatkiem. Biblioteka bazuje na "moich skryptach", które są pochodną skryptu vsc i jemu podobnych - to jest ta sama "rodzina". Trochę ulepszona, ale dalej to samo "jądro", czyli wszystkie funkcjonalności. W tym wypadku mogę pomóc z przeróbką. Przynajmniej przyszłościowe poprawki będą już bezbolesne.
Pomógł: 28 razy Wiek: 50 Dołączył: 05 Mar 2018 Posty: 375 Skąd: Kraków
Wysłany: 31-12-2025, 20:44
[quote]-Czy chęć naprawy tego oznacza koniecznośc manualnej ingerencji w plik skryptu w każdym modelu? (jeżeli tak, sprawa dotyczy na oko 300 albo lepiej modeli lokomotyw). [quote]
Wątek w istocie traktuje o problemie stanowiącym cenę wskazanej już ręcznej poprawki skryptu zapobiegającej wywracaniu się trawnika na polskich lokomotywach. Po poprawce gra się nie wywala, ale dotychczas ceną za to był fakt, że lokomotywy po poprawce "nie trzymają" priorytetu 3 przy ruszaniu z postoju w trybie AI. Dlatego też wielkie dzięki autorowi wątku za dostrzeżenie rozwiązania i podjęcie skutecznej próby naprawy tej sytuacji.
Przeczytawszy ostatnie wpisy, spróbowałem doświadczalnie sprawdzić na własnym terenie, jak takie przedsięwzięcie polegające na wprowadzeniu poprawki skryptu mogłoby wyglądać od strony logistyki, a ściślej, czasochłonności. Jako króliki doświadczalne wystąpiły lokomotywy SM42 typu 6D, 6Dg i 6Dk, jako największa grupa lokomotyw manewrowych. U mnie jest to łącznie około 90 modeli. Z tego zbioru wyłączyłem wersje ADHD, które, nota bene, pracują na bibliotece skryptów i to ułatwiałoby ich poprawkę, ale ponieważ konsekwencją tego jest fakt, że nie mają one skryptu w folderze dodatku, tylko w zewnętrznej bibliotece, na razie odpuściłem sobie szukanie go tam.
W odniesieniu do pozostałych, stwierdziłem, że SM42 6D pracują na trzech skryptach: sm42.gs - większość istniejących repaintów na modelu Wujka082,
lsc.gs - znacznie mniejsza grupa, oraz
sm42.gse - tylko stare modele SirM-a i ich repainty. Skrypt jest kodowany i z tego powodu nie do ruszenia bez znacznej ingerencji w modele.
Pozostałe, tj. turbostonki 6Dg na modelu Xsonera z wyjątkiem 6Dg-33 Koltaru, która ma skrypt dg6.gs (wyglądający jednak, jakby tylko nazwa została zmieniona w stosunku do sm42.gs, ale może się mylę?) oraz 6Dk tegoż autora pracują na skrypcie s200.gs.
skrypt lsc.gs wydaje się nie wymagać poprawki(?), a w każdym razie wydaje się nie zawierać wpisu analogicznego czy zbliżonego do tego, który wskazany został przez autora wątku, jako źródło problemu. Pozostaje otwartym pytanie, czy ten skrypt wymaga w związku z tym jakiejś poprawki? Lokomotywy pracujące na nim nie powodowały również wywracania się TRS19 i 22.
Po wprowadzeniu poprawki (według sposobu podanego przez Radka powyżej) w jednym egzemplarzu pracującym na skrypcie sm42.gs skopiowałem skrypt do pozostałych lokomotyw pracujących na tym samym skrypcie. Operacja wykonana została analogicznie wobec skryptu s200.gs. Obie operacje pod TRS22 po zatwierdzeniu nie wykazały błędów w lokomotywach. Całość trwała około godzinę. Oczywiście, to nie wyczerpuje całości logistyki, gdyż upload na stronę i na DLS to osobne kwestie. Ale niniejszym deklaruję chęć pomocy przy tym przedsięwzięciu, w miarę możliwości czasowych oczywiście.
Chciałbym tylko zauwazyć, że pewien, jak się wydaje, błąd w optyce dotyczącej przedsięwzięcia poprawek w skrypcie polega na tym, że nie trzeba ręcznie edytować skryptu osobno w każdej lokomotywie, ponieważ repainty tego samego modelu, pracujące na tym samym skrypcie, nie mają w nim na ogół indywidualnych różnic. Dlatego zastosowanie biblioteki wydaje się być jak najbardziej sensownym, a co więcej, eleganckim rozwiązaniem ogromnie ułatwiającym ewentualne poprawki skryptowe w przyszłości. Obecnie, zamiast otwierać skrypt do edycji w każdej lokomotywie osobno, można go zwyczajnie skopiować z już poprawionej wersji.
Ostatnio zmieniony przez Railwoj 31-12-2025, 20:51, w całości zmieniany 3 razy
Pomógł: 105 razy Wiek: 41 Dołączył: 19 Lut 2008 Posty: 5344 Skąd: Warszawa
Wysłany: 01-01-2026, 13:13
Konkluzja z ostatnich wpisów w tym wątku jest dość przerażająca. O ile słuszność metody naprawy problemu jest poza dyskusją, o tyle jego skala pod względem logistycznym, zwłaszcza zawarta w pytaniu "kto ma to zrobić" oznacza katastrofę jakiej w Trainz jeszcze nigdy nie mieliśmy. To są setki modeli... i nie chodzi o to czy manualnie czy automatycznie skorygujemy skrypty, większy problem to świadome opanowanie ile jest wersji skryptów, co obsługują, które modele jaki skrypt wykorzystują, ile jest pod-wersji tego skryptu, precyzyjna i świadoma korekta kuid2, uzupełnienie opisów "description" po polsku i angielsku żeby użytkownik wiedział jaka zmiana zaszła... + re-upload na DLS i Trainzart. To praktycznie oznacza "zostaw wszystko, nie miej życia, siedź kilka miesięcy cały czas i się z tym p$@@l". Np. dla mnie, a wszystko wskazuje że musiałbym być głównym wykonawcą tego pomysłu, oznacza to że całkowicie przestanę robić co innego - czyli to co najbardziej lubię w tej grze robić - tworzyć modele wagonów i scenery i zajmować się mapami.
Nie wiem czy w tej chwili jest sens kontynuować tu dyskusję, bo nic nie ugadamy mądrego. Trzeba by rozpoznać wszystkie problemy, przygotować rozwiązanie systemowe, wytypować 10 modeli o różnych wersjach skryptów jako "pilotowe" do nowego rozwiązania z każdym rozpzonanym zestawem opcji jaki do tej pory był wyróżniony, sprawdzić czy działa... i dopiero wtedy dochodzimy do etapu "implikacja do wszystkich pozostałych modeli", gdzie bardzo się przyda pomoc kogoś (jak np. Kolega Railwoj - ale może nie tylko) na etapie systemowego wprowadzenia.
Od razu chciałbym zwrócić uwagę, że mowa tylko o modelach na które mam jakiś wpływ, czyli nie wszystkich w ogóle jakie powstały na naszym podwórku do TRS, tylko tych nad którymi panuję od strony organizacyjnej - czyli w gruncie rzeczy te oparte o skrypty RBacha i Qcyka + skrypty erniego lsc (o innych nawet nie chcę podejmować dyskusji, bo jeszcze powiększy to skalę i tak już dramatycznie wielkiego problemu jaki powstał). Nie kryję jednak, że niektóre modele zwłaszcza we mnie budzą pytanie "co z nimi" - tu parowozy TKt48, Pt47, Pm2, Pm3, Ty2, Ol49... co zrobić w ich przypadku, nie mając dostępu do siatek (a w przypadku PTram, także do konta na DLS).
Żeby zobrazować skalę katastrofy, w kolejnych, osobnych wpisach przedstawię listę rozpoznanych skryptów wraz z funkcjami oraz zestawienie zaktualizowanych, opublikowanych na dzień dzisiejszy modeli lokomotyw dotkniętych chorobą.
Pomógł: 105 razy Wiek: 41 Dołączył: 19 Lut 2008 Posty: 5344 Skąd: Warszawa
Wysłany: 02-01-2026, 00:56
I najprawdopodobniej kompletna lub bliska kompletności lista modeli "dotkniętych" problemem, z podziałem na grupy skryptów (w sumie 619 rozpoznanych lokomotyw):
baureihe323d.gs
<kuid:741143:203> DB BR 323 639-5
<kuid:741143:211> DB BR 323 228-7
<kuid:741143:225> DB BR 323 276-6
<kuid:741143:999001> SOB BR Tm34
<kuid:741143:207> DB BR 324 010-8
<kuid:741143:2030> DR BR 100 821-2
Pomógł: 28 razy Wiek: 50 Dołączył: 05 Mar 2018 Posty: 375 Skąd: Kraków
Wysłany: 02-01-2026, 18:33
Dzięki Koledze Kilanowi za posortowanie katalogu potencjalnych lokomotyw do przejrzenia. Mnie ta liczba 619 nie przeraża o tyle, o ile próbowałem już z dobrym skutkiem wprowadzić na własnym gruncie techniczną poprawkę w skrypcie SM42 i ET22. Obie te grupy lokomotyw łącznie dają liczbę około 150 modeli, licząc te, które zostały oficjalnie opublikowane, lub udostępnione. Jest to, moim zdaniem, do ogarnięcia.
Ciekawe byłoby także skonstruowanie modelowej wersji lokomotywy, np. jednej, wybranej jednostki danego typu do podmiany skryptu na system biblioteki skryptów. Ten pomysł Kkolegi Radka także bardzo popieram. Wydaje się, z tego, co ostatnio przeglądałem, że takie właśnie rozwiązanie zaproponował już AdamStan np. w jego wersjach stonek SM42 ADHD.
Jeśli chodzi o ET22 + 201E, jako moją ulubioną serię elektrowozów, to wczoraj podjąłem próbę wprowadzenia w nich poprawki skryptowej. W trakcie tej operacji okazało się, że większość lokomotyw, a łącznie z moimi różnej maści mini i maxi repaintami jest to dobrze ponad 100 indywidualnych egzemplarzy, przełknęła poprawkę gładko. Okazało się jednak, że w tej liczbie jest mniejsza grupa lokomotyw, prawdopodobnie ze względu na różnice umieszczenia coron świateł pracująca na wariancie skryptu et22dcc. Wariant ten nie posiada różnicy w nazwie skryptu, ale mechaniczna podmiana skryptu z poprawką spowodowała w tych lokomotywach niepożądane skutki: brak animacji pantografów, trwałe świecenie się świateł czołowych bez możliwości ich zmiany. Takie objawy wystapiły w publikowanych lub czasowo udostępnionych kiedyś publicznie modelach ET22 o numerach:
001, 526, 657, 910, 1051,1082, 1105.
W tych modelach skutecznym rozwiązaniem okazało się dokonanie wpisu poprawki w istniejącym skrypcie.
Przypadkiem indywidualnym pozostaje ET22-645 Patrykosa. Model ten ma kodowany skrypt zawierający pewne specyficznie rozwiązane funkcjonalności, które nie pokrywają się z tymi zawartymi w skrypcie niekodowanym. Bez współpracy autora skuteczna poprawka nie jest w tym przypadku prawdopodobnie możliwa, podobnie jak w przypadku innych lokomotyw pracujących na kodowanych skryptach. W pozostałych znanych mi przypadkach dotyczy to jednak starszych modeli spod pierwszych wersji gry, dziś już w zasadzie nieużywanych ze względu na niższe standardy ich wykonania od strony wizualnej.
Pozostaje jednak nadal aktualnym pytanie o skrypt lsc erniego souchaka. Czy modele pracujące na skrypcie lsc w ogóle wymagają poprawki?
Jak napisałem powyżej, przejrzawszy skrypt nie znalazłem w nim wpisu analogicznego lub zbliżonego do tego, który zauważył Kolega Sebek07. Być może zatem w tym przypadku nie ma w ogóle takiej potrzeby.
Jest to duża grupa lokomotyw różnego typu zarówno spalinowych jak i elektrycznych, w tym wszystkie (chyba?) publikowane modele Zgreda z dawnej stacji Żary oraz SM30 i SM31 - według mojego ostatniego sprawdzenia.
Ostatnio zmieniony przez Railwoj 02-01-2026, 18:36, w całości zmieniany 4 razy
To może tak - żeby nie robić niepotrzebnej roboty. Zaczęliśmy z Piotrem prace nad przewaleniem tego wszystkiego na bibliotekę, z dostosowaniem. Robota zaczęta, testowy pojazd działa, procedura opracowana. Wszystko z tej listy będzie przerobione. Kiedy - nie wiem, nie pytajcie
Jeżeli chodzi o różne wersje świateł (meshe i corony) i działanie bądź nie - to tez mam ogarnięte. Teraz tylko "mechaniczna" robota przy poprawianiu configów.
Kodowane skrypty nie są problemem, bo to jest kolejna wersja skryptów znanych, lubianych i niekodowanych, z paroma dodatkowymi funkcjami, które moja biblioteka też "umi". Się zrobi.
lsc niby nie wymaga poprawek - na dziś. Ale robimy je także, raz, że unifikacja, dwa - a kto wie, co kangurom do łba strzeli i znów będzie trzeba "pińset" modeli poprawiać, Jak prujemy, to raz, a dobrze.
Wtrącę się tylko z krótkim stwierdzeniem że lubię Was Panowie za to, że się "wam ciągle chce" :P
(spoko - jestem hetero ale wesoły :P - cytując "Facetów w rajtuzach"
Jestem blisko tematu bo między innymi przy moich sesjach do Bystrzyckiej coś zaczęło zgrzytać w priorytetach ale nie od razu to skojarzyłem. Parę dni temu rozkminialiśmy przy herbacie skalę tego problemu itd. i wyglądało to źle. Cieszę się, że z Waszych wpisów wyłania się bardziej optymistyczny obraz i nadzieja na dalszy ciąg zabawy, w sesje między innymi. Szacunek :)
P.S. Jestem kolejny dzień poza domem w zasadzie i nie mam tego jak sprawdzić ale wydaje mi się że w TANE też coś się z tym działo, zwróciłem uwagę na "wracający" 2 priorytet ale to była zanim "wybuchła" ta sprawa szerzej. Jakoś się wtedy nie przejąłem bo mój scenariusz tego nie potrzebował, ale coś takiego sie działo.
Wtrącę się tylko z krótkim stwierdzeniem że lubię Was Panowie za to, że się "wam ciągle chce" :P
No a jak inaczej? Zrobić to trzeba, a Kilan sam pewnie by nie dźwignął. Więc zróbmy sciepę narodową i kupmy bombę skryptową.
W TANE też mogło się dziać, bo to siedzi w skrypcie, nie w grze. Przyznam się, że ja nie wyłapałem, bo mało jeżdżę, a do testów mapy i snucia się po trójmiejskich portach to mam jeden skład ze stonką ADHD, a tam tego nie ma. Pociąg specjalny MIKOL pełen mikoli
Pomógł: 105 razy Wiek: 41 Dołączył: 19 Lut 2008 Posty: 5344 Skąd: Warszawa
Wysłany: 26-01-2026, 00:03
Po kilku tygodniach wytężonej pracy (RBach i ja), dokonaliśmy adaptacji i przebudowy wszystkich modeli lokomotyw które znajdowały się w zasięgu dostępu - sumarycznie blisko 700 modeli (także nieco więcej niż z początku antycypowaliśmy). Radek systemowo opracował biblioteki oraz rozwiązania indywidualne dla poszczególnych przypadków, które następnie zostały aplikowane do modeli. Celem ich przyszłego funkcjonowania, niezbędne jest zaopatrzyć się w pliki biblioteki (dostępne na DLS), których najnowsza wersja prezentuje się następująco:
Wszystkie modele przeszły też kompleksowe korekty techniczne, obejmujące m. in. uporządkowanie zależności z kuid-table do najnowszych wersji, ujednolicenie zasady wyświetlania siatek LOD (z lekkim odsunięciem wyświetlania kolejnych siatek), ujednolicenie tekstur szyb, uzupełnienie interiorów (zwłaszcza w zakresie lokomotyw serii 750 - ze szczególnym udziałem Patryka), ujednolicenie obrazków i opisów, uporządkowanie wpisów category-class, category-era, description i innych. Poniżej lista modeli które z powodzeniem przeszły adaptację i zostały już skierowane na DLS, gdzie jednak (z uwagi na chwilową niedyspozycję) jeszcze nie dotarły - ale dotrą zapewne w ciągu kilku najbliższych dni.
Uprzedzając pytania, istnieją jeszcze coraz mniej liczne grupki starych modeli które nie znalazły się pośród wyżej wymienionych, głównie ostatnie niedobitki czeskich lokomotyw serii 750 i 754 oraz pojedyncze SU45, SU46 i M62 wymagające generalnej przebudowy tekstur "na nowo". Być może z biegiem czasu i te ostatki zostaną "dodane" do biblioteki, natomiast inne modele raczej nie - głównie dlatego, że nie ma dostępu do ich siatek oraz autorów a zatem nie ma możliwości wgrać ich na DLS... co zasadniczo przekreśla sens ruszania ich (inna sprawa, to fakt, że często maja one też młodsze i nieco rozsądniej wykonane odpowiedniki).
Także... chyba tyle na ten temat. Mam nadzieje (i zupełnie poważnie sobie tego życzę), że nie będę już nigdy więcej dotykał żadnych modeli lokomotyw do Trainz i w końcu zajmę się czymś innym.
Pomógł: 28 razy Wiek: 50 Dołączył: 05 Mar 2018 Posty: 375 Skąd: Kraków
Wysłany: 30-01-2026, 18:20
Przykro mi, że to akurat mi się trafiło znalezisko łyżki dziegciu w beczce miodu, ale po pobraniu z DLSu najnowszej wersji ET22-222 zauważyłem błąd skryptu, który wcześniej opisałem w tym wątku, ponieważ powodował dokładnie te same objawy, tj. świecenie świateł czołowych loka bez możliwości zmiany w kilku modelach tej serii. Prawdopodobnie pracują one na nieco innym wariancie skryptu i podmiana powoduje niepożądane objawy.
Tutaj wersja :2, bez błędu (światła domyślnie wyłączone):
a tutaj widok po pobraniu z DLS wersji :3 :
Wielka prośba o ponowny upload poprawki skryptowej modelu, z całym ogromnym szacunkiem dla wykonanej pracy.
Pomógł: 105 razy Wiek: 41 Dołączył: 19 Lut 2008 Posty: 5344 Skąd: Warszawa
Wysłany: 01-02-2026, 19:47
Cytat:
Wielka prośba o ponowny upload poprawki skryptowej modelu, z całym ogromnym szacunkiem dla wykonanej pracy.
Zajmę się tym, natomiast, ponieważ okazało się że wkradł się taki przypadek jak ta ET22, zwracam się do Kolegi z uprzejmą prośbą o przejrzenie pozostałych modeli czy jeszcze coś innego nie umknęło. Byłby Kolega tak uprzejmy? Mogło coś umknąć przy tej skali przedsięwzięcia i tak skromnych zasobach ludzkich zaangażowanych przy nim.
*Przy tej okazji może od razu doprecyzuję jedno z ewentualnych pytań: czy w modelach M62-1560, TE109-015, TE109-017, TE109-026 i TE125-001 prawidłowo funkcjonuje oświetlenie kabin i przedziału maszynowego?
Pomógł: 28 razy Wiek: 50 Dołączył: 05 Mar 2018 Posty: 375 Skąd: Kraków
Wysłany: 03-02-2026, 13:23
ET22-222 mam w sesjach na kilku najbardziej ulubionych mapach, m.in. na znakomitym PSJ 1976 autorstwa Kolegi Kilana (choć oczywiście żółte czoła go falsyfikują w sensie zgodności historycznej z tą mapą, ale mimo to, nie mogłem się oprzeć) stąd też szybko zauważyłem różnicę na minus w wyglądzie / zachowaniu loka. Ludmiły nie byłyby moim pierwszym wyborem, ale chętnie pomogę i sprawdzę niebawem wskazane kwestie. Spróbuję także przejrzeć to co mam z pozostałego taboru z listy podanej wyżej w wątku. Ponownie podkreślę, że ogromnie doceniam włożoną w te zmiany pracę Kolegów.
Ostatnio zmieniony przez Railwoj 03-02-2026, 13:28, w całości zmieniany 2 razy
Pomógł: 28 razy Wiek: 50 Dołączył: 05 Mar 2018 Posty: 375 Skąd: Kraków
Wysłany: 06-02-2026, 15:12
kilanziom napisał/a:
czy w modelach M62-1560, TE109-015, TE109-017, TE109-026 i TE125-001 prawidłowo funkcjonuje oświetlenie kabin i przedziału maszynowego?
Sprawdziłem i niestety nie działa poprawnie. Gdy oświetlenie kabin i/lub przedziału maszynowego włączy się w opcjach w/w modeli, następuje rozbłysk światła wewnątrz modelu, lecz gaśnie ono po chwili i mimo włączonej opcji kabina czy przedział maszynowy pozostają ciemne.
Pomógł: 105 razy Wiek: 41 Dołączył: 19 Lut 2008 Posty: 5344 Skąd: Warszawa
Wysłany: 06-02-2026, 20:28
Dziękuję bardzo, czyli prawdopodobnie problem z oświetleniem w tej grupce modeli ma jednak charakter systemowy a nie jednostkowy (tylko u mnie).
Będę zobowiazany za uwagę i testy pozostałych modeli celem rozpoznania ewentualnych kłopotów takiego rodzaju jak w przypadku ET22-222. Na chwilę obecną 100% taboru poddanego przebudowie jest już na DLS (wczoraj doszły brakujące reskiny makarona, 2 dni wcześniej martinaST43).
Pojawiały się głosy jakoby SP42 nie działały prawidłowo, ale sprawdzilem to i wszystko wydaje się w najlepszym porządku. Może oprócz trybu kabinowego, ale to nie kwestia skryptu tylko enginespec'a, ale niestety na DLS lepszego na ten czas nie ma.
Pomógł: 28 razy Wiek: 50 Dołączył: 05 Mar 2018 Posty: 375 Skąd: Kraków
Wysłany: 07-02-2026, 16:47
kilanziom napisał/a:
celem rozpoznania ewentualnych kłopotów takiego rodzaju jak w przypadku ET22-222.
Potwierdzę, że dokładnie ten sam problem ze świeceniem świateł, który stwierdziłem w ET22-222 wystepuje w najnowszych wersjach lokomotyw SP42 o numerach: 006, 011, 037, 070, 071, 108, 132, 166, 170, 202, 225, 236, 237. Nie stwierdziłem go w SP42-179.
Zaletą jednego skryptu jest to, że na szczęście działa również to samo rozwiązanie, które Radek Bach podał powyżej, czyli podany przez niego dopisek w configu.
Problem z oświetleniem wnętrz udało się rozwiązać. Poprawka biblioteki skryptów z końcówką :11 właśnie poszła na DLS. Jak się przemieli, to proszę pobrać i będzie działać.
Nie możesz pisać nowych tematów Nie możesz odpowiadać w tematach Nie możesz zmieniać swoich postów Nie możesz usuwać swoich postów Nie możesz głosować w ankietach