Новый проект для всех виртуальных пилотов.

Цитата:

---

Сообщение от trabla

thread это хорошо, и он там наверняка есть. Но доступ к данным сцены должен быть синхронизирован и тут хоть 100 threads запускай, всё равно только один данные сцены будет апдейтить и при этом thread рендерера не сможет их использовать до окончания апдейта. Я не говорю о приёме пакетов из сети, я говорил об их обработке.

Я не говорил о том что там что-то неправильно, а тем более никого не обвинял в том, что он чего-то незнает или не умеет :) . Просто, я описал предполагаемую причину фризов. Причём, я указал, что решение не может быть абсолютным и может являться только компромиссом.

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

---

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

Но так никто не делает, все нормальные игроделы применяют такую архитектуру:
есть тред "расчета и отображения картинки на экране"
есть локальный массив параметров в этом треде

есть тред "обмена с сетью"
есть локальный массив параметров в этом треде

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

Цитата:

---

Сообщение от pakman

Побойся бога трабла! Нет в этом никакой данности. Одно дело, если расшифровка сетевого протокола занимает столько процессорного времени, что ФПС падает. Но когда становятся заметными глазу замирания картинки - это совершенно явная ОШИБКА.

---

pakman, не о сети я говорил. Читай пост выше :) .
По моим наблюдениям фриз происходит в моменты, гогда сервер доставляет много информации. Подозреваю, что львиная доля её относится именно к картинке(содержимому 3D сцены). А вносятся изменения в сцену с высшим приоритетом, чем сцена отрисовывается. И поскольку изменений просто много, тои задержка отрисовки начинает зависеть от количества принятых изменений, а не от сети и т.д.
Такое вот моё IMHO.

P.S. ветка, кажется, стала о фризах, а не о новом проекте. Надо, наверное остановиться. Причину, всё равно, знают только разработчики.

Цитата:

---

Сообщение от operok

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

---

Я не говорил о том что thread обмена с сетью блокирует thread отрисовки. Я сказал что "внесение изменений в сцену" блокирует отрисовку.

Цитата:

---

Сообщение от operok

Но так никто не делает, все нормальные игроделы применяют такую архитектуру:
есть тред "расчета и отображения картинки на экране"
есть локальный массив параметров в этом треде

есть тред "обмена с сетью"
есть локальный массив параметров в этом треде

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

---

Так делают не только игроделы :)

Цитата:

---

Сообщение от tugarin

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

Второе плечо - это прохождение сигнала от сервера до локального игрока. Если в этом плече происходит замирание сигнала (потеря пакетов), то мы наблюдаем фриз. Это искусственное торможение картинки при отсутствии сигнала от сервера. Это как бы защита от читеров, не уверен, что оправданная.

---

По моему, что-то тут в вашем объяснении не так, вот мое:
Если у игрока все нормально с приемом, но передачи на сервер нет, то фриз у игрока, а на сервере лаг.
Если все нормально с передачей на сервер, но нет приема, то лагает всех игроков у вас, а на сервере вы летите нормально, фриза нет.

Было у меня вот такое на ГТ1: Лечу, вдруг смотрю все полетели в стороны, глянул на модем, а приема-то нет. Полетал неного, кикнул сервак, в стате диско.
Следующий раз в такой ситуации я просто прыгнул, в стате записали прыгнул.

ПыСы: Пока нашел время написать пост, тут уже столько накатали... %)

Цитата:

---

Сообщение от trabla

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

---

Что конкретно в онлайн нельзя предугадать и предвидеть? Чем так уж сильно различаются самолёт за горизонтом в оффлайне и онлайне? В оффе компьютеру приходится думать ещё и за того парня, который бот. И за зенитки, и за базар. Ей богу, это не сопоставимо с простой раскладкой по полочкам данных, прибывающих из сети.

Цитата:

---

Сообщение от pakman

А заодно эта идея низводит разработчиков до уровня недоразвитых ламеров. Так что давай отбросим её.
Ожидать опаздавший пакет, что бы верно отобразить опаздавшее событие - абсурд.

Но фризы есть. Пойти чтоли застрелиться?

---

Отбрасываем.

Что еще может объяснить появление фризов?

