Nie wiedziałem w którym dziale to napisać, więc napisałem tutaj. Śledzę projekt VCMI, od już dłuższego czasu i cały czas mu kibicuję, ostatnia wersja wydała mi się wystarczająco dobra, żeby spróbować swoich sił w zrobieniu moda na bazie VCMI. Niestety lekko się pomyliłem, gdyż myślałem, że limit jednostek jest złamany.
Mój problem polega na tym, że limit ustawiony jest na 196. Każde dodanie postaci w pliku
ZCRAITS, powoduje błąd, że “String” jest w nieodpowiednim miejscu.
Czy to jest jakieś niedopatrzenie, czy dopiero zamierzacie złamać ten limit ?
Mam też prośbę, czy w kolejnych wersjach, dzięki plikom config, a szczególnie plikowi building, będzie można dodać 3 ulepszenia ?
Żeby była jakaś baza pod tworzenie 3 jednostek. Dzięki czemu w łatwy sposób mogła być 8 jednostka z WOG, jako po prostu ulepszenie 7.
A nawet wprowadzenie prawdziwych 8 w zamkach.
Powinno też być takie coś, że jeżeli w pliku building.json jest więcej wymienionych zamków, to powinno od razu czytać i ładować wszelkie dane z innych plików.
Choć ustawiłem 9 zamek, kopiując Rampart, jako 9 i pozmieniałem we wszystkich configach to co trzeba było i nawet w plikach .lod to i tak wyskakiwał błąd w commander.json, w którym było wszystko dobrze, kilka razy sprawdzane.
Mam nadzieję, że mnie zrozumiecie.
PS. Co do pierwszego, ustawiane jednostki podmnieniałem z NOT USED i śmigało, i podmieniłem jednostki w grze.
Wszystkie informacje o jednostkach, a także ich grafiki są wczytywane z oryginalnych plików gry, a wielkość tych plików jest ustalona na sztywno. Owszem, zamierzam się a niedalekiej przyszłości zabrać za ten problem, ale do funkcjonalnego systemu modów droga daleka.
Nie wiem co prawda, jak to dokładnie działa, ten pomysł wprowadził Ivan.
Powinno, ale tych plików jest mnóstwo, a każdy inny. Modowanie miast to bardzo odległa perspektywa. Chcemy też rozwiązać ten problem lepiej, niż przy pomocy pliku konfiguracyjnego.
Proponuje dodać plik limits.json z wartościami tych limitów zamiast ustawiać przez const w pliku include. Pomoże to we wczesnym podchodzeniu do jeża, chciałem powiedzieć moddingu VCMI przez podmianę istniejących plików danych. Dodatkowe jednostki w ZCTRAITS można dodać zgodnie z bieżącym standardem (format wspólny dla ZCTRAITS z woga i CTRAITS z SoD tak jak w modzie/etyczce amethyst do ERY). Problemem jest że wiele wartości dla stworzeń jest poza tymi tabelami (Amethyst dodaje dla nich nowe pliki konfiguracyjne bo w SoD/WoG/ERA są one zakodowane w pliku exe) ale problem chyba już został (częściowo) rozwiązane przez pliki konfiguracyjne VCMI które były dodane przy implementacji między innymi tego która jednostka strzela (flaga w polu monster flags w oryginalnym SoD/WoG, niedostępnym przy moddingu SoD bez zmieniania pliku exe, w WoG dostępne przez skrypty).
Nie wiem czy cię dobrze zrozumiałem majaczek, ale na dzień dzisiejszy dodanie jednostki w ZCTRAITS powoduje błąd, przynajmniej tak jest u mnie za każdym razem.
edit:
za każdym razem pojawia się error w logach i wywala grę:
“invalid string position”
HellKiller generalizuję… ogólnie format jest taki że większość to fragmenty które mogą się powtórzyć dowolną ilość razy i trzy puste linie na końcu - zarówno w SoD (tu plik nazywał się inaczej) WoG i ERA z Amethyst… ale część limitów jest wpisanych z palca w kodzie vcmi (plik GameConstants.h chyba) i twój mod musiałby zawierać przekompilowane VCMI z tymi kilkoma liczbami zmienionymi w kodzie… sporo roboty więc zaproponowałem aby developerzy odwalili robotę za ciebie tj. wczytywali tę wartość z pliku a nie ustalali w programie niezależnie od configu. … …
Właśnie znalazłem w GameConstants, liczba jest sztywno ustawiona na 197, ale jak się nie mylę liczy od zera, dlatego nie mogę dodać kolejnych.
Dzisiaj lub jutro wgram VC2010 i powinienem przekompilować jutro VCMI.
Dziwi mnie to, że takich wręcz podstaw nie można zmienić, gdyż taka rzecz powinna się od razu znaleźć.
Nie najeżdżam na projekt, bo idzie w bardzo dobrym kierunku, ale na tym VCMI popularność ma polegać i polega, że łamie wszelkie limity i jest genialną bazą dla moderów.
Mam na koniec pytanie, dlaczego podchodzicie do tego, że jeszcze długa droga do tworzenia modów i że należy czekać, bo będzie to w przyszłości. Oczywiście jeszcze część podstawowych funkcji jest niewdrożona, ale to nie znaczy, że nie możecie pomóc sobie jak i innym
Ta stała nie jest nigdzie używana. Akurat ZCRTRAIT.TXT powinien być parsowany niezależnie od stałych, tj. ile linii z wpisami znajdzie w pliku, tyle stworów doda. Jeżeli twoje dodanie wpisu psuje parsowanie, to wygląda, że nie zachowujesz oryginalnej składni (uwaga na różne rodzaje białych znaków!).
Ale możliwe też, że wywala się nieco dalej, bo informacje o stworze to więcej niż sam ZCRTRAIT. Np. musisz też dodać wpis do CRANIM.TXT — jak go tam zabraknie, to też się wykrzaczy (wpisy w obu plikach muszą się „parować”). Jeszcze jest w naszym configu creatures.json, no i oczywiście kwestia zapewnienia samych grafik, powstawiania nowych klatek do defów takich jak TWCRPORT.DEF, ten drugi z miniaturkami i podobne.
Mnóstwo dziubdziania w rozmaitych miejscach. Nawet jeśli się uda dodać stwora w ten sposób (prawdę mówiąc nie mam pojęcia, czy gdzieś coś nie zostało jeszcze zahardkodowane), nie jest to sposób modowania, który bym mógł komukolwiek polecić i spojrzeć potem z podniesioną głową w lustro. Modowanie przez modyfikowanie oryginalnych plików to… dalekie zboczenie z drogi cnoty.
Najpierw baza, potem nadbudowa.
Chcesz zrobić moda, więc patrzysz na nasz projekt z perspektywy modera. Jest to oczywiście zrozumiałe i słuszne, ale mod pewnie kierujesz go jakichś odbiorców-graczy, a Ci mają własny punkt widzenia. Podstawową kwestią, warunkującą sens istnienia jakichkolwiek modyfikacji do VCMI, jest zapewnienie wsparcia dla funkcjonalności oryginalnej gry. Co z tego, że zrobisz moda, dodasz 50 stworów i 2 miasta, jeżeli i tak nikt nie będzie chciał z tego dzieła skorzystać, bo silnik jest niekompletny funkcjonalnie i wywala się przy byle okazji?
Mody nie są istotnie potrzebne, dopóki silnik nie jest grywalny i stabilny. Możnaby je oczywiście było zrobić dawno temu, ale pożytek byłby znikomy (chwila radości dla moderów-grafomanów, którzy jedynie chcą dodać jednostkę i schować dyskietkę z modem do szuflady). Ceną natomiast byłby wzrost kosztów utrzymania, struktury danych gry ewoluowały w ciągu lat i taki system modów trzeba by było w kółko poprawiać.
Z cyklu wynikałoby, że we wrześniu. Cykl jest ważny, projekt wydaje się dzięki niemu dobrze zorganizowany.
Inna sprawa, że akurat jak mi się wydawało, że będę miał trochę czasu, to się pojawiły na horyzoncie inne zadania. A niestety, $$$ > VCMI. Przy projekcie cały czas pracuję i posuwam sprawy naprzód, po prostu nie idzie to tak szybko, jak bym chciał.
Dziękuję za wyczerpującą wypowiedź. Zapomniałem o przerobieniu pliku CRANIM, inne przerobiłem.
O wyniku poinformuje edytując post.
edit:
Działa! Dziękuję. Po przerobieniu CRANIM, już się nie krzaczy i mogę spokojnie brać się do wpychania jak największej ilości jednostek ;).
Mam też prośbę, czy w kolejnej wersji moglibyście dodać, że plik ZCRTRAIT.txt i CRANIM.txt, może czytać z folderu? Pliki DEF, VCMI czyta z folderu sprites, ale już plików txt nie czyta, a to ułatwiłoby pracę.
Podmienianie plików przynależących do h3bitmap.lod przez umieszczanie plików w Data/ działało jeszcze w H3. Folder Sprites to już nasza innowacja.
Jakbyś chciał jakoś jeszcze zmyślniej zorganizować sobie pliki, to rzuć okiem na plik config/filesystem.json. Tam możesz określić lokacje, w których są szukane poszczególne rodzaje plików (tekstowe configi Heroesa to kategoria DATA).
