Nagyjából átfutottam a kommenteken. Röviden kifejtem a véleményem:
A See, Fay, stb. szerverek egy ponton buknak meg: A kezdésnél. Azaz nincs stabil alapon a szerver. Mire is célzok?
Egy jó RP szerver kezdéshez 3 dolgot kell biztosítani:
1. RP alapscriptek
2. professzionális IC igazságszolgáltatás (RENDÕRSÉG!)
3. professzionális OOC igazságszolgáltatás (ADMINISZTRÁTOR CSAPAT!)
Hogy mért nem hibáztathatjuk a játékosokat? Mert akármennyire is szeretnénk, az átlagéletkor miatt nincsen akkora felfogóképességük.
Na de visszatérve a három pontra: Az elsõ egyértelmû (parancsok, lehetõségek). A 2. pont a rendõrség. A valóságban is vannak olyan társadalmi követelmények amiknek mindenkinek eleget kell tenni, hogy az emberek egymás mellett tudjanak élni, biztonságban. Mivel a rendõrség komolyságáról és szabályzatáról 50 szónál többet nem nagyon képesek írni az ottani játékosok, így nem lesz ki biztosítsa az IC fegyelmet.
3. Pont: adminisztrátorok. Ugyanazért felelõsek mint a rendõrök, viszont OOC szempontból. És mivel a rendõrség gyenge, egyszerûbb megoldás a rendõrség feladatát OOC okokra átvetíteni, azaz olyan reális, egyértelmû IC dolgokat korlátoznak szabályokkal, amiket a rendõrség nem tud végrehajtani.
És ezért gondolom, hogy a RENDÕRSÉG egy kritikus pont az RP szervereknél. Ha az nincs, akkor nem beszélhetünk RP szerverrõl. Az illegális oldalon lévõ emberkéknek könnyebb pénzhez jutni, akció dúsabb a játék.
És mit is várhatunk el egy alacsony átlagéletkorú brigádtól, akik nem nagyon értik meg, mi a szerepjáték lényege? Fõleg, hogy a Grand Theft Auto szérián belül játszanak RP szerveren? A játék maga arra buzdít, hogy lövöldözzünk, szerezzünk könnyû pénzt, lopjunk kocsit. Ezt kéne fékeznie az adminisztrátoroknak, de LEGINKÁBB a RENDÕRSÉGNEK. Ez a fõ oka, hogy inkább szabályokat hoznak be.
 

Szerintem ez mindent elmond úgymond a \"tökéletes RP szerverrõl\".

Ezt úgy hívják, hogy szteganográfia, ha már errõl beszélgetünk itt, tudjuk a nevét.
Azt azért fontos észrevenni, hogy minnél nagyobb a fájl mérete, annál nagyobb képben kell elrejteni, és egyértelmûen minnél kisebb képet használsz annál nagyobb lesz a hibalehetõség.

Ez az eszmefuttatás hülyeség.
Ennyi erõvel a programozók 75%-a, aki nem tanult meg Assemblyben programozni, csak valami \"holmi\" C/C++-ban az már nem is igazi programozó?
Azért rakták be az új objecteket hogy növeljék a produktivítást, növeljék a mapperség elérhetõségét a nagyobb rétegeknek, és ez szerintem jó dolog. Ha valaki csak ebbõl akar táplálkozni, és jó mapot csinál, kit érdekel? Ha szar a map, akkor meg teljesen mindegy, hogy milyen objectbõl csinálja, az nem von el meg nem ad hozzá ahhoz, hogy a map önmagában kaksi lett.

 

Kár, hogy a CPUID-s és a HDD Serial azonosítós dolog nem mûködik. Ámbár szerintem nem csak kötet azonosítót lehet kiolvastatni, hanem mélyebbre is lehet ásni.
 

Ezen kívül a SCSI/ATA/SATA merevlemezeknek létezik egyedileg a merevlemezbe égetett sorozatszámuk is, amelyek minden egyes meghajtónak elméletileg egyediek, ezeket is meg lehet változtatni (bár azt megnézném, hogy mi történne, ha mondjuk egy RAID-kötet két meghajtója egy számmal rendelkezne, szerintem lyukat ütne a tér-idõ kontinuumban). De ezt is meg lehet változtatni, bár nem olyan egyszerûen, mint a MAC-címet, a hozzá elérhetõ eszközök felemásan viselkednek, van, hogy mûködnek, van, hogy nem.
 
[/quote]
 
[/quote]
Szóval akkor változó a mükõdésük?
 
[/quote]
Igen, legalábbis az ilyen programok több mindentõl függnek, oprendszer, hardvertípus, processzor architektúrája, 32/64 bit. Láttam olyat, hogy az egyik program megváltoztatta a HDD ID-t, és egy rendszerfigyelõ program át is írta magának a HDD ID-t, a másik ilyen rendszerfigyelõ program meg nem csinált semmit.
Szóval igen, változóak.

