Jakie chcielibyście miasta w VCMI.
Ja:
-Forge (nawet fajny pomysł)
-GroveURL (ma w sobie coś bajecznego i mrocznego .Dlatego mi się podoba)
-Coś na kształt potworów morskich(nie chodzi mi o piratów tylko o same potwory : krakeny ,lewiatany itd.Miasto mogło by być tylko na wodzie a bohater jeździł by na wodzie bez statku)
Forge zawsze popierałem. Grove moim faworytem nigdy nie było, za warcraftowskim stylem grafiki nie przepadam. Z istotnych projektów pominąłeś egipski Bastion.
Oczywiście możemy sobie życzyć lub nie życzyć rozmaitych miast, ale… tak naprawdę na razie nie mamy żadnego.
Liderzy grup odpowiadających za Bastion i Grove należą do grupy CoreWoG, tak więc możliwe, że właśnie te miasta zostaną ukończone i wraz z WoG-iem 3.59 ujrzą światło dziennie. W takim wariancie zostaną wsparte i po stronie VCMI. Ale droga do tego mimo postępów wciąż daleka.
Ale ogólnie - jak będzie jakieś gotowe miasto, to je wesprzemy.
Natomiast wyliczanie miast marzeń raczej nie doprowadzi do niczego sensownego.
Grove AFAIK kradnie grafiki z innych gier ( Warcraft 3 )
W pełni zaś popieram miasta i grafiki zrobione od zera (jak Bastion czy to co tworzy HoTA)
E tam, zaraz “kradnie”. Ot, “reusability” 
A co do HotA, to o ile wiem przynajmniej nie wszystkie ich grafiki są robione od zera.
zauważyłem że vcmi ma dla zamków własne txt
czy można by zrobić by dla każdego cośtam.txt dodać support dla cośtam.custom.txt, tak by czytał najpierw dane ze zwykłego (waszego) a potem sprawdzał custom i dodawał informacje do gry?
można byłoby testować np. własne zamki, bez nadpisywania (standardowych) plików konfiguracyjnych, które i tak będą nadpisane przy instalacji vcmi, i będą zmieniać się przy każdym wykrytym błędzie/dodanym feature…
(wiele plików txt to listy, wystarczy żeby jakoś łączył treść obu przy inicjacji programu)
ponadto chciałbym castles_replace.txt który by służył grze do zamiany obiektów z edytora map, na nowe zamki według systemu:
jeśli znalazłby losowy zamek z podmienionym defem, szukałby go (defa) w bazie i przy znalezieniu zamieniałby zamek na jeden z nowych, przy wczytaniu mapy
(zamki custom możnaby numerować np. od 32 tak by nie konfliktowały z tymi z plików głównych)
EDIT: wsparcie dla *.custom.txt byłoby mile widziane nie tylko dla zamków, ale np. także dla list bohaterów, stworzeń itp.
Obawiam się, że to zbyt wiele jak na taką drobnostkę. To nie byłoby trywialne w implementacji, szczególnie kontrola zgodności wersji. Dopóki nie zaczniemy zajmować się ogólnym wsparciem dla modów, zostaje ci backupowanie standardowych plików. Wydaje mi się, że mniejszym kłopotem jest backup niż dodanie wsparcia od strony silnika, ktore i tak musiałoby w końcu być przerobione.
Może kiedyś się dorobi, na razie stosunek pilność/trudność jest trochę za mały. Poza tym nie rozumiem idei numerowania od 32… w grze miałyby być naraz zamki oryginalne i podmienione? Na cóż to?
miasta podmienione byłyby jako prowizorka, w chwili gdy nie mamy edytora map vcmi.
po prostu jest to sposób na dodanie nowych zamków opisanych w plikach txt VCMI do mapy: np. zrobi się grafiki i dane dla smoczego miasta z mojego pomysłu i chce się zobaczyć jak to działa na mapie, więc wstawiamy na mapę losowy zamek, podmieniamy def na smoczą utopię i serwer vcmi zauważy że losowy zamek ma podmieniony def, sprawdzi w liście że chodzi o smoczy zamek i przy ładowaniu gry, w miejsce tamtego losowego zamku będzie ten wybrany poprzez tą sztuczkę
równie dobrze może być kilka(naście) nowych zamków i odczyt sprawdza który z defów do jakiego miasta się dopasowuje; DEF pełni tu funkcję markera
@na co numerowanie od 32?
przydatne tylko gdy listę zamków podzieli się na defaultową i custom, wtedy dodanie oficjalnego miasta nie zaszkodzi modom z dodatkowymi miastami użytkownika…
wiadomo że w różnych txt-ach odwołuje się do numeru miasta - przy przypisaniu frakcji potworkom, przy opisie rozstawienia budynków, przy zestawie budynków do budowy w ratuszu, etc.
Zdecydowanie za dużo roboty jak na prowizorkę, przynajmniej moim okiem patrząc. Lepiej to później rozwiązać w sposób spójny niż kompleksowy, niż teraz wprowadzać jakieś brzydkie, tymczasowe sztuczki.
małe FAQ:
pytanie: kiedy planowany edytor? odpowiedź nawet do 1.0 nie jest w pewnych planach
pytanie: kiedy VCMI mogłoby wspierać nowe zamki? ODP: już teraz pod warunkiem że da się go odczytać z mapy (np. podmiana istniejącego, losowanie, lub konwersja obiektu - mój pomysł)
pytanie: co się stanie jeśli odczyta się taką “sztuczkową” mapę w zwykłym wog/sod ? ODP: nic szczególnego, będzie to po prostu losowy zamek
co trzeba byłoby zrobić by dodać typ zamku korzystając z nie-podmienionego edytora? ODP: wesprzeć podobny obiekt z dodanym markerem dostępnym przez edytor który byłby podmieniany w wyniku wykrycia
4-0 dla mojego pomysłu
to byłaby dość trwała prowizorka, niesypliwa, z wizją na przyszłość jako nowy standard
no może 4-1 bo trochę roboty 
(no ale w podstawowej interpretacji jedna strona kodu 
)
nie widzę powodu by unikać pomysłu, jest kilka powodów aby z niego skorzystać
więc co myślicie podsumowywując ten post?
Dobrze, wygrałeś.
Jak dostanę pełen komplet grafik dla nowego miasta, jednostek oraz mechanikę tego wszystkiego (niezbędne rozszerzenia do plików konfiguracyjnych H3 i VCMI) i będzie to trzymać sensowny poziom, to zajmę się wsparciem po stronie VCMI. To wprawdzie trochę roboty, ale już się poświęcę.
Będzie nowy zamek - będzie wsparcie dla nowego zamku.
FAJNIE 
teraz muszę tylko zebrać grafików, lub zebrać grafiki od grup projektujących już miasta…
twoje podejście “wsparcie tylko dla gotowych materiałów” wydaje się bardzo sensowne
teraz tylko muszę się zająć sprawami technicznymi (grafiki, konfiguracja txt)
Dzięki za wszystko…
proponuje, żeby zachować informacje z zamku losowego, który jest markerowany podczas podmiany (garnizon, podstawowe budynki), myślę że będzie to w miare proste
podmiankę można zrobić jako metodę do klasy miasta (np .morph(castle_id), która mogłąby być wykorzystywana później przez skrypty(coś na kształt, burzenia/odbudowy zamku z woga, lub inne użycie) a skanowanie zrobić jako oddzielną funkcję, uruchamianą tylko od razu po wczytaniu mapy, (oczywiście potrzebny będzie txt dekodera jak już wspomniałem)
rozpoczęta praca nad smoczym zamkiem
Hosting provided by DigitalOcean