Скриптование

[Malandrinus 615]

Artos,

Довольно "детский" вопрос ...

Что мешает скриптеру НЕ использовать штатные способы получения имени и описания объекта, а написать свои и ими пользоваться в зависимости от ситуации/потребностей?

Ох и тяжелый у тебя характер =) Сразу в лоб: "детский вопрос". Совсем не детский! На стандартные движковые значения завязаны много стандартных же движковых вещей. К примеру часть интерфейса инвентаря, окна диалогов, торговли. Можно конечно завести свои скриптовые значения со смыслом "имя", "описание" и т.п., но в этих движковых диалогах так просто будет не подменить.

 

Выходов из этого есть потенциально несколько, как минимум два.

 

Первый, на самом деле завести чисто свои скриптовые значения. В диалогах придется закрывать поля с движковыми значениями своими окошками со своими строками. Выгода - это чисто скриптовый способ. Недостаток - хлопотная реализация с потенциальными проблемами стабильности работы. Кроме того, если поразмыслить, то это не везде сработает. К примеру, как отследить, что в инвентаре выбран некий предмет, чтобы установить его описание?

 

Второй способ, заменять движковые значения. Штатных средств для этого нет, поэтому это можно делать только модификацией движка. Мы говорим в основном о значениях системного имени, описания предмета, имени персонажа. Все это скриптами доступно только на чтение. Для записи нужно добавлять функции для записи, иногда также в серверный объект. Кроме того, описание с объектом не сохраняется, а каждый раз читается из секции. Поэтому, кроме функции записи, для описания потребуется также некоторая скриптовая обвязка, которая сохраняет это значение в нетпакете объекта и при загрузке прописывает его заново. Достоинства этого пути - это вполне реально и не очень сложно. Недостаток, требуются модификации движка со всеми вытекающими.

[Malandrinus 615]

_Призрак_,

если надо быстро, то забудь про это. Но в самом то деле, зачем выводить быстро и при этом динамически переносить строки? На худ что ли многострочный текст дампить? Думаю, что при выводе на худ лучше как-то решить вопрос компромиссно - самому распределить строки и отформатировать текст.

Если же вывод подразумевается в диалоговое окно, то соображения скорости по большому счету не важны. В этом случае однако нет другого решения, кроме как считать символы и слова и формировать текст с переносами. Дополнительная сложность будет в том, что ширина символов почти всех ходовых шрифтов движка - неодинаковая. Придется делать допущения о среднем размере символа и вводить некий запас, чтобы строка ненароком не вылезла за ширину окна. Ну или сформировать таблицу размеров символов и при суммировании брать размеры из этой таблицы по коду.

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

[Malandrinus 615]

Удаляются рестрикторы, не удаляются... Переведите название функции remove_in_restriction. Речь не о рестрикторах (restrictor), а об ограничениях (restriction). Удаляются ограничения (задаваемые естественно именем рестриктора).

[Malandrinus 615]

Artos,

1. Почему разработчики для "пламени" (zone_flame_small) использовали тип 0 (DefaultRestrictorTypeNone)? ...Ведь тип 2 (DefaultRestrictorTypeIn) продублировал бы запрет на вхождение в костер и может быть снизил бы кол-во поджаривающихся НПС.

Это более-менее понятно. Костёр - это аномалия. Да, у него есть шейп и этот шейп может одновременно работать и как ограничитель. Но есть одна неприятность. Дело в том, что механизм работы аномалии таков, что она срабатывает от касания. Это означает, что непись начнёт жариться, ещё фактически не войдя в рестриктор костра, а только коснувшись его. Просто для справки, по такому же механизму работает левелченджер по отношению к актору.

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

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

[Malandrinus 615]

Artos,

