DuFF

Zo zoznamu, ktorý si napísal, používajú pluginy iba sscanf a streamer. U ostatných by ti mali stačiť tie verzie, ktoré aktuálne používaš. Odkazy: https://github.com/Y-Less/sscanf/releases https://github.com/samp-incognito/samp-streamer-plugin/releases Stiahni si najnovší release, .so/.dll (podľa toho, či ti beží server na Linuxe, alebo na Windowse) daj do serverovej zložky "plugins" a .inc súbory si vlož do zložky "include" do pawna, ktorým následne skompiluješ mód.

Mód si skompiloval s includmi, ktorých verzie nie sú kompatibilné s verziami pluginov (.so / .dll) ktoré ti bežia na serveri. Doporučujem ísť na oficiálny github pluginov, ktoré používaš, a stiahnuť si tam najnovší release pluginu spolu s includom. https://github.com/samp-incognito/samp-streamer-plugin/releases

Ak niekomu nastavíš hp na 0 alebo sa zabije sám pádom, ohňom, výbuchom, utopením, ..., počítaj s tým, že killerid je INVALID_PLAYER_ID (65535). Ak používaš index killerid na prístup do nejakého poľa, tak ti to tam spadne na ArrayIndexOfBoundsException. Z tohto dôvodu sa kód, ktorý robí niečo s killerid, zvykne dávať do tela podmienky if (killerid != INVALID_PLAYER_ID). Je možné, že niečo také robíš v UpdatePlayerKills. Inak na odhalenie takýchto chýb určite použi crashdetect plugin

Chcelo sa po tebe, aby si odstránil ten cyklus, ale jeho telo tam nechal (aby sa vykonalo iba raz). V tom tele potom musíš ešte prepísať SCM na SCMTA ako som písal vyššie

Ja som nepochopil ten for cyklus cez všetkých hráčov (v PHY_OnObjectUpdate). Pozerám to síce na mobile o 3 ráno a je veľmi možné, že mi niečo uniká, ale jediný výskyt premennej i vidím v SendClientMessage, čo by si mohol nahradiť SendClientMessageToAll a vonkajší for cyklus by sa dal odstrániť.

To znie ako keby ti to blokoval antivírus

Najčastejšia chyba býva, že človek nemá nainštalovanú samp 0.3.7-R1. Skontroluj si, že máš naozaj verziu R1 a nie nejakú inú.

Zdar, mohol by si ukázať screenshot, ako vyzerá v hre dialog DIALOG_MISE_HOTEL a priložiť aj riadok so ShowPlayerDialog, kde ho zobrazuješ? Používaš tam správny štýl dialogu? Všimol si, že ti na konci tela case DIALOG_MISE_HOTEL chýba return 1, a tak sa ti to môže biť s inými dialogmi.

Detail: "IP sa delí na štyri 8-bitové čísla (číslo v rozsahu 0 – 255), ktoré sa zapisujú v desiatkovej sústave oddelené bodkou."

Ak si nikdy nepracoval s ukladaním dát, databáza môže byť príliš veľký skok. Napadlo mi riešenie, ktoré nie je úplne ideálne, ale mal by si ho zvládnuť naprogramovať sám: Navrhujem vytvoriť si v scriptfiles priečinok "available_vouchers", do ktorého si budeš ukladať dostupné kódy. Ak budeš chcieť pridať nejaký nový kód, iba vytvoríš súbor "available_vouchers/<kód>" - teda napríklad pre pridanie kódu 5555 5555 5555 5555 by si vytvoril súbor "available_vouchers/5555 5555 5555 5555" (využiješ fopen s módom io_write). Keď hráč zadá kód do dialogu, najskôr overíš, či je kód dostupný - zistíš, či existuje súbor "available_vouchers/<kód, ktorý ti hráč zadal>" (využiješ fexist). Pre zvýšenú bezpečnosť si predtým môžeš skontrolovať, že jeho vstup neobsahuje iné znaky ako 0-9 a medzery. Ak je kód dostupný, dáš hráčovi odmenu a súbor "available_vouchers/<kód, ktorý ti hráč zadal>" vymažeš (využiješ fremove). // Edit: V mojom predošlom riešení nebolo domyslené pridávanie kódov

