nagmatwane mody? nie widziałeś The Elder Scrolls 3-4 (morrowind i oblivion)?
żeby różne mody działały razem moderzy muszą się (nie)zdrowo nagimnastykować i jeszcze zazwyczaj to i tak wymaga zewnętrznego fanowskiego narzędzia które trzeba dobrze skonfigurować pod dany zestaw modów a owe narzędzie jest pełnowymiarową aplikacją same w sobie… naprawdę nie wiesz jak to się potrafi skomplikować

@cele
ja uważąm za dobrą strategię wyznaczanie sobie celów pośrednich które ułatwią te docelowe
prostota działania mechanizmu przy jego wysokiej kofiguralności jest podstawowym prawdziwym sposobem na wsparcie modów i przede wszystkim moderów
wysoka konfigurowalność przy niezbyt utrudnionej reszcie może być postawione za cel bez zastanowienia gdyż prawie zawsze się sprawdzi i to często tam gdzie się nie spodziewamy
forma wykonywalna nagłówka modu daje duży wpływ modera na integracje jego modu z innymi i sposób odbierania jego przez silnik gry przy niewielkim utrudnieniu dla mniej zaawansowanych moderów

jednym z najbardziej sprawdzonych celów pośrednich ogólnie w eksploatacji programów jest utrzymanie plików konfiguracji w formie tekstowej - zobaczcie jak się różni tweakowanie linuksa i windowsa

moja ulubiona cecha celów pośrednich są zalety długoterminowe które są nie do przewidzenia startując od zera

@mój największy błąd
moim największym błędem była niespójność prezentacji i praktycznie odwrotny sposób jej realizacji za co bardzo przepraszam i co sporo utrudniło zrozumienie - zgadzam się że uporządkowanie wypowiedzi według tych trzech punktów jest dużo lepsze

@nadzieja
mam nadzieję że zrozumieliście już treść mojego przekazu i wykorzystacie to co najlepsze wwaszym vcmi

The Glory For VCMI!

Nie, nie widziałem tych gier. Tak w ogóle - czy te gry mają mod support producenta czy też fani postanowili to modować na własną rękę? Jeśli to drugie, to twój przykład jest trochę chybiony. I drugie pytanie: jeśli producent dał możliwość modowania, to czy choć minimalnie przewidział chęć mieszania modów czy po prostu jest zasada “jeden mod na raz” (nawiasem mówiąc, ucinająca wszelkie problemy z łączeniem modów - przynajmniej dla deweloperów). Uściślając moją wypowiedź: chodziło mi o sytuację, w której producent gry daje możliwość łączenia modów. Choć w sumie… może ci chodziło o to, że w sytuacjach konfliktu modów losujemy który mod wprowadzi daną zmianę i ewentualnie jakoś grupujemy konfliktowe opcje - np. jak mod A zamienia jednostkę na inną i mod B też chce, to jak wybierzemy jeden z modów do wykonania zmiany to usiłujemy tą decyzję sensownie propagować…

No to mógłby być jakiś cel, ale moim zdaniem mechanizm plików konfiguracyjnych jest prostszy od skryptów… i mógłbyś opisać jakiś konkretny scenariusz, w którym istotnie rośnie konfigurowalność?

TESy mają Construction Set : dzięki niemu można np.dodawać nowe budynki czy postacie. Głównym plikiem modu jest plik z rozszerzeniem .esp w których są główne informacje ( resztę plików np.grafikę wrzuca się do folderu Data Files przez co robi się bałagan) . Dlatego podoba mi się reguła “Wszystko w Jednym Pliku”.

hej mam odświeżony pomysł co do wsparcia modów, ponieważ tamten niedomagał trochę

1. głównym elementem konfiguracji moda byłyby skrypty (najlepiej w Pythonie)
2. zmianę treści dowolnego pliku konfiguracyjnego odbywała się na wywołaniu skryptu z tym plikiem jako parametrem, prze podanie pliku wprost można dodawać tylko nowe pliki
3. zastosowanie wirtualnego systemu plików - wszystkie pliki poniżej 64kb nie będące DEF-ami będą w czasie ładowania modów przechowywane w pamięci, przez co ograniczy się operacje dyskowe - przyspieszy proces ładowania i ubezpieczy dając pewność nie nadpisania ważnych plików
4. bazą virtualnego systemu plików będzie ten realny (realny pozostaje nie zmieniony podczas ładowania modów i odpowiada za początkowy stan VFS)
5. kolejność wykonywania skryptów modyfikujących zawartość VFS zależy od konfiguracji gry (kolejność modów) oraz konfiguracji wewnętrznej moda (plik wsadowy)
6. cały mod byłby paczką tar zawierającą
   6.1 folder VFS zawierający nowe pliki do VFS oraz skrypty edycji które też byłyby ładowane przez VFS
   6.2 dowolną ilość archiwów - archiwa mogą zawierać dane multimedialne (defy, dźwięki, grafiki, filmy itp), oraz folder VFS obsługiwany jak ten z 6.1
   6.3 plik wsadowy startowy, oraz opcjonalnie inne pliki wsadowe