Цитата:

---

Сообщение от trabla

P.S. ветка, кажется, стала о фризах, а не о новом проекте. Надо, наверное остановиться. Причину, всё равно, знают только разработчики.

---

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

Цитата:

---

Сообщение от pakman

Что конкретно в онлайн нельзя предугадать и предвидеть? Чем так уж сильно различаются самолёт за горизонтом в оффлайне и онлайне? В оффе компьютеру приходится думать ещё и за того парня, который бот. И за зенитки, и за базар. Ей богу, это не сопоставимо с простой раскладкой по полочкам данных, прибывающих из сети.

---

Действительно. Процу в онлайне на догфайтах работы доложно быть меньше, но мы наблюдаем фризы и падение ФПС в онлайн.
Чем отличается оффлайн и онлайн? Правильно, наличием работы с сетью во втором случае. Значит собака закопалась именно где-то в работе с сетью.

Цитата:

---

Сообщение от Sexton

Действительно. Процу в онлайне на догфайтах работы доложно быть меньше, но мы наблюдаем фризы и падение ФПС в онлайн.
Чем отличается оффлайн и онлайн? Правильно, наличием работы с сетью во втором случае. Значит собака закопалась именно где-то в работе с сетью.

---

Все.
Я наконец-то все понял. При работе с сетью закопалась собака. Если мы ее оттуда выкопаем, то фризы и лаги исчезнут! :D :D :D

Цитата:

---

Сообщение от pakman

Что конкретно в онлайн нельзя предугадать и предвидеть? Чем так уж сильно различаются самолёт за горизонтом в оффлайне и онлайне? В оффе компьютеру приходится думать ещё и за того парня, который бот. И за зенитки, и за базар. Ей богу, это не сопоставимо с простой раскладкой по полочкам данных, прибывающих из сети.

---

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

Цитата:

---

Сообщение от trabla

Это просто расстановка приоритетов доступа к ресурсу (данные для рендера). Всё равно их надо изменять с одной стороны и использовать для отрисовки, с другой. Сие, ИМХО, данность и ничего тут не поделаешь

---

А если сделать грамотно? Вот так например:

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

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

Здесь обозначены только обсуждаемые аспекты, остальное опущено.
Вообще-то это учебник. :)

Где тут место для 5-10 секундных фризов?
И что тут занимает столько времени? Локирование и отпускание разделяемого ресурса или обновление данных или их считывание? Бред!

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

Повторяю свое мнение. Фризы картинки введены искусственно для защиты от читеров.

Цитата:

---

Сообщение от Maximus_G

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

---

С чего ты взял?

Цитата:

---

Сообщение от tugarin

Повторяю свое мнение. Фризы картинки введены искусственно для защиты от читеров.

---

Да здравствует равенство! Теперь мы все читеры!

Считаю твою версию ошибочной.

Цитата:

---

Сообщение от Maximus_G

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

---

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

Ответ: потому что в ПХЗСАВН нет первого пункта.

Цитата:

---

Сообщение от pakman

Да здравствует равенство! Теперь мы все читеры!

Считаю твою версию ошибочной.

---

Есть какое-нибудь обоснование? :)

Цитата:

---

Сообщение от trabla

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

---

Внесены, т.е. уложены на полочки для последующей обсчёта? Да даже если там призойдёт 1000 изменений, подготовка эти данные займёт считанные миллисекунды.

Цитата:

---

Сообщение от tugarin

Есть какое-нибудь обоснование? :)

---

Я что, должен перед тобой отчитываться? :p Видишь ли, я страшно не люблю использовать набор букв "ИМХО". Но здесь именно такой случай.

Цитата:

---

Сообщение от tugarin

А если сделать грамотно? Вот так например:

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

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

Здесь обозначены только обсуждаемые аспекты, остальное опущено.
Вообще-то это учебник. :)

Где тут место для 5-10 секундных фризов?
И что тут занимает столько времени? Локирование и отпускание разделяемого ресурса или обновление данных или их считывание? Бред!

---

Я постараюсь не быть столь категоричным :D

