Свободно - нигде нельзя. Полные исходники GothicSourcer'а есть только у Vam'а, какие-то куски есть и у меня, хотя даже те куски, что есть у меня, я опять же не могу и не хочу выкладывать в открытый доступ. Тебя интересует что-то конкретное?Где можно скачать исходники GothicSourcer?
Да, меня интересует возможность дописания этой проги с возможностью определения функций, чтобы было меньше возни с списком файлов.Тебя интересует что-то конкретное?
И как это могло бы выглядеть?Да, меня интересует возможность дописания этой проги с возможностью определения функций
И как это могло бы выглядеть? Слово "макросы" понимают в разных программах по-разному.Ну и макросы, если получится. куда уж без них)
Если сможешь реализовать, то это будет норм.макросы, (#define M1 какой-то код...) как в языках си.
На мой взгляд, не стоит плодить новые расширения файлов без особой нужды. То есть лучше бы сделать так, чтобы предварительную декларацию писать в самих *.d файлах, например, так:если нужно создать новые функции, то нужно их прописать в .def файле.
(def func function123 ( var int x, var C_ITEM itm )
func void function123 ( var int x, var C_ITEM itm );
func void function123 ( var int x, var C_ITEM itm )
{
...
};
то, думаю, стоит попробовать. Обсужу это дело с Vam'ом.с++ есть знания и опыт
Этого, к сожалению мало, для полноценной модернизации Сурсера под задуманные возможности нужно хорошо знать как минимум две части проги:1) с++ есть знания и опыт
Это большая работа, хоть движок компилятора и не связан с ГУИ, в нем используется STL, которую передалать под Юникс довольно не просто + виндовые АПИ...У меня просьба к Vam'у
Конечно возможна, раньше (GS 2.4 последний) была ком. строка, а начиная с 3 (когда появилась полнофункциональная ГУИ) я её урыл за ненадобностью... =( (никто и не возражал). А так - возродить её не сложно...А для винды возможна версия компиллятора для командной строки?
Так а в чем трабла запустить имеющийся 3.14 под вайном? У меня он под вайном работал год, и даже шустрее чем на винде, + еще слышал о существовании какогото набора вайновских либ, для адаптации кода под линухи...Жалко. Была у меня такая мысль: Среда для коллективной разработки мода: через svn поднимается очередное изменение. Хук в svn'е ловит это событие и стартует сборку мода. В результате, на каждое изменение автоматически получали бы собранную новую версию. Особенно удобно было бы для коллективной отладки.
PS: А для винды возможна версия компиллятора для командной строки? Можно было бы попробовать через wine запускать. Или через WmWare.
func void function123 ( var int x, var C_ITEM itm );
Так а в чем трабла запустить имеющийся 3.14 под вайном? У меня он под вайном работал год, и даже шустрее чем на винде, + еще слышал о существовании какогото набора вайновских либ, для адаптации кода под линухи...
Так вот, если реализовать декларацию функций и переменных, то надобность в этом файле отпадет, или он превратится в файл definitions.d, для которого порядок декларации не важен, что является ключевым моментом (удобство создания новых функций), отсутствие гемора с порядком файлов.
Не отпадет. Без файла gothic.src как компилятор вообще определит, какие *.d-файлы ему компилировать? Вдобавок любые изменения GothicSourcer'а должны сохранять его совместимость со старыми скриптами. Так что файл gothic.src нужно сохранить в любом случае, я думаю так. А если мы сохраняем файл gothic.src, то порядок следования файлов в нем будет все равно важен - как минимум файл с предварительными декларациями функций надо будет подключать раньше файла, который эти функции использует.надобность в этом файле отпадет
Это на словах только просто, во-первых компилятор однопроходный, во-вторых структуру создаваемого им dat ни какиим образом менять нельзя. По сути нужно писать препроцессор и встраивать его в компилятор, в принципе при соответствующих знаниям всё реализуемо...Насчет сложности реализации...
Наверняка в уже имеющемся компиляторе есть функция типа FunctionContainer->AddFunction (function def...), и она вызываются при первом проходе, "открывая" новые функции на своем пути и занося их в список.
Так вот, необходимо внести в функции распознавания изменения, чтобы они вызывали AddFunction при встрече не только декларации + тела, но и также декларации функции без тела, в конце которых стоит точка с запятой