[TrinityCore] A Core megismerese

Indította Shyro, 2015 november 01, 03:04:40 DÉLUTÁN

Előző téma - Következő téma

Shyro

Sziasztok!

Egy problemat szeretnek eletek tarni, ami engem mar regota zavar. Egyreszt kivancsi vagyok arra, hogy mas mikent velekedik a dologrol. Masreszt lenne egy - bar megoldasnak nem nevezheto - javaslatom arra, hogy mikent lehetne elindulni.

A problemam

A TrinityCore egy eleg meretes legacy kodbazis. Felhasznaloi dokumentacioja ugy ahogy van, problemak eseten akar a forum - ozokhoz is fordulhatsz. Viszont fejlesztoi dokumentacioval egyatalan nem rendelkezik. Eselytelennek tartom, hogy szulessen hozza fejlesztoi dokumentacio, de mindjart kiterek ra, hogy miert zavar a hianya.

Ha ranezunk Github - on a repository - ra, akkor orommel latjuk a 315 - os szamot a contributor - oknal, illetve a jopar pull request - et. Ez bizalom, a projekttel szemben, hogy foglalkoznak vele, javitjak, fejlesztik, stb., ami nelkul nem lenne ennyire nepszeru az emulator.

Viszont a valosag nem ez. Ha ranezunk a contributor - okra es a pull request - ekbe is beleolvasunk hamar rajovunk, hogy nem ennyire rozsas a helyzet. Van nehany fejleszto, es tenyleg csak nehany, akik hosszu ideje tevekenykednek, nagy mennyisegu kodot tesznek a projektbe, nagy ralatasuk van a kod egeszere, tudnak donteseket hozni architekturarol, konvenciokrol, stb., atlatjak az absztrakciot. Foleg amiatt, mert regi motorosok es nagy reszet ok irtak. Ezt a tudast folyamatosan karbantartjak. Olvassak a commit - okat, egymassal kommunikalnak, stb.

Ezen fejlesztok fontossagat ugy lehet a legkonyebben bizonyitani, hogyha a 315 contributor kozul kiveszed oket, akkor kozel meghalt a projekt. Mondhatjuk, hogy nehezen potolhatok, sot szerintem egyatalan nem azok.

Az osszes tobbi fejleszto, es akik javitasokat kuldenek be egyatalan nem elhanyagolhatoak, de az a tudas, amit az a nehany fejleszto felhalmozott legtobbuknel egy az egyben hianyzik.

Miert fontos ez a tudas? Mert maskepp nem megy. Ha csinalsz egy komolyabb atalakitast, javitast, mi a garancia arra, hogy nem torsz el valamit a kod masik vegen, nem duplikalsz valamit, nem torsz el absztrakciot, a megfelelo funkciokat hasznalod, es az illeszkedik e egyatalan abba? Bizony semmi, csak az, hogy vannak olyan fejlesztok, akik annyira atlatjak a kodot, hogy meg tudjak itelni, hogy az most kb. jo lesz e vagy sem. (commit es pull request hozzaszolasokban ez is szepen megjelenik) Automatizalt tesztelesrol meg egyatalan nem beszelhetunk, ami amugy nehany esetben segitene.

Nem tudom kinek ismeros a domain knowledge fogalom. Ugy jon a kepbe jelen esetben, hogy hiaba vagy C++ programozo, ismered az SQL - t, hasznalsz MySQL - t, sorolhatnam. Nem fogsz tudni komolyabban hozzatenni a projekthez, amig fel nem szeded a fent taglalt tudast, nem kapcsolodsz be, nem olvasod a commit - okat, sorolhatnam. Viszont egy jo szoftverfejlesztonek ez idobe telik, nem is keves idobe. Ez nem csak itt problema, nem csak az open source projekteknel, hanem cegeknel is. Foleg ahol bazi nagy legacy kodbazis van. Kisebb projektek eseten, vagy projektek elejen ezt a tudast konyebb megszerezni, hiszen kevesebb kodot kell atlatni.

Ez tenyleg nem egy elbagatellizalhato tema, az iparban, a szoftverfejlesztesben egy fontos kerdes ennek a kezelese. Amiket eddig en tapasztaltam, az az, hogy keszulnek fejlesztoi dokumentaciok, es az uj alkalmazottak a regi motorosoktol felszedik ezeket az ismereteket. Szukseges, mert ha csak raeresztenek egy projektre, hogy old meg, az tul sok idobe telik, mire magadtol kisakkozod, hogy az adott modositast hova is kellene irni, melyik kodreszlet mire is jo.

