Ebben viszont maximálisan egyetértek Hektorral. Hogyan várod el, hogy akárki megváltozzon a szerveren, ha te nem teszel semmit azért, hogy a szabályszegõk (akár adminok, akár playerek) megkapják a büntetésüket. Valóban minimum egy pindurkát abszurd az, hogy a problémákat úgy oldjátok meg, hogy \"hát én nem tudok vele mit csinálni, ne engem hibáztassatok\" - fõleg, ha az a személy éppen a tulaj.
Ez semmi, csak a fej homokba dugása.

Túl sokat gondoltok bele. Igazuk van azoknak, akiknek ezeket a szemétdombokat üzemeltetik: \"ha nem tetszik, nem nézel rá\".
Köszönöm a szemétdomb kifejezést. Te magad sem vagy épp az RP megtestesítõje - noha bajom nincs veled,de azért ez az ócsárolás ez sok
 

Te viszont vedd figyelembe, hogy én ezt elsõsorban nem a See RPG-re gondoltam, hanem azokra a 8-10 éves emberekre, akik nyitják a topicokat az új szerverüknek 3 soros leírással, majd mikor szólva van nekik, hogy ez rossz, válaszolnak rá, hogy: \"ha nem tetszik ne nézzél rá amúgy is cuccvisszaadás van!\". Vagyis a tucatszerverekrõl van szó, amik tényleg megközelítik egy-egy személtlerakó minõségét.
A See RPG-s témát késõbb vették fel az emberek és ha észreveszed, nem is néztem ezt a témát idõszakosan. Már egy ideje fut a See RPG, és bár nem a legkedvesebb szerver a szememben, de színvonalban (ha nem is player színvonalban, de a szerver színvonalában) felülmúlja a legtöbb olyan szervert, amiket én szemétdombnak neveznék. Azzal azonban még mindig egyetértek, hogy azok a játékosok, akik jelenleg játszanak az ilyen szervereken, és hülyék az RP-hez (ez a playerekre vonatkozik elsõsorban, ismét), jobb, ha olyan helyen maradnak, ahol ezt tolerálják/muszáj tolerálniuk, ez itt akár a See RPG-re is vonatkozhat.
Azt sehol sem írtam, hogy az életkornak van összefüggése az RP tapasztalattal. Szimplán annyi a helyzet, hogy az élettapasztalat és az informálódás sokat segít az RP-ben, ezt pedig igencsak meg lehet tapasztalni.

Na most akkor jövök én, aki úgy jár informatika/angol-magyar két tanítási nyelvû iskolába hogy az osztálytársaim 30%-a se angolt nem tanult, se informatikát nem ismer, de még egy egyszerû bool-algebrát sem bír felfogni. És ezekbõl lesznek a programozók meg az informatikusok. És még így is alulképzettség van!
Az, aki meg nem tud angolul, nem tudom, hogy nyalja be pl. ezt:
[hs width=300 height=300]https://fbcdn-sphotos-g-a.akamaihd.net/hphotos-ak-ash3/1235504_499272086828426_1461294766_n.jpg[/hs]

Túl sokat gondoltok bele. Igazuk van azoknak, akiknek ezeket a szemétdombokat üzemeltetik: \"ha nem tetszik, nem nézel rá\".
Ha nem lenne ez a sok szar, akkor se menne az, aki eddig azokon játszott, valami normális szerverre, ne hogy azt higgyétek. Maradjanak csak ott, ahol vannak, legalább el vannak szegregálva a viszonylag rendes játékosoktól.

Az RP alapja a szerepjátszás.
Ha tudod, hogy kell egy olyan embert élethûen eljátszani, aki te nem vagy, onnantól minden magától adódik.
Az RP játékosok nagy hányada nem tudja, hogy hogyan kell ezt megtenni (ezért élik reneszánszukat a GF szerverek), vagy ha tudná is, nem érdekli, hogy háttértudást szerezzen a karakteréhez. Ezzel megszületnek a See RPG-s karakterek, amelyek vagy nem tudják, mit kéne játszaniuk, vagy tudják, de nem tudják, hogy hogy mûködik a dolog a valóságban. Ezt a tudást pedig élettapasztalattal vagy informálódással lehet pótolni.
Eleve. elméletileg, nem lehet egy olyan karaktert eljátszani, akinek az életében te nem látsz fantáziát, hiszen akkor nem tudnád jól eljátszani.
Ennyire egyszerû.

