Standardy tworzenia dodatków: Różnice pomiędzy wersjami

Wersja z 15:38, 3 mar 2024

Pliki

Wszystkie pliki muszą pasować do obecnie przyjętej struktury katalogowej na repozytorium. Niedozwolone jest tworzenie nowych zbędnych folderów i umieszczanie plików w innym miejscu niż starsze podobnego typu.

Struktura jest mocno niejasna. Wiele plików podobnych typów znajduje się w różnych miejscach. Dlatego póki co nie można ściśle określić co gdzie należy wsadzić. Pewnym wzorcem może być lista umieszczona poniżej poniżej.W razie wątpliwości należy skonsultować się z Wydziałem Repozytorium.

   • Elektryczne – elementy energetyki komunalnej, przemysłowej, sieci przesyłowych. Słupy oświetleniowe.
   • Eng – obiekty inżynieryjne. Mosty, wiadukty, przepusty.
   • Kolejowe – inne kolejowe, nie do zakwalifikowania precyzyjniej.
   • Miejskie – obiekty użyteczności publicznej i detale do krajobrazu miejskiego.
   • Mieszkalne – wszelka zabudowa mieszkaniowa.
   • Nastawnie – nastawnie i inne posterunki PKP.
   • Peronowe – ławki, wiaty, tablice z rozkładami. Do dekorowania peronów.
   • Pkp – wskaźniki z sieci PKP.
   • Plants – roślinność.
   • Pojazdy – pojazdy statyczne. Koparki, dźwigi i.t.p.
   • Posers – ludzie.
   • Przejazdy – elementy przejazdów kolejowych.
   • Przemysl – elementy zakładów przemysłowych, taśmociągi, rury ciepłownicze.
   • Przytorowe – elementy ze szlaków kolejowych. Słupki hektometrowe, rezonatory, czujniki, szafy sterujące automatyką.
   • Stacje – budynki dworców.
   • Tr/tra/trakcja – sieć trakcyjna.
   • Wiejskie – zabudowa gospodarcza, detale polne.

Przykładami złej struktury w obecnej paczce to foldery: otoczenie\budynki, \ip i \szlakowe.

Pliki z nowych paczek nie mogą nadpisywać starszych (wydanych wcześniej) plików. W szczególnych przypadkach, gdy nadpisanie plików jest konieczne należy zapewnić kompatybilność wsteczną.

Nienadpisywanie plików mam nadzieję jest zrozumiałe. Za przykład zachowania kompatybilności wstecznej może posłużyć plik: scenery\rainsted\lwzmp_l.inc

Dla zgodności z SCSem, autor użył komend zmiany stanu rozjazdu w formacie nazwa:stan. Zostawił jednak zdarzenia dla starego systemu.

event (p1)+ multiple 0 none (p1)_dzwiek (p1)_0 (p1)_Vmax (p1)_suwak0 (p1)_latarnia0 (p1)_walek0 endevent event (p1)- multiple 0 none (p1)_dzwiek (p1)_1 (p1)_V40 (p1)_suwak1 (p1)_latarnia1 (p1)_walek1 endevent event (p1):+ multiple 0 none (p1)_dzwiek (p1)_0 (p1)_suwak0 (p1)_latarnia0 (p1)_walek0 endevent event (p1):- multiple 0 none (p1)_dzwiek (p1)_1 (p1)_suwak1 (p1)_latarnia1 (p1)_walek1 endevent

Wszystkie pliki muszą mieć nazwy zapisane małymi znakami bez spacji i znaków diakrytycznych.

Nie Mój Domek.inc tylko moj_domek.inc. Odnosi się to także do plików tablic relacyjnych. Nie Dąbrowa Górnica.tga a dabrowa_gornicza.tga.

Pliki tekstowe muszą być zapisywane w formacie ANSI Windows-1250 z windowsowym końcem wiersza \r\n.

Szczególnie dla użytkowników Linuxa. Nie UTF-8, nie sano \n (LF). Wiele narzędzi wymaga takiego formatu i nie trawi linuksowych znaczników. Poniżej te ustawienia w Notepadzie++.

Stosowanym separatorem powinna być spacja.

Maszyna jako separator akceptuje spację, tabulator, znak nowego wiersza, przecinek i średnik, ale preferowana jest spacja dla czytelności pliku przez człowieka. Ewentualnie tabulator lub nowy wiersz dla zwiększenia czytelności kodu. Stare skrypty do 3ds Maxa generują średniki. Warto je zamienić na spacje. Przecinek jest separatorem, nie symbolem dziesiętnym!

