Форум Stalker Simbion Mod

Всё, что написано ниже является имхо, написано для разгрузки рабочей ветки от "мусора"
Слово Lisaa:И вот мы вернулись к своим баранам........
(не хвалюсь а просто напоминаю прошлое) весна-лето-и часть осени прошлого года:
ARTOS усиленно занимается сборкой, RedFox и Lisaa ВСЕ (!!!) ночи напролёт занимаются отлавливанием ошибок\багов\глюков и стабилизацией оных сэйвами. Одного только Крота на локе БАР ТРИ дня ловили. И в ТД чуть-ли не поштучно выщитывали кол-во критическое тушканов. Попутно я по мере наличия свободного времени отвечаю на все вопросы всех подрят вопрошающих на СП тем самым снимая\разгружая ARTOSа от этой рутины, тем самым он может не отвлекатся на флуд\бред\идиотов и заниматся только сборкой.
Вспомните с какой скоростью выходили обновления фиксы-минификсы.....
На данный момент ни я ни RedFox не имеем возможности\времени заниматся этим-же так плотно как раньше. Других бесплатных помошников на горизонте что то не видать....
ARTOS правильно акцентирует внимание на логах и сэйвах - без них нихрена не получается!!
Для тех у кого всётаки есть желание и время помогать в режиме реальной помощи небольшая инструкция:
1) устанавливаем игру, мод, последний вариант фикса, мини-фикса - И БОЛЕЕ НИЧЕГО!
( как вариант допускается втулить в продажу Сидору пару артов и один ствол)
прим. желательно этого не делать, если точно не знаешь КАК это сделать правильно
2) запускаем игру и НЕ ТОРОПЯСЬ выполняя ВСЕ квесты\задания, читая все подряд диалоги, откликаясь на все просьбы идём по игре. С периодичностью нажимая F6 (иль чё там у кого). При этом точно запоминая что и как вы делаете от сохранки до сохранки чтоб при обнаружении бага сделать ПОЛНЫЙ сейв, перезагрузится и пройти по тому же месту с теми же выкрутасами ещё несколько раз для подтверждения стабильности или рандомности найденного бага. В случае обнаружения графического бага делаем скриншот и сэйв.
3) удостоверившись что данный баг постоянен - выкладываем лог(при наличии), описание ВАШИХ действий перед обнаружением бага, сэйв.
Если баг рандомен, то все равно перегружаемся несколько раз чтоб удостоверится в этом. После этого выкладываем описание обнаруженного бага с вашими действиями перед обнаружением оного.
===============================================
Дополнение (имхо):
- Необходимо хорошо знать не только оригинал, но и саму сборку...дабы не загружать рабочий топик сообщениями типа: "У меня ошибка, бандиты, которые грузят Юрика, нейтралы";
- Уметь устанавливать сборку правильно (см. технические вопросы), знать (или узнать) что такое логи, как их выкладывать;
- Следить за рабочими ветками (вторая находится на С-П), чтобы не забивать рабочий топик сообщениями об уже исправленых багах;
- Выполнять просьбы/требования разработчика, ему виднее, какая задача на данный момент имеет приоритет на исправление;
- Исходя из написанного выше не огорчаться, если вам кажется, что пост с вашим багом не заметили, вполне возможно, что отложили исправление "на потом"

Не пудрите себе и другим мозги!
Уже отвечал пару раз по "битым" сэйвам и опять 25 ...

Немного прописной "истины":
1. "Сталкер" вместе с модами - такое же приложение, как и все другие программы на вашем компе. То, что они могут в процессе работы менять/добавлять свои файлы - прописано в движке/конфигах/скриптах.
Только несколько директорий разрешены 'штатно' для записи/изменения файлов (хотя модом можно добавить ...).
2. В директории сэйвов ("$game_saves$"), которая задана в "fsgame.ltx", игра может писать/сохранять файлы-сэйвы.
3. Сама игра, без ведома игрока может создавать/перезаписывать ТОЛЬКО файл авто-сэйва;
4. По кнопке быстрого сохранения создается/перезаписывается ТОЛЬКО файл квик-сэйва;
5. Существует только один файл "user.ltx", который игра постоянно перезаписывает 'сама', внося в него различные текущие настройки/флаги/имена последних сэйвов/... ;
6. Сэйв, создаваемый игроком с присвоением сэйву индивидуального имени, НИЧЕМ после его создания НЕ изменяется. Если только САМ игрок вновь запишет свой сэйв и этим же именем. Причем игра ПРЕДУПРЕЖДАЕТ о перезаписи!