1. (Главный цикл потока приема сетевых данных) Сколько занимает "обновлять данные" и от чего зависит скорость её выполнения? И что включает эта процедура?
2. (Главный цикл потока отрисовки) Сколько занимает времени "считывать данные" и от чего зависит скорость её выполнения? Включает ли оно еще и время для изменения сцены перед рендером? Вот тут я, конечно, не очень разбираюсь, но сильно подозреваю что накладные расходы будут пропорциональны количеству данных от сервера, которые влияют на содержимое сцены.

P.S. tugarin, по-моему мы уже в оффтоп упали. Предлагаю без алгоритмов, "грамотности" учебников и категоричности ;) .

Цитата:

---

Сообщение от Maximus_G

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

---

Потому что видеокарта все равно одна, а FPS зависит в первую очередь от нее. Нормальный же современный процессор с обсчетом данной конкретной FM на данный момент справляется и один, причем очень уверенно. Поэтому если ты поставишь 2 современных процессора, эффекта не будет. Точнее, будет, только если ты в миссии наставишь туеву хучу техники, но ее должно быть реально МНОГО, причем в РАЗНЫХ местах карты, чтобы не задевать видеокарту.
Пример:
Начинал я летать в ил на версии 1.11, у меня тогда был атлонXP 1600+ (реальная частота 1.4 GHZ, SSE2 нету). В миссии "утопление линкора руделем" у меня при ускорении времени в 8 раз fps сразу же падал капитально (до 3-4), я так понимаю, потому, что процессору приходилось обсчитывать в 8 раз больше физики в единицу времени, и он не справлялся. Через полгода я приобрел P4 2.6Ghz, шина 800, HT, SSE2 и все такое (видеокарта осталась прежней). Первое, что я сделал - это провел вышеприведенный тест, никакого падения fps уже не было.

Цитата:

---

Сообщение от pakman

Я что, должен перед тобой отчитываться? :p Видишь ли, я страшно не люблю использовать набор букв "ИМХО". Но здесь именно такой случай.

---

Нет не должен. Но с твой строны было бы любезностью поделиться своим мнением. Я не настаиваю.

Цитата:

---

Сообщение от trabla

Я постараюсь не быть столь категоричным :D

1. (Главный цикл потока приема сетевых данных) Сколько занимает "обновлять данные" и от чего зависит скорость её выполнения? И что включает эта процедура?
2. (Главный цикл потока отрисовки) Сколько занимает времени "считывать данные" и от чего зависит скорость её выполнения? Включает ли оно еще и время для изменения сцены перед рендером? Вот тут я, конечно, не очень разбираюсь, но сильно подозреваю что накладные расходы будут пропорциональны количеству данных от сервера, которые влияют на содержимое сцены.

P.S. tugarin, по-моему мы уже в оффтоп упали. Предлагаю без алгоритмов, "грамотности" учебников и категоричности ;) .

---

Обновление даных и их считывание продразумевает только копирование данных (в идеале memcpy). Внесение любой логики, а тем более каких-либо ожиданий (только подумал об этом и сразу мороз по коже), внутрь пары залочить-разлочить является ГРУБЕЙШИМ ПРОГРАММИСТСКИМ ЛЯПОМ.

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

Цитата:

---

Сообщение от tugarin

Обновление даных и их считывание продразумевает только копирование данных (в идеале memcpy). Внесение любой логики, а тем более каких-либо ожиданий (только подумал об этом и сразу мороз по коже), внутрь пары залочить-разлочить является ГРУБЕЙШИМ ПРОГРАММИСТСКИМ ЛЯПОМ.

---

Ты прав :), memcpy - быстрая операция. Но кажется мне, что сервер высылает не готовые данные для сцены, а данные на основании которых вносятся изменения в сцену. Так кто их вычисляет и делает, эти изменения, кто подгружает текстуры для изменённых объектов, меняет их если надо? Или сейчас это уже как-то по другому делается?

Цитата:

---

Сообщение от trabla

Ты прав :), memcpy - быстрая операция. Но кажется мне, что сервер высылает не готовые данные для сцены, а данные на основании которых вносятся изменения в сцену. Так кто их вычисляет и делает, эти изменения, кто подгружает текстуры для изменённых объектов, меняет их если надо? Или сейчас это уже как-то по другому делается?

