Thief Series Complete Patch by Dark Fate Team

[DJ Riff]

Апдейт Тафферпатча.

— Набор исправленных миссий от Antimatter16 обновлён до 1.1e. Из-за этого дистрибутив ещё пополнел, лайтмэпы 32-битные же ж.
— Сборка Дромеда обновлена до DromEd_Basic_1.10 от того же автора.
— Исправлен мелкий баг, из-за которого при некоторых антинаучных манипуляциях дублировалась ссылка на папку .\patchedmis в cam_mod.ini

Чтобы обновить указанные компоненты, просто натравите Тафферпатч на установленного Вора со старой версией и давите "Далее" до упора. Дубликаты ".\patchedmis", если есть, не влияют на работоспособность, могут быть удалены вручную в текстовом редакторе или переустановкой компонента "Полный комплект исправленных ресурсов 1.1e". Для переустановки снимаем галку в списке компонентов, жмём Далее, потом Назад, ставим галку обратно и жмём Далее до конца.

[DJ Riff]

Хотфикс-апдейт, лол.

На Google Docs
http://download.darkfate.org/patches/thief2/fanmade/TafferPatcher/TafferPatcher_TMA_212_beta.exe
ftp://95.31.27.16/patches/thief2/fanmade/TafferPatcher/TafferPatcher_TMA_212_beta.exe

— Исправлен баг, в котором патч путал похожие строчки в cam_ext.cfg (конфигурационный файл в составе NewDark). Баг присутствовал в версиях 2.0.10 и 2.0.11.

Чтобы исправить багнутый файл, достаточно запустить новую версию, указать папку с Вором и нажимать Далее до конца.

[DJ Riff]

Если у кого есть время, погоняйте Тафферпатч:

http://download.darkfate.org/projects/tafferpatcher/TafferPatcher_TMA_214_beta.exe

Просто апдейт до Ньюдарк 1.22 самого Вора и Дромеда, если установлен тоже через Тафферпатч. Если до этого был установлен Тафферпатч с более ранним Ньюдарком, достаточно прокликать Далее.

Промежуточный апдейт, пока вожусь с утилитой мод-менеджера и наверное надо будет снести Enhancement Pack как устаревший. Пока просто обновил программные файлы.

У любителей выкидывать конфиги из одних файлов и запихивать в другие скорее всего случится полный кавардак, т.к. я пока не решил, как Тафферпатч должен с этим справляться.