Pliki nie posiadają odniesień do tekstur z jawnymi rozszerzeniami.

Uwaga zwłaszcza dla tworzących scenerie w Rainstedzie. Przy podaniu ścieżki do tekstury podsypki, on lubi zapamiętać rozszerzenie, eksportując potem wpisy: node -1 0 none triangles material ambient: 0.0 0.0 0.0 diffuse: 149.94 149.94 149.94 specular: 229.5 229.5 229.5 endmaterial grass.dds 1349.94 0.0 830.446 0.0 1.0 0.0 550.887 1130.69 end 1668.69 0.0 802.989 0.0 2.0 0.0 335.016 1116.46 end 1668.69 0.0 273.227 0.0 1.0 0.0 335.016 841.902 endtri

Jest to niedopuszczalne. Wszystkie odniesienia do tekstur muszą być pozbawione rozszerzeń. Inne edytory raczej nie robią takich problemów.

W ekranach na Pythonie, większość grafik ma format png i jest nieużywana w modelu. Są więc otwierane metodą: Image.open(lookup_path + "image.png") Tekstury użyte również w modelu, muszą być wczytywaną uniwersalną metodą: self.openimage(lookup_path + "image") Dla spójności lepiej stosować wyłącznie drugą metodę.

Modele

Wszystkie modele muszą mieć strukturę hierarchiczną. Jeden obiekt nadrzędny i jego potomne kolejnych stopni. Głębokość hierarchii powinna być możliwie płytka.

Do podglądu można użyć dowolnego edytora 3d lub Rainsteda. W przykładach Rainsted jako najłatwiej dostępny. Podgląd wywołujemy z menu modele>otwórz t3d.

Jako przykład stary model pudła EU20. Jak widać obiektem nadrzędnym jest tu banan. Jest to zwyczajowa nazwa dla handlera geometrii w maszynie. Może być to pusty obiekt lub geometria. Istotne by miał największy w modelu zasięg renderowania. Poniżej widzimy jego dziecko-obiekt potomny mocowanie2 a dalej potomne drugiego stopnia w postaci przewodów pneumatycznych w obu stanach. Przykładem zbędnego zagnieżdżania hierarchii jest tutaj pantograf. Animacja wymaga struktury ramię_dolne>ramię_górne>ślizg. Optymalnie ramię dolne powinno być potomnym banana. Podpinanie go pod pudło, podstawę izolatorów, izolatory i mechanizm, to cały stos zbędnych macierzy transformacji do wymnożenia.

Przy braku obiektu nadrzędnego, u góry drzewka byłoby kilka obiektów luzem, nie połączonych przerywanymi liniami

Wszystkie submodele muszą mieć unikalne nazwy.

Nazwy obiektów w ramach jednego pliku t3d (lub kilku t3d includowanych razem do jednego e3d) muszą być unikalne. Na podstawie nazw tworzona jest hierarchia rodzic-dziecko. Jeśli kilka obiektów ma taką samą nazwę, staje się ona nieokreślona i zależy od kolejności parsowania pliku. Problem ten występował w starych semaforach świetlnych, gdzie soczewka, flara i freespot miały taką samą nazwę.

Za przykład zdublowanych nazw posłuży plik dynamic\pkp\4e_v1\4e-zez-profeta\4e_3]kabina-4en-a.t3d

Zdublowane nazwy obiektów na podglądzie struktury w Rainstedzie są oznaczane symbolem wykrzyknika. Po zapisie jest on dodawany do nazwy submodelu dla usunięcia duplikatu.

Plik musi być zapisany zgodnie z hierarchią obiektów. Zawsze rodzic musi występować przed potomnym.

Rodzic zawsze musi się znajdować w pliku t3d przed dzieckiem. Jest to wymuszone liniowym działaniem parsera. Musi on najpierw wczytać rodzica, by mógł podpiąć pod niego dziecko. Jeśli nastąpi próba wczytania dziecka, odwołującego się do niewczytanego jeszcze rodzica, zostanie ono wczytane luzem, bez hierarchii.

Jako przykład celowo uszkodzony plik z obiektem nadrzędnym wyrzuconym na koniec t3d. Jak widać nowym nadrzędnym stała się kabina_b a obiekty podparentowane wcześniej pod profeta są teraz luzem. Symbolizuje to linia skierowana do góry drzewka hierarchii.