---

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

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

Короче, при грамотной архитектуре многопоточной программы, нет места 5-10 секундным фризам из-за синхронизации данных.

Предлагаю считать эту версию фризов тупиковой и больше не возвращаться к ней.

Ну, хотя бы просто поверьте мне! Я этим делом на хлеб себе зарабатываю!

Цитата:

---

Сообщение от tugarin

...

Короче, при грамотной архитектуре многопоточной программы, нет места 5-10 секундным фризам из-за синхронизации данных.

---

А вот это и есть наезд на разработчиков :D .

Есть мнение, что любая многопоточная программа на системах с вытесняющей многозадачностью будет иметь фризы. Вопрос только насколько часто и насколько длительные и при каких условиях они будут происходить. ( Это я так, стебаюсь :) )

Цитата:

---

Сообщение от tugarin

Предлагаю считать эту версию фризов тупиковой и больше не возвращаться к ней.

---

А я бы с удовольствием выслушал "начальника транспортного цеха", т.е. разработчиков. Жаль, что это маловероятно. Хоть бы рассказали, ЧТО нужно для того, чтобы 5-10 сек фриз стал просто временным понижением FPS (но не до 0.1 :) )

Цитата:

---

Сообщение от tugarin

Ну, хотя бы просто поверьте мне! Я этим делом на хлеб себе зарабатываю!

---

Ты не один ;)

> Да я был сильно удеивлен. Штурмовал на лайтнинге, и тут какя то наглая зена начала стрелять. Ну я туда ракетами, а оно как бубухнет . У меня весь самолет в дырочку, баки текут, а сзади продолжают равться бензовозы и постоянно добовляются новые уничтоженные цели. Еще какой то зеро пристал, но до дому я дотянул. Правда у меня получилось всего 124 машинки и зенитка, в которую я собственно и стрелял

А чего удивляться,если ты случайно :) засадил НУРС в топливный или оружейный склад? :rolleyes: Там все и сдетонировало..(потому и дыры в крыльях)
Читайте брифинги-там усе сказано.Типа "Важно уничтожить топливные склады,ангары и т.д. на а/б противника.." Ну или заводик там разбомбить-то же очей немало поимеешь :cool:
Хотел же народ стратегические цели для бомберов-будьте любезны,получите и распишитесь.
Не,если не хотите-уберу. Мне рисовать проще будет %)

Цитата:

---

Сообщение от trabla

А вот это и есть наезд на разработчиков :D .

Есть мнение, что любая многопоточная программа на системах с вытесняющей многозадачностью будет иметь фризы. Вопрос только насколько часто и насколько длительные и при каких условиях они будут происходить. ( Это я так, стебаюсь :) )

---

1. Большинство игроков не являются тупыми и не запускают параллельно с игрой другие ресурсоемкие и/или высокоприоритетные процессы. Тем не менее фризы наблюдаются. Т.е. их нельзя объяснить захватом железячных ресурсов другим приложением.
2. Внутри процесса у потоков управления имеются все средства, чтобы избегать монопольного захвата ресурсов одним потоком и длительного простоя других потоков. Такими средствами являются функции ожидания с таймаутом, Sleep(0), yield() и т.п. Эти средства конечно же не могут абсолютно произвольно регулировать расписание запуска потоков, т.к. винды не являются системой реального времени, но 5-10 секунд и более - это все-таки слишком.

Как ты этого не понимаешь, если работаешь с этой же области?

P.S. Я закончил благотворительную лекцию по написанию сетевых многопоточных приложений. Остальные консультации платные.

Пожалуйста, не превращайте топик в платную консультацию :D:D:D

Цитата:

---

Сообщение от pakman

Пожалуйста, не превращайте топик в платную консультацию :D:D:D

---

Ну конечно же платные консультации будут происходить в привате, а лучше по e-mail. Так больше заработать получится. :D

Цитата:

---

Сообщение от tugarin

Ну конечно же платные консультации будут происходить в привате, а лучше по e-mail. Так больше заработать получится. :D

---

Думаешь заполучить клиентуру из среды разработчиков Ил2? :D

Цитата:

---

Сообщение от pakman