7. plik wsadowy nic by nie robił poza wykonywaniem skryptów edycji (tych w pythonie), przekazaniem do nich parametrów, oraz wywoływaniem innych plików wsadowych
   7.1 parametrem przesłanymi do skryptu edycji musi być jako pierwszy ‘edytowany’ plik (z vfs)
   7.2 parametrami przesłanymi do skryptu edycji mogą być inne pliki pomocnicze (Read/Only) i/lub stringi przekazywane dosłownie
   7.3 przy wywoływaniu pliku wsadowego można przekazać parametry (stringi, pliki) które ten może przekazać dalej
8. skrypt edycji byłby uruchamiany z zainicjowanymi parametrami (plik-> zawartość, string- jak leci)
9. skrypt edycji wysyła na standardowe wyjście przetworzoną zawartość pliku
10. VFS oprócz plików przechowywałby zestaw wszystkich ścieżek do plików które nie wchodzą w jego skład
11. plik reguł byłby podobny do pliku będącego modem przy czym:
    11.1) nie może zawierać plików spoza VFS (grafik itp)
    11.2) plik wsadowy miałby dodatkowo opcje załadowania modu (plik startowy modu byłby wywoływany z parametrami przekazanymi tu)
    11.3) pliki które mają być przekazane jako parametry do plików startowych modu muszą być w tym tarze tej paczce zawarte, lub zawarte w paczce modu

W ogólnych zarysach zaczyna to przypominać system, który zaproponowałem wcześniej - a nawet, jeśli nie zaproponowałem, to miałem na myśli

Coś ty się uparł na te pliki wsadowe? O ile w pewnych sytuacjach znajdują zastosowanie, to odpalanie jednocześnie kilkudziesięciu takich wydaje się dość kontrowersyjne. Wystarczy w każdym modzie wyznaczyć plik główny (o sugestywnej nazwie header.py, main.py, mod.py czy co tam jeszcze), który będzie zbierał do kupy zawartość folderu z modem. W takiej sytuacji każdy mod żyłby sobie w oddzielnym folderze.
Plik taki zawiera funkcje w rodzaju NewArtifact(nazwa), które dodają nowe obiekty do listy i zwracają ich indeks, oraz wszelkie wywołania parserów plików tekstowych, konfiguracyjnych, .def i innych. Działają one dokłądnie tak samo (i są tymi samymi), jak dotychczas istniejące funkcje VCMI odpowiedzialne za wczytywanie plików gry.

pliki wsadowe są odpowiednikiem makefile - można łatwo zamienić kolejność zmian bez konieczności edycji skryptu jako takiego

co do skryptów edycji, to mogą korzystać z jakich bibliotek chcą, w szczególności tych opracowanych przez team vcmi
można będzie korzystać z technik wysokoobiektowych, a także z tych prostszych… oczywiście zalecanym wariantem może być korzystanie z konkretnych bibliotek, jednak nie ograniczenie do takowych zwiększa kontrolę nad integracją moda

pliki konfiguracyjne byłyby wirtualnymi plikami tekstowymi które skrypty edycji mogą zmieniać w DOWOLNY sposób: np dopisywać treść w uprzednio zamienionym miejscu, zamieniać teksty namierzone wyrażeniem regularnym na własne itp.
dobrą cechą pełnego egzekutywizmu jest dobra obsługa sytuacji wyjątkowych tzn. skrypt może się zorientować że czegoś brakuje i załatać wymagającą tej brakującej części opcję używając prostszych danych (“aha brakuje zasobów zamku heaven to zróbmy wzmocnioną wersję castle na istniejących zasobach”) i wiele rzeczy o których nie przypuszczamy że mogą wystąpić… oczywiście skrypty edycji mogą się w szczególnym przypadku ograniczyć do “dodaj to to i to zgodnie z zaleceniami” ale nie muszą

głównym zadaniem plików wsadowych jest proste przekazywanie parametrów (np możesz przesłać listę zmiennych jako plik z zewnątrz modu przez główny plik wsadowy gry)

za to skrypty WEWNĄTRZ gry byłyby traktowane jako zwykłe pliki konfiguracyjne co umożliwiłoby metaprogramowanie ich z poziomu sekcji instalacyjnej modu

AHA i jeszcze bym zapomniał: klient mógłby przechowywać cache dla konkretnej konfiguracji (po prostu po ukończeniu inicjalizacji wszystkich modów zapisałby stan VFS-u wraz z elememntem na podstawie którego można sprawdzić czy w bieżącej konfiguracji chodzi dokładnie o tą samą konfigurację)