[Призрак Boris'а3000]

У любителей выкидывать конфиги из одних файлов и запихивать в другие скорее всего случится полный кавардак

У любителей запихивать конфиги в другие файлы кавардака не случится, потому что они используют Тафферпатч только как инсталлятор, финализатор 1.07->1.18 и сгрёбщик архивов (лишь бы не исчезла возможность этим ограничиваться). Причём строго всё вместе за один подход, а не по отдельности.
К тому же такие любители обычно знают, как исправить возможный кавардак, поэтому для них достаточно просто вывести предупреждение о том, что если они щас накатят такой-то компонент, то таким-то и таким-то конФИГУрационным файлам настанет трижды писец, и надо бы позаботиться о бэкапе. Хотя у подобных любителей даже и бэкап имеется по умолчанию, причём сразу в виде всей игры целиком, да в нескольких вариантах, включая свежеустановленный посредством того же Тафферпатча. Соответственно, даже такое, облегчённое, использование Тафферпатча случается только по праздникам. Так что напортачить данным товарищам крайне проблематично...
Те же, кто юзает Таффера полностью, не то, что не переносят конфиги в другие файлы, а и вообще, боюсь, в них даже не заглядывают.

Думаю, Тафферпатч при необходимости внести изменения в конфиги должен просто жоско перезаписывать все конфигурационные файлы, приводя игру к оригинальному виду. При этом бэкапя перезаписываемые файлы и выдавая об этом сообщение.
Ведь даже если все конфиги сидят по своим стандартным файлам, то всё равно непонятно, как быть, если человек, скажем, в cam_ext.cfg поменял один-единственный параметр и теперь хочет обновить Нью-дарк с помощью Тафферпатчера...

И ещё. Хоть Тафферпатч и  умеет что-то там прописать в реестр, но в списке установленных программ игра всё равно не появляется. Sad but true.

[DJ Riff]

Ведь даже если все конфиги сидят по своим стандартным файлам, то всё равно непонятно, как быть, если человек, скажем, в cam_ext.cfg поменял один-единственный параметр и теперь хочет обновить Нью-дарк с помощью Тафферпатчера...

Это уже давно сделано: кладётся новый конфиг и из старого переносятся изменённые значения и добавленные. А вот если в качестве "добавленных" оказывается целиком сборка конфигов из совсем другого файла, тут-то котовасия и начинается. Перезаписывать конфиги на дефолтные не вариант, я не собираюсь издеваться над юзером, заставляя его перенастраиватьигру на каждом обновлении. Предупреждения тоже не вариант, т.к. юзеру будет казаться, что он вот щас себе что-то поломает, хотя на самом деле вообще не должен об этом беспокоиться, если руками глобально ничего не переделывал.

И ещё. Хоть Тафферпатч и  умеет что-то там прописать в реестр, но в списке установленных программ игра всё равно не появляется. Sad but true.

А смысл ей там быть? Деинсталлятора всё равно нет, удаляется простым удалением папки. Прописывается в App Paths, чтобы по win+R "thief2" запускать. Ну и чтобы другие проги могли по этому ключу игру найти.

[Призрак Boris'а3000]

кладётся новый конфиг и из старого переносятся изменённые значения и добавленные

Так он умеет прописывать строчки в текстовые файлы? Тогда не вижу проблем, за исключением увеличения геморроя. Надо просто забыть, что у нас есть какие-то определённые файлы, и сосредоточиться непосредственно на параметрах.
Полный список параметров, существовавших за все времена (оригинальные, ддфиксовские, нью-дарковские) известен. Некоторые из них потеряли актуальность. Сначала Тафферпатч производит поиск неактуальных параметров по *.cfg и *.ini, имеющимся в установленной игре, и грохает эти параметры, если находит. После этого он берёт новый cam_ext.cfg (а после него то же самое ещё и с new_config_vars.txt и с subtitles.txt), берёт первый параметр из него и ищет его по *.cfg и *.ini, имеющимся в установленной игре. Далее варианты:
1) Нашёл, и значения совпадают. Тут ничего не надо делать.
2) Нашёл, и значения не совпадают. Значит либо оставить старое значение, либо крепко подумать - а может, старое значение для новой версии не прокатит...
3) Не нашёл такого параметра. Тогда ищем файл, в котором этот параметр должен лежать по умолчанию. Если находим, то прописываем в него этот параметр. Если не находим, то смотрим, какие вообще конфигурационные файлы есть в игре. Затем либо прописываем новый параметр в любой из них, либо создаём недостающий файл и пишем этот параметр в него.

Всё, переходим ко второму параметру из нового cam_ext.cfg. Закончив с cam_ext.cfg, проделываем то же самое и со всеми остальными файлами нового Нью-дарка, в которых могут лежать какие-либо параметры.
Аналогично можно поступать вообще с любыми параметрами, хоть из оригинального darkinst.cfg и других файлов.

Данный алгоритм избавил бы от того геморроя, который приходится иметь после каждого выхода нового Нью-Дарка - составление нового cam_ext.cfg (в моём случае cam.cfg), который не содержит устаревших параметров, но включает все новые из дистрибутивных cam_ext.cfg, new_config_vars.txt и subtitles.txt.
А я ещё и описания параметров копирую, но это уже опционально...

[DJ Riff]

Полный список параметров, существовавших за все времена (оригинальные, ддфиксовские, нью-дарковские) известен.

Огласите весь список, пожалуйста. Потому что мне он не известен и иногда я натыкаюсь на возможность добавить параметр, которого в конфиге нет ни в явном виде, ни в комментариях. Типичный пример — известный Objtextures16 и менее известный Meshtextures16.