Думаешь заполучить клиентуру из среды разработчиков Ил2? :D

---

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

Цитата:

---

Сообщение от flogger

А чего удивляться,если ты случайно :) засадил НУРС в топливный или оружейный склад? :rolleyes: Там все и сдетонировало..(потому и дыры в крыльях)
Читайте брифинги-там усе сказано.Типа "Важно уничтожить топливные склады,ангары и т.д. на а/б противника.." Ну или заводик там разбомбить-то же очей немало поимеешь :cool:
Хотел же народ стратегические цели для бомберов-будьте любезны,получите и распишитесь.
Не,если не хотите-уберу. Мне рисовать проще будет %)

---

Думается, что наличие подобных целей провоцирует одиночные действия. Вот некто Джойстик за один вылет на истребителе стал лучшим бомбардировщиком карты. Это перегиб. Думаю, не следует строить цели так, чтобы одним сбросом убивалось более 40-60 машинок. Лучше строить жирную цель из нескольких таких групп, расположеных неподалёку, что бы одна не детонировала от другой. Тогда можно прилететь в хорошей компании 3-4 человека и каждый унесёт свой кусок пирога. Все будут счастливы.

Цитата:

---

Сообщение от Jedi I

еще.... непонравились просто агромные расстояния..... когда от точки старта летишь к противнику.... пока летишь, одна тоска - синее море под тобой, синее небо над тобой.... а время тянется просто дико. тоска ужасная.... имхо нужно сократить расстояния. В смоленске и на подобных картах, хотябы пейзаж меняется :) видно где ты летишь.... а я как поклонник фулреала(вообще-то летаю без иконки на карте, был бы рад еслиб на г1 ее отключили :D ) умираю со скуки. на морских картах т.к. в руках тока секундомер и курс перед глазами..... вот. Японцам дали Хенкеля, за неимением у них бомбера.... ето правильно. тока нужно учесть, то хенкель в одиночку с двумя sc2000 топит авианосец с топмачта.
(но это для режима камикадза) а так и с высоты можно жахнуть.... В целом впечатления положительные..... за исключением расстояний, фризов..... и корсара который не может взлететь с авианосца :D

---

хе хе я таких люблю тоскующих. Так плавненько заходишь незаметно пикируешь с приглушенным движком ба-бах и нет тоски :D

to pakman:

>Думается, что наличие подобных целей провоцирует одиночные действия.

Не думаю.До цели надо долететь и найти ее+зены. Но в любом случае будет пересматриваться "тип" цели.Например не 100 машинок,а 10 вагонов(образно). И так,что б если не склад боеприпасов и керосина-не будет такой детонации.

Цитата:

---

Сообщение от pakman

С чего ты взял?

---

Это активно проверялось участниками форума 3 года назад.

Кстати, какая то фигня со статом. Отлетал миссию, на Лайтинге, завалил 1 самоль и одну зену :) Вернулся на базу, летел 1 час туды и обратно. Сел, выключил двигло, вышел. В стате написано, 3 минуты летал и был убит, что за херь ?

Цитата:

---

Сообщение от Ram_Wolf

Кстати, какая то фигня со статом. Отлетал миссию, на Лайтинге, завалил 1 самоль и одну зену :) Вернулся на базу, летел 1 час туды и обратно. Сел, выключил двигло, вышел. В стате написано, 3 минуты летал и был убит, что за херь ?

---

Может,это как на Гене 1-м?Там кто-то писал,что вроде бы следующую попытку надо жать лишь через 10 сек.Или я что-то перепутал... %)

Брен, я там жал кнопу через 20 сек. :)

Кстати,. на ИвоДжиме44 фризит как тока начинают зены работать, просто жуть. И это не есть гуд !
Притом замечено, чем больше их выносишь тем меньше фризов. Это толстый намёк разработчикам.
А так большое спасибо ребятам из комманды Генадича ! Классный проект.

Цитата:

---

Сообщение от Alexander =SF=Krogoth

А Гипперлобби закрывал, когда ботов гонял? Тормозит не сетка, а лобби, когда серваки пингует и мессаги в чате получает. Сделай логгофф и наслаждайся жизнью.

---

