199 ответов в теме

[Korvin]

глобальная дискуссия вынесена отсюда

Товарищи, а почему вы считаете что бонусы в гриде невозможны без переделки системы грида? ССР могут сделать очень просто - сделать для бонусников рейндж, в котором бонусы будут работать. Т.е. чтобы словить бонус с калимора, нужно от этого самого калимора находиться на расстоянии не более Х км (100, например) и быть при этом в одном с ним флоте.

А теперь подумай, как при этом быть с бонусниками на винге/скваде, при этом если бонусы разные по разным сквадам. Что будет если допустим бонусник винга в 100км, а сквада вне ренжа и т.п.

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

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

Сообщение отредактировал Clancy: 07 November 2012 - 16:15

[DanGion]

А теперь подумай, как при этом быть с бонусниками на винге/скваде, при этом если бонусы разные по разным сквадам. Что будет если допустим бонусник винга в 100км, а сквада вне ренжа и т.п.

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

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

А кто-то мешает?

Расчитываем все комбинации 1 раз (как и сейчас)

а потом if-else по уже готовым значеням. Нагрузка возрастет, но на пренебрежительно малую величину.

А еще лучше switch-case так еще "быстрее" будет.

Сообщение отредактировал DanGion: 07 November 2012 - 10:20

[Delcheff]

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

Проверки же только при расчете характеристик будут.Чем это принципиально отличается от проверки находится ли пилот в той же системе что и бонусник или нет?

Сообщение отредактировал Delcheff: 07 November 2012 - 10:21

[Korvin]

А кто-то мешает?

Расчитываем все комбинации 1 раз (как и сейчас)

а потом if-else по уже готовым значеням. Нагрузка возрастет, но на пренебрежительно малую величину.

Какой if-else? Корабль движется. Изменения скилов статсов происходят по евенту, то-есть чтоб бонусы пропадали/появлялись - этот if-else должен проверяться по таймеру в виде евента с циклом раз в 1-5 секунд постоянно.

объектно ориентированное программирование сейчас в школах хоть в основе дают?

Чем это принципиально отличается от проверки находится ли пилот в той же системе что и бонусник или нет?

Тем, что такую проверку достаточно провести 1 раз - при смене сессии.

Сообщение отредактировал Korvin: 07 November 2012 - 10:22

[Midael]

А вот это мысль! Но как привязать радиус шара к гриду?

Также как это сделано с мобилами и бублями?

[DanGion]

Какой if-else? Корабль движется. Изменения скилов статсов происходят по евенту, то-есть чтоб бонусы пропадали/появлялись - этот if-else должен проверяться по таймеру в виде евента с циклом раз в 1-5 секунд постоянно.

объектно ориентированное программирование сейчас в школах хоть в основе дают?

ну понеслось.

while (in_greed())
{
switch (bonus)
case
...
default
}

где in_greed возврашающая true, если вы с бонусником в одном гриде. Приэтом можно просто проверять расстояние.
если расстояние до бонусника меньше-равно X, то в гриде, если меньше то возвращаем false.

Корвин, мне тебе весь кусок кода писать чтоли (а это часть клиента ИВ реализовывать). Или ты таки прочитаешь про ПСЕВДОКОД. Я написал концепцию, а не реализацию. Ничего не мешает использовать данну концепцию в рамках ООП.

Чем моя концепция отличается от концепции работы мобил и бублей,, Корвин?

Также как это сделано с мобилами и бублями?

Кстати да.

Сообщение отредактировал DanGion: 07 November 2012 - 10:32

[Korvin]

Также как это сделано с мобилами и бублями?

ну понеслось.

while (in_greed())
{
switch (bonus)
case
...
default
}

где in_greed возврашающая true, если вы с бонусником в одном гриде. Приэтом можно просто проверять расстояние.
если расстояние до бонусника меньше-равно X, то в гриде, если меньше то возвращаем false.

Корвин, мне тебе весь кусок кода писать чтоли (а это часть клиента ИВ реализовывать). Или ты таки прочитаешь про ПСЕВДОКОД. Я написал концепцию, а не реализацию. Ничего не мешает использовать данну концепцию в рамках ООП.

Чем моя концепция отличается от концепции работы мобил и бублей,, Корвин?

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

То-есть проверяется 1 раз при нажатии варпа и все.

Теперь по поводу "кода".
while (in_greed()) - это что, цикл? То-есть у тебя проверка происходит циклически? С какой периодичностью?

[Delcheff]

Тем, что такую проверку достаточно провести 1 раз - при смене сессии.

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

Как оно на самом деле я хз.

Теперь по поводу "кода".
while (in_greed()) - это что, цикл? То-есть у тебя проверка происходит циклически? С какой периодичностью?

Сообщение отредактировал Delcheff: 07 November 2012 - 10:49

[Korvin]

Я вот предполагаю, что проверка происходит именно при расчете характеристик, а не меняет характеристики с какой то переодичностью.

