как прогресс? уже можно юзать в опытной эксплуатации?Есть ли интеграция с dcg? идеальным был бы вариант - dcg генерит миссии по своим правилам, а демон следит за самолетами/пилотами/критически важными объектами и если что принудлителньо заставляет dcg перегенерить миссию.
еще добавить
- количественно распределение самолетов по званиям (среди тех что вставит dcg)
- учет этих самых званий пилотов
И получается мега система для не супер хардкорных серверов с уклоном к серьезной войне.
Крайний раз редактировалось MoHaX; 18.10.2006 в 17:23.
В принципе должно быть уже юзабельно, но пока не провели публичного тестирования ничего гарантировать не могу. Но пока, к сожалению, для этого не хватает времени.
В сторону DCG ничего не делалось. Мне более знаком FBMission в этом вопросе так что когда буду зтачивать под генератор то это будет скорее всего последний.
Крайний раз редактировалось IvanoBulo; 18.10.2006 в 18:04.
не можешь летать - не мучай метлу!
FBMission мы как раз сейчас используем. Но насколько я понял он просто двигает фронт по фидам. Превысили разницу в очках наземки (считается по всему фронту) - захватили ближайший филд. Отсюда невозможность организовать "локальное преимущество" когда целенаправлено выносим участок фронта и по итогам миссии фронт там сдвигается.Сообщение от IvanoBulo
В принципе должно быть уже юзабельно, но пока не провели публичного тестирования ничего гарантировать не могу. Но пока, к сожалению
В сторону DCG ничего не делалось. Мне более знаком FBMission в этом вопросе так что когда буду зтачивать под генератор то это будет скорее всего последний.
Какой прогноз по времени?
Неожиданно к серверу проявил народ интерес. Даже удивительно.
Кирилл
На днях исправил несколько багов и в принципе считаю что всё должно работать нормально. Пока что нет статистики, над ней работает Бакс. Если статистика не очень нужна могу собрать пре-альфа версию демона с краткой инструкцией по инсталяции.
Вопрос ко всем заинтересованным. Какие из перечисленных функций наиболее интересны (в скобках трудоёмкость)?
1. (3) Отслеживание игроков с высоким пингом или с низким коннектом
2. (2) Голосование за смену карты
3. (2) Отслеживание игроков уничтожающих своих
4. (4) Интеграция с DCG/FBMission
5. (5) Графический интерфейс (в данный момент только командная строка и конфигурационные файлы)
Буду имплементировать в зависимости от ваших приоритетов. Также жду новых предложений. Первая версия демона будет выпущена примерно в то же время что и статистика.
не можешь летать - не мучай метлу!
3, 1, 2, 4, 5 -совсем не надо
Наибольший интерес представляет поддержка плагинов, как это сделано в OpenCommander -произвольно написанная прога цепляется к "движку" и слушает уже отпарсенные события из разных источников (лог + чат) и реагирует на это как вздумается.
Учитывая то что сейчас весь функционал судя по всему сделан монолитно, видимо это самая трудоемкая задача =(
Я не вижу необходимости в этом. Что может дать такая поддержка? Будет реализован отчёт о миссии в XML формате. Будет возможность определять через параметры выбор из нескольких альтернатив на более высокоуровневые события, как то давать или запрещать взлёт неавторизированым игрокам взлететь, получить тот или иной самолёт. К тому же так как исходники все есть, то что мешает заменить тот или иной код на произвольный?
Иными словами, моя цель создать достаточный уровень гибкости для того чтобы не нужно было разрабатывать ещё какие-то плагины.
не можешь летать - не мучай метлу!
Все очень просто: можно будет неограниченно расширять функционал. Добавлять новыее команды чата, по своему их обрабатывать, можно будет писать какие угодно по сложности войнушки, не заморчаиваясь на низкоуровневую коммуникацию (типа соединения с сервером, парсинг событий, преобразование в уникод и пр.) - ведь просто разбирая высокоуровневые события игры можно сконцентрироваться именно на своих задачах. Как пример: сделать начисление званий и раздачу самолетов по званиям. Через XML это не прописать, до тех пор пока Вы не добавите такой функционал в сам демон. А это потеря гибкости и бОльшая нагрузка на Вас. Поскольку писать плагин не заботясь ни о чем и ковырять сам код демона не одно и то же - в первом случае жизнь стороннего разработчика сильно облегчается.
Дык вроде проблем особых нет... например смотрим сюда
http://jaydaemon.svn.sourceforge.net...2/daemon/impl/
Тут реализация всех команд и реакций на события...
Например вот команда list-missions
http://jaydaemon.svn.sourceforge.net...97&view=markup
Ничего не мешает написать свою kill-em-all и добавить тут. (думаю чуть пожже добавится возможность конфигурирования этого через конфиг)
http://jaydaemon.svn.sourceforge.net...98&view=markup
По идее даже можно замутить некий generic-groovy/python-command который будет исполнять произвольный скрипт на нужном языке...
...И от полученных знаний скончался на месте
Я лично противник такого потому как в реальности такого не было. Был полк укомплектованный конкретным типом самолётов и это было бы самоубийством если было бы как ты предлагаешь. Ну как ты себе представляешь что ведущий летит на Як-9У а его ведомый на Як-7? Что может сделать такая боевая единица? Только умереть...
Тем не менее будет возможность добавления некого своего делегата который будет извещён что такой-то пилот пробует влететь на таком-то самолёте, а там делай что хочешь, пиши всё что в голову придёт...
не можешь летать - не мучай метлу!
Хорошо, добавить обработчик чата действительно просто (но сам факт ковыряния основного кода все равно не добавляет радости). Но я имел ввиду другое. Сразу скажу что по ка в вашем командере не копался, по этому сужу просто по тому что мельком увидел.
Для примера стоит взглянуть на обработчики событий игры,а не чата. Например возьмем TakeoffEventHandler - он парсит строку напрямую из лога и записывает состояние пилота. Задача: если взлет был меньше чем через минуту после смерти то кикнуть игрока. Сейчас это надо реализовывать прям в том же хендлере, дописывая внизу проверки и реакции. Так понаписав кучу обработчиков в разных хендлерах поддержка всего этого превращается в головняк (ведь вы тоже продолжаете развивать свой продукт). Я прошу рассмотреть возможность сделать вот что - все события обработанные вот этими хэндлерами потом экспортировать ввиде событий, на который могут подписывать (на все или только на некоторые) разные внешние модули и обрабатывать их по-своему (естественно им надо будет предоставить некий API для обратной связи, например в нашем примере что б можно было кикать пилота).
Если я не до конца усек (а я полагаю что это так) дизайн демона и добавлять высокоуровневые (не парсеры строчек из лога) обработчики тоже довольно просто тогда поддержку плагинов можно будет реализовать меньшими силами чем я предполагал ранее
Вот про это я и говорю. Не только кто на чем взлетел, а вообще все события игры представить в удобоваримом виде (кто прыгнул, кто где танк уничтожил и т.д.). Сейчас делать что хочешь не получится, потому как можно написать такой функционал который будет конфликтовать с существующим, зашитым в код. Для развязывания рук надо иметь возможность отключать то что уже есть. Самое красивое если демон будет представлять движок, целью которого станет:
1) коммуникация с игрой
2) разбор событий и экспорт их в удобоваримом виде для плагинов
3) разные удобные классы типа pilot, plane, mission, server и т.д. (API в общем)
4) стандартные плагины, которые реализуют виденье авторов о том, какой должен быть функционал демона. Заодно будут служить примером другим плагинописателям
+1
Кирилл
Запустил демона под линуксом
Как не странно но работает всё как-то лучше... (субъективно)
не можешь летать - не мучай метлу!
Дык я его так и девелопилЗапустил демона под линуксом
Как не странно но работает всё как-то лучше... (субъективно)
...И от полученных знаний скончался на месте
Будет даже больше. При создании самолёта/юнита некий Observer будет об этом оповещён, а в нём вешайте слушатели на этот самолёт/юнит. Можно будет реагировать на любое из событий, вроде взлетел, сел, уничтожен, ранен а также узнать где и когда и кем
не можешь летать - не мучай метлу!
Вот за этот приоритет голосую
Как будет решен конфликтов функционала. Гипотетический пример: если у вас уже реализован кик, если не введен корректный пароль, а я хочу написать свой модуль который в случае взлета без пароля будет выводить в течение минуты предупреждения на экран и только потом кикать - на лицо конфликт, т.к. ваш встроенный функционал уже кикнет игрока, пока мой модуль будет только готовиться к этому
А если я ему захочу сказать пару словечек? Не предусмотренных в твоем коде?
PS MoHaX первый спросил. Почти тож самое.
Менее 2-ух часов, т.е. "очень легко". Фактически уже почти зделано.Вот за этот приоритет голосую
С такими взглядами из любой ситуации можно "высосать" конфликтКак будет решен конфликтов функционала. Гипотетический пример: если у вас уже реализован кик, если не введен корректный пароль, а я хочу написать свой модуль который в случае взлета без пароля будет выводить в течение минуты предупреждения на экран и только потом кикать - на лицо конфликт, т.к. ваш встроенный функционал уже кикнет игрока, пока мой модуль будет только готовиться к этому
Конфликта не будет, потому как Вашему observer'у будет доступен лишь метод "kick(Player player, String reason)". Одним словом "чужой" код будет довольствоваться тем малым что не сможет вызвать конфликта интересов
не можешь летать - не мучай метлу!
будет метод "sendMessage(Player player, String msg)"А если я ему захочу сказать пару словечек? Не предусмотренных в твоем коде?
PS MoHaX первый спросил. Почти тож самое.
не можешь летать - не мучай метлу!
И все равно, если вернуться к моему примеру - мой observer не будет кикать сразу, а будет раз в 10 секунд слать sendmessage(), после 6 циклов пошлет kick(), в то же время ваш встроенный функционал кикнет забывичвого игрока сразу же в момент отрыва от земли. Если подумать то таких конфликтов может быть много. Вопрос ИМХО можно решить просто: достаточно ввести конфигурационный файл с параметрами типа bool где весь встроеный функционал будет включаться или отключаться.С такими взглядами из любой ситуации можно "высосать" конфликт
Конфликта не будет, потому как Вашему observer'у будет доступен лишь метод "kick(Player player, String reason)". Одним словом "чужой" код будет довольствоваться тем малым что не сможет вызвать конфликта интересов
Никаких асинхронных операций в чужом коде. Это будет в документации. Кто так делать не будет сам себе злой Буратино.
С другой стороны твой встроенный цикл на 10 секунд остановит обработку событий чата и евентлога на это время, так что будешь вдвойне сам себе злой Буратино.
И это вовсе не из-за моих принципов а из-за того что транзакции имеют начало и конец, открывается при получении сообщения из консоли или лога и закрывается после его обработки. Любая твоя асинхронная операция попросту не попадает в транзакцию и ломает всю твою логику. Так что как бы не хотелось придётся мирится с некоторыми ограничениями и пользоваться только тем что разрешено.
не можешь летать - не мучай метлу!
Как говориться "по просьбам трудящихся", добавил Plug-in API и как пример реализация команды <vote. API как понимаете далеко от финального и будет изменять до выхода первого релиза но для ознакомления вполне подходит
не можешь летать - не мучай метлу!
Ещё один плагин для отслеживания и "награждения" штрафными очками игроков с низкими настройками сети.
ЗЫ: "Юбилейный" 100-ый коммит в репозиторий
не можешь летать - не мучай метлу!
Ваши права
Ответить с цитированием