Т.о. если игрок создал свой сэйв и этот сэйв был рабочим (т.е. с него игра запускалась) и сам игрок 'ручками' НЕ изменял файлов игры/мода и не перезаписывал этот сэйв - его сэйв НИКАК не может оказаться "битым"! (вирусы, дисковые ошибки и пр.чепуху не связанную с игрой я не рассматриваю).
Существует еще вероятность, что вносимые игроком/игрой изменения в файл "user.ltx" могут привести к незапуску игры - но это уже отдельная история, строго индивидуальная для каждого случая, игрока и компа. Лечится банальным пересозданием пользовательского файла (удалить его и игра сама создаст дефолтный) или исправлением в этом файле фатальных изменений.

Резюме:
1. В процессе игры не может быть изменен НИКАКОЙ сэйв (кроме автосэйва) без ведома игрока. Т.е. если сэйв был "рабочим" - он не может стать "битым";
2. Если сэйв(ы), ранее бывший(е) "рабочим(и)" перестал(и) грузиться - а) фатальные для старых сэйвов изменения в "user.ltx" или файлах игры/мода и б) вы запускали новую игру с другим модом и ... создался некорректный "all.sav" - удалите его.
3. Следует НЕ путать действительно "битые" сэйвы, создаваемые в процессе игры (такое возможно при ошибках в кодах), и которые ИЗНАЧАЛЬНО не могут быть "рабочими" 'уже вообще' или без устранения существующей ошибки. Такие сэйвы СРАЗУ битые, а не становятся "битыми" по прошествии ...

"all.sav" стОит всегда 'чистить', если меняется all.spawn или иные глобальные изменения игры/мода/железа, дабы избежать "незапуска" сэйвов или даже новой игры (вспоминаем билд 1935 с "чужим" all.sav в архиве).
По сути, all.sav - это шаблон создаваемый при запуске новой игры и 'привязанный' к данному железу/ПК и кодам (игра+мод), который суммируется с запускаемым сэйвом и если ... то ...

В игре разрабы многое сделали 'странно' с точки зрения игрока. Какие-то моменты и вовсе могут ставить в тупик, если нарушить ИХ логику прохождения. Вот несколько примеров:

Отсупление: Определимся с понятиями (упрощенно):
Alife (а-лайф) - некая дистанция (радиус) относительно ГГ в пределах которого 'жизнь' в Зоне течет своим ходом. В ней учавствует игрок и за ней наблюдает. За пределами этого радиуса почти все (но НЕ все!) действия замирают/замораживаются, непси 'исчезают'. Игра как бы теряет объекты из вида (прекращает их контролировать/управлять/отображать).
Online (он-лайн) - объект в игре (контролируется/управлется) и может быть доступен как в пределах а-лайфа, так и за его пределами, если на то есть причины.
Offline (офф-лайн) - объект как бы в другом измерении его никто не видит (даже если он 'под носом'), не управляется и никак не отображается.

1. В игре сразу же присутствуют взаимозависимые пары квестовых персонажей. 'Лис-Проводник' - первый валяется раненым с самого начала игры и по окончании своей части квестов обязательно исчезает (в офф-лайн), заменяясь вторым (Проводником). Эти два перса НЕ могут быть в игре (в он-лайне) одновременно. Все попытки оставить Лиса в живых до конца игры заведомо обречены на провал. Или он жив и в игре и тогда никакого Проводника и соответственно продолжения сюжета, заложенного разрабама. Или он все одно исчезнет в офф-лайн, а для игрока это одно и тоже, что и 'погиб'.

2. Пара 'Волк и Фанат'. Тут все несколько более логично. Волк после серии квестоы 'уходит' на Склады и его место занимает Фанат. Оба они могут быть в игре (в он-лайне) одновременно, но только на разных локациях.

