O webu Bannery a partneři Letecké motory Popisy motorů Teorie a další články Slovník pojmů Časté otázky Srovnání motorů Převaděč jednotek Zajímavé odkazy Literatura Expozice For English readers Ruská letecká výzbroj Popis zbraní Články Pilot Súčka Technik u dopravky Jindřichův Hradec Letecké simulátory Jesenicko 2.0 ZK VFR Objects FSbox - crashboxy Přehled scenérií ČR Poznatky z tvorby Časté problémy s FS Lock On - tutorial Ka-50 Black Shark Ostatní Cyklovýlety Akce & fotky Kalendář akcí Mapa leteckým muzeí Letecké dny v ČR/SR Letecké dny a akce Aviatická pouť 2010 Aviatická pouť 2012 CIAF 2000 CIAF 2002 CIAF 2003 CIAF 2004 CIAF 2005 CIAF 2006 CIAF 2007 IFD 2008 Přerov 2005 Přerov 2006 Flying Rhino 2005 Flying Rhino 2007 Flying Rhino 2008 Flying Rhino 2009 Ramstein Rover 2012 Náměšť, Hradec 95/6 Náměšť 1995 a 1996 Náměšť 2006 Mošnov 1989 Den NATO 2006 Den NATO 2007 Dny NATO 2008 Dny NATO 2012 Čáslav 2007 Sliač 1964 Sliač 2003 Sliač 2005 Národné let. dni 2007 Malacky 2009 CSIAF 1992 Le Bourget 2007 RIAT 2009 TLP 2008 Duxford 2008 Kecskemét 2008 Kecskemét 2010 Airpower 2009 NTM 2009 Radom 2013 Cihelna 2006 Cihelna 2007 Cihelna 2010 Cihelna 2012 Den Pásovce 2009 Den Pásovec 2010 Kbely Bílý Potok Olomouc Neředín Králíky, tvrz Bouda Lešany Vyškov AirPark Zruč TM Brno Krakow 2013 Muz. Orla Bialego Świdnica Košice SPSL 2008 Messerschmitt Stif. Schleißheim Cottbus Gatow Peenemünde Sinsheim Gatčina NASM Castle Air Museum Hill Aerospace Museum Pacific Air Museum USS Hornet Planes of Fame Cradle of Aviation Kennedy Space Center Midland Museum of Flight USS Interpid Hendon De Havilland Museum Le Bourget Museum Linköping Aeroseum Ängelholm Moskva Siem Reap Bukurešť War Remnants Museum Rimini Caproni Automoto Autosalon 2005 AUTOTEC 2008 Ecce Homo 2005 Ecce Homo 2006 Ecce Homo 2007 Ecce Homo 2008 Ecce Homo 2009 FMX Brno 2010 Fotky z letů Let nad Jeseníky I Let nad Jeseníky II Let v Piper L4J Praha - Chania 2007 Ostatní Priessnitzův pohár 07 Delfín OK-ATS JAS-39 Gripen Panorama Medlánky 24.2.2008 Depozit TM Brno Dargen Ignis Brunensis 2008 aukce Mariánské Láz. California agric. mus. Petroleum museum Možnosti webu

Switch to English Přidat k oblíbeným Verze pro tisk
Spřátelené weby
L-39 Výcvikový systém ATM Online www.airbase.cz www.militarybox.cz Československá PVO další odkazy

Poznámky ke tvorbě scenérií do Flight Simulatoru

Popis několika problémů, se kterými jsem se setkal a musel při tvorbě do FS řešit.

Nebudu tu popisovat úplné základy tvorby - je to nad moje síly, nechce se mi a je to zbytečné. Je o tom dost popsáno jinde. Ale pokusím se tu shrnout a předvést řešení několika často dost zásadních problémů při práci ve více vývojových programech. Ani nečekejte bůh ví jakou úroveň a kompletnost - co mě napadne, to tu dám.
Vše se vztahuje k FS2004, k vývojovým nástrojům dostupným v té době (cca polovina roku 2005) a k aktuálním SDK od Microsoftu.
  1. Objekty v FS mají obrácené plochy (GMAX)
  2. MakeMDL vyhazuje chybovou hlášku (GMAX)
  3. Makro stromy od Petra Bednáře (Airport)
  4. Crashboxy a kolize s objekty i daleko od nich (GMAX)
  5. Dávkové soubory *.BAT
  6. Export z GMAX do *.ASM
  7. Texturování polygonu z Airportu
  8. Špatná AFD data (AFCAD)
  9. Odstraněný autogen okolo GMAX objektů
  10. Export z GMAX
  11. Převody souřadnic
  12. Objekty, reagující na vítr a podobně
