Перейти к контенту

[SoC] Ковыряемся в файлах


Halford

Рекомендуемые сообщения

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

В общем-то ничего сложного в этом нет, именно по такому принципу работают смарты (работы задаются динамическими ltx, смотрите gulag_general.script). Вопрос в том, не придётся ли респавнить объекты для применения параметров? Хотя, если сделать это в виде переключения режимов огня, то это и не нужно, по идее можно даже класс менять. Надо будет попробовать проделать такое с вертолётом, чтобы, к примеру, он мог бросить что-нибудь типа бомбы (сменить класс на G_FAKE с G_RPG7).

Поделиться этим сообщением


Ссылка на сообщение

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

 

----

И всё равно, в большинстве случаев, водка в руке не появляется - отыгрывается "пустая" анимация.

Проверьте в m_stalker.ltx строку attachable_items. Если водки там нет, то это и есть причина, надо дописать. У меня такая же байда с биноклем - везде заменил binocular_a на wpn_binoc, а он так не работает - идёт пустая анимация.

Изменено пользователем Полтергейст

Поделиться этим сообщением


Ссылка на сообщение

Подскажите, что именно значит такая ошибка:

 

[error]Expression    : fatal error
[error]Function      : CScriptEngine::lua_error
[error]File          : E:\stalker\patch_1_0004\xr_3da\xrGame\script_engine.cpp
[error]Line          : 73
[error]Description   : <no expression>
[error]Arguments     : LUA error: d:\games\stalker\gamedata\scripts\move_mgr.script:250: attempt to call field 'get_anomaly_list_for_pos' (a nil value)

Что именно это значит? Он не видит функцию или же она возвращает nil? Если что, функция на месте (скрипт amk_anoms). Может ли какая-то ошибка в синтаксисе LUA до этой функции вызвать такое безобразие?

 