Az olyan dokumentaciok szuletese, mint ami pl. az OracleDB eseten is lathato. Vagy az olyan kezdemenyezesek, mint a linux insides, amelyek nem azert szulettek, mert valakinek volt folosleges ideje es szeret irni. Mind azert tortent meg, mert szukseg van arra, hogy valaki atlasson a szitan, nem eleg csak a kod.

Szerintem mindenki tud olyan kodot irni, amit ha mas ranez, nem fogja tudni megerteni egybol, csak hosszabb bogarasz utan. Pedig ha az azt a kodot iro illeto elmondana, hogy mikent mukodik, hogyan kepzelte el a megoldast, akar 5 perc is eleg lenne arra, hogy az ember kepbe keruljon. Hiaba a clean code, nagy kodbazis eseten az sem segit, es a nehany percbol, napok, hetek is lehetnek, ha egyedul allsz neki megerteni.

TrinityCore is egy egeszseges kodmennyiseg, ami miatt az a szint, amivel mar erdemben be tudsz kapcsolodi a projektbe magasan van. Az uj fejlesztoknek egyatalan nincs konnyu dolguk, egyetlen eselyuk, ha fork - oljak a repository - t, elkezdik bogaraszni, probaljak faragni a kodot, modositasokat kuldenek be, aprankent lepdelnek elore. Aki erre vetemedik annak teny, hogy tukrozi az elhivatottsagat, de valljuk be, nem egy effektiv modja a bekapcsolodashoz. Ha lennenek kapaszkodok, sokkal gyorsabban lehetne haladni.

Szerintem az egyertelmu, hogy keves kesobb meghatarozo fejleszto kapcsolodik a projekthez, amit en nem csak a WoW elnepszerutlenedesenek, az open source projekt tulajdonsaganak, hanem ennek is betudok. Ahhoz, hogy megismerjem a projektet, eloszor kerdesekkel kell eloallnom, azokat feltennem, megvarnom ra a valaszokat, es biznom abban, hogy azt a 70.000 kerdest - ami bizony fel fog merulni az emberben, ha komolyan meg akarja erteni az eddigi felhalmozott kodot - lesz is aki megvalaszolja keszsegesen. Ez nem tul bizalomgerjeszto. Pedig ez a helyzet, marad a main.cpp es el lehet kezdeni felterkepezni a kodot.

Ahogy fent irtam, fejlesztoi dokumentacio kizart, hogy fog szuletni. Igy az zsakutca. A jelenlegi valtoztatasokat a commit message - kbol generalt release note - okban jol nyomon lehetne kovetni. (Ez a TDB eseten mar valamennyire megvalosul, csak nem automatiksan generalt, azt hiszem)

A javaslat

Viszont, van egy magyar forum (ez), ahol adott a lehetoseg arra, hogy az eddigi ismereteinket megosszuk a Core - rol, beszeljunk a mukodeserol, kerdeseket tegyunk fel, megprobaljuk kozosen felterkepezni az eddigi kodbazist. Megprobalhatju kfelepiteni azt a domain knowledge - t kozosen, mert egyedul drama...

Valamilyen formaban mar megtortent mindez, de nagyon specialis kerdesek szoktam felmerulni, amelyek nem segitik a ralatast, csak nagyon szuk kontextusban vizsgalnak egy kerdest. Ezek mellett jo lenne egy olyan torekves, ami a TrinityCore - t komponensenkent, fuggosegekkel egyutt, teljes mukodeseben targyalja. Engem speciel erdekelne ilyen melysegekben is a Core es biztos vagyok benne, hogy aki ugy gondolja, mar valamennyire ert is hozza, nem lenne kepes leirni, osszefoglalni, felskiccelni a Core mukodeset, akar igy:



Pedig te jo eg, egy ilyen komponens abra, es a mellekelt szoveg (OracleDB dokumentacio) mennyit tud segiteni a megertesben!

Ha megis akadna ilyen ember, akkor az rengeteget segitene, ha megosztana a tudasat, akiket pedig szinten erdekel a tema, megprobalhatnank kozosen utanajarni.

Miert ezen a forumon?

Ez csak egy dontes volt reszemrol, szerettem volna itt eloszor felhozni a temat, hatha kisul belole valami.

