Про высотные бомбардировки.

[Charger]

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

Вообще то странно слышать от бомбера который отказывается от крупной, стратегической важной цели...
Я уверен что с появлением таких целей, отряд бомберов увеличится в разы.
Далеко не у каждого сейчас вызывает интерес делать единственный вылет на миссию ради пары статиков...

Бомберы, они зверьки специфические. Появление целей не увеличит "в разы" их численность. Ибо лететь долго, куш, конечно не маленький, но появятся и те, кто будет баркапить свою тыловую цель. А с мелким калибром мало кто на бомберов ходит.

[mr_tank]

Точки "атака" быть не должно . Пока не сделают раздельный выбор целей для самолётов одного звена .

Если прикрутили респавн объектов, то вероятно, можно сделать респавн точек маршрута. Это, естественно, сугубо дилетантское мнение.

[Q-8]

мое имхо по данному вопросу:

площадные цели(триггерный, условные, называйте как хотите-главное чтобы с их помощью можно было получить инфу) нужны. причем именно обязательно чтобы о падении АБСП в етой зоне неким образом можно было получить информацию и передать ее какой либо сторонней проге. например, через особый лог, где как раз и отображается какой абсп, когда и какой мощности,а так же кто владелец.
далее уже десятое дело, где ее обрабатывать. думаю что некие простейшие пересчеты можно доверить самой игре(тогда при этом лог можно отключить). но еще раз повторюсь-возможность вывода инфы в сторонние проги обязательна
сделать такую фишку программерам будет несложно, и отключаться/включатся она будет безболезненно. поетому однозначно-маст хэв
------
по поводу обсчета на сервере или в сторонней проге.
некие простейшие просчеты можно делать на сервере.
однако сервер ни коим образом не сможет включить функционал командера хотябы потому что
а) написать свой функционал или внести некие изменения в "командер" будет краней сложно. это убьет онлайн
б)из технических соображений, в том числе ето значительно может осложнить защит, повысить ресурсоемкость, понизить качество игры и т.п.
поетому вывод такой:
в игру стоит включить минимальнф функционал(кик, бан,модерство, простенькая статистика может быть и т.п.), необходимый для простейшего мясного догфайта. все остальное- на откуп сторонним прогам.

все выше сказанное-всего лишь мое имхо

Насколько я понял, для такого решения специальные ключи не нужны....
Достаточно толкового программиста.
В таком случае остаётся уповать, что кто нить из программистов возьмётся за это дело.

Бомберы, они зверьки специфические. Появление целей не увеличит "в разы" их численность. Ибо лететь долго, куш, конечно не маленький, но появятся и те, кто будет баркапить свою тыловую цель. А с мелким калибром мало кто на бомберов ходит.

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

[sansanich54]

Если прикрутили респавн объектов, то вероятно, можно сделать респавн точек маршрута. Это, естественно, сугубо дилетантское мнение.

Простите , не совсем понял . Распавн - это что ?
С объектами пока вроде ничего не произошло . На "догфайт" теперь можно ставить всё , что движется . Ну ещё Пешка не хочет на "быстром редакторе" бомбы бросать с пологого пикирования ( на остальных картах - нормально штурмует ) . Всё .
Подскажите , если что не углядел .

[Charger]

В бытность мою птичником, бомберами становились в основном из-за плохой связи, и по религиозным соображениям Он-лайн хоронят примерно лет тридцать, а он всё ещё жив. Убивают он-лайн параноики, и гораздо быстрее и качественнее, чем читеры. Опять же птицы существую года с 1994, предтеча птиц, AirWarrior с 1986, и до сей поры продолжают оставаться достаточно интересным он-лайн действом. Интересно, когда появятся инструменты от разработчиков, для включения необходимого функционала в игру? Птичный сервер считает и выдаёт в лог достаточно параметров для полноценного освещения вылета. Почему этого не может/не должен делать другой сервер? А птичный сервер сделан в Миллениум. Прошло одиннадцать лет, и нормальный функционал сервера вдруг необходимо урезать? Зачем?

