roma912

Ну мне пришел в голову такой вариант - написать свой парсер и на его основе уже использовать функции рисования. Если хочешь сделать разметку для текста вроде HTML, то придется написать тебе обработчик данной строки. Допустим, ты передаешь в свою функцию следующее (Ну соотв. класс для всего этого) CustomGDIDraw->DrawTextbyHTML("<fontColor:#ff0000> January 30, 2011\n </fontColor><fontColor:#ff0010> Feb 1, 1999\n </fontColor><fontColor:#ff0050> Feb 2, 1970\n </fontColor>") Первый твой этап - сделать парсинг, который ты уже будешь обрабатывать по своей логике. Сначала определять текст, потом цвет, потом символы переноса и т.д. Самый простой вариант - регулярка (кликабельно) Совпадения по группам, это будет то, что тебе нужно в данном случае. Группа 1 - выдаст тебе hex цвета. Далее уже сам преобразуешь Группа 2 - выдаст тебе текст, который нужен для отображения. Далее уже сам обработаешь перенос строки. Ну и по итогу получишь то, что хотел. Минус только в том, что тебе придется на совершенно любой текст ставить данные кастомные теги. В целом теги можно сделать и попроще, чтобы и сама регулярка была проще. Ну тут уже как хочешь, тебе решать. По поводу переноса текста - берешь начальные координаты отрисовки, и высчитываешь от этой координаты вниз некоторое количество пикселей (Допустим шрифт 14 + отступ текста 8 = 22). Примерно такая логика для переноса текста. Ну а далее стандартная отрисовка по координатам. Идею для реализации я тебе описал, дальше все за тобой.

Еще есть другой вариант. 1. Ставишь хук на нужную точку или функцию 2. При срабатывании хука запоминаешь нужные тебе регистры 3. Выписываешь все в файл 4. Возвращаешь управление игровой функции

Поэтому тебя и направили изучать основы ассемблера. Изучишь основы, тогда поймешь что нопнуть

Это конечно все хорошо, но лучше для записи смещений использовать reclass. Штука очень удобная и сгенерирует автоматически класс для дальнейшей работы

Насколько я понял никакого виртуального метода у данного объекта нет, т.к. тут _thiscall и передается указатель на EC_LoginUIMan Если существуют какие-то варианты вызова метода без поиска данного указателя EC_LoginUIMan или установки хука, то готов прочитать пару статей об этом.

Вот для конкретности. Есть базовый класс AUIManager, в котором virtual PAUIDIALOG GetDialog(const char *pszName); - Метод для получения окна по имени, он точно реализован. Ставлю точку на вызов метода с нужным именем окна, нахожу указатель на класс из Ecx и Reclass уже подсказывает что это CECLoginUIMan, где базовый класс AUIManager Логично предположить, что этот метод будет и в CECLoginUIMan, однако указатель на нее найти не получается Если предположение не точное, то возможно ли выйти на базовый класс (AUIManager) через (CECLoginUIMan) и взять его указатель? А потом еще глубже в нем найти указатель через VTable на метод GetDialog?

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

У меня вопрос насчёт устройства методов, которые существуют внутри объекта (в памяти) Допустим с виртуальными все понятно, и вызываются они через vtable. А возможно ли найти обычную функцию внутри объекта? (в памяти) Т.е лежат ли там указатели на все методы класса? Или для _thiscall конвенции это так не работает?

Ну это уже слишком... Хотя тоже имеет право на жизнь Мне проще написать dll на с++ которая вызовет просто эту функцию по адресу и все. Тем более все аргументы ты уже знаешь через декомпилятор .net

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

Ну... Я с видовыми матрицами работал совсем немного Но перевернутых никаких мне не встречалось. Да и если посмотреть как формируется н-мерный массив, то он останется таким же и в памяти. Т.е. как он был записан в коде, так должен и выглядеть в памяти. Разве что в CE выбрать неправильное отображение (Оно и может наверное запутать)

Ну если игра не на юнити, то тогда и нужно искать видовую матрицу Для юнити довольно просто все писать. Берешь саму dll, которая Assembly-csharp из папки manage. Это считай твоя "основная библиотека классов" для модификаций чего угодно. После написания инжектируешь как mono библиотеку

Ну наверняка структура до каменя примерно такая pPlayer->CInventory[N]->CItem-> (И вот тут уже вариации) В любом случае нужно искать указатель на инвентарь, а далее искать указатель на каждую вещь в инвентаре Иначе врятли ты найдешь сразу камешек который тебе нужен Ну а для возвращения его в слот, нужно найти функцию которая ставит / вынимает его, если это невозможно записью указателя в память

Ну вот такие хуки как раз довольно сложно отлаживать. Переписал бы ты хук на detours 1.5, или же 3 версию. Там хотя бы точно не накосячишь со стеком и прочим.

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