речь шла о том, почему самой аномалии назначают тип рестриктора 0, т.е. как рестриктор не работает. Так? Я об этом и говорил, что самой аномалии нет смысла придавать ещё и тип рестриктора, поскольку это не будет работать. Вне зависимости от формы и размера встроенного в аномалию шейпа аномалия срабатывает раньше, чем срабатывает задаваемый той же формой рестриктор.

 

Почему бокс, а не сфера, сие мне не ведомо. Может схалтурили просто.

[Malandrinus 615]

Artos,

Но, учитывая, что это все же не аномалия, которых немало в зоне и которым специально в модах ставится тип 0, дабы неписи в них попадались, а именно костер, который заведомо виден неписям, то значение 2 просто бы продублировало внешний ограничитель. И, учитывая эмпирические наблюдения, НПС "видит" границу рестрикторов несколько ранее, чем касается их, т.к. видно, как при своих похождениях они именно обходят зоны, а не "коснувшись" границы - начинают обход. Вот это и подразумевал под "может поменьше бы жарились", т.к. возможно "видели" бы не одно, а целых два ограничения.

Да не будут они "видеть" два, поскольку внутреннее не сработает никогда. Они вообще ничего здесь не видят, поскольку касание относится к другому типу сенсоров, тактильному, вдобавок рестриктор - вообще не сенсор, а просто тупой запрет на вход. Видеть аномалию неписи не могут хотя бы потому, что у неё нет визуала и сенсор зрения на неё не сработает.

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

 

Что касается неписей, обходящих аномалии. Лично я наблюдал картину противоположную описанной тобой: непись идёт строго по краю аномалии, а та непрерывно на него срабатывает. Непись не дохнет сразу только потому, что степень удара вроде как зависит от расстояния до центра и на краю существенно меньше.

 

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

 

А халтура (это о форме куба) - обычно делается с целью облегчения ... Но задать сферу, с ее двумя параметрами радиуса и offset'а, гораздо проще, чем четыре для куба ... тем более для пламени все одно сфера применена ... Вот это и смущает, а может есть какой-то скрытый смысл в "халтуре" разрабов? ;-)

Не боги горшки обжигают =) Сказали кому-то расставить костров на уровне и накрыть рестрикторами. Этот кто-то не заморачиваясь натыкал их за полчаса, после чего все об этом забыли. А мы тут скрытый смысл ищем.

[Malandrinus 615]

Artos,

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

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

 

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

Artos,

Мною слово "видят" взято именно в кавычки и даже никак не подразумевает чего то связанного с визуалами.

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

Если шейп аномалии находится внутри шейпа рестриктора, то "увидеть" его невозможно никак, потому что единственный способ, чтобы непись о нём узнал - это коснуться его. Но он же внутри рестриктора, как непись его коснётся? Ну и зачем его включать тогда? Потому и выключен. Это отвечает на твой вопрос "почему не 2, а 0".

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

[Malandrinus 615]

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

 

Это предположение можно проверить, у меня есть идея как именно. Надо будет заняться на досуге.

[Malandrinus 615]

*Shoker*,

Наверно уже обсуждалось, но можно ли, используя level.main_input_reciver(), получить доступ к интерфейсу инвенторя, а конкретно к сетке. на которой находятся иконки предметов. Цель - необходимо перекрасить в игре иконку нужного предмета, например придать ей красный оттенок. Такое возможно?

 

Или же такой вопрос, можно ли в ТЧ\ЧН делать инвентарный предмет "не продаваемым", аналог can_trade = false из конфигов, чтобы предмет при торговле был выделен красным и не продавался. Только делать это надо скриптами, и для конкретного предмета, а не для всех предметов данной секции.

По второму вопросу, есть такие средства в проекте x-ray extensions. По-первому не уверен, но кажется SkyLoader добавил что-то в этом духе.

В чистом движке таких возможностей нет.

[Malandrinus 615]

AndreySol,

Вообще-то я указал, что спаун предмета - скриптовый. Какое отношение к этому имеет ACDC и all.spawn не понимаю.

