Malandrinus

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

Alex Ros, с погодой есть одна сложность. Все классы, отвечающие за погоду, находятся не в xrGame.dll, а в исполняемом файле игры. Это в свою очередь означает, что надо делать патч для всех версий этого файла: чистого (и получится ли сделать вообще на чистый, не будет ли возникать защита) + на все варианты nodvd. Это кроме собственно проблем с правкой, о которых ничего не могу сказать, поскольку погодой никогда вплотную не занимался.

*Shoker*, здесь исходные мои и KD87 посты на эту тему. Другой информации я не видел. Флаги там приведены все, хотя по некоторым информации не хватает. Старшие разряды за пределами указанных не используются. При этом, большая часть флагов достаточно внятно описана. Кроме того, флаги вообще говоря для разных объектов имеют неодинаковое значение в том смысле, что для конкретного объекта отдельные флажки могут быть безразличны.

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

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

_zero_cool_, эта цитата из lua-help не отвечает на поставленный выше вопрос. Кроме того, народ, это совершенно точно тема не о том. Здесь обсуждается язык Lua, а это какие-то системные константы, к синтаксису языка Lua и особенностям его применения не имеющие ни малейшего отношения.

AndreySol, =) Понимаешь, если у каждого объекта система своя, то это и называется - нет системы. Параметр состояние для всех инвентарных предметов, кроме оружия и брони, не сохраняется в сейве и устанавливается в 100%. Ты можешь состояние клиентского объекта установить скриптом без мудотени с нетпакетами и серверным объектом (есть штатная функция), но оно опять-же не сохранится. Если надо сохранить, то сохраняй самостоятельно и всякий раз восстанавливай при выходе объекта в онлайн. Синхронизация к наличию/отсутствия биндера не имеет никакого отношения. Биндер - это способ получить доступ к событиям объекта, при условии, что объект эти события предоставляет. Биндер вторичен, т.е. если он есть, то на него влияет объект, но он сам не влияет на объект, к которому прикреплён. А ты вообще читал мои статьи в справочнике? Походу нет. Я там кое-что из этого расписывал. Как-то не хочется повторяться.

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

Функция get_value ничего с объектом не делает, только читает из него данные. Ошибку я увидел сперва безо всякого применения этой функции, а использовал её только потом, чтобы увидеть, что именно происходит. Кстати, а что такое zone_informer? Не "Zones Editor" часом имеешь в виду? Если так, то у нас в команде его никто не использует, тестеры и подавно. Он даже не включён в код мода.

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

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

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

AndreySol, Посмотри пост в этой теме про оконные классы. Там и чуть дальше есть ответы на оба и может на другие подобные вопросы. GetWndPos но это только в ЗП. Упомянутый выше xml:InitStatic("имя_статика", self) собственно и возвращает объект статика. Потом делай с ним что хочешь скриптами. Добавлено через 2 мин.: Насчёт второго вопроса я неправ, CScriptXmlInit я выходит так и не расписал, руки не дошли.

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

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

