stationFunctions2
  EN PL |
| Content |
| Introduction |
- funkcje do definiowania układu kafli na podstawie sprite'ów, współrzędnych i informacji 3D,
- funkcje, aby uzyskać informacje o właściwościach bieżącego (lub sąsiada) kafla, takich jak liczba lub długość platform, typ terenu, nachylenie terenu itp., a także funkcje dostępu do zmiennych związanych z grą, takich jak bieżąca data, klimat itp. Zobacz funkcje dla wydajność stacji ,
- funkcje pomocnicze , które są używane przez te dwa poprzednie typy funkcji,
- funkcje globalne, które są ważne nie tylko dla stacji, ale dla wszystkich funkcji.
| Format |
| Opis |
W przypadku kafli stacji istnieją dwa rodzaje 'sprites'. Pierwszy typ tworzy nową ramkę ograniczającą 3D do użycia przez sortownik sprite. Drugi typ współdzieli obwiednię 3D poprzedniego 'sprite'. Nie może być większy niż 'sprite', który ustanowił ramkę ograniczającą, ani żadna jego część nie może znajdować się poza tym prostokątem. Dla uproszczenia może mieć dokładnie takie same wymiary jak 'sprite', z którym dzieli obwiednię.
Obwiednia 3D jest używana przez sorter sprite'ów TTD do ustalenia kolejności rysowania 'sprites', a także do wskazania, które 'sprites' mają narysować, ponieważ te, których obwiednia wykracza poza aktualnie aktualizowany prostokąt ekranu, nie zostaną narysowane. Upewnij się, że obwiednia 3D jest wystarczająco duża, aby pomieścić cały 'sprite', ale nie tak duża, aby sortownik 'sprites' nie mógł określić, które 'sprite' powinny znajdować się z przodu.
Oznacza to, że kolejność, w jakiej określane są 'sprites', jest nieistotna. Sprite zawsze będą rysowane od tyłu do przodu, w kolejności, którą sortownik 'sprite' uzna za poprawną, z ich obwiedni. Istnieją jednak dwa wyjątki:
- Sprite'y współdzielące tę samą obwiednię będą zawsze rysowane w podanej kolejności.
- W oknie konstrukcji stacji nie jest używany sortownik sprite. Kafle, które mogą być wyświetlane w tym oknie, należy określić we właściwej kolejności rysowania, od tyłu do przodu.
| 'Term' układu | Funkcja m4nfo |
|---|---|
| <tile></tile> | tile() | xtile() |
| <groundsprite></groundsprite> | NOSPRITE |
| <buildingsprite> | notransparency() glass() recolour() NOSPRITE |
| <xoffset, yoffset, zoffset> | xyz() |
| <xoffset,></xoffset,> | xy() |
| <xextent, yextent, zextent> | dxdydz() |
| <xpixeloffset, ypixeloffset> | xyoff() |
Ta funkcja ustawia układ kafli dla określonego ID-stacji. Wymaga co najmniej dwóch wywołań funkcji tile() (lub jednego z xtile()): jednego dla kafla w kierunku-x, a drugiego dla kierunku-y. Wywołania tile()/xtile() są wewnętrznie numerowane kolejno, tzn. Pierwszy kafel stacji otrzymuje numery 0/1 (kierunek-x/y), druga 2/3 i tak dalej. Są to numery kafli, do których odwołuje się wywołanie zwrotne CB_LAYOUT z funkcji makestation() podczas rysowania wszystkich kafli stacji we właściwy sposób. (Oczywiście możliwe jest użycie 'etykiet' zamiast tych liczb podanych w sposób dorozumiany, patrz następny akapit).
Struktury układów mogą być używane wielokrotnie, odwołując się do różnych zestawów ikonek graficznych.
Ta funkcja przyjmuje blok definicji 'sprites' , zarówno dla 'sprites' naziemnych, jak i 'sprites' budujących, patrz poniżej. Kafel można opisać, aby odwołać się do niego później, np. W łańcuchu CB_LAYOUT:
layout(_ROOFS, ... tile(__roofs, ground(1011) regular(21, xyz(0,0,0), dxdydz(5,16,12)) regular(24, xyz(0,0,0), dxdydz(16,16,35)) ) ... ) ... def(3) plt_num( self( reftile(__roofs) if(4) reftile(__roofs+1) if(3) reftile(__roofs+2) if(2) reftile(__roofs+3) if(1) reftile(0) else ) )
Funkcja xtile() może zostać użyta do automatycznego wygenerowania definicji sprite'ów dla kafla w kierunku-y, pochodzących z kafla w kierunku-x. Użycie tej metody wymaga szeregu dodatkowych wymagań i jest bardziej ograniczone niż użycie tile(): 'sprites' budowania muszą być uporządkowane w taki sposób, aby ich numery 'sprites' wynosiły +1 dla kafla w kierunku-y, a dla sprite'ów naziemnych różnica musi wynosić -1 dla oryginalnych sprite'ów TTD i +1 dla niestandardowych sprite'ów naziemnych. Współrzędne 3D zostaną odpowiednio zamienione. Grafiki powiązane z kierunkiem x- i y- układu xtile() muszą być symetryczne, aby zapewnić prawidłowe obwiednie, i nie można używać funkcji xyoff(), ponieważ współrzędne ikonek grafiki są całkowicie nieznane w układach kafli.
Ta funkcja definiuje 'sprite' ziemi, który ma być użyty dla danego pola. W bloku kafli może istnieć tylko jeden 'sprite' naziemny zdefiniowany przez ground(). W przypadku wielu (ułożonych w stos) kafli gruntu, należy je dostarczyć za pomocą funkcji regular() przed zdefiniowaniem dowolnego pola ograniczającego.
Możesz zdefiniować oryginalne naziemne sprite'y TTD lub niestandardowe naziemne sprite'y zdefiniowane w spriteblock(). W takim przypadku będziesz potrzebować drugiego parametru ustawionego na CUSTOM.
Jeśli nie jest potrzebny żaden 'sprite' ziemi, powinieneś użyć makra NOSPRITE zamiast wywoływania funkcji ground(). Może to być przydatne do wyświetlania grafiki ikon lub podczas rysowania niestandardowych fundamentów.
Ta funkcja definiuje 'normalnego' sprite 'budującego' (lub dodatkowego 'sprite' naziemnego). Pierwszy parametr to indeks do bloku sprite'ów powiązany z aktualnym układem, pozostałe parametry to albo przesunięcia od północnego rogu kafla i rozmiaru sprite'a, albo przesunięcia względem poprzedniego sprite'a (patrz zdjęcia poniżej). W tym drugim przypadku ten 'sprite' będzie współdzielił swoją ramkę ograniczającą z bieżącą ramką ograniczającą. Ustawienie opcjonalnego parametru "TTD" umożliwia dostęp do oryginalnych sprite'ów TTD.
Ta funkcja działa tak samo jak regular(), z tą różnicą, że jej 'sprite' jest wyświetlany normalnie nawet w trybie "przezroczystych budynków".
</a>Znowu to samo zachowanie co regular(), ale tym razem z domyślną 'translacją' kolorów firmy.
Znowu to samo zachowanie co regular(), ale tym razem z translacją kolorów zdefiniowaną przez tabelę recolour podaną przez ostatni parametr.
</a>To samo zachowanie co regular(), ale sprite jest rysowany w trybie 'przezroczystym', albo przy użyciu domyślnego trybu 'szkła', albo przy użyciu niestandardowego przezroczystego ponownego zabarwienia po podaniu dodatkowego parametru. Ten parametr musi być adresem mapy 'recolour', która ma być użyta dla efektu szkła.
Ta funkcja definiuje przesunięcia-x/y/z aktualnego 'sprite' od północnego rogu kafla. Należy odnotować, że współrzędne to współrzędne 3D, gdzie x biegnie od prawego górnego rogu do lewego dolnego, a y biegnie od lewego górnego do prawego dolnego (patrz rysunek poniżej), przy czym wymiary kafla to 16x16 pikseli dla xiy i 8 pikseli dla jednej wysokości poziom. Oznacza to, że wartości x i y powinny zawsze zawierać się w przedziale 0 ... 15.
Ta funkcja definiuje rozmiar aktualnego 'sprite' w kierunku-x/y/z. Podane współrzędne są równe powyższym.
| http://www.ttdpatch.de/grfspecs/m4nfoManual/img/stat_dim.png |
Ta funkcja definiuje przesunięcia-x/y 'sprite' potomnego w stosunku do poprzedniego 'sprite' ustawiającego ramkę ograniczającą. Współrzędne odnoszą się do lewego górnego rogu poprzedniego 'sprite', tj. Nie jest to współrzędna 3D.
| http://www.ttdpatch.de/grfspecs/m4nfoManual/img/stat_xyoff.png |
W nowszych wersjach OpenTTD obsługiwany jest tak zwany 'zaawansowany format układu sprite' (ASL), który umożliwia 'dynamiczne' modyfikacje układu za pomocą rejestrów.
Formalna specyfikacja m4nfo dla tego formatu jest taka sama, jak powyżej, z wyjątkiem dwóch dodatkowych parametrów w funkcjach ground(), regular(), recolour() i glass(), a mianowicie <flags> i <registers>. Np. ground(<sprite> [,CUSTOM]) gets ground(<sprite> [,CUSTOM], <flags>, <registers>), or regular(<tile-id>, (<xyz()>, <dxdydz()>) | <xyoff()> [,TTD]) gets regular(<tile-id>, (<xyz()>, <dxdydz()>) | (<xyoff()> [,TTD]), <flags>, <register>.)
Funkcja aslflags() przyjmuje jako parametr cytowaną listę następujących flag:
Potrzebne rejestry są ustawiane przez funkcję registers(), również jako listę cytowaną. Kolejność rejestrów musi być taka sama, jak podane flagi (patrz przykłady). W przypadku nieużywanych flag nie określono żadnego rejestru. Ponieważ przesunięcia dla <x> i <y> można włączyć tylko razem, potrzebne są dwa rejestry. Rejestr dla SKIP używa wartości "1" do narysowania 'sprite' i "0", aby go pominąć. Flaga CUSTOM_RCSPRITE w ogóle nie używa rejestru.
Ostatnie dwie flagi dotyczą tylko stacji. W przypadku stacji, łańcuch kontroli jest rozwiązywany wiele razy, a sprite'y mogą być częścią różnych bloków sprite'ów ('sprites' naziemnych, niestandardowych sprite'ów 'fundamentów', zwykłych 'sprites') bez korzystania z zaawansowanego formatu układu sprite'ów. W przeciwieństwie do pierwszych 6 flag, dla obu flag dotyczących tylko stacji parametr w funkcji registers() nie jest rejestrem, ale wartością z zakresu 0 .. 7, do której dostęp uzyskuje się za pomocą funkcji spritetype() podczas rozpoznawania ikonek . Pamiętaj, że niektóre wartości mogą być już używane, np. '2' do rozwiązywania niestandardowych 'sprites' 'fundamentu' . Nawet jeśli sprite nie pochodzi z bloku sprite, ale z oryginalnego sprite'a, wartość nadal określa, który łańcuch kontroli definiuje wartości dla przywoływanych rejestrów.
Aby uzyskać więcej informacji, zobacz Przykład 4 poniżej.
| Przykłady |
W TTD 'normalne' kafle stacji (mogą być egzotyczne kafle składające się tylko z naziemnego sprite'a lub dodatkowego pojedynczego 'sprite' platformowego) są zwykle składane z trzech sprite'ów: podstawy toru (sprite naziemny), sprite'a 'tła' i ' sprite 'pierwszego planu'. Te 'sprites' są ułożone tak, aby budować kafel stacji w taki sposób, że pociągi jeżdżą po tle i naziemnych 'sprites', podczas gdy pierwszy plan zakrywa wszystko. Zobacz zdjęcie poniżej.
| http://www.ttdpatch.de/grfspecs/m4nfoManual/img/stat_layout.png |
W przypadku dodatkowego 'dachu' lub 'wiaduktu' stacji, 'sprites' te zostaną dodane jako ostatnie lub mogą zostać zintegrowane z 'sprite' na pierwszym planie.
Ponadto kafle stacji muszą być zawsze definiowane dwukrotnie (nawet dla ikon menu budynku), tj. w kierunku x- i y- .
layout(_ROOFS,
tile(
ground(1012) // track x
regular(1, xyz(0,0,0),dxdydz(16,5,8))
regular(3, xyz(0,11,0),dxdydz(16,5,8))
)
tile(
ground(1011) // track y
regular(2, xyz(0,0,0),dxdydz(5,16,8))
regular(4, xyz(11,0,0),dxdydz(5,16,8))
)
...
)
W m4nfo można uniknąć konieczności definiowania zarówno x-, jak i y-kafli poprzez zamianę funkcji tile() na funkcję xtile(), która automatycznie wygeneruje kafle dla kierunku-y, w przypadku gdy kafle są swoimi lustrzanymi odbiciami, graficznie. Oznacza to, że w powyższym przykładzie wystarczy podać tylko pierwszy kafel, a za pomocą xtile() drugi kafel ze sprite'em ziemnym #1011 i normalnymi 'sprites' #2 i #4 zostanie dodana automatycznie wraz z zamianą ich współrzędnych odpowiednio.
layout(_GLASS,
// nowoczesne szkło barwione na zielono
tile(
ground(1012)
compcol(502, xyz(0,0,0),dxdydz(16,5,11))
glass(538, xyoff(0,0), GREEN)
compcol(504, xyz(0,11,0),dxdydz(16,5,11))
glass(540, xyoff(0,0), GREEN)
)
tile(
ground(1011)
compcol(503, xyz(0,0,0),dxdydz(5,16,11))
glass(539, xyoff(0,0), GREEN)
compcol(505, xyz(11,0,0),dxdydz(5,16,11))
glass(541, xyoff(0,0), GREEN)
)
...
)
Przykład 2 przedstawia układ kafli 'nowoczesnej szklanej' platformy z NewStations . Składa się z pięciu 'sprites': 'sprite' naziemnego, dwóch sprite'ów platformy do narysowania w 'kolorze firmy', każdy z przezroczystym 'sprite' 'szklanym', które są zdefiniowane jako ' 'sprites' podrzędne' , tj. obwiednia (sprite'y platformy).
| http://www.ttdpatch.de/grfspecs/m4nfoManual/img/stat_layout2.png |
Detale, które mają być przedstawione w jednym z 8 dostępnych kolorów firmy, należy narysować specjalnym kolorem, spójrz na palety TTD . Jednak obszary reprezentujące efekt przezroczystego szkła mogą być rysowane w dowolnym kolorze (w tym przykładzie czerwonym). Ten przykład pokazuje również, jak zastosować 'niestandardowy efekt szkła' (barwione zielone szkło). Wymaga to ustawienia niestandardowej tabeli kolorystycznej , aby uzyskać pożądany efekt.
Przykład 3 pokazuje, jak użyć wielu sprite'ów naziemnych dla kafla. Jest to przydatne, jeśli chcesz użyć zwykłego 'sprite' szyna/trawa/podłoże~betonowe, ale nadal musisz dodać do niego funkcje bez używania nowego pola ograniczającego. W tym celu używana jest składnia sprite'ów współdzielących poprzednią ramkę ograniczającą, ale przed zdefiniowaniem jej pierwszej definicji.
Przykład definiuje dwa typy 'waypoints', pierwszy utworzony wyłącznie z naziemnych 'sprites', drugi z dodanym 'sprite' budynku.
layout(_WAYP2,
// bez budynku
tile(
ground(1012) // tor
regular(0, xyoff(0,0)) // nakładka
)
tile(
ground(1011) // tor
regular(1, xyoff(0,0)) // nakładka
)
// w budynku
tile(
ground(1012) // tor
regular(0, xyoff(0,0)) // nakładka
regular(2, xyz(0,0,0),dxdydz(16,5,10)) // budynek
)
tile(
ground(1011) // tor
regular(1, xyoff(0,0)) // nakładka
regular(3, xyz(0,0,0),dxdydz(5,16,10)) // budynek
)
)
Należy odnotować, że <xpixeloffset> i <ypixeloffset> w OpenTTD odnoszą się do zwykłego miejsca 'kafli gruntu', ale są ignorowane w TTDPatch i ustawiane na zero. Tak więc, w przypadku tworzenia nowego GRF, który musi być kompatybilny z obydwoma programami, zawsze należy pozostawić wartości <xpixeloffset></xpixeloffset> i <ypixeloffset></ypixeloffset> zero, aby uzyskać ten sam efekt w obu.
Należy odnotować jednak, że z powodu złej specyfikacji w zwykłym nfo, obie implementacje nie uwzględniają ustawienia GROUNDSPRITES we flags() funkcji właściwości stąd te 'wiele 'sprites' naziemnych' muszą zawsze być częścią zestawu ikonek budowania i nie mogą być częścią inny zestaw 'sprites' dla 'sprites' naziemnych. Dlatego nie możesz sprawdzić wielu sprite'ów naziemnych za pomocą funkcji spritetype() .
W przeciwieństwie do niestandardowych fundamentów domów, kafli przemysłowych i obiektów, fundamenty stacji nie wymagają żadnej specjalnej obsługi w ramach definicji układu kafli .
Zamiast tego potrzebne podstawowe sprite'y są definiowane w specjalnym bloku sprite i dostępne w łańcuchu graficznym za pomocą funkcji spritetype() . Prośba odnotowania, że wymaga to ustawienia flagi NOFOUNDATION we właściwościach funkcji flags() .