Witam. Wiem że temat pluginów był już poruszany.
Proponował był dodanie pluginów załączanych w dll’kach. Dzięki temu będzie można pisać pluginy w wielu jeżykach.No i dzięki temu ktoś by mógł napisać plugin do obsługi jeżyków typu lua ,python itp
Vcmi ma oficjalna wersje na linuxa, da sie zaladowac do takiej aplikacji dll? 
To nie tak różowo, bo taki DLL musi się jakimś interfejsem z VCMI komunikować. Jeśli interfejs jest w C++, to wtedy i DLL musi być w C++. Do tego trzeba go budować tym samym kompilatorem i z tymi samymi opcjami, co silnik (C++ nie ma ustandaryzowanego ABI). Robienie alternatywnego interfejsu w czystym C — mnóstwo roboty, a potem by trzeba i tak jeszcze raz interfejsować do „języka docelowego”.
Zalążek obsługi języków skryptowych, jaki jest obecnie zrealizowany w VCMI, faktycznie wykorzystuje ten mechanizm (pluginy w dll). Tyle, że takie pluginy muszą być częścią projektu (nie zaś niezależnym przedsięwzięciem), inaczej się będzie rozwalać przy każdym releasie. Tak więc jest to raczej wewnętrzny sposób organizacji kodu niż forma, w jakiej bym widział przyszłe, niezależne od jądra projektu, dodatki.
Tak, tyle że na Linuksach się to nazywa biblioteką dzieloną i ma rozszerzenie .so. Niby inny mechanizm, ale w praktyce można używać identycznie. Przynajmniej w zakresie, jaki jest nam potrzebny.
ja tam myślę że niektóre elementy serweraq można “upublicznić” i stworzsyć mechanizm pluginów podobny do tego w jakim jest zrealizowane AI w VCMI. to znaczy że przy niektórych zdarzeniach (niekoniecznie wszystkich) można przypiąć własny kod z tą samą klasą bazową. oczywiście taki mechanizm byłby średnio kompatybilny póki VCMI zamierza wprowadzić duże zmiany, ale opracowanie takiego mechanizmu pomogło by projektowi i byłoby bardzo użyteczne w “finalnej” wersji. Gdy już powstanie API dla pluginów, dodanie nowych języków skryptowych/interpretowanych nie będzie problemem - nic nie przeszkadza by plugin był wrapperem. natomiast dodanie innych języków kompilowanych będzie trudniejsze z powodu wnętrzności C++, choć nie wykluczone jest napisanie wrappera API w C++ na API w C, który umożliwi crosscompiling (tj. korzystanie z różnych kompilowanych języków programowania w jednym projekcie)