Информацию из acdc можно использовать при скриптовой перезаписи нетпакета объекта. Эти флажки теми же нетпакетами можно переписать.

[Malandrinus 615]

AndreySol,

Из Вашего ответа, как я понял, следует, что ф-ция alife():create(....) не может создать объект на местности без каких-то граблей ? И в купе с ней необходима правка нет-пакета для такого объекта ?

Несколько некорректно стоит вопрос. Что значит грабли? Функция create имеет в своём распоряжении свои аргументы (координаты) и содержимое секции. Всё остальное задаётся конструктором по умолчанию. Если заглянуть в acdc или аллспавн, то там можно увидеть гораздо больше параметров, которые в данном случае пролетают мимо: задаются как-то или не задаются вовсе. Иногда это срабатывает, а иногда надо имитировать процесс загрузки аллспавна путём перезаписи нетпакета объекта. Типичный пример - аномалии, или объекты с логикой в кастомдате. Общих принципов нет, про каждый конкретный объект в каждом конкретном случае надо знать конкретно, что от него хочешь и что и как надо дописать дополнительно в нетпакете. Для этого и рекомендуют смотреть в аллспавн или acdc. Соответственно, надо хоть на базовом уровне знать, что там. Если занимаешься спавном объектов скриптами, то без этого никак. Надо разбираться.

[Malandrinus 615]

AndreySol,

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

Это вообще не повод для разговоров такого рода. Дизайн системы разработчики делали для себя. С этой точки зрения там всё логично и правильно. Система создания исходно двустадийная. Сначала создаётся объект как программная сущность, в качестве параметра функции создания передаётся имя секции. Из секции читается класс объекта, что уже является указанием создать объект конкретного типа: монстра, сталкера, предмет и т.п., В соответствии с классом читаются общие параметры из секции. На этом создание объекта как именно объекта в программе закончено. Это вполне логичная система, следующая распространённому шаблону фабрики объектов. Далее надо собственно инициализировать объект его конкретными параметрами, что делается уже при чтении этих параметров из аллспавна. Разработчики изначально предполагали, что объекты будут создаваться в SDK, и значит проектировали дизайн системы под эту идею. Те немногие объекты, которые им требовалось создавать скриптами, дополнены кодом инициализации и необходимыми скриптовыми функциями для управления. Надо было бы это для остальных - добавили бы и для них, но им это было не надо.

 

спаун обычного предмета, на обыкновенном грунте(поверхности), на обыкновенной локации - это заморочки моих причуд и похотелок ?

Да, поскольку спавн скриптами произвольного предмета в произвольном месте не входил в планы разработчиков. Можно сказать, что им было плевать на нужды модостроителей (что будет правдой), но нельзя сказать, что это всё криво. С точки зрения разработчиков всё работало как им надо.

[Malandrinus 615]

AndreySol,

данный ящик я планирую использовать единственный раз, в единственном уникальном квесте.

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

 

Из того что я смог найти здесь на форумах я представлял себе это так: непосредственно при вызове 'create' движок создает серверную "часть" объекта.

Это верно

Затем, по "выходу" из ф-ции, в которой вызывали 'create' движок создает клиентскую часть.

Не совсем верно. Эти два события непосредственно друг у другу не примыкают. После создания серверного объекта, при условии нахождения его на том же уровне, начинает периодически проверяться условия его выхода в онлайн, что может включать в себя проверку нахождения в радиусе алайфа от актора, включённость/выключенность некоторых серверных флажков или нахождение в инвентаре актора или другого онлайнового объекта (ящика, непися). Важно то, что эта проверка периодическая (примерно раз в секунду) и срабатывает не сразу после создания серверного объекта. При срабатывании этой проверки создаётся клиентская часть.

 

Он использует уже существующую серверную часть, копируя из нее необходимые данные, или клиентская часть создается самостоятельно ? А затем синхронизируется с клиентской ?

