Tak, chcemy docelowo coś takiego zrobić.
Ale oczywiście ma to rację bytu gdy rozbieżności są niewielkie (bo np. przesłanie trzech miast do siedmiu graczy by trochę trwało).
Powino się ulepszyć też system doświadczenia gdyż jak pokonam z 1000 Drakoliczów to 10 centaurów dostało smieszną ilość doświadczenia
Ja się do tej pory nawet nie orientowałem jak dokładnie system doświadczenia wygląda w WoGu… ale oczywiscie można będzie zrobić trochę inny niż tam, jeśli bedzie to sensowne. Ale to jest wątek o rzeczach, któe mają być dodane a nie zmienione. Coś takiego powinno raczej trafić do wątku “Pomysły”.
Mam fajny pomysł żeby zrobić jak w Heroes 5 pod zdolności
No na to chyba gra juz nie pozwala. Zreszta… po co? Podzdolnosci w H5 sa inspirowane H4, a tam podzdolnosci przewaznie byly przeniesionymi umiejetnosciami z III. Poza tym trzeba by kombinowac z wymyslaniem nowych itd.
Na to jeszcze gra nie pozwala. Ale muszę przyznać, że to świetny pomysł! Otwiera ogromne mozliwości do popisu dla twórców modów, ale też pojedynczych map.
Technicznie chyba wystarczy dodać opcję, kiedy dana umiejętność wymaga posiadania innej.
Ogólnie z powodu coraz to nowych komplikacji przydałoby się dodać w oknie bohatera nieograniczoną, przewijalną listę na którą w przyszłości trafiać będą informacje o kolejnych pomysłach modderów. Na przykład zamiast bajerować grafikami sagamosy, wystarczyłoby dodać te cztery linijki tekstu opisujących profesje. Podobnie z dodatkowymi bonusami bohaterów, umiejętnościami albo po prostu liczbowe zestawienie różnych modyfikatorów., jak w grach opartych na D&D.
Proste, a daje ogromne możliwości.
Skrypty Sagamosy nie są złe. Jego skrypty to zdolności rasowe a te które ja mam na myśli to rozwinięcia zdolności Np .
Magia Wiatru poziom Expert
Pod zdolności które można wybierać wraz z wzrostem poziomu.Każda zdolność może mieć wybrane tylko trzy pod zdolności
Mistrz błyskawic-Zwiększa obrażenia czarów błyskawic o 10 % oraz ogłusza cel na 1 kolejkę
Mistrz łask - Czary łask trwają o 2 kolejki dłużej
Mistrz klątw - Czary klątw trwają o 2 kolejki dłużej
Burzowa aura- jest szansa że zamiast żywiołów wiatru przyzwiemy żywiołaki Burzy 20%
Magiczne przyspieszenie - mając taktykę czar przyspieszenie daje nam dodatkowy punkt szybkości
Grafiki muszą być zawsze bo bez nich nikt by niegrał w Heroesy
Chodziło mi o balans.Np zdolność sokoli wzrok jest tak słaba że dodatkowo twórcy hoom3 dodali że na ekspercie ta zdolność jest o wiele gorsza niż taktyka na 1 poziomie.Chodziło mi żeby słabsze zdolności upchać do tych silniejszych
ja to myślę tak - większe mody funkcjonowałyby jako tak zwane pak-i (zestaw danych, skryptów i konfiguracji zapisane w jednym archiwum np. wysoka kompresja 7z [format niezbyt standardowy ale nowa technologia kompresji - LZMA]) każdy pak miałby własny metatekstowy plik konfiguracyjny plus konfiguracja modułów do wł/wył (w głównym pliku konfiguracyjnym pak-u byłyby wypisane m.in nazwy plików konfiguracyjnych modułów), oczywiście byłaby kontrola md5 pliku już spakowanego
serwer gry by wybierał z których paków korzystać i przesyłałby prosty ini z zaznaczonymi opcjami wybranymi w menu na serwerze(w tym wartości które są zaznaczone jako liczba do wyboru), gdy klient ma paka, lub najpierw by go wysłała gdy klient nie ma [byłaby też opcja blokowania przesyłania paków, wtedy klient niezgodny nie mógłby się podłączyć], a grafiki można by było wybierać na poziomie plików konfiguracyjnych paka (a nie ‘twarde’ ścieżki)
każdy pak byłby oznakowany w następujący sposób “data-twórca-dodatkowy_tekst.pak” (np. “20080930-majaczek-miasto_elvenville.pak”) , a rodzaj kompresji sprawdzałby moduł pakera (może jako polecenie zewnętrzne)
w ten sposób do dogadania się, w najmniej konfliktowym przypadku, wystarczyłoby podać identyfikator paka, sumę md5, i prosty ini z opcjami co w większości przypadków oznaczyłaby transmisje kilku kilobajtów lub kilkuset bajtów.
Zauważcie że w ten sposób można w jendym dodatku zamieścić kilkadziesiąt opcji do wyboru i parenaście do tuningu (np. czy czary/jednostki mają być dostrojone do homm3sod czy na przykład na 75% czy 120%), a na dodatek możnaby mieć zainstalowane różne dodatki modyfikujące te same dane i w czasie rozgrywki wybrać z którego się korzysta, bez ciągłego nadpisywania np. defów w tym samym katalogu
w odróżnieniu od “twardych” ścieżek można by było ustawić identyfikatory danych, z których każdemu można by przypisać w pliku konfiguracyjnym inną twardą ścieżkę
np. mon123=data\smoki\majaczek\turkusowy*
można by też zrobić wielowarstwowe tłumaczenie symboli np. smokdia=gamepath("\jakas_sciezka*") a gdzie indziej mon238=gamepath("\smokdia")
w skryptach najlepiej dane opisywać przez identyfikatory, tak by można było zmienić jurysdykcję skryptu w odpowiednim pliku konfiguracyjnym lub innym skrypcie
rozwiązanie paka jest o tyle dobre że wystarczy policzyć sumę kontrolną jednego średniego pliku i tylko raz na grę, a nie sprawdzać za każdym razem setki małych plików
można by przez symbole dokonywać łączenie elementów jednego obiektu z listą zmian w drugim np. mon238=gamepath.merge("\smokdia","\inna_sciezka\stat*")
pomysł by taki można poszerzać i poszerzać, ale chyba poruszyłem kilka z najważniejszych jego cech
Czyli jak w Homm5.Pomysł dobry.Bo tylko za pomocą tych plików pak. można by coś wprowadzić do gry.Wprawdzie można by zmienić def błękitnego smoka na Chłopa np simple lodem ale chłop to zawsze chłop,statystyk to nie zmieni .
Majaczek, mam do ciebie jedno pytanko.
Mianowicie, jakim programem będzie tworzona suma kontrolna md5, i czy wszyscy, którzy będą chcieli zagrać PAK-ami muszą posiadać ów program?
@majaczek
Po pierwsze jakoś bardziej przypada mi do gustu koncepcja modów z gry Spring. Nie ma tam możliwości konfigurowania moda przy jego wyborze, ale opcja taka nie wydaje mi się aż taka potrzebna - kto naprawdę chce, może łatwo zmodyfikować samego moda, a takie parametry wprowadzałyby tylko bałagan. Wydaje mi się, że ludzie szybko doszliby do tego, któe są najlepiej zbalansowane i zalecali grę tylko na tych (szczególnie na turniejach). W Springu aby przygotować własnego moda nie trzeba się bardzo trudzić - można zrobić moda który jest nakładką na innego moda i nadpisuje tylko niektóre ustawienia.
Po drugie nie wiem, na co ci dobra komprecja w modach. Przy obecnych szybkościach łącz i pojemnościach dysków nie ma sensu dbać o te kilka potencjalnie zaoszczędzonych megabajtów. Poza tym lepsza kompresja będzie powodować mniejszą szybkość działania VCMI (dłużej będzie schodziło rozpakowywanie). Ja bym się zastanawiał między danymi nieskompresowanymi a zwykłym zipem.
Dalej, twój system nazywania tych “paków” jest dosć nieczytelny - moim zdaniem nazwa jest ważniejsza niż data i powinna być na początku, twórca jest raczej nieistotny, a zamiast długiej daty dałbym po prostu numer wersji.
Na koniec zwrócę uwagę na to, że w sumie nie ma potrzeby liczenia za każdym razem sumy md5 - wystarczy jakiś identyfikator moda zawarty w nim samym który pozwalałby go odróżnić - na przykład nazwa i numer wersji. W przypadku załadowania złego moda (co w moim modelu przez przypadek zdarzać się i tak nie powinno) i tak ucierpieć może tylko gracz - nie będzie mógł oszukiwać, bo komendy są i tak kontrolowane przez serwer. A że np. chciałby, żeby jego chłopi wyglądali jak błękitne smoki… po cóż mu bronić ;].
Sumy kontrolne md5 liczyłoby samo VCMI - np. poprzez tą bibliotekę: cryptopp.com/ . Jednak jak już pisałem nie jestem przekonany do tego pomysłu.
problem kompresji nie jest taki duży, zakładając że gra będzie korzystać z katalogu tymczasowego do którego dekompresuje co trzeba, kiedy trzeba, żeby nie trzeba było kilka razy to samo rozpakowywać…
konfiguracja wydaje mi się niezbędną rzeczą, a coś takiego jest już w WoGu, (mamy menu WoG options które tworzy plik konfiguracji, tyle że niefrasobliwy bo binarny, moja opcja zakłada korzystanie z nazw a nie numerów zmiennych konfiguracyjnych - więc ini jest w porzo, poza tym mógłby być podzielony na sekcje dotyczące oddzielnych modów, poza tym powinna być opcja zapisywania opcji… a zmienne typu int to bonus do wogowego systemu “wszystko albo nic” (praktycznie każde rozszerzenie gry można tylko włączyć lub wyłączyć) a można zrobić i chociażby multipliery. w pliku twardej konfiguracji byłoby napisane z jakich danych korzysta mod, pogrupowano by je, oraz zapisano jakie zmienne ustawia się w miękkiej konfiguracji i za pomocą jakiego menu
a data zamiast wersji to specjalny chwyt: załóżmy że ktoś porzucił mod w wersji 113 - a dwóch ludzi zamierza go rozbudować i jeden nie wie o drugim - i co mamy? dwie różne wersje 114 
PS: apropos kompresji przydałby się jakiś bufor cache do defów, tak by te najczęściej używane mogłyby być otwierane z niego bez kompresji (w rozsądnej konfiguracji pozwalałoby zaoszczędzić do 20% mocy procesora używanej do interfejsu
PS2: oprócz paków kontrolowanych byłyby takie z samymi grafikami, które nie musiałyby być sprawdzane, ale nie mogłyby mieć zawartości aktywnej (skrypty, statystyki, etc.),co byłoby sprawdzane powiedzmy byłyby to *.static.pak, lub *.flat.pak, a kontrolowanie całości jest potrzebne ze względu na różne menu przyciski i innne duperele, nawet niestandardowe pliki wejście (czytane przez skrypt)
a kompresje 7z można zrobić poprzez polecenie zewnętrzne, które zapewnia darmowy program (część pakietu 7zip, właściwy paker wywoływany z linii poleceń)
Po pierwsze nie napisałeś ciągle, na co ci ta konfigurowalność w samej grze - przecież będziesz mógł niewiele większym nakładem sił przygotować własny minimod nadpisujący ten, który chcesz lekko zmodyfikować. Początkujący gracze i tak nie bedą się orientować w tych mnożnikach a bardziej doświadczeni będą grali najczęściej na jednych lub paru ustalonych. Pozostają więc tylko średniozaawansowani gracze, którzy wszak mogą przygotowywać własne minimody z tymi mnożnikami na przykład. Całość się będzie sprowadzała do zrobienia pliku ini z zawartością np.
override_mod="Standard SoD-1.01.zip"
multiplier1=2.0
multiplier2=12.4I zapakowania go do jakiegoś zipa Czy to aż tak niewygodne?
A załóżmy, że wydali te wersji 114 w ten sam dzień i mają takie same nicki. Ten problem wydaje mi się dość abstrakcyjny, takie mod miałyby albo niewielki zasięg rozprowadzenia albo ich autorzy musieliby nawzajem o sobie wiedzieć. Żeby temu zapobiec należałoby wprowadzić jakieś dodatkowe środki ostrożności - np. ostrzeżenie w przypadku niezgodności jakichś innych danych o pliku niż nazwa.
No cóż, na pewno to pozwoli zaoszczędzić do 100% mocy procesora (;]), ale nie rozumiem twojej propozycji. W VCMI defy nie są ładowane bez akcji użytkownika - a minimalny wzrost szybkości np. wchodzenia do miasta w sytuacji, gdy czas otwarcia ekranu miasta jest bardzo mały nie wydaje mi się palącą potrzebą.
Nie wiem, na co to. Obecnie planujemy wykopać z klienta VCMI wszystkie informacje, których gracz mieć nie powinien. W takiej sytuacji żadnym sposobem jakikolwiek mod nie będzie mógł dać graczowi przewagi w grze (a i bez tego będzie to praktycznie niemożliwe przy odpowiednim zaimplementowaniu obsługi tego, co będzie z takiej paczki wykonywane lokalnie). Może to być przydatne dla modderów, którzy chcą tylko grafiki podmieniać, ale… czemu właściwie nie mogliby sobie zrobić własnego moda? Napisaliby, że ich mod jest kompatybilny z jakimś innym i kto by chciał, wiedziałby, że taka kompatybilność występuje. Możnaby ją nawet wpisywać do samych modów i wszystkim by się wyświetlała przy grze. “Chosen mods are compatible/incompatible”.
O ile wiem, jest możliwość rozpakowywania 7z przez bibliotekę w C++.
no jest dev-lzma … tyle że rozwiązanie przez polecenie zewnętrzne jest prostsze, po drugie, przy pozostawieniu niekomercyjności vcmi i wzmiance o plikach których licencja vcmi nie obowiązuje (tzn. że są oddzielnie licencjonowane i mała wzmianka jak), nie ma większych problemów w rozprowadzaniu vcmi z zewnętrznymi programami poleceń w freeware itp.
–drugi post
bufor cache byłby po to aby najczęściej używane dane domyślnie skompresowane były dostępne bez wielokrotnego powtarzania obliczeń służących dekompresji
–trzeci post
właśnie że niewygodne, bo każdy musiałby mieć tego zipa, a gdyby były stosowane np. 1238 wersje grup wartości mnożników - to by gracze którzy chcą być kompatybilni mieliby cały śmietnik małych zipów.
załóżmy że używany ma być mod który modyfikuje trudność rozgrywki, lub celowo daje przewagę jednych graczy nad innymi (tzw. handicap) … jak myślicie, wtedy informacja o zmianie procentowo wybranych przez mod danych, byłaby wysoce pożądana do konfiguracji…
wtedy wszystkie mody typu “modyfikuj siłę wszystkich strażników na mapie”, “zmień n% strażników na mapie, na stwory z modu xyz”, itp. mogłyby wychodzić w jednej wersji i być tylko konfigurowane na serwerze, poza tym niektóre wartości mogłyby być typu string - bo na przykład w polu wybierz język trudno podać numer, a łatwiej wpisać pl, en, ru, jap itp.
–czwarty post
poza tym proponuje by większość informacji nie ustawiać jako hardcoded, tylko rozpisać po plikach metatekstowych (np. jakaś implementacja xml-a), wtedy dużo łatwiej byłoby robić mody tłumaczące, dodające nowe obiekty w pewnym sensie podobne do już istniejących (np. nowe typy miast) i różne inne
[size=75]Posty scaliłem. Na przyszłość proponuję korzystać z konta - wtedy możesz po prostu użyć opcji edit.[/size]
A wszystko to po to, aby lekko poprawić kompresję? Nie, dziekuję bardzo.
Zapominasz, że “najczęściej” to w przypadku danych skompresowanych przynajmniej z pół minuty z bardzo nielicznymi wyjątkami. Więcej zabawy niż pożytku. A w niektórych miejscach nawet przechowywanie danych w postaci skompresowanej cały czas (!) jest wskazane - na przykład w przypadku animacji jednostek. Co klatkę są one rozpakowywane, bo w innym przypadku zajęłyby nieprawdopodobną ilość pamięci (gdzieś na tym forum chyba było wyliczenie, to chyba wyszło do 2 GB w jak najbardziej realnym przypadku).
W ten śmietnik to ja nie wierzę, w takim przypadku możnaby dodać wsparcie dla modów w podfolderach. Np. modyfikacje do moda A byłyby w folderze A, do B w B itd. Poza tym rozsądnych kombinacji różniących się czymś istotnym raczej nie byłoby aż tak dużo. Sądzę, że jeśli mielibyśmy dodawać ustawianie jakichś mnożników poza modem, to tylko na wyraźną prośbę przyszłej społeczności graczy. W szczególności nie widzę, aby twój pomysł ktokolwiek tu popierał. Tak czy siak, na razie wsparcia dla modów robić nie bedziemy, gdyż mamy ważniejsze rzeczy do zrobienia.
Już to robimy, zerknij sobie choćby na 30 plików w folderze config - tam są różne opcje, które można modyfikować bez rekompilacji VCMI, a których nie dało się ustawiać za pomocą plików tekstowych z lodów. Tylko na razie nie widzieliśmy potrzeby wykorzystywania formatów metatekstowych… rozumiem, że np. skryptowanie okienek z VCMI w XHTMLu z CSS byłoby fajne, ale kto to ma zaimplementować?
po co od razu xhtml?
wystarczy własna implementacja xml, nawet z małą ilością tagów
coś w stylu
coś tam tak nie
z tym że np. bitmapy możnaby osadzać w polach wyboru etc. łapałyby też pliki w wszystkich graficznych formatach obsługiwanych przez vcmi