Продолжение хождений
Опять таки опытным путем было выявлено, что изменять значение дальности прорисовки по адресу 0x73295E (сам содержит адрес памяти со значением, но об этом было написано выше) больше чем на цифру 140 не имеет смысла.
Значение 140 дает весьма хорошую дальность прорисовки. (Имею ввиду только педов, и только созданных через скрипт вручную, все остальные объекты это не затрагивает.)
Любые попытки увеличить это число ни к чему не привели - видимо достигнут предел. Печаль.
Как жить дальше?
Как добиться большей дальности прорисовки? Куда копать, куда смотреть?
Предполагаю, если есть значение в памяти, значит это кому-то нужно. Но кому?
а) Это либо функция отрисовки, которая проверяет расстояние до модели и решает, показывать её или нет.
Но это сомнительно, ведь логичнее было делать эту проверку в другом месте, а в функцию отрисовки давать уже только нужные модели.
б) Может быть есть какой то менеджер объектов (моделей), который помещает в массив видимые объекты и удаляет оттуда те, что слишком далеки от игрока.
В массиве таким образом остаются только видимые объекты.
Далее остается скормить этот массив (или объекты из него) рисовальщику.
в) ?
Однако, как бы там ни было, если они используют это значение из памяти, почему увеличение дальности отрисовки не происходит после значения 140?
Достигнут лимит игрового движка? Но ведь другие игровые объекты (деревья, краны, дома) рисуются и дальше.... Или для педов есть такой вот жесткий лимит внутри движка?
Возможно, в коде записано как тот так limit = Min(pedDrawDistance_0x73295E, 140) ???
Как это найти и обойти?
Подскажите, помогите куда дальше смотреть? какие возможные варианты?
Приветствуются любые ответы, догадки, предложения, советы!
Заранее большое спасибо!
- Форумы GTAModding.ru
- → Просмотр профиля: Сообщения: BlackMan
Статистика
- Группа: Пользователи
- Сообщений: 5
- Просмотров: 6687
- Статус: Новичок
- Возраст: Неизвестен
- День рождения: Неизвестен
-
Пол
Мужчина
-
Интересы
GTA SA
Старые поля
-
Флаг (Flag)
Не выбран (None)
-
Любимая игра серии
Grand Theft Auto: San Andreas
0
Обычный
Инструменты
Друзья
BlackMan еще не добавил друзей
Последние посетители
Мои сообщения
В теме: Вопрос по скрипту увеличения дальности прорисовки
06 December 2012 - 19:19
В теме: Вопрос по скрипту увеличения дальности прорисовки
06 December 2012 - 11:27
Ого, жесть какая. 0x863994 это не число, это такой же адрес, по которому записано 300.0. Ответил подробнее на твои сообщения в ЛС.
Последние два значения меняются напрямую, потому что другие функции их не используют и ничего страшного от их перезаписи не произойдет.
(Написал бы в приват где-нить на gtaforums, я сюда иногда нечасто захожу, сам видишь)
Спасибо огромное за ответ!
Много интересного познал, пока изучал этот вопрос, поэтому это даже здорово
Да, обязательно буду посещать побольше форумов по модингу ГТА, хорошо что они все есть!
Еще раз спасибо всем за ответ и участие
В теме: Вопрос по скрипту увеличения дальности прорисовки
05 December 2012 - 22:20
Шутка про заблудших овец оказалась пророческой - чувствую себя бараном
Опытными путем было обнаружено, что (независимо от другого кода) именно строка
0A8C: write_memory 0x73295E size 4 value 0x863994 virtual_protect 1 //[(float)220.0000] pedsDrawDistanceInstall
позволяет увеличить дальность прорисовки созданных вручную педов - именно тех, которых сам помещаешь на карту через скрипты. На дальность отрисовки других созданных самой игрой педов это никак не повлияло (оно нам и не важно).
Для проверки я параллельно с помощью другого скрипта создал на расстоянии 100 метров друг от друга 5 индифферентных к происходящему вокруг педов.
Дальность прорисовки, мягко говоря, гораздо лучше той, что по умолчанию. Хотя всех педов с одной точки увидеть и нельзя. По-моему, дальность отрисовки где-то 380-400 метров.
Вооружившись стандартом http://en.wikipedia....i/IEEE_754-1985 , двинулся дальше исследовать скрипт.
Как видно из кода выше, нас интересует адрес 0x73295E , другие мы даже трогать не будем.
1) Для начала закоментировал весь код (чтобы посмотреть какие значения пишутся по адресу по умолчанию).
Загрузил игру.
Запустил HEX-редактор.
Смотрю, какие значения выставлены по умолчанию:
HEX-вид
те же значения, только в двоичном виде
Вот оно, значение по нашему адресу, выставленное самой игрой (по умолчанию): 34 8b 85 00 (HEX), 00110100 10001011 10000101 00000000 (BIN)
2) Далее компилирую CLEO-скрипт с единственной рабоче строкой:
0A8C: write_memory 0x73295E size 4 value 0x863994 virtual_protect 1 //[(float)220.0000] pedsDrawDistanceInstall
Запускаю новую игру.
Смотрю в HEX-редактор:
те же яйца, только в двоичном виде
Все верно: по адресу 0x73295E записано значение 0x863994 (HEX), 00000000 10000110 00111001 10010100 (BIN ) , что и следовало ожидать от скрипта.
3) Дальше начинается самое интересное (и печальное
Предположительно, в память пишутся числа с плавающей запятой, но не в первозданном виде, а согласно стандарту http://en.wikipedia....i/IEEE_754-1985 .
Более того, в комментарии к строке кода написано :
0A8C: write_memory 0x73295E size 4 value 0x863994 virtual_protect 1 //[(float)220.0000] pedsDrawDistanceInstall
Что как бы намекает, что загадочное значение, которое записывается в память, это число (float)220.0000 , приведенное в божеский вид согласно стандарту.
Википедия дает ссылки на несколько онлайн конвертеров чисел в этот стандарт (первый, второй, третий, плюс я использовал отдельную программу).
Иду на первый конвертер http://www.binarycon...vert_float.html
Подставляю число 220.0000 - выдается число согласно стандарту:
Первое, что бросается в глаза, - представление числа согласно стандарту не сходится с тем, что уже есть в нашем коде.
Конвертер выдает нам 0x435C0000 = 01000011 01011100 00000000 00000000,
но в коде у нас 0x863994 (HEX), 00000000 10000110 00111001 10010100 (BIN )
Попытка подставить новое значение, которое выдал конвертер как представление числа 220.0000 в код ни к чему хорошему не привело - игра вылетела...
5) Далее я попробовал идти в каком то смысле от обратного: раз у нас уже есть рабочие значения памяти, значит надо просто конвертировать их обратно из стандарта IEEE-754 в человеко-понятный вид.
Снова иду на первый конвертер - http://www.binarycon...vert_float.html
Беру наше значение из работающего кода 0x863994 (HEX) и подставляю его в нужное поле.
Результат:
К сожалению, получается слишком большое число....
P.S. Далее....
Далее была попытка "инвертировать" порядок байтов, то есть из
0x863994 (HEX), 00000000 10000110 00111001 10010100 (BIN )
сделать
0x943986 (HEX), 10010100 00111001 10000110 00000000 (BIN )
но это дало еще худший результат (как следовало ожидать, ведь теперь бит, определяющий по стандарту знак числа, дает отрицательное значение)....
Очень прошу помочь, направить на путь истинный, указать направление
Любые советы, догадки, предложения по прежнему приветствуются
Заранее большое спасибо!
Опытными путем было обнаружено, что (независимо от другого кода) именно строка
0A8C: write_memory 0x73295E size 4 value 0x863994 virtual_protect 1 //[(float)220.0000] pedsDrawDistanceInstall
позволяет увеличить дальность прорисовки созданных вручную педов - именно тех, которых сам помещаешь на карту через скрипты. На дальность отрисовки других созданных самой игрой педов это никак не повлияло (оно нам и не важно).
Для проверки я параллельно с помощью другого скрипта создал на расстоянии 100 метров друг от друга 5 индифферентных к происходящему вокруг педов.
Дальность прорисовки, мягко говоря, гораздо лучше той, что по умолчанию. Хотя всех педов с одной точки увидеть и нельзя. По-моему, дальность отрисовки где-то 380-400 метров.
Вооружившись стандартом http://en.wikipedia....i/IEEE_754-1985 , двинулся дальше исследовать скрипт.
Как видно из кода выше, нас интересует адрес 0x73295E , другие мы даже трогать не будем.
1) Для начала закоментировал весь код (чтобы посмотреть какие значения пишутся по адресу по умолчанию).
Загрузил игру.
Запустил HEX-редактор.
Смотрю, какие значения выставлены по умолчанию:
HEX-вид
те же значения, только в двоичном виде
Вот оно, значение по нашему адресу, выставленное самой игрой (по умолчанию): 34 8b 85 00 (HEX), 00110100 10001011 10000101 00000000 (BIN)
2) Далее компилирую CLEO-скрипт с единственной рабоче строкой:
0A8C: write_memory 0x73295E size 4 value 0x863994 virtual_protect 1 //[(float)220.0000] pedsDrawDistanceInstall
Запускаю новую игру.
Смотрю в HEX-редактор:
те же яйца, только в двоичном виде
Все верно: по адресу 0x73295E записано значение 0x863994 (HEX), 00000000 10000110 00111001 10010100 (BIN ) , что и следовало ожидать от скрипта.
3) Дальше начинается самое интересное (и печальное
Предположительно, в память пишутся числа с плавающей запятой, но не в первозданном виде, а согласно стандарту http://en.wikipedia....i/IEEE_754-1985 .
Более того, в комментарии к строке кода написано :
0A8C: write_memory 0x73295E size 4 value 0x863994 virtual_protect 1 //[(float)220.0000] pedsDrawDistanceInstall
Что как бы намекает, что загадочное значение, которое записывается в память, это число (float)220.0000 , приведенное в божеский вид согласно стандарту.
Википедия дает ссылки на несколько онлайн конвертеров чисел в этот стандарт (первый, второй, третий, плюс я использовал отдельную программу).
Иду на первый конвертер http://www.binarycon...vert_float.html
Подставляю число 220.0000 - выдается число согласно стандарту:
Первое, что бросается в глаза, - представление числа согласно стандарту не сходится с тем, что уже есть в нашем коде.
Конвертер выдает нам 0x435C0000 = 01000011 01011100 00000000 00000000,
но в коде у нас 0x863994 (HEX), 00000000 10000110 00111001 10010100 (BIN )
Попытка подставить новое значение, которое выдал конвертер как представление числа 220.0000 в код ни к чему хорошему не привело - игра вылетела...
5) Далее я попробовал идти в каком то смысле от обратного: раз у нас уже есть рабочие значения памяти, значит надо просто конвертировать их обратно из стандарта IEEE-754 в человеко-понятный вид.
Снова иду на первый конвертер - http://www.binarycon...vert_float.html
Беру наше значение из работающего кода 0x863994 (HEX) и подставляю его в нужное поле.
Результат:
К сожалению, получается слишком большое число....
P.S. Далее....
Далее была попытка "инвертировать" порядок байтов, то есть из
0x863994 (HEX), 00000000 10000110 00111001 10010100 (BIN )
сделать
0x943986 (HEX), 10010100 00111001 10000110 00000000 (BIN )
но это дало еще худший результат (как следовало ожидать, ведь теперь бит, определяющий по стандарту знак числа, дает отрицательное значение)....
Очень прошу помочь, направить на путь истинный, указать направление
Любые советы, догадки, предложения по прежнему приветствуются
Заранее большое спасибо!
В теме: Вопрос по скрипту увеличения дальности прорисовки
05 December 2012 - 10:27
- Форумы GTAModding.ru
- → Просмотр профиля: Сообщения: BlackMan
- Политика Конфиденциальности
- Общие правила форумов ·