1. Клиентский объект таки создаётся независимо, как независимо ранее создался серверный. Как-то инициализируется. В какой степени, зависит от типа объекта.

Это естественно не всё.

2. Часть данных берётся из серверного объекта.

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

 

Системы здесь нет. Какие из параметров инициализируются по пп. первому, второму или третьему, зависит исключительно от типа объекта и его настроек.

 

[Malandrinus 615]

AndreySol,

Как мне кажется, система как раз то и есть, надо только ее знать для конкретного объекта?

=) Понимаешь, если у каждого объекта система своя, то это и называется - нет системы.

 

Я пробовал для артефакта, примерно так:

...

объект создается и нормально спаунится в инвентарь актора(ГГ), но серверная часть имеет "condition" 35%, как и установлено с помощью нет-пакета, а клиентская имеет "condition" в 100%. После save\load и та и другая части приходят к "condition" в 100%. Значит для такого объекта, на момент создания(спауна), движок параметр "condition" явно не синхронизирует между серверной и клиентской частями ? Подскажите, как это сделать ?

Параметр состояние для всех инвентарных предметов, кроме оружия и брони, не сохраняется в сейве и устанавливается в 100%. Ты можешь состояние клиентского объекта установить скриптом без мудотени с нетпакетами и серверным объектом (есть штатная функция), но оно опять-же не сохранится. Если надо сохранить, то сохраняй самостоятельно и всякий раз восстанавливай при выходе объекта в онлайн.

 

Нашел здесь-же на форуме информацию о том, что оказывается не для всех объектов движок вообще делает синхронизацию клиентской\серверной частей - если нет биндера для объекта, нет и синхронизации.

Синхронизация к наличию/отсутствия биндера не имеет никакого отношения. Биндер - это способ получить доступ к событиям объекта, при условии, что объект эти события предоставляет. Биндер вторичен, т.е. если он есть, то на него влияет объект, но он сам не влияет на объект, к которому прикреплён.

 

А ты вообще читал мои статьи в справочнике? Походу нет. Я там кое-что из этого расписывал. Как-то не хочется повторяться.

[Malandrinus 615]

AndreySol,

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

Пример чего, как сохранять переменную в биндере? Этого навалом в коде. Бери почти любой биндер: сталкеров, актора, монстров - там имеются примеры сохранения переменных.

[Malandrinus 615]

Artos,

ты призываешь оставлять в топике весь 'мусор'?

"мусор", как ты говоришь, может быть результатом чьей-то работы и стараний. Вот если это тупая километровая копипаста из скриптов оригинала без признаков своей мысли, то выходит, что максимум скажут "убери под спойлер". А вот человек писал что-то своё, пусть ошибался и делал неоптимально - а это хотят удалить. Я считаю, что это неправильно. Люди ошибаются и имеют право ошибаться. Где для этого самое место, как не здесь? Если не здесь, то где ещё? Пусть пишут ахинею, но только пусть пишут её сами. От этого будет польза. Если неправильно что-то написали - здесь присутствующие поправят, на то они и такие умники.

 

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

"сделайте мне то и то, а я вам подарок"

"не надо мне советов, а дайте мне чиста конкретный пример по моей конкретной проблеме"

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

 

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

 

Всё остальное - на мой взгляд не должно караться никакими санкциями, включая словесное неодобрение и удаление сообщения.

[Malandrinus 615]

Artos,

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

В этой ситуации всё ещё хуже и дополнительный код проверки не поможет. Проблема в том, что если запомнить ссылку на объект, скажем клиентский объект вертолёта, а потом удалить вертолёт или просто отправить его в оффлайн, то произойдёт следующее: движковый объект преспокойно удалится/уйдёт в оффлайн, а вот объект Lua вместе с ним не удалится, поскольку этого не даст сделать сборщик мусора из-за того, что на объект имеется ссылка. В итоге имеем объект, за которым уже нет реального движкового объекта. При попытке вызвать любой метод этого объекта будет вылет. Не помню точно, как именно этот вылет выглядит. Вроде как на нодвд это обычно вылет без лога.

