DuFF

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.