Вид для печати
Бомберы, они зверьки специфические. Появление целей не увеличит "в разы" их численность. Ибо лететь долго, куш, конечно не маленький, но появятся и те, кто будет баркапить свою тыловую цель. А с мелким калибром мало кто на бомберов ходит.Цитата:
Сообщение от Q-8
Если прикрутили респавн объектов, то вероятно, можно сделать респавн точек маршрута. Это, естественно, сугубо дилетантское мнение.Цитата:
Сообщение от sansanich54
Насколько я понял, для такого решения специальные ключи не нужны....Цитата:
Сообщение от ZloyPetrushkO
Достаточно толкового программиста.
В таком случае остаётся уповать, что кто нить из программистов возьмётся за это дело.:)
Думаю что для настоящего бобра расстояние не помеха, было бы ради чего туда тащиться.Цитата:
Сообщение от Charger
Прокладка курса тоже дело занятное, особенно если этот курс приходиться прокладывать по приборам....
Простите , не совсем понял . Распавн - это что ?Цитата:
Сообщение от mr_tank
С объектами пока вроде ничего не произошло . На "догфайт" теперь можно ставить всё , что движется . Ну ещё Пешка не хочет на "быстром редакторе" бомбы бросать с пологого пикирования ( на остальных картах - нормально штурмует ) . Всё .
Подскажите , если что не углядел .
В бытность мою птичником, бомберами становились в основном из-за плохой связи, и по религиозным соображениям :) Он-лайн хоронят примерно лет тридцать, а он всё ещё жив. Убивают он-лайн параноики, и гораздо быстрее и качественнее, чем читеры. Опять же птицы существую года с 1994, предтеча птиц, AirWarrior с 1986, и до сей поры продолжают оставаться достаточно интересным он-лайн действом. Интересно, когда появятся инструменты от разработчиков, для включения необходимого функционала в игру? Птичный сервер считает и выдаёт в лог достаточно параметров для полноценного освещения вылета. Почему этого не может/не должен делать другой сервер? А птичный сервер сделан в Миллениум. Прошло одиннадцать лет, и нормальный функционал сервера вдруг необходимо урезать? Зачем?
Убитые зенитки (да и любые другие объекты) могут возрождаться. Конечно, возрождение объекта не то же самое что появление, и возможно, принципиально разное. Но терзают смутные сомнения, что если объект можно воссоздать в заранее заданной точке, то его можно создать в произвольной точке. А точка маршрута такой же объект.Цитата:
Сообщение от sansanich54
--- Добавлено ---
затем, что нет нужды комплектовать каждый трактор бульдозерным отвалом, основываясь на том, что есть тракторы с бульдозерным отвалом. Не всем оно нужно, а исходный продукт усложняет.Цитата:
Сообщение от Charger
Зачем прикручивать серверу логику, надо только средства, которые могут менять обстановку, а логику пропишут уже в коммандере.
Спасибо , понял .Цитата:
Сообщение от mr_tank
Воссоздать в произвольной точке - но район воссоздания должен быть указан ?
Ага. И помимо настроек собственно сервера, разборки что там наколбасили разрабы именно этого командера и до кучи имеем зоопарк командеров, вместо вменяемого и расширяемого инструмента управления сервером. :) Командер должен быть один, но модульный и позволять управлять всеми возможностями сервера.Цитата:
Сообщение от mr_tank
Конечно, только не район, а координата точки, где надо поставить требуемый объект.Цитата:
Сообщение от sansanich54
--- Добавлено ---
Что конкретно ты подразумеваешь под термином "командер"? Иначе нет предмета разговора.Цитата:
Сообщение от Charger
На самом деле надо только чтобы сервер умел запускать "арену", отдавать максимально возможное количество информации (в идеале, что в общем-то вполне возможно, всю информацию о происходящем в игре вообще) и принимать команды - загружать необходимые настройки и конфигурацию "арены", через нормальный АПИ, а не как это сейчас в Иле реализовано.
Правила игры, т.е. логику войны или как угодно это назови, - управление игрой, с запросом и обработкой данных от текущей запущенной "арены", написать уже гораздо проще, и её напишут кто надо, на чем ему надо, вплоть до размещения её на отдельном сервере от самой игры, то же самое про отображение состояния "арены" - вэб интерфейс (что происходит с кем или чем происходит).
Это понятно - воссоздать в заранее заданной точке . Но tank пишет о создании объекта в произвольной точке . Вот я и хочу понять степень этой "произвольности" .Цитата:
Сообщение от Karabas-Barabas
Ну не совсем четко выразился, в произвольной - это значит в любой желаемой точке в пределах текущей карты, не по каким-то заданным заранее маркерам на карте, а вот просто где захотелось прямо вот сейчас, там и поставить, т.е. отправить серверу команду типа: координата Х, координата У, координата Зет, № или имя объекта.Цитата:
Сообщение от sansanich54
П.С. Разумеется чтобы объекты ставить корректно, "установщик" должен уже владеть информацией (или иметь возможность её получить) о любой точке: вода-суша, рельеф (высота, наклон поверхности, тип грунта и т.п.), дорога-мост, лес-поле, город, наличии в точке какого-то объекта и т.д.
Достану и расстреляете ... Это сможет делать только хост ?
да тут даже толковый программист то может и не понадобиться)Цитата:
Сообщение от Q-8
я со своими кривыми навыками вижу ето так:
берем общий метод взрыва бомбы, вносим туда изменения что при определенной настройке сервера вносить информацию в эвент лог например. и все =)
но тут однако нужно будет еще провести оптимизацию, как то выяснить на практике не вызывает ли это фризов; может стоит выводить не в евент лог а например в апи или девайслинк; куда лучше цепляться чтобы как можно меньше ресурсов прожрать ну и т.п...
сама идея то в общем то простая, но ее нужно обкатывать на практике :)
а триггерные площадные цели в итоге вообще не нужны будут. ибо наверняка обсчет попадания/непопадания в цель может жрать ресурсов больше, нежели просто вывод в эвентлог или девайслинк.
я не ковырял в серверную часть, но думаю все дело в архитектуре и организации передачи даных.Цитата:
Сообщение от Charger
дело в том, что в иле все таки несколько большая нагрузка как в плане математики, так и остальных аспектов. в итоге объем вычислений больше, т.е. необходимо экономить ресурсы.
кроме того, объем данных так же достаточно велик.
поетому в иле вводить оптимизация( и ето кстати совершенно логично). в итоге вычисления распределены. т.е. часть передается по сети, часть довычисляется на месте.
таким образом, выходит первая причина-что банально на сервере есть не все данные что есть на компе игрока. и наоборот.
причина вторая. следует из первой. а именно-архитектура. понятно дело, что сервер в иле изначально был оптимизирован немного для др целей. в итоге-проигрыши производительности при введении в него такого функционала.
для сервера например требуется очень большая работа с базами данных. а архитектура такова, что нудные компоненты часто находятся в разных ветвях.кроме того отсуствуют утилиты работы с базами данных. ну и т.п.
я думаю не требуется объяснять почему спец. программа работающая с БД выполнит ту же работу гораздо быстрее :)
в третьих-чисто технические причины. например- та же ЧРТ. в суть ее углубляться не буду, ибо не надо нам пополнения читеров :)
ну и в четвертых. много ли было сделано вариантов сервера для ВБ с разным функционалом командера? я вот не слышал о таком. хотя наврное я просто не в теме :)
но в любом случае-зашитие функционала командера в бинарные файлы ето серьезно ограничивает простор для творчества командеров :)
это как бронежилет или автомат. он долэен быть один на все войска, но модульный и иметь все возможности. подходить как морской пехоте, так СПН, мотопехоте и десантникам :)Цитата:
Сообщение от Charger
сделать единый модульный командер крайней сложно. недовольные будут всегда.
кроме того, как быть например с модным функционалом( а ведь в БоБе обещают поддержку модов!), если под него командер нельзя доработать?
Если будет чего обкатывать, то стучите в личку, с бобрами договорюсь.Цитата:
Сообщение от ZloyPetrushkO
Я имею ввиду, что командер, это модульное приложение к серверу. А необходимое количество модулей, как - ганстат, время "закрытия" цели до её респавна, количество игроков на арене, состояние наземки/конвоев, состояние плавсредств и конвоев из оных, состояние и дальность радаров, экономика, РПС(куда входит как исторически выверенный, так и сбалансированный варианты), плюс всё, что на сегодня в этой области есть, ДОЛЖНЫ регулироваться серверным приложением, с удобным и понятным интерфейсом с максимально гибкими настройками, желательно при этом, безальтернативным, но с возможностью добавления самописных модулей как статистики так и управления.Цитата:
Сообщение от Karabas-Barabas