EDIT: pliki konfiguracyjne z VFS-u trafiałyby do silnika dopiero po zakończeniu inicjalizacji, więc dzięki temu jest możliwa obróbka wstępna nieograniczona silnikiem

Widzę, że cały koncentrujesz się na tym, jak przeprowadzić modyfikacje, natomiast chciałbym wiedzieć, CO tak naprawdę chcesz modyfikować. Najpierw cele, potem środki. Inaczej całość staje się niemożliwa do ogarnięcia.

Jako pierwszy cel realizowalny w przewidywalnej przyszłości i decydujący o faktycznym powodzeniu projektu określiłbym możliwość dodawania (ew. modyfikowania) obiektów gry, takich jak stwory i artefakty oraz lokacje na mapie.
Aby tego dokonać, proponuję wyeksportować kilka podstawowych klas opisujących te obiekty do Pythona, wraz kilkoma funkcjami pozwalającymi na ich modyfikację (dodaj zdolność, podmień opis etc). Wówczas wystarczy stworzyć nowy obiekt poprzez dziedziczenie i/lub te funkcje, określić jego właściwości, podpiąć jakąś grafikę i dodać do listy obiektów występujących w grze. Voila, losowe potwory i artefakty zaczną pojawiać się na mapie.
Wparcie dla bardzie zaawansowanych modów, jak zaklęcia i interface (a zatem również miasta) może wymagać większego nakładu pracy oraz dobrze przemyślanego udostępnienia graczom modyfikowalnych elementów gry, oddzielonych od stabilnego i spójnego silnika. Nie łudźmy się, że moderzy będą w stanie swobodnie grzebać w najciemniejszych zakamarkach kodu i np. podmieniać funkcje biblioteczne na własne

Przykładzik w postaci Pythonowego pseudokodu:

id = CreateArtifact(
'CrystalOrb', #nazwa referencyjna
'Crystal Orb', #nazwa w grze
ART_RELIC, #rarity
ART_HERO, #sa niby jeszcze artefakty dowódców / oddziałów
ARTPOS_MISC #slot
)
id.AddBonus (SIGHT_RADIOUS,+12)
id.price = 8000
id.AIValue = 12000
id.description = ParseTextFile ('.\CrystalOrb.txt')
SetArtifactDef ('CrystalOrb','.\lodfile\orb.def')
ArtHandler.SetArtAvaliable ('CrystalOrb')

Amen.

moim zamiarem byłoby danie nieograniczonych możliwości skryptowych,
zaś zapis utrzymać w prostocie

więc medium byłyby tekstowe pliki konfiguracyjne (takie jak dotychczasowe pliki konfiguracyjne heroesa, jak dodatkowe pliki tekstowe vcmi, jak bazy danych mysql, jak arkusze xml) - medium byłoby prosto określone

za to dowolność w operacjach (podmiany, inserty, haszowanie, dublowanie i co dusza zapragnie)

cały pomysł w tym żeby skrypty wyedytowały pliki konfiguracyjne przed startem growej części silnika, a nie opierały się wyłacznie na eksportach silnika

biblioteki z eksportami w moim pomyśle, zawierałyby tylko uproszczone obsługi pliku tekstowego (znajdź-zamień, sprawdź-dodaj itp) opakowane w ładny interfejs obiektowy, za to skrypt mógłby korzystać z (prawie) każdej biblioteki czy to matematycznej czy plikowej, czy to generatora losowego czy co tam modder zapragnie - standardem by było skrypt dostaje plik z VFS od preloadera z silnika, przetwarza go, zwraca preloaderowi a ten uaktualnia go w VFS

oczywiście nie jestem przeciwko edytowaniu zasobów gry w czasie wykonania (skrypty edycji tj. kompilują środowisko) ale to powinno być jako oddzielna opcja już wewnątrz właściwej części silnika, zwłaszcza że takie runtime-script-y miały by mniejsze możliwości
zapewne runtimy miały by ciekawe właściwości typu dynamiczna allokacja itp ale powinny być (jeśli będą) oddzielnie od surowej części loadera

gdyby zostawić tylko interfejs obiektowy mielibyśmy sytuacje odwrotną do oczekiwanej w moim pomyśle - czyli binarno-klasowy nośnik i ograniczone funkcjonalnie skrypty

cały sęk w tym że gdy się sztywno ustawi granice co może być modyfikowane prędzej czy później nastąpi potrzeba ich przekroczenia - więc lepiej wyposażyć moddera w bardziej skomplikowane narzędzie, które bez problemu załatwi wszystkie podstawowe potrzeby, a zostawi (prawie) nieograniczone pole do zaawansowanych modderów/skrypterów

