Egy fájlos pack fájlok.

[udvatt108]

Sziasztok.

Most egy olyan témát szeretnék felhozni nektek, amire a választ már sokan keresték, és bizonyára sokatokban fel is merült.

Nos ez a téma arról szól,  hogy hogyan kezeljünk eix/epk fájlokat úgy, hogy azok egyben, az-az egy fájlként szerepelnek. Itt most nem az indítóban olvasztott eix fájlokról beszélek, hanem alapértelmezetten az úgy kreált pack fájlokról, amelyek egyetlen fájlba vannak.

Ugyebár ma már a metin2 szerverhez szinte minden forrással rendelkezünk, ami sok távlatot nyit olyanok számára akik esetleg érdekeltebbek a forrásos módosításokban, és/vagy biztonságosabb praktikusabb megoldásokat szeretnének kivitelezni.

Most ilyen fajta felindulásból érdekel ez a téma engem, amit szeretnék veletek megosztani és közös eszmecserére invitálni titeket.

Ezért ide, a Segítség kérés topikba írtam, mert némileg segítség kategóriájú a téma.

Nemrég fél napot szántam rá, hogy átnézzem, próbálgassam, az egyfájlos pack fájl (PackMaker-ben) kezelést, ami kisebb-nagyobb előre haladással járt az ügy érdekében.

Na de kíváncsi lennék, hogy ti fórumozók, hogyan vélekedtek erről a témáról és hogy ti hogyan kezdenétek ezen téma megvalósításához? Esetleg milyen tanáccsal járulnátok hozzá?

Én az alábbival kezdeném meg az eszmecserét:
Első sorban úgy csináltam, hogy az epk és eix fájlok kreálását töröltem, majd egyesítettem egy fájl létrehozására, amit alapból úgy hoz létre a PackMaker, mint akár csak az index fájl létrehozásánál, ami már létrehozáskor  a fájlban elhelyezi a fejlécet, ami tartalmazza a Index FOUR_CC-t, IndexVerziót.

Majd módosítottam a pack adatok beszúrását, úgy hogy az minden feltérképezett index fájl adatai után a fájl tartalmát szúrja be.

A példa enkódolás nélkül értetendő:
Pl.:
EPKD - Index four cc
2 - Verzió
Teszt/Teszt.py - A fájl indexelése
(Teszt.py) - A Teszt.py fájl tartalma
Teszt/Teszt2.py - A fájl indexelése
(Teszt2.py) - A Teszt2.py fájl tartalma

A probléma ezzel most számomra az, hogy nem tudom a kibontásnál elhatárolni, hogy minden második adat az előző sor fejlécéhez tartozik és ezt be is tudjam azonosítani a rendszer.

Tehát hogy tudja a packmaker és a kliens is kibontáskor, hogy melyik sor index-hez melyik sor adat társul.


Nagyon szívesen venném a válaszotokat, legyen az bármilyen jellegű, de a témához kapcsolódó!

(UI:. Természetesen az elkészült forrást publikussá szeretném tenni, mindenki számára.)

[masodikbela]

Kb 2 hete elkezdtem ide válaszolni aztán menet közben meguntam... Nagyjából addig jutottam legutóbb, hogy felvázoltam mennyire nincs értelme SADLY ilyen témáknak magyar viszonylatban, de az, hogy lassan egy hónapja senki nem szólt hozzá mindent elmond, szóval a lényegre térve...

Korábban írtam egy elég részletes és hosszú leírást "Az EterPack" névvel, de nem ezen a fórumon van szóval linket SADLY nem tudok adni.

Az egyik járható út az, amit leírtál, hogy berakod a fájl elejére a szokásos headert, amiben eltárolod, hogy hány fájlt tárolsz a csomagban, majd ezt követően jön egy újabb fejléc amely tárolja az első fájl nevét, méretét stb, ami után pedig egyből az adat jön. Mivel az index részben tudod hogy mekkora a fájl, ezért a következő eltárolt fájl fejléce a jelenlegi fejléc vége + adat mérete után található (egy fejléc mérete ugyebár állandó).

Persze ne feledkezzünk el róla, hogy ezzel még a probléma nincs megoldva teljesen, mivel ugyebár az adatokat a kliens akkor olvassa be a fájlokból amikor szükség van rájuk, ezért továbbra is szükséges a kliens indításakor az összes indexet beolvasni és eltárolni, hogy amikor keressük egy fájl helyét (mert éppen szükségünk lenne rá) tudjuk honnan kell betölteni (pozíció, stb).

A másik lehetséges megoldás, hogy simán csak "összemásolod" a indexeket és az adatokat, azaz a fájl elejére berakod a szokásos headert, hogy hány fájl lesz, stb, majd utána egymás után jönnek a fájlok fejlécei, amik tartalmazzák, hogy hol, milyen pozíción lesznek a hozzá tartozó adatok tárolva, majd a headerek után jöhetnek az adatok folyamatosan, csak ügyelni kell rá, hogy arra a pozícióra kerüljenek, amiket megadtunk a headerben.

Ugyanígy itt is szükség van indításkor az indexek betöltésére, ez hasonlóan megy, nem írom le még egyszer.

Amúgy az ilyet publikálni meg azért nem érdemes, mert ugyan arra a sorsra fog jutni, mint az eterpack. Annak sem lenne baja, ha nem tudná mindenki a structokat...

[udvatt108]

Igen, egyet értek, hiába törekedek a fejlődésre és próbálok "adni" én is ehhez az egészhez, senki nem értékeli vagy támogat. Jó tudom, tök naiv gondolat volt, rájöttem magamtól is.