A memóriaszivárgás a következõ:
a dinamikusan lefoglalható memória azért dinamikusan lefoglalható, mert egy adott hosszúságú memóriaszakaszt lefoglalhatsz saját használatra az ún. \"heap-bõl\" (az most lényegtelen, hogy mi, ha érdekel, elmondom). A memóriaszakasz hosszát nem kell meghatároznod futtatás elõtt, elég futtatás alatt. Ettõl \"dinamikus\". A memóriaszakaszt azonban, amennyiben a használat után nem szabadítod fel, keletkezik egy \"lyuk\"  -- azaz a memória, amit lefoglaltál, elveszik: hisz nem szabadítottad fel.
Pl. ha egy függvényben 2 kb memóriát lefoglalsz, de a függvény végeztével nem szabadítod fel, minden egyes alkalommal, mikor a függvény lefut, 2kb memória el fog veszni. Ez elõbb utóbb a memória kikezdésével fog járni.
Az a memória, amit lefoglaltál a ciklusoddal, ott marad a samp szerver névterébe, mivel a használat után nem szabadítottad fel. Az, hogy önmagában mennyi memóriát eszik a plugin, könnyû kideríteni: fogd a plugint, és indítsd el egy tök üres scripttel, nézd meg, mennyit foglal. Ha már magától is sokat foglal, akkor mérlegelni kell, hogy hosszú távon megtérülhet-e a használata.
A memóriaszivárgás nem akkora nagy probléma a GVar pluginnal, mivel a változóknak van id-jük és nevük, de pl. egy C++-ban ha a függvényben, amiben lefoglaltad a memóriát, nem szabadítod fel, akkor elveszik a mutató a memóriára, tehát egy végleges vesztésrõl beszélünk.
Amit meg kell jegyezni: a dinamikus memória esetén TE kezeled azt, hogy mennyit foglalsz le, és mennyit szabadítasz fel. Ha nem szabadítod fel, akkor a memória ott fog maradni a szerver névterében, használatlanul, addig, míg le nem állítod azt.

A fenti adatot úgy lehet kicsalni a fordítóból, hogy valami extrém kicsire állítod be a stack méretet a
 

#pragma dynamic [szám]

 
direktívával. A fordító minden olyan esetben kiírja a hibát, ha gyanítja, hogy a többszörösen beágyazott függvények esetén felmerülhet az a gyanú, hogy stack overflow történhet (ez gyk. azt jelenti, hogy a lentrõl felfele növekvõ stack belír az \"elõtte\" lévõ memóriába - ezt a SAMP szerver egy elegáns azonnali kilépéssel reagálja le).
Dinamikusan foglalja a memóriát: ez bajos. A dinamikus memóriával nagyon óvatosan kell bánni. Kicsi figyelmetlenség és lesz egy rohadt nagy memórialyuk (vagy ki tudja, hogy hívják ezt magyarul, memory leak) a SAMP szerveredben. Ezt így kell érteni:
 

RandomFuggveny()
{
   for(new i=0; i<5000; i++)
   {
      SetGVarInt(\"teszt\",i,i);
   }
}
main()
{
   RandomFuggveny();
   return 1;
}

 
A fenti kód hibája, hogy a lefoglalt memóriát nem szabadította fel a heap-bõl, ezzel okozva egy \"memórialyukat\", mely a szerver futásáig megmarad. Nyilván, ha ez a memórialyuk egy többször használatos függvényben fordul elõ, akkor minden egyes meghíváskor elszivárog ez a memóriamennyiség, elõbb utóbb kifogyva a lehetséges memóriából. Még a világklasszis programokban (khm, Windows, khm, Firefox) is nem egy ilyen hiba van, és ha õk elkövetik, te is el fogod.
A változók maguk nem foglalnak helyet a PAWN kódban, mivel a PAWN csak a változó helyére mutató pointert raktároz el (amennyiben a változó globális). Lokális változók esetén pedig a \"fájlnövekedés\" annyi, hogy pár bájttal több az assembly kód (hiszen 0x0FA0 több, mint mondjuk 0x64, az elõbbi csak 2 bájtba fér be).
A felhasznált memória, amennyiben a tömböket lokálisan [függvényen belül] akarod használni, csak addig lesz nagy, amíg a függvény futása zajlik. A függvény visszatérése után a stackrõl lepakolódik a változó és a változó miatt lefoglalt memória, önmagától (ezért a dinamikus memória esetén leírt memóriaszivárgás nem probléma).
Az elérés sebessége lassabb lesz (ez az ún. \"overhead\" miatt van, a pluginban elérhetõ függvények lefuttatása több idõbe telik), DE a plugin kevesebb memóriát fog enni, hiszen annyit foglalsz csak le, amennyi kell.
Fontos továbbá, hogy a GVar plugin (szándékosan) nem támogat komplexebb adatstruktúrákat, ha valami olyat szeretnél, akkor muszáj lesz a stack változókat használni.
Elméleti síkon egyébként a maximális tömbhossz az, ami egy cellát teljesen túltölt (4 bájt), de ezt nyilván nem fogod elérni, mivel annyi kocsit az életbe nem fogsz lerakatni a SAMP-pal.

Hy!
Megkérdezném hogy Pawnon kívül lehet mással irni a SA:MP Scripteket? Vagy van ilyen egyátalán?
 

Van, de nem fejlesztik õket.