1) Нашёл, и значения совпадают. Тут ничего не надо делать.
2) Нашёл, и значения не совпадают. Значит либо оставить старое значение, либо крепко подумать - а может, старое значение для новой версии не прокатит...
3) Не нашёл такого параметра. Тогда ищем файл, в котором этот параметр должен лежать по умолчанию. Если находим, то прописываем в него этот параметр. Если не находим, то смотрим, какие вообще конфигурационные файлы есть в игре. Затем либо прописываем новый параметр в любой из них, либо создаём недостающий файл и пишем этот параметр в него.

Это всё круто. Но что делать, если:

1) юзер использует и ddfix'овый вариант тоже, без ведома Тафферпатча, а я ему тут возьму и конфиги погрохаю?
2) в старых конфигах есть добавленные юзером параметры, которых нет в новых?
3) в разных конфигах встречается один и тот же параметр, но с разными значениями? Рейтинг приоритета файлов есть?
4) есть ли гарантия, что абсолютно все параметры игра точно ищет во всех конфигах, или для некоторых параметров наличие его в определённом (не дефолтном) файле равносильно его отсутствию?

Наверняка ещё что-нибуь вылезет. В общем, чтобы людям ничегно случайно не сломать, нужна бригада тестеров с совершенно разными стилями мышления.

[Призрак Boris'а3000]

Огласите весь список, пожалуйста. Потому что мне он не известен

А я и не себя имел в виду. А вот тебе он просто обязан быть известен. Странно, что этот список не выполняет своих обязательств...
Но вообще, это и не так важно. Это в идеале - отталкиваться от полного списка актуальных параметров. То есть от "белого списка". А на худой конец, можно оттолкнуться и от "чёрного" - списка известных НЕактуальных параметров. Если находится параметр, который точно известно, что на данный момент не нужен, то он грохается. И пусть даже останется некоторое количество неиспользующихся параметров - кому они помешают?

параметр, которого в конфиге нет ни в явном виде, ни в комментариях. Типичный пример — известный Objtextures16

Ну этот-то всю жизнь в dark.cfg сидел.

юзер использует и ddfix'овый вариант тоже, без ведома Тафферпатча, а я ему тут возьму и конфиги погрохаю?

Не, ну это вообще не проблема. Зачем грохать? Сначала надо проверить - а использует ли юзер ддфиксовский вариант. Тут есть целый ряд признаков, которые все вместе дадут гарантию, что использует. Главный из них - наличие "ddfix.dll" хотя бы в одном из главных экзешников (если их несколько, в разных папках).
Соответственно, после того как определено, что ддфиксовский вариант наличествует в установленной игре, то файл ddfix.ini просто не трогаем и всё. Тем более, что вроде ддфиксовские настройки должны лежать строго в нём, правильно? Значит и нет никакой возможности наткнуться на них в других файлах.

в старых конфигах есть добавленные юзером параметры, которых нет в новых?

Если известно, что эти параметры не нужны, то см. выше. Если не известно, то Тафферпатч их просто и не ищет, соответственно они остаются на своих местах. Игра их всё равно не юзает, ну так и хрен с ними.

в разных конфигах встречается один и тот же параметр, но с разными значениями?

И это не проблема. Это всего-навсего приведёт к тому, что данный алгоритм:

1) Нашёл, и значения совпадают. Тут ничего не надо делать.
2) Нашёл, и значения не совпадают. Значит либо оставить старое значение, либо крепко подумать - а может, старое значение для новой версии не прокатит...
3) Не нашёл такого параметра. Тогда ищем файл, в котором этот параметр должен лежать по умолчанию. Если находим, то прописываем в него этот параметр. Если не находим, то смотрим, какие вообще конфигурационные файлы есть в игре. Затем либо прописываем новый параметр в любой из них, либо создаём недостающий файл и пишем этот параметр в него.

отработается 2 раза для одного и того же параметра.
Ведь юзер уже как-то жил с подобным "дуализмом", верно? Ну так и пусть продолжает жить дальше.
К тому же проблема нескольких копий одного и того же параметра существует сама по себе - вне зависимости от предложенного мной алгоритма. И если она не волновала тебя до сих пор, то почему вдруг заволновала сейчас?

