Po prostu dla niektórych katalogów wiem, jakie powinny być modele i zapisałem to w programie. Nie mam jednak pojęcia o wszystkich modelach, poza tym każdy może mieć jakieś własne utwory. Pisałem, że trzeba się sugerować opisem i przykładami. Nie da się tego zrobić z automatu.
Proszę mi podać nazwy katalogów i nazwy modeli, jakie mają być dopisywane, to postaram się uwzględnić je w kolejnych wersjach programu.
Na dłuższą metę, jeśli kilka osób poopisuje prawidłowo tekstury, będzie to można wyeksportować na serwer i wtedy pozostali będą sobie mogli ściągnąć poprawne wpisy.
Co do EN57, to modele są dopisywane błędnie, i jak się tego nie poprawi, to tekstury z silnikowych trafiają do rozrządczych i na odwrót, co wygląda komicznie. Poprawiłem to w kolejnej wersji.
Wersja alfa 1.0.31 - test poprawiania brakujących pojazdówW tej wersji nie trzeba wchodzić na zakładkę
Tabor posiadany przed losowaniem tekstur. Sprawdzenie taboru wykonuje się automatycznie.
Również lepiej przypisują się modele do tekstur EN57 (sprawdzana jest ostatnia litera w nazwie tekstury). Przy wyszukiwaniu nowych tekstur w pierwszej kolejności sprawdzane jest istnienie pliku
.chk o nazwie utworzonej z początku nazwy tekstury (np. dla
303E-n-483.tga powinien się ustawić model
303E-n, o ile zostanie znalezione
303E-n.chk).
Poza tym nowość: poprawianie brakujących pojazdów na inne. Przy pierwszym użyciu pojawi się dodatkowe okienko. Po lewej stronie będą wypisane modele brakujących pojazdów, po prawej z listy posiadanych trzeba wybrać, czym należy je zastąpić. O ile dla zastępującego modelu zostały zdefiniowane tekstury (w pliku
TEXTURES.TXT), dla zastępowanego pojazdu zostanie wylosowana tekstura (tylko dla zastępowanych, pojazdy znalezione nie są modyfikowane). Podmienianie są również tekstury dla posiadanych modeli, jeżeli nie posiadamy tekstury zapisanej w scenerii, a mamy zdefiniowane tekstury (w pliku
TEXTURES.TXT) dla tego modelu. Oczywiście zapis zmian tylko do pliku
SCENERY\$.SCN.
Ustawienia podmiany zapisują się w pliku
MASZYNA.INI w sekcji
[DYNAMIC]. Po uzupełnieniu katalogów brakujących modeli, wpisy te przestają mieć znaczenie (nie będą używane, jeśli w przyszłości oryginalnie wpisany w scenerii model zostanie znaleziony).
Sceneria nie da się uruchomić, jeśli po podmianie nadal będzie brakowało pojazdów (tzn. nie ustawimy wszystkich modeli zastępujących). Uruchamianie scenerii w takiej sytuacji i tak nic nie da, ponieważ symulator się wysypie z błędem.
Uwaga! możliwe jest zastąpienie brakującego pojazdu z kabiną przez DUMB albo WRAK. (Np. zmiana
PKP\SM42\6D na
PKP\SM42\SM42DDUMB.) W takiej sytuacji nie będzie możliwe jego prowadzenie, a w przypadku zmiany na WRAK sceneria może nie działać prawidłowo.
Zrobiłem definiowanie następstwa modeli w pojazdach wieloczłonowych. Ustawia się to dopisując kolejne linie do
TEXTURES.TXT, z nazwą modelu poprzedzoną dwiema gwiazdkami. Obecnie takie następstwo ustawiłem sobie dla EN57 oraz ET41. Wygląda to następująco:
**6BB=6BS,S-R,SB-R,SB-RB
**6BS=6BA,R-S,RA-SA,RA-S=6BS,SA-SB,-
**203E-B=203E-A,A-B,-
Teraz o co w tym chodzi. Po dwóch gwiazdkach mamy nazwę modelu, na który tekstura ma być uzależniona od tekstury poprzedniego modelu. Jak widać, w przypadku EN57 nie ma definicji dla modelu
6BA, ponieważ jego tekstura nie zależy od poprzedniej. Gdyby dopisać
**6BA=6BB,RB-RA,-, kolejne zestawy EN57 w ramach jednego
trainset zostałyby obleczone tą samą teksturą.
Po znaku równości jest nazwa poprzedniego modelu, jeśli uzależnienie tekstur ma wystąpić. To lepiej wytłumaczyć na przykładzie ET41: jeśli wstawimy
203E-A+203E-B, to uzależnienie zadziała. Jeśli zaś wstawimy
203E-A+Eaos+203E-B, albo
203E-B+203E-A - to każdy człon może dostać inną teksturę, ponieważ nie ma właściwej kolejności modeli.
Dalej, po przecinku, są reguły zmiany końcówek w nazwie tekstury, rozdzielane przecinkami. Przykłady znaczenia zapisów:
- S-R - jeśli poprzednia tekstura kończyła się na S, zostanie ono zastąpione przez R, np. en57-1132s.bmp zostanie zamienione na en57-1132r.bmp,
- SB-R - jeśli poprzednia tekstura kończyła się na SB, zostanie ono zastąpione przez R, np. en71-02sb.bmp zostanie zamienione na en71-02r.bmp,
- - (sam minus) - akceptacja tekstury bez zmiany nazwy - może być wyłącznie jako ostatnia reguła.
Za każdym razem przy zmianie końcówki sprawdzane jest, czy tak zmieniony plik istnieje. Jeśli nie, przetwarzana jest kolejna reguła.
Po ostatniej regule dla danego poprzedniego modelu, można po kolejnym znaku równości określić reguły zmian nazwy pliku dla innego poprzedzającego modelu.
Rozwiązanie na chwilę obecną ma kilka wad.
- Jeśli np. dla EN57 istnieje tylko tekstura dla wagonu rozrządczego, a nie istnieje dla silnikowego (np. mam tak dla en57-732r.bmp) - tekstura ta może trafić błędnie na wagon silnikowy. Da się to obejść - w takiej sytuacji program powinien powtórzyć losowanie dla całego transet.
- Rozłączanie lokomotyw dwuczłonowych będzie najczęściej skutkowało przydzieleniem im różnych tekstur. To by się dało obejść poprzez zapamiętanie oryginalnej tekstury i stworzenie listy przypisań (tzn. jaka tekstura jest zastępowana przez jaką - raz ustalone przypisanie obowiązywałoby dla całej scenerii). Dobrym rozwiązaniem mogłoby być również zablokowanie losowania tekstur dla lokomotyw lub pewnych typów lokomotyw.
- Ubieranie kilku połączonych EN57 w jedną teksturę jest uzależnione od obecności definicji **6BA. To też można by obejść poprzez wspomnianą listę przypisań.
- Nie rozwiązuje to kwestii niepełnej wymienności pewnych tekstur. Np. nie do końca jest sensowna zmiana en71-02r.bmp na en57-1132r.bmp, mimo iż korzystają z tego samego modelu. To by można było łatwo rozwiązać poprzez porównywanie początkowej części nazwy tekstury (niemniej nie dotyczy to wszystkich pojazdów, czasem nazwy tekstur różnią się całkowicie).
- Nie rozwiązuje to wymienności modeli wraz z grupą tekstur (np. 303E z 303-N).
Nie będę na razie publikował tej zmiany, spróbuję jeszcze coś poprawić.