Kár, hogy a CPUID-s és a HDD Serial azonosítós dolog nem mûködik. Ámbár szerintem nem csak kötet azonosítót lehet kiolvastatni, hanem mélyebbre is lehet ásni.
 

Ezen kívül a SCSI/ATA/SATA merevlemezeknek létezik egyedileg a merevlemezbe égetett sorozatszámuk is, amelyek minden egyes meghajtónak elméletileg egyediek, ezeket is meg lehet változtatni (bár azt megnézném, hogy mi történne, ha mondjuk egy RAID-kötet két meghajtója egy számmal rendelkezne, szerintem lyukat ütne a tér-idõ kontinuumban). De ezt is meg lehet változtatni, bár nem olyan egyszerûen, mint a MAC-címet, a hozzá elérhetõ eszközök felemásan viselkednek, van, hogy mûködnek, van, hogy nem.
 
[/quote]

 

# RP-re fel! Ezentúl minél többet játszol ( RP-zel ), annál többet kaszálsz. Magyarul ha feljössz reggel nyolckor játszani, és lemész a szerverrõl este nyolckor, akkor kb. 5000-8000 $-t keresel munka nélkül.
 

Ezt érdemes kiemelni. Rengetegen problémáztak azon, hogy nagyon sokat kell dolgozni a pénzszerzéshez. Mostantól megadjunk arra a lehetõséget, hogy amennyiben nincs kedved dolgozni, csak RP-zni, pénzt kerehess ezen a módon.
1) A pénz a bankszámlára utalódik.

2) Csak akkor mûködik, ha NEM VAGY egyéb munkában (beleértve a frakciókat is).
 
[/quote]
Szerintem szerelõknek is lehetne, mivel a szerelõknek nincs óránkénti fizetés és ha kevés a munka akkor nincsen fizu és -ba megyünk, mint például én.
 
[/quote]
Egyelõre mûködik minden frakciónak, késõbb ez le lesz korlátozva.

Állj. Nem azt mondtam, hogy az IP-cím egy JÓ megoldás, azt mondtam, hogy a többi, általánosan mindenki által kért megoldásnál nem jobb az IP-címes banolás sem.
Amit itt le kéne fektetni, az a különbség a changing és a spoofing közt. A changing az a konkrét változás, azaz, hogy, pl. a te IP-det megváltoztatod egy másik címre, vagy a MAC-címedet megváltoztatod úgy, hogy veszel egy új netkártyát.
A spoofing ezzel ellentétben az, hogy az adatot használó programmal te elhiteted, hogy a fenti changing létrejött, de közben nem.
IP-t nem lehet spoofingolni, MAC-címet, és a fentiek közül az összes egyebet lehet. Persze ez nem jelent sokat, mivel attól még nem lesz nehezebb új IP-címet generálni magadnak, de ez mindenképpen elõny a leírásban bemutatott védelmek ellen.
A leírás esõdleges célja a tévhitek lerombolása, az IP-címrõl mindenki tudja, hogy könnyû változtatni, de némelyeket a sokak által kérvényezettek közül még könnyebb.