Objekty v FS mají obrácené plochy
Příčina:
Při vytváření objektu jste nejspíše použili funkci zrcadlení. Ač to není v GMAXu vidět, rozhodily se tím normály ploch. To se pak ve hře projeví tím, že plochy objektu, které by měly jít vidět vidět nejsou a naopak.
Řešení:
  1. Vyberte objekt, u kterého se problém vyskytuje
  2. Pokud možno, přesuňte těžiště objektu (pivot) na střed objektu
  3. Zrcadlete (mirror) objekt podle osy X
  4. Aplikujte na objekt modifikátor Edit Mesh
  5. Označte všechny plochy objektu
  6. V liště s nástroji podržte levé tlačítko myši na ikoně Scale a vyberte Non-Uniform Scale. Klikněte znova pravým na tuto ikonu
  7. Otevře se okno pro zadání změn velikost objektu. Do políčka Offset X zadejte -100%.
  8. Objekt by měl být nyní na své původní pozici a měl by mít obrácené normály. Teď už jen aplikujte modifikátor Normal a flipněte normály.
Pokud objekt teď exportujete a vyzkoušíte v FS, měly by už být jeho plochy orientovány správně.
MakeMDL vyhazuje chybovou hlášku
Problém:

Při pokusu o export scény pomocí MakeMDL vyskočí hláška, obsahující krom jiného taky řádek ".... Invalid X file ...".

Jedna z příčin:

Některý objekt má nějakým záhadným způsobem více vrcholů než by měl mít. Vrcholy navíc nejsou součástí žádné plochy a myší se obvykle nedají označit, jen mopomí Select All.

Řešení:
  1. Vyberte objekt, u kterého se problém vyskytuje. Naleznete jej třeba metodou pokusu omylu nebo to provedete pro všechny objekty.
  2. Pomocí modifikátoru Edit Mesh myší vyberte všechny polygony objektu a zvolte Detach do nového objektu.
  3. Vznikne vám nový objekt, pojmenovaný třeba Mesh01. Původní objekt už není viditelný, ale stále obsahuje ty záhdné vrcholy (vertexy). Starý objekt teď můžete smazat.
  4. Exportujte přes MakeMDL.
Makro stromy od Petra Bednáře
Makro několika stromů středoevropského vzhledu je použitelné v programu Airport a tuším i ve FSSD (nevím, nepoužívám). Dají se umisťovat jednotlivně nebo jako skupinka (forest). Při jednotlivém umisťování je nutné zadat krom parametrů jako jsou rozměry a podobně také souřadnice, která oblast textury se na ten který strom vykreslí. Následuje obrázek a tabulka s parametry, které se v Airport vyplní do odpovídajících políček.

listnaté vf_tree1.bmp

číslo x size y size x offset y offset
1 64 255 0 0
2 64 127 64 0
3 128 127 128 0
4 64 127 64 128
5 64 127 128 128
6 64 82 192 128
7 64 45 192 211

jehličnaté vf_tree2.bmp