Kiedy to właśnie pliki konfiguracyjne są nierozszerzalne - bo konfigurują tylko to, co autor zaplanował. Znam to z H5 - łatwa edycja różnych ustawień, ale własnych rzeczy (jak choćby skryptów wywoływanych przy każdym uruchomieniu) dopisywać w ten sposób nie można. Inna sprawa, że do obsługi zdarzeń (kampania, elementy RPG, popularne modyfikacje parametrów jednostek) i tak trzeba będzie wykorzystać Pythona.

Gdzieniegdzie można dodać wskazania na funkcje (szablony funkcji lub bind), które będą wywoływane przy zaistnieniu określonego zdarzenia - na przykład każdy artefakt może wywołać swój unikalny skrypt po rozpoczęciu walki. W ten sposób można dodawać funkcjonalności inne, niż standardowe.

hmm chyba rozumiem
ale nie można by w tabeli dodać pola “binded script”?
poza tym ciągle rozwijający się “standard” to nie jest takie fajne zwłaszcza gdy nie ma zgodności wstecz

ale i tak można zrobić wsparcie dla OBU mechanik

PS: twój pomysł może jest i dobry dla dodawania nowych zasobów, ale będzie się średnio nadawał do edytowania istniejących

Niepojęty pozostaje dla mnie opór, z jakim dyskutujecie nieistotne w ostatecznym rozrachunku detale implementacyjne. Ich omawianie nie jest naturalnie niczym złym, ale w oderwaniu od nadrzędnych zagadnień jest po prostu… daremne. A kwestie prawdziwie ważkie, kluczowe wydają mi się kompletnie pominięte.

W angielskim wątku o skryptach wskazałem przykład takiej, nie spotkało się to z konkretnym odzewem, więc pozwoliłem dyskusji toczyć swoim torem - co chyba mogło być opacznie poczytane za moją aprobatę. Tutaj widzę to samo, ale język bliższy (nienawidzę mojej koślawej angielszczyzny) więc raz jeszcze się wtrącę.

Pierwszy pomysł Majaczka jako całość jest dla mnie trudny do ogarnięcia. Przeczytałem jeden post, potem jeszcze raz, potem myślałem, że kolejne rozjaśnią całość, ale nic z tego. “Im bardziej Puchatek zaglądał do środka, tym bardziej Prosiaczka tam nie było.” Mimo to zrozumiałem dostatecznie dużo, by mnie ciarki przeszły. Kolejne wersje różnią się detalami implementacyjnymi, ale ta straszliwa myśl, stojąca za nimi wszystkimi, trwa niezmieniona.

Po moim trupie! [albo twoim forku ]
Ten pomysł jest tak aberracyjny, że nawet nie potrafię wymyślić porównania, które by to dobrze ukazało.

Dlaczego?
W skrócie - zawodne, obłędnie pracochłonne, mało możliwości, nierozwijalne.
W szczególe:

1. Pliki konfiguracyjne reprezentujące identyczną logikę mogą mieć w H3 różną postać tekstową. (Wersje językowe dla przykładu)

2. Długa i kręta droga by cokolwiek zrobić. Aby skrypter mógł zaimplementowac daną funkcjonalność, to:
   a) Implementuje ją w języku skryptowym. Aby to było możliwe, język skrytpowy musi udostępniać jakiś interfejs umożliwiający interakcję z mechaniką gry.
   b) Biblioteka skryptu tłumaczy to co modder napisał na odpowiadającą temu postać tekstową i odpowiednio modyfikuje pliki konfiguracyjne.
   c) VCMI parsuje plik konfiguracyjny, odczytując z niego informacje o logice gry.

Każdy element logiki musi być tak naprawdę w czterech miejscach naniesiony: raz - wykonanie logiki przez sam silnik; dwa - dodanie logiki to formatu pliku konfiguracyjnego i parsowanie jej przez VCMI; trzy - odwrotne parsowanie (logika -> tekst) po stronie biblioteki skryptu; cztery - udostępnienie elementu i powiązanych struktur w interfejsie skryptowym dla moddera (i w końcu pięć - użycie tego wszystkiego przez moddera). Szaleńcze, jeśli za alternatywę weźmiemy udostępnienie pewnego interfejsu (zbioru funkcji i powiązanych z nimi struktur danych) bezpośrednio skryptom. (Raz - robimy funkcję realizującą logikę w VCMI; dwa - biblioteka skryptu udostępnia to modderowi).

3. Ograniczona funkcjonalność. Można tylko modyfikować pliki konfiguracyjne. To może i pozwoli na dodawanie nowej treści wizualnej, ale niewiele więcej. Nie można na tym zrealizować interaktywnych skryptów, nie można pisać złożonej logiki. Wszystko jest wszak wykonywane przed rozpoczęciem rozgrywki, więc siłą rzeczy te skrypty będą statyczne.
   No chyba, że przez bogactwo możliwości rozumiemy, że będzie można napisać skrypt podający VCMI wszystkie pliki wspak albo pokemonizujący komunikaty w grze.

