Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - xanser

Страницы: [1] 2 3 ... 33
1
Программирование / Re: Расширение классов
« : Январь 16, 2018, 04:24:02 am »
Последний вопрос - функция Get() получает объект перебором всех существующих, пока не найдет совпадение, или сразу выхватывает нужного?

2
Программирование / Re: Расширение классов
« : Январь 12, 2018, 11:42:35 am »
Может захочется еще что-то расширить кроме машин, например CPed, допустим добавить "голод". Да и просто понимать, как сделано, может где еще пригодится. Форум-то для того и нужен, чтобы научиться, а не только брать чужое. Если будет желание, опиши хотя бы последовательность действий, хотя и за твой пример уже спасибо.

3
Программирование / Re: Расширение классов
« : Январь 10, 2018, 04:22:39 am »
Мне интересен сам используемый прием. Поэтому хотелось пошагово на простом примере сначала понять суть, за счет чего происходит "прикрепление", и какой синтаксис должен быть от начала до конца. Если смотреть пример по CVehicle, там код не полностью приведен в сообщении, для меня остались пробелы в таких местах:
Код: C++
  1. VehicleComponents(CVehicle *) { // Конструктор этого класса будет вызван при вызове конструктора транспорта (CVehicle::CVehicle)
Не очень понятно, почему происходит вызов нового конструктора при вызове стандартного CVehicle::CVehicle
Код: C++
  1. static VehicleExtendedData<VehicleComponents> vehComps;
Не описано, что такое VehicleExtendedData
Код: C++
  1. vehComps.Get(vehicle).m_pDoorLF
Как выглядит функция Get() ?
Видимо ответы в самом sdk, но так тяжело изучать что-то, копая чужой код. Вот и хотелось на отвлеченном примере понять сам принцип, а потом уже идти от простого к сложному.

4
Программирование / Расширение классов
« : Январь 06, 2018, 05:10:43 pm »
В этом посте DK показывал пример, как расширить класс, "прикрепив" к нему дополнительные атрибуты. Насколько я понял, существующие пулы при этом не расширяются.
Код: C++
  1.     #include <plugin.h>
  2.      
  3.     using namespace plugin;
  4.      
  5.     class VehicleExtendedExample {
  6.     public:
  7.         class VehicleComponents { // Класс, который представляет наши данные (можно сказать, что эти данные "прикрепляются" к структуре транспорта)
  8.         public:
  9.             RwFrame *m_pDoorLF;
  10.             RwFrame *m_pDoorRF;
  11.             RwFrame *m_pDoorLR;
  12.             RwFrame *m_pDoorRR;
  13.      
  14.             VehicleComponents(CVehicle *) { // Конструктор этого класса будет вызван при вызове конструктора транспорта (CVehicle::CVehicle)
  15.                 m_pDoorLF = m_pDoorRF = m_pDoorLR = m_pDoorRR = nullptr; // устанавливаем все указатели в 0
  16.             }
  17.         };
  18.      
  19.         VehicleExtendedExample() {
  20.             static VehicleExtendedData<VehicleComponents> vehComps; // Создаем экземпляр нашего расширения. vehComps - это переменная, через которую мы будем
  21.                                                                     // обращаться к нашим данным (используя метод Get(CVehicle *транспорт) )
  22.      
  23.             Events::vehicleSetModelEvent += [](CVehicle *vehicle, int modelIndex) { // Выполняем нашу функцию, когда игра устанавливает модель транспорту
  24.                 if (vehicle->m_pRwClump) { // Если создан графический обьект модели (RpClump)
  25.                     vehComps.Get(vehicle).m_pDoorLF = CClumpModelInfo::GetFrameFromName(vehicle->m_pRwClump, "door_lf_dummy"); // Находим компоненты в иерархии
  26.                     vehComps.Get(vehicle).m_pDoorRF = CClumpModelInfo::GetFrameFromName(vehicle->m_pRwClump, "door_rf_dummy"); // и записываем их в наш класс
  27.                     vehComps.Get(vehicle).m_pDoorLR = CClumpModelInfo::GetFrameFromName(vehicle->m_pRwClump, "door_lr_dummy");
  28.                     vehComps.Get(vehicle).m_pDoorRR = CClumpModelInfo::GetFrameFromName(vehicle->m_pRwClump, "door_rr_dummy");
  29.                 }
  30.                 else // иначе устанавливаём всё в 0
  31.                     vehComps.Get(vehicle).m_pDoorLF = vehComps.Get(vehicle).m_pDoorRF = vehComps.Get(vehicle).m_pDoorLR = vehComps.Get(vehicle).m_pDoorRR = nullptr;
  32.             };
  33.      
  34.             Events::vehicleRenderEvent += [](CVehicle *vehicle) { // Выполняем нашу функцию, когда игра рендерит транспорт
  35.                 if (vehComps.Get(vehicle).m_pDoorLF)
  36.                     vehComps.Get(vehicle).m_pDoorLF->modelling.pos.z = 1.0f; // Сдвигаем компонент вверх
  37.                 if (vehComps.Get(vehicle).m_pDoorRF)
  38.                     vehComps.Get(vehicle).m_pDoorRF->modelling.pos.z = 1.0f;
  39.                 if (vehComps.Get(vehicle).m_pDoorLR)
  40.                     vehComps.Get(vehicle).m_pDoorLR->modelling.pos.z = 1.0f;
  41.                 if (vehComps.Get(vehicle).m_pDoorRR)
  42.                     vehComps.Get(vehicle).m_pDoorRR->modelling.pos.z = 1.0f;
  43.             };
  44.         }
  45.     } vehicleExtendedExample;

DK, можешь на простом примере показать общий принцип расширения классов через прикрепление новых атрибутов. К примеру, есть условный класс
Код: C++
  1. class CVector {
  2. public:
  3.     float x;
  4.     float y;
  5.     CVector();
  6. } vector2d[100];

И есть, например, пул таких координат по определенному адресу памяти, где идет по порядку vector2d[0].x, veсtor2d[0].y, vector2d[1].x, veсtor2d[1].y, vector2d[2].x, veсtor2d[2].y...
Как к этому классу "прикрепить" еще свою координату float z, чтобы обращаться уже к vector2d.x, vector2d.y, vector3d.Get(vector2d).z и не повредить существующий пул. Пример не связан с игрой.

5
Идеи / Re: Отражения воды
« : Декабрь 27, 2017, 05:45:25 am »
Первые 4 параметры как-то не улучшают воду, ухудшается плавность перехода прозрачной воду в непрозрачную, мне кажется дефолтный вариант самый оптимальный. Остальные параметры по указанной ссылке использовались.

6
Хотел перенести на основу plugin-sdk, но не вышло пока. Вот эти строчки не знаю, как реализовать
05E7: 2@ = car 0@ struct
05E3: call_method 0x59E590 struct 2@ params 1 pop 0 1@
Вроде это самое простое, у меня так, на plugin-sdk по аналогии.
Код: C++
  1. void CAutomobile::SetModelIndex(int id) {
  2.         ((void(__thiscall *)(CAutomobile *, int))0x59E590)(this, id);
  3. }
  4.  
  5. ((CAutomobile *)(PlayerPed->Vehicle))->SetModelIndex(149);

7
Общие вопросы / Зеркальное отражение модели
« : Октябрь 27, 2017, 06:37:16 pm »
Есть ли способ поставить на карту модель в зеркальном отражении, например по-хитрому задав углы поворота. Актуально для симметричных моделей, например ворот, чтобы не моделить отраженный аналог.

8
Идеи / Re: Смена текстур транспорта
« : Октябрь 24, 2017, 05:19:26 am »
Радует, что это возможно. Спасибо за код, буду разбираться.

9
Идеи / Re: Смена текстур транспорта
« : Октябрь 19, 2017, 04:21:50 am »
Может тогда поэкспериментировать пока на спец. актерах с id 109-129, посоздавать одновременно на один номер разные модели или текстуры. Как поведет себя игра, создаст разных или одинаковых, и что нужно, чтобы происходила смена. Между миссиями это же как-то происходит. Возможно придется удалить созданные модели, чтобы появилась новая, тогда это поставит крест на всей задумке. А может достаточно поменять какой-то флаг или что-то переинициализировать.

10
Идеи / Смена текстур транспорта
« : Октябрь 18, 2017, 03:13:50 pm »
Предлагаю запилить мод для смены скинов машин или поделиться соображениями, возможно это или нет. Вот, что мне удалось. Во вложении вторая текстура для танка rhino2.txd для gta3.img и тестовая asi-шка, которая меняет скин танка до его первого появления нажатием на Tab, для проверки после этого можно ввести например чит-код panzer. Проблема в том, что текстуру танка пока удалось сменить только до появления первой модели, потом все модели создаются такие же. Если первым создать стандартный танк, то мой код уже не оказывает эффекта. Нужна помощь в поиске причины. Хотелось бы сделать смену на лету.



Почему это кажется возможным. Я позаимствовал функции из этого блока: 0x40AA60 CStreaming::RequestSpecialModel, здесь меняются модели и текстуры для специальных актеров для миссий:
109, special01, generic, CIVMALE, STAT_STD_MISSION, man, 0, null, 9,9
110, special02, generic, CIVMALE, STAT_STD_MISSION, man, 0, null, 9,9
......................................
129, special21, generic, CIVMALE, STAT_STD_MISSION, man, 0, null, 9,9

Получается, что можно на один id вешать любые модели и текстуры, в перспективе кажется возможным таким способом расширить количество транспортных средств, используя одни и те же номера.
Что касается скинов, то мне видится возможным внедрение кода с чередующимися текстурами до отрисовки отдельной машины в функцию 0x589AE0 CAutomobile::PreRender

Вот примеры практического применения с использованием этого кода, но пока неодновременные полуфейки:


11
Может кто-нибудь разбирался, почему игрок не падает с эскалатора. От чего интересно зависит "примагничивание" к ступенькам. Попробовал сделать свой эскалатор из тех же ступенек, работает только вертикальное движение, при горизонтальном ступеньки уезжают из под ног. Также игрок не съезжает с яхты кортеза в миссии, интересно от чего это зависит.

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

12
В продолжение темы с другого боку...
1. Модификатор Edit Normals - Average/Selected выбирает средний угол между всеми нормалями, причем от последовательности выбора зависит конечное направление. Тем не менее положительный результат есть, после такого выравнивания можно поворачивать нормали в ZModeler все сразу и на глаз поставить пусть не 90 градусов, но 89.99, что не отличимо в игре. Это актуально еще вот где - если поставить на карту траву, то с динамическим светом одна сторона травы будет светлой, а вторая жутко темной, если направить нормали вверх, то трава одинаково освещена со всех сторон, незаметно перетекая в поверхность земли, и картинка получается красивая.
2. По поводу экспорта скриптами КАМа, действительно они портят нормали, я использовал плагин экспорта dff, с моделями все норм. Но вот с педами беда - КАМ как и обычно все портит, превращая педа в угловатую заготовку, а плагин экспорта на педах вызывает ошибку в игре. Может есть идеи, как импортировать и экспортировать педов с теми же нормалями, а то я сделал несколько новых, а они в игре как топором обтесанные получились.

13
0x100 день в году, всех с праздником !!!

14
О сайте и форумах / Re: Будет ли закрыт сайт?
« : Сентябрь 04, 2017, 11:39:29 am »
А тема то заставляет задуматься. Весь материал и обсуждение конечно надо беречь. Даже просто обмен вопросами помогает находить решения, в том числе и самостоятельные, расти в творческом плане. Я бы забросил это все много лет назад, если бы не наткнулся на этот замечательный сайт. Но у форума есть проблема - недостаток участников обсуждений, хорошо бы, чтобы тут взаимодействовало человек 100 ежедневно, потому как сейчас и десятка не наберется, вобщем-то 2-3 человека, желающие дать даже не совет, а хотя бы просто отписаться по теме. Но верю, что все будет развиваться. Пожелаю сайту безлимитных дней существования, Sektor-у и участникам бесконечная благодарность.

15
Программирование / Re: Модульность dll
« : Сентябрь 04, 2017, 11:24:19 am »
Согласен, это просто как пример. Просто есть однотипные места встраивания для разных модов, например процесс отрисовки худа, обработка компонентов транспорта, пререндер сущностей, запуск игровой сцены и т.д., куда можно сделать общее входящее внедрение, а потом просто дописывать различные dll, которые будут инклудиться уже куда нужно. Необязательно, что я так буду делать, мне то проще писать одну большую dll, просто интересно как вариант.

Страницы: [1] 2 3 ... 33