есть ли гарантия, что абсолютно все параметры игра точно ищет во всех конфигах

Я даже готов перебрать их по одному и проверить. Но только если ты сначала скажешь по каждому параметру, куда надо смотреть, чтоб заметить их влияние.
Ну и во-вторых, это опять-таки не твоя забота. Если человек напереносил себе и спокойно живёт, то пусть и дальше так живёт. В случае же отсутствия добавляемого параметра и отсутствия умолчанского файла для этого параметра можно выбрать вариант создания умолчанского файла и помещения туда этого параметра. Юзер же, если захочет, сам перенесёт его в cam.cfg свой любимый файл.

Но вообще-то все эти вещи:

Огласите весь список, пожалуйста

Рейтинг приоритета файлов есть?

есть ли гарантия, что абсолютно все параметры игра точно ищет во всех конфигах, или для некоторых параметров наличие его в определённом (не дефолтном) файле равносильно его отсутствию?

по-определению должны быть известны, если есть исходники. А они есть.

Наверняка ещё что-нибуь вылезет

"Что-нибудь" вылезает абсолютно всегда и везде. А потому - "глаза боятся, руки делают".

чтобы людям ничегно случайно не сломать

Пока не вижу, чтоб предложенный алгоритм мог что-то сломать. Только вот "сломать" и "не починить" - немного разные вещи. Тут уж надо сначала определиться с генеральной линий - либо ты в добровольно-принудительном порядке причиняешь добро, удаляя все экспромты конкретного юзера и пытаясь заставить игру гарантированно взлететь, либо мягко и ненавязчиво добавляешь нововведения, удаляя лишь то, что на 100% известно, что теперь не потребуется, а уж что там юзер себе наворотил - его личные проблемы.
Но так как попытка заставить игру автоматически взлетать абсолютно на всех конфигурациях заранее обречена на провал, то остаётся только второй путь.

нужна бригада тестеров с совершенно разными стилями мышления

Ты не в тренде. Щас софт тестируется в основном "боем" - и "тестеров" больше, и затрат меньше. Так что, весь мир - твоя бригада.

[DJ Riff]

А вот тебе он просто обязан быть известен.

Откуда? Если только все исходники перелопатить в поисках этих параметров. Я не программер, у меня на это год может уйти.

И пусть даже останется некоторое количество неиспользующихся параметров - кому они помешают?

На этом можно и закончить, т.к. параметров, старое значение которых может помешать всего две штуки, и их Тафферпатч правит в обязательном порядке при обновлении Ньюдарка. Другое дело, что ищет он пока их только по тем файлам, в которых им положено быть, а не по всем возможным.

Ну этот-то всю жизнь в dark.cfg сидел.

"всю жизнь" не сидел, был найден в своё путём просмотра dromed.exe в текстовом редакторе и добавлен в архив с Дромедом, примерно в то же время, когда появилась версия с поддержкой полноцветных TGA-текстур для объектов.

наличие "ddfix.dll" хотя бы в одном из главных экзешников (если их несколько, в разных папках).

А ничего, что рабочий каталог может параметром при запуске задаваться и не совпадать с путём к экзешнику?

Если известно, что эти параметры не нужны, то см. выше. Если не известно, то Тафферпатч их просто и не ищет, соответственно они остаются на своих местах. Игра их всё равно не юзает, ну так и хрен с ними.

Они не "остаются", их надо перенести в новый конфиг. Конфиг-то я кладу новый, с той структурой, порядком следования параметров и комментариями, которые соответствуют новой версии. Это безопаснее, чем модифицировать старый. А уже потом параметры из старого по возможности переношу в новый.

К тому же проблема нескольких копий одного и того же параметра существует сама по себе - вне зависимости от предложенного мной алгоритма. И если она не волновала тебя до сих пор, то почему вдруг заволновала сейчас?

Это если сравнивать пофайлово, как сейчас, то проблема останется как была. А если для каждого параметра просматривать все конфиги, то ему в конечном итоге придётся присваивать какое-то одно из найденных значений.

