Alhimik

Что-то хрень какая-то а не прицел. Выглядит не серьезно совсем, нужно было или оставить квадратный или делать полный редизайн по типу того что было в сспшных роликах.
Не знаю, что некоторые тут находят. Сообщения по типу пол шестого несут смысловой нагрузки не больше чем (допустим) 50% армора, при этом мне (хотя я уверен, что не 1 такой, кто не пользуется механическими часами) придется задумываться, чтобы перевести в стандартные проценты.
В общем, изменение в негативную сторону, причем, казалось бы, такое маленькое и незначительно, а негатива у меня лично вызывает очень много.

новый варп крут, очень
пс шлейфы движков надеюсь отключаемые? никогда не нравились.

А то перепродадут франшизу в какой-нить варгейминг

А с чего ты взял что это пойдет игре во вред?  
Там несмотря на толпы обиженных(а на обиженных сами знаете что возят) проблем с онлайном не будет еще пару лет точно.
И новые проекты уже можно точно сказать что окупятся

А если по делу: У самого 2 ака уходят в непроплату один через 3 дня второй через месяц,решил дать еве 6-12 месяцев после чего вернусь посмотрю что изменится, а там уже решу окончательно. Я собсно давно еще писал что основная проблема в том что совершать ошибки еве нельзя, 1 ушедший человек это -2,3 аккаунта.
То как ева сейчас меняется меня радует, но этого мало игра уже устарела морально. Это чисто мое имхо но я бы на месте ссп заместо WoD делал-бы  EVE2, но это так на правах Кирила и корованов.

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

ДиректХ тут не при чем- семерка его ставит самостоятельно при установке(мой дистриб директа отказался ставиться на 7ку, сказав что все и так уже стоит)

Это не так, обновления DRX выходят каждый месяц то что идет с виндой устарело года на 2 уже. Достаточно скачать DRX с сайта и посмотреть сколько файлов он обновит(при условии что винда чистая).

У меня 8 гб от корсара с тайменгами 8-8-8-12. Вообще никаких проблем=)

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

"я нимагу паймать караблегиии хныыык" дубль 33.

С чего вдруг такая реакция?

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

И чем простимулирована такая идея?
Лучше бы чукча-писатель написал на кой ляд оно надо, отсутствие варпа в 0?

Опять таки мне лично тебе ответить? Или ответ уже данный в теме тебя таки устроит? посему таки да

Чукча писать,чукча не читать.

"я нимагу паймать караблегиии хныыык" дубль 33.

Чукча писать,чукча не читать.

Оригинал тут
Перепост отсюда


Многие игроки в EVE знают, что наша игра написана на языке программирования Python – если быть точнее, Stackless Python. Stackless ― это усовершенствованная версия интерпретатора, позволяющая пользоваться многими преимуществами многопоточного программирования. Но, тем не менее, «питон» остается «питоном», и нам приходится иметь дело с глобальной блокировкой интерпретатора (Global Interpreter Lock, также известной как «этот чертов GIL» или просто GIL).
GIL ограничивает доступ к интерпретатору (и всем соответствующим данным): в каждый конкретный момент времени обрабатывается лишь один поток. Поэтому хотя Stackless Python и обладает многими признаками «многопоточного» языка (такими как разделение задач, каналы, планировщики, совместная память, и т.д.), написанная на нем программа все равно способна обрабатывать лишь одну задачу за раз. Это похоже то, как работали некоторые многозадачные операционные системы в прошлом ― и такая схема позволяет гарантировать, что исполнение каждого потока не будет прервано в какой-то момент времени (за исключением тех случаев, когда поток нарушает принципы проблемы остановки). Это также позволяет нам исходить из многих предпосылок о глобальном состоянии игры при написании кода, что было бы невозможно, если бы мы использовали асинхронную логику и функции обратного вызова. По сути дела, большая часть логических блоков в коде нашей игры следуют принципам процедурной синхронной модели, что позволяет быстро и безболезненно вносить изменения в код.

Проблема заключается в том, что часть «фреймворка» в EVE Online написана на Python, и поэтому нам приходится использовать GIL. Это ограничение распространяется и на написанные на языке C модули, которым необходимо получать данные от интерпретатора Python.


Все задачи, работающие с Python, должны перед выполнением «получить» GIL;
программа, по сути дела, выполняется в один поток.
(прошу прощения за некрасивый график; я программист, а не художник)