[mr_tank]

Простите , не совсем понял . Распавн - это что ?

Убитые зенитки (да и любые другие объекты) могут возрождаться. Конечно, возрождение объекта не то же самое что появление, и возможно, принципиально разное. Но терзают смутные сомнения, что если объект можно воссоздать в заранее заданной точке, то его можно создать в произвольной точке. А точка маршрута такой же объект.

--- Добавлено ---

Зачем?

затем, что нет нужды комплектовать каждый трактор бульдозерным отвалом, основываясь на том, что есть тракторы с бульдозерным отвалом. Не всем оно нужно, а исходный продукт усложняет.
Зачем прикручивать серверу логику, надо только средства, которые могут менять обстановку, а логику пропишут уже в коммандере.

[sansanich54]

Убитые зенитки (да и любые другие объекты) могут возрождаться. Конечно, возрождение объекта не то же самое что появление, и возможно, принципиально разное. Но терзают смутные сомнения, что если объект можно воссоздать в заранее заданной точке, то его можно создать в произвольной точке. А точка маршрута такой же объект.

Спасибо , понял .
Воссоздать в произвольной точке - но район воссоздания должен быть указан ?

[Charger]

затем, что нет нужды комплектовать каждый трактор бульдозерным отвалом, основываясь на том, что есть тракторы с бульдозерным отвалом. Не всем оно нужно, а исходный продукт усложняет.
Зачем прикручивать серверу логику, надо только средства, которые могут менять обстановку, а логику пропишут уже в коммандере.

Ага. И помимо настроек собственно сервера, разборки что там наколбасили разрабы именно этого командера и до кучи имеем зоопарк командеров, вместо вменяемого и расширяемого инструмента управления сервером. Командер должен быть один, но модульный и позволять управлять всеми возможностями сервера.

[Karabas-Barabas]

но район воссоздания должен быть указан ?

Конечно, только не район, а координата точки, где надо поставить требуемый объект.

--- Добавлено ---

Ага. И помимо настроек собственно сервера, разборки что там наколбасили разрабы именно этого командера и до кучи имеем зоопарк командеров, вместо вменяемого и расширяемого инструмента управления сервером. Командер должен быть один, но модульный и позволять управлять всеми возможностями сервера.

Что конкретно ты подразумеваешь под термином "командер"? Иначе нет предмета разговора.

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

Правила игры, т.е. логику войны или как угодно это назови, - управление игрой, с запросом и обработкой данных от текущей запущенной "арены", написать уже гораздо проще, и её напишут кто надо, на чем ему надо, вплоть до размещения её на отдельном сервере от самой игры, то же самое про отображение состояния "арены" - вэб интерфейс (что происходит с кем или чем происходит).

[sansanich54]

Конечно, только не район, а координата точки, где надо поставить требуемый объект.

Это понятно - воссоздать в заранее заданной точке . Но tank пишет о создании объекта в произвольной точке . Вот я и хочу понять степень этой "произвольности" .

[Karabas-Barabas]

Это понятно - воссоздать в заранее заданной точке . Но tank пишет о создании объекта в произвольной точке . Вот я и хочу понять степень этой "произвольности" .

Ну не совсем четко выразился, в произвольной - это значит в любой желаемой точке в пределах текущей карты, не по каким-то заданным заранее маркерам на карте, а вот просто где захотелось прямо вот сейчас, там и поставить, т.е. отправить серверу команду типа: координата Х, координата У, координата Зет, № или имя объекта.

П.С. Разумеется чтобы объекты ставить корректно, "установщик" должен уже владеть информацией (или иметь возможность её получить) о любой точке: вода-суша, рельеф (высота, наклон поверхности, тип грунта и т.п.), дорога-мост, лес-поле, город, наличии в точке какого-то объекта и т.д.

[sansanich54]