Meg aki esetleg itt ért is olyan szinten hozzá, mint amekkora értelmet ez a módosítás megkíván, az megcsinálja magának. (Ha szüksége van rá.)

Így átgondolva mivel már sikerült időközben összehoznom a rendszert, nem érdemes publikálnom, mert senki nem értékelte (tisztelet a kivételnek) az erőfeszítésemet, még csak annyival, hogy hozzászól bármilyen jellegű indokkal.

Az utóbbi időben elgondolkodtam, hogy talán felesleges ez az index fájl nélküli dolog, mert időközben rájöttem, hogy mivel az index fájlok kisméretűek és egy jó tömörítő algoritmussal még lehet a méreteket csökkenten, így célszerű lehet az index fájlokat külön vagy egy fájlként a kliens indítóba helyezni és onnan kezelni. Mivel van mód arra is, hogy hogyan tudunk enigma és egyéb ilyen furamányos programok segítsége nélkül is még a indító fordítása előtt csatolmány fájlokat kezelni, amelyek a lefordítás után beleolvadnak automatikusan az indítóba, ami ugye nem eredményez vírus kijelzést, mivel természetes úton kerültek az indító binary-ba, ami hagyomány hívően az imént említett programok átka. És igen a te utolsó pár sorodon is elgondolkodtam, idézve:

Amúgy az ilyet publikálni meg azért nem érdemes, mert ugyan arra a sorsra fog jutni, mint az eterpack. Annak sem lenne baja, ha nem tudná mindenki a structokat...

Valamint köszönöm az építő jellegű "kritikát" valamint a segítő szándékú tartalmat az első hozzászólásban.

[masodikbela]

Nincs sok értelme beolvasztani az indexeket a kliensbe, nem fog rajta semmi múlni. A méretes részét sem nagyon értem, hiszen attól, hogy van egy 500 megás fájlod amibe minden össze van öntve nem lesz semmi sem lassabb, mivel a fájl "beolvasása" nem úgy működik, hogy megnyitod és máris be van 500 mega töltve ramba, hanem ugyan úgy lehet benne az offsetekkel ugrálni, szóval ha te csak az indexeket akarod olvasni akkor lényegében ugyan annyi memóriát fogsz használni, mintha külön fájlban lennének az indexek és csak azokat nyitogatnád.

Továbbá ha ennyire bele akarunk menni, sokkal gyorsabb az egész ha minden egy fájlban van, mivel csak egy handlet kell nyitni és mivel fájlról van szó az adatok egymást követik, így mint az a ramnál is működik ilyen esetekben ez optimálisabb, mintha nyitni kéne több kis handlet és össze vissza ugrálni a fájlok között.

Valamint azon is el lehet gondolkozni, hogy mennyire van értelme erősebb tömörítést használni néhány kbnyi helyért, holott lehet, hogy sokkal lassabb ezzel az algoritmussal az adott adatot "kitömöríteni", mint amennyit amúgy nyernénk vele.

[udvatt108]

Értem az első bekezdésed, de az hogy egy fájlba teszem nem konkrétum volt és nem azt takarta, hogy attól gyorsabb lesz, csupán az esztétika és a rendezettség, valamint némi védelem elérésének célja munkált/munkál bennem.

Értem a második bekezdésed is, de ez hátrányt okozhat abban az esetben, ha mondjuk módosítunk egyetlen egy sort valamelyik fájlunkba és ezt a kb 10-15 byte módosításért nekünk az össze fájlt újra kell csomagolnunk és ezt lepatcheltetnünk újra a játékosokkal. Nos ez ugyebár így nem célra vezető, ezért döntött nyilván a Ymir is a rendszerezett pack fájl kezelés mellett, már mint érted mit értettem a rendszerezett alatt.

Igen egyetértek az utolsó bekezdéssel is, viszont annyival kiegészíteném, hogy abban az esetben nem hátrány az erősebb tömörítés, ha az adatvédelmet vesszük szem elé. Nyilván nem keverhető az encryptelés a tömörítéssel, de a konstrukciós alapja ugyan az, hogy az adatokat átakítjuk, nyílván az encryptnél nincs jelentősége, hogy compresseljük a méretet, de jó kiinduló pont lehet, valamint ha egyedi az algoritmus akár tömörítés akár enkódolás esetén, ez védelmet biztosít, de hát ugye a teáltalad felvázolt eset még akkor is fent áll - nem hogy gyorsítást nem fog, hanem még lassulást okozhat.

Jól van akkor.

Megvárom, hogy esetleg van-e hozzáfűzni való még, és zárom a témát.

Pacsi.

[masodikbela]

Egyébként ha valaki írna egy normális patcher szervert nem lenne probléma, hogyha minden egyben lenne, mivel akkor megoldható lenne, hogy csak bizonyos fájlokat küldjünk át, és a patcher pedig átcsomagolná (mint ahogy ez értelmesebb játékoknál meg is van csinálva (pl gw2)). Többször megfordult már bennem, hogy nekikezdek, de leginkább a lustaság miatt még nem sikerült elszánnom magam.

Egyébként meg ahogy mondtad, nem keverendő össze a tömörítés és a cryptelés, éppen ezért felesleges a tömörítésen változtatni csak azért, hogy hátha nem bontják ki, hiszen már nagyon régóta nem úgy bontják a klienseket, hogy megfejtik a tömörítést vagy az encryptelést, mivel nem éri meg ezzel bajlódni, sokkal egyszerűbb módjai is vannak ennek.

És a védelem amúgy is akkor jó, ha azzal közben nem lépnek fel olyan mellékhatások, mint hogy perceket töltünk a loading screenen.