Jump to content

Search the Community

Showing results for tags 'dcmd'.

  • Search By Tags

    Oddělujte čárkami
  • Search By Author

Content Type


Fórum

  • Obecné
    • Všeobecné
    • Všechno možné
  • Programování
    • Poradna
    • Návody
    • Tvorba
    • Hledám programátora
  • Herní oblast
    • Poradna
    • Jak na to?
    • Herní kontext
    • Herní zážitky
    • Komunita
  • Grafika
    • Poradna
    • Návody
    • Tvorba
  • Ostatní
    • Hardware a software
    • Hledám/nabízím
    • Archiv
    • 3D Tisk

Calendars

  • Kalendář Pawno.cz

Categories

  • Verze

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Web


Facebook


Jabber


Skype


Steam


Twitter


Github


Pastebin

Found 3 results

  1. I-ZCMD Obsah: Úvod I-ZCMD Vytváření příkazů Funkce includu Tipy a triky Příklady Závěr 1. Úvod: V tomto návodu se podíváme na práci s příkazovým systémem I-ZCMD. Konkrétně tedy probereme vytváření příkazů, používání funkcí includu a nějaké tipy. 2. I-ZCMD Příkazový systém I-ZCMD vytvořil Yashas, jako reakci na neaktuálnost ZCMD, z kterého také vychází. Jedná se o aktuálnější, optimalizovanější a rychlejší ZCMD. Stáhnout jej můžete na tomto githubu. Návod se bude držet aktuálního I-ZCMD, ale většina informací platí i k ZCMD od Zeexe. 3. Vytváření příkazů Příkazy můžeme vytvářet hned několika způsoby a to COMMAND:nazev_prikazu(playerid, params[]) { //další kód } CMD:nazev_prikazu(playerid, params[]) { //další kód } command(nazev_prikazu, playerid, params[]) { //další kód } cmd(nazev_prikazu, playerid, params[]) { //další kód } nazev_prikazu – váš název příkazu bez lomítka (kill, pm, admins). playerid – id hráče, který odeslal příkaz. params[] - text, který hráč napsal za samotný příkaz. Parametry jsou od názvu příkazu oddělené mezerou. pozn. V příkazech při vrácení 0 (CMD_FAILURE) a nepoužití OnPlayerCommandPerformed se vypíše hláška "UNKNOWN COMMAND". Doporučuji tedy vracet 1 (CMD_SUCCESS). V samotném scriptu nepoužíváme OnPlayerCommandText (I-ZCMD ho již zahrnuje), protože se stejně nezavolá. Místo této funkce zde máme dvě funkce, na které se nyní podíváme. 4. Funkce includu V I-ZCMD se narozdíl od ZCMD tyto funkce volají přímo. To je jednou z optimalizací, kterou tento systém prošel (ZCMD využívá funkci CallLocalFunction, která je více časově náročná). . ● OnPlayerCommandReceived(playerid, cmdtext[]) je plnou náhražkou za OnPlayerCommandText a má stejné parametry. Funkce se volá před samotným procesem zpracování a volání zadaného příkazu. Vrácením 0 můžeme ukončit zpracování příkazu, ale nebude vypsána hláška "UNKNOWN COMMAND". ● OnPlayerCommandPerformed(playerid, cmdtext[], success) je další ze zmiňovaných dvou funkcí. Narozdíl od předešle, se tato funkce volá až po zavolání našeho příkazu. Funkce má stejné parametry, ale jeden zde přibyl. Hodnota success odpovídá vrácené hodnotě funkce CallLocalFunction (pokud příkaz existuje, odpovídá vrácené hodnotě v daném příkazu). Díky tomuto parametru si tedy můžeme kontrolovat, zda příkaz existuje, proběhl v pořádku a podobně. Vrácení 0 v této funkci vypíše hlášku "UNKNOWN COMMAND". 5. Tipy a triky ● I-ZCMD není defaultně case-sensitive. Znamená to tedy, že příkaz "/prikaz" a "/PRIKAZ" vyvolá stejnou funkci, avšak tuto vlastnost můžeme změnit následující definicí (nelze u ZCMD). #define IZCMD_ENABLE_CASE_SENSITIVITY . ● Narozdíl od ZCMD, se nehookuje OnFilterScriptInit/OnGameModeInit, a proto nijak neřešíme definici FILTERSCRIPT. . ● Pokud chceme zjistit, zda hráč nezadal parametry, využijeme k tomu isnull (součástí includu). Viz spoiler. . ● Příkaz můžeme vyvolat odkudkoliv následujícím způsob (za playerid a params si dosadíme příslušné hodnoty) cmd_nazev_prikazu(playerid, params); Tímto způsobem můžeme jednoduše vytvořit mnoho příkazů, které provádějí stejné akce. 6. Příklady ● Jednoduchý příkaz na zabití hráče (bez parametrů). COMMAND:kill(playerid, params[]) { SetPlayerHealth(playerid, 0); return 1; } . ● Jednoduchý příkaz (s parametrem), ukázka použití isnull a chybová hláška. CMD:say(playerid, params[]) { if(isnull(params)) return SendClientMessage(playerid, -1, "Použití: /say [zpráva]"); new str[145]; GetPlayerName(playerid, str, MAX_PLAYER_NAME); format(str, sizeof str, "%s říká: %s", str, params); SendClientMessageToAll(str); return 1; } . ● Vlastní text místo "UNKNOWN COMMAND". public OnPlayerCommandPerformed(playerid, cmdtext[], success) { if(!success) return SendClientMessage(playerid, 0xFF0000FF, "Příkaz neexistuje"); return 1; } . ● Zakázání příkazů danému hráči. public OnPlayerCommandReceived(playerid, cmdtext[]) { if(isMuted[playerid]) { SendClientMessage(playerid, 0xFF0000FF, "Máte zakázáno používání příkazů"); return 0; } return 1; } . 7. Závěr To by bylo k tomuto návodu o jednom z nejrychlejších příkazových systémů vše. Pokud máte nějaké otázky, připomínky, nebo máte cokoliv jiného na srdíčku, můžete dát vědět do komentářů. Ověřený návod Tento návod prošel validací, a lze ho proto považovat za ověřený.
  2. PŘECHOD Z DINI/DCMD/JINÉ NA YSI4 ***** Je to až k neuvěření... dini oslavuje 10 let od doby jeho první publikace(8 let od jeho poslední aktualizace) a stejně se najde spousty uživatelů, kteří si ho bez nějakých námitek vesele používání, a prohlašují ho za nejlepšího, i když ani nemají ponětí jak přesně funguje. To samé dcmd. A navíc, o nějaké lepší, rychlejší a efektivnější variantě nechtějí ani slyšet, protože buď zatvrdnou na nich a ostatní je pro ně pitomost nebo moc složité i přesto, že je to neuvěřitelných 80% to samé. Myslím, že je asi zbytečné vám vysvětlovat funkčnost dini/dcmd a jejich pomalost. Zkušenější to už dávno ví a snaží se to vtlouc začátečníkům, kteří buď o tom nic neví, nebo to nechápou či to ignorují. Chci se zaměřit na ukázky hlavně v kódě. Ale nenechte se zmást. I když mají uživatelé YSI za neskutečně rychlou, už se najdou i rychlejší includy. Akorát, k čemu si stahovat celou knihovnu a z ní využít jen pár includů a pak si postahovat ty rychlejší? Nikdo vám za to nemůže utrhnout hlavu, když budete pracovat jen s knihovnou, protože už jenom, že se odvážíte pracovat s YSI je pro ně něco. V tomto topicu vám nechci jen popsat, jak jednoduše přejít z dcmd a dini na YSI4, ale také další změny v kódě, například práce s timery, cyklusem a tak dále. A do budoucna doufám, že v případě, kdyby si někdo neuměl představit jak přejít na YSI, nebo by ho měl za složité, tak, že bych mu mohl já nebo někdo z uživatelů mu odeslat odkaz na tento topic, aby se přesvědčil o opaku. Chtěl bych upozornit, že tento topic je doporučen především pro uživatele, co už mají přehled, jak funguje jaká funkce či callbacky. Proto se nechci zdržovat s vysvětlováním některých fcí, které se objeví v tomto topicu. Obsah Ukládání a načítání - Ukázka, jak můžeme jednoduše přejít z dini na y_ini. Příkazy - Ukázka, jak je jednoduché přejít z dcmd na y_commands. Proměnné - Ukázka, jaký je rozdíl práce klasicky s proměnnými a s y_playerarray + y_bit. Formátování - Ukázka, jak nám y_va velice usnadní práci s formátováním například zpráv. Dialogy - Ukázka, jak nám y_dialog pomůže s dialogID a všeobecně s prací s dialogy. Cyklus - Ukázka, jak y_iterate může zjednodušit práci s cyklusem. Callback - Ukázka, jak můžeme jednodušeji hookovat callbacky pomocí y_hooks jinak, než pomocí preprocesoru "ALS". Timer - Ukázka, jak je jednoduché přejít z klasického timeru na y_timers. Použito z knihovny Závěr Ukládání a načítání Ukládání a načítání je docela základní záležitost. Hlavně pro registraci a přihlášení. Ale pracovat na tom s dini je zbytečně zdlouhavé a ještě velice pomalé. Je desítek návodů na dini, samozřejmě i na jeho mnohonásobně lepší variantu dof2, najdou se dokonce návody i na y_ini, ale nikdo je moc nechápe, proto zůstávájí u toho dini s tím, že si myslí, že je to jednodušší. Ale dělat na registraci s y_ini není o nic moc složitější. Tady je taková rychlá jednoduchá registrace přes dini: (INFO Ano, prozatím se nebudeme zdržovat s hashováním hesla. A také nepřidám i ukládání při odchodu, protože je to prakticky to samé, jako je v callbacku s dialogem přihlašování). Teď si ten samý script uděláme pomocí YSI knihovny. V případě, že ostatním funkcím nerozumíte, tak nevadí. Dozvíte se o nich později v topicu. Začneme v OnPlayerConnect(). Především budeme pracovat s podmínkou existence souboru. Můžeme jí nahradit, že v případě, že neexistuje jeho soubor, zobrazí se dialog s registrací, a pokud ano, tak načteme údaje ze souboru(kvůli heslu hlavně), a zobrazíme dialog s přihlašováním. Ano, já vím. Načítám už všechny ostatní údaje (život, adminlevel...), když se ještě ani nepřihlásil. Ale to nevadí, jelikož, pokud nezadá správné heslo, tak se stejně na server nedostane. A když ho zadá správně, tak se nemusíme zdržovat s načítáním už: A nyní vše načteme. Funkce pro načítání si jsou dosti podobné s dini(jak později uvidíte v tabulce). Nebude tak obtížné se je naučit. Všimně te si, že nemusíme už zadávat adresu souboru, odkud to má načítat. Callback už to zná, stejně jako funkce: A nakonec už jen samotné callbacky s dialogy. Oba budou samozřejmě kontrolovat, zda hráč nezadal žádné heslo. U registrace nemusíme zjišťovat, jestli hráčův soubor neexistuje pro vytvoření, jelikož INI_Open ho vytvoří automaticky v případě, že neexistuje, a nesmíme zapomenout soubor zavřít. U přihlášení samozřejmě zkontrolujeme, zda nezadal špatné heslo. Jelikož jsme už údaje načetli, nemusíme naše heslo znova zjišťovat ze souboru, už s naší proměnnou můžeme pracovat rovnou. Stejně jako načítání, i zde jsou callbacky. Musíme přidat i forward: U přihlášení můžeme i přidat zprávu, že se přihlásil. Jinak nemusíme nic více, jelikož vše se jíž načetlo. No, nevím co vy, ale podle mě je to mnohem přehlejší, kratší, jednoduší... a dokonce i mnohem rychlejší jak po stránce tvorby, tak po stránce funkčnosti. To byla jen ukázka, kde jsme použili ukládání 4 základních datových typů (integer, string, float a boolen). Aby jste viděli, že v práci mezi dini a y_ini není tak velký rozdíl, připravil jsem si pro vás 2 tabulky. Obě obsahují dini a y_ini, a obě obsahují fce a informace k nim: Funkce pro ukládání a vepisování údajů [/td] td --> dini YSI Účel Funkce Informace Funkce Informace Vytvořit soubor dini_Create(); - INI_Open INI_Open otevře a zároveň vytvoří sbr v případě, že neexistuje. Používá ještě tag INI: jako mají files File: Zavřít soubor - Zavírá soubor zbytečně při každém vepsání! INI_Close(); - Existence sbr dini_Exists Je to prakticky jen preprocesor fce fexist - - Vepsat tag - - INI_SetTag(); Jde jen o poznámku, ale lze i šikovně využít. Vepsat integer dini_IntSet - INI_WriteInt(); - Vepsat string dini_Set - INI_WriteString(); - Vepsat float dini_FloatSet - INI_WriteFloat(); - Vepsat boolen dini_BoolSet - INI_WriteBool(); - Vepsat hex - - INI_WriteHex(); - Vepsat bin - - INI_WriteBin(); - Funkce pro načítání údajů dini YSI Účel Funkce Informace Funkce Informace Načíst všechny údaje--INI_ParseFile();Všechny fce na načítaní pak stačí přidávat do callbacku.Načíst integerdini_Int-INI_Int();-Načíst stringdini_Get-INI_String();Musíte do fce přidat i délku.Načíst floatdini_Float-INI_Float();-Načíst boolendini_Bool-INI_Bool();-Načíst hex--INI_Hex();-Načíst bin--INI_Bin();- Příkazy Pawn obsahuje sice callback, který zjišťuje, zda hráč zadal příkaz, ale zjistit, co zadal po příkazu (tzv. parametry) není už tak jednoduché. Takže, začátečníkům dělá problémy vytvořit příkazy s id, například /heal [iD_hráče]. Ale na internetu je jednoduché řešení, a to za pomoci includu. Akorát, velká většina skončí u dcmd. Jakmile přidáte do kódu patřičný preprocesor (pro jeho "nahrání"), tak využití je celkem jednoduché a prosté: dcmd_prikaz(playerid, params[]) { Avšak to není všechno. S každým příkazem musíme ještě přidat takovou "funkci" ještě do callbacku OnPlayerCommandText. Nechci se zdržovat s vysvětlováním o co přesně je a co to dělá, ale jde o: public OnPlayerCommandText(playerid, cmdtext[]) { dcmd(prikaz, 6, cmdtext); Není to tak hrozné, ale představte si, že to budete muset psát pro každičký příkaz, a jakmile zapomenete jen jediný, tak nám to nepůjde a budeme se divit proč. Všimněte si, jak je každé přidávání příkazu zpracováno: nejdříve samotné slovíčko dcmd, což je i jméno preprocesoru, díky kterému můžeme naše příkazy přidávat, pak spodní podtržítko a jméno příkazu a nakonec parametry playerid a params. Okej... nyní to porovnáme se zápisem y_commands: YCMD:prikaz(playerid, params[], help) { Jako u dcmd, je také nějaké označení, že přidáváme příkazy s parametrem a to YCMD, pak to pokračuje podobně akorát místo spodního podtržítka je tam dvojtečka a za ní jméno příkazu, a nakonec také parametry playerid a params, včetně help. Parametr help nám vrací true v případě, že hráč napíše příkaz a za ním otazník (například /admins ?), nebo nemusí to být otazník ale cokoliv jiného. Ale, když ho nebudete využívat, nic ne nestane. Nyní, kde je takový rozdíl? Není nějak extrémně velký, pro ukázku obě přidávání příkazu: dcmd_prikaz(playerid, params[]) { YCMD:prikaz(playerid, params[], help) { Rozdíl v zápisu tak velký není ale po stránce funkčnosti je celkem dost značný. Hlavně po stránce rychlosti, jelikož y_commands pracuje na principu, že každý příkaz bere jako nějaké id, jelikož hledání/porovnávání stringu(textu) je mnohem pomalejší. Ale také y_commands obsahuje další vychytávky, například přidávání alternativných příkazů: public OnScriptInit() { Command_AddAltNamed("help", "pomoc"); Nyní, když přidáme příkaz help, tak automaticky už je /help to samé jako /pomoc a nemusíme nikde nic vracet či přidávat znovu obsah příkazu. Nebo také lze jednoduše povolit, zda se hráčovi povede příkaz napsat. V případě, že je mu nastaveno false, bude to pro něj, jako by ten příkaz neexistoval: if (!IsPlayerAdmin(playerid)) { Command_SetPlayerNamed("kick", playerid, false); } Nyní si ukážeme nějakou rozsáhlejší ukázku, například zrovna příkaz /heal [iD_hráče], nejdříve využijeme dcmd: Teď to zkusíme s y_command. První co změníme je naše první slovíčko a to ze dcmd_ na YCMD:. Dále přidáme parametr help. Využijeme již formátované zprávy ze y_va, a nakonec vymažeme naší "funkci" z callbacku: Žádný extra rozdíl, co? Každopádně je to kratší samozřejmě a nemusíme přidávat naší "funkci" do callbacku. Ale jak jsem říkal, po stránce funkčnosti je tam značný rozdíl. Proměnné Další ukázky se už netýkají dini a dcmd, ale spíše, kdyby jste dělali na gamemodu či scriptu, tak jak přejít na YSI a pracovat s knihovnou. V téhle části jde o práci s proměnnými, přesněji s datovým typem boolen a polem. Zkušenější, možná i někteří začátečnicí ví, že ke každé proměnné můžeme přidat pole, a čím větší to pole je, tím více zabírá paměti. Například proměnná: new bool:Promenna[MAX_PLAYERS]; Jak jistě někteří ví, tak MAX_PLAYERS není nic více než jen preprocesor pro číslo 500. Když si nyní trošku započítáme, tak zjistíme z příkladu 500*4 že touto jedinou proměnnou využijeme až 2 000 bajtů. Teď si jich představte například deset. Nemluvě o tom, že některé publikované gamemody se zdrojovým kódem obsahují až stovky takových proměnných. Můžeme využít i char, které nám pole vydělí 4, a využití paměti spadne už na 500 bajtů, ale furt je to dost. Ale, když přidáme proměnnou pomocí y_bite: new BitArray:Promenna<MAX_PLAYERS>; Tak využití paměti spadne už jen na pár desítek bitů(nejsem si jistý přesným číslem). Nojo, ale, když chceme zjistit, jestli má hráč premium, tak jak to uděláme? Jednoduše, přidáme si naší proměnnou(když je to pro hráče hodí se využít y_playerarray): new PlayerArray:bIsPremium<MAX_PLAYERS>; Teď ale příjde ta těžší část. y_playerarray a y_bit používá na zjištění hodnoty a přiřazování hodnot fce. Ale, pokud vám nesedí s nimi pracovat, můžete na to použít preprocesor(ukážeme si později). Použítí pro podmínky(takže zjištění hodnoty): if (Bit_Get(sIsPremium, playerid)) /* v případě, že vlastní premium */ if (!Bit_Get(sIsPremium, playerid)) /* v případě, že nevlastní premium */ Nebo si na to přidáme preprocesor: #define IsPlayerPremium(%0) Bit_Get(bIsPremium, %0) if (IsPlayerPremium(playerid)) /* V případě že vlastní premium */ if (!IsPlayerPremium(playerid)) /* V případě že nevlastní premium */ Pro přiřazení hodnot máme 2 možnosti, a to buď klasické Bit_Set, kterým můžeme přiřadit hodnotu jak true tak i false a nebo využít 2 rychlejší fce: Bit_Set(sIsPremium, playerid, true); /* Nyní vlastní premium */ Bit_Set(sIsPremium, playerid, false); /* Nyní přišel o premium */ Bit_Let(sIsPremium, playerid); /* Nyní vlastní premium */ Bit_Vet(sIsPremium, playerid); /* Nyní přišel o premium */ A toť vše. Že to není tak složité, že ne? A co, když chceme VIP s 3 levely? Řešení je prosté. Prostě využijeme dvojdimenzní proměnnou: new PlayerArray:bIsPremium[3]<MAX_PLAYERS>; Můžeme si říct, že 0 bude Bronze, 1 bude Silver a 2 bude Gold. A pro kontrolu, pokud například není Silver použijeme: if (!Bit_Get(sIsPremium[1], playerid)) return NejsiSilver(); A pro nastavení Silver VIP zase použijeme: Bit_Let(sIsPremium[1], playerid); /* Nyní má VIP level Silver Formátování I když Pawn obsahuje dvě funkce na odeslání zpráv (jednotlivci a nebo všem hráčům na serveru), tak jediné, co může odeslat je text, ale ne nějaké zjištěné hodnoty, například adminlevel toho hráče, jméno toho hráče a podobně. To všechno musíme formátovat. Nojo, ale každé formátování vyžaduje nějakou proměnnou, kterou bude formátovat, pak samotnou fci formátování a pak, co s tím formátováným obsahem (například odeslání zprávy). To už jsou ale 3/4 řádky a jen například na jedinou zprávu. Pro více zpráv je potřeba více řádků a to hrozně zdržuje. Ukážeme si nějaký příklad. Chceme, aby nám do chatu zjistilo několik důležitých informací(pro lepší ukázku příkladu v tomto případě nebudeme využívat nový řádek, aka \n): A to ještě formátujeme jedinou proměnnou neustále. Jsou i uživatelé co neustále formátují další a další proměnné. Ale jak vidíte, je to zdlouhavé, trochu i matoucí a ne zrovna jednoduché, hlavně, kdyby tam bylo více údajů. Ale pomocí y_va to jde velice zjednodušit. Ten už má všechny "prvky"(proměnnou, formátování a akci) už v jednom, takže nemusíme nic formátovat, stačí jenom přidat: Mnohem kratší, jednoduší a přehledější, že ano? A to není vše, také je to rychlejší než obyčejné formátování, jak přes funkci, tak přes preprocesor, dokonce i rychlejši než fce za použitím emitu: Věřím, že jak se to používá, tak je zcela zřejmé. Navíc si můžeme přidat i vlastní va_ fci(je to už složitější), ale y_va už má některé fce již předpřipravené, takže nemusíme je vytvářet. Zde je seznam těch nejdůležitějších, jejich parametry a jejich příklad použití: Dialogy Tohle je velice častý problém mnoha začátečníků ale i několika autorů scriptů. Jelikož fce ShowPlayerDialog(), vyžaduje vepsat ID dialogu, tak si musí každý pawner hlídat, aby nezadával stejná id, jinak by se dialogy křižily a nefungovaly by, jak mají. Na to je hned několik řešení: 1) Tohle je známe především u gamemodů a nebo u větších scriptů, a to místo toho čísla(dialogid) přidat preprocesor s tím číslem, a tak si uživatel pak může následující čísla měnit, aby mu dialogy už fungovaly. 2) Ani tohle není vzácné, a to za dialogid dosadit nějaké obrovské číslo. Například 3000, jelikož nejvyšší možné dialogid je 32767, tak ve většine případech je celkem malá šance, že se zrovna dialogy budou křížit. Ale je tu ještě jedna možnost, a to nezadávat žádné dialogid a to pomocí y_dialog. Ten funguje na principu, že najde nejnižší nepoužívané dialogid (například, pokud zrovna někdo nebo něco nepoužívá dialogid 1, tak ho vezme) a ním pak pracuje. Uživatel má možnost také si nějaké id "zabrat", takže nebude hledat ale bude pracovat jen s tím daným id. Ukážeme si příklad, máme 3 dialogy v nějakém už propracovanějším módě: Je v tom už menší zmatek, a to jsou pouze tři dialogy s listy. Nic méně. Pomocí y_dialog to celé můžeme zkrátit a úplně se vyhnout callbacku OnDialogResponse. Jak je to možné? Můžeme pomocí fce Dialog_ShowCallback, což už sama o sobě něco říká, a to, že veškéré akce daného dialogu budou v patřičném callbacku, který si přidáme. Jak se s tím pracuje, tak vám samozřejmě ukážu. Nejdříve nahradíme fci ShowPlayerDialog, funkcí Dialog_ShowCallback. Ale místo parametr dialogid nedáme nějaké id ale 3 slova a to "using callback dDialogNeco" bez uvozovek. Kdo nerozumí, co to je, tak to znamená, že dění toho dialogu(hráč stiskne tlačítko, hráč klikne na list) se bude odehrát v tom daném callbacku dDialogNeco(z příkladu to jistě pochopíte). Jinak pokračujeme stejně. Jen doporučuji tuhle fci Dialog_ShowCallback u typů dialogů listy, input a password. Na obytečjný text můžete využití obyčejnou fci Dialog_Show(později si ukážeme použití). Tak začneme tím přepsáním: Pak přidáme postupně každý forward a každý callback, jako u normální přidávání callbacku. Nemůžeme to dát do jednoho, musíme to dát samostatně, jinak by to nefungovalo. Nemusíme kontrolovat o jaké jde id dialogu, každý ten callback to ví: Přehledjší, rychlejší, kratší a navíc bez potřeby id dialogu. Ale co, když chceme odeslat obyčejný box, se zprávou, který bude mít jenom tlačítko zavřít? Není problém, můžeme využít obyčejné Dialog_Show. Dialog se po stisknutí na tlačítko Zavřit jednoduše prostě zavře a nic více se nebude dít: Dialog_Show(playerid, DIALOG_STYLE_MSGBOX, "Uvítání", "Vítej na našem serveru", "Zavrit", ""); Cyklus Hodně tvůrců scriptů jistě zná asi nejstarší cyklus na všechny hráče na serveru a to: for(new i; i<MAX_PLAYERS; i++) { if(IsPlayerConnected(i)) { Akorát u několika lidí se moc neosvědčilo kvůli preprocesoru, který není nic více než jen číslo 500. A tak někteří přidávají preprocesor MAX_PLAYER_EX s menším číslem, (nebo jen undefnou MAX_PLAYERS a nahradí novým číslem) například: #define MAX_PLAYER_EX (100) for(new i; i<MAX_PLAYERS_EX; i++) { if(IsPlayerConnected(i)) { Ale to je furt pro několik lidí docela složitě na naučení. A ještě k tomu nedávno se v updatu objevila nová fce, která nám zjistí nejvyšší playerid na serveru a to: for(new i = 0, j = GetPlayerPoolSize(); i <= j; i++) { if(IsPlayerConnected(i)) { Ale zase je i tento způsob pro někoho složitý na naučení. A tak je tu ještě jedna možnost, dost jednoduchá, mnohem rychlejší, a to za pomocí y_iterate/y_foreach. Tam stačí pouze jmého samotného cyklusu z tohoto includu, pak deklarovaná proměnné a, co má ocyklovat: foreach(new i: Player) { } Nyní máme cyklus, který projede všechny přítomné hráče na serveru. Nic více nepotřebujeme a pracujeme stejně jako s cyklusem v první ukázce, akorát je rychlejší, efektivnější a bez nutnosti fce IsPlayerConnected. A přitom to nemusí být zrovna Player, může to být i pro všechny vozidla(Vehicle), všechny BOTy(Bot), všechny charaktery(Character) a nebo všechny actory(Actor). Nebo, si můžeme přidat i vlastní tzv. Iterator, který pak do cyklu dosadíme, který má project. Můžeme například nemovitosti. Chceme, aby nám vypsal všechny volné nemovitosti. Začneme tím, že si určíme maximum nemovitostí a to třeba 10, pak deklarujeme samotný Iterator za pomoci zrovna tagu Iterator a na konec proměnné, které budeme potřebovat. V případě, že chceme, aby tam ty nemovitosti vypsal, tak jednoduše použijeme funkci Iter_Add, ale nejdříve musíme pro něj najít volné místo v cyklusu pomocí Iter_Free. Pak následuje samotný foreach a na konec, pokud chceme, aby nám to nevypsalo jakoukoliv nemovitost, tak jednoduše ten iterator "vyčistíme", pomocí Iter_Clear: Jakto, že nevypíše tu Autodílnu s cenou 1000? Odpověď je prostá. Sice jsme všechny 3 přidali do iterátoru pomocí fce PridatNemovitost, ale v cyklusu foreach podmínkujeme, zda je volná a to naše Autodíla není. Iterator má podle mě velikou škálů využití. Například s ním lze jednoduše vytvořit fci, která vám už rovnou bude přidávat administrátory do /admins: Callback Tato část se týká především tvůrců includů. Asi znáte, že velká škládá fci nebo možností potřebuje patřičný callback, jinak nebudou fungovat, jak mají. A tak vytváří další callback a pak uživatel ho bude muset přidat do hlavního callbacku, který a_samp již obsahuje, například: Což ještě sice není tak hrozné, ale jde furt o jediný callback. Nojo, ale jak jsem říkal, je více udělaných takových to includů, hlavně ty staré, takže to může dopadat i nějak takto: To už je trošku bordel, co? Samozřejmě je úspornější a lepší možnost a to přes preprocesor "ALS". Ale ten není o nic moc jednoduší. Ale je tu ještě 3. možnost. Představte si, že můžete volat 2x stejný callback a nemusíte přidávat nový (přes forward). S y_hooks je to jednoduché. Stačí akorát zaměnit slovíčko public za hook a můžete přidat stejný callback a compiler nebude protestovat: Takhle můžete do include si vesele si přidávat hooky a uživatel nebude muset nikam přidávat volání. Užitečné, že ano? Ukážu nějaké jednoduché využití. Budu mít include, například nějaké úplně jednoduché VIP.inc a v něm: Tak. Nyní jsem si vytvořil include, který obsahuje nastavení proměnné (Bit_Let) aka jeho VIP, a hook, že jakmile se spawne tak mu to nastaví plnou vestu a život, a napíše, že se spawnul VIP hráč. Teď, když si náš include nahrajeme a přejdeme do editoru, kde máme nový list: A to je vše. Jakmile se hráč připojí tak se nastaví VIP. A jakmile se spawne, stane se přesně to, co jsem popisoval před chvilkou. Všimněte si, že nikde nemusím volat OnPlayerSpawn a přidávat do něj nějaký nový callback VIP_OnPlayerSpawn. Snad tohle posune některé include už ku předu trošku. Timer A nakonec timer. Tohle se už týká i té pokročilejší skupiny. Viděl jsem hodně includů či scriptů, kde jak zachází s timery. Od jejich spuštění, po jejich obsah až k zastavení. Timer je snad jedna z nejpoužívanějších funkcí v PAWN. Má hodně velkou škálů využití. Tipy, ochrana, anticheat, eventsystém, porty (ty s 5 sekundovým čekáním), nemovitnosti, dražba a mnoho dalšího. Ale my se zaměříme na nějaké, které lze pomocí YSI4 velice zjednodušit a vylepšit. Například, asi snad každý zná jeden z nejjednoduších scriptů a to tipy. Několik desítek zpráv, které se po nějakém čase odešlou hráčům. Jako ukázku jsem si připravil tipy a k nim 5 zpráv, včetně spuštění a vypnutí: Jak vidíte, i když to jsou obyčejné tipy je to celkem rozsáhlé. Teď zkusíme udělat ty samé tipy zapomocí y_timers. První co, tak můžeme vymazat proměnnou TipyTimer, jelikož y_timers pracuje "s jménem" toho timeru(uvidíme v příkladě), ale může se mu samozřejmě nastavit ID. Dál změníme fci na spouštění na repeat (defer by nám spustil jednom jednou, repeat nám to bude opakovat). Čas nemusíme zadávat, to budeme zadávat až ve fci timer. A nakonec vypnutí opět zaměníme fci KillTimer na obyčejné stop: A to je vše. Není to přecijen jednoduší a kratší? Nemluvě o tom, že je to rychlejší. Ale y_timers také se může široce využít, například když máte příkazy ve VIP a chcete, aby je hráč mohl využít třeba jen 1x za 2 minuty. Ve starších verzích(v některých nových vlastně také) to vypadá nějak následovně: Je to dost vyčerpávající, a to jsou zatím jenom 3 příkazy. Teď na to zkusíme využít y_timers. Můžeme použít, že spolu se spuštěním timeru, nám pošle i pár potřebným argumentů a to id toho hráče a jaký příkaz použil. Takže nebudeme muset přidávat timer na každý příkaz zvlášť ale stačí jediný: Opět mnohem kratší a jednoduší, že ano? Použito z knihovny Include Cesta Alternativní cesta Popis y_ini <YSI_Storage\y_ini> <YSI\y_ini> Ukládání a načítá údaje ze souboru. y_commands <YSI_Visual\y_commands> <YSI\y_commands> Umožňuje pracovat s příkazy a s jejich parametry, plus help. y_bit <YSI_Data\y_bit> <YSI\y_bit> Šetří paměť proměnné boolen(s polem). y_playerarray <YSI_Data\y_playerarray> <YSI\y_playerarray> Šetří paměť proměnné boolen(s polem). Doporučeno na proměnné určené pro hráče. y_va <YSI_Coding\y_va> <YSI\y_va> Umožní pracovat s již formátovanými funkcemi. y_dialog <YSI_Visual\y_dialog> <YSI\y_dialog> Umožní pracovat s dialogy bez nutnosti jim přidělovat id. y_iterate <YSI_Data\y_dialog> <YSI\y_iterate> Umožní pracovat s cyklusem foreach. y_foreach <YSI_Data\y_foreach> <YSI\y_foreach> Alternativní cesta na include y_iterate y_hooks <YSI_Data\y_hooks> <YSI\y_hooks> Umožní jednoduše hookovat callbacky. y_timers <YSI_Data\y_timers> <YSI\y_timers> Práce s timery ze YSI. y_scriptinit <YSI_Coding\y_scriptinit> <YSI\y_scriptinit> Přidává callback, který je možné použít jak ve FS tak v GM. Závěr To je prozadím vše. V případě, že naleznu nějakou další užitečnou zajímavou informaci, přidám jí sem. ! Kódy, kde jsem nevyužíval YSI slouží jako ukázka! Nebyly kontrolovány compilerem a tak se tam můžou vyskytnout chyby. Proto je v žádném případě nepoužívejte! PS: Topic obsahuje skutečně mnoho textu a kódu a tudíž, než ho celý pročtu a zkontroluji, chvilku to potrvá, tak se prosím prozatím zdržte komentářů poukázující na nějakou chybu. Děkuji.
  3. TextDraw namísto GameTextForAll Úvod: Tento návod je zaměřen na TextDrawy a jejich využití namísto GameTextForAll jelikož když máte logo serveru přes TextDraw a použijete GameTextForAll / ForPlayer tak text draw zmizí. Proto jsem se rozhodl udělat provás tento malý TuT. Co potřebujeme(?): TextDraw Editor by Zamaroht(http://samp-scripts.com/post/11314/[0.3x_RC1+]_Zamaroht_TextDraw_Editor_with_Model_Previews/adri1/filterscript/other) Vysvětlení: Budeme pracovat s dcmd které nám usnadní v tomto práci, také budeme pracovat se stringama. Zapotřebí je testovací server aby jste mohli vytvořit grafickou předlohu. Ve hře si vytvořímte grafickou předlohu kterou pak uložíte. Jděte do scriptfiles a otevřete textový dokument (s názvem vašeho projektu) a tam máte vše co potřebujete (zkopírujete kód který vypadá nějak takto: Textdraw0 = TextDrawCreate(410.000000, 200.000000, "Tvůj text"); TextDrawBackgroundColor(Textdraw0, 255);TextDrawFont(Textdraw0, 1); TextDrawLetterSize(Textdraw0, 0.500000, 1.000000);TextDrawColor(Textdraw0, -2139062017); TextDrawSetOutline(Textdraw0, 0);TextDrawSetProportional(Textdraw0, 1); TextDrawSetShadow(Textdraw0, 1);TextDrawUseBox(Textdraw0, 1); TextDrawBoxColor(Textdraw0, -2139062017); TextDrawTextSize(Textdraw0, 490.000000, 10.000000); Nahoře do GM / FS dáme #define Textdraw0 (nebo jaké číslo vám to tam hodí) aby nám to fungovalo dáme nahoře do mádu definici dcmd. #define dcmd(%1,%2,%3) if ((strcmp((%3)[1], #%1, true, (%2)) == 0) && ((((%3)[(%2) + 1] == 0) && (dcmd_%1(playerid, "")))||(((%3)[(%2) + 1] == 32) && (dcmd_%1(playerid, (%3)[(%2) + 2]))))) return 1 Příklad: A teď se dostáváme k samotném tvoření "dannu". do OnGameModeInit() dáme celý kód který vám to vyhodí do scripfiles. (ten kód který je nahoře ale VÁŠ kód). Pak dáte Úplně dolů dáme dcmd ve kterém bude náš příkaz a za ním (playerid,params[]) dcmd_dann(playerid,params[]) Aby nám neházelo upozornění dáme pod toto { #pragma unused playerid Teď jsme se dostali k samotnému nastavení textu. TextDrawSetString(Textdraw0,params); Pokud máte Textdraw5 nebo jiné číslo tak ho musíte udělat i zde! Teď dáme ještě že po zadání příkazu se tento TextDraw ukáže všem hráčům. TextDrawShowForAll(Textdraw0); return 1; } Teď jdeme do OnPlayerCommandText a dáme sem definici pro naše dcmd. zadáme někam do toho publicu: dcmd(dann,4,cmdtext); dcmd(dann = příkaz 4 = počet písmen na rozeznání příkazu cmdtext = text v příkazu Tipy: Na serveru když zadáte /dann [TEXT] tak pro změnu barev dejte ~r~ (červená) podle této tabulky se podívejte na barvy - ~n~ = New line ~r~ = Red ~g~ = Green ~b~ = Blue ~w~ = White ~y~ = Yellow ~p~ = Purple ~l~ = Black ~h~ = Turns text lighter ~u~ = Grey up arrow ~d~ = Grey down arrow ~~ = Grey right arrow ( http://weedarr.wikidot.com/game-text#toc8 ) Závěr: Toto by bylo z tohoto TuT vše, pokud máte nějaké návrhy na rychlejší úpravu nebo něco takového tak uričtě pište Pokud by vám to nefungovalo pište zprávu. ( )
×
×
  • Create New...