Приведённый мною вариант абсолютно правильно работает :-p
Покажи свой вариант или сделай простенький скрипт для примера.

Расчитывается с учётом вложенных сумок/рюкзаков, то есть если в главном рюкзаке у тебя лежит мешок с вещами и ты его откроешь, прокрутишь инвентарь вниз и нажмёшь F11, то будет вариант нажатия home в мешке.

Именно это будет, остальные call_offset_v# (где # > 0) — нет (сейчас).

call_offset_v0(0x45EB98); /* intface_redraw_ */

Чего-чего доработать?

Ага, прикольно — исправил ;)

а что может быть проще — после того как с контейнером(инвентарь открыт) провел какие либо махинации с его предметами добавил или удалил, в коде скрипта идет код обновления.
вот добавь этот кусок кода к хуку который сделал ты — по F9 перемещает инвентарь игрока в контейнер (аля твоя клавиша положить все)

подходишь к любому контейнеру юзаешь его, там нажимаешь F9 и F11 и нифига, нужно мышкой поводить) а для игрока все работает.

Отправлено: 6 мар 16 21:07
А тьфу я понял, почему не работает! потому-что код для цели работает только в связке с кодом для игрока.
т.е. в таком варианте кода, корректно оно не будет обновляться.

это можно изменить или юзать в связке?

Отправлено: 6 мар 16 21:25

Ну к примеру когда в неактивном слоте руки(пусть это будет слот левой руки) держишь какой либо предмет то critter_inven_obj не получает указатель на этот предмет.
или critter_inven_obj(dude_obj, INVEN_TYPE_LEFT_HAND) — возвращает NULL хотя предмет там лежит, но оно его не видит пока не поменяешь активный слот руки клавишей 'B' — как-то так.

Отправлено: 6 мар 16 21:36

Замечательно работает!
Не проверял, а AP в режиме боя тоже перерисовывает или нет?

Скрипт не сработал, да не важно, код процедур поглядел. В display_inventory_ есть вызов функции отрисовки окна, а в display_target_inventory_ почему-то нет. Поэтому для цели после вызова call_offset_v4(display_target_inventory_...
добавляй call_offset_v1(0x4D6F5C, read_int(0x59E964));/* win_draw_ */ (поправлю сейчас пример).

Для неигрока активная рука — правая, для игрока сначала нужно узнать активную с помощью active_hand(). Вот это чудно работает с critter_inven_obj:

lol, действительно не видит, сейчас поправлю. Done ;)

Нет.

Тогда давай перейдем к водным процедурам)

А чего у тебя подсветка предметов/контейнеров разными цветами сделана серый/желтый/розовый нафига такой дикий раскрас?)
вместо розового бы зеленый сделал — а то розовый это как-то не из мира фоллаута))

Это нужно через ини опцию фиксить, потому как функция в игре определяет держит ли игрок в активной руке оружие — понимаешь смысл?!
Т.е. к примеру в неваде охраники будут кричать гг 'убери оружие' хотя он его не держит в активной руке, и придется убирать его из слота вообще. — невада то писалась не под сфалл где без Active_Hand() нет возможности определить активную руку.

Отправлено: 7 мар 16 16:53

а без аргументов есть такая же функция? чтобы можно было вызывать из оригинального сфала — call_offset_v0
ибо как оказалось к функции display_stats_ тоже нужно применять процедуру win_draw_

Ну какие цвета свободные были, те в ход и пошли. Выбор там всяко скудный.

Весьма топорный способ функции в движке для получения предмета в активной руке игрока, когда исправлял так почекал скрипты оригинального F2 и увидел только использование с зеркальными очками, причём это опция для дополнительной ветки разговора доступная с очками в активной руке.
Через ини делать не буду — ненужная суета с выбором названия переменной и описания :-p Прокомментировать переменную как "включённая требует убирания оружия из обеих рук, в противном случае только оружия в активной руке" и никто её включать не будет. Потому отключу.

