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

[Niyazovitsh]

Прим.
Этот топик не для игроков, а для тех кому интересно разобраться в сборке и помочь в её создании.
Разраб, возможно в дальнейшем исправит/дополнит этот раздел при наличии времени/желания/необходимости.

Поехали

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

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

Не важно, сколько тратить времени на тест, час в день или сутки напролёт, главное это делать вдумчиво, не торопясь. Только так можно оказать реальную помощь. Занятие не самое благодарное, надоедливое. Но "без труда, не вынять рыбку из пруда"...участие каждого приближает релиз.

Дальше в этой теме будет выкладываться немного специфическая, но полезная для тех кто тестирует сборку информация
(в основном "разъяснялки" Разработчика из рабочих топов сборки).

[Niyazovitsh]

Обязательный при тестировании режим "Дебаг"

Если есть желание действительно помочь, то при тестировании сборки необходимо включать в "Доп. опциях" игры режим "Отладка-1" (режимы "отладка" 2 и 3 включать не стОит, это для Разработчика).
В этом режиме в лог выводится более полная информация об ошибке.

Во всех сборках Симбион (ТЧ/ЧН/ЗП) с недавнего времени режим дебага по умолчанию отключен.
Для его включения необходимо в файле: "\gamedata\config\mods\m_debug.ltx" изменить в секции [params] строку 6:

debug = false
на
debug = true

После этого в меню "Доп.опции" появится третья закладка с управлением режимами дебага.
Для того, чтобы в логе в режиме real-time фиксировались все выводимые строки необходимо включить режим "debug-1". В противном случае при крахе игры последние сообщения консоли могут не попадать в лог-файл.

При выключенном режиме "debug-1", секунды не показываются.

[Niyazovitsh]

"БИТЫЕ СЕЙВЫ" в игре

Artos:

Не пудрите себе и другим мозги!
Уже отвечал пару раз по "битым" сэйвам и опять 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 - это шаблон создаваемый при запуске новой игры и 'привязанный' к данному железу/ПК и кодам (игра+мод), который суммируется с запускаемым сэйвом и если ... то ...

[Niyazovitsh]

Alife (а-лайф);Online (он-лайн);Offline (офф-лайн) ... и ещё чуток об игре:

Artos:
Не хотелось бы заниматься раскрытием технических моментов игры, которые для игрока могут быть и не понятны даже, а вот изменить отношение к игре могут. Но многие из нас уже перешли некий уровень, который и так заставляет смотреть на игру глазами НЕ игроков.

Кто не хочет вникать в 'исподнее' игры, тому лучше не смотреть под спойлером:

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

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

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

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

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

[Niyazovitsh]

Алгоритм динамических аномалий

Artos:

Алгоритм динамических аномалий предусматривал ранее при создании новой игры полное удаление всех 'старых' аномалий, которые не помечены в 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

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

Q(Artos): Да, модуль артефактов завязан на модуле динамических аномалий и без него почти бесполезен.

Для 'хитрого отключения' могу пока посоветовать:

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

[Niyazovitsh]

Немного о логах и иформации в них

Artos:

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

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

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