Сообщений в теме: 1246

[Crafty]

QUOTE

На новой версии ошибка, есть идеи в какую сторону копать?))

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

QUOTE

P.s. Проверил, действительно на новой версии не создаётся sfallgv.sav.

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

[Fakeman]

Здрасьте!
В HRP есть очень полезная опция позволяет прокручивать инвентарь цели колесиком мыши предварительно наведя мышь на слот инвентаря цели но при этом не используя зажим клавиши контрл — но вот беда при ее активировании что-то ломается в сфале и перестает работать обработчик хука MouseСlick можно это как-то пофиксить или сделать что-то подобное в самом сфале?

CODE

Set ALT_MOUSE_INPUT=0 to allow Sfalls mouse input functions to work. ; Set ALT_MOUSE_INPUT=1 to enable alternate mouse input control built into the hi-res patch. ALT_MOUSE_INPUT=0 ; Set SCROLLWHEEL_FOCUS_PRIMARY_MENU=1 for inventory, barter, loot screens etc. to make mouse wheel control default to the PC's item list unless the cursor is hovering over another list. SCROLLWHEEL_FOCUS_PRIMARY_MENU=1

Это сообщение отредактировано Fakeman - 10 марта 2016 | 23:00

[Pyran]

sFall2 v1.5
Megamod 2.44.2 (пока только здесь, о других отпишусь позже) — при использовании dll от Crafty, машину невозможно заправить. Меняю на обычный 3.6 все работает.

[Fakeman]

QUOTE

Меняю на обычный 3.6 все работает.

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

CODE

>Added a fix for the original engine issues with being able to charge the car with using cells on scenary/critters and cells getting consumed even when the car is already fully charged.

Это сообщение отредактировано Fakeman - 11 марта 2016 | 01:03

[Crafty]

QUOTE

Megamod 2.44.2 (пока только здесь, о других отпишусь позже) — при использовании dll от Crafty, машину невозможно заправить. Меняю на обычный 3.6 все работает.

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

[Fakeman]

скорей всего поменяли, так как в 3.7 тоже не робит.

Это сообщение отредактировано Fakeman - 11 марта 2016 | 03:01

[kotmatposkin]

Собственно да, перестает создаваться sfallgv.sav на новых версиях (последнюю перекачал попробовал, тоже самое, та же ошибка), на старой 1.5 такого нет и всё нормально создается и ошибки нет.

[Fakeman]

QUOTE

Собственно да, перестает создаваться sfallgv.sav на новых версиях

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

[Nordan]

ЕМНИП, в сфалле есть 2 вида сохранения глобальных переменных — старый и новый. По умолчанию в новых версиях стоит новый вид сохранения, но в ИНИ файле есть возможность использовать старый метод сохранения, может это поможет.

Это сообщение отредактировано Nordan - 11 марта 2016 | 17:50

[kotmatposkin]

При сохранении новой игры на новом сфалле, то же самое, ошибка. А не могли бы подсказать где сия строка в ини файле (использовать старый формат сохранения)? arraysBehavior — вот это? Менял толку нет, вообще интересно почему такая проблема. С чем может конфликтовать в теории сфалл?
И ещё вопрос, что может быть соббсно без файла sfallgv.sav?
Заранее, еще раз Всем Спасибо!

Это сообщение отредактировано kotmatposkin - 11 марта 2016 | 18:59

[Pyran]

И так, попробовал новый sFall 1.5.6
Все вроде работает и с настройками из 1.5 и с дефолтными настройками 1.5.6
но при сохранении (быстром) выдает такое сообщение
фото
но спокойно сохраняется/загружается.

p.s.
кажется все дело в конфиге (ini), заменил только dll оставив нетронутый конфиг, такого срама не вылезает.

Это сообщение отредактировано Pyran - 11 марта 2016 | 23:53

[Nordan]

QUOTE

И ещё вопрос, что может быть соббсно без файла sfallgv.sav?

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

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

Это сообщение отредактировано Nordan - 12 марта 2016 | 11:33

[Fakeman]

QUOTE

// Исправление "заправки" не_автомобиля и использования топливных элементов даже когда бак полный MakeCall(0x49C36D, &protinst_default_use_item_hook, true); MakeCall(0x49BE70, &obj_use_power_on_car_hook, false);

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


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

CODE

//Ray's combat_p_proc fix - в действительности это не фикс, а расширение функционала combat_p_proc //Однако, чтобы получить профит от этого нужно править скрипты SafeWrite8(0x424DC7, 0x00); MakeCall(0x424DD9, &apply_damage_hook, false); // SafeWrite8(0x424EA1, 0x00); // MakeCall(0x424EB3, &apply_damage_hook, false);

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

[Crafty]

Fakeman

QUOTE

В HRP есть очень полезная опция позволяет прокручивать инвентарь цели колесиком мыши предварительно наведя мышь на слот инвентаря цели но при этом не используя зажим клавиши контрл — но вот беда при ее активировании что-то ломается в сфале и перестает работать обработчик хука MouseСlick можно это как-то пофиксить или сделать что-то подобное в самом сфале?

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