Я даже готов перебрать их по одному и проверить. Но только если ты сначала скажешь по каждому параметру, куда надо смотреть, чтоб заметить их влияние.

Если б я это знал, заодно с побочными явлениями, я бы уже сам всё проверил.

Но вообще-то все эти вещи:
по-определению должны быть известны, если есть исходники. А они есть.

Осталось найти человека, который их прочитает и выдаст этот список. Моих знаний для этого явно не хватает.

"Что-нибудь" вылезает абсолютно всегда и везде. А потому - "глаза боятся, руки делают".

Ближайший год руки делают более приоритетные вещи.

Пока не вижу, чтоб предложенный алгоритм мог что-то сломать. Только вот "сломать" и "не починить" - немного разные вещи. Тут уж надо сначала определиться с генеральной линий - либо ты в добровольно-принудительном порядке причиняешь добро, удаляя все экспромты конкретного юзера и пытаясь заставить игру гарантированно взлететь, либо мягко и ненавязчиво добавляешь нововведения, удаляя лишь то, что на 100% известно, что теперь не потребуется, а уж что там юзер себе наворотил - его личные проблемы.

Пока второе. Перелопаченные юзером конфиги, как было написано выше, были отнесены к его личным проблемам, о чём я и сообщил. И да, у меня поначалу был очень похожий на твой алгоритм, и он таки что-то ломал, поэтому был заменён на обратный.

Ты не в тренде. Щас софт тестируется в основном "боем" - и "тестеров" больше, и затрат меньше. Так что, весь мир - твоя бригада.

Я человек эгоистичный до костей мозга, и такое издевательство над юзером мне удовольствия не доставляет.

[Maxim]

Ближайший год руки делают более приоритетные вещи

For example... ?

[DJ Riff]

For example... ?

Там на последней страничке Тафферпатча кнопка "Mod Manager" или как-то так пока неактивная. Вот его, например.

