50 ответов в теме

[St1'n'Gear]

вот такую вещь сейчас увидел вернувшись за комп

Прикрепленные изображения

• 

[Caliber .50]

Я не был на русском клиенте с последнего "обновления" локализации, но... мне одному кажется, что содержимое скрина выше написано излишне правильно? Ждём девблога про адекватную локализацию?

[Kachey]

Я не был на русском клиенте с последнего "обновления" локализации, но... мне одному кажется, что содержимое скрина выше написано излишне правильно? Ждём девблога про адекватную локализацию?

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

[kezman77]

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

[Edgardus]

Пожалуйста, сохраняйте спокойствие.
За вами уже выехали.
ничего ипичнее я еще не видел. ппц. ССР как обычно отжигает с переводом. записатся чтоль в ТТ?

[EVEPlayer]

"Ужасный, ужасный лаг" - это новый мем, не иначе

Не новый.

[backtrace]

А я не знал, что исландцы родственны индийцам (код неимоверно палит).

Сообщение отредактировал backtrace: 13 December 2010 - 2:49

[January]

А хорошо. С юмором. Типа: "Почему бы Вам не выпить Боржоми, раз почки всё равно уже отвалились."

[Anastasy]

Мне вот больше интересно, что там за отладчик запросов, что-то новое или старый добрый монитор ?

[radnor]

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

[Tester128]

Я таки решил добавить к переводу часть ответов на вопросы из соответствующих топиков на оффоруме. Сразу предупреждаю что это не все ответы а только те которые я посчитал интересными и это не дословный перевод ответов, а передача общего смысла, собранного зачастую из нескольких ответов в разных топиках. Отвечали CCP Explorer и CCP Masterplan.

В. Когда клиенту посылается информация о ракетах и объектах вообще, что делает сам клиент?

О. Клиент получает информацию о том что ракета запущена (появился новый шар) и в кого она запущена. Дальше клиент сам рассчитывает и отображает полет ракеты. Второе обновление информации от сервера приходит, когда ракета уничтожена (попала в цель, сбита дефендером, сбита смартой, кончилось время полета). Однако на сервере ракеты как объекты еще занимают часть времени физической симуляции. Однако основные затраты времени уходят не на саму симуляцию, а на добавление/уничтожение объектов. Турельное оружие требует время только на рассчет урона с учетом трекинга. Цифры трекинга и скоростей которые можно увидеть в овервью рассчитывает сам клиент на основе данных о положении и скорости объектов в гриде.

В. EVE действительно работает со скоростью 1 герц?

О. Да, EVE тикает со скоростью 1 герц и так было с самого начала. Именно поэтому прямое управление кораблем с помошью, к примеру, джойстика, в EVE работать не будет. Если посмотреть на другие игры, от шутеров до онлайн ммо, то существует примерно обратная пропорциональность между максимальным числом игроков и тактовой частотой физического движка. Мы планируем повысить частоту EVE в Incarna и сейчас работаем над рефакторингом сетевого кода.

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

О. Потому что мы не можем доверять клиенту и должны давать ему только необходимую информацию.

В. Стоит ли объединять ланчеры в группы

О. Да, это действительно заметно снижает затраты процессорного времени на обсчет ракет и мы очень рекомендуем это делать.

В. О переработке ракет из объектов в эффекты

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

В. О переделке SendToClients под настоящий miltuthread

О. Мы не отказываемся от такой возможности. В принципе, у нас есть механизмы бродкаста в которых можно было бы это реализовать.

В. О Destiny на C/C++?

О. Destiny написана на C++. Python и C++ могут прекрасно работать вместе и у нас есть возможность делать первичные объекты (underlying object) родными объектами (native object) в обоих языках одновременно. В EVE также есть несколько других подсистем, написанных на C++ ( или на смеси Python/C++). Наиболее известная из них – графический движок Trinity.

В. Замедление времени/увеличение длительности тика при лагах

О. Мы обдумывали такую возможность, а также несколько других достаточно масштабных вариантов решения проблемы лагов. Часть из них мы отбросили, часть осталась в качестве возможных кандидатов, часть мы даже реализовали в качестве прототипов.
Что касается непосредственно варианта с замедлением времени – возникает масса вопросов что именно мы должны при этом замедлять (скорость регенерации щита, скорость стрельбы, движение, тренировку скилов, время жизни ордеров в маркете, таймеры агрессии, циклы сиджа и триажа?) Когда у нас внезапно появляется две части игры, работающие с разной скоростью, приходится принимать во внимание абсолютно все действия, в которых както фигурирует время. Что делать с другими солнечными системами, живущими на той же ноде – надо ли их тоже замедлять? Если нет, то надо внимательно следить за всеми запросами к ноде, потому что они могут опрашивать какойто таймер. Я не хочу сказать что это невозможно в принципе, но задача явно требует намного более вдумчивого анализа. Это какбы намекает что мы серьезно рассматривали такую возможность

В. Сколько времени занимают операции опроса даных о шарах в пузыре? Можно ли часть данных получать асинхронно?

О. Каждый запрос сам по себе занимает не так много времени, проблема возникает когда мы должны сделать много запросов в течении одного тика. Именно поэтому я добавил кэширование. Если нам надо запросить данные об одном шаре для многих наблюдателей, то только первый запрос приведет к выполнению полной процедуры рассчета и обработки запроса, остальные запросы будут братьь готовые данные из кэша. Эффект особенно хорошо заметен когда один флот наварпывает в грид к другому флоту. В таких ситуациях я наблюдал соотношение попаданий/промахов по кэшу до 50,000:1.