Nejde o chyby, ale o príliš detailné logovanie. Niekde v kóde máš pravdepodobne riadok mysql_log(ALL). Toto zapne logovanie aj info a debug správ, ktoré ťa pravdepodobne nezaujímajú. Väčšinou ti stačí logovanie errorov a warningov: mysql_log(ERROR | WARNING);

Pamätám si, že s rcon gmx boli nejaké problémy pri používaní filterscriptov. Konkrétne mám pocit, že to nevyvolá OnFilterScriptExit (a následne OnFilterScriptInit), ale fakt si nie som istý - radšej si to testni.

Kód, ktorý si poslal, má na starosti vkladanie dát do databázy a vyzerá to tak, že tam máš preklep. V poslednom argumente si použil Player[ID][NickName] a myslím si, že tam chceš skôr Player[ID][AdminLevelHodnost]. HighPrint chcel vidieť ten enum, v ktorom máš AdminLevelHodnost a riadok new Player... Okrem tohto by si mohol poslať ešte kód, v ktorom máš načítavanie dát z databázy.

Ak chápem správne, že tento kód si používal pôvodne a teraz ťa zaujíma, ako v mysql zistiť, či je hráč (ne)registrovaný, môžeš to skúsiť touto funkciou. Nezabudni si upraviť názov tabuľky (players) a názov stĺpca (nick) tak, aby to sedelo s tvojou databázou. stock IsNickRegistered(MySQL:dbHandle, const nick[]) { new query[128]; mysql_format(dbHandle, query, sizeof(query), "SELECT COUNT(*) FROM `players` WHERE `nick`='%s'", nick); mysql_query(dbHandle, query); new found; cache_get_value_index_int(0, 0, found); return found; }

Ďalšia možnosť je použiť Streamer plugin, pomocou CreateDynamicRectangle vytvoriť zóny a používať callbacky OnPlayerEnterDynamicArea a OnPlayerLeaveDynamicArea. Ak to urobíš takto, môžeš si do zóny uložiť aj nejaké dáta - napríklad index do poľa s názvami zón. Potom by si nemusel vždy prechádzať zoznam všetkých zón na to, aby si zistil, do ktorej zóny hráč vošiel a aký text mu máš zobraziť. Toto by si docielil pomocou Streamer_SetArrayData a Streamer_GetArrayData (array kvôli tomu, že okrem indexu názvu zóny budeš ukladať aj iné informácie - napríklad unikátne ID scriptu, aby sa ti to nebilo s inými scriptami).

Skontroluj si, či si do query nezabudol vložiť nejaké čiarky (napríklad medzi y a angle, prípadne na ďalšie miesta).

Ahoj, nejde o chybu špecifickú pre MySQL plugin. SZ1.pwn(19529) : error 075: input line too long (after substitutions) ti hovorí, že riadok číslo 19529 v súbore SZ1.pwn je príliš dlhý (do dĺžky riadka sa počítajú aj znaky v ďalších riadkoch, ktoré si pridal pomocou \). Ak si správne spomínam, ZeeXov compiler umožňuje používať aj dlhšie riadky. Ak by sa ti nepodarilo spojazdniť ten compiler, môžeš skúsiť to query formátovať postupne po častiach a tie potom pospájať do výsledného query (napr. cez strcat). Keď sa ti podarí túto chybu s dlhým riadkom odstrániť, ešte si potom rozmysli, či ti v new query[145]; stačí 145 (144) znakov na uloženie celého toho dlhého query.

Ak chceš presunúť hráča, ktorý nešoféruje, jednoducho použiješ SetPlayerPos na zmenu pozície a SetPlayerVirtualWorld na zmenu virtuálneho sveta. Ak hráč šoféruje, presunieš do virtuálneho sveta (okrem hráča) aj jeho vozidlo (použiješ GetPlayerVehicleID na zistenie ID vozidla a SetVehicleVirtualWorld na zmenu virtuálneho sveta). Pozíciu tohto vozidla potom zmeníš klasicky cez SetVehiclePos. Potom ešte záleží, či chceš spolu s vozidlom presúvať aj všetkých pasažierov, alebo aj hráčov, ktorí sú na jeho streche. Toto by si mohol docieliť pomocou cyklu, ktorým by si prešiel všetkých pripojených hráčov a overil by si, či hráči sedia v danom vozidle (GetPlayerVehicleID), prípadne či "surfujú" na jeho streche (GetPlayerSurfingVehicleID). Ak áno, nastavil by si virtuálny svet aj im. PS: Nie som si istý, či po zmene pozície/virtuálneho sveta vozidla z neho nevyhodí hráčov. Ak by sa to náhodou dialo, môžeš ich vrátiť naspäť do vozidla pomocou PutPlayerInVehicle (a predtým GetPlayerVehicleSeat, aby si vedel, kam ich usadiť).