И ещё один вопрос: я сделал так, что вместо аномалий amk_zone* спавнятся просто zone_* (динамические аномалии), так вот, во втором случае из них появляются артефакты. Как-то так само собой получилось, что их появляется много, и в такой ситуации почему-то очень косячат диалоги (просто не отображаются некоторые фразы для ответа, например "До встречи". Как только менаю обратно на amk_zone* - глюк исчезает вместе с большим количеством артов. Как это может быть связано между собой?

 

Добавлено через 22 мин.:

И ещё одно наблюдение: динамические рестрикторы у меня снова заработали, правда, только для монстров (людей до этого перевёл на схему anomaly_evader). Теперь я понял, почему они слетают. Похоже, что это первый признак перегрузки стека - функции add_restrictions() и remove_restrictions() из-за этого просто перестают работать.

 

Нашёл в скриптах немало функций, которые попусту перебирают все объекты и тратят на это время. Выглядят они так:

for i = 0,65534 do
  if level_object_by_id(i)~= nil then
--' Какое-то действие
  end
end

Для этих целей есть таблица db.creatures, было бы логичнее использовать её, т.к. там только онлайн-объекты.

Изменено пользователем Полтергейст

Поделиться этим сообщением


Ссылка на сообщение
Привет всем. Кто подскажет, как заставить один гулаг напасть на другой?

Очень просто - в customdata всех нападающих неписей прописать:

 

[smart_terrains]
имя смарта, в котором отряд до нападения = {-инфопоршень - сигнал к атаке}
имя смарта, на который надо напасть = {+инфопоршень - сигнал к атаке}

Кстати, кто-нибудь знает, какой скрипт читает секцию smart_terrains и разбирает всё это дело? А то я что-то кроме xr_wounded ничего не нашёл...

 

P.S. этот метод не пойдёт, если нужен любой состав смарта (т.е. если в нём любые неписи, а не только те, которым всё это дело прописано). Можно сделать и это, но если ответ на вопрос (который чуть выше) не будет найден, то придётся возиться с net_packet().

 

P.P.S. Кто знает, уменьшатся ли проблемы со стеком, если снизить настройки графики?

 

так и называется: smart_terrain.script. Куфзук

Изменено пользователем Куфзук

Поделиться этим сообщением


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

Тогда без ковыряния smart_terrain.script тут никак не обойтись. Я делал как-то, чтобы неписи не прописывались во враждебном гулаге, это не сложно. Но здесь вопрос поставлен немного по-другому - сделать, чтобы они наплевали на счётчик свободного места в смарте и шли всё равно. Надо будет доделать это как-нибудь, вряд ли есть другие способы.

 

Чтобы шли "с оружеем на изготовку", надо, чтобы они заранее заметили врага. Иначе приётся ковырять многострадальный state_mgr.script, чтобы непись всегда был в состоянии "danger", пока не займёт смарт.

 

gamedata\scripts\state_mgr.script:194: C stack overflow

Скрипт этот перегружает стек. Не знаю как и почему, там дофига evaluator'ов и в связи с этим разбираться с ними нелегко. Бывает, что вылетает без лога.

Если перенести state_mgr из ЗП, то вылет пропадает, но полностью перенести его пока не получилось, для этого нужен кто-то, кто хорошо разбирается в evaluator'ах.

 

@"StreloK"

~~~ nil self.object in motivator_binder

 

Замените функцию xr_motivator.AddToMotivator(npc) на такую:

function AddToMotivator(npc)

if alife() and npc ~= nil then

npc:bind_object(this.motivator_binder(npc))

end

end

Если не поможет - сносите свои правки, я как-то тоже доправился, что командир военных на кордоне и двое спецназовцев были фактически без биндера (вернее, без self.object'а для него) и глючили.

Изменено пользователем Полтергейст

Поделиться этим сообщением


Ссылка на сообщение

Эта функция отвечает за добавление биндера к неписю. Я просто поставил проверку на npc == nil, чтобы биндер не создался по ошибке "сам по себе". Но вряд ли это поможет, у меня такое было с военными на кордоне. Проблему решил удалением трёх глючных неписей из all.spawn - всё заработало. После этого несколько раз изменял свои правки, попробовал этих неписей вернуть - вернулись без проблем, таких глюков нет.

 

P.S. вычислить глючащего npc можно так: начать новую игру (или перейти на тот уровень, где глючит), сохраниться и попробовать загрузить это сохранение. Если будет ошибка ""SAVE FILE IS CORRUPT", то это хорошо. Далее, в xr_motivator, в функции загрузки, надо найти

  if reader:r_eof() then
    abort("SAVE FILE IS CORRUPT")
  end

и заменить на

  if reader:r_eof() then
    abort("SAVE FILE IS CORRUPT! NPC: %s", self.object:name())
  end

 

При чтении self.object ещё не обнулился и можно отследить имя глючащего.

Изменено пользователем Полтергейст

Поделиться этим сообщением


Ссылка на сообщение

Помечу-то SChecker ругается на amk_offline_alife, выдаёт "invalid floating point operation". Если убрать из скрипта сравнение с числом 4294967296, то ошибка уходит. Что это значит?

Поделиться этим сообщением


Ссылка на сообщение

Подскажите, как переделать amk_anoms.script, чтобы статус аномалии сохранялся не в customdata, а в специальном поле серверного объекта? А то у меня ерунда какая-то получается...

Вчера переделал. Сделал поле status для se_zones.se_zone_anom, поставил в сохранение/загрузку, но при ковырянии amk_anoms наделал ошибок. Первая ошибка - хотел перенести проверку на состояние del вместе с удалением объекта на обновление binder'а и благополучно забыл. В результате аномалии появлялись, но не удалались (кстати, играть от этого стало трудно, но интересно

:) ). Сегодня поправил, но обнаружил ещё один досадный баг непонятной причины: в функции net_spawn(sobj) почему-то нельзя запросить поле sobj.status, пишет, что оно равно nil, хотя это не так. Пришлось переносить всё это дело в серверный объект. Успешно перенёс, но теперь почему-то всем аномалиям присваивается статус del и они удаляются. В чём тут дело - никак не пойму.

 

Поделиться этим сообщением


Ссылка на сообщение

Призрак

Можно ли узнать попал ли актор в какой нибудь спейс?

А в чём проблема? Пишем:

local actor_v_zone = npc_in_zone(db.actor, zone)

где zone - это restrictor, который надо проверить.

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

Поделиться этим сообщением


Ссылка на сообщение
Не npc_in_zone(db.actor, zone), а

utils.npc_in_zone(db.actor, db.zone_by_name[sZoneName])