Miert probalkozok ilyesmivel, ahelyett, hogy fognam magam es bogarasznam a kodot? Mert sokkal hatekonyabbnak tartom a tudasmegosztast, mint a keves eredmennyel jaro maganakciokat. Tapasztaltam, hogy mennyit jelent az, ha valaki megosztja az ismereteit, es hogy milyen elindulni mindenfele kapaszkodo nelkul.

Azzal is tisztaban vagyok, hogy amire en kivancsi vagyok, azt a Core vezeto fejlesztoi tudnak a legjobban elmondani. De ketlem, hogy barmelyikuk is vallalkozna arra, hogy ezekrol komolyabban irjon, ugy, hogy azt az elozetes ismerettel nem rendelkezok is megertsek. Az inkabb egy kovetkezo lepcsofoka lehetne a dolognak.

Ezzel kapcsolatban erdekelne a velemenyetek. Barmilyen hozzaszolast szivesen fogadok, de a legjobban annak orulnek, ha elso korben eldontenenk, hogy hol erdemes kezdeni, mit erdemes eloszor felterkepezni.

Udv,
Shyro
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

eztcsekk

#1
Hát itt ilyen topicban nem fogsz válaszokat kapni :D

Tényleg nem tudok mit mondani, bogarászni kell a kódot ha meg szeretnél valamit oldani ha nincs konkrét célod akkor nézegetheted bármeddig, a matekot sem munkafüzet lapozgatással tanitják.

Az olyan dolgok, pedig, hogy release után 12 órával hogy tudják mind az ~1200 Opcode-ot névvel együtt, nos fogalmam sincs, de nem is fogják elmondani.

Shyro

Ha valaszokat nem is, de abban remenykedek, hogy vannak itt olyan emberek, akik szeretnenek tobbet megtudni arrol, hogy mi is az amit leforditanak, es mi is tortenik a hatterben, amikor elinditjak. Nem akkora misztikum a Core, egyszeruen csak nincs rola informacio.

Eppen most olvastam itt egy posztot, hogy C++ fejlesztot keresnek. A C++ az alap, viszont ami a lenyeg itt, az maga a domain knowledge. Hogyha azt mondjak neked, hogy figyelj, jo lenne ha ezt kijavitanad, akkor Te tudod, hogy xyz.cpp fajl zyx osztalyanak adott tagfuggvenyet kell ahhoz megfeleloen modositanod. Egy evek ota dolgozo senior C++ fejlesztot is ha odaultetsz a TrinityCore ele, nem fogja tudni megoldani a problemadat kapasbol, lehet, hogy a rutin miatt neki napok/hetek alatt kitisztul a kep, de egeszen addig, amig meg nem szerzi a ralatast, nem tudja megoldani. Ennyire szamit a domain knowledge. Es ahogy fentebb irtam, ennyire szarul el ebbol a TrinityCore.

Elso korben en annak is orulnek, ha osszegyujtenenk egy topic ala forrasokat, hogy hol erdemes elindulni. TrinityCore wiki, oke, de rengeteg mindent leirnak forum topic - okban, egy - egy hozzaszolasban, commit hozzaszolasokban, issue hozzaszolasokban. Amiket aki nem olvasott el, az le is maradt rola.

Ezzel kapcsolatban fel tudok hozni 2 open source projektet, hogy mennyire mas a helyzet, ha rendelkezesre allnak a megfelelo informaciok.

Az egyik a jspm, amit hasznalok. Ez egy eleg developer edition fazisban levo package manager/bundler JavaScript - hez. Marha jo, de meg van mit fejleszteni rajta. A dokumentacioja egyatalan nincs szinkronban a mogottes koddal, nincs jol karbantartva. Folyamatosan nyomon kell kovetnem az issue - kat, olvasnom a release note - okat, a chat - et, hogy kepbe keruljek a projekt aktualis allapotaval, es ki tudjam hasznalni az ujitasok, reagalni a breaking change - ekre. Rengeteg olyan informaciohoz jutottam pl. az issue hozzaszolasokbol, amiket ha csak a weboldalat neztem volna a budos eletben nem hallok rola. Egyenlore eleg szenvedos hasznalni, de mivel meg nem akkora a kodbazisa, meg emeszheto, ezert ezt vallaltam azzal, hogy hasznalom.

