DBC-k --> MySQL-be. TrinityCore 3.3.5.12340

[NevemSenki]

Sziasztok.

Az első kérdésem az lenne, hogy a DBC fájlok miért nem adatbázisban vannak? Mivel a Core indulásnál tölti be őket, szerintem teljesen mindegy lenne hogy egy mappában vannak, vagy pedig adatbázisból olvassa ki.

Ha ez teljesen mindegy, akkor miként lehetne átpakolni a DBC-ket adatbázisba? Konkrétabban az átpakolással nem lenne nagy gond, nem kis meló ez tény, de megoldható. De miként kéne megváltoztatnom a Core-t, hogy ne keresse a DBC-ket, hanem adatbázist nézzen? Én a World adatbázisba szeretném tenni ( DBC_[DBC_File_Neve] táblanevekkel ), így a SQL lekérdezések ( INNER, LEFT, RIGHT JOIN-ok ) működnének, és ez a szerverhez tartozó weblapra is nagyon jó hatással lenne.

Miként kéne ennek nekilátni? Várom az ötleteket, javaslatokat, ha egyáltalán megoldható a dolog.
Előre is köszönöm!

Üdv.: Senki

[EroniX]

Az első kérdésem az lenne, hogy a DBC fájlok miért nem adatbázisban vannak?

Valószínűleg azért mert így ha kliensoldalon változik a dbc akkor nem kell matatni az adatbázisban.

De miként kéne megváltoztatnom a Core-t, hogy ne keresse a DBC-ket, hanem adatbázist nézzen?

A struktúrákat nem feltétlen kell megváltoztatni, egyszerűen ne fájlból olvasson hanem adatbázisból. Én a DBCStores LoadDBC függvényében keresném a megoldást.

Ha ez teljesen mindegy, akkor miként lehetne átpakolni a DBC-ket adatbázisba? Konkrétabban az átpakolással nem lenne nagy gond, nem kis meló ez tény, de megoldható.

Ahol az emulátor betölti az adatokat ott nyilván hozzáfér azokhoz. Ezen a ponton egy egyszeri core modifikációval szimplán belehetne insertelni az új táblába, nem kell kézzel átvinni.

[NevemSenki]

Hát, utána nézegettem a dolgoknak. C-vel még sosem foglalkoztam igazából.
Az én elméletem az lenne hogy:

PHP alapján gondolkodva, a DBC fájlokból az adatokat kiolvassa, majd beteszi egy tömbbe. Majd a későbbiekben ebből a tömbből kéri ki az adatokat. Megnézegettem a DBC-khez kapcsolódó fájlokat. Összesen 8 DB-ot találtam.

• DBCEnums.h
• DBCfmt.h
• DBCStores.cpp
• DBCStores.h
• DBCStructure.h
• DBCFileLoader.h
• DBCStore.h

Elgondolásom szerint a megvalósításnak úgy lenne értelme, hogy egy If függvényhez hasonló megoldással megnézné először hogy a World adatbázisban található-e a DBC nevének megfelelő tábla, ha igen azt tölti be, ha pedig nem, akkor megnézi a DBC mappán belül is és ha ott megtalálható akkor azt tölti be.
Úgy gondoltam hogy megnézek egy már meglévő adatbázis lekérdezést, majd megpróbálom meghatározni hogy milyen nevű tömbbe dobja be a különböző DBC-ket. És simán írok egy új mechanizmust ami adatbázisból kér, és addig kikommentezem a DBC kiolvasás azon részét.
A későbbiekben pedig megolható lenne a fentebb említett IF megoldás.

Lehet hogy rosszul gondolkodom. Még sosem foglalkoztam ezzel. Ahogy elnéztem ezek a DBC-s dolgok nem valami egyszerűek.

Minta lekérdezésnek ezt használnám.

Részlet a ObjectMGR.cpp-ből:

Kód (c) Kijelölés Kibont

void ObjectMgr::LoadPageTexts()
{
    uint32 oldMSTime = getMSTime();

    //                                                 0      1       2
    QueryResult result = WorldDatabase.Query("SELECT entry, text, next_page FROM page_text");

    if (!result)
    {
        sLog->outInfo(LOG_FILTER_SERVER_LOADING, ">> Loaded 0 page texts. DB table `page_text` is empty!");
        return;
    }

    uint32 count = 0;
    do
    {
        Field* fields = result->Fetch();

        PageText& pageText = _pageTextStore[fields[0].GetUInt32()];

        pageText.Text     = fields[1].GetString();
        pageText.NextPage = fields[2].GetUInt32();

        ++count;
    }
    while (result->NextRow());

    for (PageTextContainer::const_iterator itr = _pageTextStore.begin(); itr != _pageTextStore.end(); ++itr)
    {
        if (itr->second.NextPage)
        {
            PageTextContainer::const_iterator itr2 = _pageTextStore.find(itr->second.NextPage);
            if (itr2 == _pageTextStore.end())
                sLog->outError(LOG_FILTER_SQL, "Page text (Id: %u) has not existing next page (Id: %u)", itr->first, itr->second.NextPage);

        }
    }

    sLog->outInfo(LOG_FILTER_SERVER_LOADING, ">> Loaded %u page texts in %u ms", count, GetMSTimeDiffToNow(oldMSTime));
}