4. Niemożliwe do rozwoju. Dodanie jakiegoś nowego elementu do pliku konfiguracyjnego spowodowałoby, że wszystkie dotychczasowe skrypty wykonujące operacje tekstowe na pliku (dokonując tym samym założeń odnośnie jego kształtu) pogubiłyby się. Dowolna zmiana czegokolwiek w formacie wymagałyby dużych zmian w parserze VCMI i parserach wszystkich bibliotek skryptowych. Wskaż mi dewelopera, który by to robił. Ja na pewno nie.

To tylko najbardziej cisnące się na usta (palce?) uwagi.

Nie czuj się proszę dotknięty tą krytyką - naprawdę podziwiam twój zapał i cieszę się, że przedstawiasz swoje pomysły - po prostu ta konkretna idea jest w moich oczach nietrafiona.

A kto zrobi? Na razie wciąż brak nam rąk do pracy, by odtworzyć funkcjonalności oryginalnego Heroesa…

To o czym pisze Warmonger jest generalnie słuszne. Niestety jest zbyt generalne, by coś wynikało. Udostępnienie językom skryptowym (Python, nie Python - to nieistotne) odpowiedniego zbioru funkcji umożliwiających modyfikację logiki i interakcje z nią jest oczywistym i najwidoczniej jedynym słusznym sposobem realizacji skryptów. Nic lepszego chyba nie wymyślono. [No, jeszcze jest uproszczony wariant pod tytułem handler skryptów bezpośrednio dziubie w silniku, ale tego nie chcemy.]

Trafna jest uwaga, że najpierw należny określić cele do osiągnięcia, a dopiero następnie dobierać odpowiednie “środki implementacyjne”. Natomiast zanim zaczniemy się bawić w jakiekolwiek skrypty, musimy mieć ideę całości ich systemu. Najpierw cele i wymogi względem ogólnej całości, potem dopiero można wypełniać ją jakąś szczegółową treścią. Dodawanie nowych potworów czy artefaktów jest tu właśnie szczegółem - jakimś małym wycinkiem całości, niespecjalnie fascynującym z jakiejkolwiek perspektywy. (Dzięki mojemu systemowi bonusów nie powinno tu być problemów )

Podstawowy cel, jaki ma nasz projekt, to odtworzenie funkcjonalności Heroesa z WoG-iem. WoG ma swój język skryptów - ERM. Nasz system więc zasadniczo powinien oferować przynajmniej te możliwości, jakie ma ERM. To można sobie przyjąć za cel pierwszy - bo jest zgodne z założeniami projektu, oczekiwaniami fanów i dostatecznie komplikuje zagadnienia. Żeby było weselej, niech skrypty działają w trybie multiplayer należycie; muszą być przy tym bezpieczne (nie stwarzające możliwości oszustwa) lub reaktywne (nie robiące “lagów” w mechanice lub GUI). Piszę “lub” - bo jednego z drugim połączyć się nie da. Pamiętajcie, że gra VCMI to jeden serwer i do ośmiu klientów. Pamiętajcie, że ERM umożliwia reagowanie zarówno na koknretne zdarzenia w logice gry (bohater odwiedza pole, nowy dzień) jak i zdarzenia w GUI (gracz kliknął myszą).

A, jeszcze fajnie by było, gdyby funkcjonalności dodane przez skrypty mogły być wspierane przez AI.

W ogóle zagadnienia modów i skryptów to trochę co innego. Dużo łatwiej zmodyfikować ( / sparametryzować) istniejącą logikę w silniku, niż dodać ją gdzieś “poza”.

W skrócie:

• bezpieczeństwo skryptów (co zrobić, żeby mogły być używane w rozgrywkach MP bez obawy oszustw)
• niezawodność i reaktywnośc skryptów (żeby mogły by ć używane w MP i nie prowadziły do lagów lub błędów desynchronizacji)
• skrypty a AI

W ogóle, to zanim poważnie będziemy dyskutować o dodaniu skryptów, VCMI musi mieć działający tryb multiplayer w dwóch wariantach (reaktywny, bezpieczny). To ciągle długa perspektywa. Traktujcie mój post jako wrzucenie problemu do niezobowiązującej dyskusji - która jednak jak najbardziej może wpłynąć na kształtowanie się mojej końcowej idei systemu skryptów / modów.
Szeroko rozumiane modyfikacje gry muszą być ostatnią dużą funkcjonalnością, jaką zaimplementujemy. (No, może poza AI, które do niczego nie jest konieczne, a może być od nich zależne.)

hmm troche zostaem niezrozumiany
chodzilo mi o to zeby przed zaserwowaniem silnikowi konfiguracji byla dostarczona jako tekst skryptowi i jako tekst wracala do puli i to samo przez kilka iteracji

