maszyna

Przydzielony do projektu: maszyna
Zgłoszone przez Milek7 - 30.09.2017
Ostatnio edytował Stele - 22.10.2018

Proponuję uporządkować kwestię pierwszego parametru plików INC, w którym może być unikalna nazwa albo tekstura (np. dachu). Kiedyś wymóg unikalnej nazwy był oznaczony za pomocą wielkich liter w nazwie pliku (obecność eventów), ale to rozróżnienie zostało zlikwidowane bez zastosowania alternatywnego rozwiązania.

0. Można przyjąć, że wstępne rozróżnienie odbywa się po nazwie katalogu. Np. obiekty mieszkalne, czy peronowe na ogół nie będą wymagały unikalnej nazwy, w związku z tym w (p1) będzie tekstura. Jakiś inny katalog (np. pkp czy mav) będzie zawierał obiekty typowo aktywne, które w (p1) będą musiały mieć unikalną nazwę. Jeśli dany plik INC ma inne znaczenie (p1), niż to wynika z katalogu, musi być specjalnie oznaczony. W zasadzie można by oznaczyć wszystkie pliki, ale będzie to wymagało ogromu poprawek, które formalnie są zbędne, a także ich wprowadzenie może prowadzić do błędów, które następnie trzeba by eliminować.

1. Pliki INC modeli, które mają wymienną teksturę dachu w (p1), ewentualnie nie mają wymiennej tekstury, ale ignorują zawartość (p1), oznaczamy za pomocą znaku $ na początku nazwy.

2. Pliki INC modeli, które wymagają unikalnej nazwy w (p1), ewentualnie nie używają (p1) wcale (w szczególności tekstura jest w innym parametrze), oznaczamy za pomocą znaku # na początku nazwy pliku.

(Zmiana koncepcji na bardziej ogólną i wymagającą mniejszego zakresu zmian.) Ra

Mariusz1970:
1) Najpierw trzeba by moim zdaniem oczyscic paczke z plikow inc, ktore sa czesciami scenerii. Jest narzedzie do tego, dwa klikniecia i gotowe.
2) Q wpadl na pomysl, aby pierwszy parametr oznaczal typ pliku includowanego. Wiaze sie to z przerobka wpisow do plikow inc, jak rowniez przesunieciem

Ra:
Typ lepiej zapisać w nazwie niż w parametrze. Już wystarczający jest śmietnik z przesuniętymi parametrami w niektórych elementach sieci trakcyjnej.

Mariusz1970:
Inni maja inne zdanie. Nie widze tego smietnika, tylko dlatego, ze pojawi sie dodatkowy parametr jako pierwszy z typem. Raczej widze smietnik dodajac co rusz nowe znaczniki typu mala/duza litera, #, @ itp., no ale mi to ze tak powiem zwisa jak bedzie.

Stele:
Ruszanie parametrów wymaga przeróbek we wszystkich edytorach. Nazwa jest tu najmniej inwazyjna, ale znając życie nikt o tych regułach nie będzie pamiętał i nawet jakby ktoś przemielił paczkę, za dwa lata znowu będzie śmietnik.

Mariusz1970:
Mysle, ze ze znacznikami ludzie nie beda pamietac i ich przestrzegac. Ja juz sie pogubilem w nich. Dla torow jakies, dla t3d inne, teraz mialoby dojsc inc. Dla mnie jest to bardziej bledogenne i malo czytelne/intuicyjne. EOT

Ra:
Znaczniki nie są do tego, żeby ich się uczyć na pamięć, tylko raczej po to, żeby edytor, w którym się wybierze plik INC obiektu oraz ustawi współrzędne XYZ oraz nazwę i teksturę, mógł wyeksportować obiekt do scenerii z odpowiednią kolejnością parametrów. Jeśli nie chcesz przestrzegać znaczników, to musisz w edytorze ustawiać dodatkowy parametr, który określi sposób tworzenia wpisu include w sposób nie prowadzący do błędów.

Fakt jest taki, że używano różnych znaczeń dla parametrów bez jawnego określenia tego. W efekcie mając wpis include w scenerii nie ma się informacji, czy tekstura powinna być jako (p1), (p6), czy może (p5). Największe zamieszanie jest z siecią trakcyjną, bo tam obiekty mają przesunięte współrzędne XYZ. Można to powiązać z obecnością plików INC w katalogu tr, ale z kolei wyjątkiem od wyjątku są znaczniki We. Sieć trakcyjna może być również umieszczona w innym katalogu i nie ma ogólnej reguły wskazującej, po czym poznać katalogi z parametrami przesuniętymi w sposób charakterystyczny dla sieci trakcyjnej.

Najczęstsze układy parametrów (T-tekstura, XYZ-współrzędne, ABC-kąty, N-nazwa):
TXYZA — większość modeli otoczenia
TXYZABC — modele z opcją pochylania
NXYZAT — np. semafory
XYZAT — sieć trakcyjna (ale np. ostatnio zlikwidowałem tablicę peronową z takim układem)