Streamer plugin má v CreateDynamicObject (voliteľný) parameter worldid. Ak použiješ worldid iné ako -1, vytvorený objekt bude viditeľný iba v tom svete.

Práve som testoval všetky ponúkané riešenia (svoje, obidve Scydove a ATomasovo) týmto scriptom: Výstup: Moje pôvodné riešenie vyzerá, že funguje správne.

Nemám to otestované, ale niečo takéto by mohlo fungovať:

Takto by mohlo vyzerať riešenie pomocou spomínaného include inline-sort na zoradenie hráčov (a napríklad ZCMD na vytvorenie príkazu):

Zdravím, najskôr skúsim pre istotu vysvetliť, prečo sa vypisujú mená a skóre hráčov v takom poradí, v akom sa vypisujú: Predpokladám, že aktuálne kód vyzerá približne takto: Ako bolo povedané - ide o klasický for cyklus. Do premennej i sa na začiatku uloží hodnota 0 a následne sa vykoná telo cyklu. To znamená, že sa overí, či je hráč s ID 0 pripojený, a ak áno, vypíše sa jeho nick a skóre všetkým hráčom do chatu. Následne hodnota i stúpne o 1. Potom sa overí, či je hodnota uložená v premennej i menšia ako MAX_PLAYERS, a ak je, opäť sa vykoná telo cyklu s tým, že v i bude uložená hodnota 1. Teda sa overí, či je pripojený hráč s ID 1, a ak je, vypíše sa do chatu jeho nick a skóre. Týmto spôsobom sa pokračuje až dovtedy, kým neprestane platiť podmienka i < MAX_PLAYERS. Teraz k riešeniu problému: Problém je možné riešiť uložením si ID hráčov do nejakého poľa a následným zoradením tohto podľa takým spôsobom, že ak má napr. ID 3 vyššie skóre ako ID 1, tak bude ID 3 uložené v poli na nižšom indexe ako ID 1. Keď je už pole takto zoradené, nie je problém (for cyklom) prejsť postupne jeho prvky (od najnižších indexov k najvyšším) a vypisovať nicky a skóre. Na zoradenie poľa existuje množstvo algoritmov, z ktorých má každý nejaké výhody a nevýhody. Môžem spomenúť napríklad Bubble sort, Insertion sort, Merge sort, Heapsort, ... Implementácia nejakého z týchto algoritmov nemusí byť pre začiatočníka jednoduchá. Preto uvediem aj odkaz na include, pomocou ktorého je možné zoradiť pole celkom pohodlne (a využíva Merge sort). V spodnej časti stránky je aj príklad použitia tohto include, v ktorom sa rieši presne tento problém - zoradenie hráčov podľa ich skóre.

Budeš potrebovať súradnice bodu, z ktorého začínaš ťahanie myšou. Keď prvýkrát zistíš, že bola stlačená myš v oblasti menu, ulož si aktuálnu pozíciu myši do nejakej premennej (napr. dragStart). Ďalej si ulož vzdialenosti dragStart od ľavého horného bodu menu na osiach x a y (napr. dragOffsetX = dragStart.x - AikoData.X; dragOffsetY = dragStart.y - AikoData.Y). Je dôležité, aby si tieto vzdialenosti už ďalej počas ťahania myšou neprepisoval (chceš tam mať uložené rovnaké hodnoty počas celej doby ťahania). Počas ťahania myšou budú potom nové súradnice ľavého horného bodu menu x = mouse.x - dragOffsetX a y = mouse.y - dragOffsetY (kde mouse je aktuálna pozícia myši). Pytagorovu vetu nebudeš potrebovať.