Да,по поводу плагина adminPlagin.dll (aminPlagin.dll) Не сохраняет записи списка админов. После перезапуска сервера админлист пустой.
Не забыл.
---------- Добавлено в 13:33 ---------- Предыдущее сообщение было написано в 13:32 ----------
Создается.В нем пусто
---------- Добавлено в 13:34 ---------- Предыдущее сообщение было написано в 13:33 ----------
Не знаю
---------- Добавлено в 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 файлы миссий, привертеть рандомайзер, и новый коммандер готов...
Крайний раз редактировалось mar$; 07.12.2010 в 00:06.
Нужна помощь в разработке веб-статистики.
База данных практически готова, сбор в базу практически всей информации с сервера - тоже.
БД на MS SQL EXPRESS.
Сайт статистики нужен или на php (желательно сразу пятом), или на .NET под IIS.
Всем, кто заинтересован и готов взяться за написание (пусть даже под другую платформу), готов отдать образец пустой базы или чуть позже (через недельку) базы с собранной с действующего сервера статистикой и ответить на любые вопросы.
POP,а готовые тела стат не подойдут,типа как эта?
Нет.
База данных разработана полностью новая, поэтому, переделка будет сложнее, чем написание с нуля.
Не нужны изыски. Нужен минимум функционала и оформления, как было в "стандартном" стате от Геннадьича.
Это для раздачи всем желающим.
А если Дайдалосы выдадут вдруг нагора свой коммандер и стату? Ведь не зря они трудились над MDS, зная,что без MDS догфайт-серверы не поддерживают движучку?
Здравствуйте, меня зовут Александр.
Прошу прощения, за то что, резко вклиниваюсь в дискуссию.
Честно, прочитал все посты мельком, но уловил основную суть.
Сам не являюсь игроком, потому, тяжело понимаю аббревиатуры и местный сленг.
"Ближе к теме".
Все здесь собравшиеся, обсуждают новую версию статистики для игры ИЛ-2 штурмовик.
Я заинтересован этой темой, по многим причинам:
- я немного веб-программист (php).
- мой брат играет в эту игру и очень переживает из-за плохой статистики.
- несколько, добрых людей, попросили помочь со статистикой.
Вопросы:
- Зачем писать данные статистики на прямую в БД? Это очень сильно ограничивает, сторонних разработчиков, в возможности модификаций.
- Чем обусловлен выбор СУБД (MS SQL EXPRESS)? Опять-же, мы сталкиваемся с проблемой совместимости — решение: Предложения по существу.
- Зачем жесткая структура БД? Опять-же, мы сталкиваемся с проблемой совместимости — решение: Предложения по существу.
СТАТ — сервер (программное обеспечение) статистики.
ИС — игровой сервер (совокупность ИЛ-2 сервера и связующего программного обеспечения)
Предложения по существу:
Можно использовать протокол передачи (через HTTP, используя JSON, XML, URI, JSON:RPC, XML:RPC).
Данные передавать «сырыми» - как есть. Механизмы «разгребания» данных откинуть на СТАТ. (как и каким образом эти данные будут храниться и обрабатываться — будет проблемой разработчика СТАТ)
Протокол можно будет использовать не только для записи данных статистики (с ИС, в БД СТАТ), но и для «общения» СТАТ с ИС, для реализаций таких вещей как: авторизация, проверка допустимости игрока к игре (кик, бан) и многого другого.
Для защиты от подмены или фальсификации данных, можно обойтись, простым средством: каждая сторона (СТАТ и ИС), будут иметь одинаковые ключи проверки, которые будут посылаться с каждым запросом (ключ, даже длинной в 10 символов, заставит попотеть, желающих «напакостить»).
Суть:
Разделить «яйца».
ИС — будет заниматься игрой, сбором информации и пересылкой ее, на СТАТ.
СТАТ — будет заниматься хранением, обработкой и выводом статистики.
ИС+СТАТ — смогут взаимодействовать, на основании протокола.
Не словом, а делом:
Готов взяться за разработку СТАТ (php+MySQL). Есть хорошие наработки в области, хранения и обработки данных (но там своя, очень хитрая система таблиц и хранения данных — MySQL), от сюда и проблема.
Если я смогу получать (а по факту, ИС, сам будет кидать новые данные) данные в сыром виде, я смогу самостоятельно организовать их хранение, в удобном мне формате. И соответственно, при запросе ИС, на авторизацию пользователя, СТАТ просто ответит: да или нет.
Буду рад увидеть, желающих поддержать разработчиков ИС и СТАТ.
Не только, добрыми советами, но активным участием в процессе, разработки и тестирования.
Хорошо-бы еще одного (а можно и двух), программистов (php) – будет веселей.
Так-как проект, общественный - думаю, можно смело работать на GitHUB (программисты - поймут)
Скрытый текст:
Крайний раз редактировалось AlexMcArrow; 16.12.2010 в 07:46. Причина: Забыл указать время, когда я в сети
В архиве 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.
Впрочем все это уже давно реализовано и успешно работает не менее чем на десятке игровых серверов.
Крайний раз редактировалось Karabas-Barabas; 20.12.2010 в 22:14.
Перечитайте, мой первый пост (1518624), я там, как раз и сообщаю, что я очень плохо знаю игру.
И поверьте, знание игры, не очень сильно повлияет на качество написанного программного кода.
Как думаете, программисты, которые писали код ИЛ-2, сколько имели боевых часов, на як-3 и ла-5фн???
Почитайте на досуге:
http://ru.wikipedia.org/wiki/Sql
http://ru.wikipedia.org/wiki/MySQL
Уважаемый, я не лечу Вас и всех здесь присутствующих, по Вашей родной теме. Я не рассказываю, почему какой самолет лучше. Я не делаю выводов, о не верных конструкторских решениях КБ Лавочкина и т.д.
Так будьте добры, не лезьте в Мой огород.
Я программист, я пишу код, что этот код будет делать - я знаю, для чего - мне знать не обязательно.
Ни чего личного.
Я не "спаситель", во втором пришествии.
А лишь заинтересован в развитии проекта, а именно новая, хорошая, масштабируемая - статистика.
Что я хочу от Вас?
Я хочу посильной помощи, в создании этого проекта. Будет много вопросов и про интерфейс, и расположение элементов статистики на странице сайта и много других важных и не очень вопросов.
Буду очень рад Вашей помощи.
Прошу прощения, если мои слова, в этом посте, кого-то обидели и оскорбили.
Как и у любой программы
Главное - работает УЖЕ.
А недостатки это продолжение достоинств
И их никто не мешает править тем, кому надо.
Глюки уж точно ни при чем, если кто-то не разбирается в программировании
---------- Добавлено в 10:31 ---------- Предыдущее сообщение было написано в 10:17 ----------
Вас никто и не лечит.
Вам говорят как надо.
А если вы сами программист, то чего тогда спрашиваете,
и пишите:
С этого точно не стоит начинать
Не надо бежать впереди паровоза.
Что куда отобразить надо прикидывать, когда БУДЕТ ЧТО отображать.
А до этого еще много чего надо сделать.
Крайний раз редактировалось Karabas-Barabas; 21.12.2010 в 10:41.
Вопросы данной тематики, будут очень щепетильными и будут решаться несколько недель, а может и месяцев.
И ждать решения, когда уже тех.часть готова - будет неуместно.
А почему мне важно мнение людей которые будут пользоваться этим "продуктом"? - ответ в вопросе, "им пользоваться, а не мне". Я могу сделать на свое усмотрение, и оно с большой вероятностью будет ошибочным и не удобным.
По сути есть два пути:
- Я делаю так как удобнее конечным пользователям - и все счастливы.
- Я делаю, как сам решу - и в последствии начнется переделка ("сделай лучше так")
Именно потому что я программист, я и спрашиваю ИГРОКОВ, которым пользоваться этой системой. Я заставляю "программу работать", но как она должна работать и какой должен быть конечный результат - решать конечным пользователям (ИГРОКАМ).
Итог:
Думаю нет смысла продолжать выяснять, кто в чем прав и виноват.
Лучше всю эту энергию направить в нужное русло.
Я так понимаю, вы очень хорошо знаете игру и методы расчета и вывода статистических данных.
Может Вы и возьмете на себя роль "выпускающего редактора"?
- тестирование
- внесение предложение
- вынесение отдельных вопросов на обсуждение общественности
- принятие решений касательно визуального и структурного оформления
Ребята, не ругайтесь
У каждого свои предпочтения и взгляды на "как оно должно быть".
Думаю, что всегда можно договориться до наиболее интересного решения, если не только говорить, но и слушать друг друга.
Сейчас не идёт речь о создании нового крупного проекта, а, для начала, всеголишь, о замене SC более открытым и гибким проектом, постаравшись избавиться от его основных ограничений и недостатков и не наделав новых.
Пока - просто нужен массовый продукт, на начальном уровне под новые возможности 4.10, с возможностью в дальнейшем масштабировать до более серьёзных вещей.
Основа, собирающая и хранящая информацию от сервера, понимающая русские (на русской винде, немецкие на немецкой, китайские на китайской.... и т.д) буквы в никах, уже есть, возможность прикручивать любой функционал - есть.
Нужно отображение статистики, уровнем не хуже того древнего стата от Геннадьича.
Что и как делать дальше - будем разбираться потом, главное сейчас - не наделать принципиальных ошибок, которые потом придётся обходить "костылями".