не компилируется с ним, может внутри компилятора автоматом подставляется.

Действительно не компилируется. В компиляторе не подставляется, в исходниках (в extra.c) how_much описана как функция без параметров.
Если напишешь pull, добавь ещё чтобы в optimize.c в IsProtectedProc добавили "Protect("desc_p_proc");" для F1 ;)

Типа того — движок достаёт аргумент из стэка, но в нашем случае этого аргумента в стэке нет и он трогает что не нужно ;)

Легче и правильнее всё же исправить компилятор :-p

В F2 "description_p_proc", а в F1 "desc_p_proc".

Неверная информация, основанная на демо-версии движка, что:

У F1 такие же именные обработчики как и у F2, только вместо "description_p_proc" это "desc_p_proc" и нет "push_p_proc", "is_dropping_p_proc", "combat_is_starting_p_proc" и "combat_is_over_p_proc". Связка start+script_action является резервной и срабатывает если именного обработчика нет (вроде рассказывал об этом когда сделал "! Исправлено использование фиксированной позиции для вызова скриптовой процедуры start при отсутствии стандартного обработчика.").

Поэтому, на примере jennifer.ssl,:

проверка в start нафик не нужна, движок вызовет look_at_p_proc напрямую.

Почему я постоянно в процедуре start вижу эти script_action, скрипты остались с демо-версии?
Вообще я кто-то не лезу в дебри F1, тут бы с F2 разобраться))

Вероятно, а может привычка. Честно говоря у меня нет под рукой F1 версии 1.0, а искать лень, но в патче 1.1 экзешник уже точно вызывает именные обработчики напрямую.

Из item_w_damage_ нужно же только получить рандом дамага? или есть какие-то скрытые нюансы.
Я переделал скрипт полностью на скриптовой вариант, но вот с item_w_damage_ остались сомнения.

Всё верно. Хотя можно вообще от item_w_damage отказаться заменив сразу на random ;)

Опять баки забил :-p
Неверно — HOOK_ITEMDAMAGE срабатывает в оригинальной item_w_damage_, а поскольку ты её полностью исключаешь из использования, то значения item_w_damage_min и item_w_damage_max никогда не будут соответствовать реальным значениям оружия.
Конечно можно сделать полный аналог движковой item_w_damage_, похерив при этом любые моды использующие HOOK_ITEMDAMAGE ;)
К чему вообще такие сложности?

Так мин-макс дамаг получаются из HOOK_ITEMDAMAGE каждый раз при стрельбе.
Цепочка вызова
Движковой compute damage -> item_w_damage_ -> HOOK_ITEMDAMAGE -> Получили мин-макс -≥ Hook_Damage
Что не так то?

И спрашивал по цикл

Он там в движке чтобы просто убить процессорное время?)) в этом цикле ничего не анализируется, ничего не запоминается относительно предыдущей итерации цикла.
Поэтому я и спрашиваю про item_w_damage_ может там что-то ещё есть, кроме получения рандомного дамага.

Отправлено: 9 апр 18 13:08

Потому что в оригинальном использование движковой item_w_damage_ совместно с HOOKDAMAGE глючит, это ты там у себя поправил и все ок)

Так, попутал с хуками полностью переопределяющими обработку ;)

Дамаг суммируется, rounds — это количество пуль.

Та ладно? :-p

Та, не спорь — твой все равно круче ;)

Вот я так и думал, что должно суммироваться))
Я когда отформатировал твою писанину для более легкого чтения, в конце просчета поставил := вместо += :)

Ты не чего не исправлял? само от ремонтировалось))

Отправлено: 9 апр 18 17:55

Ага) я опять получаю краши, которых нет в старых 1.7 версиях и в оригинале.
Разберусь что там крутое) крашит игру, напишу.

Не, я серьёзно не припоминаю каких-либо изменений в "item_w_damage_ совместно с HOOKDAMAGE".

Это хитрый план :-p

Если делать свою собственную игру и с собственными скриптами — то да))))
Да и еще просить фишки в движке (про слух именно ты просил), которые потом обычным играм будут условности ставить)))

Ладно это ложная тревога, крашилось на clear_array, обновил ддл на последнию и вроде норм (может забыл обновить с прошлых правок массива).

