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

[Zander_driver 10 333]

 

 

Можно отследить потерю предмета (съел) аналогично ручным телепортам

Жуть какая... когда же это прекратится блин.

 

Расскажите мне границы применения Seq-файлов текстур. их на что угодно можно вешать или все же нет?

[Zander_driver 10 333]

Ну как бы да. use_callback вызывается у самого актора, при съедении им итема.

а так же у внешне-лежащих объектов, когда актор их юзает, но не ест

drop_callback - у актора при дропе итема. а не у самого итема.

[Zander_driver 10 333]

 

 

2)

Это же можно самому протестировать)

 

 

Коллбек use_object вызывается только для съедаемых предметов.

Вообще-то еще для юзаемых физ-объектов, когда их юзает актор. У самого актора да, для съедаемых им.

Щас задумался над логикой такого сочетания... это когда мы в выжигателе жмем на рычаг, то рычаг должен по логике актора съесть

 

 

3)

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

[Zander_driver 10 333]

parent вообще то как раз к инвентарным предметам и применяется, возвращая владельца итема.

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

[Zander_driver 10 333]

@Winsor, есть еще вариант создавать объекты GUI-классов с помощью скриптов, и с помощью них же управлять. Тут щас по традиции поднимут вайн что это ненужно и неправильно, я же придерживаюсь позиции что ненужен xml
 А своими методами я лично доволен.

Я подниму вайн, что давно уже нужна статья и хорошая, читабельная рыба. dc

Изменено 1 Мая 2015 пользователем Dennis_Chikin

[Zander_driver 10 333]

[psy_dog_phantom] - фантом, создаваемый зверушками с секцией psy_dog, psy_dog_radar.

Меня порядком удивило, что секция фантома - не прописана в конфиге этих зверушек.

Она что, в движке гвоздями прибита, да? На весь класс SM_DOG_P

 

 

ltx:r_string(id, "description"),

Чтение из конфига. id - секция, description - ключ который читаем.

 

 

 

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

Без ковыряний движка - никак. Альтернативы... поидее будут но не скоро.

[Zander_driver 10 333]

 

 

alife, way - какие еще?

Никакие больше и не надо, только эти.

[Zander_driver 10 333]

, Стесняюсь спросить, а что мешает допустим при каждом входе актора на уровень, проверить сколько на этой локации крыс, и доспавнить скриптом рандомно по локации недостающее количество?

 

У меня вопрос такого характера. Есть в папке sounds энное число файлов по разным папкам. Есть подозрение что какие-то из них не были прогнаны через СДК, т.е. в них не хватает каких-то необходимых для игры данных. среди прочего это приводит к вылетам при обращении игры к этим файлам.

каким инструментом можно вычислить все файлы нуждающиеся в обработке?

[Zander_driver 10 333]

 

 

Открываешь лог\консоль и смотришь, на какие файлы ругается игра

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

 

Еще раз...

 

 

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

Просьба дать вменяемый ответ. А не из разряда "Если у вас какой-то вылет, то наверно посмотрите логи".

[Zander_driver 10 333]

@BoBaH_671, При желании, вообще все и вся в игре можно делать на апдейте, и проверять каждый апдейт кучу условий - почему бы нет?

И утверждать, что все кто делает иначе, "несут ахинею" - вам конечно, никто не запретит. Только не надо потом удивляться, если кто-то ВАМ скажет, что вы делаете и пишете ахинею. Потому что так оно и есть. Для одноразовых действий при появлении актора, кто-то придумал actor_binder:net_spawn. Вам использовать его, религия не позволяет или что?

[Zander_driver 10 333]

 

 

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

Напрасно. На мой взгляд, (личное, субъективное имхо, да), более 50% всех туториалов и уроков, находящихся в сети на различные темы, имеют разные ошибки начиная от незначительных, и заканчивая совершенно недопустимыми огрехами в освещаемой теме.
Так что смотреть не на "уроки" а на реальные работающие примеры, где как и что было сделано - это совет вобщем-то, хороший.

[Zander_driver 10 333]

 

 

проверка по npc:memory_visible_objects()

Не проверка а перебор. С выбором "наилучшего" объекта, к которому нпс и пойдет. Почему для него объект лежащий за 400 метров оказался лучше того что под ногами, это другой уже вопрос.

 

 