3. А вот "пара" 'Круглов и Семенов' имеет дополнение в виде 'Круглов-ростокский и Круглов-янтарный' и это совершенно разные персы. Т.е. в игре с самого начала присутствуют ДВА Кругловых и оба в он-лайне, а Семенов (в паре с янтарным Кругловым), как и Лис с Проводником, всегда в противофазе (если один в он-лайне - второй в офф-лайне).
Купец, в твоем случае произошло нарушение логики прохождения игры. 'Круглов на Янтаре' не должен был учавствовать в игре (должен был торчать в своем бункере) и ГГ должен был встрититься с ростокским Кругловым.
Но, если янтарный Круглов ушел с Янтаря и погиб то а) его место на Янтаре занимает Семенов, но(!) ... б) на Ростоке (Дикая территория) Круглов то еще живой! Вот и получаются коллизии/неувязки.

Алгоритм динамических аномалий предусматривал ранее при создании новой игры полное удаление всех 'старых' аномалий, которые не помечены в all.spawn'е как эксклюзивные и замену их новыми аномалиями (естественно на новых местах).
Как то недавно проверял игру при отключенном модуле аномалий и ... при старте новой игры что-то почувствовал ностальгическое по 'стареньким' аномалиям.
При очередном 'ковырянии' в аномальном модуле подумалось: "А для чего при старте новой игры удалять все 'старые' аномалии?" Ведь для рандомности Зоны достаточно менять карту аномалий на 25-50% ...
Решил попробовать сделать так:
а) При старте новой игры удаляются только 25% 'старых' аномалий на Кордоне и 'разбавляются' новыми динамическими до кондиции, определяемой для данного уровня.
б) При выбросе весь 'старый' набор активных аномалий исчезает и заменяется на новый набор, т.о. 1-й же выброс на локации и каждый последующий полностью заменяет расположение и типы аномалий.
в) При заходе ГГ на очередную 'неизвестную' пока еще локацию повторяется п. а) но на данной локации а не на Кордоне.

В общем то может быть и заморочено, но ... дает возможность понастальгировать по оригинальной Зоне .
Минус этого варианта - при сэйве игры ДО выброса и последующем его запуске - игра НЕ помнит какие 'старые' аномалии НЕ удалялись и ... удаляет их.
В обще считаем это чудачеством разработчика и ... если очередная дурь в голову не стукнет вернем строку 529 модуля m_anoms.script из нынешнего вида:

if (get_object_story_id(se_obj.id) or not db.maps_know[db.cur_map_id]) and math.random() > 0.25 then

в более приивычный:

if get_object_story_id(se_obj.id) then

в конфиг-файле модуля динамических аномалий ('m_anoms.ltx') установить коэффициент вероятности заспавнить новую аномалию ('prob' в секции '[params]') в ноль.
Т.о. модуль будет НЕ отключен, хотя и новых аномалий добавляться не будет.
Если ошибка, связанная с 'запертостью' переходов не связана с отключением/удалением уже имеющихся аномалий - то ... и переходы открыты и арты спавнятся.

Сколько уже можно писать(?) о том, что если в скриптах нет опыта и в логе что-то непонятно - НЕЧЕГО удивляться!
С сборке специально:
- в игровом режиме (без 'Debug mode') отключено большинство технологических сообщений.
- в дебаговых режимах специально выводится различная технологическая информация.

Признаком 'технологической' информации сообщения из скриптов мода является начало строки с: "! Unknown command: Info~>:".
Признаком, что строка не несет в себе какой-либо "непонятной" информации является окончание строки на: ":[ ! ]" (infirmation).
Технологичесике строки лога с окончаниями: [?] - означают о том, что не все ясно в некритичных ситуациях предваряющих некое событие (например, стоимость костюма оказалась нулевой).
Технологичесике строки лога с окончаниями: [Warning!] - выводятся в ситуациях, которые потенциально опасны/ошибочны, но не требуют прерывания игры.

Т.о. какие-либо строки помимо заключительных строк секции [FATAL ERROR] , имеющих окончания [?] , [Warning!] или [Error!] нет смысла обычному игроку считать "странными". Их смысл знает только тот, кто вставлял в нужное место вывод в лог.