DuFF

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ť.

Off topic: Z hodín štatistiky som si síce veľa neodniesol, ale zaujímalo by ma, prečo by si chcel normálne rozdelenie. Pokiaľ viem, v normálnom rozdelení má najvyššiu pravdepodobnosť výskytu priemerná hodnota a táto pravdepodobnosť so vzdialenosťou od priemernej hodnoty klesá. Ak by teda funkcia random generovala čísla takýmto spôsobom, znamenalo by to, že by niektoré čísla boli generované častejšie ako iné (v tomto konkrétnom prípade by boli nejaké ID vyberané častejšie ako iné). Myslím si, že v tomto prípade chceš skôr rovnomerné rozdelenie, v ktorom majú všetky hodnoty (z daného intervalu) rovnakú pravdepodobnosť výskytu. Trochu som testoval som funkciu random a mám pocit, že sa všetky čísla generujú s rovnakou pravdepodobnosťou (čo je asi presne to, čo chceme, pretože každý hráč by mal mať rovnakú šancu na to, aby bol vybraný).

To máš samozrejme pravdu, ale teraz sa bavíme o čisto abstraktnej triede (pure abstract class), ktorá obsahuje iba dekladárie metód, neobsahuje žiadnu implementáciu a nemá ani žiadne data members. C++ nemá (na rozdiel od C#, Javy, ...) interface keyword a rieši sa to práve pomocou týchto čisto abstraktných tried.

Zdar, predpokladám, že tým "Alespoň jednou bude v projektu implementováno dynamické pole objektů jiné třídy" sa myslí, že máš v kóde použiť std::vector. Čisto abstraktná trieda je taká trieda, ktorá obsahuje iba deklarácie (a nie definície) metód. Ak máš skúsenosť s inými objektovo orientovanými jazykmi (napr. C#, Java, ...), tak to poznáš pod názvom interface.

Nazdar, práve som testoval na localhoste (Windows) a na fakahede (casa1, Linux) tento kód: V súbore server_chatlog_utf8.txt boli na obidvoch strojoch niektoré znaky zapísané nesprávne, ale v súbore server_chatlog_eascii.txt bolo na obidvoch strojoch všetko zapísané správne. Skús to možno tiež spustiť u seba a daj vedieť, aký si dostal výsledok. Ako píše Delete, skús výsledné súbory aj stiahnuť a pozrieť v inom editore.

Posledná verzia samp serveru je 0.3.7-R2 (na ktorej server tento beží) a na túto verziu serveru nie je problém pripojiť sa s akýmkoľvek klientom minimálne z možností 0.3.7-R1, 0.3.7-R2, 0.3.7-R3 a 0.3.7-R4, pričom 0.3.7-R4 je posledná verzia klienta. Navyše RC vo verzii znamená "release candidate", a teda verzie 0.3.7-RC2 a 0.3.7-R2 nie sú jedna a tá samá verzia.

V kóde máš definovanú funkciu strtok (bez modifikátoru stock) a nikde ju nepoužívaš. Funkciu nemusíš nikde použiť. Stačí pred ňu pridať modifikátor stock. Práve k tomuto modifikátor stock slúži - dovolí kompileru ignorovať nepoužité funkcie (čo sa hodí hlavne v includoch, pretože takmer nikdy nevyužiješ všetky funkcie z include). Vo svojom prípade si ešte môžeš rozmyslieť, či danú funkciu v kóde naozaj potrebuješ a prípadne ju môžeš úplne odstrániť.

Momentálne tam má viditeľný array index out of bounds na riadkoch: format(string, 256, "%s %s dal hráčovi %s VIP %s na %d dní !", GetAdminRank(playerid),PlayerName(playerid),PlayerName(id),viptarif,strval(params[days])); DOF2_SetInt(UserPath(id),"VIP_Days", strval(params[days])); (napríklad ak zadám príkaz /setvip 0 3 99, strval(params[99]) určite nespraví nič dobré) Ak by sa držal doporučenia pracovať iba so sscanf, tento problém by odstránil a vedeli by sme, či pády spôsobovalo toto, alebo niečo iné.

Prečo kombinuješ chrfind a strval so sscanf? Keď parametre načítaš pomocou sscanf, žiadne chrfind a strval nemusíš ďalej riešiť a môžeš pracovať priamo s premennými, do ktorých ti sscanf uložil nájdené hodnoty parametrov.