Не, нема. Дак напиши на гитхабе чтобы в следующей версии исправили чтение аргументов для v# функций.
Не знаю, кстати, чего ты так с небезопасными функциями возишься — требуют отладочного режима и AllowUnsafeScripting=1, что может вызвать проблемы у конечного пользователя, Лучше на том же гитхабе понапрягай на предмет добавления новых опкодов для этих дел.

Плохо чекал там еще макросы на это дело надо чекать. Есть Стивен и охранники в брокенхилз которые говорят чтобы игрок спрятал свое оружие — иначе говорить отказываются.
С одной стороны это правильно, что надо убирать стволы из слотов рук, с другой стороны это лишние телодвижения для игрока.
Я попросил это доработать для того чтобы можно было использовать эту функц. к примеру для реализации скриптового предмета на подобии зеркальных очков которые на двиг завязаны.
В идеале конечно для этого нужно бы новый опкод делать — но кто это будет делать?! — наши зарубежные "друзья" настолько ленивые, что и писать там нет желания — ну или ответят в стиле в этом нет смысла. (с) Phobos :)
вот что написал NovaRain на NMA

зайди почитай, там последние сообщение от меня, я еще полгода назад просил добавить поддержку для LOOT/USE интерфейса.

Отправлено: 7 мар 16 20:03

А чем отличается вызов по этим адресам, от введения нового опкода который как я понимаю будет ссылаться на этот адрес?

ps научи меня ковыряться в движке)

Макросы тоже и с оружием понятно, меня интересовало есть ли в скриптах именно проверка наличия не_оружия в активной руке, чтобы после "исправления" это не оказалось сломанным. Обнаружились только очки — если в активной руке, то в диалоге с левым мужиком добавлялся несущественный вопрос. Это можно игнорировать (я даже посчитал это исправлением), ну с оружием игроку конечно пришлось бы возиться, убирая из правой и левой руки при всяких critter_is_armed.
А оригинальную доработать нельзя — она в движке. Только через новый опкод.
Для аналога зеркальных очков просто такой же pid присваивай своему предмету, получишь +1 удачу, ну как амулет дикарей в Неваде сделан.

Именно что ничем ;) От AllowUnsafeScripting нужно отказаться, перевести небезопасные функции в обычные, чтобы была возможность эмулировать нужный функционал при отсутствии аналога в виде опкода.

Доступна же IDB-база с оригинальными названиями функций и переменных.

В неваде амулет вместо очков, и поменяли в двиге с харизмы на удачу.
А я говорю о добавлении к очкам еще какого-либо предмета аналогично очкам который может давать к примеру +1 к восприятию.
И что значит "просто такой же pid присваивай своему предмету получишь +1 удачу" не совсем понял это, типа два предмета с одним и тем-же пидом? — это что-то новенькое)

Да, запамятовал уже какой там стат в оригинале. У очков и амулета одинаковый пид, поэтому амулет движково обрабатывается. Хочешь себе перстень с нужным статом — меняй название/описание очков, правь чутка байт в движке для нужного стата и выйдет "такой же pid присваивай своему предмету". А для нового предмета через скрипт конечно, те же хуки.
А чем бы critter_inven_obj помог в этом случае?

Мне вот что интересно — использует кто-то sfall'овские функции, а в скрипте делают проверку что sfall, да ещё и нужной версии установлен? Чекнул sfall_ver_* — сломаны.

Не нашел подходящего хука для этого дела, только если hs_inventorymove (не тестировал его в деле конечно) но я так понял в теории оно не сработает если скриптом убрать предметы из рук игрока, т.е. если там будет лежать наш предмет то вероятно стата так и останется в +1 (до очередного срабатывания хука).
а critter_inven_obj сейчас вполне выполняет эту поставленную задачу.