Проще говоря: код, написанный на Stackless Python, исполняется так быстро, как позволяет самое быстрое ядро процессора. В случае четырех- или восьмиядерного процессора использоваться будет лишь одно ядро; впрочем, остальные могут использоваться для обработки других процессов. Это хорошо работает в тех случаях, когда эти процессы не сильно зависят от других компонентов системы, но не подходит для таких задач, как обработка действий игроков, находящихся в космосе или гуляющих по станциям.
Пока один процессор справляется со всей нагрузкой ― а во многих случаях это так и есть ― никаких проблем не возникает. Но не мне вам рассказывать, что в настоящий момент одного процессора уже не хватает для обработки больших боев, несмотря на то, что команда Gridlockи  другие разработчики выжимают из системы все возможное, оптимизируя код. В настоящее время процессоры не становятся быстрее ― увеличивается объем кэша и пропускная способность шины, но с точки зрения того, что необходимо нашей игре, их скорость не растет. Задача, которую нам предстоит решить в недалеком (и, возможно, в далеком) будущем ― обеспечить возможность использования кодом игры несколько процессоров одновременно.
В общем и целом, дальнейшее развитие многоядерных процессоров теоретически открывает интересные возможности перед EVE – кластер игры устроен таким образом, что при использовании процессоров с более чем 30-60 ядрами мы получим значительные преимущества по сравнению с текущей архитектурой. Но в настоящий момент перед нами стоит более достижимая задача ― сделать определенные элементы «фреймворка» (сетевое взаимодействие и процессы ввода/вывода данных) независимыми от GIL.
Эта проблема возникла не вчера: необходимость повышения быстродействия важных компонентов нашей игры (для которых не требуется использовать Python) назрела уже давно. CarbonIO – гигантский шаг в этом направлении.

CarbonIO ― естественное развитие StacklessIO. По сути дела это написанный с нуля «движок», при разработке которого перед нами стояла главная задача: сделать сетевой код ― и любой код, написанный на C++ ― полностью независимым от механизма GIL. Вторая часть этой задачи ― большое начинание, на реализацию которого ушел почти год.