číslo x size y size x offset y offset
1 64 255 0 0
2 64 255 64 0
3 64 127 128 128
4 64 128 192 128
5 64 127 128 0
6 64 127 192 0
Kouzlo tohoto makra je ale ještě v něčem jiném. Krom stromků se dají takto do scény umístit jakékoliv jiné objekty/textury (v terminologii grafiků tzv. sprites). Dost dobře se tak dají do scenérie umisťovat například osoby. Zásadní problém je v tom, že použitá textura musí mít rozlišení maximálně 256x256 pixelů. Plyne to tuším z omezení kódu SCASM, který toto makro využívá.
Crashboxy a kolize s objekty i daleko od nich (GMAX)
Problém:
FSko detekuje kolize s vámi vytvořenými objekty třeba i 15 metrů od nich.
Příčina:
Je to dámo způsobem, jakým jsou reprezentována a uložena data pro kolize. Každý exportovaný model, i když je složen z více objektů, má svůj popis kolizí uložen v tzv. 8-stromu (octtree). 8-strom vzniká dělením kvádru, obalujícího model na omezený počet menších kvádrů poloviční, čtvrtinové, osminové velikosti. Kolize letounu se scenérií jsou pak počítány jako kolize s těmito ať už hodně velkými nebo malými kvádry. Právě tyto kvádry většinou nemohou přesně obalit všechny části objektu a často značně přesahují námi vytvořený objekt. A to je příčinou nechtěných kolizí ve větší vzdálenosti od objektu.
Proč je to řešeno pomocí rozkladu na 8-stromy a ne jako kolize polygonu s polygonem? Důvod je asi podstatně větší rychlost výpočtu zda se koliduje nebo ne. Když máte ve scéně 200 objektů a každý by měl mít kolizní tvar složený z polygonů, tak by se CPU poněkud dost zapotilo.
8-strom:
"Osmistrom" je v tomto případě datová struktura, kde každý uzel může mít svou hodnotu buď bude kolize, nebude kolize nebo ukazatel na svých 8 potomků. 8-strom vzniká přibližně tak, že se exportované objekty pokud možno obalí co nejmenším kvádrem. Ne vždy tomu tak je. První dělení proběhne vždy a zjišťuje se, zda 8 vzniklých kvádrů se bude považovat za kolizní, nekolizní nebo zda se bude některý z nich muset dělit na dalších 8. Pokud nejde o exportování krabice, tak se obvykle dále dělí. Zjistí se jestli každá jednotlivá část (kvádr) bude kolidovat, nebude nebo se bude dále dělit. Dělí se tak dlouho, dokud nějaký mechanismus při exportu neuzná za vhodné, že je třeba skončit (může být i dosaženo maxima kvádrů). Na obrázku je vidět jak takové dělení postupuje a postupně se označují kolizní a nekolizní kvádry. Čtvrtý obrázek je v tomto případě konečný a jde vidět, které kvádry jsou jak označeny. Žlutě jsou označeny některé oblasti, ve kterým není žádný objekt, ale přesto jsou kolizní - to právě způsobuje problémy s "building crash" i daleko od budov v FSku.
Část kódu souboru jes_st_boudy.asm, ve které je popsán 8-strom kolizí
001: crash_riff_start label BGLCODE 002: db 'C','R','A','S' 003: dd crash_riff_end - $ - 4 004: BGL_CRASH_START model_crash_end, 67 005: BGL_CRASH_OCTTREE crash_end_1 006: dw CRASH_FLAG_BUILDING_PLANE ; crash type 007: dw 30 ; nodes used 008: real4 50.951530,0.000004,-6.792075 ; Box x,y,z 009: real4 11.377305,9.922221,29.766663 ; Box w,h,d 010: dw 1, 8, 8, 11, 16, 21, 25, 25 ; base offset into node table 011: ; So if you take branch 2 (count from 0), you add 8 to indices you encounter on that branch 012: ; Nodes (254=empty 255=full, else an index into branch) 013: OCTTREE_NODE 0, 255, 0, 0, 0, 0, 254, 0 ; node 0 014: OCTTREE_NODE 1, 2, 3, 4, 254, 254, 5, 6 ; node 1 015: OCTTREE_NODE 254, 254, 255, 255, 254, 254, 255, 255 ; node 2 016: OCTTREE_NODE 254, 254, 255, 255, 254, 254, 254, 254 ; node 3 017: OCTTREE_NODE 254, 254, 254, 254, 255, 255, 254, 254 ; node 4 018: OCTTREE_NODE 254, 255, 254, 254, 255, 255, 254, 254 ; node 5 019: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 6 020: OCTTREE_NODE 255, 255, 255, 254, 255, 255, 254, 254 ; node 7 021: OCTTREE_NODE 254, 254, 254, 254, 254, 1, 254, 2 ; node 8 022: OCTTREE_NODE 255, 254, 255, 254, 254, 254, 254, 254 ; node 9 023: OCTTREE_NODE 255, 254, 254, 254, 254, 254, 254, 254 ; node 10 024: OCTTREE_NODE 1, 2, 254, 254, 3, 4, 254, 254 ; node 11 025: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 12 026: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 13 027: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 14 028: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 15 029: OCTTREE_NODE 254, 254, 1, 2, 254, 254, 3, 4 ; node 16 030: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 255, 255 ; node 17 031: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 255, 255 ; node 18 032: OCTTREE_NODE 255, 255, 255, 255, 255, 255, 254, 254 ; node 19 033: OCTTREE_NODE 255, 255, 255, 255, 255, 255, 254, 254 ; node 20 034: OCTTREE_NODE 1, 255, 255, 255, 2, 255, 3, 255 ; node 21 035: OCTTREE_NODE 255, 255, 255, 255, 254, 255, 254, 255 ; node 22 036: OCTTREE_NODE 254, 255, 254, 255, 254, 255, 254, 255 ; node 23 037: OCTTREE_NODE 255, 255, 255, 255, 255, 255, 254, 255 ; node 24 038: OCTTREE_NODE 1, 2, 254, 254, 3, 4, 254, 254 ; node 25 039: OCTTREE_NODE 255, 255, 254, 254, 254, 255, 254, 254 ; node 26 040: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 27 041: OCTTREE_NODE 254, 255, 254, 254, 254, 255, 254, 254 ; node 28 042: OCTTREE_NODE 255, 255, 254, 254, 255, 255, 254, 254 ; node 29 043: crash_end_1 label word 044: model_crash_end label word 045: BGL_RETURN 046: crash_riff_end label BGLCODE
Pokusím se trochu popsat jak to v této části kódu funguje (alespoň to co chápu). Nejprve si uvědomme, že kvádry jsou orientovány rovnoběžně s poledníky, rovnoběžkami a jsou vodorovné (za předpokladu, že v XML není uvedena nějaká rotace scény).
  1. Řádek 007 - počet uzlů v seznamu
  2. Řádek 008 - souřadnice levého, spodního (osa kolmá na zemský povrch), dolního rohu oblasti vzhledem k souřadnicovému středu projektu.
  3. Řádek 009 - velikost oblasti (kvádru) - šířka (osa X), výška, délka (osa Y)
  4. Řádek 010 - základní offsety prvních osmi kvádrů. Příklad: dw 1 (na uzel 1), 8 (na uzel 8), 8, 11, 16, 21, 25, 25. Uzly jdou popořadě tak jak na následujícím obrázku
  5. Řádek 013 až 042 - samotné definice uzlů. Za OCTTREE_NODE vždy následuje 8 čísel. 254 znamená, že tento kvádr nebude kolizní a dále se nedělí. 255 znamená, že kvádr kolizní bude a dále se nebude dělit. Jakékoliv jiné číslo je offset, ukazující na řádek s rozkladem daného kvádru na 8 dalších. Offsety fungují následovně. Na řádku 14 je poslední hodnota 6 - znamená to, že tento kvádr se bude rozkládat na kvádry popsané na uzlu 6+1=7 (v ukázce řádek číslo 20). Proč +1? Protože se tyto kvádry nacházely v první osmině základního kvádru a na řádku 10, začínajícím "dw" je na prvním místě uvedeno číslo 1.
    Pokud to stále není zřejmé, zkuste si tento příklad projít a určitě pochopíte.

    Zde je řádek 10 a 13 u sebe. Všimněte si, že offsety v prvním řádku na pozici 2 a 7 vlastně nejsou ani tak offsety, jako spíše bezvýznamné číslo. To proto, že na druhém řádku jsou tyto pozice označeny jako kolizní (255) a nekolizní (254) a offset pro další rozklad není nutný.
    dw 1, 8, 8, 11, 16, 21, 25, 25 OCTTREE_NODE 0, 255, 0, 0, 0, 0, 254, 0