Nordan

QUOTE

ЕМНИП, в сфалле есть 2 вида сохранения глобальных переменных — старый и новый. По умолчанию в новых версиях стоит новый вид сохранения, но в ИНИ файле есть возможность использовать старый метод сохранения, может это поможет

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

CODE

HANDLE h = CreateFileA(buf, GENERIC_WRITE, 0, 0, CREATE_ALWAYS, 0, 0); if (h != INVALID_HANDLE_VALUE) {  пишем всякую сфалловскую информацию в файл } else {  cсообщаем о ошибке "ERROR saving extended savegame information... бла-бла-бла" }

Pyran

QUOTE

Все вроде работает и с настройками из 1.5 и с дефолтными настройками 1.5.6

Отличие в коде между 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: номер_ошибки". Вот хочется взглянуть на пути и номер_ошибки.

[Fakeman]

Еще какие-то проблемы всплыли в версии 1.5.6 при сохранении в бою
и последующей загрузки начинается дикая вакханалия в бою т.е. все нпс начинают мутузить какую-либо рандомную выбранную цель из НПС на карте, при этом на игрока не обращают внимания, типа они думают что это игрок))
После того как они добьют свою выбранную жерту они не реагируют на игрока, тут же в бою делам новое сохранение и загружаемся, все сразу агрятся на игрока, делаем очередное сохранение, загружаемся — НПС не реагируют стоят как вкопанные.
(некоторые НПС (тоже рандомно) все-же не перестают нападать на игрока)
Тут же я меняю сфалл на старый 1.4 (или 3.6 / 3.7) загружаю данный бой все нормально.
даже со старым 1.5 от 27 февраля 2016 г. 1:18:35
такая же беда после сохранения в бою.

Реально ты там что-то серьёзно все поломал! и по ощущениям что-то при загрузке в бою.

(на всяк случай в ini установлено SaveInCombatFix=1)

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

CODE

HANDLE h = CreateFileA(buf, GENERIC_WRITE, 0, 0, CREATE_ALWAYS, 0, 0); if (h != INVALID_HANDLE_VALUE) {  пишем всякую сфалловскую информацию в файл } else {  cсообщаем о ошибке "ERROR saving extended savegame information... бла-бла-бла" }

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

CODE

void LoadGameHookInit() { GetPrivateProfileString("sfall", "SaveInCombat", "Cannot save at this time", SaveFailMsg, 128, translationIni); SaveInCombatFix = GetPrivateProfileInt("Misc", "SaveInCombatFix", 1, ini); if (SaveInCombatFix < 0 || SaveInCombatFix > 2) SaveInCombatFix = 0; GetPrivateProfileString("sfall", "SaveSfallDataFail", "ERROR saving extended savegame information! Check if other programs interfere with savegame files/folders and try again!", SaveSfallDataFailMsg, 128, translationIni);

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

Это сообщение отредактировано Fakeman - 12 марта 2016 | 20:26

[Crafty]

QUOTE

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

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

QUOTE

еще если можешь разъясни что за расширение, и что за изменение ты внес QUOTE //Ray's combat_p_proc fix — в действительности это не фикс, а расширение функционала combat_p_proc //Однако, чтобы получить профит от этого нужно править скрипты

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

CODE

procedure combat_p_proc begin if (fixed_param == COMBAT_SUBTYPE_HIT_SUCCEEDED) then  begin   count_weapon_used = count_weapon_used + 1;  end else if (fixed_param == COMBAT_SUBTYPE_WEAPON_USED) then  begin   count_weapon_used = count_weapon_used + 1;  end end

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

QUOTE

Реально ты там что-то серьёзно все поломал!

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

[Fakeman]

QUOTE

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

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

QUOTE

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

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

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

QUOTE

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

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

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

Это сообщение отредактировано Fakeman - 12 марта 2016 | 20:20

[kotmatposkin]

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

[Crafty]

QUOTE

Реально ты там что-то серьёзно все поломал! QUOTE Пока отключил, проверяй. Потом перепишу.

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

QUOTE

Меня больше интересует механика от этого как-то поменялась?

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

CODE

procedure combat_p_proc begin count = count + 1; end

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

QUOTE

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

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

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

QUOTE

Собственно забавно, перекачал, текстового лога нет и походу не создается, проверил. Ошибка возникает и при новой игре (запись) и при старой (записывает и загружает, но файла sfall нет в сохранении)

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

QUOTE

Я вот что думаю, может мне архивом сборку эту скинуть? Возможно как то облегчит?

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

Это сообщение отредактировано Crafty - 15 марта 2016 | 01:25

[Fakeman]

QUOTE

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

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

QUOTE

Не согласен. Массивы в старом стиле потенциально опасны и замусоривают сохраненки. И какие многие моды их используют? Из всех тех что я видел, почти никто не использует, за исключением временных массивов (temp_array), которые данная настройка не касается.

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

Это сообщение отредактировано Fakeman - 12 марта 2016 | 23:33