Как часто крашат старые клиенты? 1.26.4 - 2.0.3 Опции

[Aimed]

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

Оо, опять этот эксперт активировался!))
Проблемы в железе, проблемы в реестре, UORice, NO-CD. Прям все что в голову пришло - все назвал, плохо что без каких либо аргументов и главное, - все мимо.
Что может быть проблемой в железе?
Причем тут шифрование и UORice? Как ты думаешь, когда клиент использует шифрование?
Что может такого быть в реестре, из-за чего клиент крашит? Зачем по-твоему реестр вообще нужен?
NO-CD тут причем? Игра у него запускается.

Кстати! Совсем забыл кое что важное по теме.
Juzzver, какие логи во время фриза/краша в Event Viewer попадают? Вангую банальный Access Violation эксепшен, он же null reference.

[Juzzver]

Кстати! Совсем забыл кое что важное по теме.
Juzzver, какие логи во время фриза/краша в Event Viewer попадают? Вангую банальный Access Violation эксепшен, он же null reference.

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

Процесс просто зависает в диспетчере("Не отвечает"), никакой цепочки задач при этом на нём не отображается, но цп по прежнему прыгатся в районе 15-20%.

[Aimed]

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

Процесс просто зависает в диспетчере("Не отвечает"), никакой цепочки задач при этом на нём не отображается, но цп по прежнему прыгатся в районе 15-20%.

Это прога от винды. Нажимаешь win клавишу и пишешь Event Viewer. Погугли, если что.

[Juzzver]

Это прога от винды. Нажимаешь win клавишу и пишешь Event Viewer. Погугли, если что.

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

[Александр Needle™]

Оо, опять этот эксперт активировался!))
Проблемы в железе, проблемы в реестре, UORice, NO-CD. Прям все что в голову пришло - все назвал, плохо что без каких либо аргументов и главное, - все мимо.
Что может быть проблемой в железе?
Причем тут шифрование и UORice? Как ты думаешь, когда клиент использует шифрование?
Что может такого быть в реестре, из-за чего клиент крашит? Зачем по-твоему реестр вообще нужен?
NO-CD тут причем? Игра у него запускается.

Кстати! Совсем забыл кое что важное по теме.
Juzzver, какие логи во время фриза/краша в Event Viewer попадают? Вангую банальный Access Violation эксепшен, он же null reference.

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

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

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

Juzzver, если понадобятся файлы, я скину, тему буду наблюдать.

[Aimed]

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

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

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

Juzzver, если понадобятся файлы, я скину, тему буду наблюдать.

Теперь все понятно.

Пришлось поработать со старыми версиями клиентов от 1.26.4 (с установочного диска), и столкнулся с тем, что периодически возникают фатальные фризы клиентов. Будь то при активных действиях, или же при обычном простое. Версия 1.26.4i зависает стабильно каждые 15-30 минут, а то и намного раньше.

Где тут речь о том что у него зависает стабильно после входа игру или на авторизации?

@Juzzver есть ещё один вариант. Если в эвент вьювер логи не попадают, то запускай клиент через ProcDump. Внизу примеры с использованием. Там по дампу можно попробовать разобраться.

[Juzzver]

Event Viewer отлавливает его только после завершения заглючившего процесса, тип ошибки Application Hang.
Там есть какой-то Unknown пакет, но это что-то стороннее судя по всему.

В общем лог такой:

- System

- Provider

[ Name] Application Hang

- EventID 1002

[ Qualifiers] 0

Level 2

Task 101

Keywords 0x80000000000000

- TimeCreated

[ SystemTime] 2020-02-26T02:17:22.071110500Z

EventRecordID 91052

Channel Application

Computer DESKTOP-VPEKCHL

Security


- EventData

client1.26.4i.exe
0.0.0.0
45ec
01d5ec4aaea263a2
10
E:\UO_1.26\UOClient\client1.26.4i.exe
51b63d4b-515a-454e-bd30-9c574598cacd


55006E006B006E006F0077006E0000000000


--------------------------------------------------------------------------------

Двоичные файлы:


По словам

0000: 006E0055 006E006B 0077006F 0000006E
0010: 0000


По байтам

0000: 55 00 6E 00 6B 00 6E 00 U.n.k.n.
0008: 6F 00 77 00 6E 00 00 00 o.w.n...
0010: 00 00 ..