Ты не предполагай, ты проверь.

Бонусы - это как и модули, они расчитываются 1 раз по евенту, а не постоянно.
Евент соответственно - смена сессии для пилота, смена сессии (включая логоф) бонусника в цепи, нажатие активации модуля линка бонусника.

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

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

Это тебе для общего развития.

Сообщение отредактировал Korvin: 07 November 2012 - 11:04

[Denadan]

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

это все привязывается к смене сессии для бонусника.

зы. слоупок.жепег

Сообщение отредактировал Denadan: 07 November 2012 - 11:07

[DanGion]

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

То-есть проверяется 1 раз при нажатии варпа и все.

Теперь по поводу "кода".
while (in_greed()) - это что, цикл? То-есть у тебя проверка происходит циклически? С какой периодичностью?

Тыж сам запрашивал циклическую проверку нет? Для тебя знатока школьного ООП расписываю букавами:

Отлавливаем событие входа в грид
Пока в гриде проверяем бонусы
{
Выбираем нужную комбинацию бонусов (из заранее вычисленных возможных)
ждем период времени
}
Вышли из грида сбрасываем бонусы на ноль

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

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

[Korvin]

Тыж сам запрашивал циклическую проверку нет? Для тебя знатока школьного ООП расписываю букавами:

Отлавливаем событие входа в грид
Пока в гриде проверяем бонусы
{
Выбираем нужную комбинацию бонусов (из заранее вычисленных возможных)
ждем период времени
}
Вышли из грида сбрасываем бонусы на ноль

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

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

Правильно, ты таким образом рассчитываешь бонусы в гриде. (евент - смена грида).
Ренж ты при этом не считаешь.

А что-бы ренж учитывать - быдлокодингом как?

[Der Alte]

В гриде - еще хоть как-то технически реально (смена грида - тоже евент теоретически)

Ну что вы спорите о теории программирования

На первой же странице вполне адекватно разобрались -- с существующей механикой грида "корабли в 5 км друг от друга отделены невидимой стеночкой и находятся в разных гридах" о бонусах "на грид" не стоит даже и вспоминать.

[Korvin]

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

абы не сломали слепня...

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

[brammator]

Бонусы - это как и модули, они расчитываются 1 раз по евенту, а не постоянно.
Евент соответственно - смена сессии для пилота, смена сессии (включая логоф) бонусника в цепи, нажатие активации модуля линка бонусника.

Забыл ещё превышение лимита для флит/сквад/вингкомов в цепи. Не все с 5-5-5 лидершипом летают.

Но проблем с рассчётом по смене грида я всё равно не вижу, это тот же эвент. Вот если ренж ввести, тогда да, ежесекундная проверка и рассылка смены состояния.

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

[Naimas Alvares]

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

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

[Delcheff]

Ты не предполагай, ты проверь.

Расскажи как ты проверил. Я хоть научусь.

Бонусы - это как и модули, они расчитываются 1 раз по евенту, а не постоянно.

По какому ивенту расчитывается модификация модулей? Откуда предположение, что тригером является отключение модулей, а не учет их активности при расчете, например, урона?

Евент соответственно - смена сессии для пилота, смена сессии (включая логоф) бонусника в цепи, нажатие активации модуля линка бонусника.

В чем цель слушать 5-6 тригерров, если можно слушать 1, который и так слушается?

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

Ты ошибаешся, думая, что перерасчет нужно проводить или постоянно или при тригеррах. Можно просто считать по условиям, нет?

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

Какой нихренасебе? Грубая прикидка дает для 1000 стреляющих маэльстормов в гриде при наличии 3 гипотетических бонусников на урон примерно 120 проверок в секунду при неизменном количестве трафика.

Это без ухищрений, просто if then else. Что уж говорить о нормальном коде, который явно эффективнее.

Сообщение отредактировал Delcheff: 07 November 2012 - 11:25

[Korvin]

Ты ошибаешся, думая, что перерасчет нужно проводить или постоянно или при тригеррах. Можно просто считать по условиям, нет?

Эммм... можно мне объяснить - в чем разница между "перерасчет" и "просто считать"?

[DanGion]

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

Я тебе уже расписал, что расчеты делаются 1 раз (как сейчас посути) и потом идет обращение к уже готовым даннам. Это раз.
Два. Грид в моем примере можно считать, как растояние до бонусника.
Три. ВСе эти клиенты и так обращаются к серверу.
Четыре. ????
Пять. Профит!

[Korvin]

Я тебе уже расписал, что расчеты делаются 1 раз (как сейчас посути) и потом идет обращение к уже готовым даннам. Это раз.

Это не так.

Два. Грид в моем примере можно считать, как растояние до бонусника.

Грид устроен по другому.

Три. ВСе эти клиенты и так обращаются к серверу.

И чем реже - тем лучше и серверу и клиентам.

Четыре. ????

Хороший аргумент !!!!

Пять. Профит!

Где?