Artos, Вот не соглашусь. Рассмотрим типичный сценарий проверки наступления некоего события через N единиц времени после последнего срабатывания. Код может выглядеть как-то так: local last_event_time = 0 function update() if game.time() > last_event_time + events_interval then last_event_time = game.time() -- здесь делаем работу, связанную с событием end end Теперь смотрим, что происходит после переполнения счётчика. Текущее значение времени становится почти нулевым, а мы хотим дождаться момента, когда оно станет больше последнего значения + <время между событиями>. Но последнее значение осталось очень большим, близким к переполнению. Выходит, что мы попросту не дождёмся следующего события никогда. В приведённом выше примере ситуация выправится только после перезагрузки игры, когда значение предыдущего времени вновь обнулится. Т.е. несрабатывание продлится как минимум до перехода на другой уровень, перестанут спавниться монстры, не сработает какой-то квест и т.п. А если мы рассмотрим этот же алгоритм, но уже в варианте с сохранением счётчика в сохранёнке, то всё становится совсем грустно. local last_event_time function load(packet) last_event_time = packet:r_u32() end function update() if game.time() > last_event_time + events_interval then last_event_time = game.time() -- здесь делаем работу, связанную с событием end end function save(packet) packet:w_u32(last_event_time) end Код приведён с некоторой степенью условности, но проблему иллюстрирует: предыдущее значение сохранится и зафиксируется. Ни загрузка сейва заново, ни переход на другой уровень уже не исправят ситуацию. Вообще-то, за исключением вот этой проблемы с багом, я не вижу никаких иных проблем в использовании этого класса. Он достаточно легковесный, внутри всего 8 байт, и вычисления на его основе весьма быстрые, поскольку производятся в своей основе на целочисленной арифметике с 64-х разрядным счётчиком. Этот класс позволяет в большинстве случаев обходиться без разложения его на компоненты и использовать его самого для сравнений больше/меньше и приращений значений. Очень удобная штука и вдобавок даёт сервис получения дней, месяцев и т.д. Здесь, увы, уже полагаться на случай нельзя. Тем более, что система появления бага непонятна, его можно ожидать когда угодно и где угодно. Лично я буду теперь ставить заплатки везде, где найду.

Artos, Пока это обсуждение идёт в контексте использования и проблем использования движковых функций. Если руки дойдут, почищу позже тему и оставлю тезисно обсуждение под спойлером. 1. аргумент delta неточен в том смысле, что при превышении одной секунды всегда возвращает одну секунду и уже будет фактически врать. Для апдейта актора это может и не критично, а если эта проверка стоит где-то в другом клиентском объекте, то уже будет потенциальный косяк. 2. Я могу захотеть делать некие вычисления не каждый апдейт, а с большим периодом. Это в частности актуально, когда я вешаю проверку на событие с низким приоритетом. В этом случае период вообще заранее не известен. Заниматься в этом случае суммированием аргументов выглядит уже не проще, чем использование CTime. 3. Это будет крайне плохо работать в случае прокрутки времени во время сна, когда фактор ускорения времени выставляется на значения десятки тысяч, а апдейты идут со всё той же скоростью. Погрешность вычислений может быть колоссальная, в то время как используя CTime об этом можно вообще не думать. Может что-то ещё забыл упомянуть, но выглядит так, что мотивация использовать CTime есть. Конечно, именно для вычисления времени между обновлениями можно было бы использовать 32-х разрядный счётчик игрового времени game.time(), поскольку здесь нам вроде как и не нужно абсолютное время. Но он зараза переполняется каждый игровой месяц. Вот из-за этого единственного проблемного момента, который случается так редко, но таки случается, нам и приходится использовать вычисления на основе CTime. Это не считая тех случаев, когда нам собственно надо сохранить некий абсолютный момент времени (для генерации события, выброса скажем или чего угодно другого). В этом последнем случае альтернативы CTime просто нет.

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

Artos, Эффект устойчивый? в качестве оффтопа. Когда я перехожу на Склады читовым телепортом (т.е. не по сюжету), то почти всегда вылетаю как раз через пару минут. Может конечно и случайное совпадение. Однако ж, теперь выходит надо переделывать весь код, завязаный на Ctime

Здесь использовалось Реальные географические координаты

AndreySol, Краем уха слышал где-то, что вторая маркирует предмет, чтобы не удалялся менеджером смерти. Реализовано ли это удаление/игнорирование скриптами (есть функция проверки этого маркера) или это влияет на некое движковое удаление предметов я понятия не имею, как не уверен и в точности этой информации. Мне кажется, что я всё-таки видел в оригинальных скриптах использование второй функции. Это вращение текстуры окна. Вот кстати показательный пример невероятной заботы пыс о сообществе. Сами они эту функцию нигде не использовали. Как только у них дошли руки (в ЗП) - тут же и вырезали, несмотря на то, что функция используется в модах.

Кое-что всё-таки вырезано, например настройка партиклов.