To, co proponuję, jest możliwe do zastosowania od razu i nie wymaga ogromnego nakładu pracy. Oczywiście nie upieram się przy moim rozwiązaniu i nie ma przeszkód, żeby ktoś zgłosił lepsze. Ale wstawianie dodatkowego parametru lepszym rozwiązaniem nie jest, bo będzie wymagać ogromnych zmian w paczce i utrudni życie ludziom, którzy tworzą coś bazując na obecnej strukturze paczki. Zmiana ograniczonej liczby plików zgodnie z pewnymi regułami nie jest tak uciążliwa, jak zmiana wszystkich.

Można by jeszcze przyjąć, że domyślnie obiekty w podkatalogach scenery mają kolejność TXYZA, natomiast katalogi z domyślną unikalną nazwą muszą być zaczynane od #. Czyli by musiało być #pkp, #mav, #przejazdy jako sugestia, że dla plików INC w tych katalogach należy stosować kolejność NXYZA (chyba że plik będzie miał znacznik $).

Mariusz1970:
Niemozliwe jest zaproponowanie lepszego rozwiazania, niz Twoje... System zmian, zaproponowany przez Q, a realizowany przez moj program, automatycznie wspiera ludzi, ktorzy cos w tej chwil trzworza, nawet, dla tych, ktorzy wydadza paczke ze sceneria juz po zmianach. Natomiast twoja propozycja opiera sie tylko i wylacznie na ludzkim czynniku. No ale jak bedzie, nie ja decyduje.

Ra:
Gdzie jest opisany system zmian zaproponowany przez Q? Czytam chyba wszystkie wiadomości tu, ale nic takiego sobie nie przypominam. Skoro jest taki wspaniały, a program jest gotowy, to dlaczego jeszcze nie został wdrożony przez ekipę składającą paczki i dlaczego wymieszane parametry nadal są problemem? Ja nie mam nic przeciw, żeby ktoś coś zrobił lepiej, niż mi się wydaje, że można. Ja też nie decyduję, bo póki co nie dałbym rady jeszcze zajmować się składaniem paczki. Widzę problem (nie od wczoraj, tylko od 7 lat), to w końcu proponuję jakieś rozwiązanie.

Też nie widzę problemu, żeby uruchomić program, który posprawdza kolejność parametrów i doda znaczniki do nazw plików oraz zmodyfikuje pliki w sceneriach. Pisanie programów też opiera się tylko i wyłącznie na ludzkim czynniku — drobny błąd w programie może wyprodukować masę błędów w danych, które to błędy ujawnią się dopiero po długim czasie, gdy już będzie za późno na powtórne uruchomienie poprawionego programu w celu pozbycia się tych błędów.

Ja z kolei mam zrobiony w Rainsted eksport scenerii — i jak mam to zintegrować z systemem zaproponowanym przez Q i z Twoim programem?

To, że opisałem tu mój pomysł, to nie oznacza “macie tak zrobić, bo ja wiem lepiej”, tylko chciałbym wiedzieć, czy ktoś ma jakieś inne przemyślenia na ten temat.

Nie znam szczegółów pomysłów Q, ale moim zdaniem informacja o parametrach powinna być zawarta w nazwie pliku, bo dodatkowy parametr nie spowoduje, że plik INC się do określonego znaczenia parametrów dostosuje. Czyli trzeba by ten parametr ustalać zależnie od nazwy pliku. Zresztą, jeśli były by jasne reguły co do stosowania parametrów i oznaczania tego w nazwie, to kombinowanie z dodawaniem dodatkowego parametru było by zbędne.

Mariusz1970:
Na tutejszym forum nie zobaczysz tego programu. Jest to swieza sprawa, dlatego szerzej sie o tym nie mowi. Zaczalem dyskusje dlatego, ze pomysl Q mi sie spodobal. Mial do mnie prosbe, abym napisal program, to napisalem. Oczywiscie, ze w zalozeniu pomysl Q raczej nie wnosi rozwiazania, do oznaczania w jakim inc jest zmiana paramertow, ale mozna pomysl dopracowac, aby nie bylo dwoch roznych koncepcji. W tym linku http://eu07.pl/userfiles/23403/priv-zmieniacz.rar wystawiam ten program. Co do czynnika ludzkiego, jasne, ze sie go nie wyeliminuje, jednak rozwiazanie Q wymusza nadanie typu w razie stworzenia nowego pliku inc, w przeciwnym razie, scenerie sie nie uruchomia. W twoim rozwiazaniu, to przejdzie niezuwazone i trzeba znac te znaczniki, ktore sa nie intuicyjne.

Moze sie niech wypowiedza inni, skoro zamiescilem program, a w nim opis z koncepcja Q. Jest teraz pelen obraz 2 pomyslow.