PageText const* ObjectMgr::GetPageText(uint32 pageEntry)
{
    PageTextContainer::const_iterator itr = _pageTextStore.find(pageEntry);
    if (itr != _pageTextStore.end())
        return &(itr->second);

    return NULL;
}

Lehet hogy nem is jót nézek, de az én logikám ez lenne.
Véleményeket, segítséget elfogadok!

Üdv.: Senki

[EroniX]

Engem is érdekel ez a téma, vegyél fel skypon:
tamee88

[NevemSenki]

Engem is érdekel ez a téma, vegyél fel skypon:
tamee88

Ha itt beszélnénk meg, akkor esetlegesen mások is segítenének. Ez azért egy olyan dolog, amit lehet hogy többen is alkalmaznának. Én azt javaslom, hogy itt próbáljuk megoldani a dolgot, ezzel is segítve a fórum életben maradását.

Üdv.: Senki

[NevemSenki]

Kicsit elfoglalt voltam mostanában. Ez 1978-as Rotát restaurálok, eredeti alkatrészekkel, mindene megvan még a garanciajegye is. Mindegy is....

Hogyan kéne ennek a dolognak nekiállni? Akinek van ötlete vagy véleménye az írjon bátran!!

Üdv.: Senki

[NevemSenki]

Én ezt akkor sem akarom annyiba hagyni.

Én addig jutottam, hogy már 60 DBC fájlt átdobtam Adatbázisba... haladok vele...
Nézegettem a dolgot.. de mivel sosem foglalkoztam hasonlóval, így hát nem jutottam semmire....
Nekem annyi is elég lenne ha elmondaná alaki hogy mégis hol induljak el... miképpen kéne ebbe belekezdeni.... utána már lehet hogy rájönnék hogy miként csináljam meg ( remélem belátható időn belül )

Vannak köztünk Script-er emberkék akik állandóan a script-ekkel bogarásznak. Ez már nektek is nagy falat lenne?
Tény... hogy ez nem egy agyontaposott teleportNPC lenne....

Ha itt nem sikerül semmit sem elérnem, átnézek Informatikai Kerekasztalra.... Nem akarom ezt annyiba hagyni, nagyon hasznos dolog lenne, főleg azért mert nekem már egy adatbázisban van mindenem.. könyebb lekérdezések... sorolhatnám...

Valaki ha tud mondjon valamit!

Üdv.: Senki

[Shyro]

Fogalmam sincs, hogy milyen koncepcio alapjan tarolnak adatokat dbc fajlokban, ezen kivul meg nem tudom, hogy mikent hasznalja fel az adatokat a core. Ahhoz, hogy barmi okosat tudjak mondani, eloszor atkell latnom, hogy jelenleg mikent mukodik, es ez alapjan mit kellene modositani. Nagyvonalakban ertem a dolgot, de az keves. Esetleg utana tudnek segiteni a dologban, ha mar van ralatasom a leirtakra. Ebben termeszetesen varom a segitsegedet.

Az elso benyomasom (amit EroniX is mondott), hogy elso korben importalni kell az adatokat az adatbazisba. Ha jol tudom a dbc fajlok tartalma a core futasa soran nem valtozik, igy eleg megirni annyit, hogy azokat az adatokat (vagy mindet) amire szukseg van a core beolvassa az adatbazisbol indulasnal, majd azt hogy ahol ezeket az adatokat felhasznalja a core ott az altalunk beolvasott tarolokbol olvassa.

Kesobb talan tobbet tudok hozzaszolni a temahoz, de az is lehet, hogy ennel oszetettebb a problema.

[Shyro]

Van 2 tabla a world adatbazisban.
achievement_dbc
spell_dbc
A wiki szerint ezekben olyan adatok vannak, amik a dbc fajlokban nem leteznek, pedig kellene, hogy letezzenek.
Igy a LoadDBC(...) [DBCStores.h] fuggvenyt ugy irtak meg, hogyha kap 2 + paramtert (customFormat/customIndex), akkor adatbazisbol IS olvas valamilyen modon.
A paramterek konstansok melyek definicioja a [DBCfmt.h] - ban talalhato, es a [DBCStore.h] - ban van megirva, hogy mikent hasznalja fel a program ezt a ket parametert.

