Перенес из темы вопросов.
Цитата Сообщение от Small_Bee Посмотреть сообщение
Если ты не задумываешь действительно чего то глобального с пол-сотней классов и тысячами строк кода, делать отдельную dll не стоит. Да и засорять папку игры dll-ками я бы не стал, имхо стоит подумать как сделать проще (например загружать пустые миссии со скриптом)
Bridge это не совсем рефлексия, там она используется для загрузки сборки и извлечению из нее класса и его методов.
Переменные можешь смело хранить в файле. Код скриптов миссии вызывается последовательно, так что о проблемах многопоточности можно не беспокоится.
А вообще, скажу по секрету, будет встроенный локалайзер и общее хранилище для миссий в RSTMission, это что бы не делал лишнюю работу, если что.
Нет, ничего глобального. Как раз нужна система отправки/локализации сообщений и хранилище. А когда планируешь сделать?
Еще вопрос по командеру.

6. Требования к скрипту миссии.

Если карта не имееет собственного скрипта, необходимый скрипт будет добавлен автоматически. Однако если скрипт есть, для корректной работы коммандера необходимо будет выполнить несколько действий.

- первой строкой поместить строку
//$reference REPKA.Stat.dll
- класс миссии должен наследоваться от RSTMission
- переопределить метод Inited(), в котором указать имя сражение и название карты, так, как она выглядит в mis файле, исключая все, что до знака $.
В качестве примера можно использовать скрипт, который коммандер добавляет к картам автоматически.
Какие требования к структуре папок? Мне будет неудобно вставлять все миссии в папку командера. Можно там использовать папку SMP, например, а в ней уже остальные папки миссий? Наверное нужна возможность задать путь к каждой хост миссии.

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