Я как то хотел делать проверку на версию сфала, но потом плюнул — посчитал это лишним. думаю навряд ли ее кто-то юзает иначе бы ее починили)
Кстати вот хотел тебе предложить чтобы с помощью этой команды твоя версия возвращала какой-нибудь опознавательный знак, что используется длл не оригинальна — ну мало ли вдруг в коде скрипта придется обходить какой-либо код завязанный на не оригинал.

Можешь напомнить о чем речь?

о я накастовал нашего "зарубежного" друга).
©Phobos — теперь будем знать это магическое слово))

Гуру скриптов, подскажи как получить указатель на предмет который лежит в неактивном слоте(руки) у игрока — может я не знаю секрета, да голову тут всем забиваю.
знаю, что через хук hs_inventorymove можно получить указатель, НО только тогда когда игрок его кладет в слот.
А в определении неактивного слота проблем нет, спасибо за Active_Hand()

Эмм, я вроде тебя не о чем не просил, по крайней здесь и в этом году)

to Crafty

Так я чего-то не понял, ты же ее(critter_inven_obj) уже доработал.
(dll от 6-го марта).

hs_removeinvenobj ещё к hs_inventorymove, но видимо нужно просто свои обработчики через register_hook_proc вешать.

А на следующий день закомментировал в коде это "изменение":

Потому как изменение удобно для скриптописателя, но для простого игрока потребует убирания оружия из рук, а если добавить переменную в ini, то игрок её включать не будет из-за лени.
В общем нужно или оставить изменение или добавить новый опкод (конечно если аналога нет).

Phobos

critter_inven_obj для не_игрока вернёт указатель на предмет (если он конечно есть в руке) лежащий в любой опрашиваемой руке, но для игрока указатель вернётся только если опрашиваемая рука является активной, в противном случае вернёт NULL (даже если в опрашиваемой неактивной руке есть предмет).

так я к тому и клоню, что обычным юзерам ее включать и не стоит — это для скриптеров такое баловство позволено)

А аналога нету(или я по крайней мере не в курсах как можно это реализовать) можно конечно было бы на хуке hs_inventorymove сделать, но он не сработает если применить скриптово unwield к ГГ — и даже совместно с новым хуком hs_invenwield ситуации не поможет — ибо у ГГ он не возвращает указатель на объект который был снят со слота. arg2 всегда равен НУЛЮ.

это не то. из описания следует что хук срабатывает при удалении/перемещении предмета из инвентаря объектов — слоты там не приделах.

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

Bugs.cpp, в конце файла. Но я включил это изменение в отладочной версии dll.

То-то, попробуй :-p (тебя должен заинтересовать 4 аргумент описанный как RMOBJ_DROP в sfall.h, не хочу убивать кучу времени на попытку написания скриптового примера).
Это для игрока предметы в слотах выглядят как отдельные, а фактически они лежат в инвентаре, только у них стоят флажки принадлежности слоту (броня, правая/левая рука) по которым движок определяет что рисовать в слотах.

кстати зачем ты создаешь две версии длл?

Я это не делал:

Не может sfallgv.sav создать, а если откат на старую версию сделать?

То есть если отсюда скачать архив, заменить ddraw.dll в каталоге игры на dll из архива, то перестаёт sfallgv.sav создавать?

А sfallfs.sav создаётся?

А в 3.7 или со старым 1.4?

Pid'ы машины(33555441) и багажника(455) там что ли поменяли? (фикс заключается в проверке конкретных пидов).

Может проблема в том что ты сохранился на старой, а теперь на новой имеешь проблемы?
У меня нет никаких проблем с новым 1.5.6

Судя по названию, там хранятся данные о глобальных переменных сфалла, которые используются в скриптах. И это критически важно, поскольку, если он не может их сохранить, то и в скриптах при вызове той или иной сфаллической глобальной переменной она будет возвращать только 0.

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

Можешь для этого сделать вкл/выкл фикса бага в ini?
в мегамоде поменяли пиды на машину.
я же думаю там это не сложно поставить строчку, да? :)
if (GetPrivateProfileIntA("Misc", "CarChargeFix", 0, ini)) { }