A masik, ennek ellentetje a redux, egy Flux implementacio. Marha jo dokumentacioja van, es a kod is eleg tiszta ahhoz, hogy konnyeden at lehessen latni. Nem kellett heteket baszakodnom, mire hasznalni tudtam volna, es mindez ennek koszonheto. Arra is vannak forrasok, hogy a mogottes filozofiaval, koncepciokkal is megismerkedjen az ember. Ez borzasztoan hasznos.

Es igen, itt a TrinityCore, egy monstrum, es egy `Good luck!` - on kivul nem sok utravalot kapsz az elindulashoz. Ez nem is fog valtozni, de legalabb mi, akik erdeklodnek a projekt irant, osszedobhatnak amink van, es teremthetnek egy kiindulo alapot. Ezt gondolom.
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

eztcsekk

Idézetet írta: Shyro Dátum 2015 november 01, 06:33:02 DÉLUTÁN
Ha valaszokat nem is, de abban remenykedek, hogy vannak itt olyan emberek, akik szeretnenek tobbet megtudni arrol, hogy mi is az amit leforditanak, es mi is tortenik a hatterben, amikor elinditjak. Nem akkora misztikum a Core, egyszeruen csak nincs rola informacio.

Eppen most olvastam itt egy posztot, hogy C++ fejlesztot keresnek. A C++ az alap, viszont ami a lenyeg itt, az maga a domain knowledge. Hogyha azt mondjak neked, hogy figyelj, jo lenne ha ezt kijavitanad, akkor Te tudod, hogy xyz.cpp fajl zyx osztalyanak adott tagfuggvenyet kell ahhoz megfeleloen modositanod. Egy evek ota dolgozo senior C++ fejlesztot is ha odaultetsz a TrinityCore ele, nem fogja tudni megoldani a problemadat kapasbol, lehet, hogy a rutin miatt neki napok/hetek alatt kitisztul a kep, de egeszen addig, amig meg nem szerzi a ralatast, nem tudja megoldani. Ennyire szamit a domain knowledge. Es ahogy fentebb irtam, ennyire szarul el ebbol a TrinityCore.

Elso korben en annak is orulnek, ha osszegyujtenenk egy topic ala forrasokat, hogy hol erdemes elindulni. TrinityCore wiki, oke, de rengeteg mindent leirnak forum topic - okban, egy - egy hozzaszolasban, commit hozzaszolasokban, issue hozzaszolasokban. Amiket aki nem olvasott el, az le is maradt rola.

Ezzel kapcsolatban fel tudok hozni 2 open source projektet, hogy mennyire mas a helyzet, ha rendelkezesre allnak a megfelelo informaciok.

Az egyik a jspm, amit hasznalok. Ez egy eleg developer edition fazisban levo package manager/bundler JavaScript - hez. Marha jo, de meg van mit fejleszteni rajta. A dokumentacioja egyatalan nincs szinkronban a mogottes koddal, nincs jol karbantartva. Folyamatosan nyomon kell kovetnem az issue - kat, olvasnom a release note - okat, a chat - et, hogy kepbe keruljek a projekt aktualis allapotaval, es ki tudjam hasznalni az ujitasok, reagalni a breaking change - ekre. Rengeteg olyan informaciohoz jutottam pl. az issue hozzaszolasokbol, amiket ha csak a weboldalat neztem volna a budos eletben nem hallok rola. Egyenlore eleg szenvedos hasznalni, de mivel meg nem akkora a kodbazisa, meg emeszheto, ezert ezt vallaltam azzal, hogy hasznalom.

A masik, ennek ellentetje a redux, egy Flux implementacio. Marha jo dokumentacioja van, es a kod is eleg tiszta ahhoz, hogy konnyeden at lehessen latni. Nem kellett heteket baszakodnom, mire hasznalni tudtam volna, es mindez ennek koszonheto. Arra is vannak forrasok, hogy a mogottes filozofiaval, koncepciokkal is megismerkedjen az ember. Ez borzasztoan hasznos.

Es igen, itt a TrinityCore, egy monstrum, es egy `Good luck!` - on kivul nem sok utravalot kapsz az elindulashoz. Ez nem is fog valtozni, de legalabb mi, akik erdeklodnek a projekt irant, osszedobhatnak amink van, es teremthetnek egy kiindulo alapot. Ezt gondolom.

Aki nem ért a játékhoz lehet akármilyen C++ mágus nem fog tudni Crash fixeken kivül mást csinálni.