Jak minimalizovat škody vzniklé nedostatečným rozkladem:
Za prvé: Pokud mají objekty větší rovné plochy (např paneláky), rozhodně je navrhujte "rovnoběžně s osami" a případné otočení proveďte až pomocí XML souboru.

Za druhé: U malých objektů, kde jsou kolize vcelku zbytečné, je vypněte. Pamatujte, že vypnout se dají pouze u celého objektu, takže pokud chcete, aby některá část existujícího objektu byla nekolizní, musíte příslušné polygony pomocí Detach oddělit. Zamotné zrušení kolizí vybraného objektu provedete v GMAXu skriptem AttachTools - viz SDK. Nebo napsáním tohoto textu do Properties vybraného objektu.
<?xml version="1.0" encoding="ISO-8859-1"?><FSMakeMdlData version="9.0"><NoCrash/></FSMakeMdlData>
Za třetí: Pokud je scéna rozlehlejší (např fotbalový stadion + pár budov kolem), exportujte ji v několika částech. Samostatně vyexportujte objekty, které nebudou kolizní. Poté od sebe oddělte objekty, které spolu moc nesouvisí a jsou od sebe vzdáleny. Následující obrázek by to měl osvětlit. Červený obdélník obsahuje všechny objekty. Ty byly při prvních pokusech s touto scenérií exportovány najednou. Crashboxy samozřejmě nemohly tak dobře sednout a výsledkem byly nechtěné kolize krom jiného i na místech vyznačených červenými fleky nebo žádné kolize na místech, kde by se hodily. Scénu jsem rozdělil na 5 částí (označeny žlutě) a objekty bez kolizí (neoznačeny). Vetšina špatných kolizí se napravila až na kolize mezi budovami vlevo dole. Tam by bylo potřeba další dělení.