Там глюк если возвращается ретурном дамаг в HOOK_ITEMDAMAGE, то после вызова item_w_damage_ в HOOK_COMBATDAMAGE критеры/игрок наносят дамаг сами по себе))

Всё равно хз о чём, но выглядит как серьёзный ахтунг :-p

Ну это выглядит примерно так же как MultiHex критеры метают оружие сами в себя)))

Спасибо. Серьёзная лажа, кстати :/

Гугл или там Яндекс, не? ;)

не для нубов не находит)

Вбил в яндексе "опкоды к ассемблеровским командам", выбрал наугад Хабрахабр, бегло просмотрел текст и увидел ссылку. Уверен что при желании можно ещё чего найти.

Но ты бы лучше конкретизировал для чего тебе это — изучения ассемблера или, как я полагаю, для конвертации ассемблерного кода в машинный код, чтобы самому было удобно делать изменения.
Для второго способа есть простой способ с использованием Hiew'а — в Decode режиме включить редактирование (F3), потом редактор ассемблерного кода (F2) и после ввода нужного кода и нажатия Enter увидеть подсвеченный результат в виде машинного кода. Главное потом выйти из режима редактирования через Esc не нажав Update (F9) ;)

Вот это, а то мне приходится по исходникам базы IDA искать)
По ссылке таблицу уже смотрел там точно уже для прошареных.

Если бы не его досовский вид)

Уверен что можно найти и GUI-аналог.
Или так — Online x86 / x64 Assembler and Disassembler.

Вся документация есть в архиве сфала.

Было еще предложение самим создавать пользовательские хуки непосредственно в скрипте, а не только через хард-кодинг в dll.

Ну прям все нельзя. Ну это пока)

Очень серьезный долгострой)

Можно что угодно, но это же совсем :-p Лучше считать что нет.

Может и не должно? ;-p
Для получения значения локальной переменной требуется передача указателя на место, куда будет записано это значения. Напрямую его передать через call_offset_* нельзя.
Установка через call_offset_r3(0x4A6E58, read_int(object+0x78), int var_index, int value).

Виндовые вроде GetPrivateProfile*, движковые (это которые config_get_*) специфичны.

чем специфичны?

Та не суть, менять сейчас с виндовых на движковые уже нет смысла.

К чему? :-p

Обсуждали уже — нельзя.
Механизм уменьшения/увеличения скорости "течения" времени в игре заложен в движке, но похерен и вместо этого 1 секунда это фиксированные 10 тиков. Можно было бы допилить, чтобы менять скорость (5 вместо 10 ускорят, а 20 вместо 10 замедлят игровое время в 2 раза) и была совместимость с таймерными событиями и анимацией, но это дополнительно требует проверки и редактирования всех скриптов для замены использования фиксированных значений (ONE_GAME_MINUTE = 600 и т.д.) на рассчитываемые "на лету" (ONE_GAME_MINUTE = game_ticks(60)). И мне слабо верится что кто-то будет заниматься последним :-p

а да точно обсуждали)
но это можно сделать, только потребуется одновременно допиливать множитель и для функции game_ticks (это чтобы без перекомпиляции) ну и все остальное фиксить, что связанно с тиками.

Просто перекомпилировать скрипты. Но, в том случае если мод использует заголовки оригинального фола, иначе если скрипты декомпилированы, просто так не заменить. Но возможно и при чём в автоматическом режиме.

Проблема в совместимости. Все старые моды, просто сойдут с ума))

При переносе, ф1 на движок ф2, я с помощью сишного препроцессора и excel'я восстанавливал, гвары, номера скриптов и т.д Если заморочиться то вполне решаемо.

Ты не понял сути, это была бы пользовательская опция, а не заточенная под конкретный мод.
Сегодня я играю на x2 скорости, а завтра на x1 хочу, и что каждый раз перекомпиляцию делать)))

jordan
Кстати ты лет 10 назад а то и больше, делал рассылку на почту для всех кто когда-то был на ТимХ, короче ты чего-то хотел всех собрать, я пришел на форум посмотрел никого нет, подумал подумал ну и пошел дальше пить пиво)