Search the Community

Zdravíčko přátelé - pokud hrajete Armu 3 (případně jiné Arma tituly) jistě dobře víte o scriptovacím jazyku SQF, na kterém je hra kompletně postavená. Veškerý funkční content je psán v tomto jazyce a dá se s ním vyčarovat cokoliv si představíte. Pro mě je Arma 3 takový sandbox, ve kterém si vytvářím a realizuje nápady a myšlenky herních typů - engine nabízí kvalitní modely postav, objektů i terénu. Dá se říct, že si v Armě 3 můžete vytvořit svou vlastní hru. BIWiki Veškerou dokumentaci, podklady a zdroje najdete na jednom místě - https://community.bistudio.com Jsou tam rozepsané a popsané veškeré nativní funkce enginu, seznamy objektů, zbraní, vozidel a dalších zdrojů. Lze tam najít kompletní informace pro jakýkoliv druh příkazu, řešení, či návrhu. Bez tohoto se při scriptování v SQF určitě neobejdete. Základy SQF SQF je jednoduchý jazyk. Jakákoliv logika je defakto uložená v proměnné a celý interpreter jen pracuje s těmito proměnnými. Pokročilé vysvětlení zde. Datatypy Každá proměnná v jazyce SQF má vlastní způsob deklarace (a defakto automatické inicializace). Veškeré číselné hodnoty jsou podpultové floaty (tedy desetinná čísla), texty jsou stringové řetězce (a lze je rozebrat na bajty - ve formě číselných hodnot) - tedy cokoliv mezi uvozovkami "text", pole jsou jednoduché soustavy jakýchkoliv proměnných deklarovaný jako [obsah,obsah,obsah] a kód je cokoliv mezi závorkami {code}. Existují ještě speciální typy proměnných, jako například displayNull, controlNull, namespace, configNull, grpNull, locationNull, taskNull, objNull, scriptNull a pár dalších. Deklarace a inicializace probíhají ve stejném kroku a to při přiřazení hodnoty k proměnné, proměnné mohou měnit typy i hodnoty (jedinou výjimku tvoří kód prohnutý funkcí compileFinal - taková proměnná se zabije až se zabitím namespace, ve kterém pracuje - zůstává konstantní - vysvětlíme si později). Codespace SQF kód lze praktikovat takřka kdekoliv v enginu. Jedinou výjimku tvoří config, ve kterém pracujeme s C strukturami pro definice tříd a jejich vlastností. Celý engine hry funguje (a je postavený) na SQF - všechny kampaně, mise, addony a další komunitní obsah, obsahuje více, či méně prvků SQF. Kód se dá psát v Eden editoru (ve spínačích - triggerech), .sqf souborech ve složce mise/kampaně/addonu nebo v debug konzoli. Mnoho cheater řešení dříve užívalo exkluzivně děr v SQF interpreteru pro získání kontroly nad voláním funkcí za běhu - a byli psány celé v SQF. Lokální / globální proměnná SQF chápe lokalitu proměnných základně jen ve dvou bodech scope lokální a globální. Globální proměnná je deklarována s jakýmkoliv názvem, který se neshoduje s názvem nativní funkce, či již jiné deklarované globální proměnné. Lokální proměnná se deklaruje a volá s podtržítkem před názvem, spadá pod scope ve kterém je deklarována: globalniPromenna = 1; //Globální číselná proměnná func_cistaFunkce = //Globální proměnná obsahující kód { _lokalniPromenna = 2; //Spadá pod scope kódu func_cistaFunkce }; Hello World private ["_text"]; //Moderní (volitelná) deklarace lokální proměnné - kód se bez tohoto plně obejde _text = format["Hello world, %1", profileName]; //Vytvoření textu "Hello world, jméno-hráče" hint _text; //Vypsání textu na obrazovku (hint) Struktura kódu Každý příkaz, či operace musí být ve všech případech oddělena středníkem (;). Kód se může psát v jednom řádku (oddělený středníky) nativní funkce mohou být krmeny dvěma způsoby parametrů - před a za funkcí: player setPos [0,0,0]; //Příklad nativní funkce s před-za single parametry (před-odkaz na objekt hráče ; za-pozice hráče XYZ v poli) _stav = linearConversion //Deklarace lokální proměnné s hodnotou z outputu funkce linearConversion, která má jen multi-parametry za sebou v poli [ //Pole 0, //Výchozí bod konverze Z 60, //Výchozí bod konverze Do time, //Progress konverze 0, //Konverzní bod Z 100 //Konverzní bod Do ]; //při time=15 je výsledek 25 Scheduled/unscheduled SQF engine pracuje ve dvou prostředích. To hlavní, ve kterém poběží váš kód většinu času (resp. vy budete většinu času psát kód pro tento environment) a druhý real-time, na který engine počká před vykreslením frame. Při volání funkcí pomocí call se prostředí dědí od volajícího. Pokud ve scheduled prostředí voláme jinou funkci, spustí se také ve scheduled prostředí (a volající čeká na výsledek - neprovádí další logiku). Pokud je funkce volána z unscheduled prostředí, také bude pracovat v unscheduled. Voláním funkce pomocí spawn volanou funkci vždy spustí v scheduled prostředí. Unscheduled prostředí si můžeme vynutit trikem za použití funkce isNil. Scheduled (a k němu vázaný scheduler) environment je rozhraní, ve kterém mohou scripty běžet neustále, ve smyčce, nikdy nekončící, případně i vytěžující. Běží na pozadí vykreslování, engine na ně nečeká, případně je i pozastavuje v momentě slabšího výkonu. Scheduler je systém, který se stará o rozložení dostupného výpočetního výkonu a snaží se rozdat mezi všemi scripty rovným dílem. Může se stát, že váš script poběží jen v jednom frame z deseti, při dobrém výkonu poběží v každém frame. Spouštění scriptů v scheduled environmentu může být několik framů odloženo a při spuštění několika scriptů zároveň se tyto scripty reálně spustí nezávisle na sobě, i s rozdílem několika framů. Scheduled environment je defakto všechno spuštěné ze souboru, pomocí execVM nebo spawn. Unscheduled environment je pro změnu rozhraní, ve kterém engine zpracovává exkluzivně skripty až do konce. Nekonečné smyčky jsou schopné bricknout celou hru a nesmí být v tomto environmentu spouštěné. Také všechny odkládací funkce (sleep, waitUntil) v tomto prostředí nefungují, vyhodí chybu, či jsou ignorovány. Jen v tomto prostředí máte jistotu, že se vaše scripty spustí okamžitě, projdou veškerou logiku za sebou tak jak mají a vše stihnou v jednom frame - scheduler na základě výpočetní náročnosti takového scriptu poté pozastaví, či omezí spuštění jiných skriptů ve scheduled prostředí. Kam psát skripty? Většinou ze začátku vám bude stačit soubor init.sqf ve složce s misí (Dokumenty/Arma 3/missions/). Případně deriváty initPlayerLocal.sqf a initServer.sqf. Existují i další speciální názvy souborů, které engine spouští na základě různých událostí, to už dohledáte na BIWiki. Dalším způsobem psaní scriptů pro mise je přímo v editoru. Stačí hodit kamkoliv spínač (trigger), podmínku mu hodit jen true a do pole Po aktivaci vepsat kód (můžete si ho připravit v editoru jako VS Code). Případně do pole inicializace jednotek. Pro dočasná, či jednorázová spuštění kódu lze využít i debug konzoli, která je vždy dostupná editoru. Případně lze aktivovat i pro finální verzi pomocí atributů mise. Takto spuštěné skripty se nikam neukládají, a jsou spouštěny jen pro aktuální relaci mise. Na závěr Projděte si dokumentaci, experimentujte a tvořte. Pomocí SQF se dají vytvářet nehorázné blbosti a kreace. Vaším nejlepším přítelem je i fakt, že vše publikované pro Armu 3 podléhá open-source licenci, můžete číst všechny skripty ostatních autorů, vykrádat jejich obsah a učit se z nich. Najděte si na workshopu zajímavou misi, či addon - s pomocí programu PBO Manager můžete rozbalit balík, který obsahuje veškeré zdroje, soubory a skripty, který tento addon nese, tento program vám bude i velkým pomocníkem, až budete hledat textury základní hry - můžete si pomocí jej rozbalit i základní soubory hry a čerpat informace z nich (kampaně, objekty, funkce, textury) Úkol pro vás: Prohledejte BIWiki a zkuste si najít další event scripty, se kterými se dá pracovat. Vytvořte misi, ve které máte za úkol ukrást nepřátelské vozidlo - zkuste se držet podobného stylu jako v misích základní hry - využívejte tasky, naučte se s nimi pracovat ve scriptu, relevantní dokumentaci vyhledejte na BIWiki. Naučte se spojit prvky editoru se scripty, využijte spínače pro aktivování scriptovacích funkcí (nativní funkce call nebo spawn).

