Ez a szekció lehetővé teszi a felhasználó által írt összes hozzászólás megtekintését. Vedd figyelembe, hogy csak azokba a fórumokba írt hozzászólásokat látod, amelyekhez hozzáférésed van.
Ez a kódsor úgy ahogy van kuka. Nem is értem hogy miért szerver oldalon ellenőrzöd hogy a két jelszó egyezik-e, illetve hogy a felhasználónév tartalmaz-e minimum 5 karaktert. A dbQuery rész is úgy ahogy van rossz, ha callback-et használsz a kód ugyan úgyfutni fog tovább, csak jelen esetben mivel egyedül teszteled nem lesz elváltozás. Ilyen esetekben közvetlenül a callback-be írd azt hogy mi fusson le akkor ha például a játékos még nem regisztrált, illetve a felhasználónevet és a serial ellenőrzés is megoldható egyetlen sql query-ben. A másik, hogy az az id is amivel a játékos regisztrál rosszul van lekérdezve, mivel az az exportált \"query_free\" callback nélkül kéri le az értéket, így nagyobb lesz a szerver oldali cpu használat, erre az mta wiki is figyelmezetet. Ilyen esetben dbExec-el vidd be az adatot, majd dbQuery-vel kérdezd le az utoljára bevitt ID-t. (Ahogy látom, te nem csinálsz semmit az ID-vel szóval feleslegesen kérezed le, szóval a példában lévő dbQuery rész hanyagolható) Példa:
dbExec(sql, \"INSERT INTO test SET a=1, b=2\") dbQuery(function(qh) local res,rows,err=dbPoll(qh,0) if rows > 0 then local id = res[1][\"id\"] outputChatBox(id) end end, sql, \"SELECT id FROM test WHERE id = LAST_INSERT_ID()\")
Amúgy pedig a 24. sorodban ott egy ( szóval ne csodálkozz ha hiba üzenetet ír a debug. Valamint, az mta adatbázis funkcióknál teljesen felesleges az escape string, mivel alapból megteszi helyetted ha jól írod meg a query-t. Példa:
dbExec(sql, \"INSERT INTO test SET a=?,b=?\", 1, 2)
Ez a chates \"optimizáció\" nem ér semmit sem. Ahogyan DrAkE is leírta, amikor elküldesz egy üzenetet azt még mindig fogadja a szerver, így van kliens-szerver közötti szinkronizáció a továbbiakban is. Te most írtál feleslegesen egy saját szinkronizációt. Duplán fogadja az üzeneteket így a szerver, ergo csak feleslegesen terheled az internetet meg még egyéb mást.
Ez a chates \"optimizáció\" nem ér semmit sem. Ahogyan DrAkE is leírta, amikor elküldesz egy üzenetet azt még mindig fogadja a szerver, így van kliens-szerver közötti szinkronizáció a továbbiakban is. Te most írtál feleslegesen egy saját szinkronizációt. Duplán fogadja az üzeneteket így a szerver, ergo csak feleslegesen terheled az internetet meg még egyéb mást.
Én, mint Pawn szkripterként is megmondom hogy a timeres megoldás csak egy CPU evő bullshit. js
Mint azt már írtam, ilyen kis dolgoknál nem számít.
Ne haragudj Xenius de ha fingod sincs valamiről akkor ne beszélj bele, mert már a faszságaidon röhögök fél órája. Hogy az isten faszába ne hívná már meg az RPC-t a kliens a szerveren, ha beírsz egy parancsot? Ha már a szerveren le kell kezeljed a cancelEvent()-et ahhoz, hogy ne történjen semmi, az már elég nagy jele annak, hogy a kommnunikáció megtörtént.
[/quote] Ha nem érted a lényeget, ne szólj bele, nyugodtan csinálhasz bármit, nekem van igazam.
ATTÓL HOGY CANCELEVENTEZED A SZÁJBAKÚRT EVENTET MÉG A KLIENS ELKÜLDI A SZERVERNEK AZ ÜZENETET, ÉS A SZERVER FOGADNI IS FOGJA AZ ÜZENETET! U.I.: Ha már optimalizációról beszélünk, nem tudom ki futtatja MTA szerverét Windowson.
Attól hogy elküldi a szervernek, semmit sem fog vele csinálni mivel a cancelEvent megállítja. Amúgy pedig Windows-on jobban fut az MTA, és ezt olyanok ajánlották nekünk akikhez képest te semmi nem is vagy és nem is leszel. + Ameddig én szépen beszélek veled, addig elvárom ugyan ezt.
Hidd el, nem Te vagy az egyetlen ember itt fórumon, aki ért programozáshoz. Én C++ - Lua közötti kommunikációval is foglalkoztam, illetve írtam is Lua plugint SA-MPra, szóval tudom, mi hogy működik, de azért köszi. Viszont szomorú, hogy még ilyen szar helyzetben is próbálsz \"okosnak\" tűnni
Az is szomorú, hogy nem vagy képes ésszerűen gondolkozni, nem 40-50 emberre scriptelek mint a fórum többsége, az mta pedig mérföldekkel másképp működik mint egy sampos lua plugin, 3 éve foglalkozom az MTA-val ne akard megmagyarázni hogy mi hogyan működik. A magyar mentalitás is kibaszott vicces, segíteni próbálok a kezdőknek erre jönnek az olyan okoskodó hozzá nem értő emberek mint te.
[/quote] Attól, hogy 3 éve programozol, nem jelenti azt, hogy ismered is a kliens - szerver kommunikációt, meg a Lua felépítését. A Te kódodat szimplán elkezdi spammelni egy emberke, akkor meghívódik a kliens oldali say parancs, triggerServerEventezel egyet, és elküldöd a szöveget. Csak az a gond, hogy közben az ALAP MTA SAY PARANCSA MÉG UGYAN ÚGY OTT VAN, ÉS MEGFOG HÍVÓDNI, ÉS ELFOGJA KÜLDENI AZ ÜZENETET. A szerver oldali scriptemben mellesleg semmi megterhelő nincs, mivel egy érték állítás van (2 secenként, vagy amikor lejárt a spam protection), meg egy érték vizsgálat
Drake az hogy jó seggeket nyaltál és kaptál ide egy lokális moderátort nem jelenti azt hogy letettél annyit az asztalra mint Xenius, vagy hogy érsz bármit is
[/quote] Egyrészt, több mindent tettem már alapból a közösségért, mint Te és Xenius tettetek, és valaha is fogtok. Szomorú azt is látni, hogy Xenius hívta a kis csicskáját, hogy \"2v1\"-be megpróbáljanak lenyomni (magyar mentalitás). Attól függetlenül még ugyan úgy szar Xenius megoldása, és le is írtam miért. Ha akarod megnézheted a munkáimat, C++-ban, PAWNban, na meg Luaban is ^^ Peace.
[/quote] Nem fog lefutni az alap say parancs, mivel az onPlayerChat blokkolja (cancelEvent) Amúgy pedig nem teljesen érted még mindig, az azért triggereli be a kliens a táblában lévő elementeknek a dolgokat mert ha ugyan ezt megcsinálnád egy szerver oldali for ciklussal és úgy iratnád ki a chatbe a dolgokat akkor az egyrészt szinkronizálja a kliensel, ergo adatot küld neki és a kliens válaszol a szervernek hogy oké-e, ha például kilép egy játékos és közben iratod ki szerver oldalon neki akkor kapsz debugba egy szép kis hibaüzenetet mert a kliens nem fog válaszolni. Plusz még mellette szerver oldalon lefutna még pár funkció (például nálunk a nyelv rendszer, illetve a játékos név sem sima getPlayerName), ha ezeket használnád / használnánk szerver oldalon akkor egy szép nagy cpu használatot kapnánk 300 embernél szerver oldalon. A te példádhoz hasonló dolgot használtunk, viszont 200 felett 5-6% szerveroldali cpu terhelés volt, és a szerver laggolt. Ezzel amit én írtam legfelül 0.16% a szerver oldali cpu használat, a kliens oldali is 0.1-0.2 közt van mivel a szerver csak a közeli playerekkel szinkronizál így ha kis pista ír a map egyik végén akkor kis józsinak nem fogja szinkronizálni, mert kis pista gépe nem küldi el kis józsi azonosítóját (element) a szerver oldalnak, így a szerver oldal nem fogja triggerelni kis józsinak amit kis pista ír. Dupla hozzászólás automatikusan összefûzve. ( 2015. augusztus 27. - 20:24:13 )
Felesleges tovább húzni a szót, meglátjuk kinek a szervere a működőképes hosszútávon 300 playernél és kinek nem. Azon hogy egy kutya vagy és csak ugatni tudsz, sajnos józan szavakkal nem tudok változtatni. :*
[/quote] te pedig fejezd be, nem csak saját magad minősíted ezzel
Hidd el, nem Te vagy az egyetlen ember itt fórumon, aki ért programozáshoz. Én C++ - Lua közötti kommunikációval is foglalkoztam, illetve írtam is Lua plugint SA-MPra, szóval tudom, mi hogy működik, de azért köszi. Viszont szomorú, hogy még ilyen szar helyzetben is próbálsz \"okosnak\" tűnni
Az is szomorú, hogy nem vagy képes ésszerűen gondolkozni, nem 40-50 emberre scriptelek mint a fórum többsége, az mta pedig mérföldekkel másképp működik mint egy sampos lua plugin, 3 éve foglalkozom az MTA-val ne akard megmagyarázni hogy mi hogyan működik. A magyar mentalitás is kibaszott vicces, segíteni próbálok a kezdőknek erre jönnek az olyan okoskodó hozzá nem értő emberek mint te.
szerveroldal használata nélkül adatokat közölni kliens-kliens közt
Alapból hülyeség, hiszen a kliens elküldi először a szervernek az adatot, utána pedig a szerver küldi el a többi kliensnek az adatot, tehát már alapból nem lesz kliens-kliens kommunikáció. Másrészt, Te fogod, és tiltod az eventet, majd csinálsz kliens oldalon egy \"/say\" parancsot kliens oldalon. Ez mind szép és jó, csak ha írsz a chatbe, akkor 2X! küldi el ugyanazt az üzenetet. Egyszer ugye az alap MTA say parancsa, utána pedig a kliens oldali say parancs. Ezzel már alapból tönkrebasztad a(z) \"Szerver optimalizáció\"-t, és \"sok sok\" netet elhasználsz. Ha annyira akarsz spam protectiont, meg lokális chatet, írtam neked egy nagyon szép, és rövidkét:
local antiSpam = {} function sendMessageToNearbyPlayers(player, dist, message) local x,y,z = getElementPosition(player) local myDim = getElementDimension(player) local myInt = getElementInterior(player) for k,v in ipairs(getElementsByType(\"player\", root, true)) do if myDim == getElementDimension(v) and myInt == getElementInterior(v) then local distance = getDistanceBetweenPoints3D(x, y, z, getElementPosition(v)) if distance <= dist then outputChatBox(getPlayerName(player) .. \"#FFFFFF mondja: \" .. message, v, 255, 255, 255, true) end end end end addEventHandler(\"onPlayerChat\", root, function(message, messageType) if not antiSpam[source] or antiSpam[source] < getTickCount() then antiSpam[source] = getTickCount() + 2000 sendMessageToNearbyPlayers(source, 20, message) end cancelEvent() end)
Legközelebb inkább gondolkodj el, hogyan is működik egy kliens - szerver kommunikáció. Peace.
[/quote] \"szerveroldal használata nélkül adatokat közölni kliens-kliens közt\" - ezt a régi rendszerre írtam. amúgy pedig nem fogja kétszer kiírni, tájékozódj jobban mielőtt hülyeséget írsz. a szerveroldali spam védelem pedig alapból fail, amit írtál kód, az teljesen használhatatlan. lehet hogy 50 embernél nem fog nagyobb gondot okozni, viszont 200-300 embernél már meg fogod érezni. \"Nem mindegy hogy a hülye okoskodik vagy hogy az okos hülyéskedik-\"
Bocsánat, a kliens oldalit elnéztem, viszont szerintem még mindig kézenfekvőbb a getTickCount. A colshapeba is lehet igazad, mert az összes elementet nézi.
Kliens oldalon van a getElementsByType funkciónak egy plusz paramétere, amivel csak a be streamelt elementeket kéri le. Amúgy meg tick count vagy timer, ilyen kis dolgoknál nem számít semmit hogy melyiket használod.
Ezek a timerek.. Játszik péld 200 játékos és 200 timer elindul akár egyidőben 2 másodpercre. Semmi értelme nincs. Erre van a getTickCount nevű funkció. A nearbyplayerst egyszerűbben temp colshapeval is meglehetne oldani, bár ez sem rossz, csak gondolom a C++-os colshape gyorsabban lefutna mint ez.
Milyen timerről beszélsz? Ez csak egyszer fut le kliens oldalon, 2 másodpercenként 1x enged írni. Amúgy pedik nem létezik ennél jobb megoldás, colshape-val is csak zabáltatod a cpu-t. A getNearbyPlayers csak azokat a játékosokat kéri le akik a közeledben vannak (getElementsByType(\"players\", root, true)). Máskor nézd meg jobban a dolgokat, mielőtt hülyeségeket írsz.
Üzenetek megjelenítése
![](\"http://puu.sh/jQFja/0c7ab320ff.png\"){kind=link}
![](\"http://puu.sh/jQFzR/d7d81bb7a0.png\"){kind=link}