Краткий экскурс в историю: предыдущим большим шагом на этом пути являлся механизм StacklessIO (http://www.eveonline...?a=blog&bid=584). Он позволил обрабатывать сетевые операции на уровне операционной системы и передавать результаты интерпретатору Python по мере необходимости.



stacklessIOпозволяет завершать обработку запросов Python, не прибегая к GIL


  CarbonIO ― это следующий этап развития этой системы. Многопоточный «движок», отвечающий за коммуникации, был полностью отделен от механизма GIL; он может отправлять и принимать данные без взаимодействия с интерпретатором Python.
  Это стоит повторить еще раз: система CarbonIO может отправлять и получать данные без взаимодействия с интерпретатором Python. Параллельно. В обход механизма GIL.
Когда через систему CarbonIO устанавливается соединение, немедленно вызывается функция WSARecv(), и начинается сбор данных. Эти данные расшифровываются, распаковываются и в несколько потоков собираются в пакеты; это происходит параллельно с работой интерпретатора Python. Затем эти пакеты помещаются в очередь, где они ждут вызова от Python.
Когда для работы написанного на Python кода требуется один из таких пакетов, в систему CarbonIO отправляется вызов ― и эти данные, скорее всего, уже там есть. Данные вынимаются из очереди и возвращаются в нее без участия механизма GIL – это происходит практически мгновенно. Вот первое преимущество, которое обеспечивает система CarbonIO – возможность осуществлять параллельное опережающее считывание.
Второе преимущество касается отправки данных. Специальный поток Python собирает и отправляет данные; при этом сжатие, шифрование, сбор их в пакеты и вызов функции WSASend() осуществляются в обход механизма GIL в другом потоке, и операционная система может запускать этот поток на другом процессоре. В принципе, это можно было делать и в рамках StacklessIO ― но это не имело бы никакого смысла без других изменений, которые мы реализовали.
Вернемся чуть-чуть назад. «Эти данные, скорее всего, там уже есть?» Хмм. Что, если создать функцию обратного вызова, которая позволяла бы модулю, написанному не на Python, получать эти данные без использования системы Machonet? Встречайте: система BlueNet.



Система CarbonIOпостоянно выполняет цикл recv-loopи может обращаться к написанным на С++ модулям без участия Python.


Система Machonet выполняет ряд важных функций ― маршрутизация, управление сессиями, постановка пакетов данных в очередь и их отправка; по сути дела, это «нервная система» EVE. Она написана на Python, поэтому все данные со всех узлов сервера EVE обязаны в какой-то момент проходить через GIL. Как бы быстро не исполнялся написанный на C++ модуль, его быстродействие все равно будет ограничено этой системой. Поэтому мы не приступали к оптимизации многих написанных на C++ элементов кода ― ведь любой выигрыш сводился бы на нет ограничениями, связанными с механизмом GIL и системой Machonet.

Но это осталось в прошлом.

Теперь написанный на C++ модуль может принимать и отправлять через систему BlueNet пакеты, для обработки которых механизм GIL не требуется. Это нововведение было реализовано для проекта Incarna― ведь для передвижения персонажей требуется передача больших объемов данных. Мы подсчитали, что при использовании старой системы Incarna буквально «положила» бы сервер Tranquility даже при средней длительности игрового «тика». BlueNet позволяет решить эту проблему, направляя сетевой трафик между написанными на C++ модулями (такими как физический «движок») в обход механизма GIL; эти данные не приходится дважды пропускать через систему Machonet, что позволяет добиться значительного выигрыша.
Как именно это работает? BlueNet хранит копию всех необходимых структур Machonet и добавляет ко всем пакетам маленький заголовок (8-10 байт), где содержится информация о маршрутизации. Когда система BlueNet принимает пакет, она может прочесть этот заголовок и направить пакет дальше ― на другой узел или на модуль C++, исполняемый на том же процессоре. Пересылка пакета осуществляется в обход механизма GIL; Machonet/Python никак в этом процессе не участвуют. Это значит, что наши прокси-серверы могут полностью параллельно обрабатывать пакеты BlueNet, вообще не прибегая к связанным с Python процессам. Насколько это эффективно? Мы пока не знаем, какое слово выбрать для того, чтобы описать уменьшение лага и нагрузки на процессоры в ряде случаев ― «потрясающе» или «невероятно». Серьезно ― мы сами не верим своим глазам.
В дополнение к описанному выше, при работе над CarbonIO мы реализовали ряд других нововведений; каждое из них незначительно повышает быстродействие системы, но все вместе они дают хороший результат. Некоторые из которых стоит упомянуть отдельно:

Группировка запросов

В рамках этой статьи сложно рассказать об этом нововведении, но, грубо говоря, система CarbonIO очень эффективно «группирует» запросы перед их обработкой. Для выполнения некоторых операций всегда требуется некоторое дополнительное время; это преимущественно касается сетевых протоколов, но применимо и к другим аспектам программирования. Это время можно сократить, «сгруппировав» эти операции. Например, в EVE и раньше группировались пакеты данных для отправки в рамках единого TCP/IP MTU, но CarbonIO позволяет группировать и другие операции. Хороший пример этого связан с работой механизма GIL.
При возникновении первого потока, обращающегося к механизму GIL, создается очередь; другие потоки добавляют соответствующие вызовы (wake-upcall) в ее конец. Когда GIL освобождается, первый поток очищает всю очередь без необходимости повторно отменять и получать GIL для каждого wake-upcall. Эта ситуация часто возникает при высокой нагрузке на сервер, и использование CarbonIO позволяет получить здесь значительное преимущество.

Интеграция openSSL

Механизм SSL в системе CarbonIO реализован с помощью протокола openSSL, который работает без участия механизма GIL ― вся маршрутизация осуществляется через CarbonIO с использованием так называемых «completion ports». Это позволит нам не только лучше защитить EVE от несанкционированного доступа, но и в перспективе перенести для удобства некоторые функции управления учетной записью непосредственно в игровой клиент.

Интеграция сжатия

CarbonIO осуществляет сжатие и распаковывание пакетов данных с помощью библиотек zlib и snappy; опять же, этот процесс не зависит от механизма GIL.


Полевые испытания

Данные, собранные за 24 часа работы типичного прокси-сервера игры (примерно 1600 пользователей в пиковый период), показывают, что использование CarbonIO позволяет значительно сократить нагрузку на процессор (как абсолютную, так и в расчете на одного пользователя). По мере роста нагрузки на сервер эффективность CarbonIO снижается ― влияние оптимизаций уступает место количеству обрабатываемых операций ― но все равно остается довольно высокой.


Нагрузка на CPUна одного пользователя за 24 часа




Нагрузка на CPU(в %) за 24 часа



На работу серверов, обрабатывающих звездные системы, CarbonIO влияет меньше ― ведь нагрузка на них связана преимущественно с кодом игры, а не с сетевым взаимодействием ― но и здесь нам удалось получить выигрыш в 8-10%.

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

Подводя итоги

Что это значит для сервера EVE? После внедрения системы CarbonIO мы сможем лучше использовать возможности современных процессоров ― это непосредственно касается и быстродействия игры. Чем меньше кода обрабатывается с использованием механизма GIL, тем эффективнее работает вся система. CarbonIO и BlueNet открывают перед нами двери в новый мир ― нам еще предстоит узнать, насколько мы сможем повысить быстродействие всей системы в целом, но можно смело сказать, что большой «затор» на этом пути устранен.



- CCP Curt

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

Я требую буста Дрейка! Т3Й!!

Лол вот кем кем а лоу ператегом(как в общем и нулевым) я вообще никогда небыл. Скорее уж наоборот иногда огребал от них.  
Искать скрытый смысл моей в моей идее не стоит, можете не верить но я ничего не получу как в общем и не потеряю.

Ну ладно, попытайся мне, как пилоту фрейтера, например, объяснить, ЗАЧЕМ эта новая фишка?

Чтобы твой корован могли ограбить.

посмотрите килборду ТСа и поймете чем вызвано данное предложение.

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

ТС отсыпь травы что ты куришь....
идея бред!

Да, я тоже люблю конструктив.

Какие то мобилки ларджовые получаеются, только с них еще отварпать можно, а приварпать нельзя. Нет смысла корёжить игровую мехнику лишь ради того, что бы некоторые индивидумы могли еще чаще сваливать от приварпывающих врагов. Где-то так.

А я вот утверждаю что данная механика почти в том же виде что я описал уже есть в игре(процентов на 95).  Так может некоторые индивиды не знают игровой механники?. Как то так   .

отменить варп в 0 и дать галам оптимал бластеров на клоз патроне 15 км, будет ок

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

ps переходы на личности доставляют.

Слишком много исключений: варп в ноль убрать, но алайнед-букмарки запретить, но при этом запретить не везде и не всем шипам.

Система бук тут вообще не причем. Варп в 0 просто прервется. Что до не всем шипам просто чтобы было интереснее, к слову условия и сейчас есть на тех же т3 шипах способных игнорировать бубули.  

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

Поправь меня если я ошибаюсь прыжки в 0 ввели не по геймплейным соображениям а только по тому что копирование 100500 букмарок 100500 игоков делало сервер несчастным.
Зачем вернуть?  Потому что это логично,  текущий варп слишком уж читерский слишком точный и быстрый это не свойственно ни фантастике не играм.

Какая практическая ценность

Просто на карте появятся своего рода укрытия занимать которые будет отчасти выгодно во всяком случае в 0 тебе на голову ничего не упадет.

Все помнят еву без варпа в 0? Идея проста - убрать его к чертям, а чтобы не спамили букмарками в центр крупных объектов(гейтов планет станций лун?) ) воткнуть спец мобилки большого рейнджа или даже скорее систему стац. плексов. Ибо убирать у человека возможность смотаться со станции нельзя.
Вообще можно даже добавить зависимость массы шипа и рейнжа на который он может придти.
Забавно выйдет у каждой планеты будет ренж варп в 35 км (у газовых гигантов 50    звезд 80 ) можно будет прятаться так сказать у планеты от приварпа в 0, лунами а точнее с посам хз возможно 20 км но это имхо много, возможно для посов сделать исключение и разрешить при варпе под поле варпать в 0.
Станции 15 гейты 10.  