Здесь два решения:

1. Не хранить ссылки на объект, а только его id + естественно делать проверку существования при каждом обращении

2. Аккуратно подчищать ссылки при удалении объектов. По идее, это надо делать в том-же биндере скорее всего в net_destroy. Здесь имеется дополнительная проблема, что отследить все ссылки на самом деле сложно чисто организационно. Вот недавно выловили баг, оставшийся ещё с оригинала. Оказывается, в таблице-хранилище каждого объекта в db.storage есть поле для текущего врага и это поле хранит именно ссылку на врага и его никто не чистит. Ошибки посыпались тогда, когда повысили "злопамятность" неписям и повысился шанс того, что они уйдут в оффлайн раньше, чем боевая схема поведения начнёт игнорировать врага. Пришлось дополнительно подчищать ещё и это поле у каждого непися, а не только глобальную таблицу. Надо понимать, что если таких мест становится слишком много, то контролировать их все становится просто невозможно, поэтому подход с хранением id является универсальным.

[Malandrinus 615]

abramcumner,

С таким же ид может быть уже совсем другой объект. Лучше чистить

Да, с id выходит тоже надо чистить, но уже реже, только при удалении объектов. Получается, что подход с id имеет свои ограничения, поскольку контролировать момент удаления можно далеко не для всех объектов. Однако для монстров/неписей/физических объектов вполне годится. Неудобно будет со всякой инвентарной мелочёвкой: патроны, аптечки/еда и т.п., поскольку они удаляются движком, но такого рода объекты обычно и не надо учитывать, а если надо, то это уже специальные случаи и имеют свои решения.

 

Так что насчёт "универсального подхода" я был неправ, нет здесь такого.

 

Но это уже будет в сталкер2

Т.е. никогда, в свете последних новостей =)

Кроме шуток, это всё возможно, но IMHO не всегда нужно. Насчёт прокси можно и подумать, а вот Null Object pattern - вещь более чем сомнительная, поскольку может (и с гарантией будет) скрывать ошибки и вместо повышения надёжности в итоге приведёт к появлению неуловимых и неотлаживаемых багов.

 

Artos,

как именно решили проблему с полем хранящим ссыку на об'ект

Вставили дополнительную чистку. В данном случае это было несложно и потребовало что-то около пяти строк кода.

 

Ну, во-первых, если 'такой же' ID'овый обект стал воагом, попав в поле - то какая разница? Ну и ничего не мешает контролировать то, что вместо исходного ID занят уже иным об'ектом. Грубая зачистка конечно упрощает проблемы, но и ... порою саму игру. ;-)

Если так разобраться, то проблем id вызывают не меньше. Помогают два факта:

1. Удаление - вообще говоря не такое уж частое действие и как правило достаточно контролируемое, если не считать всякую инвентарную мелочёвку, как я говорил выше.

2. Движок назначает новые id "на удалении" от последнего и рандомно, что несколько сглаживает возможность коллизий, хотя и не исключает их совсем.

 

[Malandrinus 615]

Artos,

хорошо видно сколь нередко возникает подмена об'екта с таким же ID'ом.

Ну значит чистить и ещё раз чистить. Вот здесь бы пригодился сборник этаких "шаблонов", т.е. типичных подходов для серверных, клиентских объектов разного типа и где и как это делать.

[Malandrinus 615]

Artos,

таблицы никак(!) не завязаны на 'онлайн'

Я полагаю, что _Призрак_ имел в виду, что при налаженной регистрации/очистке таблиц из биндера они отражают факт нахождения объекта в онлайне. Т.е. объект появляется в онлайне - он появится и в таблице, так что причинно-следственная связь здесь вполне имеется =)

Собственно, надёжность этой причинно-следственной связи никак не умаляется вторичностью её организации (не движковая, а на скриптах).