argument o nierozszerzalnosci wydaje sie sensowny ale tylko wydaje
jest wiele formatow tekstowych latwo rozszerzalnych - chocby te oparte na xml

w moim pomysle bylo by pliki konfiguracyjne mial jakis standard opracowany przez team vcmi (najlepiej rozszerzalny) i by mozna bylo z trescia zrobic cokolwiek na co jezyk skryptowy pozwala (nawet po obsluge zewnetrznych baz danych, zaleznosc od czasu ostatniego czegos czy uzycie biblioteki pseudolosujacej zewnetrznej)

w przypadku bazy danych, tabeli i niektorych formatow opartych na xml polem moze byc rowniez nazwa skryptu ktory zadziala w juz w pelni uruchomionej wersji silnika

oczywiscie team vcmi moze opracowac “biblioteczke standardowa” do edycji takich plikow konfiguracyjnych

A co mnie sklonilo do dania modderom takiej kontroli nad zawartoscia?
doswiadczenie z produktem o pieknym wsparciu modow, ale niedopracowanym
mowie o tes3-morrowind i tes4-oblivion
producent dostarczyl edytor plikow modow w ktorym mozna zmienic prawie wszystko ALE
ale jest jedno ALE:
gromadzenie informacji przez silnik bylo mocno ograniczone
w praktyce zeby 2 mody korzystajace z tego samego zestawu opcji podstawowych nie mogly zgodnie dzialac (np 1 opcje dialogowa w tej samej bazie dialogow) bez latki zgodnosci
zeby sensownie dalo sie grac w wiecej niz jeden mod powstal program BASH utworzony przez moddera- parsowal on binarne pliki modu szukal pewnych rzeczy i od zera budowal latke na podstawie tego
problem w tym ze nie dosc ze bylo to binarne to jeszcze standard byl niejasny, a edytor producenta pozostawial w plikach modow kawalki blednych danych ktore gra pomijala a byly trudne do parsowania zewnatrz
slowem koszmar teoretycznie cukierkowy ale tylko teoretycznie
dlatego zamierzam zeby przetwarzanie wstepne modow bylo w ogole nie ograniczone przez silnik… oczywiscie pewne rzeczy lepiej zrobic po zaladowaniu calego silnika ale pewnych rzeczy tak sie nie da zaleznie od silnika
a formaty tekstowe sa bardzo proste do parsacji zwlaszcza gdy sa porzadnie zbudowane

wiec zastosowanie tej czesci mechanizmu obslugi modow mialo by dzialanie analogiczne do tego jakie maja dyrektywy preprocesora w kompilacji albo analogiczne do kompilacji jakiegos silnika obiektowego jeszcze przed uruchomieniem przetwarzania w-czasie-wykonania

a sprawdzanie zgodnosci jest wazne ale wystarczy zalozyc ze klient i serwermusza miec te same mody a jak nie to serwer podaje to co klient nie ma
i nie wykluczam tu takich spraw jak kod w modzie zalezny od tego na ktorym kompie byl uruchomiony (np od ip, od nazwy uzytkownika itp) - jesli moder zawarl takie tresci jego sprawa jak chce moze zrobic mod ktory bedzie dzialal na jego korzysc

Nie prościej od razu napisać silnik pozbawiony tego błędu?

O tym pisałem.

O tym też, choć sam się w ERM babrać nie zamierzam. Za to już dwie osoby zaoferowały swoją pomoc w tym zakresie

Ogólnie widzę, że treści merytoryczne zaginęły w tej i innych dyskusjach. Pokrótce więc opiszę istotne etapy wdrażania systemu skryptów:

-Dodanie interpretera poleceń do silnika. Dobrze byłoby podpiąć go pod konsolę w celach testowych.
-Komunikacja musi się odbywać w dwie strony, mianowicie VCMI potrafi operować na skryptach i jednocześnie skrypty mogą wpływać na stan gry.
-Serializacja struktur skryptowych
-Obsługa skryptów w sieci - wysyłanie paczek i synchronizacja połączenia
-Zabezpieczenie przed niepowołanym wywołaniem skryptów.
-Możliwość istotnego wpływanie poprzez skrypty na zawartość gry - np. modyfikacja własności i dodawanie obiektów.
-Synchronizacja skryptów na zasadzie klient-serwer.
-Wsparcie dla modów - skryptów wykonywanych automatycznie przy starcie gry i w trakcie jej trwania, po zajściu pewnych określonych zdarzeń. Dobrze zdefiniowana postać modu.
-Możliwość opisania własności skryptów dla AI - dodawania i modyfikacja własności sieci neuronowej (która ponoć gdzieś tam powstaje) na zasadzie asocjacyjnej.
-Stworzenie rozszerzalnego zbioru predefiniowanych funkcji dostępnych dla ogółu społeczności.
-Przetłumaczenie (mapowanie?) funkcji ERM na tenże zbiór. Wydzielenie osobnej struktury danych na zmienne, które oryginalnie są przechowywane w dość dziwnej postaci.
-Edytor i format mapy umożliwiający przechowywanie skryptów.

