Witam!

#1

Witam! Mój pierwszy post na forum, ogółem dzisiaj dowiedziałem się o tym projekcie, mam tyle pytań, że po prostu musiałem się zarejestrować.

Na początek jednak zadam trzy najważniejsze dla mnie pytania, potem to już będą setki :slight_smile:

  1. Jaki jest teraz status projektu, pod względem rozwoju, czyli liczby osób i zainteresowania/czasem wkładanych w projekt. Mam nadzieję, że projekt nie umiera! :slight_smile:

  2. Nad czym teraz trwają prace, czy są jeszcze rzeczy, które muszą być dopisane, bo bez nich Heroes jest jak demo, czy może teraz już tylko ulepszacie?

  3. Jak jest z dokumentacją VCMI lub Heroesa 3 jest kompletna/nie kompletna/nie istnieje?

Jestem fanem Heroesa 3 od dawien dawna i chciałbym pomóc, ale oczywiście jeżeli nic nie ma do roboty lub gdy projekt umiera, to już na nic moje chęci :frowning:

Chcę pomóc, ale nie wiem w czym mógłbym się przydać, więc pomyślałem o stworzeniu dokumentacji (o ile taka nie istnieje), coś w tym guście jak dla silnika IE
gemrb.org/iesdp/file_formats/index.htm

Z czytaniem z kodu napisanego w C++ C nie mam najmniejszego problemu, bo cały czas programuję w tych językach. Mógłbym napisać proste konwertery z formatu do formatu, często pisałem podobne rzeczy, ale pod BG (z dokumentacją powyższą). W każdym razie chciałbym pomóc, może się na coś przydam, pozdrawiam!

#2

Znalazłem wikipedie, skoro tam nie ma dokumentacji, to chyba jej jednak ogółem nie ma… Hmmm, rozpocząłbym dokumentacje od spisania wszystkich typów plików jakie gra obsługuje - info wyciągnięte z CResourceLoader.cpp

Trochę oczywistych typów plików:
MAP_ENUM(TEXT) - .txt .jsp
MAP_ENUM(IMAGE) - .bmp .jpg .pcx .png .tga
MAP_ENUM(VIDEO) - .mjpg .mpg .avi .smk .bik
MAP_ENUM(MUSIC) - .mp3 .ogg

Fonty, chyba bez udziwnień?
MAP_ENUM(BMP_FONT) - .fnt descent2.com/ddn/specs/fnt/
MAP_ENUM(TTF_FONT) - .ttf microsoft.com/typography/otspec/otff.htm

Tutaj znalazłem 2 typy Heroes’owe już opisane:
rewiki.regengedanken.de/wiki/Her … _and_Magic
MAP_ENUM(SOUND) - .wav .82m - .82m rewiki.regengedanken.de/wiki/.82 … d_Magic%29
MAP_ENUM(PALETTE) - .pal rewiki.regengedanken.de/wiki/.PA … d_Magic%29

Na temat następnych nic nie znalazłem, albo nie jestem pewny czy służą do tych samych celów co odpowiedniki znalezione w necie:
MAP_ENUM(ANIMATION) - .def - nie znalazłem opisu
MAP_ENUM(MASK) - .msk(akurat ten jest popularny) .msg(a tego nie znalazłem
MAP_ENUM(CAMPAIGN) - .h3c
MAP_ENUM(MAP) - .h3m
MAP_ENUM(ARCHIVE_LOD) - .lod .pac
MAP_ENUM(ARCHIVE_SND) - .snd
MAP_ENUM(ARCHIVE_VID) - .vid
MAP_ENUM(CLIENT_SAVEGAME) - .vcgm1
MAP_ENUM(SERVER_SAVEGAME) - .vcgm1
MAP_ENUM(ERM) - .erm
MAP_ENUM(ERT) - .ert
MAP_ENUM(ERS) - .ers

To jak, mogę rozpocząć robotę :)? Czy wszystkie rozszerzenia są prawidłowo zakodowane? Bo może jakieś nie jest rozpracowane w 100% i nie powinienem ufać kodowi? Jakieś zagwozdki na które, mogę się natknąć opisując to wszystko?

#3

Zacząłbym od zastanowienia się, komu ta dokumentacja ma służyć. Typami plików interesują się głownie autorzy modów. Z reguły rekrutują się na forach poświeconych dodatkowi Wake of Gods i ogólnie pojętemu moddingowi, a zatem wiedzą, który plik do czego służy, jaki ma format i czym go edytować. Oczywiście dobrze byłoby mieć taką dokumentację u nas na stronie, ale to raczej zadanie dla osób doświadczonych w moddingu.

Jedna rzecz, którą zdecydowanie warto udokumentować, to nowe formaty plików (.jpg .pcx .png .tga ) obsługiwanych razem ze starymi. Po prostu nie wszysyc moga o tym wiedzieć.

Dokumentację kodu w doxygenie próbowałem kiedyś stworzyć, ale nie okazała się przydatna. Podobnie z manualem - tej jest dość sensowny, ale znów nie mam czasu go kontynuować. Z wszelką dokumentacją problem jest ten sam - powinna ją tworzyć osoba DOBRZE znająca projekt, jego założenia i rozwiązania techniczne, a niestety każda taka osoba jest jednocześnie programistą i powinna tworzyć właściwą grę, zamiast dokumentacji.

