То есть утверждается, что строки call SetPlayerAlliance(Player(15),Player(#),ConvertAllianceType(6),true) вставлены в config вручную? И при снятии защиты их надо просто поместить в начало инициализации?

На всякий случай уточню, в редакторе нет опций, позволяющих расшарить контроль нейтрального игрока остальным, не используя триггеров? (Что-то похожее есть в настройках Scenario->Force properties)

DioD: спс за информацию,

Тогда я просто добавлю лишний код из конфига с помощью тех же //! inject config (тем самым программа будет требовать вджасс, могу добавить опцию чтобы это отключить).

По поводу переменных, значит редактор всё-таки не пересоздаёт war3map.j с нуля при каждом сохранении, а создаёт новый код на базе старого? А что же он делает если ему подсунуть war3map.j из исходной карты (то есть обфусцированный)?
Я бы предпочёл не создавать гуи-триггеров специально для этого, если так возможно. Но получается что для этого надо будет пересоздать war3map.j в вот виде, в котором его пишет редактор?

А одного большого триггера я хотел бы избежать так как это довольно неудобно редактировать.

Да и ещё, насколько я понимаю данные об исходных локациях, указанные в war3mapUnits.doo (в виде объектов sloc) имеют приоритет над теми, которые указаны в war3map.w3i? Ибо данные в w3i доты не совпадают с локациями, заданными в функции config.

И ещё вопрос тогда, где можно прочитать подробное описание того, что оптимизатор (vex?) делает с BJ функциями? В доте несколько функций продублированы почти без изменений (первые несколько функций в скрипте - PolledWait, PolarProjectionBJ, GetPlayerEnemies, UpdateEachStockBuilding, PerformStockUpdates, StartStockUpdates). Единственное отличие, которое я нашёл - замена null булэкспра на другой, всегда возвращяющий true. Это связано с очередным мак-багом? И можно ли это всю эту развёртку InitBlizzard безопасно убрать, понадеявшись что на этапе обратной оптимизации этот фикс внесётся опять?

FunkieFoO: по поводу сроков точно сказать не могу, я бы хотел по крайней мере доделать обработку джасса (сейчас пишу исполняющую часть) и восстановление звуков/регионов/камер/юнитов. Вообще говоря, работоспособную версию могу выложить и сейчас (убрав лишний код), если тупо создать огромный триггер со всем кодом карты и ничего из него не извлекать. Но тогда мне придётся писать программу в нелогичном порядке (сначала интерфейс потом начинку???).
Я думаю что сделаю гуи программку со всякими чекбоксами для настроек, благо для этого просто требуется добавить один диалог что есть дело 15 минут. А может сделаю консольную програмку с ini файлом подобно xdep плюс гуишную программу с чекбоксами, которая этот ini файл пишет и запускает сам депротектор.

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

У меня возникает ощущение что редактор читает глобальные переменные в war3map.j и находит среди них те, которые имеют вид gg_unit_xxxx_####. У меня получается что-то вроде следующего:
1. Редактор читает список глобальных переменных war3map.j, похожих на названия юнитов, и добавляет их в список, если они упоминаются в war3map.wct/wtg
2. Если через ГУИ-редактор выбирается юнит, он добавляется в список
3. При сохранении список пишется в глобальные переменные
4. Независимо от этого списка, при генерации функции CreateUnitsForPlayerX редактор ищет упоминание gg_unit_<id>_<#> в wct/wtg, если найдено то пишет set gg_unit_<id>_<#> = CreateUnit (...), иначе set u = CreateUnit (...). Например если ничего в ГУИ редакторе не выбирать, просто поставить ферму и написать триггер call KillUnit (gg_unit_hhou_0001) то ругатся редактор будет не на эту строчку, а на строчку в своей же инициализации (правда, возможно, это ошибка jasshelper).
Я потестирую ещё немного и посмотрю что получится.

А вообще странно, почему бы не научить jasshelper тупо создавать недостающие переменные gg_unit_xxxx_####...

Вообще-то я хотел попробовать написать свой AI; я понимаю что это делается не так и AI скрипты в конечном счёте вставляются в карту программно, но было бы удобней писать скрипт в редакторе. А может это мне кажется...
И потом, делали же люди ОпенДоту и ничего...
Конечно правда, что ск2 может это всё очень быстро накрыть... ну тогда я просто возобновлю вов аккаунт и мне на всё снова по барабану будет.

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

Да и по поводу 6х6: сравни с OMG дотой, она появилась значительно позже 6х6, и гораздо более популярна. Аналогично AI карты.

Да, я делаю vampirism fire и dota replay manager

Но на ск2 я переходить наверное не буду, я и не особо увлекался ск1, хз.