Ezen kivül minden teljesen logikusan van felépitve az egész Core, ha pedig valami komolyabb kell amit még a Core nem ismer/támogat akkor pedig jönn az Ida Pro és szépen lehet nézegetni a klienst.

Shyro

Ez nem igaz. Rengeteg olyan feladat van a projektben, amelyeknek csak kozvetetten van koze a jatekhoz. Egyszeruen tervezessel, refaktoralassal es optimalizalassal vannak kapcsolatban. Epp CMangos - nal lattam, hogy elkezdtek kivezetni az ACE - t. De azt hiszem TrinityCore eseten is valtottak, illetve az uj C++ szabvanyt elkezdtek hasznalni. Csak ra kell nezni a forumra:
http://community.trinitycore.org/topic/10559-lua-scripting-engine/
http://community.trinitycore.org/topic/11624-grid-system/
http://community.trinitycore.org/topic/11896-pooling-gameobjects/
(Hirtelen ezek voltak elol, de teljesen jo peldak)

IdézEzen kivül minden teljesen logikusan van felépitve az egész Core
Vannak eleg letisztult es jol implementalt reszei, de ezzel meg a Core - t fejlesztok sem ertenenek egyet. Amikor felmerul neha komolyabb tema szoktak is huzni a szajukat, hogy `ejj azt bizony ujra kellene irni, mert katasztrofa`.

De abban igazad van, hogy a jatek ismerete is elengedhetetlen a projekt fejlesztesehez. Hiszen az a lenyege. Viszont, hogy valaki atlatja a projektet, annak felepiteset es mukodeset, az nem a jatek ismereten mulik.
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

eztcsekk

Idézetet írta: Shyro Dátum 2015 november 01, 09:04:31 DÉLUTÁN
Ez nem igaz. Rengeteg olyan feladat van a projektben, amelyeknek csak kozvetetten van koze a jatekhoz. Egyszeruen tervezessel, refaktoralassal es optimalizalassal vannak kapcsolatban. Epp CMangos - nal lattam, hogy elkezdtek kivezetni az ACE - t. De azt hiszem TrinityCore eseten is valtottak, illetve az uj C++ szabvanyt elkezdtek hasznalni. Csak ra kell nezni a forumra:
http://community.trinitycore.org/topic/10559-lua-scripting-engine/
http://community.trinitycore.org/topic/11624-grid-system/
http://community.trinitycore.org/topic/11896-pooling-gameobjects/
(Hirtelen ezek voltak elol, de teljesen jo peldak)

IdézEzen kivül minden teljesen logikusan van felépitve az egész Core
Vannak eleg letisztult es jol implementalt reszei, de ezzel meg a Core - t fejlesztok sem ertenenek egyet. Amikor felmerul neha komolyabb tema szoktak is huzni a szajukat, hogy `ejj azt bizony ujra kellene irni, mert katasztrofa`.

De abban igazad van, hogy a jatek ismerete is elengedhetetlen a projekt fejlesztesehez. Hiszen az a lenyege. Viszont, hogy valaki atlatja a projektet, annak felepiteset es mukodeset, az nem a jatek ismereten mulik.

0. A TC már szakitott az ACE-el végülis érthető, az ACE-t nem igazán fejleszteték már a Boost egy sokkal jobb Lib.

1. Lua system, hülyesség.  Van már SmartAI system, igazából mindenre elég (lásd Tauri már komplett Boss fightokat is írnak benne). A Lua is csak azt tudná amit implementálsz hozzá a Core-ba megint az API-n múlna minden, a SmartAI is így megy csak abban már van lassan 8 évnyi munka.

2. Grid System handling, hát manapság 2-300Gb memóriával szerelt szervereket lehet aprópénzért bérelni, nem hiszem, hogy a memory handling-en kéne fentakadni ráadásul aki a jelenlegi rendszert anno írta jobban értet hozzá, mint akik ma újra írnák.

3. Részben egyet értek a jelenlegi Pool system nem éppen logikus, de ez nem lényeges változtatás egy kis egyszerüsités.

Ha 1 dolgot kéne választanom a TC-ből amire teljes re-work-ot kérnék a Phase System-et mondanám. A jelenlegi Phase System össze-vissza lett *******-va ami most van rosszabb mint bármi ami valaha volt, használhatalan pedig MoP-tól fölfelé szinte minden Questnél szükség lenne rá.