Zdravíčko přátelé - možná jste někdy ve svém módu řešili animace, interpolaci, či jakýkoliv plynulý pohyb předmětu či čehokoliv jiného. Dá se samozřejmě přes lineární konverzi (jejíž algoritmus najdeme ve všech jazykových podobách na internetu) zařídit ostrý pohyb z bodu A do bodu B. Pokud ale chceme zajistit plynulejší pohyb s rozjezdem a dojezdem - tedy zrychlením a zpomalením, které nebije tolik do očí - je potřeba upravit chování naší lineární konverze tak, aby buď rovnou pracovala na algoritmu, který toto bere v potaz, případně můžeme toto nasimulovat pomocí nástrojů nám svěřených. Nejdříve si ukážeme "hack" verzi - tedy pro mě jako absolutního nematikáře - absolutní začátek a experiment celé pseudofunkce. Příklad si uvedeme ve hře Arma 3, pro pohyb kamery v cutscéně. Arma 3 nám nabízí funkce pro lineární pohyb kamery z bodu A do bodu B - ostrou cestou. Tím je myšleno, že po spuštění funkce se kamera fixní rychlostí přesune z jejího dosavadního bodu do bodu zadaný v parametru funkce v čase také zadaném v parametru funkce: _cam = "camera" camCreate [0,0,0]; //Vytvořit kameru na pozici [0,0,0] _cam cameraEffect ["internal","back"]; //Přepnout obraz hráče do této kamery _cam camPreparePos [10,10,10]; //připravit přesun na pozici [10,10,10] _cam camCommitPrepared 5; //přesun trvá 5s Vizuálně takový přesun je sice použitelný, nicméně není plynulý a strašně neuhlazený (hlavně při pohybu na více bodů v řadě). Double LERP Ukážeme si ten nejjednodušší způsob, který vymyslí hlavně nematikář - za pomocí lineárního pohybu, který arma nabízí, můžeme nasimulovat rozjezd a dojezd pomocí zdvojeného lerpování (linearní interpolace, kterou obstará příkaz camCommitPrepared). //Používáme globální proměnné pro zviditelnění kamer pro skript na EachFrame V_cam = "camera" camCreate [0,0,0]; //Vytvořit kameru na pozici [0,0,0] V_cam cameraEffect ["internal","back"]; //Přepnout obraz hráče do této kamery V_camPos = "camera" camCreate [0,0,0]; //Vytvoří kameru využitou na pozadí pro výpočet lineráního přesunu kamery V_camLerp = addMissionEventHandler ["EachFrame", //Vytvoříme unscheduled environment spuštěný na každém vykresleném snímku { _T_pos = getPosASL V_camPos; //Vezmeme si ASL pozici kamery pro přesun _C_pos = getPosASL V_cam; //Vezmeme si ASL pozici vizuální kamery _T_pos = vectorLinearConversion [0,1,0.1,_C_pos, _T_pos]; //Provedeme lineární konverzi (lerp) s progressem 0..0.1..1 (toto zajistí efekt akcelerace) V_cam camPreparePos (ASLToATL _T_pos); //Nastavíme výslednou (interpolovanou) pozici V_cam camCommitPrepared 0; }]; V_camPos camPreparePos [10,10,10]; //připravit přesun na pozici [10,10,10] V_camPos camCommitPrepared 5; //přesun trvá 5s sleep 5.1; //Počkáme 5s na přesun kamery + 0.1s na dokončení akcelerace naší vizuální kamery removeMissionEventHandler ["EachFrame", V_camLerp]; //Zničíme lerpovací skript Můžeme si samozřejmě napsat kompletní funkci, která využije příkaz vectorLinearConversion dvakrát a obejde tím rovnou vytvoření druhé kamery a příkaz camCommitPrepared pro přesouvací kameru. Pro jednoduchost a čitelnost skriptu (a variabilitu) jsem předal funkci takto Pro práci s pohybem kamery (resp. pro relevantní výpočty a manipulace) využívám výhradně pozici ve tvaru ASL (Above Sea Level), protože při interpolaci ATL (Above Terrain Level) kamera při přesunu skáče dle toho jestli pod sebou zrovna nemá kopeček, či díru (proto zjišťuji polohy ASL a poté překládám do ATL při nastavení pozice samotné kamery - příkaz pracuje s ATL pozicemi a sám interpoluje na ASL) Interpolace pomocí algoritmu Tou "správnou" cestou by měla být pravá matematická interpolace se zahrnutím easingu už v algoritmu. Existuje mnoho různých algoritmu na ty samé pohyby - ať už jde jen o zrychlení, jen o zpomalení, či oboje - na vše je několik variant. Ukážeme si jenom tu základní - na zbytek uvádím silný zdroj: http://gizma.com/easing/ _posA = [0,0,0]; //Nastavení bodů _posB = [10,10,10]; _startTime = time; //Nastavení výchozího času a délky průběhu _endTime = _startTime + 5; //+5s _eh = addMissionEventHandler ["EachFrame", { _progress = linearConversion [_startTime, _endTime, time, 0, 1, true]; //Převod průběhu času na range 0..1 s clamp _progress = _progress * _progress * (3 - 2 * _progress); //https://www.wolframalpha.com/input/?i=x+*+x+*+%283+-+2+*+x%29 (křivka pro easing-inout) _curPos = vectorLinearConversion [0,1,_progress, _posA, _posB]; //Vlastní výpočet bodu na trase (interpolace s easingem) }]; sleep 5; //Celý pohyb i s akcelerací bude probíhat přesně 5s removeMissionEventHandler ["EachFrame", _eh]; Kdo chce bejt absolutní fajnšmejkr, tak tu má ještě funkci pro lineární interpolaci (i když ji skoro každej engine i samotný jazyk nabízí už v nějaké matematické třídě) func_myLerp = { params ["_A", "_B", "_progress"]; //Parametry funkce _progress = _progress max 0 min 1; //Clamp na range 0..1 (_A + (_B - _A) * _progress); };