В. Для SinglecastByClientID это именно нагрузка на CPU или сетевые задержки при передаче данных?

О. SinglecastByClientID это именно нагрузка на CPU при сериализации и адресовании данных. Уменьшение этой нагрузки есть у нас в списке задач. Сами операции ввода/вывода делаются stacklessIO асинхронно.

В. Используется ли новый профайлер разработчиками GUI (например для оптимизации работы овера в больших флотах)?

О. Сосбтвенно, Telemetry интегрировали в клиент именно для этого. Но когда мы ее увидели, то потребовали поставить ее и на сервер "WANT ON SERVERS NOW PLEASE!"

В. Можно ли залочить корабль (использующий мвд+клоаку) в ту же секунду/тик, в которую я по нему контрол-щелкнул с заранее активированными дизом/сетками/пушками?

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

В. Допустим у меня есть пушка которая стреляет раз в 4.2 секунды с 3 дамагмодами и раз в 3.95 секунды с 4 дамагмодами, как это сочетается со скоростью работы сервера в 1 герц?

Активация модулей обрабатывается другой подсистемой под названием Dogma. У нее нет фиксированной тактовой частоты как у Destiny -- Dogma просто запускается так часто как может и старается обработать столько эффектов, сколько получится за разумное время. Эффекты работы Dogma могут иметь последствия вроде добавления ракет в список объектов. Тогда на следующем тике Destiny обнаружит появление нового объекта и проведет необходимые операции по добавлению/удалению объектов и оповещении об этом клиентов.
Так что хотя новая ракета может появляться в космосе только раз в секунду, времена работы модулей все равно будут обсчитываться с необходимой точностью до долей секунды (по крайней мере, пока нет лагов).

В. Последняя информация о лагах говорит что можно ожидать нормальной работы сервера при количестве участников около 600. Это для реинфорснутой ноды или нет. И что такое вообще реинфорснутая нода?

О. Эта цифра дана для реинфорснутой ноды. То же самое можно ожидать для обычной ноды при условии, что все остальные обсчитывающиеся на ней системы пусты. Но для обычной ноды достаточно сложно указать лимит участников, поскольку неизвестно что будет происходить в других находящихся на ней системах. Над анный момент цифра 600 основана на графиках загрузки, обратной связи от игроков, симуляциях и анализе. Определить ”качество игры” в какихто величинах довольно сложно. Но мы пытаемся разработать какуюто объективную величину, которая позволит его оценить. Например, ”сколько модулей активируется на ноде” или ”задержка активации модуля”. В зависимости, насколько они будут коррелировать с впечатлениями игроков, мы возможно в дальгнейшем даже будем публиковать такую информацию. Но пока все это находится в стадии эксперимента.
Реинфорснутая нода означает, что на 1 процессоре обсчитывается 1 солнечная система. Каждый блейд в составе кластера транквилити содержит 4 процессора (и 32 Гб памяти), так что на одном блейде работает 4 ноды.

Сообщение отредактировал Tester128: 13 December 2010 - 19:38

[January]

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

[CHoh]

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

[January]

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

Допускаю, что в девблоге просто не описана причина почему фича была сделана опциональной, и допускаю, что причина эта очень веская. Но мне что-то в голову ничего не приходит.

[Mauller]

Тестеру зачот, там действительно на форумах ССП еще много интересных коментов постит.

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

Я причем первым делом подумал, что у них один и тот же объект каждый раз сериализуется на каждого клинта, которому нужно выслать апдейт, думал "НУ НЕУЖЕЛИ!?". Оказалось так и есть.
Ладно в начале проекта действительно на оптимизацию забивается, но сейчас.. Сколько времени уже прошло с тех пор, как народ впервые столкнулся с флитолагодромами?
А они только сейчас додумались залезть в код Destiny, которая тупо по логике должна одной из первых влиять на производительность и отклик.
Мало того, додумались залезть, по их собственным словам, они лишь после того как GUI-команда показала им (Gridlock) новую тулзень, графически отображающую низкоуровневые внутренности (Telemetry).

Так то. Радует одно, они наконец-то нащупали направление и приступили к продуктивной работе. Сколько у них там еще этого псевдокода и сколько всего можно наоптимизировать остается только гадать.

[Yolkree]

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

Допускаю, что в девблоге просто не описана причина почему фича была сделана опциональной, и допускаю, что причина эта очень веская. Но мне что-то в голову ничего не приходит.

В лагодромах участвует малая часть населения евы, за пределами этой нулевой вакханалии есть огромное кол-во юзверей которые испытали бы просто лютый баттхерт от того что игра не даёт им стрельнуть во-о-он в тот крестик одной ракетницей, а делает целый залп со всей батареии дорогущими КН ракетками

[January]

Как вариант. Хотя у меня аргумент есть, и ты его знаешь - Кариберы должны страдать!

[reiser]

Tester128, повесь ссылку на Q&A в конце первого топика, пожалуйста. И продолжай переводить ответы ССР - Инсмазер и CJ тебя не забудет!

[JesDarkJewel]

Tester128, повесь ссылку на Q&A в конце первого топика, пожалуйста. И продолжай переводить ответы ССР - Инсмазер и CJ тебя не забудет!

Скидываемся по 2 ляма на кошель Тестеру за перевод?

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

Сообщение отредактировал JesDarkJewel: 14 December 2010 - 6:14

[vhl]

Мне по-прежнему непонятен смысл опциональности фичи

В смысле? Ты не знаешь зачем дана возможность группировать пушки в несколько групп, а не все в одну? Спроси у Фона: http://forum.eve-ru....hp?showuser=850, посмотри его мувики, поймешь.