Za čtvrté: V souboru ASM můžete crashboxy upravit. Psát to ručně je ale trochu pekelná práce. Nějakým jednoduchým programem půjde udělat definice vlastních crashboxů. Crashboxy by taky mohly jít pěkně vytvořit přímo v GMAXu a pak si trochu pohrát se spojováním dat z více ASM souborů. Zatím jsem vypotil malý prográmek, který z ASM souboru pomůže vytvořit BGLko, ve kterém jsou viditelné crashboxy - FSBox
Zde je vidět v praxi jak crashboxy vypadají a že přesně nekopírují hranice objektu.
Dávkové soubory *.BAT
Spousta programů pro tvorbu a kompilaci scenérií jsou pouze konzolové aplikace bez uživatelského rozhraní. Pracuje se s nimi pouze v příkazovém řádku formou zadání jména programu a jednoho nebo více parametrů. Často je potřeba spustit sérii programů, které si budou postupně předávat výsledky své práce. Právě tady se uplatní dávkové soubory = textové soubory s příponou BAT.
Příklad vytvor.bat souboru pro konverzi .asm na .mdl a .bgl
bglc /mdl %1.asm bglcomp %1.xml copy %1.bgl "c:\hry\fs2004\Addon Scenery\moje_mesto\Scenery\%1.bgl pause
Při exportu testovací scenérie namesti z GMAX přes MakeMDL a se zaškrtnutím volby Keep Files v Options vzniknou soubory namesti.asm, namesti_0.asm a namesti.xml. V namesti.xml nastavíte souřadnice, kde bude náměstí umístěno. Ke spuštění procesu převedení těchto souborů na soubor namesti.bgl stačí do příkazového řádku napsat vytvor namesti. Provede se tím:
  1. Převedení souborů *.asm na namesti.mdl
  2. Převedení namesti.mdl na namesti.bgl
  3. Překopírování namesti.bgl na zvolenou cestu
  4. Čeká na stisk klávesy