#4

Typami plików powinni interesować wszyscy, którzy chcą coś stworzyć w silniku gry, ponieważ jest to jakaś podstawa dająca pojęcie o tym co mogą w tym silniku zrobić. Programista i tak to wie, więc mu jest to niepotrzebne, przynajmniej tak się programiście wydaje, każda dokumentacja wprowadza ład. Ponadto tak jak mówisz, jeżeli ktoś jest moderem to sobie poradzi, a co z osobami które dopiero chciałyby poznać i ogarnąć to wszystko? Nikt się moderem nie rodzi :slight_smile:

Z własnego doświadczenia powiem, że dzięki dokumentacji iesdp, udało mi się przerzucić z wszystkich gier IE animacje do BGEE (tego było z 1GB), w życiu bym nie doszedł jaki format ma plik .bam (bez dostępu do kodu, bez dokumentacji, pozostają tylko metody porównywania tysiąca plików)
forum.baldursgate.com/discussion … mations/p1

W każdym razie, nie znam projektu, a bez dokumentacji, mogę zacząć analizować kod. Pomyślałem, że gdy zacznę spisywać myśli z analizy powstanie taka przynajmniej jakaś podstawowa dokumentacja.

#5

Z zastrzeżniem może, że większość formatów z H3 wspieramy jedynie dla kompatybilności z grą, nie chcemy natomiast, by moderzy (czy w ogóle ktokolwiek) tworzyli takie pliki. Po co komu DEF, jeżeli VCMI wspiera zbiór PNG-ów, któéego nie trzeba fikuśnie pakować i który normalnie wspiera przeźroczystość i który można wszędzie bez cyrków wyświetlić/edytować?

Ale tak czy siak — jeśli czujesz inspirację, by opisać formaty, fajnie. Korzystając z forumowego konta możesz edytować wiki VCMI, myślę, że dokumentacja formatów byłaby miłym uzupełnieniem.

#6

Dzięki przydatna stronka, jest też częściowo opisany format .LOD wiki.enleth.com/homm:homm3-lod-archives

Teraz już kojarzę dlaczego w kodzie jest dziwny skok do danego adresu, i co oznacza ta nieznana/nieużywana wartość. Jednocześnie ciekawostką jest wartość ‘type’ w nagłówku, ponoć losowa, może jakaś suma kontrolna typów rozszerzeń w archiwum. Rozpocznę chyba właśnie od plików archiwizujących.

#7

Mało plików .lod w grze :frowning: Trudno będzie wyciągnąć z tego więcej niż to co zostało opisane. Znalazłem za to jeszcze jeden numer od “type” który występuje, jest to 14 i występuje dokładnie jeden raz dla formatu .msg

Troszkę nie ogarniam jak działa wiki, czy mógłbym stworzyć sobie jakiś artykuł do przetestowania jej?

#8

Oczywiście. :slight_smile:
Możesz sobie stworzyć gdziekolwiek stronę i ją pomału budować, eksperymentować — a podlinkować z czegoś ogólnodostępnego dopiero wtedy, gdy będzie zdatna do pokazania.
Masz też swoją stronę użytkownika wiki.vcmi.eu/index.php?title=User:Viader — możesz na niej ćwiczyć, wtedy dla wszystkich będzie jasne, że to twoje.

#9

Dzięki, dobry pomysł, stronka użytkownika będzie dla mnie najlepsza:) Powoli i opiszę wszystkie formaty, które VCMI wykorzystuje, a tak przy okazji, wspomniałeś o animacjach z .png Ale w formacie od ANIMATIONS jest tylko .def, czy obsługa z .png jest już zaimplementowana i po prostu nie został format .png podczepiony pod tą kategorię?

#10

Teraz staram się opisać format H3M, trochę nie jestem pewien if’ów których zacząłem używać w środku struktur, ale nie mam pojęcia jak to inaczej zapisać tak by było ładnie i czytelnie… Póki co trzymałem się tego by kolejność zmiennych i struktur odpowiadała kolejności takiej jak występują w pliku, bez zapisywania żadnych adresów. Przymierzam się do stworzenia szeregu tabelek dla każdej struktury z opisem do czego służy jaka zmienna, jednak zanim zacznę może jakaś krytyka tego zapisu?
wiki.vcmi.eu/index.php?title=Use … ap_formats

I jeszcze jedna sprawa, często pomijane są jakieś informacje, w poszczególnych sekcjach, funkcją skip(), oznaczam je jako niewiadome, ale być może tam są zawsze zera, lub coś w tym rodzaju?

#11

Czasem są tam określone wartości jak zera (to chyba najczęściej), czasem „przypadkowe”. VCMI nie robi to róźnicy i nikt bliżej się tym nie interesował. Co tam wsadzić, by H3 się nie boczył na taką mapę — trudno powiedzieć, trzeba by sprawdzić.

#12

Format H3M to nic innego jak archiwum ZIP. Gdy otworzysz WinRar-em, to zobaczysz w środku plik bez formatu, i w nim jest wszystko zapisane: jakie DEF-y zostały użyte do zrobienia danego pliku H3M. Z plikiem H3C już tak łatwo nie jest.