И это можно легко сделать.
Понятия не имею. Возможно, в ban.cmd, нужно где-то добавить ban SAVE.Цитата:
Кстати,а почему после остановки сервера ban.txt переименовывается в ban.bak?
Я раньше не замечал такого, но проверил - точно есть такое.
Вид для печати
Да,по поводу плагина adminPlagin.dll (aminPlagin.dll) Не сохраняет записи списка админов. После перезапуска сервера админлист пустой.
Не забыл.
---------- Добавлено в 13:33 ---------- Предыдущее сообщение было написано в 13:32 ----------
Создается.В нем пусто
---------- Добавлено в 13:34 ---------- Предыдущее сообщение было написано в 13:33 ----------
Не знаю:rolleyes:
---------- Добавлено в 13:34 ---------- Предыдущее сообщение было написано в 13:34 ----------
По-разному пробовал. И сразу server.exe,и через SC
Поправил баг с несохранением списка, добавил команду <banch.
Архив в первом сообщении обновлён.
Команда <banch N добавляет ip канала N в банлист сервера и сохраняет банлист в файл ban.txt.
Проблема с переименованием ban.txt в ban.bak при остановке сервера решается добавлением в конец файла server.cmd строки
ban LOAD ban.bak
Если не планируется править ban.txt вручную во время работы сервера, то этого достаточно.
POP,its work!:) Теперь осталось привертеть команды управления сервером из SC, заставить читать ini файлы миссий, привертеть рандомайзер, и новый коммандер готов...:D
Нужна помощь в разработке веб-статистики.
База данных практически готова, сбор в базу практически всей информации с сервера - тоже.
БД на MS SQL EXPRESS.
Сайт статистики нужен или на php (желательно сразу пятом), или на .NET под IIS.
Всем, кто заинтересован и готов взяться за написание (пусть даже под другую платформу), готов отдать образец пустой базы или чуть позже (через недельку) базы с собранной с действующего сервера статистикой и ответить на любые вопросы.
POP,а готовые тела стат не подойдут,типа как эта?
Нет.
База данных разработана полностью новая, поэтому, переделка будет сложнее, чем написание с нуля.
Не нужны изыски. Нужен минимум функционала и оформления, как было в "стандартном" стате от Геннадьича.
Это для раздачи всем желающим.
А если Дайдалосы выдадут вдруг нагора свой коммандер и стату?:eek: Ведь не зря они трудились над MDS, зная,что без MDS догфайт-серверы не поддерживают движучку?
Здравствуйте, меня зовут Александр.
Прошу прощения, за то что, резко вклиниваюсь в дискуссию.
Честно, прочитал все посты мельком, но уловил основную суть.
Сам не являюсь игроком, потому, тяжело понимаю аббревиатуры и местный сленг.
"Ближе к теме".
Все здесь собравшиеся, обсуждают новую версию статистики для игры ИЛ-2 штурмовик.
Я заинтересован этой темой, по многим причинам:
- я немного веб-программист (php).
- мой брат играет в эту игру и очень переживает из-за плохой статистики.
- несколько, добрых людей, попросили помочь со статистикой.
Вопросы:
- Зачем писать данные статистики на прямую в БД? Это очень сильно ограничивает, сторонних разработчиков, в возможности модификаций.
- Чем обусловлен выбор СУБД (MS SQL EXPRESS)? Опять-же, мы сталкиваемся с проблемой совместимости — решение: Предложения по существу.
- Зачем жесткая структура БД? Опять-же, мы сталкиваемся с проблемой совместимости — решение: Предложения по существу.
СТАТ — сервер (программное обеспечение) статистики.
ИС — игровой сервер (совокупность ИЛ-2 сервера и связующего программного обеспечения)
Предложения по существу:
Можно использовать протокол передачи (через HTTP, используя JSON, XML, URI, JSON:RPC, XML:RPC).
Данные передавать «сырыми» - как есть. Механизмы «разгребания» данных откинуть на СТАТ. (как и каким образом эти данные будут храниться и обрабатываться — будет проблемой разработчика СТАТ)
Протокол можно будет использовать не только для записи данных статистики (с ИС, в БД СТАТ), но и для «общения» СТАТ с ИС, для реализаций таких вещей как: авторизация, проверка допустимости игрока к игре (кик, бан) и многого другого.
Для защиты от подмены или фальсификации данных, можно обойтись, простым средством: каждая сторона (СТАТ и ИС), будут иметь одинаковые ключи проверки, которые будут посылаться с каждым запросом (ключ, даже длинной в 10 символов, заставит попотеть, желающих «напакостить»).
Суть:
Разделить «яйца».
ИС — будет заниматься игрой, сбором информации и пересылкой ее, на СТАТ.
СТАТ — будет заниматься хранением, обработкой и выводом статистики.
ИС+СТАТ — смогут взаимодействовать, на основании протокола.
Не словом, а делом:
Готов взяться за разработку СТАТ (php+MySQL). Есть хорошие наработки в области, хранения и обработки данных (но там своя, очень хитрая система таблиц и хранения данных — MySQL), от сюда и проблема.
Если я смогу получать (а по факту, ИС, сам будет кидать новые данные) данные в сыром виде, я смогу самостоятельно организовать их хранение, в удобном мне формате. И соответственно, при запросе ИС, на авторизацию пользователя, СТАТ просто ответит: да или нет.
Буду рад увидеть, желающих поддержать разработчиков ИС и СТАТ.
Не только, добрыми советами, но активным участием в процессе, разработки и тестирования.
Хорошо-бы еще одного (а можно и двух), программистов (php) – будет веселей.
Так-как проект, общественный - думаю, можно смело работать на GitHUB (программисты - поймут)
Скрытый текст:
В архиве ServerCommander.rar, в первом сообщении, обновлён до версии 2.1.0.0 файл IL2SERVER.dll.
Исправлен баг с пропуском событий отключения игроков
---------- Добавлено в 12:24 ---------- Предыдущее сообщение было написано в 11:06 ----------
Ответил по электронке... Уже дня три...
Без результата
Доброго времени суток.
Письмо получил, и прочитал.
По поводу тех.задания, к сожалению, я сам не гуру в игре, а по этому - даже не знаю, что и как считается и какие данные мне нужны.
Мое представление работы:
БД - база данных
ИС - игровой сервер (сам ИЛ-2)
КМ - командер (программа обеспечивающая работу ИС и производящая сбор информации)
СТАТ - система статистики
ПИЛОТ - один из игроков
КМ - определяет работу ИС (запуск ИС, выбор текущей карты и т.д.), собирает информацию об игре и передает ее СТАТ
СТАТ - занимается формированием отчетных данных, учетом авторизации пользователей
Авторизация (как я это вижу): (далее описана логика, без претензий на верность)
ПИЛОТ, заходит на ИС под своим логинов, вводит свой пароль. КМ, передает логин и пароль СТАТ, которая проверяет допустимость данной пары (логин+пароль) (существование, кик, бан и т.д.) и сообщает КМ результат (login/error). КМ - на основании полученного результата производит необходимые действия (разрешает ПИЛОТУ играть, или принуждает покинуть игру)
Передача статистики боя
КМ, работая с ИС, производит сбор данных о текущих действиях на ИС и передает их СТАТ.
СТАТ, обрабатывает полученные данные и сохраняет их в БД, для последующего использования.
Статистика для ПИЛОТОВ
ПИЛОТ, заходит в СТАТ (которая может являться, веб-страницами, веб-приложением или даже локальным клиентом).
СТАТ отображает необходимы данные ПИЛОТУ получая данные из БД
Понимаю, что все выше описанное, для большинства - не новость. Просто есть желание сделать все по человечески.
Вопросы и ответы:
1) Зачем КМ, напрямую работать с БД?
Как я понял, КМ необходимо где-то хранить промежуточные данные, кто сейчас в игре, кто авторизирован, а кто еще нет.
Думаю для этих целей КМ может использовать собственную БД, но только для хранения временных данных.
Даже такие вещи, как: список карт, последовательность карт, настройки карт (если это возможно) - хранить в БД СТАТ = это даст возможность, редактировать ИС из удобного интерфейса, не ковыряясь в десятках файлов
2) Протокол для КМ+СТАТ?
Использование протокола, позволит организовывать независимую (от ОС, разрабочика, СУБД) систему хранения данных в СТАТ.
Каждый желающий, сможет использовать КМ и создать свою СТАТ
КМ и СТАТ - смогут работать на разных серверах и станут независимыми в своей работе
Потому что вы себе слабо представляете, нет, совсем не понимаете как и что работает.
Чтобы не городить всю следующую ерунду:
База это альфа и омега.
SQL База это и есть сама война или что вам угодно.
А сатистика - это всего лишь набор скриптов на Языке Структуированных Запросов, что и означает SQL.
Статистика лишь визуальное представление текущей войны, частный случай, определяемый лишь тем, что какая-то группа игроков желает увидеть, или даже скорее - показать, тем, кто находится вне игры :)
Как впрочем является скриптами на SQL и все остальное - генерация "арены" для боя (куда, какие и сколько танчиков поставить, доступные аэродромы и самолеты с вооружением на них для пилотов, что каким игрокам доступно, в первую очередь в связи с привязкой к выбранной армии, всякие условия типа погоды и т.п.), обработка запросов пилотов при входе на сервер о "конфигурации арены", а так же постоянное отслеживание изменений на "арене" вносимых игроками в процессе игры или по еще каким то механизмам, отслеживание состояния самих игроков, расчеты необходимых изменений, с учетом заранее заданных или вычисляемых параметров и т.п., и передача этой информации обратно игрокам.
Всякие частности типа авторизация (потому что можно и без неё ведь обойтись в каких-то случаях), проверка чего-то или кого-то, защита от и т.п. это тоже все скрипты.
Что-то примерно так.
И вне всякого сомнения для базы надо использовать настоящий SQL. MS SQL хороший выбор.
Какое MySQL имеет отношение к SQL, непонятно.
А командер/демон/парсер это всего лишь костыль/замена отсутствующего API у выделенного сервера Ил-2.
Впрочем все это уже давно реализовано и успешно работает не менее чем на десятке игровых серверов.
Перечитайте, мой первый пост (1518624), я там, как раз и сообщаю, что я очень плохо знаю игру.
И поверьте, знание игры, не очень сильно повлияет на качество написанного программного кода.
Как думаете, программисты, которые писали код ИЛ-2, сколько имели боевых часов, на як-3 и ла-5фн??? :dontknow:
Почитайте на досуге: :rtfm:
http://ru.wikipedia.org/wiki/Sql
http://ru.wikipedia.org/wiki/MySQL
Уважаемый, я не лечу Вас и всех здесь присутствующих, по Вашей родной теме. Я не рассказываю, почему какой самолет лучше. Я не делаю выводов, о не верных конструкторских решениях КБ Лавочкина и т.д.
Так будьте добры, не лезьте в Мой огород.
Я программист, я пишу код, что этот код будет делать - я знаю, для чего - мне знать не обязательно.
Ни чего личного.
Я не "спаситель", во втором пришествии.
А лишь заинтересован в развитии проекта, а именно новая, хорошая, масштабируемая - статистика.
Что я хочу от Вас?
Я хочу посильной помощи, в создании этого проекта. Будет много вопросов и про интерфейс, и расположение элементов статистики на странице сайта и много других важных и не очень вопросов.
Буду очень рад Вашей помощи.
Прошу прощения, если мои слова, в этом посте, кого-то обидели и оскорбили.
Как и у любой программы :)
Главное - работает УЖЕ.
А недостатки это продолжение достоинств :)
И их никто не мешает править тем, кому надо.
Глюки уж точно ни при чем, если кто-то не разбирается в программировании :)
---------- Добавлено в 10:31 ---------- Предыдущее сообщение было написано в 10:17 ----------
Вас никто и не лечит.
Вам говорят как надо.
А если вы сами программист, то чего тогда спрашиваете,
и пишите:
С этого точно не стоит начинать :)
Не надо бежать впереди паровоза.
Что куда отобразить надо прикидывать, когда БУДЕТ ЧТО отображать.
А до этого еще много чего надо сделать.
Вопросы данной тематики, будут очень щепетильными и будут решаться несколько недель, а может и месяцев.
И ждать решения, когда уже тех.часть готова - будет неуместно.
А почему мне важно мнение людей которые будут пользоваться этим "продуктом"? - ответ в вопросе, "им пользоваться, а не мне". Я могу сделать на свое усмотрение, и оно с большой вероятностью будет ошибочным и не удобным.
По сути есть два пути:
- Я делаю так как удобнее конечным пользователям - и все счастливы.
- Я делаю, как сам решу - и в последствии начнется переделка ("сделай лучше так")
Именно потому что я программист, я и спрашиваю ИГРОКОВ, которым пользоваться этой системой. Я заставляю "программу работать", но как она должна работать и какой должен быть конечный результат - решать конечным пользователям (ИГРОКАМ).
Итог:
Думаю нет смысла продолжать выяснять, кто в чем прав и виноват.
Лучше всю эту энергию направить в нужное русло.
Я так понимаю, вы очень хорошо знаете игру и методы расчета и вывода статистических данных.
Может Вы и возьмете на себя роль "выпускающего редактора"?
- тестирование
- внесение предложение
- вынесение отдельных вопросов на обсуждение общественности
- принятие решений касательно визуального и структурного оформления
Ребята, не ругайтесь :)
У каждого свои предпочтения и взгляды на "как оно должно быть".
Думаю, что всегда можно договориться до наиболее интересного решения, если не только говорить, но и слушать друг друга.
Сейчас не идёт речь о создании нового крупного проекта, а, для начала, всеголишь, о замене SC более открытым и гибким проектом, постаравшись избавиться от его основных ограничений и недостатков и не наделав новых.
Пока - просто нужен массовый продукт, на начальном уровне под новые возможности 4.10, с возможностью в дальнейшем масштабировать до более серьёзных вещей.
Основа, собирающая и хранящая информацию от сервера, понимающая русские (на русской винде, немецкие на немецкой, китайские на китайской.... и т.д) буквы в никах, уже есть, возможность прикручивать любой функционал - есть.
Нужно отображение статистики, уровнем не хуже того древнего стата от Геннадьича.
Что и как делать дальше - будем разбираться потом, главное сейчас - не наделать принципиальных ошибок, которые потом придётся обходить "костылями".