Dávkové soubory se také neuvěřitelně osvědčí při tvorbě ortofotomap. Zde je příklad bez podrobnějšího popisu.
resample jes.inf del 011232010033201*.tga del 011232010033203*.tga del 011232010033210*.tga del 011232010033211*.tga del 011232010033321*.tga del 011232010033323*.tga del 011232010211001*.tga abc.exe "c:\FS-sdk\0*.tga" /flip /convert="c:\FS-sdk\*.bmp" imagetool -nogui -terrainphoto 0*.bmp copy *.mip JES-tex\*.bmp copy *.mip c:\hry\FS2004\Scenery\World\texture\*.bmp del 0*.mip
Dávkové soubory vám často ušetří až desítky procent času, námahy a nervů.
Export z GMAX do *.ASM
Z GMAXu je přes MakeMDL možné exportovat přímo do formátu MDL a nebo při zaškrtnutí volby Keep Files v Options můžete ponechat mezistupeň mezi GMAXem a formátem MDL - soubory ASM. V těchto souborech je vámi vytvořená scéna (objekty) popsána na nejnižší člověkem čitelné úrovni. Znalost struktury těchtou souboru vám dá možnost editovat parametry, které by jste přímo v GMAXu těžko ovlivnili.
Texturování polygonu z Airportu
Zatím jen pár poznámek bez delšího popisu.
Vytvoří se polygon, přiřadí se mu textura. Projekt se převede do kódu SCASM. Ve vzniklém souboru SCASM se upraví závorka u odpovídajícího řádku Bitmap(.....)
  • druhá a čtvrtá souřadnice se použije pro přesné umístění
  • hodnoty jsou 0 - 255
  • druhá souřadnice je horizontální osa - čím víc tím víc do prava
  • čtvrtá souřadnice je vertikální osa - čím víc tím výš
Špatná AFD data (AFCAD)
Jak se to projevuje:
FSko při načítání nebo při přiblížení k letišti na vzdálenost asi 15 km někomu spadne, někomu ne.
Příčina:
Program AFCAD v AFD datech vytvořil chybu - například zdvojenou dráhu.
Řešení:
  1. Výsledný BGL soubor dekompilovat pomocí programu bglxml
  2. Opravit chybu (například právě ta zdvojená dráha)
  3. Zpětně zkompilovat pomocí programu bglcomp
Odstraněný autogen okolo GMAX objektů
Problém:
I ve vzdálenějším okolí objektů z GMAXu je v FSku ostraněn autogen. To znamená, že například blízko u vymodelovaného letiště by měl být les, ale v FS v něm nejsou stromy. Ty se objevují až o několik desítek až stovek metrů dále.
Pravděpodobná příčina:
Autogenové objekty se pravděpodobně ruší v kruhu (no, spíše v obdélníku), který má střed ve středu souřadnicového systému vašeho GMAX projektu a poloměr sahá k nejvzdálenějšímu bodu objektu vaší scény, přesněji k nevzdálenějšímu bodu objektu, který exportujete.
Možné řešení:
Pokud máte ve scéně některý objekt příliš vzdálen, posuňte jej do středu. Budete pak ale muset pro tento objekt zvlášť zjistit jeho souřadnice a zvlášť ho exportovat. Neznamená to ale, že výsledek bude muset mít více BGLek. Při kompilaci jednoduše všechny objekty scény v XML souboru sloučíte dohromady a vyexportujete jako jediný BGL soubor.
Zde je příklad fotbalového stadionu a přilehlého školy. V prvním případě se v FSku smazaly autogenové domy do vzdálenosti cca 250 metrů od středu hřiště. Po úpravě, samostatném vyexportování a sloučení všecho v XMLku se smazaly autogenové domy jen do vzdálenosti cca 150 metrů.
Export z GMAX
Jen krátce. Exportuje se přes utilitku MakeMDL.
Exportuje se buď přímo do .MDL a .XML a potom se pomocí bglcomp vytvoří BGL.
Při exportu lze v MakeMDL zvolit monost Keep Files, díky čemuž krom .MDL a .XML vzniknou ještě dva soubory .ASM. MDL je v podstatě pouze kompilát z těchto souborů ASM.
Postup kompilace je zatím napsán někde výše (BAT soubor).
Převody souřadnic
Občas je potřeba převádět souřadnice různých souřadnicových systémů. Například S-JTSK <-> WGS-84 (ten používá FSka). Zatím mi jako dobrý nástroj připadá tento "excelovský program".
Objekty, reagující na vítr a podobně
Takové specialitky, jako pěkné větrné pytle, přistávací "téčka" v signálním čtverci, zahrádka u hospody, otevřená jen v létě a podobně se dají udělat pomocí editace BGLC kódu.
Někdy tu možná trochu popíši, jak se to dělá. Zatím ale jen doporučím samostudium zde http://www.scenerydesign.org/forum/.




Přístupů od 24. 4. 2002