Отправлено: 12 мар 16 15:02
И еще если можешь разъясни что за расширение, и что за изменение ты внес

Отправлено: 12 мар 16 16:05
И еще не большое замечание — если на предмете стоит флаг NoHighlight то он подсвечивается как контейнер серым.

Потом попробую дурным способом сделать.
sfall'овский CarChargingFix добавил.

Nordan

Это всё не то, сообщение о ошибке выводится только если не получается [пере]создать sfallgv.sav (другой процесс "держит" его):

Отличие в коде между 1.5 и 1.5.6 по части записи сфалловской информации в файл визуально-косметические, ну вроде замены "HANDLE h=CreateFileA..." на "HANDLE h = CreateFileA...". И с ини-файлом такая же история.

Сообщение о ошибке выводится при первой записи игры сразу после загрузки/начале новой игры или же можно загрузить/начать новую игру, один раз нормально записать, а второй и следующие уже пишут про ошибку?

Так или иначе, я добавил в отладочную версию пару информационных строк. В каталоге игры будет создаваться файл sfall-log.txt, из него интерес представляют несколько строчек: "Saving game: D:\Games\Fallout2\data\savegame\slot06\sfallgv.sav" (вид конечно зависит от путей и номера слота) и, если запись невозможна и в информационном окне игры выводится сообщение о ошибке, то добавится ещё две: "ERROR creating sfallgv!" и "sfallgv.sav: номер_ошибки". Вот хочется взглянуть на пути и номер_ошибки.

Я эту бяку у тебя нашел здесь...

поэтому решил по тестить бой, может чего с ним связанно — и как обнаружилось читай выше)

Так и задумано, у всех контейнеров этот флаг стоит.

В скриптовом define.h определены COMBAT_SUBTYPE_*, но движком все не используются. Ray здесь предложил исправление, чтобы движок помимо COMBAT_SUBTYPE_HIT_SUCCEEDED ещё обрабатывал COMBAT_SUBTYPE_WEAPON_USED. Это нужно, к примеру, для мода в котором учитывается износ оружия при каждом его использовании. Удачные попадания обрабатываются с помощью COMBAT_SUBTYPE_HIT_SUCCEEDED, а вот промахи — нет. Дополнительная обработка COMBAT_SUBTYPE_WEAPON_USED и должна решить эту проблему. Но нужна правка скриптов, что-то вроде:

Я же просто переписал его вариант (сравни Combat_p_procFix в оригинальном sfall с apply_damage_hook в моём main.cpp).

Пичалька конечно. Это фикс рудиментарного бага "с форсированным (подбросить взрывчатку и покинуть карту до взрыва) использованием взрывчатки если взрыв задевает кого-либо рядом, возвратом на карту и снова выходом с карты.". Пока отключил, проверяй. Потом перепишу.

Путь проверят атрибут только чтение на папке.

меня это как бы не напрягает. но а что нельзя проверять по item_subtype ? (есть же под тип контейнеров)

Отправлено: 12 мар 16 20:09

ну разница в коде большая) — все равно я в этом как в темном лесу.
Меня больше интересует механика от этого как-то поменялась?

Ты у себя в конфиге arraysBehavior подефолту лучше поставь в 1

Переписал, включил (в F1-версии тоже).

Если сравнивать функционал моего кода с кодом Ray'а — нет. Но с момента добавления этого фикса (v1.20 оригинального sfall) изменилась обработка скриптовых combat_p_proc, в которых нет точной проверки на COMBAT_SUBTYPE_HIT_SUCCEEDED. То есть до фикса:

срабатывал только при попаданиях, а после фикса ещё и при промахах.

Вроде раньше это тут обсуждали, но не помню к чему пришли :-p

Отправлено: 12 мар 16 23:18

А dll'ка отладочная (из каталога debugging)?