Достану и расстреляете ... Это сможет делать только хост ?

[ZloyPetrushkO]

Насколько я понял, для такого решения специальные ключи не нужны....
Достаточно толкового программиста.
В таком случае остаётся уповать, что кто нить из программистов возьмётся за это дело.

да тут даже толковый программист то может и не понадобиться)
я со своими кривыми навыками вижу ето так:

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

но тут однако нужно будет еще провести оптимизацию, как то выяснить на практике не вызывает ли это фризов; может стоит выводить не в евент лог а например в апи или девайслинк; куда лучше цепляться чтобы как можно меньше ресурсов прожрать ну и т.п...

сама идея то в общем то простая, но ее нужно обкатывать на практике
а триггерные площадные цели в итоге вообще не нужны будут. ибо наверняка обсчет попадания/непопадания в цель может жрать ресурсов больше, нежели просто вывод в эвентлог или девайслинк.

Птичный сервер считает и выдаёт в лог достаточно параметров для полноценного освещения вылета. Почему этого не может/не должен делать другой сервер? А птичный сервер сделан в Миллениум. Прошло одиннадцать лет, и нормальный функционал сервера вдруг необходимо урезать? Зачем?

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

таким образом, выходит первая причина-что банально на сервере есть не все данные что есть на компе игрока. и наоборот.


причина вторая. следует из первой. а именно-архитектура. понятно дело, что сервер в иле изначально был оптимизирован немного для др целей. в итоге-проигрыши производительности при введении в него такого функционала.
для сервера например требуется очень большая работа с базами данных. а архитектура такова, что нудные компоненты часто находятся в разных ветвях.кроме того отсуствуют утилиты работы с базами данных. ну и т.п.
я думаю не требуется объяснять почему спец. программа работающая с БД выполнит ту же работу гораздо быстрее

в третьих-чисто технические причины. например- та же ЧРТ. в суть ее углубляться не буду, ибо не надо нам пополнения читеров

ну и в четвертых. много ли было сделано вариантов сервера для ВБ с разным функционалом командера? я вот не слышал о таком. хотя наврное я просто не в теме

но в любом случае-зашитие функционала командера в бинарные файлы ето серьезно ограничивает простор для творчества командеров

Командер должен быть один, но модульный и позволять управлять всеми возможностями сервера.

это как бронежилет или автомат. он долэен быть один на все войска, но модульный и иметь все возможности. подходить как морской пехоте, так СПН, мотопехоте и десантникам

сделать единый модульный командер крайней сложно. недовольные будут всегда.
кроме того, как быть например с модным функционалом( а ведь в БоБе обещают поддержку модов!), если под него командер нельзя доработать?

[Q-8]

сама идея то в общем то простая, но ее нужно обкатывать на практике

Если будет чего обкатывать, то стучите в личку, с бобрами договорюсь.

[Charger]

Что конкретно ты подразумеваешь под термином "командер"? Иначе нет предмета разговора.

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

Правила игры, т.е. логику войны или как угодно это назови, - управление игрой, с запросом и обработкой данных от текущей запущенной "арены", написать уже гораздо проще, и её напишут кто надо, на чем ему надо, вплоть до размещения её на отдельном сервере от самой игры, то же самое про отображение состояния "арены" - вэб интерфейс (что происходит с кем или чем происходит).

Я имею ввиду, что командер, это модульное приложение к серверу. А необходимое количество модулей, как - ганстат, время "закрытия" цели до её респавна, количество игроков на арене, состояние наземки/конвоев, состояние плавсредств и конвоев из оных, состояние и дальность радаров, экономика, РПС(куда входит как исторически выверенный, так и сбалансированный варианты), плюс всё, что на сегодня в этой области есть, ДОЛЖНЫ регулироваться серверным приложением, с удобным и понятным интерфейсом с максимально гибкими настройками, желательно при этом, безальтернативным, но с возможностью добавления самописных модулей как статистики так и управления.