В текущих реалиях это утверждение неверно в связи с последними событиями(обьединение серверов на офе это показало)
У вновь созданых персов айди = MaxInt(если читать как INT) и меньше, сам изначально считал это лагами клиента, но персов с такими айди много и айди у них стабилен. при этом у старых персов которые попадались айди бывал 0х800 (меньше не встречал).
Максимальный WID персов - в студию. Когда я играл, диапазоны WID мобов и персов не перекрывались.
Цитата:
Сообщение от tianddu
а почему нету в шапке AAC - откат химии, AB0 - максимальный откат химии
На данный момент содержимое базы(x10 система счисления)
2496, 'Алёшка', 102, 5140, 136, 0, 4
2141424880, 'мадЖАХед', 5, 0, 4234, 6, 6
а так вэлком на лиридан, делайте перса и будет у вас айди больше чем у последнего)
Данные в порядке WID NICK LVL Clan_Points Clan_Id Class Rank
На данный момент содержимое базы(x10 система счисления)
2496, 'Алёшка', 102, 5140, 136, 0, 4
2141424880, 'мадЖАХед', 5, 0, 4234, 6, 6
а так вэлком на лиридан, делайте перса и будет у вас айди больше чем у последнего)
Данные в порядке WID NICK LVL Clan_Points Clan_Id Class Rank
Создал. Постоял. Последний созданный перс при мне - 0x7FA43B80.
НПС рядом - 0x80105CB6, 0x80105DD3.
Все осталось, как прежде.
Цитата:
Сообщение от sumikot
у мобов, петов и НПС значение ВИД большое, точно сейчас не помню, с чего начинается - 0х800000, чтоли. Если меньше - игрок.
Да, я ошибся в границе. Но я и предупредил, что не помню.
Итак, выше 0х80000000 - нпс, ниже - перс. Если персам стали присваивать большие идентификаторы, пугаться не стоит, все равно перекрываться они не будут - механика игры этого не позволит.
То что они перекрываться не будут - факт, тут речь о другом) это не способ отделять персов от нпц)
Да и разница между ними в 7кк - смущает немного, ибо крайне мала.
Последний раз редактировалось ToRcH2565; 06.06.2013 в 19:59.
То что они перекрываться не будут - факт, тут речь о другом) это не способ отделять персов от нпц)
Да и разница между ними в 7кк - смущает немного, ибо крайне мала.
Тогда о чем весь разговор?
Вопрос стоял:
Цитата:
Сообщение от rufat2005
как определить? кто в таргете? игрок моб или нпс
Я привел в пример самый простой вариант, который всегда нормально работал. Могу написать сложнее. Например, перебрать оба массива, в каком найдется данный WID, и будет означать, перс это или нпс\моб. Работать будет дольше. Можно проверить длину структуры, у перса она больше. Можно проверить данные в структуре, какие соответствуют только персу или мобу\нпс.
А разница совсем не смущает - для этого есть китайские программисты. Могут сместить диапазон WID мобов\нпс вверх до упора, могут разрезать диапазон WID персов и продолжить его за диапазоном мобов. Могут для WID в дальнейшем выделить двойной dword, что даст больший запас.
Например, перебрать оба массива, в каком найдется данный WID, и будет означать, перс это или нпс\моб. Работать будет дольше.
Цитата:
Сообщение от sumikot
Предложи свой.
Хэш таблицы, бинарные деревья... вариантов масса но все сводятся к перебору и имхо это единственный верный способ.
Нам же никто не мешает при чтении структур заполнять не только оную, но и сделать хэш табличку или деревце где будем хранить соответствие моб\нпс\перс....?)
Да и что такое перебрать массив из 300 значений на современном пк?)
(в получении данных от клиента читаю структуры персов\мобов\ресов и в нескольких местах идет перебор всех этих значений и сборка их в xml, при частоте раз в 0.05 сек загрузка цп(2ггц) ~ 7%)
Последний раз редактировалось ToRcH2565; 07.06.2013 в 09:56.
Да и что такое перебрать массив из 300 значений на современном пк?
Давай теперь все посчитаем. 0х300 это 768. Два массива это 1536.
Цитата:
Сообщение от ToRcH2565
при частоте раз в 0.05 сек загрузка цп(2ггц) ~ 7%)
Многие (не голословно, данные с форума) запускают по 4-5 окон. 4*7 = 28 только на перебор массивов.
Есть такое понятие, как оптимизация - если способ с разделением нпс и персов по WID работает (а он работает), я буду пользоваться им. Кроме того, структуру по WID из таргета можно получить, не перебирая массив. Всего 8 смещений вместо 1536 переборов...
Давай теперь все посчитаем. 0х300 это 768. Два массива это 1536.
Согласен, забыл про запись в 16 ричном виде но мои слова про загрузку относились к нагрузке на цп ВСЕМИ действиями моей програмки, которая перебирает не 1 массив, и при МАКСИМАЛЬНО частом переборе, где цикл запускается раз 50мс... оно вам надо так часто запускать цикл который читает данные с пв, проверяет кто у вас там в таргете выполняет комманды скриптов(да да встроеные скрипты в этом цикле на тригерах висят)?
Теперь ставим реальные условия для ПО:
Цитата:
Сообщение от sumikot
Многие (не голословно, данные с форума) запускают по 4-5 окон. 4*7 = 28 только на перебор массивов.
Берем ваши 28%, и делим как минимум на 4(обновление раз в 200мс чего достаточно с головой).
Идем дальше Выкинем обработку скриптового языка, чтение структур, еще 2-3 цикла с перебором остальных массивов, убираем генерацию XML строк(вот только тут срежем еще 50% нагрузки)... что в итоге выйдет?
Перебрать массив\список поиск в бинарном дереве\Хэш таблице на 10к записей 20 раз в секунду, не займет много процессорного времени...
Цитата:
Сообщение от sumikot
Есть такое понятие, как оптимизация - если способ с разделением нпс и персов по WID работает (а он работает), я буду пользоваться им.
Не там оптимизируете. уберите вообще чтение параметров, зачем оно? его можно оптимизировать, причем сильно. как пример - внедряем длл в чужой процесс, и вместо копирования и прыжков в зад в перед оперируем со всеми переменными как со своими(время на передачу то тоже тратится) дальше больше, только встает вопрос, кому это нужно?)
те кто запускает по 4-5 окон и так вынуждены иметь современные машинки, а кто запускает 1-2 окна, и так не нагрузит таким циклом свой пк.
Цитата:
Сообщение от sumikot
Кроме того, структуру по WID из таргета можно получить, не перебирая массив. Всего 8 смещений вместо 1536 переборов...
В большинстве случаев это полезно) но если вам нужно оперировать списками окружающих персов, то это бесполезная трата времени.
Зачем мудрить с теми решениями которые могут перестать работать даже без изменения клиентской части игры?, и кстати пологаю что в серверной часте заложен алгоритм "перепрыгивания" айди нпц...
Плюс такая возможность есть на фришках(в том плане что там предложеный вами алгоритм работать не будет, ибо ленивый админ добавил нпс с айди < чем айди первого стандартного нпс).
ну и пы.сы. если хоть один из списков вам нужен, то в момент считывания списка, вы можете создать указатель на структуру находящуюся в таргете(точней считали и проверили таргет с текущим айди прям в цикле чтения)... и если таргет не = 0 а ваша ссылка =null то явно понять в который список попадет искомый айди.
Внезапно заглянул в тему и возник вопрос. Как? И можно ли таким же способом получить структуру не из таргета, просто по WID?
GA+0x18+0x8+0xB0+0x8+0x1C4+0xC+0x8+0x248 Только я уже не помню, искал я это для Возрождения династии или для Гнева Империи )) В общем, то, потестил и дальше ничего делать не стал. По WID найти не получится - тут используется указатель на адрес структуры перса из таргета, хотя если разобрать функцию, которая его туда пишет, может, и удастся воспользоваться, как подпрограммой получения из WID адреса. Кто его знает...
Когда собирал dll - пробный вариант, мне оказалось лучше воспользоваться перебором, чем потом обновлять кучу офсетов. Но, как вариант...
ToRcH2565, спор ни о чем... Закончился у меня уже рабочий день. И тебе тоже приятных выходных )) Надеюсь, админы лишнее потрут.
GA+0x18+0x8+0xB0+0x8+0x1C4+0xC+0x8+0x248 Только я уже не помню, искал я это для Возрождения династии или для Гнева Империи )) В общем, то, потестил и дальше ничего делать не стал. По WID найти не получится - тут используется указатель на адрес структуры перса из таргета, хотя если разобрать функцию, которая его туда пишет, может, и удастся воспользоваться, как подпрограммой получения из WID адреса. Кто его знает...
Когда собирал dll - пробный вариант, мне оказалось лучше воспользоваться перебором, чем потом обновлять кучу офсетов. Но, как вариант...
Отправлять пакет на взятие в таргет определенного перса с нужным WID и считывать тоже можно
Это всяко лучше перебора, особенно когда в таких программах, которые следят за 5-6 людьми из всего массива, причем постоянно, т.е. каждые 50ms идет обновление информации. И
Цитата:
Сообщение от sumikot
Всего 8 смещений вместо 1536 переборов...
намного выгоднее.
В любом случае, спасибо за информацию
________________
Больше не занимаюсь читами, ушёл в серверную часть. Новый ник - int 3.
P.S. Но я всё такой же добрый модератор раздела PW.
Последний раз редактировалось Smertig; 07.06.2013 в 17:36.
Отправлять пакет на взятие в таргет определенного перса с нужным WID и считывать тоже можно
Это всяко лучше перебора, особенно когда в таких программах, которые следят за 5-6 людьми из всего массива, причем постоянно, т.е. каждые 50ms идет обновление информации. И
Ох батенька, вы совсем незнакомы с устройством пв.
Вот причины:
1) Отправлять пакет на взятие в таргет определенного перса - 1 раз в сек(может 0.5 сек) если чаще- "вы отсутпаете".
2) Отправляя пакет вы даете команду игре перебрать этот массив.
3) 50 мс в моей программе предусмотренны только для проверки нагрузок всей это фигни, реальный же режим отслеживания не имеет смысла чаще чем раз в 200мс. пройдем далее..
4) отправляя пакет - вы выделяете память в клиенте что очень неслабо кушает процессорное время.
5) чтение кусочков памяти намного менее продуктивно чем чтение области в несколько мб и последующий разбор этих данных у себя на стороне(в своем софте).
6) пока персонаж в радиусе(если вы следите за 5-6 окружающими) вам не нужно каждый раз читать всю информацию о них, она будет статична. вам не нужно каждый раз перебирать весь массив, перебрали 1 раз, сохранили смещения до старта структур в отдельный список(аля observ_list) и уже по готовым смещениям читаете нужные данные.
Цитата:
Сообщение от sumikot
ToRcH2565, спор ни о чем... Закончился у меня уже рабочий день. И тебе тоже приятных выходных )) Надеюсь, админы лишнее потрут.
Ну да последние посты были уже откровенным холиваром, ибо оптимизировать нужно только тогда когда проблема возникла, не стоит сразу пытаться делать идеальный код, уйдет куча времени и ничего хорошего не выйдет...
Цитата:
Сообщение от Smertig
Всего 8 смещений вместо 1536 переборов...
намного выгоднее.
В любом случае, спасибо за информацию
Не будьте так уверены.... 1536 переборов это случай когда вокруг вас 700+ человек(на згд и того меньше) и столько же нипов, в реальных ситуциях максимум 1к(как раз таки згд в пик загруженности). как вы думаете сколько уйдет тиков на 8! вызовов апи функции которая обратится к памяти чужого процесса и скопирует ее кусок в вашу память?)
я вам советую сделать массив на 1к записей, заполнить его случайными данными и отсортировать по возрастанию а затем по убыванию вложеным циклом, и замерить время,
а потом прочитать 8000* значений по 4байта из чужого приложения которые идут вразброс!(от этого время выполнения теста увеличится, и т.к. в реальных условиях данные не будут последовательны то это создаст эфект правдоподобности по времени)...
*(сортировка массива будет как 1к*1к интераций, посему 8*1к для чесности теста)
результатом теста вы будете удивлены, операция над массивом займет в разы меньше времени(а ведь 2 сортировки массива займет 2кк интераций цикла...)
Ох батенька, вы совсем незнакомы с устройством пв.
Вот причины:
1) Отправлять пакет на взятие в таргет определенного перса - 1 раз в сек(может 0.5 сек) если чаще- "вы отсутпаете".
2) Отправляя пакет вы даете команду игре перебрать этот массив.
Насчёт взятия в таргет пакетом соглашусь, не подумал
Цитата:
Сообщение от ToRcH2565
3) 50 мс в моей программе предусмотренны только для проверки нагрузок всей это фигни, реальный же режим отслеживания не имеет смысла чаще чем раз в 200мс. пройдем далее..
В моей программе считывается почти постоянно, даже чаще, чем в 50 мс, т.к. как минимум идёт проверка на каст скилла, что при инкасте может занимать доли секунды.
Цитата:
Сообщение от ToRcH2565
6) пока персонаж в радиусе(если вы следите за 5-6 окружающими) вам не нужно каждый раз читать всю информацию о них, она будет статична. вам не нужно каждый раз перебирать весь массив, перебрали 1 раз, сохранили смещения до старта структур в отдельный список(аля observ_list) и уже по готовым смещениям читаете нужные данные.
Так и делал, пока не прочитал про смещения, о которых говорил sumikot. Существовало 5-6 переменных, отвечающих за номер игрока в структуре, и соответственно, если игрок никуда не уходил, структура считывалась по старому номеру
Цитата:
Сообщение от ToRcH2565
5) чтение кусочков памяти намного менее продуктивно чем чтение области в несколько мб и последующий разбор этих данных у себя на стороне(в своем софте).
Об этом тоже не думал, попробую.
Спасибо.
P.S.
Цитата:
Сообщение от ToRcH2565
сортировка массива будет как 1к*1к интераций
Пополам разделить. А точнее 500*999 итераций, если сортировка методом "пузырька" (с другими не знаком, но википедия говорит о [Ссылки могут видеть только зарегистрированные пользователи. ]. Сложность O(n*lg n) по сравнению с O(n^2))
P.P.S это я уже придираюсь, общий смысл поста понял
________________
Больше не занимаюсь читами, ушёл в серверную часть. Новый ник - int 3.
P.S. Но я всё такой же добрый модератор раздела PW.
Последний раз редактировалось Smertig; 08.06.2013 в 13:25.
отсортировать по возрастанию а затем по убыванию вложеным циклом
Цитата:
Сообщение от Smertig
А точнее 500*999 итераций, если сортировка методом "пузька"
Я вроде указал способ сортировки, считывание данных чаще чем 50 мс не имеет смысла для персов отличных от своего из за пинга.
Вложеный цикл аля
For i:=1 to 1000 do
For j:=1 to 1000 do
Begin
//Code
end;
считайте кол-во интераций...
Добавлено через 5 минут
Цитата:
Сообщение от Smertig
Так и делал, пока не прочитал про смещения, о которых говорил sumikot. Существовало 5-6 переменных, отвечающих за номер игрока в структуре, и соответственно, если игрок никуда не уходил, структура считывалась по старому номеру
Зачем лишнее чтение? храните не номер в массиве, а сразу адрес до старта структуры требуемого персонажа....
Последний раз редактировалось ToRcH2565; 08.06.2013 в 02:09.
Причина: Добавлено сообщение
Регистрация: 20.08.2009
Сообщений: 90
Популярность: 173
Сказал(а) спасибо: 14
Re: РУОФФ Адреса и оффсеты
Золото Zhyk.Ru: 300 