1. TÉVHIT: A MAC-CÍM A MEGOLDÁS.
Nem. Nem, nem. Nem! A MAC-cím nem megoldás a hatékony banolásra. A legfontosabb ok az, hogy a MAC-címmel általában az internet nem törõdik. A legtöbb esetben a MAC-címek a helyi (otthoni, iskolai, munkahelyi) belsõ hálózatokon kapnak nagyobb szerepet (amiket otthon ált. egy router köt össze). A legtávolabb, ameddig eljut a MAC-címed, az általában a netszolgáltató azon szolgáltatása (DHCP), ami a géped vagy routered MAC-címére véletlenszerûen vagy fix módon kioszt egy IP-címet.
Másik, MAC-címekkel törõdõ protokol az ARP protokol, melynek elsõdleges feladata az, hogy amennyiben két gép egymással akar kommunikálni, az ARP feladata az IP-címek MAC-címekké való konvertálása. Ezt hosszadalmas és bonyorult lenne elmagyarázni, amennyiben a két gép nem egy hálózaton belül van, de elégedjünk meg annyival, hogy, mint az elõzõ esetben, az egyetlen hely, ahol a MAC-cím ténylegesen számít, az az a router, amelyre a te hálózatod csatlakozik.
Sokak szerint a MAC-címek, mivel minden hálózati kártyán egyediek, nem változtathatóak és ezért tökéletes módja a játékos kibanolásának, hiszen senki se fog a szerver miatt egy új hálókártyát venni.
Ez nem igaz. A MAC-címek, bár egyediek, a helyi hálózaton kívül nem használandóak gépek azonosítására. Ez azt jelenti, hogy amennyiben a hálózati eszköz, amin keresztül te eléred az internetet (ez általában az az eszköz, ahova a te modemedbõl érkezõ adat végsõ soron megérkezik az internetszolgáltatódhoz), vagy bármilyen alacsonyabb hálózat (beleértve a routered, illetve a routerekre rákötött esetleges switcheket, más routereket) során nincs MAC-cím ütközés, lényegében akármire megváltoztathatod azt.
Sokak szerint a MAC-cím változtatása forrasztási vagy profi hackelési tudást igényel. Nem igazán. Amennyiben routert használsz, vagy olyan modemet, aminek van firmware-n keresztül elérhetõ weboldala (köznyelvben: router weboldal, router konfiguráló weboldal), valószínû fog lehetõséget adni, hogy megváltoztasd az eszköz MAC-címét.
Csak hogy bebizonyítsam, hogy igazam van, a laptopomon (amin linux fut, gépneve: pluto) megváltoztattam a NIC (hálókártya) MAC-címét 00:11:22:33:44:55-re, ami  a Cimsys, Inc. hardvergyártó cégnek van bejegyezve, és láss csodát, a DHCP-klienslista felismerte a megváltoztatott MAC-címet, tehát már csatlakozhattam is az internetre a routeremen keresztül (igen, a telefonom gépneve pocokarcu, nem tudom miért). Ezt Linux alatt töbféleképp el lehet érni, van rá külön program is (macchanger, ami random mac-címet is tud kiosztani, de nmappal is meg lehet oldani), hasonló programok elérhetõek Windowsra is.
[hs width=300 height=300]http://imagerz.com/QE5DDEtvAwMCVFocQAVQ[/hs]
Ezek után a MAC-címet visszaváltottam az eredetire, majd fogtam magam, és a router MAC-címét változtattam meg, mint láthatjátok, vidáman pingeltem a google-t hiba nélkül.
[hs width=300 height=300]http://imagerz.com/QE5DDEtvAwMCVFofQgVQ[/hs]
Természetesen a szimpla-modemes hálózat esetén is hasonló eredményre jutottam, de azt már nem fényképeztem le.
Ezen okokból nyilván õrültség azt feltételezni, hogy a MAC-ban valakit megállíthat abban, hogy visszajöjjön a szerveredre.
2. TÉVHIT: CPUID BAN
A CPU-dnak már rég nem egyedi az ID-je. A CPUID x86 utasítás csak a processzorod típusát és az az által támogatott ficsöröket adja vissza, semmi egyedi azonosítót.
3. TÉVHIT: HDD ID
Nyilván ez már közelrõl sem olyan hasznos, mivel a másik fizikai lemezre átrakva a dolgokat a ban kikerülhetõ. Azonban még erre sincs szükség. A windows ún. kötet-azonosítókkal lát el minden leformázott kötetet, amiket aztán az aktiválási folyamatok során is használ, többek közt. Erre is le lehet szedni olyan fantáziadús nevû programokat, mint  Hard Disk Serial Number Changer (szó szerint: Merevlemez sorozatszám változtató), bár ez konkrétan nem a merevlemez, hanem a kötet egy azonosítószáma (értsd: a kötet formázása során ez a szám változik, nem marad azonos).
Ezen kívül a SCSI/ATA/SATA merevlemezeknek létezik egyedileg a merevlemezbe égetett sorozatszámuk is, amelyek minden egyes meghajtónak elméletileg egyediek, ezeket is meg lehet változtatni (bár azt megnézném, hogy mi történne, ha mondjuk egy RAID-kötet két meghajtója egy számmal rendelkezne, szerintem lyukat ütne a tér-idõ kontinuumban). De ezt is meg lehet változtatni, bár nem olyan egyszerûen, mint a MAC-címet, a hozzá elérhetõ eszközök felemásan viselkednek, van, hogy mûködnek, van, hogy nem.
4. TÉVHIT: BIOS ID
A BIOS-t könnyedén fel lehet flashelni pl. a PHLASH16 nevû programmal.
5. TÉVHIT: GCPI BAN
A gcpi() egy nem dokumentált SAMP függvény. Elsõdleges célja a nagy szerverek segítése akik rendszeresen kapnak cheaterektõl és botoktól támadást.
A gcpi() egy lossy hashhel tér vissza a GTA telepítésedrõl. Mivel a hash lossy, ezért több személynek is azonos hashe lehet, ami a banolást sokkal veszélyesebbé is teheti, fõleg, hogy a SAMP populáció jelentõs hányadának a crackelt játék miatt megegyezik.
Elõnye viszont az, hogy alap SAMP native, ezért akárki használhatja.
KONKLÚZIÓ
Mint ahogyan azt olvashattátok, rengeteg megoldás lett felsorakoztatva, amelyeket, bár sok ember istenít, és kíván a SAMP függvénykönyvtárba, nem nyújtanak valódi védelmet a cheaterek ellen.
A fenti módszerek mindegyikéhez, továbbá, speciális kliens-szerver kapcsolatot kell megteremteni, amit a tehetségesebb hackerek lehallgathatnak és szimplán a csomagokat megváltoztatva megkerülhetik az anticheatet.
Az egyetlen olyan azonosító, amivel ezt nem tehetik meg, az az IP-cím, és ezért, bár eléggé gyenge védelmet nyújt, még mindig a legkényelmesebb megoldása az emberek kitiltásának.