En ugy csinalnam, hogy szinten hoznek letre *_dbc tablakat, atirnam a Load() [DBCStore.h] fuggvenyt, hogy csak adatbazisbol olvasson, a LoadDBC() [DBCStores.h] fuggvenyen is kellene egy keveset modositani, es a [DBCfmt.h] - ba definialnam a sajat customFormat es customIndex konstansaimat.

Ez a modszer lenne a leghatekonyabb, jarna a legkevesebb modositassal es lenne a legkevesbe rombolobb az egesz szempontjabol (talan). Viszont van 1 bokkeno: emberes feladat lesz kommentek es dokumentacio hijjan (erre a C++ is ratesz 2 lapattal) kibogaraszni, hogy mire gondolt a kolto amikor ezt megirta.

[NevemSenki]

Nagyon jó az útmutatás!!

Belevetem magam a C++-be valamilyen módon elkezdem... hogy valamit azért megértsek belőle.
Én átteszem a DBC-ket adatbázisba... és a te elméleted alapján szerintem ez az egész megvalósítható lenne!
Köszönöm a hozzászólásodat!!!

Üdv.: Senki

[clawlancer]

Erről volt régen egy topic, és a nagy arcok 2 opciót mondtak:

1. Azért mert így jó és kész, meg így elméletileg könnyebb kiolvasni a kliensből, már pedig ha minden meglenne fejtve, igazándiból minden dolog megoldható lenne DBC-kből
2. Nem igazán szeretnének sok dolgot SQL-ből futtatni, régen volt terv hogy a Boss scriptek,  átmennek SQL-be, de ezt is eltörölték, jó az úgy ahogy van.

Én ennyit tudok hozzászólni

[EroniX]

régen volt terv hogy a Boss scriptek,  átmennek SQL-be, de ezt is eltörölték, jó az úgy ahogy van.

Mindent átraktak a SmartAI és hozzá hasonló szarságokkal DB-be, a boss scriptek pedig azért maradtok ott ahol mert egyszerűen olyan bonyolultságúak, hogy a legegyszerűbb C++-ban megírni.

[NevemSenki]

Tény, hogy könnyebb kipakolni a kliensből. De ezek nyers adatok, pont mint egy adatbázis.. táblákra bontva.
De mivel már nincs Patch váltogatás, így nagyobb lényegét látnám ha Adatbázisban lennének.
Rá lehetne keresni értékekre... stb....
Mellesleg....  ki van csomagolva mind a 246 DBC fájl. Kétlem hogy az összes DBC-ből az összes oszlop kellene. Vegyük csak a local szerinti nyelvet. Akármilyen régiókódú kliensel fel tud jönni a szerverre. Ha figyelembe venné mondjuk példaképpen az " Area " neveket, akkor kis ütközés lenne.
Mert az én enUS DBC-im kicsit sem hasonlítanak a ruRU DBC-khez.
Csak vessetek egy pillantást a DBC-k tartalmára....

Szerintem akkor volt a fentebb írt mondat mérvadó, mikor még küzdötte fel magát TC a " Patch " létrán.

Üdv.: Senki

[NevemSenki]

Elnézést a Dupla Post-ért, de!

Item.dbc

[itemID]	[ItemClass]	[ItemSubClass]	[ItemDisplayInfo]	[Name]
[17]	[4]	[4]	[7016]	[??]

Item_Teplate ( MySql )

[itemID]	[ItemClass]	[ItemSubClass]	[ItemDisplayInfo]	[Name]
[17]	[4]	[1]	[7016]	[Martin Fury]

Wowhead ( XML )

Kód (javascript) Kijelölés Kibont

<![CDATA[
"armor":0,"classs":4,"commondrop":true,"displayid":5663,"id":17,"level":1,"name":"7Martin Fury","slot":4,"slotbak":4,"subclass":-8
]]>


Akkor ez most hogy van? Tény, hogy eltérhet a Wowhead XML. De az Item.DBC és az Item_Template hogy a viharos picsában térhet el? Ez nekem valahogy nem tiszta. Más rendszer szerint csinálta TC ( példából kiindulva ) a SubClass-okat?

De ha ezt nem is vesszük, miért van duplán a Class és SubClass opció? Egyszer szerepel a DBC-ben, másszor az adatbázisban is, ráadásul eltérő értékkel.

Tök egyszerű lenne kijavítani, a már sokak által felhozott hibát. Mégpedig az Egyedi Item-ek [ ? ] ikonját. Ha adatbázisban lenne az Item.DBC, csak simán létrehoznánk egy új sort a kellő ItemId-vel, és adnánk neki egy Ikon-t.

Érdekes.........................................................


Üdv.: Senki