Так же решил сверить последние отправленные/полученные пакеты сервером/клиентом, в итоге ничего криминального, обычная прогрузка WorldItem пакетов. Причем одни и те же итемы могут загружаться и в определенный момент может подвиснуть.
После нескольких тестов стала проявляться закономерность, где от большого кол-ва одновременно прогружаемых пакетов WorldItem - ловится лаг почти стабильно. В моём случае это данж, где много LOS блокеров и еще различных элементов. И если быстро бегать туда-сюда по телепорту, заставляя постоянно прогружаться окружающие элементы - то ловится этот фриз. На самом экране в то же время видно, как пошагово прогружались эти элементы и на каких-то из порядка зависате(рандомный элемент).

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

Постестил в полях, и обнаружил еще одну закономерность. Если создать много объектов, к примеру bag, штук 500 (что равносильно кол-ву объектов в зоне видимости того данжа, где я зависал), то всё будет нормально. Даже при резких телепортациях в эту область. Но стоить только изменить всем bag в этой области айдишник на тип стула "throne", то во время их отрисовки ловится баг.
Аналогично потестил с прочими более менее крупными объектами и выявил такую тенденцию к зависаниям при отрисовке крупных компонентов. Пусть даже их будет 100 штук, лаг будет обеспечен. А с многокомпонентными вещами, типа largeboat, то и еще меньше объектов достаточно для вызова лага.

Видимо копать надо в эту сторону.

[Aimed]

С эвент логом скудновато : /

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

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

Постестил в полях, и обнаружил еще одну закономерность. Если создать много объектов, к примеру bag, штук 500 (что равносильно кол-ву объектов в зоне видимости того данжа, где я зависал), то всё будет нормально. Даже при резких телепортациях в эту область. Но стоить только изменить всем bag в этой области айдишник на тип стула "throne", то во время их отрисовки ловится баг.

А если просто этот трон поставить рядом?

Аналогично потестил с прочими более менее крупными объектами и выявил такую тенденцию к зависаниям при отрисовке крупных компонентов. Пусть даже их будет 100 штук, лаг будет обеспечен. А с многокомпонентными вещами, типа largeboat, то и еще меньше объектов достаточно для вызова лага.

Видимо копать надо в эту сторону.

Лаг или завасание клиента?

[Juzzver]

А если просто этот трон поставить рядом?

ничего не произойдет, корректно поставится. Это явление с зависанием происходит только при массовых прогрузках картинок.
К примеру делаю [tile bag, создаю штук 100-200 мешков, далее делаю [area set itemid 2353 where bag (где 2353 к примеру айдишник "throne" картинки), и вижу как половина стульев отрисовывается, а на оставшейся части - клиент зависает.

Лаг или завасание клиента?

зависание, как на скрине в первом посте.

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

на гринзоне чисто, тестил считай на нескольких айдишниках, которые точно есть в клиенте.

Кстати, визуально даже заметно, что старый клиент значительно дольше отрисовывает элементы, чем к примеру зайти на той же 4й версии. И на ней соответственно всё будет ок.

[Aimed]

Кстати, визуально даже заметно, что старый клиент значительно дольше отрисовывает элементы, чем к примеру зайти на той же 4й версии. И на ней соответственно всё будет ок.

Кривой рендеринг, как я в первом посту и говорил - изначально большую часть кода ГД писали, вот и результат : /
Может много чего быть, но похоже на кривой n² алгоритм сортировки, при котором количество итераций врзрывается. А ты пробовал хоть раз подождать, вдруг отвиснет? )))

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

Но все это никак тебе не поможет. Я не думаю что ты пойдешь так далеко что б дизасмить это дело и создавать патч для фикса. Меняй клиент)

[Александр Needle™]

Кривой рендеринг, как я в первом посту и говорил - изначально большую часть кода ГД писали, вот и результат : /
Может много чего быть, но похоже на кривой n² алгоритм сортировки, при котором количество итераций врзрывается. А ты пробовал хоть раз подождать, вдруг отвиснет? )))

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

Но все это никак тебе не поможет. Я не думаю что ты пойдешь так далеко что б дизасмить это дело и создавать патч для фикса. Меняй клиент)

То есть, причина в кривом рендеринге?
Почему тогда такая проблема не у всех пользователей?

[Aimed]

Почему тогда такая проблема не у всех пользователей?

Это мое предлоположение, основанное на утверждениях самих создателей и наблюдениях Juzzverя.

Почему тогда такая проблема не у всех пользователей?

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

Когда я скачивал этот клиент у меня практически сразу одно ядро на 100% загружалось и сессий дольше 5 минут у меня не было, потому что я просто тестил его поддержку протокола. Я его очень быстро удалил.