[Призрак Boris'а3000]

Откуда?

Скажу, наконец, прямо. Кто делал Нью-Дарк? Неужели те, кто создавал новые параметры, не знают их списка, списка старых, приоритета файлов и всего остального? На ттлг никак нельзя на знающих людей выйти?

Если только все исходники перелопатить в поисках этих параметров. Я не программер, у меня на это год может уйти.

Что касается списка параметров, то разве они не должны присутствовать в тексте программы в явном виде? Не достаточно для поиска всех параметров, которые могут располагаться, скажем, в cam.cfg, задать поиск "cam.cfg" по файлам исходников?

"всю жизнь" не сидел, был найден в своё путём просмотра dromed.exe в текстовом редакторе и добавлен в архив с Дромедом, примерно в то же время, когда появилась версия с поддержкой полноцветных TGA-текстур для объектов.

Не понимаю, о чём речь. Этот параметр сидит в dark.cfg в составе оригинального дистрибутива версии 1.07.

А ничего, что рабочий каталог может параметром при запуске задаваться и не совпадать с путём к экзешнику?

Не понял, Thief2.exe лежит не в папке (включая под-) с игрой? Не, ну понятно, что всяких немыслимых экзотических ситуаций можно навыдумывать сколько угодно. Например, юзер - прогер, и написал свой собственный ланчер, а все файлы игры зашифровал (каждый по отдельности со своим собственным ключом), и расшифровываются они на лету ланчером при запуске.
И эти ситуации типа являются доказательством, что предложенный вариант подойдёт далеко не для всех случаев... Ну да пусть даже так. Но ведь теперь ясно, что и текущий вариант Тафферпатчера тоже подходит не для всех случаев. Так какая тогда разница? Но предполагаемый новый хотя бы будет создавать полноценный конфиг, удаляя неактуальные параметры (пусть даже и не все) и добавляя все новые из всех файлов (количество которых, к слову, постепенно растёт) дистрибутива Нью-Дарка. А не просто кидать недоношенный умолчанский cam_ext.cfg, поменяв в нём всего пару параметров, которые сам юзер менял в своём предыдущем конфиге.
А с ддфиксом на самом деле всё совсем просто. Потому что вполне может статься так, что ддфикснутого экзешника нет в папке (и вообще нет) временно по воле юзера, а ddfix.ini с его выстраданными настройками имеется в единственном экземпляре на всём компе. И тут приходит Тафферпатчер и его грохает... Поэтому ddfix.ini просто не трогать вообще, и дело с концом. Ну а ddfix.dll можно и затереть втихаря, ибонех, как говорится.

Они не "остаются", их надо перенести в новый конфиг. Конфиг-то я кладу новый, с той структурой, порядком следования параметров и комментариями, которые соответствуют новой версии. Это безопаснее, чем модифицировать старый. А уже потом параметры из старого по возможности переношу в новый.

Я имел в виду гипотетический Тафферпатч, скроённый по предложенному варианту. А так-то понятно.

если для каждого параметра просматривать все конфиги, то ему в конечном итоге придётся присваивать какое-то одно из найденных значений

Нет, это немного нечётко. Присвоить можно только новое значение, но никак не найденное. Выбора между двумя старыми значениями нет и возникнуть не может. Выбор возникает между найденным старым значением и новым. Один раз и второй раз. И оба этих раза абсолютно независимы друг от друга. Тут в принципе нет разницы, одинаковые ли имена у двух параметров или разные - в любом случае гипотетический патч рассматривает их как разные, а точнее ему вообще плевать, разные они или нет - он просто последовательно переходит от одного параметра к другому, про предыдущий сразу "забывая".
Возьмём, например, game_screen_size. Пусть в первом файле указано game_screen_size 640х480, а во втором - game_screen_size 1920х1080. При этом в новом конфиге прописано game_screen_size 1280х1024.
Патч в поисках "game_screen_size" натыкается на него в первом файле и выбирает - оставить ли 640х480 или присвоить 1280х1024. Выбрал. После этого продолжает поиск "game_screen_size" и натыкается на него во втором файле, и снова выбирает - оставить 1920х1080 или присвоить 1280х1024. Выбрал и тут.
Какие возможны итоговые варианты?
1) При логике "оставляем старое" получится ноль изменений. Раз ноль изменений, то и нечего не сломано.
2) При логике "присваиваем новое" получится game_screen_size 1280х1024 в обоих файлах. Не только не сломано, но даже и немного починено.

Ближайший год руки делают более приоритетные вещи.

Ничего, мы люди терпеливые - подождём. Некоторые ФМ-ки да текстурные паки, вон, по нескольку лет делаются, и то ничего.

Перелопаченные юзером конфиги, как было написано выше, были отнесены к его личным проблемам

В какой-то степени эти проблемы теперь начинают появляться у всех, т. к. некоторые новые параметры добавляются в тот файл, в который первый встречный посоветует. Те же параметры субтитров недавно - один говорит "пиши в cam_ext.cfg", а другой - "пиши в user.cfg"...

у меня поначалу был очень похожий на твой алгоритм, и он таки что-то ломал, поэтому был заменён на обратный

Суть вовсе не в том, что он обратный. Обратность - это те же яйца, только в профиль. Можно за отправную точку взять и новые конфиги, а просматривать старые. И добавлять старые параметры в новые конфиги, а не новые в старые. Разница будет лишь в том, что при моём способе у юзера останется его набор файлов, а в твоём - будет оригинальный набор файлов. Но набор параметров в обоих случаях будет одинаковым.
А истинная проблема в том, что твой алгоритм - файлово-ориентированный, назовём это так. Мой - параметро-ориентированный. Именно поэтому у меня случится кавардак, если я накачу Нью-Дарк Тафферпатчером.
Как тогда сделать, чтоб добавление старых параметров в новые конфиги не приводило к кавардаку в случае нестандартного набора и содержания файлов игры юзера? Тогда так, хоть в этом случае юзер и распрощается со своими файлами и получит стандартный набор файлов. Но зато он хотя б заполучит полный набор параметров, да ещё с вычищенными устаревшими, а уж раскидать их снова по своим любимым файлам - секундное дело.
Для начала склеиваем новые конфиги воедино (которые по неведомо какой причине раскиданы уже по трём файлам), тем самым получая новый cam_ext.cfg с полным набором новых параметров, а не обрезанный.
Далее ищем *.cfg и *.ini, имеющиеся в установленной игре. Нашли и заныкали в укромное местечко. Берём первый из них, берём первый параметр из него и ищем его во всех файлах оригинального набора конфигурационных файлов (включая ддфиксовские и нью-дарковские). Варианты:
1) Нашёлся в любых количествах в любых файлах. Абсолютно независимо в каждом из дублей выбираем, какое значение присвоить.
2) Не нашёлся. Проверяем по списку устаревших параметров. Если нашёлся, то игнорим, а если и там не нашёлся, то добавляем в любой файл.
Вот и всё. Далее берём следующий параметр из заныканого юзеровского конфига и проделываем то же самое, и так до конца.