но физические объекты не попадают в этот список.

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

[Zander_driver 10 333]

Ну тогда, учитывая что перебор все равно идет по таблице, надо эти объекты туда добавить.

1. Спрашиваем у нпс что он видел, движковым методом, сохраняем это в таблицу.

2. Своей функцией наподобие того что вам уже дали в соседней теме для сталкеров, получаем список нужных физ-объектов онлайн. У физ.объектов так же есть биндер, так что проблем вообще никаких.

3. В watcher_act.script делаем перебор по обеим таблицам, или сливаем их в одну и уже по ней гоняем перебор.

4. Profit

[Zander_driver 10 333]

 

 

Zander_driver, слишком заморочено, лучше сразу физиков на попадание во фруструм проверять и тут же доливать в таблицу, профит сразу.

Ты более коротко и менее понятно для не-сильно ориентирующихся, написал по сути то же что и я.

[Zander_driver 10 333]

@Карлан, Если хотеть немного понять, можно заметить что добавляя в watcher_act поиск физ.объектов, вопрошающий не хотел выкинуть оттуда все остальное что там уже было.

[Zander_driver 10 333]

@BoBaH_671,

Это параметры очередной добавляемой к гулагу работы.

idle - период времени, в течение которого работа недоступна, после того как нпс занимавший ее, по каким-то (любым) причинам ее покинул.

prior - приоритет работы.

state - список состояний гулага, в которых доступна данная работа.

in_rest, out_rest - рестрикторы где быть, куда не заходить. Возможно наоборот) никогда ими не пользовался так что могу ошибаться.

predicate - функция проверяющая, пригоден ли данный предлагаемый нпс, на эту работу. в функцию передается таблица obj_info, хранящая в себе параметры непися. Обычно в предикатах сравнивают профиль нпс с чем-то конкретным, или выясняют является ли он снайпером. Чего-то более необычного в оригинале - не видел.

[Zander_driver 10 333]

 

 

Скрытый посыл тут в том

Можно перед тем как пустить игрока в торговлю, проверить наличие необходимых участников торговли...

[Zander_driver 10 333]

@BoBaH_671, тут почитай: http://www.amk-team.ru/forum/index.php?act=findpost&pid=343515

А вообще...

Скрипт же должен быть.

 

С чего ты это взял? Это просто форма обращения к области памяти. Не обязательно скрипту...

Для наглядности, у себя к примеру такое откопал:

self.map_tex.frame:SetWndRect(tmapmove, 0, tmapwreal, 447)

Это же не означает что "должен быть" self.script или какой-нибудь еще.

[Zander_driver 10 333]

 

 

А то, если на память прикинуть, то помню как минимум 15 тайников, которые повторялись у меня по 2-3 раза, бывало и больше.

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

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

Если еще не передумали такое реализовывать, то вся проблема осталась в том, чтобы сохранить факт выдачи тайника, а при каждом обыске трупа - отсеивать те что уже когда-либо выдавались. Так что проблем тут нет никаких.

А если по хорошему делать - то перекраивать всю систему начиная с фундамента. Что я у себя и сделал.

 

 

 

А как сделать что бы красный военный был не врагом? как для актора так и для других?

Вдумайтесь в сказанное. красный = враг. но не враг? так какое же у него отношение должно быть...

[Zander_driver 10 333]

 

 

Или руками делать запись в custom_data,

И в чем проблема? кто хочет тот пишет.

 

@Vadyanchikus,

 

 

Если еще не передумали такое реализовывать, то вся проблема осталась в том, чтобы сохранить факт выдачи тайника, а при каждом обыске трупа - отсеивать те что уже когда-либо выдавались. Так что проблем тут нет никаких.

Это я тоже вам написал. Если очень хочется, по-копайте в сторону модуля se_stor Артоса, или просто сохранения данных в кастом-дату, как парой строк выше упоминалось. Учитывая что в оригинале тайники - это существующие с начала и на протяжении всей игры, инвентори_боксы, то можно и в их собственные нетпакеты сохранять, был ли он когда-либо выдан/обыскан/еще что нибудь по вкусу.