Это одно и то же. При вызове npc_in_zone(db.actor, zone) zone - клиентский объект restrictor'а, а не его имя. При таком обращении

db.zone_by_name[sZoneName]

мы как раз получим этот объект из таблицы.

Если "слепить", то получится так:

local zone = db.zone_by_name[sZoneName]
local actor_v_zone = npc_in_zone(db.actor, zone)

А если нам нужно имя restrictor'а, в котором находится actor, то

local inside_zones = {}
for name, zone in pairs(db.zone_by_name) do
  if npc_in_zone(db.actor, zone) == true then
    inside_zones[name] = true
  else
    inside_zones[name] = false
end

Поделиться этим сообщением


Ссылка на сообщение
ЗЫ:npc_in_zone() это же не глобальная функция из _g.script , а ты уже вторично забываешь указать модуля, в котором она находится.

:) У меня эта функция как раз глобальная из _g.script (перенёс для удобства), вот и написал по привычке.

 

смарт терейны находятся в табличке db.smart_terrain_by_id - отдельно от рестрикторов

В таблице рестрикторов они тоже есть - в биндере смарта есть вызов db.add_zone()

Поделиться этим сообщением


Ссылка на сообщение

Хех, только что нашёл решение проблемы обхода аномалий. Просто им нужно присваивать restrictor_type = 2 с помощью net_packet'ов при спавне. Тогда они автоматически добавляются движком в рестрикторы ко всем npc.

 

_Призрак_

Перед этой строкой напишите так:

if db.storage[zone:id()] == nil then
  db.storage[zone:id()] = {}
end

Вылет должен исчезнуть.

Поделиться этим сообщением


Ссылка на сообщение
Да, проверил ещё раз, не работает ни один квест на уничтожение лагеря

А может смарт ещё не работает. Если у него в секции [smart_terrain] в all.spawn есть строка cond с прописанным условием существования смарта и это условие НЕ выполняется, то это и может быть причиной. Попробуйте указать другой смарт или убрать это условие.

Поделиться этим сообщением


Ссылка на сообщение

Заметил баг в схеме xr_camper, а именно - расстояние реакции на опасность маловато. Меньше, чем без схемы. К тому же, NPC не реагирует на раненых, находящихся вне поля зрения - не может подойти и пристрелить, но и разговаривать не хочет. Кто-нибудь знает, как это сделать? А то придётся вообще всю схему переделывать.

 

Ещё нашёл глупый баг в all.spawn на уровне "Подземелья Агропрома". Там в customdata ящиков вместо def_box стоит def_bpx в нескольких местах.

 

P.S. попробовал перенести xr_combat_camper из ЗП, после этого NPC (включая зомби) стали заметно умнее :) Причём скрипт нигде не надо прописывать, он уже прописан - просто перекинуть файл.

Изменено пользователем Полтергейст

Поделиться этим сообщением


Ссылка на сообщение

Министр

И как НПСы должны реагировать на тех кого не видят? И с кем они должны разговаривать?

Было как-то, на мосту вынесли военных, двое раненых за вагоном лежат. Двое сталкеров заняли смарт (там у меня прописаны работы guard, схема xr_camper), раненых не добивали. При попытке поговорить с ними орут, что "тут стреляют, после поговорим".

 

Баг? Расстояние достаточное.

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

 

Может я и огорчу тебя, но в ЗП эта схема не улучшалась.

Так в ТЧ её вообще не было. Была схема xr_camper, она вроде бы действительно не улучшалась. А схема xr_combat_camper появилась только в ЗП (может в ЧН, там не проверял)

 

Похоже, единственное решение - перевести работу guard на схему walker или patrol, что там больше подойдёт. Сейчас пробовать буду.

 

Dennis_Chikin

Гляньте в xr_death.script

Изменено пользователем Полтергейст

Поделиться этим сообщением


Ссылка на сообщение
у меня сейчас ничего не произошло

Уже нашёл кучу объектов с одинаковыми именами, например, тот же clmbl#0 есть на нескольких локациях. Походу это ляп разрабов. Кое-где так спешили, что забыли заменить level_prefix тем, чем надо.

Поделиться этим сообщением


Ссылка на сообщение
  • Недавно просматривали   0 пользователей

    • Ни один зарегистрированный пользователь не просматривает эту страницу.
×
×
  • Создать...