Ну если не лень ;)

на 16 странице.
фобос писал

в 3.7 там в 1 поставлено.

0 — backward compatible with pre-3.4, 1 — permanent arrays don't get stored in savegames by default ©.

чаво?
>>> Обратной совместимости ПРИМЕЧАНИЯ <<<
Для тех, кто использовал массивы в своих модов перед sfall 3.4:
1) Существует параметр INI "arraysBehavior" в разделе "Разное" в ddraw.ini. Если установлено в 0, все сценарии, которые используются массивы, прежде чем sfall должно работать. В основном это изменения, которые "create_array" будет создавать постоянные массивы, которые "сохраненные" по умолчанию и их ID также постоянным. Это по умолчанию 1.
2) Как сохраненных игр Совместимость обрабатывается?
Сохраненные массивы хранятся в sfallgv.sav файла (в сохраненной игры) в новом (более гибкого) формате, сразу после старых массивов. Так в основном, когда вы загружаете старую сохраненную игру, sfall будет загружать массивы из старого формата и сохранять их в новом формате на следующей игре энергосбережения. Если вы загрузите сохраненную игру, сделанное с использованием sfall 3.4 sfall 3.3 (например), игра не должна врезаться, но все массивы будут потеряны.
3) Ранее вы были указать размер в байтах для элементов массива. Этот параметр в настоящее время игнорируются, и вы можете хранить строки произвольной длины в массивах.

Отправлено: 13 мар 16 00:15

Вырубай эту бяку — теперь после загрузки они просто стоят)
По ощущении после загрузки как будто игра принудительно ГГ выводит из боя и потом снова входит в бой. и можно закончить бой.
В чем фишка этого фикса — недать гг положить бомбу и смыться?

patch000.dat чего это за путь такой дебильный?
должен быть
Loading save game: data\savegame\slot05\sfallgv.sav

Создал такую папку и получил ошибку при записи.
Тут вопрос почему сфалл пишет в папку patch000.dat а не в data ?

Проще на английском прочитать, чем после гугл-транслейт :)

Сейчас точно исправил, зуб даю :-p

Устанавливаешь таймер на динамите, подкладываешь жертве, возле которой есть кто-то ещё и его заденет взрыв и он останется жив (я для тестов использовал девицу-крупье в баре-казино Бекки, что в Дыре. Ту, которая ближе к входу в подвал, к ней ещё охранник ходит. Чтобы взрывом задевало всех вокруг, но охранница в углу живой оставалась). После подкладывания бомбы, до взрыва, делаешь ноги в другую зону, возвращаешься назад и снова выбегаешь — ловишь краш.

kotmatposkin

> 3: Системе не удается найти указанный путь.©
А в fallout2.cfg какие строки в critter_patches и в master_patches? (у меня там D:\Games\Fallout2\data).

Я тут потестил бомбочки (с подкидыванием и покиданием карты до взрыва) выяснилось что у уничтоженного непеся при выходе из карты не срабатывает damage_p_proc(и соответственно не извещает столько ему нанесло повреждений) — но срабатывает destroy_p_proc.
Тебе тут еще по хорошему нужно в source_obj передавать указатель, чтобы в обработчике destroy_p_proc это можно было получить его, и узнать отчего умер непесь.
только я во тут даже не знаю какой указатель передавать предмета или самого гг, надо логически подумать... Правильнее будет указатель на ГГ.

Ну бой больше не глючит.
НО 1 раз было такое, что во время загрузки нпс "отошел по своим делам" — т.е. у нпс в скрипте указано вернуться на свое место на карте, и пока там что-то происходит(во время загрузки как будто игра принудительно ГГ выводит из боя и потом снова входит в бой) в этот момент нпс успел отойти от меня на некоторое расстояние, пока игра опять не вошла в режим боя.
может конечно это сам двиг так иногда глючит — по крайней мере больше такого эффекта не появлялось.