No, masz swoje konkrety.
Do każdego punkty można oczywiście dopisać tony detali i rozważyć każdy możliwy problem, ale lepiej byłoby to od razu zacząć przekładać na kod. Zaczynam w czwartek

jesli chodzi o ograniczenia wynikajace z silnika to zawsze beda
dlatego podalem radykalna wypowiedz

te skrypty o ktorych mowisz to mechanizm runtime gry - jako taki potrzebny - jednak sa zupelnie czym innym od skryptow INSTALACJI

SKRYPTY INSTALACJI/INICJALIZACJI to te ktore opracowuja dane dla silnika zanim ten przejdzie pelny rozruch - wykonane zostaja tylko przy rozruchu i na tym sie koncza - SLUZA DO INICJALIZACJI SILNIKA a wiec sa wykonywane jeszcze zanim rozgrywka sie rozpocznie
SKRYPTY RUNTIME o ktorych mowisz to te ktore sa uruchamiane po kazdym spelnieniu warunkow (zdarzenie/poczatek rozgrywki/sprawdzanie warunkow w petli) - SLUZA DO ZMIANY STANU SILNIKA W CZASIE

oba rodzajeskryptow moga wystepowac niezaleznie od drugich i ich porownywanie nie ma sensu bo wychodzipoza dziedzine (to tak samo jakby sie zastanawiac czy 5>5+3i czy moze 5<5+3i bo rowne nie sa, i - podstawa zespolona)

Hmm… ciekawe, ile jeszcze pomysłów na skrypty pojawi się do czasu ich zaimplementowania. Mam nadzieję, że przynajmniej kilka z nich coś wniesie i ulepszy VCMI ponad to, co ja i Tow jesteśmy w stanie wymyśleć. Póki co, z tego co pamiętam, tak się niestety nie stało. Ale próbować zawsze warto.

Może nie powinienem wciać się w twoją dyskusję z Towem, ale korci mnie, żeby go poprzeć. Z własnego doświadczenia wiem, że metoda “zacznijmy to pisać, jakoś się ułoży” jest najprostszą drogą do zagmatwanego, nieczytelnego, niedebugowalnego, nierozwijalnego i ogólnie nieutrzymywalnego kodu, który potem trzeba kilka razy przepisywać. Pierwszy system GUI był tak robiony i aby doprowadzić go do obecnego stanu Tow potrzebował przepisać go dwa razy, a ja ciągle uważam, że w wielu miejscach jest koszmarny. Na drugim krańcu mamy CGameInterface i CCallback, które bezproblemowo rozwijają się od momentu powstania. Z nowszych rzeczy mógłbym wymienić system bonusów, obmyślany i omawiany całymi godzinami.
W kwestii poprawiania, kod obsługi skryptów jest o tle krytyczny, że od momentu ogloszenia, że działa, ludzie zaczną pisać skrypty, i oczekiwać, że jak w jednej wersji zadziała, to zadziała też w kolejnej bez poważnych przeróbek. Jeśli porywasz się na taką odpowiedzialność, uważasz się za dużo lepszego programistę ode mnie i Towa. My uważamy, że nie jest to obecnie wykonalne w sensowny sposób.

A, że tak zapytam, co takiego dają skrypty instalacji, czego nie mogą dać skrypty runtime? Przecież skrypty uruchamiane przy starcie gry mogłyby zrobić dokładnie to samo, i to lepiej.

Ja bynajmniej nie zamierzam niczego ogłaszać. Rozmiar tego zadania jest ogromny i opisanie wszystkich możliwych detali ad hoc nie jest wykonalne. Tym niemniej od czegoś trzeba zacząć, a punkt pierwszy z listy jest praktycznie zawieszony w próżni i nie wpływa ani nie zależy od tej czy innej architektury silnika - prawdę mówiąc, na razie sprawdzam, jakie są w ogóle możliwości w tym zakresie. Gdy pojawią się konkretne propozycje i konkretne problemy, będzie można dyskutować o konkretnych rozwiązaniach.

To akurat zrozumiałem - ten pomysł jest chybiony. Wprowadza kompletnie zbędną konieczność tłumaczenia logiki przez skrypty na format plików konfiguracyjnych, które potem mają być z powrotem parsowane przez VCMI. Pod każdym względem bezpośrednie udostępnienie skryptom mechaniki przez prosty interfejs jest lepsze.

Tekstowe formaty są po prostu zbędne. Zarówno gra operuje na pewnej logice, jak i modder chce umieścić / zmodyfikować pewną logikę. Tak więc im bliższa reprezentacja tej logiki w skryptach będzie reprezentacji w silniku, tym lepiej. (Prostsza konwersja.)
I dużo, dużo większa elastyczność.