Апдейт.
Правда, при добавлении старых параметров в новые действительно возникает проблема выбора между несколькими старыми значениями. Что лишний раз доказывает - если цель не поломать юзеровский конфиг, то логичнее добавлять новое в старое, а не наоборот. Уж не знаю, чего у тебя там такой метод ломал...
Ну, тут, похоже, не обойтись без узнавания приоритета файлов. Если уж по каким-то причинам никак не связаться со знающими людьми, то можно попробовать вычислить его, покидав один и тот же параметр в разные файлы. По одному параметру для каждой группы - тех, кто по умолчанию сидит в cam.cfg; тех, кто по умолчанию сидит в cam_ext.cfg, ну и т. д. Конфигурационных файлов всего 6 (не считая ддфикса и дромеда), соответственно надо попробовать 6 параметров - по одному из каждого файла. И ещё плюс какой-нибудь параметр, которого нет нигде - чтоб вычислить приоритет файлов для неизвестных науке параметров.

[HellRaiser]

Предлагаю консенсус

[Призрак Boris'а3000]

[off]HellRaiser
Чё-т не кликабельно. Или мне нельзя голосовать за себя?
Да, кстати, моих алгоритмов тут уже целых два, посему просьба уточнить. По умолчанию будем считать, что первый.[/off]

[DJ Riff]

А истинная проблема в том, что твой алгоритм - файлово-ориентированный, назовём это так.

Именно так, причём я стараюсь максимально ориентироваться на файлы. Тогда можно заменить файлы с минимумом изменений в коде. Если все параметры заносить в код непосредственно Тафферпатча, то при следующем обновлении я обязательно забуду что-нибудь поменять. Пока что у меня мысль просматривать умолчанские конфиги, брать оттуда имена параметров и дефолтные значения, и ходить с ними по юзерским файлам. Ну и отдельный спичсок тех, которые при обновлении обязательно поправить или удалить. Как комментарии к ним при этом править, я пока не придумал.

Скажу, наконец, прямо. Кто делал Нью-Дарк? Неужели те, кто создавал новые параметры, не знают их списка, списка старых, приоритета файлов и всего остального? На ттлг никак нельзя на знающих людей выйти?

Понятия не имею и подставлять никого не собираюсь.

Что касается списка параметров, то разве они не должны присутствовать в тексте программы в явном виде? Не достаточно для поиска всех параметров, которые могут располагаться, скажем, в cam.cfg, задать поиск "cam.cfg" по файлам исходников?

Во-первых, наверняка не одно имя, а массив, согласно которому при обращении к конфигфайлам функция обходит все файлы (это то, что мне придётся тоже делать теперь во всех местах, где встречается обращение к чему-то *.cfg). Но я сильно подозреваю, что там тоже кавардак порядочный, и часть параметров ищется через этот массив, часть через какой-нибудь другой, часть напрямую и так далее, в зависимост от того, кто и когда код писал. Во-вторых, имена параметров совершенно не обязательно лежат в виде текста. Например, game_screen_size и edit_screen_size могут на лету составляться из двух половинок. Так что поискать-то можно, и даже найти большую часть, но гарантии, что нашёл абсолютно всё, не будет никакой.