Shyro

Ennyire mar nincs ralatasom a projektre. Amiket irtal azok is olyan informaciok, amiket ha valaki nem mond el, eselyed sincs megtudni. Gondolok itt arra, hogy miket valtoztattak, azt milyen indokkal, hogyan mukodott anno, stb. Ez kodbol nem derul ki. Visszaterve az eredeti felvetesre - eddig te irtal egyedul - mi lenne ha kezdetben osszegyujtenenk egy forrasgyujtemenyt, ami segit eligazodni. Nem a TrinityCore oldalara gondolok, de pl. a Phase System - nal mely forum topic - okat erdemes elolvasni, esetleg hol lehet ennek bovebben utananezni a forrason kivul, mely forras fajlok erintettek a mukodeseben, alapvetoen mirol van szo. Nem feltetlen errol, amelyik resze a Core - nak neked szimpatikus, vagy jobban ismered.
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

budasnorbi

Szívesen segítenék de én csak adatbázisba max dbc szoktam dolgozni.Ennek következtében úgy érzem tudásom nem ér föl e szintig.
Nyula :)

Shyro

Belefutottam egy wiki oldalba, ami elso ranezesre ugy tunik, hogy hasznos informaciokat nyujt:
http://www.pxr.dk/wowdev/wiki/index.php?title=Main_Page

Talan este, vagy a hetvegen lesz idom atbongeszni. Ha esetleg mas ismeri, akkor adhatna valami visszajelzest arrol, hogy mennyire relevans informaciokat tartalmaz. Igy elso ranezesre korrektnek tunik.

Illetve bongeszes kozben belefutottam egy ilyenbe:
http://collab.kpsn.org/display/tc/Authserver

Ami igazabol csak arra enged kovetkeztetni, hogy mas is probalkozott mar valami hasonloval. Csak nem akkora baromsag ez. (Az informaciok megosztasara gondolok.)
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

eztcsekk

Idézetet írta: Shyro Dátum 2015 november 05, 01:26:15 DÉLUTÁN
Belefutottam egy wiki oldalba, ami elso ranezesre ugy tunik, hogy hasznos informaciokat nyujt:
http://www.pxr.dk/wowdev/wiki/index.php?title=Main_Page

Talan este, vagy a hetvegen lesz idom atbongeszni. Ha esetleg mas ismeri, akkor adhatna valami visszajelzest arrol, hogy mennyire relevans informaciokat tartalmaz. Igy elso ranezesre korrektnek tunik.

Illetve bongeszes kozben belefutottam egy ilyenbe:
http://collab.kpsn.org/display/tc/Authserver

Ami igazabol csak arra enged kovetkeztetni, hogy mas is probalkozott mar valami hasonloval. Csak nem akkora baromsag ez. (Az informaciok megosztasara gondolok.)

http://www.pxr.dk/wowdev/wiki/index.php?title=Main_Page

Ez jó ami fent van rajta az igaz, de itt csak a Data mining-hoz találsz dolgokat.

A másik linkről az jutott eszembe, hogy a Packet Parser alapján vissza tudod fejteni, egészen pontosan milyen sorrendbe futnak le a dolgok a szerver oldalon.

Egy Login sorrend a Character választó screenig:

CMSG_AUTH_SESSION
CMSG_ENABLE_NAGLE
SMSG_AUTH_RESPONSE
SMSG_ADDON_INFO
CMSG_READY_FOR_ACCOUNT_DATA_TIMES
CMSG_CHAR_ENUM
CMSG_REALM_SPLIT
SMSG_ACCOUNT_DATA_TIMES
SMSG_REALM_SPLIT
SMSG_CHAR_ENUM



brecky

Sziasztok,
Az elkepzeles amit a CORE hasznalatarol gondolsz, levazolni mukodest, stb eleg bonyolult, En  a 4.0.6 TC toll bujom a kodokat, es csak anjit monthatok hogy a mindent a 3.3.5 cora epitettek. Beagyaztak stb.

Jelen pillnatban is egy nagy modositason dolgozom. 6.x re. http://live.gnome.org/Dia Diat hasznalom amikor ki akarom bogozni a kodok osszefugeset.

ha szeretnel tobbet megtudni keres meg TeamSpeak:  ts3.warlordswow.com vagy aviorgaming.com

Powered by EzPortal