Неужели HL способно так тормозить ил, тем более оффлайн? Ну не должны такие фризы быть, не 50% и даже не 30% процессорного времени лобби ест...

Цитата:

---

Сообщение от 23AG_Oves

Неужели HL способно так тормозить ил, тем более оффлайн? Ну не должны такие фризы быть, не 50% и даже не 30% процессорного времени лобби ест...

---

А ты не гадай способно, неспособно и сколько оно ест, просто попробуй поиграть в оффлайне с и без гипперлобби в онлайне. ;)

Попробую сегодня. И тимспик проверю заодно.

Цитата:

---

Сообщение от tugarin

...
P.S. Я закончил благотворительную лекцию по написанию сетевых многопоточных приложений. Остальные консультации платные.

---

No comment :D

Цитата:

---

Сообщение от 23AG_Oves

Неужели HL способно так тормозить ил, тем более оффлайн? Ну не должны такие фризы быть, не 50% и даже не 30% процессорного времени лобби ест...

---

После одной из последних версий лобби стала такая фигня. Раньше открывал лобби, шел игратся на какой-нибудь сервак, ну а лобби в фоновом висело. Теперь такое дело не проходит :( Все подгагивает и подфризивает. Хотя может дело не в лобби, а в Иле...

Цитата:

---

Сообщение от Hishnick

После одной из последних версий лобби стала такая фигня. Раньше открывал лобби, шел игратся на какой-нибудь сервак, ну а лобби в фоновом висело. Теперь такое дело не проходит :( Все подгагивает и подфризивает. Хотя может дело не в лобби, а в Иле...

---

хмм. у меня всегда так было...
да и ил очень нервно реагирует на незакрытые приложения а на ХЛ очень нервно :D

Кстати генадьичевские серваки спокойно восприниают москвичей и иже с ними. остальных россиян терпит, но с неохотой...
Стоит появиться забугорникам, он начинает кренделя выдавать.
Сначала я думал показалось, потом стал заострять внимание и мне стало казатся еще больше ;)
Поскольку многих знаю кто откуда, а последнее время сервак даже пишет откуда, то моя статистика подтверждается...
Если у кого есть противоположная, разубедите меня :)

Цитата:

---

Сообщение от mongol

Кстати генадьичевские серваки спокойно восприниают москвичей и иже с ними. остальных россиян терпит, но с неохотой...
Стоит появиться забугорникам, он начинает кренделя выдавать.
Сначала я думал показалось, потом стал заострять внимание и мне стало казатся еще больше ;)
Поскольку многих знаю кто откуда, а последнее время сервак даже пишет откуда, то моя статистика подтверждается...
Если у кого есть противоположная, разубедите меня :)

---

Зачем разубеждать? Это держателям сервера нужно собирать статистику, а потом анализировать ее. На основе этого анализа предпринимать какие-то действия по оптимизации настроек и публиковать для посетителей рекомендации по настройке клиентской части. Конечно, если им это зачем-то нужно. :)

Цитата:

---

Сообщение от mongol

Кстати генадьичевские серваки спокойно восприниают москвичей и иже с ними. остальных россиян терпит, но с неохотой...
Стоит появиться забугорникам, он начинает кренделя выдавать.
Сначала я думал показалось, потом стал заострять внимание и мне стало казатся еще больше ;)
Поскольку многих знаю кто откуда, а последнее время сервак даже пишет откуда, то моя статистика подтверждается...
Если у кого есть противоположная, разубедите меня :)

---

[Скандируя] Геннадич - для Москвичей! :cool:

Цитата:

---

Сообщение от Adler

[Скандируя] Геннадич - для Москвичей! :cool:

---

Я понимаю, что ты шутишь.

Но если серьезно, то дискриминация по региональному признаку прежде всего в худшую скажется на посещаемости сервера.

Сервер Геннадича для российских вирпилов всегда был ГЛАВНЫМ ДОГФАЙТОВЫМ СЕРВЕРОМ. А при дискриминации по региональному признаку он станет всего лишь одним из.

Я не утверждаю, что на Геннадичах есть дискриминация по региональному признаку. Это Монгол высказал такую гипотезу, а я только развил мысль. :)

Проектов нет, всё идёт в полный.............