Aj, wybacz - musiało mi to umknąć. Mógłbyś podlinkować?
Całościowego, satysfakcjonującego rozwiązania do tej pory nie wymyśliłem, choć mam pewne pomysły na ograniczenie problemu.

A AI, to już chyba dziesięć osób obiecało mi napisać…
Ale sam ERM jest nieistotny - jak się zrobi porządny interfejs dla języków skryptowych, to będzie można ich podpiąć wiele i w dowolnej kolejności.

Tam nie ma konkretów. To tak jak kandydat na prezydenta obiecujący naprawę służby zdrowia, obniżkę podatków, przyspieszenie rozwoju gospodarczego i załatanie dziury budżetowej. Nie sposób oprotestować jakiegokolwiek z postulatów - haseł, a mimo nikt nie nazwie tego dobrym, konkretnym programem.

Tyle że tutaj, to nawet nie rozumiem większości pojęć.

Przez silnik rozumiesz tu klienta czy serwera?

Co to znaczy “VCMI potrafi operować na skryptach”? Jakie operacje ma na nich wykonywać?

Struktury skryptowe to struktury w samych skryptach czy też struktury w VCMI odpowiadające za obsługę skryptów czy też jedno złączone z drugim?

Nie rozumiem.
Kto wysyła paczki do kogo? I z jakich powodów? Co to jest “synchronizacja połączenia”?

Czy to ma być ekwiwalent punktu “nie stwarzające [nowych] możliwości oszustwa”?
Gdzie jest to zabezpieczenie? Kto by miał wywoływać te skrypty? Kto weryfikuje, czy skrypt został wywołany w sposób niepowołany czy nie?

Jasne.

Jasne.

W jaki sposób będą te własności opisane?
" dodawania i modyfikacja własności sieci neuronowej (która ponoć gdzieś tam powstaje) na zasadzie asocjacyjnej." - nie rozumiem.
Skrypt nie powinien czynić założeń odnośnie postaci AI. Opis powinien być uniwersalny.

Przez predefiniowane funkcje rozumiesz funkcje wpisane w kod VCMI i udostępnione skryptom? Jeśli tak - naturalnie słuszny postulat.
Czy to jest równoważne jakiejś postaci rozbudowanego interfejsu - callbacka dla skryptów?

Generalnie jasne.

Pomiędzy szczegółem implementacyjnym a pustym sloganem jest całkiem szerokie pole. Nie chodzi o opisanie wszystkich detali systemu. Chodzi przede wszystkim o rozwiązanie kilku bardzo realnych problemów koncepcyjnych. Jeżeli nie potrafisz ich rozstrzygnąć w formie pisemnej, to tym bardziej nie uda Ci się w implementacji.

Szkoda czasu na pisanie takich wprawek. Zanim dopuszczę skrypty do VCMI, projekt musi być w miarę feature-complete, a ich idea przedyskutowana i czysta. Inaczej nie uda się tego należycie zrobić. A skrypty to ten jeden element projektu, którego nam nie wolno zepsuć.

Implementowanie skryptów w chwili, gdy nie mamy wielu istotnych funkcjonalności oryginalnego Heroesa oraz założonego minimum jest bezcelowe. Najpierw trzeba założyć skarpetki, potem buty.

Jeśli chcesz pomóc, to naprawdę dużo lepiej się przysłużysz, jeśli pomożesz w implementacji np. specjalności bohaterów.

Co do ostatniego punktu - ok, czas najwyższy się z tym rozprawić.

Co do innych niejasności - na większość tych pytań mam dobre odpowiedzi, ale widzę, że w chwili obecnej nie dojdziemy do sensownych wniosków. Zostawiam tą dyskusję na inną okazję.

Czyli zamiast pomagać w rozwoju projektu chcesz się pobawić w podpinanie interpretera do silnika i masz nadzieję, że kiedyś na coś się to przyda… no cóż, nie widzę żadnego powodu, dla którego takie eksperymenty miałyby się znaleźć w trunku, ale jeśli chciałbyś forkować projekt, to nikt ci tego zabronić nie może…

Chociaz niewiele z tego co tu jest napisane kumam to wyczuwam pewnego rodzaju napiecie w tej dyskusji. Ja osobiscie tez uwazam, ze zajmowanie sie na tym etapie modami jest lekkim przegieciem, gdyz do poprawnego dzialania VCMI jako zamiennika H3 jest jeszcze bardzo daleko. IMO, skoro projekt jest “otwarty” to po skonczeniu “podstawki” i tak zacznie zyc wlasnym zyciem.
Ale z drugiej strony jezeli rozkminianie tego czy innego tematu powoduje zwiekszenie motywacji do pracy nad ukonczeniem projektu to nie mam nic przeciwko.
PS>
Tak sie tylko wtracilem, zeby troche rozladowac atmosfere