Ах да нужен вброс    -     и т3 с антибубль системой и шатлы  начхать хотели   на  все это и варпают в 0 )))


PS юзал и поиск и тему c тем что уже предлагали не нашел

Veronika
Ну совсем запугивать незачем, никому он на рифтере не нужен будет, и уж точно никто не будет тратить время на наскан рифтера тем более в импе.
В игре есть 3 типа космоса
1.0 - 0.5 - империя относительно безопасный космос. Безопасность обеспечивает конкорд он уничтожит любой корабль открывший огонь по другому кораблю (только для игроков.) вот только он может не успеть спасти тебя, но гарантирует что твой обидчик тоже будет уничтожен.
0.4-0.1 лоу ничейная территория по сути тут тебя могут убить почти безнаказанно.
0.0  -  почти все нули поделены между альянсами игроков, почти все альянсы попытаются тебя убить как только увидят.
ВХ  -  скрытый космос, вообще нубу туда сложно попасть и почти нереально выбраться единственное место куда по нубству летать не стоит.

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

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

ДИЧ ЦСМ!

Печально.... Надеялся что не пройдет, теперь придется наедятся на благоразумие остального цсм

Что то бред какой то идет.... одни говорящие головы
Нвидиа презентация ппц,  еще майкрософт не хватало....